Algorand crossed the support threshold for its v5.0.0 protocol upgrade on August 15. The change introduces accounts that can natively authorize transactions with Falcon-1024 signatures, designed to withstand attacks from a sufficiently capable future quantum computer.

The rules are not live on mainnet yet. A mandatory 208,000-round delay separates approval from activation. “Post-quantum” also needs a narrow definition here: it describes an optional account type, not every existing account or the whole Algorand protocol.

What the network actually approved

The stable go-algorand v5.0.0 release shipped on August 12. It contains a consensus proposal: operators can install the software, but the network must vote before the new rules become binding.

Algorand Foundation’s August 16 explanation says the proposal reached the required 90% threshold on August 15. When GatherHub checked the public mainnet status endpoint at about 11:05 UTC on August 17, it recorded 9,198 yes votes in a 10,000-round voting window, above the 9,000 required.

That snapshot still showed the old protocol as active and scheduled the next version for round 64,318,659. The distinction corrects a common headline shortcut: v5.0.0 has passed, but its rules are not operating on mainnet yet. The activation round should arrive roughly a week after the vote, although a chain round cannot be translated into a guaranteed clock time in advance.

The transition directly affects node operators, indexers and infrastructure that reads the chain. The release says Indexer and Conduit operators must install compatible versions as well. Software that cannot interpret the new protocol may stop following the network correctly once activation occurs.

What a Falcon account changes

A digital signature proves that a transaction was authorized by the private-key holder. Standard Algorand accounts use Ed25519, an elliptic-curve system considered secure against computers available today. In theory, a sufficiently powerful quantum computer could solve the underlying mathematical problem much more efficiently.

The US National Institute of Standards and Technology urges organizations to begin post-quantum migration, because changing systems, keys and software takes years. NIST selected FALCON as one of the signature algorithms intended for post-quantum standardization.

Algorand could already verify a Falcon signature inside a LogicSig program. V5.0.0 makes Falcon-1024 a native authorization method, functionally alongside Ed25519 and multisig. According to protocol engineer John Jannotti’s technical note, the address is deliberately constructed so it cannot also be a valid Ed25519 curve point. If Ed25519 were one day broken, an attacker could not simply forge a classical signature against that Falcon address.

The protection is opt-in. Users must create or adopt a Falcon account; v5.0.0 does not convert existing addresses. Consensus keys, verifiable random functions and other parts of the system still sit on Algorand’s broader post-quantum roadmap. Saying “Algorand is now quantum-resistant” would overstate what this upgrade delivers.

Protection comes with a footprint

Falcon-1024 has measurable costs. Its public key is 1,793 bytes and a signature can reach 1,423 bytes, compared with 64 bytes for an Ed25519 signature. The public key must travel with the spend because it cannot fit inside a 32-byte address.

The protocol also cannot batch-verify many Falcon signatures as it can with Ed25519. Each post-quantum signature is checked separately. The technical specification therefore assigns it two additional minimum-fee units: a Falcon-authorized transaction pays three minimum fees in total, versus one for an otherwise comparable standard transaction.

That trade-off leads into v5.0.0’s second major change: resource-based pricing. Larger or more demanding transactions pay more. Transactions that were already legal under the previous limits keep their existing allowances and minimum cost, so the model is not a blanket fee increase for simple payments.

Additional fees flow into the pool used for node-runner rewards. Algorand presents this as a first step toward funding infrastructure more directly from use. It is still a design claim, not evidence that fee revenue can sustain the network; actual receipts will only become visible after activation.

Larger contracts and cross-app access

The upgrade extends well beyond Falcon. The combined maximum size of an application’s approval and clear-state programs doubles from 8,192 to 16,384 bytes. Existing applications can also grow without changing their ID and migrating all state, with a new sponsor mechanism carrying the associated minimum-balance requirement.

AVM v13 adds cryptographic operations including Poseidon2 and lets one application access another application’s boxes when the owner explicitly permits it. That permission is material. Onchain data was already visible to outside observers, but read or write access from another contract is not switched on by default.

The release also removes the old `dryrun` endpoint and `tealdbg` tool in favour of `simulate`. Developers therefore face migration work alongside new capabilities: fee estimation, testing and indexing software must understand the new rules.

GatherHub’s Blockchain course explains how validators apply a network’s shared rules. This upgrade shows why publishing a binary is only the first step: voting, a round-based cooldown and operational adoption are separate events.

Why it matters now

V5.0.0 does not respond to a quantum computer that can currently break Algorand accounts. No available machine is known to defeat Ed25519. Its value is in testing key management, transaction formats, fee logic and software support before a migration becomes urgent.

Native support also exposes the price of that precaution: more block space, individual signature checks and higher fees. That is more useful than an undefined promise of “quantum safety,” because operators and users can measure the compromise.

Adoption is the main unknown. Without wallet, SDK, custody and recovery support, a protocol primitive can remain rarely used. Security will also depend on implementation quality, key protection and future audits — not just Falcon’s mathematics.

What to watch next

The first checkpoint is round 64,318,659. Observers should verify that the protocol activates and that indexers remain synchronized. The second is actual use: how many Falcon accounts appear, when the first native transactions are confirmed and what fees they pay.

Wallet and custodian support will matter next, followed by the remaining roadmap: post-quantum multisig, additional Falcon variants and migration of consensus components. Until those steps are demonstrated, v5.0.0 is a native post-quantum account option and a substantial fee-model change — not complete quantum immunity for the network.

Sources consulted