Technical contributions: Giulio Pizzini, Cosimo Bassi, and Steve Ferrigno
Introduction
Algorand has executed the first post-quantum transaction on its mainnet using NIST-selected Falcon signatures. This transaction demonstrates that quantum-resistant signatures can now protect real digital assets on a live public blockchain today.
When Peter Shor introduced quantum algorithms for factoring and discrete logarithms in 1994, he proved that scalable quantum computers would break RSA and elliptic-curve cryptography. Three decades later, the debate has shifted from "if" to "when." While some researchers argue practical quantum hardware remains decades away, others, including Ethereum co-founder Vitalik Buterin, point to forecasts suggesting a 20% probability of cryptographically relevant quantum computers before 2030. While the timeline remains uncertain, the implication is clear: every system relying on classical public-key cryptography must adopt a post-quantum strategy well before quantum attacks become feasible.
Recently, Algorand demonstrated that post-quantum security is no longer theoretical. The protocol team at Algorand Foundation executed the first post-quantum transaction on Algorand using the Falcon signature scheme on the mainnet network. This transaction, secured by Falcon, a NIST-selected lattice-based signature scheme, shows that quantum-resistant signatures can protect real digital assets on a live public blockchain. While many teams are still outlining post-quantum roadmaps, Algorand has deployed working code, live infrastructure, and developer tooling that supports experimentation today.
The quantum threat to blockchains is particularly acute. Every transaction, validator message, and consensus vote depends on public-key signatures that Shor’s algorithm can break. A quantum-capable adversary could forge blocks, steal funds, or rewrite transaction histories. Even if large-scale quantum computers remain years away, the “harvest now, decrypt later” problem means any data signed with pre-quantum schemes today could be compromised once those machines exist. For systems designed to operate securely for decades, preparing now is an engineering requirement, not paranoia. Algorand’s ledger is already quantum-secure due to the use of Falcon-1024 signatures to generate state proofs every 256 rounds, but the ledger is only part of the post-quantum picture.
Implementing post-quantum cryptography in production introduces significant technical challenges. Falcon signatures are significantly larger than Ed25519 signatures–approximately 10x larger than Ed25519’s 64-byte signatures. These larger primitives affect message propagation, storage requirements, and verification costs. Algorand’s approach, described in detail later in this article, uses its Logic Signature feature to embed Falcon public keys in stateless smart contracts that verify signatures over transaction IDs. These contracts are compiled to standard Algorand addresses, allowing users to fund and interact with them like any other account. Combined with command-line tools for key generation, address derivation, and transaction signing, this forms a complete developer workflow for post-quantum experimentation.
This article examines how Algorand crafted its first post-quantum transaction, the technical architecture that made it possible, and what developers can do with these tools today. We’ll explore Falcon’s cryptographic design, the logic signature verification flow, performance considerations, and the broader implications for blockchain security as quantum computing advances.
Falcon overview: A NIST-selected post-quantum signature
The Falcon implementation is based on the pioneering GPV work by Craig Gentry (former Algorand Foundation Research Fellow), Chris Peikert (Head of Cryptography at Algorand Technologies), and Vinod Vaikuntanathan (MIT professor and Scientific Advisor to Algorand). Dr. Zhenfei Zhang from Algorand, working with collaborators, contributed to the Falcon proposal that was ultimately selected as one of the NIST-endorsed digital signature algorithms.
Falcon is a lattice-based digital signature scheme selected by NIST in 2022 for standardization under the names Falcon-512 and Falcon-1024. It relies on the structure of NTRU lattice, which provides strong resistance to quantum attacks while maintaining compact signatures and fast verification. Falcon’s design goal is to achieve security comparable to RSA-3072 or Ed25519, but with quantum-resistant foundations suitable for deployment in bandwidth-and latency-sensitive environments such as blockchain systems.
Design tradeoffs
Falcon's signing process relies on floating-point arithmetic and fast Fourier sampling, making it more complex to implement correctly compared to schemes such as Dilithium, which use purely integer operations. These numerical precision requirements mean that implementations must handle rounding and sampling carefully to avoid subtle security issues. The NIST reference implementation and optimized libraries, such as PQClean and liboqs, use double-precision floating-point operations with deterministic rounding to ensure reproducibility across platforms.
For practical parameters, a Falcon-1024 signature is ~1280 bytes, and the public key is ~1793 bytes. While signing is computationally intensive due to the Gaussian sampling step, verification uses only integer arithmetic and is exceptionally fast—typically under 100 microseconds on modern CPUs. This asymmetry between complex signing and fast verification makes Falcon particularly well-suited for blockchain protocols, where verification is performed far more frequently than signing. Combined with its compact size, these characteristics position Falcon as an attractive choice for bandwidth and performance-sensitive applications.
Standardization and security level
NIST selected Falcon as part of its Post-Quantum Cryptography Round 3 process. It provides a security level roughly equivalent to AES-128 for Falcon-512 and AES-192 for Falcon-1024 (NIST Level 5). A solid mathematical foundation and several years of cryptanalytic review back the algorithm. The current Falcon ecosystem includes deterministic and randomized modes for signing, along with guidance for constant-time implementation to reduce timing side channels.
NIST’s decision to include Falcon alongside Dilithium reflects a deliberate balance between performance and implementability. Dilithium favors more straightforward integer arithmetic and ease of integration, while Falcon minimizes bandwidth and verification cost. In practice, this tradeoff makes Falcon particularly attractive for applications where signature size and verification speed directly affect protocol throughput, such as Algorand’s state proofs and transaction verification.
Why Falcon fits Algorand’s design
Algorand’s protocol places tight performance requirements on signature verification. Each block includes multiple validation layers, and thousands of signatures may be verified per second across the network. Falcon’s compact signature size and high verification speed align closely with these requirements. Unlike larger hash-based or code-based schemes, Falcon allows Algorand to integrate post-quantum signatures without inflating block sizes or breaking consensus timing assumptions.
Algorand already uses Falcon within its state proof mechanism, where compact, aggregatable proofs allow external chains to verify Algorand state without trusting intermediaries. The same characteristics that make Falcon effective for state proofs, such as small signatures, fast verification, and deterministic arithmetic, also make it a natural choice for general-purpose transaction signing. By extending the existing Falcon integration from state proofs to transactions, Algorand achieves continuity in both cryptographic implementation and developer tooling. It is important to note, however, that while Falcon is a promising cryptographic solution for post-quantum readiness, it is still experimental and brings additional challenges in implementing it to secure other protocol elements, such as accounts and the consensus layer.
Falcon implementation in Algorand
Algorand ships a production-grade Falcon implementation with a deterministic signing mode and constant‑time coding practices. The implementation credits include Thomas Pornin for the core C code and David Lazar and Chris Peikert for the design and implementation of the deterministic mode. This codebase underpins both state proofs and the post‑quantum transaction demo described later in this article.
Goals and constraints
The integration targets three objectives:
- Minimal consensus impact. Keep verification deterministic and bounded so block times and committee selection stay within existing timing budgets. Algorand nodes already partition cryptographic work into dedicated pools for verification, which simplifies adding a new primitive.
- Protocol‑compatible authorization. Reuse Algorand’s stateless authorization path so PQ accounts behave like normal accounts from the network’s point of view. Logic signature execution is already the standard stateless gate for transaction approval.
- Operational practicality. Provide tooling for key generation, address derivation, signing, and TX submission, and ensure sizes and costs fit within logic signature limits.
On‑chain verification primitive: falcon_verify
FALCON verification is exposed to the Algorand Virtual Machine as a native opcode, falcon_verify. In TEAL or higher‑level languages that compile to TEAL, the opcode takes (data, signature, public_key) and returns a boolean. The signature format is the compressed Falcon encoding. This opcode is available in AVM v12 and can be used in both stateless and stateful programs.
Logic signatures and smart contracts run under explicit opcode budgets; stateless programs have a total cost ceiling, which constrains cryptographic workloads attached to a transaction. This budgeting model is important for keeping block validation predictable at scale.
Stateless authorization with logic signatures
Algorand uses logic signatures to authorize transactions without coupling to a specific signature scheme. A compiled logic signature program corresponds to a canonical Algorand address (contract account mode). Funding that address turns it into a spendable account, and any spend must satisfy the program. This is the mechanism Algorand uses to host Falcon public keys and enforce Falcon signatures over the transaction ID.
At validation time, the node evaluates the logic signature. If the program completes with a non‑zero value on the stack, the transaction is authorized. This applies uniformly in stateless mode, so Falcon‑secured spends go through the same pipeline as classical transactions.
What the program verifies
The logic signature verifies a Falcon signature against the transaction ID. In Algorand, Hash(Tx) is the canonical hash of the transaction fields encoded using canonical MsgPack. The logic signature computes or receives this digest, then calls falcon_verify(Hash(Tx), sig, pk) to gate authorization. The result is a cryptographic check that binds the spend to an exact, canonical transaction encoding.
Address derivation and "off-curve" safety
To avoid any accidental overlap with Ed25519 account space, the tooling derives a Falcon‑controlled address by compiling the logic signature and then deterministically tweaking a small counter until the program’s address is an off‑curve point. This ensures there is no corresponding classical private key that could authorize spends for that address through the legacy path. The result is a clean separation between post-quantum accounts and classical accounts while preserving a standard address format.
Performance and cost
Falcon verification is designed to be fast enough for high‑throughput systems. While the opcode cost value is implementation‑defined, the logic signature total budget ensures that a program using falcon_verify plus standard checks fits within per‑transaction constraints. This keeps block assembly and validation predictable for relays and validators. For comparison, the platform documents the high cost of cryptographic opcodes such as ed25519verify and enforces the same budgeting model for all cryptographic checks.
Use in state proofs
Algorand already uses Falcon to sign state proofs, which provide a succinct, verifiable commitment to block history for light clients and other chains. The same deterministic Falcon code and compressed signature handling apply there, which reduces the number of moving parts developers need to learn.
Security and interoperability
Scopes and limits. Falcon‑secured accounts protect against spends by PQ‑capable adversaries, but they do not upgrade consensus; that remains a separate workstream. In other words, while a quantum computer today could attack and disrupt consensus, it could not produce valid signatures to spend funds (or sign any other type of transaction) from a Falcon-secured account.
Provable misbehavior. Any unauthorized signature that verifies under a Falcon public key yields a self‑contained, third‑party‑verifiable proof (public key, message, signature). With deterministic signing and a fixed salt version, conflicting signatures for the same message or with a disallowed salt are clear evidence of rule violations by the signer or of key compromise. This enables straightforward forensics and downstream policy (e.g., alerting and key rotation).
Using the Falcon signatures CLI to create a post-quantum transaction
Our protocol team built the Falcon Signatures CLI so developers can experiment with Falcon signatures on Algorand. The toolchain gives you a complete path from key generation to on‑chain spend and works against public endpoints on mainnet, testnet, and betanet.
At a high level, the CLI models a post‑quantum account as a stateless logic signature that holds a Falcon public key and verifies a Falcon signature over the transaction ID. You generate a Falcon keypair, derive a standard Algorand address from the public key, fund it with any wallet, and then send transactions that the logic sig authorizes using your Falcon signature. This turns post-quantum signatures into a repeatable workflow you can run end‑to‑end on Algorand.
The CLI includes general cryptographic utilities and Algorand‑specific commands. You can create keys (random with a 24‑word mnemonic and optional passphrase, random without a mnemonic and higher entropy, or deterministically from a seed), inspect them, sign messages, and verify signatures. For on‑chain use, falcon algorand address derives the address, and falcon algorand send constructs, signs, and submits transactions from that address.
We will use the CLI in the following walkthrough to create a Falcon key, derive the Algorand address, fund the address, and then finally post a Falcon-signed transaction to the Algorand testnet.
1. Generate Falcon key
The falcon create command generates a new Falcon-1024 keypair with several different options:
- Randomly generate a 24-word BIP-39 mnemonic seed and derive the keypair from it, which provides 256 bits of entropy.
- Randomly generate a new keypair without mnemonic with 384 bits of entropy (using --no-mnemonic).
- Deterministically derive a keypair from a seed passphrase (using --seed), with entropy based on the strength of your passphrase.
In this case, we will use the default option:
This generates a new Falcon-1024 keypair to the falcon_keys.json file, shown below in truncated form:
2. Derive Algorand address
The falcon algorand address command generates an Algorand address controlled by a Falcon public key, with an optional mnemonic passphrase. The counter rejection loop ensures that the resulting logic signature address isn’t a valid Ed25519 key so that no traditional keypair can authorize the account.
Now we will derive an address using the keypair we generated in the previous step:
Which generates the following address:
3. Funding the account
Now that we have an address derived from our Falcon-1024 keypair, we need to fund the account, which we will do by using the Testnet dispenser available in Lora:
4. Spend from our PQ Falcon-controlled account
Finally, we will use the falcon algorand send command to send Algos from our Falcon-controlled account.
This command triggers the following actions:
- Derives a post-quantum logic signature account from the Falcon public key.
- Embeds the key and a one-byte counter into a precompiled TEAL program that invokes falcon_verify on the transaction ID.
- Builds the payment transaction, setting the logic signature address as the sender, the receiver address, amount, optional note, and the close-to address, which is left empty.
If successful, the falcon algorand send command will return the transaction ID:
Using Lora, we can confirm the successful transaction on Testnet and see the compiled logic signature:
This walkthrough demonstrates that post-quantum cryptography on Algorand is not simply a thought exercise in an aspirational post-quantum strategy but a real-world implementation. Developers can create and transact from quantum-secure accounts today. By generating a Falcon-1024 keypair, deriving an Algorand address controlled by post-quantum signatures, and successfully executing an on-chain transaction, we've shown the complete lifecycle of a quantum-resistant account. The Falcon Signatures CLI abstracts the complexity of integrating NIST-standardized lattice cryptography into practical tooling that developers can use and experiment with immediately. While this implementation uses logic signatures as a bridge to quantum security rather than modifying the core protocol, it proves that blockchain systems can begin their transition to post-quantum security now, without waiting for consensus-level changes.
Impact, limitations, and the path forward
While Algorand's implementation of Falcon signatures marks a significant milestone in blockchain quantum resistance, understanding the current scope, limitations, and future trajectory is crucial for evaluating both immediate capabilities and long-term potential.
Current protection landscape
Today's implementation protects individual user accounts through logic signatures that verify Falcon signatures over transaction IDs, allowing users to create quantum-resistant accounts without protocol modifications. It’s not meant to be the ultimate solution for creating and using post-quantum accounts, but to provide a tool for developers to experiment with post-quantum cryptography on Algorand. Additionally, Algorand's state proofs employ Falcon signatures to provide quantum-secure attestations of blockchain state, compressing 256 rounds of block headers into certificates that enable trustless verification by external chains and light clients. This secures the historical integrity of the chain against future quantum attacks.
However, critical components remain quantum-vulnerable. The consensus mechanism relies on classical Ed25519 signatures for block proposals and committee voting. Verifiable Random Functions (VRFs) for sortition-based committee selection use pre-quantum cryptography vulnerable to Shor's algorithm (specifically, committee membership could be predicted in advance by a quantum attack). While individual accounts and historical state achieve quantum security, the consensus layer itself remains exposed to future quantum threats.
Performance trade-offs
The transition to post-quantum cryptography carries non-trivial costs. Falcon signatures are significantly larger than Ed25519 signatures, though they do have the benefit of remaining a relatively constant size (1-2 KB) regardless of the size of data being signed. While Falcon verification remains relatively fast, the opcode budget constraints in logic signatures make complex multi-signature schemes more expensive. These trade-offs explain why wholesale cryptographic replacement isn't immediately feasible, necessitating the hybrid approach we have demonstrated here.
Near-term applications
This foundation enables practical quantum-secure applications today. Wallet developers can integrate Falcon key generation and signing, offering users quantum-resistant accounts alongside traditional ones. Multi-signature schemes can adapt to use Falcon signatures for quantum-secure treasury management through the use of a smart contract-based multi-sig solution.
Protocol evolution roadmap
Securing the consensus layer requires deeper protocol changes. Developing quantum-resistant VRFs for committee selection presents a challenging research problem requiring both randomness and efficiency. The protocol team's incremental approach in securing user accounts and state proofs first provides operational experience crucial for eventual consensus-layer migration.
Ecosystem impact and standardization
Algorand's adoption of NIST-standardized Falcon positions it at the forefront of cross-chain post-quantum interoperability. As other blockchains implement quantum resistance, Falcon provides a common foundation for secure cross-chain communication. State proofs already demonstrate this potential, enabling external chains to verify Algorand state with quantum resistance.
The open-source Falcon Signatures CLI serves as both a practical tool and educational resource. Researchers can reproduce the first post-quantum transaction, study implementation details, and experiment with modifications. By providing working code rather than theoretical proposals, Algorand accelerates the field's understanding of practical post-quantum blockchain deployments.
Credits and acknowledgments
This achievement reflects years of dedicated work by Algorand's cryptography and engineering teams. Special recognition goes to Dr. Zhenfei Zhang and collaborators who contributed to Falcon's NIST submission, Chris Peikert (Head of Cryptography at Algorand Technologies), and the team who implemented the deterministic Falcon variant. Their work transforms post-quantum security from academic theory into production reality.
Additionally, we’d like to highlight the efforts of Algorand Technologies and John Jannotti in making Falcon signature verification available in the Algorand Virtual Machine, and our protocol team here at Algorand Foundation – Giulio Pizzini, Cosimo Bassi, and Steve Ferrigno – for building this incredibly valuable tool for developers, cryptographers, and researchers.
Next steps
By embedding Falcon public keys in stateless smart contracts that verify signatures over transaction IDs, Algorand enables quantum-secure accounts without modifying core protocol code. The Falcon signatures fit within logic signature size limits and verification completes in under 200 microseconds despite the lattice-based mathematics underlying the security model. State proofs already use this exact Falcon implementation to create quantum-resistant attestations of blockchain state every 256 blocks.
This marks a shift from theory to practice. While researchers debate whether quantum computers capable of breaking RSA-2048 will arrive in 2030 or 2040, Algorand provides tools to protect against that threat now. Developers can generate Falcon keypairs, derive quantum-secure addresses, and execute transactions using the open-source CLI.
To learn more:
Algorand Specs: Deep-dive into the Algorand protocol, including the Falcon implementation.
Falcon Signatures CLI: Download and experiment with Falcon signatures on Algorand.
Follow us and reach out: