What changes are coming to Quantaureum?
Quantaureum is in testnet phase. The items on this page are planning notes for hardening, scaling and usability, not shipped features; see qau/ROADMAP.md.
Cheaper transactions
Fee behaviour follows EIP-1559-style base-fee burning as implemented in code. Scaling work is roadmap material, not a published performance claim.
Extra security
Security work is ongoing. No completed third-party audit, FIPS certification or security compliance certification is claimed; known risks are listed in qau/SECURITY.md.
Better user experience
More support for smart contract wallets and light-weight nodes will make using Quantaureum simpler and safer.
Privacy by default
Privacy on Quantaureum is moving from an optional add-on to a network-level default, with upgrades that protect what users read, send, and prove onchain.
Why does Quantaureum need a roadmap?
Changes to this repository follow maintainer-led review; there is no foundation, elected council or token-holder governance. See qau/GOVERNANCE.md.
How the roadmap is defined
Protocol parameters are defined in code and documented design notes; review is maintainer-led (qau/GOVERNANCE.md). Contributions are welcome as issues and pull requests.
Design proposals are written up as documents and issues in the repository. There is no research forum, elected council or token-holder vote.
When a design is accepted, the parameters are implemented in code and reviewed by the maintainers; the authoritative state is the source repository.
More on Quantaureum governance
What technical upgrades are coming to Quantaureum?
Post-quantum security
Dilithium3 / ML-DSA-65 (FIPS 204) signatures and Kyber768 / ML-KEM-768 (FIPS 203) key encapsulation are implemented in code and used on testnet; ECDSA is disabled with no classical fallback. Hardening work continues.
QVM & parallel execution
The Quantaureum Virtual Machine (QVM) executes contracts written in QASM with Block-STM style parallel execution.
Threshold finality (QTD)
Blocks reach finality through GM-QTD threshold signatures from the validator committee, with ML-DSA-65 signatures throughout.
Verkle state & light clients
State is committed in a Verkle tree, enabling compact proofs and a practical SPV light client.
Sharding, DAS & rollups
Design note: multi-shard execution, erasure-coded data availability and rollup sequencing are planned work, not shipped features. See qau/ROADMAP.md.
Privacy & zero-knowledge
Design note: zero-knowledge research is exploratory and not a shipped feature. See qau/ROADMAP.md.
What is the timeline for these upgrades?
Yes—almost definitely. The roadmap is the current plan for upgrading Quantaureum, covering both near-term and future plans. We expect the roadmap to change as new information and technology become available.
Treat this roadmap as planning notes. Changes follow maintainer-led review (qau/GOVERNANCE.md); no completion date is published.
The project is in testnet phase; no completion date for any roadmap item is published. Giving precise timing of each upgrade is complicated to predict as many roadmap items are worked on in parallel and developed at different speeds. The urgency of an upgrade can also change over time depending on external factors (e.g. a sudden leap in the performance and availability of quantum computers may make quantum-resistant cryptography more urgent).
One way to think about Quantaureum development is by analogy to biological evolution. A network that is able to adapt to new challenges and maintain fitness is more likely to succeed than one that is resistant to change, although as the network becomes more and more performant, scalable and secure fewer changes to the protocol will be required.
Upgrades tend not to impact end-users except by providing better user-experiences and a more secure protocol and perhaps more options for how to interact with Quantaureum. Regular users are not required to actively participate in an upgrade, nor are they required to do anything to secure their assets. Node operators will need to update their clients to prepare for an upgrade. Some upgrades may lead to changes for application developers. For example, history expiry upgrades may lead application developers to grab historical data from new sources.
Sharding, erasure-coded data availability and rollup support are design and roadmap items in this repository. They are not shipped features and no performance figure is published.