Algorand Post-Quantum Ledger

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¹:

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.
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.
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.

The idea of a genesis state will become useful later, when we discuss Algorand’s special addresses. Some addresses are not ordinary user accounts created through normal account activity; they are protocol-defined addresses that exist because they are part of the network’s initial state or protocol configuration.
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:

Accounts controlled by secrets must migrate away from quantum-vulnerable signature schemes such as Ed25519;
Accounts controlled by programs must ensure that their program logic cannot be bypassed through an unintended secret-based control path.

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.

This design also has an important tradeoff for standard Single-signature accounts. Algorand does not hide the Ed25519 public key behind an additional hash layer: the address directly carries the public key material needed for signature verification. This makes ordinary account verification simple and can be convenient for off-chain workflows, such as proving control of an account with a signature. But it also means that, for a Single-signature account, the quantum-relevant public key is exposed as soon as the address is known. In systems where addresses are hashes of public keys, the public key may remain hidden until the account first signs; in Algorand’s Single-signature account, that protection does not exist.

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

Single-signature accounts: the identifier is derived from an Ed25519 public key. Control comes from knowledge of the corresponding private key.
Multisignature (MSig) accounts: the identifier is derived from the hash of a multisig configuration: the version, the threshold, and the participating Ed25519 public keys. Control comes from enough valid signatures to meet the threshold.
Logic Signature (LSig) accounts: the identifier is derived from the program bytecode hash. Control comes from the program approving the transaction.
Application (App) accounts: the identifier is derived from the Application ID hash. Control comes from application logic. Only transactions initiated by the corresponding application are valid.

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:

Grover’s algorithm, which is relevant to brute-force search against hash-derived addresses;
Shor’s algorithm, which is relevant to recovering Ed25519 private keys from Ed25519 public keys.

The first question applies broadly to all hash-derived addresses and is discussed next. The second question is more subtle and affects accounts whose address may intentionally or accidentally admit an Ed25519 interpretation.

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.

This is a common requirement for every account type whose address is derived by hashing some seed into Algorand’s 32-byte address space.

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.

That would bypass the program entirely.

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.

The accidental-address idea matters for hash-derived account types, such as MSig, LSig, and App accounts. What changes from type to type is how the protocol can prevent that accidental Ed25519 interpretation from becoming a valid authorization path.

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:

A Single-signature account reveals an Ed25519 authorization path;
A Multisig account reveals a multisignature authorization path;
A Logic Signature account reveals a program authorization path;
An Application account reveals application-based control through inner transactions issued by the App account.

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.
That is why the strategy differs by account type.

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:

Compile the Logic Signature program;
Derive its address;
Check whether the 32-byte identifier decodes as a valid Ed25519 public key;
If it does, add a harmless salt to the program and try again;
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.

The important point is that the salt must not change the program’s logic. It only changes the bytecode enough to produce a different address. This can be done by adding a dummy value or by using compiler-supported salting.

This approach has already been used for the LSig-based Falcon account abstraction. That Logic Signature account must avoid having an accidental Ed25519 control path. Otherwise, the account would verify post-quantum signatures at the program level while still being vulnerable through the address-level Ed25519 interpretation.

The long-term goal is for tooling to make this automatic for any LSig. For newer TEAL versions, the proposed approach (developed in this PR) is to introduce a salt byte in the program prefix and have the assembler deterministically search for a salt that produces an off-curve Logic Signature address. Developers could still specify an explicit salt, but the default path should protect them from creating vulnerable Logic Signature accounts by accident.

This is a strong solution because it does not require a protocol upgrade or changing the fundamental Logic Signature address model. It uses the existing hash-derived address design and makes the safe outcome the default.

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).

That means changing the application code does not change the application account address. An App creator cannot simply add a harmless byte to the program and receive a new account address, as they can with a Logic Signature.

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.

This mirrors the Logic Signature strategy. The benefit is that future Application accounts could be created directly with off-curve addresses.

The drawback is compatibility. Existing applications, developer tools, indexers, contracts, and off-chain systems often assume that an App account address can be deterministically computed from the Application ID using the current derivation rule. Introducing a new derivation rule would need to be designed carefully so that it does not break existing assumptions.

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.

This approach has two separate cases:

Existing Application accounts: a protocol upgrade could perform a ledger migration that marks already-existing app accounts as application-controlled.
Future Application accounts: the protocol could mark the app account as application-controlled when the App account is created or when it receives the minimum balance required (MBR) to exist on the ledger.

