Cross-chain identifiers: glossary

A 0-100 composite score summarising an endpoint’s TLS configuration, certificate quality, post-quantum readiness, and JSON-RPC reachability. Higher is better.

The posture score is the average of four sub-scores, each 0-100: Certificate (validity, expiry, key type, hostname match), TLS profile (version, cipher suite, ALPN, OCSP stapling), Post-quantum (X25519MLKEM768 => 90+, classical => 40), and RPC reachability (successful eth_blockNumber / getSlot round-trip => 100, TLS-alive only => 30). Score is rebased into a letter grade using the standard academic scale.

A 0-100 score based on the total time the prober took to complete DNS + TCP + TLS handshake + JSON-RPC round-trip against the endpoint. Independent from posture.

The speed score is a piecewise linear mapping from total probe time (in milliseconds) to a 0-100 number: <=250ms => 100, <=500ms => 90-100, <=1000ms => 70-90, <=2000ms => 40-70, <=4000ms => 15-40, >4000ms => sub-linear taper to 0. Probes originate from the RPCScan prober in DigitalOcean NYC1; endpoints close to that region score higher than distant ones.

A standards series maintained by the Chain Agnostic Standards Alliance (CASA) for things that need to work across every blockchain, not just Ethereum.

CAIPs are to multi-chain wallets, indexers, and bridges what EIPs are to Ethereum: numbered, debated, ratified specifications. Each CAIP defines either a meta-standard (like CAIP-2 "blockchain identifiers") or a per-namespace profile (like the bip122 namespace's CAIP-2 profile that says "use the first 32 hex chars of the genesis blockhash"). Every CAIP is CC0-licensed.

The Ethereum-specific equivalent of a CAIP. Numbered, ratified specifications for protocol, application-layer, and tooling changes.

EIPs predate CAIPs. Some EIPs are Ethereum-specific (EIP-155 = chainId for replay protection, EIP-1559 = fee market). Others, like EIP-7930 (Interoperable Addresses), are deliberately cross-chain by design and pair with a CAIP for the per-namespace profile.

A short text string that uniquely names a blockchain. Format: "<namespace>:<reference>".

CAIP-2 is the workhorse identifier; every wallet, dapp, and bridge speaks it. The namespace says which kind of chain ("eip155" for EVM, "solana", "bip122" for Bitcoin and its forks, "cosmos", etc.). The reference identifies the specific chain inside that namespace. CAIP-2 limits references to 32 characters of [-_a-zA-Z0-9], which is why genesis hashes are truncated.

A blockchain identifier (CAIP-2) plus an address, separated by a colon. Names a specific account on a specific chain.

If CAIP-2 names the chain, CAIP-10 names a wallet/contract/account on that chain. Format: "<namespace>:<reference>:<address>". The address format is whatever the namespace defines (hex with EIP-55 checksum for EVM, base58 for Solana, bech32 for Bitcoin SegWit, etc.).

The directory of all approved blockchain namespaces ("eip155", "solana", "bip122", "cosmos", "polkadot", and ~40 others).

CAIP-104 is the registry; chainagnostic/namespaces is its on-disk form. Each namespace has its own folder containing a CAIP-2 profile (how to write a chain identifier in this namespace), optionally a CAIP-10 profile, and optionally a CAIP-350 profile (binary form). RPCScan tracks all 43 namespaces; see the index page.

How to encode a CAIP-2 chain identifier as raw bytes for on-chain use. The binary half of EIP-7930 Interoperable Addresses.

CAIP-2 strings (e.g. "eip155:1") are great for humans but expensive on-chain. CAIP-350 defines per-namespace rules for compressing them into compact byte sequences. Each namespace gets a 2-byte ChainType tag (eip155=0x0000, bip122=0x0001, solana=0x0002, starknet=0x0003) and a variable-length ChainReference. Only those four namespaces have published CAIP-350 profiles so far.

A binary address format that bundles "which chain" and "which account" into one self-describing byte string, so smart contracts can route to any chain without out-of-band metadata.

Layout: Version (2 bytes BE) | ChainType (2 bytes) | ChainReferenceLen (1 byte) | ChainReference (N bytes) | AddressLen (1 byte) | Address (N bytes). The "chain-only" form sets AddressLen=0x00 and is what we tag every platform with. ChainType + ChainReference values come from the per-namespace CAIP-350 profile.

The first half of a CAIP-2 identifier, a short string naming a group of chains that share serialization conventions.

A namespace covers every chain that follows the same rules for chain identification, address encoding, and (when applicable) binary serialization. "eip155" covers every EVM chain; "bip122" covers Bitcoin and its forks; "cosmos" covers every Cosmos-SDK / Tendermint chain. CAIP-104 lists the registered namespaces; chainagnostic/namespaces is the source of truth.

A 2-byte tag that identifies the namespace inside a binary CAIP-350 / EIP-7930 address. Allocated by the CAIP-350 namespace profile.

ChainType is to CAIP-350 what the namespace string is to CAIP-2: a compact identifier for the chain kind. Currently allocated values: 0x0000 = eip155 (EVM), 0x0001 = bip122 (Bitcoin), 0x0002 = solana, 0x0003 = starknet. Two bytes leave 65,536 possible namespaces; the registry expands as more namespaces publish CAIP-350 profiles.

The variable-length, namespace-specific bytes that identify a specific chain inside a namespace. Per-namespace rules are spelled out in each namespace's CAIP-350 profile.

For eip155 (EVM): the chainId encoded as a minimum-bytes big-endian unsigned integer with no leading zero. Ethereum is "0x01" (1 byte), Sepolia is "0xaa36a7" (3 bytes). For solana: 32 raw bytes of the genesis blockhash. For bip122: the first 16 bytes of the genesis blockhash. For starknet: the UTF-8 bytes of the chain id string ("SN_MAIN", "SN_GOERLI"). Length is prefixed in the binary form so parsers know how many bytes to read.

The hash of a chain's very first block. Functions as a permanent unique fingerprint for the chain because no one can forge a block-zero retroactively.

Many namespaces use the genesis hash as their canonical identifier: Bitcoin and its forks, Solana, Polkadot, Substrate, Concordium, Reef, Hive, Tezos. CAIP-2 typically truncates it to 32 characters; CAIP-350 sometimes preserves it in full or in a shorter binary form. The fork point matters: a hard-fork that started from the original genesis (BCH from BTC) inherits the same genesis hash.

EIP-7930's name for the bundled (chain, account) byte string. Used by cross-chain contracts that need to route a payment or message to a specific account on a specific chain.

A regular address is just bytes, meaningless without out-of-band knowledge of which chain it lives on. An Interoperable Address bundles the chain identity into the address itself, so a routing contract can read a single byte string and know exactly where to send. The chain-only variant (no address bytes) tags a chain itself; we use that variant on every platform page.