Skip to content

fix(stoc): remove duplicate EVM chain entries + align txPage with EIP-3091#1491

Open
tranduybau wants to merge 2 commits into
chainapsis:mainfrom
tranduybau:fix-stochain-duplicate-evm-entry
Open

fix(stoc): remove duplicate EVM chain entries + align txPage with EIP-3091#1491
tranduybau wants to merge 2 commits into
chainapsis:mainfrom
tranduybau:fix-stochain-duplicate-evm-entry

Conversation

@tranduybau

@tranduybau tranduybau commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

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.json and evm/eip155:1999.json entries and keeps only the canonical cosmos/stoc.json + cosmos/tstoc.json registrations. 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.json txPage to /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.json chainId is corrected from tstoc to tstoc_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 with chain id mismatch. Mainnet stoc.json keeps its existing chainId: "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-sign features 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 different 0x address 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 unified cosmos + evm entry 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

  • Delete evm/eip155:1306.json (STO Chain mainnet, chain id 1306)
  • Delete evm/eip155:1999.json (STO Chain testnet, chain id 1999)
  • cosmos/stoc.json: txPagehttps://stochainscan.io/en/tx/{txHash} (EIP-3091)
  • cosmos/tstoc.json: chainIdtstoc_1999-1 (match genesis)

Test plan

  • Open Keplr after applying this change, confirm STO Chain (mainnet + testnet) each show only one entry instead of two
  • Sign a tx on STO Chain testnet via Keplr — succeeds (no chain id mismatch)
  • Tap on a tx in the Keplr activity view for STO Chain — link opens the explorer tx page (/en/tx/<hash>) successfully
  • No regression on other Cosmos-only chains in this registry (only stoc files touched)

…-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)
@vercel

vercel Bot commented Jun 9, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
keplr-chain-registry Ready Ready Preview, Comment Jun 9, 2026 5:53pm

Request Review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread evm/eip155:1306.json
@@ -1,32 +0,0 @@
{

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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).
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