This preserves the familiar Application ID to address derivation rule. However, it leaves two edge cases, with a similar root cause, that must be handled explicitly.

One edge case is an Application account that has an Application ID but is not yet funded. Another is an address that corresponds to a future Application ID: because Application IDs are predictable, an address that later corresponds to an App account could already have activity under another authorization path.

The goal is clear: prevent Ed25519 signatures from bypassing application logic. The exact migration path must preserve compatibility and avoid surprising users or developers.

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.

Rekeying is important because it separates an account’s public address from the account that is currently authorized to spend from it. A user can keep the same Algorand account address while changing the authorizer. In this case, the account can rekey from an Ed25519 authorizer to a Falcon-verifying Logic Signature authorizer.

This gives users a practical migration path:

Create or obtain a Falcon-controlled Logic Signature account with the CLI (it already ensures the Logic Signature address is off-curve);
Rekey the existing Ed25519 account to that Falcon authorizer;
Authorize future transactions through Falcon signatures rather than the original Ed25519 key.

There are still usability constraints. Falcon public key (embedded in the LSig program) and signature (passed as LSig argument) are larger than Ed25519 keys and signature, and the current account-abstraction flow requires a 4-transactions group rather than a single transaction to get the necessary bytes budget (shared between LSig program and arguments). This can create friction when interacting with applications that expect exactly 1 authorizing transaction or a group with more than 4 authorizing transactions.

One possible workaround is an atomic “flash rekey” pattern:

The Falcon-controlled account temporarily rekeys to an ephemeral account;
The ephemeral account performs the required application interaction;
The account rekeys back to the Falcon-controlled authorizer in the same atomic group.

This pattern is technically possible today but operationally complex. Removing this friction would require a protocol upgrade to increase the LSig size limits to avoid the transaction group “pooled” bytes budget and reduce one abstract Falcon account authorization to a single transaction. Another option would be to introduce native post-quantum accounts, without LSig abstraction, as defined in the rest of the article.

However, even without any protocol frictions, broader adoption of Falcon accounts depends on wallets, custody providers, exchanges, and developer tooling making Falcon key generation, storage, signing, and recovery safe for everyday users.

10. Multisignature accounts: two different quantum risks

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

The first risk is the same accidental-address risk that affects other hash-derived account types. The multisig address is a 32-byte identifier derived from a multisig configuration. If that identifier also decodes as a valid Ed25519 public key, a quantum attacker might be able to derive a single private key for the multisig address itself. That would collapse a threshold account into a single-key account.

The second risk is specific to multisig. A multisig account contains several Ed25519 public keys as sub-signers. Once those public keys are visible, a quantum attacker could target them individually. If the attacker can recover enough private keys to meet the multisig threshold, the account can be controlled through the intended multisig path.

The first risk can be addressed with a salting or typing strategy similar to the one discussed for Logic Signature and Application accounts. But that does not solve the second risk. The sub-signers themselves are still Ed25519 public keys.

A natural question is whether each multisig sub-signer can simply rekey to Falcon. The answer is no, because multisig sub-signers are not accounts inside the multisig configuration. They are raw Ed25519 public keys. Rekeying applies to accounts, not to public keys embedded inside a multisig template.

This means that preserving the same native multisig structure while making it post-quantum secure requires a new multisig version, a program-based multisig, or a new threshold-signature design based on post-quantum primitives.

Owners of existing multisig accounts may still have migration options, such as moving funds or rekeying the account to a different authorizer if their governance model allows it. But preserving the same address, the same threshold policy, and the same native multisig semantics cannot be guaranteed by a passive protocol-only migration. It requires active coordination by the multisig owners and, ultimately, new post-quantum multisig support.

11. Native post-quantum accounts

The LSig-based Falcon account abstraction is an important first step: it shows that an Algorand account can be controlled by a post-quantum secret today. But account abstraction does not provide full feature parity with native Ed25519 accounts.

Ed25519 public keys are deeply embedded in several parts of the current account model. They are used not only for ordinary single-signature accounts, but also as raw keys inside multisig configurations and as the signing keys for Delegated Logic Signatures. A Falcon account abstraction can control an account through a program, but it cannot simply replace every place where the protocol currently expects a raw Ed25519 public key.

To reach full feature parity, Algorand would eventually need native post-quantum signatures and native post-quantum accounts.

The main design challenge is size.

