From block 17,047,600 an anchor certificate carries two different post-quantum signature families at once: Falcon-512, which is lattice-based, and SLH-DSA-SHA2-128s, which is hash-based.
Why two
The two families rest on different mathematics. If lattice assumptions fall, the hash-based half still holds. If something is found in the hash-based construction, the lattice half still holds. A single family is a single point of cryptanalytic failure, and the whole point of the anchor is to be the part of the chain that survives.
This was only affordable because the certificate is periodic. Hash-based signatures are large, and carrying one in every block would have grown the headers faster than a node can keep. Once the anchor became every 32nd and then every 128th block, both families fit; since block 20,746,736 Falcon-512 is back at every 32nd block and SLH-DSA-SHA2-128s is carried at every 128th.
The format
| v1 | v2 | |
|---|---|---|
| From block | 13,014,000 | 17,047,600 |
| Domain | AERE-PQ-ANCHOR-1 | AERE-PQ-ANCHOR-2 |
| Encoding | list of [index, falconSignature] | RLP[2, [[scheme, index, signature], …]] |
| Schemes | Falcon-512 only | 1 = Falcon-512, 2 = SLH-DSA-SHA2-128s |
The v2 digest is keccak256(RLP[domain, chainId, parentNumber, parentHash, BYTES(rlp(certificate))]).
A third format, v3 (AIP-22 stage R), carries the consensus round as well: RLP[3, round, [[scheme, index, signature], ...]], with seals over the round-bound commit message, so each seal is bound to the round in which its validator committed the block (the response to the AIP-22 erratum of 2026-10-01). It ships in the published node package (patch 0010), is live on the public testnet 28001 from block 6,157,024, and on chain 2800 its height is not set: there, v2 is the format in force (checked on 2026-10-15 on the newest anchor, which carried a v2 certificate).
The rules that make it a hybrid rather than a mixture
Three, and they are enforced, not conventions.
- The scheme schedule names which schemes are required at a given height, so a node cannot
quietly drop one.
- The minimum seal count applies to each scheme separately: at a height that requires both,
seven Falcon seals and one SLH-DSA seal is not a valid certificate (the minimum is seven of ten per scheme since block 20,715,632).
- Every SLH-DSA seal must sit at an index that also carries a valid Falcon seal from the same
validator. Measured over 400 consecutive anchors.
What it costs
A hash-based signature is large and slow to produce, and the hybrid format pays for both:
- Header size: every SLH-DSA-SHA2-128s signature is 7,856 bytes (FIPS 205), so an anchor header
grows by tens of kilobytes. Only anchors carry the certificate, so the cost is paid once per anchor interval, not on every block.
- Signing time: SLH-DSA performs millions of short hashes, so its cost is dominated by the hash
implementation rather than by the signature scheme. A hardware-accelerated SHA-256 signs several times faster than a pure-software one and produces byte-identical signatures, which is checked by cross-verification in both directions.
The rule we apply before adding any primitive to a consensus path: measure its cost on the target machine with the target implementation, and when a primitive looks inexplicably expensive, look at what it hashes rather than what it signs.