The Algorand protocol engineering team has been cooking up a feast lately, and the Algorand 5.0 upgrade brings a wide variety of new capabilities and raises many of the protocol’s long-standing limits. In this four-part series, we’ll explore some of the most important ones through an extended metaphor using the core components of cooking: salt, fat, acid, and heat. Rather than cooking tasty food, though, we’re enhancing the flavor of the applications that can be built on Algorand.
Part 1 of the series (Salt) is below; stay tuned for parts 2-4 in the coming days.
Part 1: Salt - Cryptographic capabilities
Post-Quantum Signatures
The single biggest addition to Algorand in this 5.0 upgrade is a framework enabling native post-quantum (PQ) signature schemes for transactions, beginning with the addition of Falcon-1024.
While it has been possible since late 2025 to create LogicSig smart contract accounts that will only authorize transactions after verifying a Falcon signature, the way this was achieved required combining multiple transactions together, which impeded DeFi composability with protocols that require using several transaction slots in the atomic group for their own calls. Smart contract accounts are also not the typical approach preferred by most Algorand wallets.
A better approach is to add first-class support for transactions to carry post-quantum signatures, and that’s what we’ve added now:
pqsig: { sch: [2]byte, slt: uint8, pk: []byte, sig: []byte }
The new pqsig framework is a transaction signature envelope that allows arbitrary schemes to be added to the protocol in the future. Here we can indicate the scheme being used, and the first one we support is Falcon-1024, a lattice-based scheme that is suitable for long-lived accounts. In the future, support for additional schemes will be explored. Falcon-512 is already on Algorand’s roadmap as a variant of Falcon with smaller public key and signature sizes that can be suitable in situations where lightness is useful, and security requirements are somewhat less demanding.
Salt to taste
Note that this signature object includes slt, an important salt value that is used to ensure that the Algorand address derived from a PQ public key does not correspond to a valid point on Curve Ed25519. If a PQ account address does not lie on the curve, then there is simply no corresponding Ed25519 private key that could ever be found by an attacker with a quantum computer. As a result, PQ accounts can only ever spend by signing with their PQ key.
Generally speaking, the Algorand technical community will consider the canonical salt to be the lowest value that results in an address that is off of Curve Ed25519. This will be the default approach used in our SDKs when handling accounts, in the algod REST API when submitting transactions, and in other tooling.
That said, the protocol itself will not enforce this canonical salting approach, and signatures will verify successfully even if a different salt has been used by a wallet to generate an account.
Astute readers will notice that the salt is only one byte, which provides 256 tries with roughly 50-50 odds each to find a point that isn’t on the Edwards curve. The probability of using all of those tries and failing to find a good address is extremely small, and if that should occur, a new PQ keypair should be generated.
Crypto-agile signing interfaces
Alongside this protocol upgrade, we have introduced upgrades in our SDKs around handling and signing for Algorand accounts. This includes support for PQ signature schemes, support for hierarchical-deterministic (HD) accounts, support for integrating with key management systems (KMS), and more secure secret handling.
Throughout the libraries, you will find flexible interfaces for signing transactions that can be wired up to any signer, with the default approach being that this signing occurs somewhere secure rather than handling raw key material directly in the library.
The goal is to make it easier for developers to build secure, production-ready applications and avoid building infrastructure or even helper scripts that involve the use of secrets in cleartext that can fall victim to malware attacks against servers and developer machines.
These new interfaces also open the door to supporting more signature schemes in the future without requiring developers to update their SDK code to leverage new and different approaches to signing transactions.
Stay tuned for Part 2 in this series: “Fat: Fatter apps and transactions,” coming later this week.
What do you want to build on Algorand 5.0? Join our Discord server to meet other developers building PQ solutions, fat apps, box families, and more.
Disclaimer: The content provided in this blog is for informational and educational purposes only. The information is provided by the Algorand Foundation and while we strive to keep it accurate and current, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the blog or the information contained in it for any purpose. Nothing in this blog is legal, financial, tax, or investment advice, nor an endorsement, guarantee, or investment recommendation. Technical descriptions are provided as of the date of publication and may change. Any statements about future plans, features, integrations, protocol or consensus upgrades, fees, or timelines are forward-looking and subject to change, including subject to community adoption, and are not commitments. You should conduct your own research and consult a qualified professional before acting on any information here; any reliance you place on it is strictly at your own risk. All third-party names and trademarks are the property of their respective owners, and their mention does not imply affiliation or endorsement.