Ed25519 public keys are only 32 bytes. This small size is one reason the current address model works so elegantly: for a standard single-signature account, the address is effectively built from the public key, and the transaction’s sender field already carries the key material needed to verify the attached signature.

Post-quantum digital signature algorithms have larger keys and signatures. This is true for both hash-based and lattice-based schemes. Falcon offers the best tradeoffs among post-quantum signature candidates, especially in terms of public key and signature size, but it is still much larger than Ed25519. Falcon-512 public keys are 897 bytes, and Falcon-1024 public keys are 1,793 bytes.

That creates a compatibility problem. Algorand addresses are 32-byte identifiers encoded into the familiar address format. A Falcon public key cannot fit directly into that format.

A native Falcon account, therefore, cannot use the same address construction as a native Ed25519 account. Instead, it would need a hash-based address, similar in spirit to Multisig, Logic Signature, and Application accounts.

In such a design, the Falcon public key would serve as the seed for address derivation, along with a domain separator and a deterministic salt. The result would still be a 32-byte account identifier, preserving the existing address format. The resulting address would not be self-describing: by looking at it alone, an observer still could not tell that it was derived from a Falcon public key. A domain separator would only serve as an internal derivation safeguard, separating the Falcon-address derivation rule from other hash-address derivation rules. Whether it is strictly necessary depends on the final protocol design, but it is generally good cryptographic hygiene. The salt would ensure that the resulting address does not accidentally create an Ed25519 authorization path.

This solves the address-size problem, but it introduces a new one: information loss.

With Ed25519, the address is closely tied to the public key. The sender address and the signature are enough for verification because the public-key material is directly represented by the address model.

With Falcon, the address would only be a hash of the public key. A hash is intentionally one-way. Given the address, the verifier cannot reconstruct the Falcon public key. Therefore, a transaction signed by a native Falcon account must make the Falcon public key available somehow.

There are two broad ways to do this.

Stateless Falcon authorization

In a stateless design, each transaction carries three pieces of information:

The sender address;
The Falcon public key;
The Falcon signature.

The verifier first checks that the Falcon public key, domain separator, and salt derive the sender address. It then verifies the signature against that public key.

This is the closest analogue to today’s ordinary signature verification. The transaction contains all the cryptographic material needed to validate the Falcon authorization path. No additional account-state lookup is required for the signature check itself.

The main advantage is parallelism. Once a stateless signature is valid, it remains valid independently of the ledger state. This makes the verification path simple and highly parallelizable.

The transaction itself provides the public key needed for verification. Whether the transaction is otherwise valid still depends on ordinary protocol rules, such as balance and minimum-balance requirements.

The drawback is transaction size. Carrying a Falcon public key on every transaction increases the serialized transaction size. Under a fee model that depends on bytes, stateless Falcon transactions would generally be more expensive than Ed25519 transactions and more expensive than a design that avoids repeating the public key every time.

Stateful Falcon authorization

In a stateful design, the account record stores the Falcon public key after it is first introduced. Future transactions from that address do not need to carry the public key every time. They carry the signature, and the verifier looks up the public key from the account state.

This is similar in spirit to how rekeyed accounts already depend on account state to determine the current authorizer. But there is an important difference: for a native Falcon account, the mapping between the address and the Falcon public key is immutable. The public key is not merely an authorizer assigned to the account; it is part of the seed from which the address was derived. Under standard assumptions about cryptographic hashes, it is the only knowable key that can map to that address.

One practical approach would be to treat the Falcon public key as soft state on the account. In system design, soft state, if available, can ease some operations but is not required for correctness, as it can be reconstructed or supplied later. Here, the account could record the Falcon key after it first appears in a stateless Falcon authorization. Future transactions could then omit the public key and rely on the one recorded on the ledger.

The advantage is a lower transaction size after the first use. Once the public key is recorded as soft state, each subsequent transaction no longer needs to pay the byte cost of carrying the full Falcon public key.

The drawback is that signature verification becomes stateful when the transaction omits the public key. The verifier must look up the sender’s account state to retrieve the public key before checking the signature. Although verification can still be parallelized, it now depends on a relatively slow ledger read. It is worth noting that because the Falcon public key is soft state, closing the account would not permanently break the account model: the public key could be supplied again via a later stateless transaction.

