Chain profiles

Part of the libID protocol specification.

1. Scope

This document holds one profile per family of Consumer Chains. Common §2 defines what a Chain Profile is, and REQ-COMMON-01C, REQ-COMMON-01D, REQ-COMMON-01F, REQ-COMMON-34B and REQ-COMMON-42 say what one owes. §2 below is what holds across every profile; each later section answers those duties for one family. EVM chains are §3; a family that identifies, authenticates, or encodes differently — Solana, Move — takes a section of its own here rather than a document of its own.

A profile defines no ceremony construction. It says what the values a ceremony already commits are on one chain, so that a Canonical Runtime composing for a destination and the Platform Verifier deployed there commit the same bytes. It also says how a fee travels on that chain and how a rejected call undoes it, so that every hop of the verification path pays and rolls back alike. Selecting one is destination selection, not proof authority.

2. What every profile fixes

duty	required by
the canonical Chain Identifier, and the exact bytes it contributes	REQ-COMMON-01C
how the chain authenticates the Transaction Author	REQ-COMMON-01D
how the chain supplies Block Time	REQ-COMMON-01D
how Authorized Transaction Data is encoded	REQ-COMMON-01F
the native value-transfer path a fee travels over	REQ-COMMON-34B
the unit a fee is denominated in	REQ-COMMON-34B
how a rejected call leaves no value transferred and no state changed	REQ-COMMON-42

REQ-CHAIN-01 (upholds SP-BIND-01): A Chain Profile MUST answer every duty of the table above for exactly one family of Consumer Chains, and MUST leave none of them to an implementation. Necessity: the Canonical Runtime and the Platform Verifier derive the first four independently, so an answer left open is two answers, and they disagree only as a digest the destination rebuilds differently. The Consumer, the Proof Verifier, and the Platform Verifier pass the fee under the last three and the Notary Service receives it, so an answer left open there is a fee one hop cannot pay or a rejection that keeps it.
REQ-CHAIN-02 (upholds SP-REPLAY-01): A Chain Profile MUST state the preimage shape it claims in §2.1, and MUST NOT claim a shape another Chain Profile claims. Necessity: REQ-COMMON-01C supplies no chain-identifier registry and leaves separation to profile authors; two profiles taking one shape give two Consumer Chains one Chain ID, and a digest authorized for either is spendable on both.
REQ-CHAIN-03 (upholds SP-BIND-01): A Chain Profile MUST define one reading by which a composition obtains a destination’s exact 32-byte Chain ID from that destination. Necessity: REQ-COMMON-01C has the composition supply the Chain ID to the Canonical Runtime, and a value derived a second time from an identifier the composition believes the destination has is a guess that fails only after the ceremony completes.

2.1 Claimed preimages

profile	canonical Chain Identifier	canonical bytes
EVM (§3)	the EIP-155 chain identifier	`U256BE`, exactly 32 bytes

Each profile adds its own row. A shape absent from this table is unclaimed.

3. The EVM Chain Profile

An EVM Consumer Chain is one whose execution environment reports an EIP-155 chain identifier, a block timestamp, and an immediate caller to the Consumer.

3.1 Chain ID

chainIdentifier = the EIP-155 chain identifier
canonicalBytes  = U256BE(chainIdentifier)          // exactly 32 bytes
chainId         = keccak256(canonicalBytes)

REQ-CHAIN-04 (upholds SP-BIND-01, SP-REPLAY-01): The canonical Chain Identifier is the EIP-155 chain identifier, and the exact bytes it contributes are that value’s unsigned 256-bit big-endian encoding. The Chain ID is the keccak256 of exactly those 32 bytes. Necessity: EIP-155 identifiers are already unique across the chains that honor them, and a fixed width leaves no encoding a second implementation could choose differently.
REQ-CHAIN-04A (upholds SP-BIND-01): The Platform Verifier MUST take the Chain Identifier from its own execution environment, and its digest recomputation MUST accept none as an argument. Necessity: REQ-COMMON-01C, restated where it is implemented — a recomputation that takes the identifier can be handed another chain’s.
REQ-CHAIN-04B (upholds SP-BIND-01): The reading REQ-CHAIN-03 requires is the Proof Verifier, which MUST expose its Chain ID. Necessity: it is the one component every Consumer on the chain already routes through, so the bytes a composition reads are the bytes that will be recomputed against.

