Crosschain Identifier Specification

StagnantStandards Track: Core
Created: 2020-10-21
Weijia Zhang (@weijia31415), Peter Robinson (@drinkcoffee)
DiscussionsOriginal linkEdit
1 min read

The EIP-3220 proposal is for a self-verifying unique blockchain identifier, called the crosschain-id, that deals with forks. It aims to improve interoperability between different blockchains by providing a unique identifier to characterize and describe a blockchain, which can be used for registration and lookup services to retrieve blockchain metadata. This is particularly important for inter-chain interoperability when chains are heterogeneous and incompatible.

Anyone may contribute to propose contents.
Go propose

Simple Summary

A self-verifying unique blockchain identifier that deals with forks.


The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain. We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.


With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace. There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network. The growth of public and private blockchains imposes challenges for inter-chain interoperability, particularly when these chains are heterogeneous and incompatible. Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.

EIP-155 provides a unique identifier to a blockchain to provide simple relay attack protection. This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.

The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid. Also, it does not address the issue for two forked blockchains having the same chainid.

Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved. A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:

  • should provide identification, description, and discovery of blockchains.
  • should provide unique identification of each blockchain in the crosschain service ecosystem.
  • should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.
  • should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.
  • should provide a mechanism for a joining blockchain to register to the ecosystem.
  • should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.
  • should provide a mechanism to get some critical information of the blockchain
  • should provide a mechanism to differentiate an original blockchain and a forked blockchain
  • should provide a mechanism to verify a chainid without external registration service


Definition of a 32 byte crosschain id

Truncated Block Hash16This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order.
Native Chain ID8This is the Chain Id value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of Chain Id, this value is zero.
Chain Type2Reserve 0x00 as undefined chaintype. 0x01 as mainnet type. 0x1[0-A]: testnet, 0x2[0-A]: private development network
Governance Identifier2For new blockchains, a governance_identifier can be specified to identify an original owner of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an owner, this field is zero.
Reserved3Reserved for future use. Use 000000 for now.
Checksum1Used to verify the integrity of the identifier. This integrity check is targeted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier.


We have considered various alternative specifications such as using a random unique hex string to represent a blockchain. The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block. A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations. The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.

Backwards Compatibility

Crosschainid can be backward compatible with EIP-155. The crosschain id contains an 8 byte segment to record the Native Chain ID. For Ethereum chains, that can be used for a value intended to be used with EIP-155.

Security Considerations

Collision of crosschain id: Two blockchains can contain the same crosschain id and hence making the mistakenly transfer assets to a wrong blockchain.
This security concern is addressed by comparing the hash of the crosschain id with the hash of the genesis block. If it matches, then the crosschain id is verified. If not, the crosschain id can be compared with the forked blockhash. If none of the blockhash match the crosschain id hash, then the crosschain id cannot be verified.

Preventing relay attack: Although crosschain id by itself is different from chainid and it is not signed into blockchain transaction, the crosschain id can still be used for presenting relay attack. An application that handles crosschain transaction can verified the crosschain id with its blockhash and decide whether the transaction is valid or not. Any transaction with a non-verifiable crosschain id should be rejected.

The crosschain-id are not required to be signed into blockchaid tx. For blockchains that do not cryptographically sign crosschain id into the blocks, the crosschain id cannot be verified with the blocks itself and have to be verified with external smart contract address and offchain utilities implemented based on the crosschain id specification.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Supported by