Enhancement API to align with Chain Agnostic Improvement Proposals (CAIPs)

[MASDXI]

Problem description

The current design of CAMARA the blockchainNetworkId proposed format is <L1_Ecosystem>:<sub_id> may face limitations in certain future scenarios, for instance. The ecosystem is going to be complex e.g. rootstock is a sidechain of the bitcoin, it's using evm address format which is also used eip155, another is moonbeam or other parachain are considered to be part of the polkadot ecosystem. Some parachain also support EVM-address, another is the emerging of the layer3 or L3 network such as apechain is built on top of optimism which also eip155 format, Deutsche Bank's L2 that build on zksync also use eip155

Possible evolution

Adopt CAIP-2 for the blockchain identifier and CAIP-10 for blockchain address or account.

Example:

• moonbeam will be polkadot:fe58ea77779b7abda7da4ec526d14db alias eip155:1284:address
• rootstock will be eip155:30:address
• optimism will be eip155:10:address
• evmos will be cosmos:evmos_9000-1:address alias eip155:9000:address
• avalanche will support three formats P-Chain, X-Chain, and C-Chain alias eip155:43114 for C-Chain only.

To ensure compatibility, networks supporting the eip155 format should include an alias.

Additional context

Collaborating with the Chain Agnostic community could help identify widely recognized blockchains and document them on namespace repository.

Supplementary

• List of chains build on zksync https://forum.zknation.io/t/list-of-zk-chains-that-make-up-the-elastic-chain/343
• List of chains build on optimism https://www.superchain.eco/superchain-index
• Polygon CDK building layer3 https://polygon.technology/blog/l3s-v-aggregated-l2s-an-analysis-for-developers

[PedroDiez]

Thanks for the input. This topic will be discussed within the WG.
Initially it will be managed for the MetaRelease Fall25

[MASDXI]

@PedroDiez @grgpapadopoulos , I've reviewed the meeting minutes, and the point raised by @grgpapadopoulos about making the implementation more feasible for Bitcoin.

Example list of Bitcoin L2s 2025

• RSK is a sidechain; it has it own chain ID in EIP-155
• MERL is a zk-rollup develop on top CDK which is EVM-compatible; it has it own chain ID in EIP-155
• DOVI is also EVM-compatible so it can rely on EIP-155

These examples show that many sidechains and L2s in the Bitcoin ecosystem—particularly those that are EVM-compatible—can adopt the EIP-155 format, effectively making them identifiable as EVM chains rather than using BIP-122.

Additional Observations

• LIQUID is not EVM-compatible. It extends the Bitcoin codebase and does not use an EIP-155 chain ID, but could instead follow BIP-122.

• QTUM is more bitcoin codebase, but they also support EVM. It's hard to consider using BIP-122, the first blockhash, or use EIP-155 because they define their EIP-155 chain ID. but I suggest it should be BIP-122 as primary and EIP-155 for alias

• STACK STX is a unique L2 that doesn’t align with EIP-155 or BIP-122. It follows a fully independent design. see configuration

Important

STACK nampace spec here https://github.com/ChainAgnostic/namespaces/blob/main/stacks/caip2.md

• Lightning Network LN as a state channel solution poses unique challenges. It relies on channel IDs or channel points, not chain IDs. Tracking new or expired channels dynamically would be impractical for standard chain ID resolution.

• Other blockchains that support EIP-155 but do not exist in CAIP-2, IOTX, IOTA and IOTA-EVM, NEO and NEO-X which is an EVM-compatible sidechain. can use EIP-155 for alias, but I recommend the implementer not to adding them to the API for now.

• Alias SHOULD not be used as the primary blockchain identifier. seen on additional consideration of the Herdera namespace.

Possible Solution/Approach

• Following the CAIP-2 first; if it does not exist on CAIP-2 .
• If no, then check the codebase to see if the blockchain can support CAIP-2, example, QTUM from above.
• If it can't be used, CAIP-2 follows up with the core developer and creates an issue requesting to support CAIP-2.
• If the network is spinning a sidechain or layer to support Bitcoin, Ethereum, or Polkadot then treating it as a separate blockchain network.

Example scenarios

• If the blockchain that adopts the UTXO style but uses PolkadotSDK as the underlying technology, the primary blockchain identifier, CAIP-2, is pokadot:<hash> and can have BIP-122 as an alias.
• If the blockchain that is forked from Algorand but I extend the codebase to support the EVM can have EIP-155 as an alias.
• If the blockchain is that forked from Hashgraph/Hiero but extends the codebase to support UTXO transactions, Bitcoin-like and EVM can have BIP-122 and EIP-155 as aliases if all transactions are supported.

TL;DR

EVM‑compatible Bitcoin L2s should adopt EIP‑155 as the chain ID.
Non‑EVM ones (e.g., Liquid) should use BIP‑122.
Qtum liked characteristic: primary = BIP‑122, alias = EIP‑155.
No dynamic networks (like Lightning) — they aren’t chain-ID compatible.
Follow CAIP‑2 first, use chain-specific rules only if needed, and open requests when required.

[MASDXI]

This enhancement idea aligns with other existing tools, on the market.
metamask-multichain, walletconnect-session, ERC-7768, spruce-id, [DRAFT]did-pkh, privy, farcaster, did-jwt, and etc.

[PedroDiez]

Hi,

Thanks for all the input @MASDXI. It has been a valuable information

After intenal WG discussion, we agree that in the long-term the use of CAIP-10 adoption seems to be a feasible solution.

(Adopt CAIP-2 for the blockchain identifier and CAIP-10 for blockchain address or account) in case we keep two concepts.

Nonetheless, we agree within the WG on keeping so far the current approach until having early implementations regarding this version and getting that feedback from the comminity that is valuable for the working group in terms of usability and concepts defined.

Therefore we keep this issue ON-HOLD and we will resume it when having early implementations

cc @grgpapadopoulos

[MASDXI]

Hi,

Thanks for all the input @MASDXI. It has been a valuable information

After intenal WG discussion, we agree that in the long-term the use of CAIP-10 adoption seems to be a feasible solution.

(Adopt CAIP-2 for the blockchain identifier and CAIP-10 for blockchain address or account) in case we keep two concepts.

Nonetheless, we agree within the WG on keeping so far the current approach until having early implementations regarding this version and getting that feedback from the comminity that is valuable for the working group in terms of usability and concepts defined.

Therefore we keep this issue ON-HOLD and we will resume it when having early implementations

cc @grgpapadopoulos

Ok thanks for update @PedroDiez . I will try to revise the standard while try to keep it simple as must as possible in mind but still alignment with the community and covering the case that non EOA account e.g. a smart contract, a chaincode, or a program you name it. (Most likely case multisig-wallet, smart-wallet) which is can boost the concept (DePIN, Buy Now Pay Never).