Post-Quantum Accounts

Algorand supports post-quantum accounts secured by Falcon-1024 signatures, a lattice-based signature scheme designed to resist attacks from quantum computers. Post-quantum accounts work alongside existing Ed25519 accounts. They hold Algos and assets, send transactions, and interact with applications like any other account, but their transactions are authorized by a quantum-resistant signature instead of an elliptic-curve one.

This page explains how post-quantum accounts work at the protocol level: the signature envelope, address derivation, key generation, fees, and how existing accounts can migrate.

Note

Post-quantum signatures are part of the v42 consensus upgrade, shipped in algod v5.0.0. All statements on this page describe behavior after the upgrade takes effect on a given network. Until then, the network rejects post-quantum signatures.

Why Post-Quantum Signatures

Every Algorand account that is controlled by a key, rather than by smart-contract or logic-signature code, uses an Ed25519 key pair. Ed25519 is an elliptic-curve scheme, and a sufficiently large quantum computer running Shor’s algorithm could break it. No such computer is known to exist today, but assets secured on a blockchain need to remain secure for decades, and an attacker can record public keys now and attack them later.

Falcon-1024 is based on lattice problems that are believed to resist quantum attack. Falcon was selected by the National Institute of Standards and Technology (NIST) for standardization in 2022, and a derived scheme, FN-DSA, is being standardized in FIPS 206, which is in draft at the time of writing. Algorand uses a deterministic variant of Falcon, which differs from the draft FN-DSA. By supporting it natively in the protocol, Algorand lets any account holder move to quantum-resistant security without waiting for a network-wide migration.

The pqsig Signature Category

A signed Algorand transaction carries exactly one of four signature categories:

Category	Field	Authorized by
Standard	sig	A single Ed25519 signature
Multisig	msig	A threshold of Ed25519 signatures
LogicSig	lsig	A TEAL program (optionally delegated)
Post-quantum	pqsig	A post-quantum signature

The pqsig field is a scheme-agnostic envelope with four parts:

• sch: the signature scheme identifier. f1 is Falcon-1024, the only scheme currently enabled. (f5 is reserved for Falcon-512, which is defined but not enabled.)
• slt: a one-byte salt used in address derivation (see below).
• pk: the post-quantum public key.
• sig: the signature itself.

The envelope is deliberately generic: the protocol maintains a registry of schemes, each individually gated by consensus parameters with its own fee contribution. This gives Algorand cryptographic agility: future schemes can be added, and a scheme that is ever weakened can be retired, without redesigning the transaction format.

Addresses

A post-quantum address is derived by hashing the scheme identifier, the salt byte, and the public key:

address = SHA512-256("PQA" || scheme || salt || public key)

The result is encoded with a checksum into the same 58-character format as every other Algorand address. On-chain, a post-quantum address is indistinguishable from any other address; it acquires meaning only when a transaction proves ownership with a matching pqsig.

The hash serves two purposes. First, an Ed25519 address can directly encode its 32-byte public key, but a Falcon-1024 public key is about 1.8 KB, so it must be hashed down to fit the 32-byte address format. Second, hashing with a salt maintains domain separation between signature schemes: a post-quantum address is never a valid Ed25519 public key, regardless of a scheme’s key size. The next section explains why this matters.

The Salt Byte

The one-byte salt exists so that key generation can search for an address that is not a valid point on the Ed25519 curve. A quantum computer can recover the private key behind any Ed25519 public key, so if a post-quantum address were also a valid Ed25519 public key, a quantum attacker could compute the matching private key and spend from the account with an ordinary sig. Because an off-curve address can never be claimed by any Ed25519 key pair, this attack is ruled out entirely.

Two subtleties are worth understanding:

• The canonical salt is a tooling convention, not a consensus rule. The protocol verifies a pqsig for any salt value, so a single Falcon key pair can control up to 256 distinct addresses. Algorand tooling always uses the lowest salt that produces an off-curve address (the canonical salt), and you should too, but do not build systems that assume one public key maps to only one address.
• The off-curve check happens at the node’s REST boundary, not in consensus. When you submit a transaction, algod rejects post-quantum addresses that are on-curve as a safety measure. This check can be bypassed with the skip-pq-address-check query parameter on the transaction submission endpoints. Consensus itself accepts any salt.

Hash-Derived Addresses

Most Algorand addresses encode an Ed25519 public key: the 58-character string is the 32-byte key plus a 4-byte checksum. However, application accounts, logic signature contract accounts, multisig accounts, and post-quantum accounts all derive their address by hashing something else, such as an application ID, a compiled program, a set of signer keys, or a Falcon public key respectively.

A hash output is just 32 bytes, and about half of all 32-byte values happen to decode as a valid point on the Ed25519 curve, purely by chance. When a hash-derived address lands on the curve, those same bytes can also be read as an Ed25519 public key, and the reasoning from The Salt Byte applies again: a quantum attacker who recovered the matching private key could authorize transactions from that address with an ordinary sig, bypassing whatever was supposed to control it, whether that is a smart contract, a TEAL program, or a signing threshold.

An address that is not a curve point is called post-quantum (PQ) compliant, meaning no Ed25519 key pair can ever claim it.

Note

This property is not new in the v42 upgrade. It has held for application and contract accounts for as long as they have existed. What v42 adds is a name for the property, a tool to test it, and an automatic fix for some of these address types.

Address type	Derived by hashing	PQ compliant by construction?
Post-quantum account	scheme, salt, Falcon public key	Yes — the salt is searched
LogicSig contract	the compiled program	Yes, when the assembler salts it
Multisig account	version, threshold, signer keys	No
Application account	the application ID	No, and nothing checks it for you

Application Accounts

Every application has an account, and its address is derived from the application ID:

address = SHA512-256("appID" || application ID)

The application ID is assigned by the network at creation time, from a global transaction counter. You cannot choose it, predict it reliably, or search for a favorable one, and there is no way for a program to test its own address and abort. About half of all applications therefore have an application address that is a point on the Ed25519 curve.

Unlike post-quantum addresses and TEAL v13+ contract accounts, nothing warns you about this. There is no consensus rule and no check at the node’s REST boundary that inspects an application address. An application whose address is on-curve deploys, funds, and operates exactly like one whose address is not.

The exposure is not limited to the application’s balance. An address that is a curve point is one whose signing rights could be forged under a quantum attack, so anything the application address is trusted to do could be done by someone else: spending its Algos and assets, and exercising any asset role, allowlist membership, or authorized-sender check that names it.

This is not an imminent threat. Forging those rights requires a large-scale quantum computer, and none is known to exist. It is worth knowing about now because an application address is public from the moment of deployment, and an application deployed today may still hold value and authority when that picture changes.

Checking an Application Address

algokey pq check-address tests any Algorand address, not only post-quantum ones:

$ algokey pq check-address \
    EGGRNA45S7W3FCDQOEX7H64KCECFHIBWO5MB6B724NVPFQNOFPQQLDF3RY
address EGGRNA45S7W3FCDQOEX7H64KCECFHIBWO5MB6B724NVPFQNOFPQQLDF3RY is PQ compliant

Pass your application’s address to see whether it is PQ compliant.

What to Do About It

For new applications, treat the check as a deployment step. Deploy, check the resulting application address, and if it is not PQ compliant, delete the application and deploy again. Each attempt is an independent coin flip, so a favorable address usually arrives within a few tries. This depends on the application being deletable, so decide that before you deploy, not after. An application can only be deleted if its approval program approves a DeleteApplication call. If it rejects delete but permits update, you can first update it to a program that allows deletion and then delete it. An application whose program rejects both can never be deleted by anyone, including its creator.

Caution

Deleting an application does not return the funds in its account. If the application account holds Algos or assets, move them out first, and remember that minimum balance locked by boxes is not recoverable after deletion.

For applications already deployed, the recommendation is to wait. More robust handling of this case may be addressed at the protocol level, and redeploying in the meantime is expensive: the application ID changes, which breaks frontends, published app specifications, other contracts that reference the ID, and indexer history, and every opted-in account has to opt in again. The exception is an application that is already deletable and whose owners accept those breaking changes, for which deleting and redeploying until the address is PQ compliant is available today. Checking your application addresses is worthwhile either way, so that you know where you stand.

Rekeying is not a substitute. Rekeying an application account to a post-quantum address does block the forged-signature attack, but it also stops the application spending from its own account, because an inner transaction is authorized by checking that its sender’s authorized address is the application address. This applies to inner transactions only: the holder of the new authorized address can still move the account’s Algos and assets with ordinary signed transactions, and only that holder can rekey the account back. Control is transferred rather than removed, and for a live application that decommissions the contract’s account rather than protecting it.

LogicSig Contract Accounts

A logic signature contract account derives its address from the compiled program:

address = SHA512-256("Program" || program)

Unlike an application ID, a program has room in it to change, and assemblers now take advantage of this: when a stateless program would hash to an on-curve address, the assembler appends a salt value as an integer constant and searches for one that produces a PQ compliant address. Salting happens during assembly, so whether a program is salted depends on the tool that assembled it, not only on its TEAL version:

• go-algorand’s assembler, used by goal clerk compile and algod’s /v2/teal/compile endpoint, salts programs at TEAL v13 or later by default.
• PuyaPy 5.10+ and PuyaTs 1.3+ salt logic signatures by default at any TEAL version.

As a second layer, algod rejects a transaction spending from an on-curve TEAL v13+ contract account when it is submitted, whichever tool assembled the program. This is the same node-level safeguard described under The Salt Byte: it applies at the REST boundary rather than in consensus, and the same skip-pq-address-check parameter bypasses it. The rejection happens when the account tries to spend, not when it is funded, so run algokey pq check-address on a contract account’s address before sending funds to it.

These cases fall outside that protection:

• Programs compiled at TEAL v12 or earlier. The node’s check does not apply, and go-algorand’s assembler only salts them if the program opts in with #pragma autosalt true. Fixing an on-curve contract account means recompiling it with salting, which produces a different address, so it means moving funds.
• Programs that were not salted during assembly. A program assembled by tooling that does not salt, or whose bytes are changed after assembly, can hash to an on-curve address at any TEAL version. At v13 or later, the node’s check still applies to it.
• Delegated logic signatures. The node’s check covers contract accounts only. A delegated program is authorized by the delegating account’s signature, so the relevant address is the delegator’s, not the program hash.
• Salting turned off. #pragma autosalt false, or autosalt set to false in Puya, opts out of the automatic salt. go-algorand’s assembler warns when this leaves the address on-curve, but the program still compiles.

Multisig Accounts

A multisig address is derived from the signer set:

address = SHA512-256("MultisigAddr" || version || threshold || signer keys)

Nothing searches for a PQ compliant result, so about half of multisig addresses are on-curve. The exposure is the same, and the consequence is specific: nothing on-chain records that an account is a multisig. The threshold and the signer set exist only inside the msig blob that a spender presents. A transaction carrying an ordinary sig from the address is authorized by that address alone, so an attacker who recovered a private key for an on-curve multisig address would bypass the threshold entirely. It would never be consulted.

Multisig accounts can be rekeyed to a post-quantum address generated with the canonical salt, as Algorand tooling does by default, which protects the funds. The canonical salt matters here: the protocol accepts a post-quantum address built with any salt, so rekeying to one that is itself on-curve would leave the account exposed. What that does not preserve is the multisig itself: there is no post-quantum native multisig, so the account ends up controlled by a single Falcon key. See Limitations.

Keys and the Master Mnemonic

Generating a post-quantum account starts from 256 bits of entropy, represented as a familiar 25-word mnemonic. The scheme-specific seed is derived with domain separation:

seed = SHA512-256("PQK" || scheme || entropy)

Because the scheme identifier is part of the preimage, the same 25-word mnemonic yields an independent key for each post-quantum scheme: a Falcon-1024 key today, and independent keys for any future scheme. The mnemonic is therefore a cross-scheme master secret: one set of words, independent keys per scheme.

