Falcon Signatures in Algorand

May 18, 2026 · Brett · crypto

Post-Quantum Signatures in Algorand

As our devoted readers know, the advent of a Cryptographically Relevant Quantum Computer (CRQC) would allow an attacker with such a machine to run Shor’s Algorithm to break most digital signature schemes including ECDSA (used in Bitcoin, Ethereum, etc) and Ed25519 (used in Solana, Stellar, Algorand, etc.) This is because the security of both these schemes rests on the hardness of the “discrete-log problem,” so an attacker with the CRQC could extract users’ private signing keys from their public keys.

NIST has already standardized two post-quantum signature schemes (ML-DSA and SLH-DSA), and they are edging ever closer to standardizing Falcon as FN-DSA. (DigiCert, one of our leading cultural pioneers, has described FIPS-206 as “most anticipated”.)

Algorand has not waited for FIPS-206, but already integrated Falcon into the Algorand blockchain in two ways, at both the execution layer and the consensus layer.

Falcon in the Consensus Layer

Proof-of-stake blockchains (like Algorand) use signatures heavily at the consensus level. Every block is signed by a committee of validators, and that’s how you know which blocks have been finalized. This means that an attacker with a CRQC could extract the validators’ signing keys, and sign competing blocks — forking the chain. But an attacker could also do this historically (not just prospectively). An attacker with a CRQC could pick a historical block, and create a fork at any block height and then build up a sequence of blocks (all with valid signatures) that tell a completely different history of the transactions that have been processed and thus have a completely different picture of the current account balances on chain.

This is a big problem for new users who connect to the network, because they would have no way of distinguishing between the real history of transactions and the fake history concocted by the quantum attacker. In 2022, Algorand introduced “State Proofs” to combat this type of attack. Even though the Algorand consensus algorithm still uses Ed25519, every 256 rounds (the State Proof Interval) the validators also publish a “state proof” using post-quantum Falcon signatures that anchors the state of the chain. This means that an attacker with a CRQC could not forge the history past the latest state proof.

But this is not the focus of this note. We are focused today on the execution layer, where users’ transactions live.

Falcon in the execution layer

Algorand uses (pre-quantum) Ed25519 signatures at the transaction layer. When you want to send another user ALGO, you sign the transaction with the Ed25519 scheme. This means that an attacker with a CRQC could send tokens on your behalf (i.e., steal your funds). Of course, this is not specific to Algorand, it’s true on pretty much every other chain as well.

To combat this type of attack, Algorand added a falcon_verify opcode, meaning that you can now write on-chain logic that checks for a Falcon signature. You can now create Applications in the Algorand Virtual Machine (AVM) that verify Falcon signatures before taking an action (like transferring tokens), and you can create LogicSigs that serve as simple stateless “gates” around other on-chain actions.

Although the Algorand Documentation says that “Logic Signatures should only be used if absolutely necessary”, the Algorand Falcon Signatures CLI only supports code for creating Falcon “LogicSigs” (not more general AVM Applications).

This is very cool, and since Algorand is a public blockchain, we can see how many people have started using this tooling. To check, we scanned every LogicSig transaction on Algorand from when the falcon_verify opcode was introduced (in September 2025) up through today (May 19, 2026) and counted all the transactions that used the falcon_verify opcode. We did not try to count any “Applications” using the opcode, just the LogicSigs. This seems reasonable though because the Algorand tooling only supports LogicSigs; if you want to use falcon_verify inside an AVM Application, you’ll need to write your own wallet software.

During this time window (about eight months), only 48 accounts used the falcon_verify opcode, and they made a total of 711 post-quantum transactions. One address (SHRTJ7K...ST24U) did use the opcode 82 times though.

The raw data can be found in github.com/bhemen/crypto_insights/algorand-falcon

Post-Quantum wallets on other chains

In principle, you could deploy a post-quantum wallet on any chain that supports smart contracts. But there’s a problem that verifying NIST’s post-quantum signatures is extremely gas intensive. There is an Ethereum Improvement Proposal, EIP-8052, that proposes adding a falcon-verify precompile to Ethereum, but it’s unlikely to be adopted. Even without a precompile, you can implement a Falcon verifier inside an ERC-4337 smart-contract wallet, but the ETHFALCON verification library (intended to be used inside an ERC-4337 wallet) takes millions of gas to verify a Falcon signature (by contrast, ecRecover, the code to validate an ECDSA signature takes 3000 gas).

To get around this, you can avoid NIST’s signatures, and implement the verifier for a one-time signature scheme inside a smart contract. This is what was done with Solana’s Winternitz Vault.

But schemes like this still require you to wrap your spending transaction inside a valid outer transaction (i.e., an ECDSA transaction on Ethereum and an Ed25519 transaction on Solana). So while the funds in your wallet are protected by a post-quantum signature scheme, you still need a pre-quantum signature scheme to pay the gas fees. (In the case of ERC-4337, the user’s UserOperation itself can use any verification scheme, but the bundler that relays it to L1 still signs the outer transaction with ECDSA.)

Algorand’s design eliminates this. If you use Algorand’s LogicSigs to gate access to your funds with a Falcon signature, you do not have to wrap your transaction inside another Ed25519 transaction, so in that way Algorand’s design is actually much closer to a “real” post-quantum solution.

Why Falcon?

Given that NIST has selected three post-quantum signature schemes for standardization, why did Algorand choose Falcon? First, Chris Peikert has been at Algorand since 2021, originally as head of cryptography and then as Chief Scientific Officer at the Algorand Foundation. Peikert is one of the world’s leading experts in lattice-based cryptography, so it would make sense that Algorand would focus on a lattice-based scheme like Falcon. Of course, ML-DSA (FIPS-204) is also lattice-based, so Peikert’s expertise alone doesn’t explain the choice of Falcon over ML-DSA. The deciding factor is signature size.

Second, Falcon has the smallest signatures of the three NIST schemes. A Falcon-1024 signature is about 1,274 bytes on average, compared to 2,420 bytes for the smallest ML-DSA variant and anywhere from 7,856 to 49,856 bytes for SLH-DSA. For reference, an Ed25519 signature is 64 bytes — so even the smallest post-quantum option is a 20× blowup. So even Falcon signatures are enormous by blockchain standards, and this causes problems for Algorand.

Algorand caps each LogicSig at 1,000 bytes — but the cap is pooled across a transaction group, so a group of N transactions has a total LogicSig budget of N × 1,000 bytes. A Falcon LogicSig (the deterministic Falcon-1024 signature plus the 1,793-byte public key plus the verifier program) comes to roughly 3,030 bytes, more than triple the per-transaction allowance. To work around this, the Foundation’s falcon-signatures CLI bundles every Falcon-signed payment with three dummy transactions in the same atomic group, each signed by a no-op LogicSig. The group now has a 4 × 1,000 = 4,000-byte pooled LogicSig budget, comfortably above the ~3,030-byte Falcon LogicSig. So while Algorand’s falcon_verify opcode helps, and Algorand users don’t have to pay gas fees with pre-quantum signatures (like in Ethereum), the sheer size of post-quantum signatures still bleeds into the UX.