Falcon-512

Falcon-512 is a digital signature scheme built on NTRU lattices, one of the schemes selected by NIST for post-quantum standardization and the basis of the FN-DSA draft standard. Its security does not rest on the elliptic-curve discrete logarithm problem, so Shor's algorithm, the quantum attack that breaks that problem, does not apply to it. Among post-quantum schemes it is notable for compact signatures and fast verification. Signatures are compressed, so their exact length varies slightly from one signature to the next.

On chain 2800, Falcon-512 plays three distinct roles, and the distinction matters.

First, as a precompile: Falcon-512 verification has been callable from any contract since block 9,189,161, as one of five post-quantum precompiles at addresses 0x0AE1 through 0x0AE5, validated against NIST test vectors on-chain.

Second, in 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 Falcon-512 signatures (with SLH-DSA-SHA2-128s seals alongside since 2026-09-04) from the validators over the parent block, and a 32-byte digest of that certificate sits inside the data covered by the block hash. The enforced threshold today is at least 7 signatures 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); in practice certificates carry 8 to 10. The validators' Falcon-512 public keys are bound on-chain in a 10-entry (9-entry until 2026-09-11) signer registry held by an immutable contract whose storage holds the registry's keccak hash.

Third, on consensus messages: since 2026-09-11 every validator refuses a commit message that does not carry a valid Falcon-512 seal, and nine of the ten refuse any consensus message without one (the tenth runs the independent second client, which extends that to proposal, prepare and round-change messages since block 24,300,000 (AIP-22 stage 4, 2026-10-25)). The anchor certificates are assembled from these seals.

Equally important is what Falcon-512 does not do today: it does not authenticate the transport between nodes, which still uses classical secp256k1 keys, and a commit still carries the ECDSA commit seal of its validator as an additional check. Since block 24,300,000 (AIP-22 stage 4) every validator under QBFT attributes a consensus vote only through its verified Falcon-512 seal and a block is post-quantum final once the certificate of the next anchor covers it (see finality), and since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA commit seals: each carries the Falcon-512 seal of its proposer instead. The anchor gives block history a signature layer designed to withstand quantum attack; it does not make the consensus itself post-quantum, and the chain does not claim that it does.