docs(specs): the EVM Chain Profile that REQ-COMMON-01C asks for

[xgreenx]

chainId is the one Authorization Digest input the two sides derive
independently: the Platform Verifier from its own execution environment
(REQ-COMMON-01C, ASM-CHAIN-02), and the Canonical Runtime from a 32-byte value
the composition hands it. REQ-COMMON-01C requires a Chain Profile to fix
the exact bytes hashed, and libid.md's ownership table already names one as
the owner of Chain ID / Transaction Author / Block Time / transaction-data
encoding — with no link, because none existed. So a composition had nothing
normative to read, and a wrong guess does not fail loudly: it produces a digest
the destination rebuilds differently, surfacing as CodeVerifierMismatch on X
and GitHub and as a public-input mismatch on Google.

Same shape as the §7 drift fixed in
libid-contracts#24, one
field over.

Shape

specs/chain-profiles.md is a frame with families under it, not an EVM
document with a general title. One REQ-CHAIN- prefix covers every family,
matching ASM-CHAIN- and the way platform-ceremonies.md carries Google, X
and GitHub under one REQ-PLAT-.

§2 — what every profile fixes. The four duties as a table against the
common requirements that impose them, then three rules that hold whatever the
family:

• REQ-CHAIN-01 — a profile answers all four duties for exactly one family
  and leaves none to an implementation. An answer left open is two answers.
• REQ-CHAIN-02 — a profile states the preimage shape it claims in §2.1 and
  may not claim a shape another profile claims. REQ-COMMON-01C supplies no
  registry and leaves separation to profile authors, so the claims are written
  down where the next author will look.
• REQ-CHAIN-03 — a profile defines one reading by which a composition takes
  a destination's exact 32-byte Chain ID from that destination, instead of
  re-deriving it from an identifier it believes that destination has. This is
  the requirement that removes the guess.

§2.1 — claimed preimages. One row per profile. Today: EVM, U256BE of the
EIP-155 identifier.

§3 — the EVM Chain Profile, answering §2 rather than restating it:
chainId = keccak256(U256BE(eip155ChainId)) with vectors for 1, 8453 and
11155111; the recomputation takes no identifier argument (REQ-CHAIN-04A);
the REQ-CHAIN-03 reading is the Proof Verifier, which must expose its Chain ID
(REQ-CHAIN-04B — the reading already exists on chain, nothing required its
use); Transaction Author is the immediate caller and never the fee-paying
originator; Block Time is the block timestamp; Authorized Transaction Data is
the ABI encoding of each transaction kind's argument tuple, with the Consumer's
protocol fixing the tuple.

A family that identifies, authenticates or encodes differently — Solana, Move —
takes a section beside §3 and a row in §2.1. Nothing in §2 assumes an EVM.

§4 — TEST-CHAIN-01…05. TEST-CHAIN-01 is the inspection that keeps §2.1
honest; TEST-CHAIN-02 and -03 are pinned in libid-contracts by
libid-contracts#25.

The choice worth reviewing

The alternative for §3.1 was a namespaced identifier —
keccak256(UTF8("eip155:1")), CAIP-2 style — self-separating, and it would
make REQ-CHAIN-02 unnecessary for this profile. I did not take it: common §2
says the identifier "takes whatever form the chain gives it — a number, a
string, or a hash", and EVM gives a number; the bare integer is what the
on-chain recomputation already commits, so writing it down costs no change to a
construction that was just corrected. Switching is cheap in this document and
expensive everywhere else — it moves every digest and reopens the contracts.