For both stateless and stateful designs, address derivation must be deterministic and verifiable. The Falcon public key alone must determine a single canonical account address. If salting is used to avoid an accidental Ed25519 authorization path, the salt must therefore be selected by a protocol-defined deterministic rule, for example, by choosing the lowest salt value that produces an acceptable address. Anyone who sees a Falcon public key can derive the address and confirm that it matches the provided key. Without this canonical derivation rule, the same Falcon public key could correspond to multiple possible addresses, making the account model harder to reason about for users, wallets, and validators.

Native Falcon accounts would not replace the need for careful migration planning, wallet support, or account-specific hardening. But they would close an important gap: they would make post-quantum signatures a first-class protocol primitive, with Ed25519 feature parity (including use cases such as Delegated LSig or MSig sub-signers) instead of relying on account abstraction alone.

12. Special protocol addresses

Algorand also includes special addresses whose security properties do not map to ordinary accounts. Some of these addresses are network-specific: they are defined in the genesis state, meaning the initial state of the ledger. Others are protocol constants and are the same across networks. In both cases, they should be considered separately from ordinary user-controlled addresses.

Zero address: this is the null address. It is constant across networks and is not defined by the genesis state. This address is used, among other things, to irreversibly disable RBAC authorizations for the Algorand Standard Assets (ASA) or to burn ALGO⁴. Although the all-zero 32-byte value can be discussed as a point on the Ed25519 curve in a purely mathematical sense, it is a small-order point and not a valid canonical Ed25519 public key for normal account authorization. It is therefore not a normal spendable account, and no post-quantum migration is required.
Fee Sink address: this is a network-specific Single-signature account defined in the genesis state. It collects transaction fees and funds payouts to the block proposers. Although a private key exists operationally, the account is already constrained by protocol rules that prevent ordinary spending behavior for payment transaction type (ALGO transfers). Additional protocol restrictions are needed to prevent any private-key control on this special address for other transaction types.
Rewards Pool address: this address was historically used for legacy protocol rewards. It is network-specific and is defined in the genesis state. On the main Algorand public networks (MainNet, TestNet, and BetaNet), it has been defined so that it is not usable as a valid Ed25519 account public key, ensuring only protocol-defined authorization paths. However, this property should not be assumed for every possible Algorand network: a new network could choose a Rewards Poll address that corresponds to a valid Ed25519 point. To make the post-quantum ledger guarantee independent of genesis state choices, the protocol should require the Rewards Pool address to be off-curve or otherwise unspendable through ordinary private key authorization.
State Proofs address: this is the only address allowed as a State Proofs transaction sender. It is constant across the networks and is not defined in the genesis state. It is a synthetic hash-based address, but it is not derived from a program (as LSig accounts), nor from a progressive protocol-wise ID (as App accounts). Instead, it is computed by hashing the SpecialAddr domain-separation prefix together with the ASCII string StateProofSender. State Proof transactions are constrained by protocol. Moreover, this address is not associated with a valid Ed25519 point. Under those conditions, no post-quantum migration is required for this special address.
Heartbeat address: this address is used for consensus participation liveness mechanisms. It is a constant LSig account across networks, not defined in the genesis state, so it is not part of the protocol specifications and can be rotated without consensus upgrades. This address decompresses to a valid Ed25519 point. In a post-quantum setting, it should therefore be rotated to an off-curve LSig address, so a quantum attacker cannot impersonate liveness responses or, worse, rekey the LSig.

The important distinction is that protocol rules govern these addresses. They should not be treated like ordinary accounts whose control depends on a signature scheme.

13. The migration problem is bigger than the protocol

Post-quantum migration is not only a protocol engineering problem. It is an ecosystem coordination and standardization problem.

A blockchain can introduce post-quantum primitives, but users still need wallets that support them. Exchanges and custodians need operational procedures for key generation, storage, signing, and recovery. Hardware providers need secure implementations. Developers need clear tooling and predictable account models.

The migration must also avoid two extremes.

The first extreme is doing nothing until a credible quantum threat appears. That would risk a panic migration, where users rush to move or rekey accounts at the same time, competing for block space and increasing operational mistakes.

The second extreme is forcing a global migration too aggressively. If the protocol unilaterally disables existing authorization paths without user consent or adequate preparation, users could lose access to accounts, funds, applications, or governance roles. A forced migration can create harm comparable to the attack it is meant to prevent.

A better path is gradual and opt-in.

One possible model is lazy migration. In this model, an account can pre-declare a post-quantum fallback authorizer while continuing to operate normally. Later, if the network needs to disable a vulnerable authorization path, the protocol can switch only those opted-in accounts to their pre-declared post-quantum authorizer.

