Skip to content

chains: add Sentrix Mainnet (7119) and Sentrix Testnet (7120)#8283

Closed
satyakwok wants to merge 1 commit intoethereum-lists:masterfrom
satyakwok:add-sentrix-7119-7120
Closed

chains: add Sentrix Mainnet (7119) and Sentrix Testnet (7120)#8283
satyakwok wants to merge 1 commit intoethereum-lists:masterfrom
satyakwok:add-sentrix-7119-7120

Conversation

@satyakwok
Copy link
Copy Markdown

Adds two new chain definitions:

  • Sentrix Mainnet (chain ID 7119, ticker SRX) — production EVM-compatible Layer-1, live since 2026-04-25 with revm 38 embedded execution and Voyager DPoS+BFT consensus.
  • Sentrix Testnet (chain ID 7120, ticker tSRX) — public testnet with faucet at faucet.sentrixchain.com.

Both networks expose:

  • Standard EVM JSON-RPC at the listed endpoints (HTTP + WebSocket on `/ws`)
  • EIP-3091-compatible block explorers (custom Sentrix Scan + Blockscout sidecar on mainnet)
  • 18-decimal nativeCurrency for EVM tooling compatibility (the underlying ledger is 8-decimal native, but `eth_getBalance` returns 18-decimal wei-scaled values for MetaMask / ethers / viem)

Source code: https://github.com/sentrix-labs/sentrix
Brand assets: https://github.com/sentrix-labs/brand-kit
Public RPC + endpoint inventory: https://sentrixchain.com

@github-actions
Copy link
Copy Markdown

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.

@satyakwok
Copy link
Copy Markdown
Author

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.

satyakwok added a commit to Sentriscloud/frontend that referenced this pull request Apr 30, 2026
* 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>
@satyakwok
Copy link
Copy Markdown
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant