Seal Certificate
A bundle of post-quantum validator signatures (Falcon-512, and SLH-DSA since 2026-09-04) over a block, with a 32-byte digest sealed under the block hash on every 32nd header of chain 2800.
A seal certificate is a package of signatures in which several validators independently attest to the same block. One signature proves that one machine endorsed the block; a certificate proves that a defined minimum of the validator set did. What makes a certificate useful is not the signatures alone but how it is bound to the chain: a 32-byte digest of it is sealed under the block hash, so a certificate detached or swapped no longer matches that digest and the anchor fails validation; the block hash itself does not change (corrected 2026-10-27: this sentence implied that detaching or swapping the certificate would change the block hash).
On chain 2800, the seal certificate is the carrier of the post-quantum anchor. Since block 13,014,000, every anchor block header (every 32nd block; every 128th from 17,225,968 to 20,746,736) carries a 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. The certificate travels in the header, and a 32-byte digest of it sits inside the data covered by the block hash. Change or remove one signature and the certificate no longer matches the digest sealed under the hash, so the header fails validation.
The rule enforced today requires at least 7 signatures of each required scheme per anchor block, as many as the quorum of the ten validators (3 from 2026-08-14, 6 from 2026-08-21, 7 since 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), drawn from the 10 entries (9 until 2026-09-11) of the on-chain signer registry; in practice certificates carry 8 to 10. The certificate is an attestation layer, not the consensus itself: finality on chain 2800 is decided under QBFT by votes, each of which counts, since block 24,300,000 (AIP-22 stage 4), only with the verified post-quantum seal of its author (a commit still carrying the ECDSA commit seal of its validator as an additional check); since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals, which AERE calls post-quantum consensus, with three limits: 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 certificate records, in a signature family designed to resist quantum attack, which validators stood behind each anchored block.
Verify it yourself
Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xC693F0", false],"id":1} to https://rpc.aere.network. Height 0xC693F0 is block 13,014,000, an anchor height: the returned extraData decodes to the Falcon-512 certificate, and its first 32-byte field is the digest covered by the block hash. A non-anchor header nearby decodes to a plain vanity string instead.