Algorand Post-Quantum Ledger

Algorand Post-Quantum Ledger

May 14, 2026

Written by: Cosimo Bassi

Securing the ledger, one account type at a time

Quantum computing changes the security assumptions behind many of today’s public-key cryptographic systems. Blockchains are especially exposed because accounts, transactions, and consensus messages all depend on public keys and digital signatures. A sufficiently powerful quantum computer running Shor’s algorithm could derive certain private keys from their public keys and use them to forge signatures.

Algorand’s post-quantum strategy can be understood as a three-part roadmap:

  1. Secure the past: protect the blockchain’s history so an attacker cannot rewrite the sequence of blocks and transactions that led to the current ledger state. Algorand began this work with State Proofs, deployed in 2022 in the “Renaissance Block”, which use Falcon signatures to make historical attestations quantum-resistant.

  2. Secure the present: protect the ledger itself, meaning the current state of every account. This requires ensuring that a quantum attacker cannot bypass account control.

  3. Secure the future: protect consensus, including the cryptographic sortition mechanism that determines which participants propose and vote on blocks. This is the hardest step because it requires research into a post-quantum replacement for the Verifiable Random Function at the heart of Algorand’s Pure Proof-of-Stake protocol.

This article focuses on the second step: securing Algorand accounts so that the live ledger can become post-quantum safe. It builds on Algorand’s November 2025 post-quantum milestone: the first MainNet transaction authorized with Falcon signatures, implemented through an account abstraction. That work demonstrated a practical path for post-quantum transaction authorization. The broader question addressed here is how to extend that idea into a complete account strategy for the ledger as a whole.

1. What does it mean to secure the ledger?

To understand the account strategy, we first need to distinguish between two ideas that are often compressed into the word "blockchain."

A blockchain contains a history: the ordered sequence of transactions and blocks that have already happened. The ledger contains the present state that results from that history: balances, assets, application state, account configuration, and other data that exists now.

This distinction is especially clear when comparing UTXO-based and account-based blockchains.

In a UTXO-based blockchain, the system starts from a genesis block. That block is still a block in the usual sense: it contains the initial transactions that create the first unspent transaction outputs. From there, the current state of ownership is reconstructed by following the full transaction history and tracking which outputs remain unspent.

In an account-based blockchain, the starting point is better understood as a genesis state. It is often still called a genesis block for consistency with blockchain terminology, but conceptually, it is not defined by a list of ordinary transactions. It defines the initial ledger state directly: the first accounts, their balances, and any special protocol accounts or parameters that exist from the beginning.

Algorand is an account-based blockchain. Instead of tracking unspent coins as independent objects, as UTXO-based blockchains do, the network maintains accounts and updates their state as valid transactions are confirmed. In this model, the ledger can be viewed as a table of accounts, where each row records the current state of one account.

Securing the ledger, therefore, means securing account control. If every account can only be controlled through a post-quantum-safe authorization path, then the ledger’s present state is protected against quantum key-recovery attacks.

That sounds simple, but Algorand has more than one kind of account, and not all accounts are controlled in the same way.

2. Two ways to control an account: secrets and programs

At a high level, an Algorand account can be controlled in two ways.

The first way is by a secret. A user knows a private key and uses it to sign a transaction. The network verifies the signature against the corresponding public key. This is the familiar model used by standard Single-signature accounts. Multisignature accounts extend the same idea by requiring several secrets instead of one.

The second way is by a program. Instead of accepting a transaction because a private key signed it, the network accepts the transaction because a program approves it or initiates it. In Algorand, this includes Logic Signatures and Applications. A program-controlled account is meant to be governed by code rather than by a private key.

This distinction is central to the post-quantum account strategy:

The first problem is intuitive. The second is more subtle.

3. Addresses are not always the same as public keys

Before looking at each account type, we need one more distinction: an Algorand address is not always just a public key.

An Algorand address is a user-friendly encoding of a 32-byte identifier, plus checksum information. All account addresses have the same external format. By looking at an address alone, you cannot tell whether it belongs to a Single-signature account, a Multisignature account, a Logic Signature account, or an Application account.

This is useful. It gives all accounts a uniform interface and avoids exposing unnecessary information from the address format itself. But it also means that the address does not describe how the account is supposed to be controlled.

Different account types derive their 32-byte identifiers from different inputs:

The hash-derived address (MSig, LSig, and App) design gives Algorand a consistent address format across account types. It also creates two distinct post-quantum questions, related to two different quantum algorithms:

4. Collision-resistant hash-based addresses

Any hash-derived address, whether it belongs to a Multisig account, a Logic Signature account, an Application account, or a future native post-quantum account, must satisfy one basic requirement: the 32-byte address space must remain collision-resistant enough for the account model.

The risk here is different from the Ed25519 key-recovery risk discussed later. Shor’s algorithm threatens signature schemes such as Ed25519 because it can solve the hard mathematical problem that links a public key to its private key. Hash-derived addresses instead rely on the difficulty of finding another input that produces the same address.

For account security, the most relevant hash attack is usually a targeted second-preimage attack: given an existing account address, an attacker would try to find a different seed that hashes to that same 32-byte identifier. In more casual language, this is often described as an address collision, but the important point is that the attacker is targeting a specific existing address, not merely looking for any two inputs that collide with each other.