Conformance vectors:

chainIdentifier = 1            chainId = 0xb10e2d527612073b26eecdfd717e6a320cf44b4afac2b0732d9fcbe2b7fa0cf6
chainIdentifier = 8453         chainId = 0x3e30a4f0e31d8ec3b8e98957bc7fedf7f6fb560612e2775c74a396200aa3155b
chainIdentifier = 11155111     chainId = 0x4679aa19497ce87eb9ffd768757c9397680da8c7963db8096790ee03622ae968

3.2 Transaction Author

REQ-CHAIN-05 (upholds SP-BIND-01): The Transaction Author is the account the execution environment reports as the Consumer’s immediate caller. The Consumer MUST authenticate it from that report alone.
REQ-CHAIN-05A (upholds SP-BIND-01): The Consumer MUST NOT read the Transaction Author from the account that originated and pays for the transaction. Necessity: that account is the Transaction Submitter of REQ-COMMON-04, which this profile does not authenticate as the same principal — anything reached through an intermediate would authorize under the submitter’s identity rather than the caller’s.

3.3 Block Time

REQ-CHAIN-06 (upholds SP-FRESH-01): Block Time is the block timestamp the execution environment reports, in whole seconds, bounded by an unsigned 64-bit integer. The Consumer MUST read it from that environment and never from the Submission or the Authorized Transaction Data.

3.4 Authorized Transaction Data

REQ-CHAIN-07 (upholds SP-BIND-01): Authorized Transaction Data is the EVM ABI encoding of the transaction kind’s argument tuple. The Consumer’s protocol fixes that tuple for each transaction kind it accepts, and the Consumer MUST decode with a strict decoder that rejects trailing bytes and any other argument shape (REQ-COMMON-01F).

3.5 Fees and rejection

The native value-transfer path is the call value: the native value a call carries, which the callee reads as msg.value. The Consumer attaches the quoted value to its call to the Proof Verifier, the Proof Verifier attaches exactly that value to its call to the Platform Verifier, and the Platform Verifier attaches one Notary Fee to each Notary Service call. The unit is wei, the smallest unit of the chain’s native asset, and every quotation, Notary Fee, and call value is a count of wei. The Proof Verifier, the Platform Verifier, and the Notary Service each compare the call value they receive with the value they require for exact equality (REQ-COMMON-06D, REQ-COMMON-34E).

Rejection is a revert. A revert undoes every state change and value transfer of the reverting call, including those of the calls it made. The Proof Verifier and the Platform Verifier let the revert of the role they call propagate, so a Submission rejected at any hop reverts the Consumer’s call to the Proof Verifier. A Consumer that lets that revert propagate leaves no fee delivered and no state changed (REQ-COMMON-42).

4. Conformance tests

TEST-CHAIN-01 (exercises REQ-CHAIN-01, REQ-CHAIN-02): Every profile in this document answers every duty of §2, and no two claim one preimage shape in §2.1. Verification: inspection.
TEST-CHAIN-02 (exercises REQ-CHAIN-03, REQ-CHAIN-04, REQ-CHAIN-04B): The §3.1 vectors reproduce, and the Chain ID read from the destination equals the one its digest recomputation commits.
TEST-CHAIN-03 (exercises REQ-CHAIN-04A): The digest recomputation takes no Chain Identifier argument, and moving the chain under an unchanged Submission moves the digest.
TEST-CHAIN-04 (exercises REQ-CHAIN-05, REQ-CHAIN-05A): A Consumer reached through an intermediate account authorizes on that account and rejects a call that only the originating account’s identity would satisfy.
TEST-CHAIN-05 (exercises REQ-CHAIN-07): Authorized Transaction Data carrying trailing bytes past its argument tuple is rejected.