Falcon private keys and signatures are substantially larger than their Ed25519 counterparts (a Falcon-1024 signature is roughly 1.2 KB and the public key about 1.8 KB, versus 64 and 32 bytes), which is why post-quantum transactions carry a fee premium.

Fees

The minimum fee for a transaction is the sum of a base fee and per-scheme contributions. A Falcon-1024 signature contributes an additional 2× the base fee, so with the current base fee of 1,000 µAlgo:

Transaction	Minimum fee
Ed25519-signed	1,000 µAlgo (0.001 Algo)
Falcon-1024-signed	3,000 µAlgo (0.003 Algo)

The premium applies whenever a Falcon signature authorizes the transaction: both top-level pqsig transactions and logic signatures delegated with a Falcon key. Each scheme in the registry defines its own contribution, so future schemes may price differently.

Transaction Fees How minimum fees, surcharges, and congestion pricing work

Migrating an Existing Account

Existing Ed25519 accounts do not need to move funds to become quantum-resistant. Rekeying is the migration path: generate a post-quantum account, then send a rekey transaction that sets your existing account’s authorized address to the new post-quantum address. Your public address stays the same; from that point on, only the Falcon key can authorize its transactions.

Note that a rekey is part of the account’s ledger state. If the account is ever closed out, its ledger record, including the authorized address, is deleted; funding the same address again recreates the account under the control of its original Ed25519 key.

Migration is a forward-looking capability rather than a step to take today. No quantum computer capable of threatening Ed25519 is known to exist, and after rekeying, every transaction from the account must be Falcon-signed. Wallets, dApps, and tooling may not support post-quantum signing yet, or may assume the 1,000 µAlgo minimum fee rather than the 3,000 µAlgo a Falcon signature requires, so a migrated account can find itself unable to interact with parts of the ecosystem. The protocol support exists now so that the path is proven and ready before it is needed. For most accounts, the right time to rekey is when the quantum threat becomes credible and their tooling supports it.

Rekeying Accounts Change the key that controls an account without changing its address

Delegated Logic Signatures

A post-quantum account can delegate spending authority to a Transaction Execution Approval Language (TEAL) program, just as Ed25519 accounts can. The delegation signature covers a different payload than Ed25519 delegation:

SHA512-256("PQProgram" || authorizer address || program)

Binding the authorizer’s address into the signed payload prevents the same delegation from being replayed across the multiple addresses (salts) a single Falcon key can control.

Caution

A delegated logic signature is honored for any account whose authorized address matches the delegator, including accounts later rekeyed to it. If a delegated program must only ever spend from one specific account, the program itself must check the sender address.

Logic Signatures Delegated and contract logic signatures in depth

Limitations

• No post-quantum native multisig. Multisig accounts remain Ed25519-only by design. Threshold-style control of a post-quantum account can be achieved with logic signatures instead.
• Consensus participation is unchanged. This release does not alter participation keys or key registration; an account rekeyed to a post-quantum address participates in consensus the same way as before.
• Ecosystem support varies. Not every wallet, SDK, or tool supports post-quantum signing; check your wallet’s and SDK’s documentation before relying on it.

Tooling

The algokey command-line tool manages post-quantum keys with the algokey pq command family: generate, info, import, sign, sign-program, and check-address. It always uses the canonical salt.

Caution

algokey pq generate displays the master mnemonic once and does not store it; the keyfile holds only the scheme-derived Falcon key. Record the mnemonic when it is shown if you want to derive keys for future schemes from the same secret. Losing it does not lose the account, because the stored Falcon key still signs, but it forecloses future derivations.

AlgoKey Command-line key management reference

Additional Resources

• Falcon: Fast-Fourier Lattice-Based Compact Signatures over NTRU: the Falcon signature scheme specification
• FIPS 206 (Initial Public Draft): FN-DSA: NIST’s draft standard derived from Falcon; Algorand uses a deterministic Falcon variant