A quantum attacker can use Grover’s algorithm to speed up a brute-force search. However, a 32-byte hash output still provides a very large security margin for this kind of targeted search, assuming the derivation uses an appropriate cryptographic hash, clear domain separation, and no structural weakness in the input format.

5. The subtle issue: no key was generated, but one may still exist

For a Logic Signature account or an Application account, the account creator does not generate an Ed25519 private key for the account address. The address comes from the program hash in the Logic Signature case, or from an Application ID hash in the Application case.

So it is natural to ask: if no private key was created, what could a quantum attacker steal?

The answer is that “no private key was intentionally created” is not the same as “no private key can mathematically exist.”

The 32-byte identifier behind an Algorand address may also be interpretable as a valid Ed25519 public key. Roughly speaking, this happens with probability close to one-half. If the identifier is a valid Ed25519 public key, then there is a corresponding private signing key in the mathematical sense, even if nobody generated it and nobody knows it today.

Under classical assumptions, this is not a problem. Given an Ed25519 public key, finding a matching private key is computationally infeasible. Therefore, a program-controlled account remains controlled by its program. The accidental existence of a valid public-key interpretation does not help an attacker.

A large enough quantum computer changes that assumption. Shor’s algorithm can solve the discrete logarithm problem on which Ed25519 relies. If a program-controlled account address also happens to decode as a valid Ed25519 public key, a quantum attacker could potentially derive a signing key for that address and submit a transaction authorized by a plain Ed25519 signature.

This is the core problem for program-controlled accounts in a post-quantum setting: the program may contain no secret, but the address may accidentally admit a secret-based interpretation.

6. Why not simply reject Ed25519 signatures for program accounts?

A natural solution would be to make a protocol rule: if an account is controlled by a program, reject any attempt to control it with an Ed25519 signature.

Conceptually, that is attractive. Practically, it is complicated because Algorand addresses are not self-describing.

Before an account is used, the address alone does not reveal whether it came from a public key, a Multisig configuration, a Logic Signature program, or an Application ID. The ledger learns the effective control path only when the account first performs a valid action:

Once the ledger has learned that an address is program-controlled, it can, in principle, enforce that interpretation going forward. But the protocol still needs to handle accounts that already exist, accounts that have not yet been funded, and addresses that may be computed before their corresponding application exists.

7. Logic Signature accounts: use the hash as a coin toss

Logic Signature accounts are the easiest program-controlled accounts to harden.

A Logic Signature address is derived from the program bytecode. Hash functions have an avalanche property: changing even one byte of the input produces a completely different output. That means a developer can slightly alter the program bytecode without changing the program’s behavior and receive a new address.

For post-quantum safety, this becomes a simple strategy:

  1. Compile the Logic Signature program;
  2. Derive its address;
  3. Check whether the 32-byte identifier decodes as a valid Ed25519 public key;
  4. If it does, add a harmless salt to the program and try again;
  5. Repeat until the resulting address is off-curve, meaning it cannot be interpreted as a valid Ed25519 public key.

Because each attempt behaves like an independent coin toss, the expected number of attempts is small.

8. Application accounts: the harder program-account case

Application accounts are harder because their address is not derived from the application program. It is derived from the Application ID, which is a unique progressive counter controlled by the protocol (not the App creator).

There are two non-mutually exclusive ways to secure Application accounts.

Option A: salt the Application address

The first option is to extend the address derivation mechanism so that the protocol-driven Application ID is combined with some salt or nonce. At creation time, the protocol could try salts until it finds an application address that does not decode as a valid Ed25519 public key.

Option B: type the Application account

The second option is to record the account’s type in the ledger and reject authorization paths that do not match that type. If an address is known to be an Application account, then a plain Ed25519 signature for that address should not be accepted, even if the address bytes happen to decode as a valid Ed25519 public key.

9. Single-signature accounts: migrate the authorizer to Falcon

Single-signature accounts are controlled by Ed25519 private keys, so their post-quantum risk is direct: if the public key is exposed, a quantum attacker could eventually derive the corresponding private key.

Algorand’s first move for these accounts is the Falcon account abstraction.

A Falcon account can be represented by a Logic Signature that verifies Falcon signatures. A user can create a new account controlled by Falcon from the start, or migrate an existing Ed25519 account by using Algorand’s rekeying feature.

10. Multisignature accounts: two different quantum risks

Multisignature accounts require special treatment because they face two different post-quantum risks.

11. Native post-quantum accounts

The LSig-based Falcon account abstraction is an important first step, but full feature parity would need native post-quantum signatures and accounts.

12. Special protocol addresses

Algorand includes special addresses whose security properties do not map to ordinary accounts. Some of these are defined in the genesis state or treated separately from ordinary user-controlled accounts.

13. The migration problem is bigger than the protocol

Post-quantum migration is not only a protocol engineering problem. It requires ecosystem coordination, standardization, and careful planning to avoid issues.

14. The overall strategy

Algorand’s post-quantum account strategy aims to ensure that no quantum-vulnerable control paths exist in the live ledger. It includes various strategies, such as secure address management and migration paths to post-quantum-safe authorization.