PoS Layer-1. Account-based ledger.

Ed25519 public keys used for single-signature accounts, as raw keys inside multisigs, and as the signing keys for delegated logic signatures. (1)

The current Algorand Verifiable Random Function (VRF) implementation relies on elliptic-curve cryptography and as such is vulnerable to CRQC. The VRF is used in Algorand's committee selection and cryptographic sortition processes. A CRQC removes the guarantee of membership anonymity before a member's vote is cast. (2) Losing this anonymity could allow an attacker to identify committee members in advance and target them. The Algorand Foundation has stated their research "shows that Algorand's VRF appears to prevent attackers from falsely claiming committee membership". (2)

Ed25519 signatures are used for consensus messages and voter signatures in the core consensus protocol. (2)

Algorand single-signature account addresses are Ed25519 public keys, and as such they are vulnerable to a CRQC deriving the associated private key as soon as the address is known. (1)

A delegated logic signature is a program signed by an account's Ed25519 spending key, allowing the program to authorize transactions on that account's behalf. The signing keys for delegated logic signatures are Ed25519 public keys and the associated private key can be derived by a CRQC. (1)

The addresses for Multisig, Logic Signature, and Application accounts are hash derived and are not Ed25519 public keys. A Logic Signature account is an account whose address is the hash of a program, where the program itself authorizes spends. An Application account is an account controlled by a deployed smart contract, with its address derived from the contract's Application ID. However there is a ~50% probability that the 32-byte identifier behind the address for all three account types may also be interpretable as a valid Ed25519 public key. Meaning a CRQC could theoretically derive a signing key for the address and submit a transaction authorized by a plain Ed25519 signature. (1)

Multisig accounts carry a second at-rest exposure. Once a multisig signs its first transaction, all constituent Ed25519 sub-signer public keys as well as the threshold and version are exposed on-chain, allowing a CRQC to recover the private keys. (1)

The heartbeat address, used for consensus participation liveness mechanisms, which is a constant Logic Signature account across all networks, decompresses to a valid Ed25519 point, which could allow for a CRQC to impersonate liveness responses or rekey the Logic Signature account. (1)

The rewards pool address, historically used for legacy protocol rewards, while not valid on "the main Algorand public networks" on a different network could be selected as an address that corresponds to a valid Ed25519 point. (1)

The fee sink address has an Ed25519 public key exposed by default. Payment transactions are blocked from the address but other operations could still be initiated if a CRQC recovered the private key. (1)

The MainNet ARC-54 burn application account, the standardized ASA burn address, decompresses to a valid Ed25519 curve point and must be secured through the application account strategy. (1)

Consensus voting public keys are exposed at rest. Accounts participating in consensus register their Ed25519 voting public key on-chain, where it is permanently published. A CRQC can recover the private key and forge that participant's consensus messages votes for the registration window. Voting keys are held separately from the account's spending key, so recovery does not allow funds to be moved or the account rekeyed. (2) (3)

VRF public keys are exposed at rest through the same registration transaction. A CRQC recovering the VRF private key can compute the participant's sortition outcomes in advance, removing the guarantee of membership anonymity before a vote is cast. (2) (4)

On-spend attack is not the primary vector on Algorand. Single-signature account public keys are already exposed at rest by default. Additionally Algorand's average block time of 2.82 seconds with instant finality would make the on-spend attack negligible. (1)

Not applicable

Not applicable

1. STATE PROOFS

State Proofs provide a Falcon-1024 signed attestation of ledger state every 256 rounds, the State Proof Interval. (1) Implemented in go-algorand v3.9.2, released September 5, 2022. (2) State proofs are intended to secure historical integrity for clients that sync from a trusted anchor and for external verifiers such as bridges and light clients. They do not protect account balances or spending authority, which depend on the account-level authorization paths below.

2. SINGLE SIGNATURE ACCOUNTS [LogicSig abstraction complete. Native PQ accounts in development for Q3 2026]

