chains: add Sentrix Mainnet (7119) and Sentrix Testnet (7120)#8283
chains: add Sentrix Mainnet (7119) and Sentrix Testnet (7120)#8283satyakwok wants to merge 1 commit intoethereum-lists:masterfrom
Conversation
|
You successfully submitted a PR! Due to the amount of PRs coming in: we will only look at PRs that the CI is happy with. We can also not hold your hand getting the CI green - just look how others that where merged did it and RTFM. So as long as there is any CI check that reports an error - no human will look at this. You might be able to ask for some support after supporting the project - e.g. by sending funds to lists.eth. When you fixed things after a requested change - then you also need to (re-)request a review. |
|
Hey maintainers — first-time-contributor PR here, the three CI workflows (Check JSON Schema / Build / Prettier) are stuck on `action_required` since they need a maintainer to approve dispatch. I did run the schema validation locally against `tools/schema/chainSchema.json` from this repo: both `eip155-7119.json` and `eip155-7120.json` pass. `shortName` (`srx`, `srx-testnet`) and `chainId` (7119, 7120) are both unique against the live chainid.network/chains.json. Could one of you click "Approve and run workflows" so the build can actually report? Happy to fix anything the gradle check turns up. |
* feat(scan): Sourcify verification badge on address page Add lib/sourcify.ts hook + components/common/SourcifyBadge.tsx that queries https://verify.sentrixchain.com/files/any/<chainId>/<addr> to detect contract source verification status: - "perfect" → green "verified" badge linking to Sourcify - "partial" → amber "partial match" badge - "none" → hidden by default (no noise on EOAs/unverified contracts) Wired into [locale]/address/[addr]/page.tsx PageHeader actions next to the existing label kind chip. Self-hosted Sourcify deployed on vps4 supports both mainnet (7119) and testnet (7120). All 8 canonical contract deployments (WSRX, Multicall3, TokenFactory, SentrixSafe across both chains) verified with perfect bytecode match. Tested: typecheck clean, build OK, scan service restarted. * feat(scan): supply / forks / epochs pages + finality + rail badges Three new top-level pages aimed at "explorer that listing teams + delegators + technical reviewers can read top-to-bottom and understand". Same data sources the rest of the explorer already uses (no new backend endpoints required for Phase 1): - /supply — single canonical SRX breakdown URL. Headline stat row, donut distribution (circulating / premine / bonded / remaining-to-mint / burnt), per-wallet premine breakdown with addresses pulled from the existing canonical-addresses registry, protocol-sentinel addresses called out. Pulls live values via useStats + useValidators so it reflects real chain state without baking magic numbers into the page. - /forks — fork-activation timeline. Source of truth in lib/forks/registry.ts, hand-synced against U64_MAX_FORK_GATES.md. Each fork gets a card with state (active / scheduled / dormant) + activation height + a non-technical "what changed when" description. Cross-network comparison table at the bottom so drift between mainnet + testnet is visible at a glance. Includes the 2026-04-30 JAIL_CONSENSUS activation (mainnet h=950400, testnet h=1030500) and the deliberately-dormant NFT_TOKENOP_HEIGHT (DO NOT activate marker). - /epochs — current-epoch detail with progress bar (blocks-into-epoch %), total bonded, rewards accrued. Past 12 epochs derived locally from the current epoch_number + EPOCH_LENGTH=28800; entries deep-link to the first / last block of each epoch. Footnote explains what an epoch does (validator-set rotation, reward settlement, slashing window, jail evidence boundary). Two new badge components for the deeper tx/block detail pages we'll wire in next: - RailBadge — distinguishes Sentrix's four transaction rails (EVM call / native SRX transfer / SRC-20 native TokenOp / native StakingOp). Sentrix is one of the only chains where SRC-20 lives at the protocol level alongside ERC-20, so users need to be told which rail they're looking at; classifyRail(tx) helper centralises the heuristic. - FinalityBadge — Sentrix BFT finality ladder (Pending → Included → Justified → Finalized). The "Justified" / "Finalized" distinction is what exchanges and bridges should pin, and no other EVM explorer surfaces it because no other EVM chain has 2/3+1 stake-weighted precommit-supermajority finality at 1s blocks. classifyFinality() helper computes the state from txBlockHeight + latestHeight + hasJustification. Nav: /supply added to the top header ("Supply"); /epochs + /forks linked from the footer Explorer column. i18n nav.supply added in en/id. `pnpm typecheck` clean across the workspace; lint reports only existing warnings unrelated to this PR. * feat(scan): wire RailBadge + FinalityBadge into the tx detail page Both badges shipped in PR #7 but weren't wired anywhere yet. This puts them at the top of every tx page so the user instantly sees "what kind of tx is this" + "how settled is it": - Page header actions now render RailBadge + FinalityBadge alongside the existing success/failed status — three compact badges grouped together like Etherscan's "Status: Success | Block: 12345 (Finalized)" cluster, but Sentrix-aware. - The Status row in the Summary card now stacks the success/failed badge with the finality badge (Pending / Included / Justified / Finalized), with a hint explaining what the four states mean. - A new "Rail" row sits below Status: shows the rail badge + a contextual one-liner explaining what that rail means (EVM call vs native SRX transfer vs SRC-20 op vs native staking op). This is the teaching aid we keep getting support tickets about — users don't know which rail their tx travelled on. Finality classification: pending if no block_height, finalized if descendant has landed (chain head > tx block), else justified for any block past the Voyager activation height (`h >= 579_047` — every Voyager block ships a justification by construction). Rail classification piggybacks on the centralised `classifyRail()` heuristic the badge component shipped with — to_address sentinels 0x0000…0000 / 0x0000…0100 → SRC-20 / Staking; data prefix "EVM:" → EVM; everything else → Native. `pnpm --filter @sentriscloud/scan typecheck` clean. * feat(chain-landing): publish canonical chain.json + tokenlist.json Three new static endpoints served by the chain-landing app at sentrixchain.com: - /chain.json — Sentrix Mainnet (7119) descriptor - /chain-testnet.json — Sentrix Testnet (7120) descriptor - /tokenlist.json — Uniswap-format token list (WSRX 7119 + WtSRX 7120) Mirrors the ethereum-lists/chains#8283 metadata one level deeper — includes consensus + finality model + canonical contract addresses + Sourcify verifier URL inline so a tooling integrator can read a single JSON and have everything they need (RPC, WS, explorer, verifier, WSRX address, decimals, finality semantics). Token list follows the standard Uniswap schema so dApp UIs that already speak it (Uniswap interface, OpenSea-style allowlists, portfolio trackers) can drop the URL in without bespoke parsing. URLs go live the next time chain-landing redeploys via the existing sentrix-landing systemd flow on the build host. --------- Co-authored-by: satyakwok <satyakwok@users.noreply.github.com>
|
Closing this in favour of #8266 — same chain registration (eip155-7119 mainnet + eip155-7120 testnet) but with active maintainer review history and the changes @marcocastignoli requested already pushed (commit 07872f8: dropped non-standard `explorers` field). Apologies for the duplicate, missed the older PR was still open when I opened this one. Continuing to address feedback over there. |
Adds two new chain definitions:
Both networks expose:
Source code: https://github.com/sentrix-labs/sentrix
Brand assets: https://github.com/sentrix-labs/brand-kit
Public RPC + endpoint inventory: https://sentrixchain.com