fix(stoc): remove duplicate EVM chain entries + align txPage with EIP-3091#1491
fix(stoc): remove duplicate EVM chain entries + align txPage with EIP-3091#1491tranduybau wants to merge 2 commits into
Conversation
…-3091
- Delete evm/eip155:1306.json (mainnet) and evm/eip155:1999.json (testnet).
These duplicates caused STOChain to display as 2 separate entries in
Keplr (one Cosmos, one EVM with broken balance fetch). Single
cosmos/stoc.json and cosmos/tstoc.json registration is the canonical
pattern for STOChain — same approach as Kava: the chain has an EVM
module but the Keplr entry covers only the Cosmos side; users connect
MetaMask separately for EVM.
- Update cosmos/stoc.json txPage to /tx/{txHash} (EIP-3091 spec). The
STOChain explorer ships /tx/ as the canonical path; /transaction/
stays as a backward-compatible alias.
STOChain uses cosmos coinType 118 + 6-decimal ustoc denom, which makes
adding eth-address-gen / eth-key-sign features non-standard (every
other dual cosmos+EVM chain in this registry uses coinType 60 + 18
decimals). Following Kava's precedent, the Keplr entry stays Cosmos-only.
EVM users continue to use MetaMask against STOChain's EVM JSON-RPC.
Verified live (2026-05-16):
- Cosmos RPC https://rpc-stoc-mainnet.stochainscan.io network=stoc height=5268223
- Cosmos REST https://api-stoc-mainnet.stochainscan.io bech32_prefix=stoc bond_denom=ustoc
- EVM RPC https://evm-stoc-mainnet.stochainscan.io eth_chainId=0x51a (1306)
- Cosmos RPC https://rpc-stoc-testnet.stochainscan.io network=tstoc height=873955
- EVM RPC https://evm-stoc-testnet.stochainscan.io eth_chainId=0x7cf (1999)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 04700fff0c
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| @@ -1,32 +0,0 @@ | |||
| { | |||
There was a problem hiding this comment.
Skip deleted registry files during validation
Deleting this JSON file makes the existing PR workflow fail before the change can merge: .github/workflows/pull-request-validation.yml iterates steps.changed-files.outputs.all_changed_files for cosmos/**, evm/**, and svm/**, and the changed-files action reports deleted files in that output, so this deleted path is still passed to yarn ts-node src/index.ts evm/eip155:1306.json; validateEvmChainInfoFromPath then attempts to read the now-missing file. Please either adjust the workflow to validate only existing/non-deleted JSON files or keep deletion handling out of all_changed_files.
Useful? React with 👍 / 👎.
The testnet genesis chain_id is tstoc_1999-1 (chain redeployed 2026-06-09 with full Evmos-style chain id), but the Keplr registry entry was still the short form 'tstoc'. Keplr passes chainId to upstream RPC verbatim on signing flow, so the mismatch made signed transactions fail with 'chain id mismatch'. Mainnet stoc.json keeps chainId 'stoc' (matches genesis, unchanged).
Summary
STO Chain was registered twice in Keplr — once as a Cosmos chain (
cosmos/stoc.json, coinType 118) and once as an EVM chain (evm/eip155:1306.json, coinType 60), with a matching pair for testnet. The EVM-side entries appeared as a second STO Chain item in Keplr that could not fetch balances, because the chain natively uses coinType 118 — addresses derived from coinType 60 do not match what STOChain expects on either the Cosmos or the EVM side.This PR removes the duplicate
evm/eip155:1306.jsonandevm/eip155:1999.jsonentries and keeps only the canonicalcosmos/stoc.json+cosmos/tstoc.jsonregistrations. Users who want EVM access continue to add the EVM RPC to MetaMask / Keplr separately, the same pattern Kava uses for its EVM module.It also updates
cosmos/stoc.jsontxPageto/tx/{txHash}, the EIP-3091-style canonical path served by the STOChain explorer. The existing/transaction/path stays in place as a backward-compatible alias on our side, so no live links break.Finally,
cosmos/tstoc.jsonchainIdis corrected fromtstoctotstoc_1999-1. The testnet was redeployed on 2026-06-09 with the full Evmos-style chain id (<name>_<evm-id>-<rev>) in its genesis, but the registry entry still held the short form, which caused signed transactions to fail withchain id mismatch. Mainnetstoc.jsonkeeps its existingchainId: "stoc"because the mainnet genesis is the short form.Context
Discussion: #1467
The issue lays out why we cannot just add
eth-address-gen/eth-key-signfeatures to the cosmos entry: STOChain uses coinType 118, but every chain in this registry that ships those features today uses coinType 60. Deriving the EVM address from a coinType-118 path produces a different0xaddress from the one MetaMask would compute, so a unified entry under the current Keplr behaviour would still leave users confused. Removing the broken EVM entry is the safest short-term fix; a unifiedcosmos + evmentry would need maintainer guidance on how Keplr should handle coinType 118 + EVM derivation, which we are happy to follow up on once you have bandwidth.Changes
evm/eip155:1306.json(STO Chain mainnet, chain id 1306)evm/eip155:1999.json(STO Chain testnet, chain id 1999)cosmos/stoc.json:txPage→https://stochainscan.io/en/tx/{txHash}(EIP-3091)cosmos/tstoc.json:chainId→tstoc_1999-1(match genesis)Test plan
chain id mismatch)/en/tx/<hash>) successfully