Signer Registry

A signer registry answers a question that signature verification alone cannot: not "did some key sign this?" but "did the right key sign this?". A signature proves possession of a private key; only a registry, a published binding between each validator and its public key, turns that into proof that a specific validator signed. Without one, a certificate of post-quantum signatures floats free, because anyone can generate keys and sign anything.

On chain 2800 the registry has ten entries since 2026-09-11 (nine before it, seven at first), one per validator, each binding a validator address to its Falcon-512 public key; since block 20,836,228 the epoch in force names the validators by post-quantum ids and carries the same ten keys. The epochs up to the ten-entry one bound from block 18,082,816 are committed on chain: an immutable contract holds, in its storage, the keccak hash of the full registry contents. Immutable means what it says: the contract has no update path, so the commitment cannot be quietly replaced. The epoch in force since block 20,836,228, which names the validators by post-quantum ids and carries the same ten keys, is not in that contract: it is pinned by its hash in the node configuration, and the published verifier checks it in full, which is the residual point to watch. Changing the bound set means publishing a new commitment, in the open, where anyone can see the change.

The registry is what the post-quantum anchor checks against. Since block 13,014,000, every anchor block header (every 32nd block; every 128th from 17,225,968 to 20,746,736) carries a seal certificate of post-quantum signatures (Falcon-512 at every anchor and, since 2026-09-04, SLH-DSA-SHA2-128s as a second, hash-based scheme, every 128th block since 2026-09-29) from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. A signature counts toward the certificate only if its key appears in the registry. The threshold enforced today is at least 7 signatures for each scheme per anchor block, as many as the quorum of the ten validators (3 until 2026-08-21, 6 until block 20,715,632 on 2026-09-29; below block 24,148,752 the seals proved those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01, and from that block a certificate that carries the quorum of one round proves the decision); in practice certificates carry seals from 8 to 10 validators.

Its boundaries, stated plainly: the votes behind finality count only through post-quantum seals checked against these keys since block 24,300,000 (AIP-22 stage 4, below), a commit still carrying the ECDSA commit seal of its validator as an additional check; the transport between nodes is still authenticated by secp256k1, the ten validators are run by one operator, and no third party has audited it yet. The registry serves more than the anchor: since 2026-09-11 every validator refuses a commit message without a post-quantum seal checked against these keys, and since block 20,836,228 consensus names the validators by the registry's post-quantum ids. Since block 24,300,000 (AIP-22 stage 4) the votes of the commit quorum count only through their post-quantum seals checked against these keys; since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals, and the Falcon-512 seal of each proposer in a header is checked against these keys too.