The solution for single signature accounts is to migrate the authorizer for the address to Falcon signatures. Initially, before Falcon native addresses are available, addresses can use Falcon account abstraction, in which a Falcon account can be represented by a logic signature that verifies Falcon signatures. This path is live on mainnet, with the first post-quantum transaction executed November 3, 2025. Falcon verification is exposed to the AVM as the native opcode falcon_verify, available since AVM v12 and usable in both stateless and stateful programs. The logic signature calls falcon_verify against the canonical transaction ID to gate authorization. (3) This can be done when the account is created or through rekeying the address.

The current Falcon account abstraction path requires a four-transaction group rather than a single transaction to obtain the necessary bytes budget, which creates friction with applications that expect exactly one authorizing transaction. An atomic flash rekey pattern is technically possible today but operationally complex. Removing this friction requires either a protocol upgrade to increase LogicSig size limits or the introduction of native post-quantum accounts. End users will not have Falcon-capable hardware devices at the initial native account release. (4)

The long term solution is Falcon native accounts and signatures. Native PQ accounts and signatures require workarounds due to the size of Falcon keys, which cannot fit the standard existing 32-byte identifiers. The workaround is using a hash of the public key, which then requires a workaround to expose the Falcon public key given the hash of the public key is only one way. This requires either stateless or stateful Falcon authorization. Stateless authorization carries the public key in every transaction, keeping verification self-contained and parallelizable at the cost of transaction size. Stateful authorization records the public key on the account after first use, reducing size but making verification dependent on a ledger read. (4)

Native accounts solve the issue in which the protocol expects a raw Ed25519 public key rather than an account, including delegated logic signature signing keys and multisig sub-signers, which cannot rekey to Falcon under the LogicSig abstraction. (4). Support for post-quantum accounts is expected to be introduced in Q3 2026. (5)

3. LOGIC SIGNATURE ACCOUNTS [Complete. Automatic tooling salting proposed]

To remove the risk surface of the Logic Signature account address decoding to a valid Ed25519 public key, the solution is to add "harmless salt" to the address in instances where there is valid decoding until the identifier can no longer be interpreted as a valid Ed25519 public key. The long term solution is for tooling to make this salting process automatic for any logic signature account. (4)

4. APPLICATION ACCOUNTS [Proposed]

Application accounts share the same risk surface area as logic signatures, with the address potentially resolving to a valid Ed25519 public key. Application accounts are the harder case because the address derives from the Application ID, a protocol-controlled counter, not from the application code. Changing the code does not change the address, so the creator cannot salt their way to an off-curve address. There are two proposed solutions. The first is similar to logic signatures, in which the protocol salts the address until it no longer resolves to a valid public key. However salting for application accounts changes a derivation rule that existing tooling, indexers, and off-chain systems assume is fixed. The second is that for application accounts the account's type is registered in the ledger and all authorization types that don't match the type will be rejected, which would mean even a valid Ed25519 signature would no longer be accepted. This would require a protocol upgrade to apply to all existing application accounts. Logic could be included in the upgrade which will mark the application as application controlled and disable the Ed25519 path for spends. (4)

Two edge cases remain unsolved for the path of registering the application type. The first is that an application account with an Application ID that is not yet funded would not be able to be registered. The second is that an address matching a predictable future Application ID could already have activity under another authorization path. (4)

5. MULTISIGNATURE ACCOUNTS [Planned, end 2026]

Multisig accounts carry two risks. The first is the accidental-address risk shared with logic signature and application accounts, where a CRQC deriving the single key behind the address collapses the threshold account into a single-key account. As with Logic Signature accounts this vulnerability is solved via salting the address until it no longer resolves to a valid Ed25519 public key. (4)

Additionally Multisig sub-signers are raw Ed25519 public keys inside the multisig configuration, not accounts, so they cannot individually rekey to Falcon. Addressing this risk requires either a new multisig version, a program-based multisig, or a new threshold-signature design based on post-quantum primitives. (4)

Native multisig support for multiple cryptographic schemes is planned for end 2026, enabled by cryptographic agility and native post-quantum accounts. (5)

6. SPECIAL ADDRESSES [Proposed]

Heartbeat address: used for consensus participation liveness mechanisms, currently decompresses to a valid Ed25519 point, which in theory could allow a CRQC to impersonate liveness responses or rekey the LSig to an address controlled by a CRQC actor. The presented solution is to rotate the address to an off-curve LSig address, which would not require a consensus upgrade to do. (4)