This gives users time to prepare before urgency arrives. It also avoids imposing a one-size-fits-all migration on accounts that may have complex custody, governance, or application dependencies.

14. The overall strategy

Algorand’s post-quantum account strategy is not one mechanism. It is a set of account-specific measures that all aim at the same goal: to remove quantum-vulnerable control paths from the live ledger.

The strategy can be summarized as follows:

Hash-derived addresses: maintain collision resistance against targeted second-preimage attacks, including quantum speedups from Grover’s algorithm.
Single-signature accounts: migrate from Ed25519 authorization to Falcon-based authorization, using rekeying where appropriate.
Logic Signature accounts: ensure the program-derived address is off-curve, ideally through automatic compiler or assembler salting.
Application accounts: introduce a protocol-level strategy, either through salted address derivation, account typing, or a combination that handles existing and future edge cases.
Multisignature accounts: recognize both the accidental-address risk and the exposed-subkey risk; plan for active owner migration and future post-quantum multisig support.
Native post-quantum accounts: introduce Falcon as a first-class protocol primitive, while deciding how public keys are carried, cached, and verified.
Special addresses: treat protocol-controlled addresses separately from ordinary user-controlled accounts.

The key idea is that post-quantum ledger security means more than replacing one signature scheme. It means examining every way an Algorand address can be authorized and ensuring that none of those paths can be exploited by a quantum attacker.

Algorand has already taken significant steps by using Falcon in State Proofs and by demonstrating Falcon-based transaction authorization with the Falcon Account abstraction. The remaining work is to turn these building blocks into a complete “crypto agile” account migration strategy: safe by default for new accounts, compatible with existing applications, and practical for users, wallets, custodians, and developers.

That is how Algorand can move from protecting blockchain history to protecting the live ledger itself.

¹Credits to my colleague Giulio Pizzini for the metaphor.

²Unspent Transaction Output.

³More precisely, about half of all 32-byte strings decompress to some valid Edwards25519 curve point, while only about one-sixteenth also lie in the prime-order subgroup generated by the Ed25519 base point B, i.e. are of the form [s]B for some scalar s. This is relevant for private-key recovery: Ed25519 signature verification may accept a decodable public key without separately proving that it lies in the base-point subgroup. For the present argument, using the one-half estimate is conservative, because it overcounts rather than undercounts the addresses that could plausibly correspond to a recoverable Ed25519 secret scalar, regardless of the subgroup check.

⁴The Zero Address cannot burn ASAs because ASA reception requires an asset opt-in, and the Zero Address cannot authorize it. ASA burning instead uses a network-specific App account (standardized by ARC-54). That is an ordinary App account for the purposes of this post-quantum analysis; for example, the MainNet ARC-54 burn App account decompresses to a valid Ed25519 curve point, so it must be secured using the Application-account strategy described in Section 8.

Disclaimer: This article discusses ongoing cryptographic research, experimental architectures, and potential future protocol design approaches relating to post-quantum security. Certain features, mechanisms, or migration strategies described herein may be conceptual, under evaluation, unimplemented, or subject to further research, testing, governance processes, ecosystem adoption, and regulatory considerations. References to “security,” “safety,” or “protection” describe design objectives and research goals under current cryptographic assumptions and should not be interpreted as guarantees of security, quantum resistance, protocol performance, or future network behavior. Cryptographic standards, quantum computing capabilities, implementation practices, and ecosystem support may evolve over time, and no assurance is given that any particular approach, feature, or migration path will be adopted, available, or effective in all circumstances. Any protocol modifications referenced in this article would remain subject to applicable governance, validator adoption, implementation, and ecosystem coordination processes.

The content provided in this article is for informational purposes only. The information is provided by the Algorand Foundation and while we strive to keep the information up-to-date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability with respect to the article or the information, products, services, or related graphics contained in the article for any purpose. The content of this article is not intended to be legal, financial, or investment advice nor is it an endorsement, guarantee, or investment recommendation. You should not take any action before conducting your own research or consulting with a qualified professional. Any reliance you place on such information is therefore strictly at your own risk. All companies are independent entities solely responsible for their operations, marketing, and compliance with applicable laws and regulations. In no event will Algorand Foundation nor any affiliates be liable for any loss or damage including without limitation, indirect, or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this article. Through this article, you may be able to link to other websites which are not under the control of the Algorand Foundation. We have no control over the nature, content, and availability of those sites. The inclusion of any links does not imply a recommendation nor endorse the views expressed therein.