Rewards pool address: while the current implementations of the rewards pool address are not usable as a valid Ed25519 public key, future networks could choose a rewards pool address that does. To prevent this, the presented solution is to add a protocol requirement that the address be off-curve or otherwise unspendable through standard private key authorization. (4)

Fee sink address: the fee sink address has an exposed Ed25519 public key by default. Payment transactions are blocked from the address currently but other operations could still be initiated if a CRQC recovered the private key. The proposed solution is to implement new protocol restrictions which would prevent any private key control on the fee sink address for other transaction types. (4)

ARC-54 burn application account: the MainNet ARC-54 burn app account decompresses to a valid Ed25519 curve point and must be secured via the application account strategy. (4)

7. VERIFIABLE RANDOM FUNCTION [In research, research paper targeted early 2027]

The current Algorand Verifiable Random Function (VRF) implementation relies on elliptic-curve cryptography and as such is vulnerable to CRQC. The presence of a CRQC removes the guarantee of membership anonymity before a member's vote is cast. (5)

A replacement candidate for the VRF implementation is under active security and efficiency analysis. If the analysis yields positive results, a research paper is expected by early 2027. (5)

8. CONSENSUS MESSAGES AND VOTE SIGNATURES [In research, 2027]

Consensus messages and voter signatures are currently signed using Ed25519. While a signature scheme has not been definitively decided on, the leading candidate is Falcon, which "offers the most compact size of keys and signatures from lattice-based schemes". Additionally it is "likely Algorand will operate under a hybrid model for a while where both Ed25519 and Falcon signatures will be used for consensus messages." (5)

Signature schemes

1. Falcon-1024 (deterministic version), with a public key size of 1793 bytes and a signature size of 1280 bytes (1). Falcon is a NIST-selected lattice-based scheme and provides NIST security level 5, roughly equivalent to AES-256. (3). For Falcon the signing process relies on floating-point arithmetic and fast Fourier sampling. Falcon-1024 is currently used with State proofs, will be used for account signatures, and is the most likely candidate for consensus signatures. Selected due to the "compact signature size and high verification speed" which aligns with Algorand's "tight performance requirements on signature verification". (2)

2. Falcon-512. Pubkey size is 897 bytes and the signature size is ~640 bytes (4). NIST-selected lattice-based scheme. Provides a security level roughly equivalent to AES-128. Falcon-512 support will exist in parallel to Falcon-1024 support, and is expected to be added by the end of 2026. As Falcon-512 is more compact than Falcon-1024, it is "a candidate for shorter-lived keys where efficiency matters alongside quantum resistance." (5). (2)

Implementation

Cryptographic agility will be supported as part of Algorand's post quantum roadmap. Support for multiple concurrent signature schemes will be included in Q3 2026. Meaning Ed25519 accounts will continue to be supported while additional schemes are incorporated. (1).

Sept 5, 2022: State Proofs launched, go-algorand v3.9.2 (1)(2)

Nov 3, 2025: First post-quantum transaction on mainnet, Falcon-1024 LogicSig accounts (3)

Q3 2026: Support for Native PQ accounts (Falcon-1024) will be released

Q3 2026: SDK, AlgoKit, and Pera support

Q3 2026: Support for multiple concurrent signature schemes will be added to the network.

End 2026: Algorand Foundation will begin migrating its treasury to post-quantum accounts (4)

End of 2026: Support will be added to allow stakers to stake from post-quantum accounts (4)

End of 2026: Native Falcon-512 support (5)

End 2026: PQ multisig and hybrid LogicSig accounts (5)

Early 2027: PQ VRF research paper to be released (5)

2027: PQ consensus to be implemented (6)

End of 2027+: "broad quantum resilience" is targeted (6)

"Broad quantum resilience" is targeted by the end of 2027.

A proposed migration model for the Algorand network to "post-quantum" is "Lazy migration". In this model an account can pre-declare a post-quantum fallback authorizer while continuing to operate normally. If a vulnerable authorization path later needs to be disabled, the protocol switches only opted-in accounts to their pre-declared authorizer.