Note

Post-Quantum Is a Layer, Not a Blanket: What Autonomi's PQC Actually Covers

Autonomi uses post-quantum cryptography for transport and release signing, symmetric ciphers for stored data, and ECDSA for payments. What each layer covers.

2026-11-03 · autonomi, post-quantum, ml-kem, ml-dsa, self-encryption, release-signing, threat-model, civil-liberties

Listen · 9 min · AI voice

Dark CryptoDecentral hex mesh with a bright teal lattice band running across the middle like a shielded conduit, while bronze cells above and below sit outside it, some sealed, some open; no text.

"Post-quantum" is turning into a badge. Projects put it on the homepage, and readers hear "safe from quantum computers, full stop." Autonomi, the decentralised storage network, is one of the few stacks whose developer docs say precisely where post-quantum algorithms are used. That precision is useful, because it lets you ask the better question: post-quantum where?

Thesis, stated once: post-quantum cryptography protects a specific layer against a specific attack, and a system is only as quantum-ready as each layer you actually depend on. In Autonomi's case the transport and the release-signing tool use NIST's new post-quantum algorithms, stored content rests on symmetric cryptography that quantum computers threaten far less, and the payment rail inherits whatever signatures its underlying chain uses. Those are four different stories, and lumping them together hides the useful parts.

What a quantum computer actually threatens

Two quantum algorithms do the work in most discussions.

Shor's algorithm breaks the maths behind today's public-key cryptography: RSA, elliptic-curve key exchange, and elliptic-curve signatures such as ECDSA. A large enough quantum computer running it would let an attacker recover private keys from public keys. NIST's transition report, IR 8547, exists precisely to plan the migration away from these "quantum-vulnerable" algorithms toward post-quantum signature and key-establishment schemes.

Grover's algorithm speeds up brute-force search, which in principle weakens symmetric ciphers and hashes. In practice the gain is much smaller. NIST's post-quantum FAQ notes that Grover's full speedup requires running its steps in series, which defeats the massive parallelism real attacks rely on, and concludes that AES with 192- or 256-bit keys "will still be safe for a very long time," assuming no new weaknesses are found in AES itself.

So the fault line is clear: public-key operations need replacing; strong symmetric cryptography mostly does not.

Layer one: the transport

According to Autonomi's Post-Quantum Cryptography page, the network's transport library, saorsa-transport, uses ML-KEM-768 for key exchange and ML-DSA-65 for signatures. ML-KEM is the key-encapsulation standard in FIPS 203; ML-DSA is the lattice-based signature standard in FIPS 204. Both were finalised by NIST in August 2024.

The docs add one line that matters more than the algorithm names: "The transport layer has no classical fallback." A system that supports both classical and post-quantum handshakes can, if badly built, be pushed into the weaker one by an attacker in the middle. With no fallback, there is no weaker handshake to downgrade to.

The threat this answers is "harvest now, decrypt later": someone records encrypted traffic today and waits for a machine that can break the key exchange. If the session keys were agreed with ML-KEM, that recording is expected to stay opaque even then.

What it does not answer: encryption hides what moves between peers, not that peers are talking. IP addresses, timing and traffic volume are visible to anyone on the path, quantum or not.

Layer two: the stored content

Content uploaded as data or files goes through self-encryption before it leaves your machine. The Self-encryption page lists BLAKE3 for chunk hashing and ChaCha20-Poly1305 for authenticated encryption. Both are symmetric constructions, which places them on the comfortable side of the fault line above. ChaCha20 uses a 256-bit key. NIST's FAQ is written about AES, but its Grover argument is generic to brute-force key search, so the same reasoning applies to a 256-bit ChaCha20 key.

The weak point here was never the cipher. It is the DataMap, the retrieval metadata that ties encrypted chunks back to readable content. Autonomi's Keys, Addresses, and DataMaps page is blunt: for private data the DataMap is returned to you, and "if you lose that DataMap, you lose the practical ability to retrieve the private content." The flip side is that anyone who obtains it can retrieve the content too. A private DataMap is only as well protected as wherever you keep it. Store it in a cloud drive behind a reused password and the weakest link is that account, not the network's ciphers, quantum or otherwise.

Two more edges. Public uploads publish the DataMap on purpose, so there is nothing to protect cryptographically. And raw chunk operations, per the Data Types page, store caller-supplied bytes directly without self-encryption. If you put plaintext in a raw chunk, no algorithm choice will help.

Layer three: the payment rail

Writes are paid. The Payment Model page explains that uploads are funded from an Ethereum Virtual Machine wallet, with the CLI exposing arbitrum-one, arbitrum-sepolia and local networks, and that nodes verify an on-chain payment proof before accepting each write. Arbitrum is an EVM chain that uses Ethereum-style accounts, and those accounts sign transactions with ECDSA, as ethereum.org's accounts documentation describes, and ECDSA is in the quantum-vulnerable class Shor's algorithm targets.

That does not make your files readable to a future quantum attacker. Autonomi's own docs separate the jobs: the wallet key "is about payment, not about private-data decryption." What it does mean is that the payment layer's long-term integrity is tied to the chain's own migration plans, not to Autonomi's transport choices. A post-quantum pipe does not retroactively protect a classical signature.

Layer four: knowing you run the real software

The last layer is the one people skip. Autonomi's ant-keygen tool signs releases with ML-DSA-65 and supports a signing context, ant-node-release-v1 by default, so a signature made for one purpose cannot be replayed for another. That is good design.

Now read the Source Repositories page. Under "Source identity limitations," the docs state that the ant-node v0.20.0 archive signatures do not validate against the public key in the repository at the release tag, warn against treating manual verification with that key as a valid installation route, and add that "a matching SHA-256 checksum alone does not resolve the signing-key mismatch."

The docs don't give a cause, and they don't describe a compromise: what they document is a mismatch between the published signatures and the key in the repository. Publishing that limitation is the honest move. It also shows the lesson in miniature. A post-quantum signature is only as useful as your confidence in the public key you check it against. When the key and the signatures don't line up, the strength of ML-DSA can't settle the question for you; you need the project to say which key is authoritative.

Who this matters for

Most people storing family photos will never face a nation-state archiving their traffic for decades. The people who might are the reason the question matters: journalists protecting sources, human-rights documenters, researchers holding sensitive interviews, and anyone in a country where today's legal activity can become tomorrow's evidence. For them, "decrypt later" is a real planning horizon, and they need to know which layer is hardened and which still depends on their own key handling.

A practical checklist travels anywhere: confirm which layers your threat model depends on; keep private DataMaps somewhere at least as strong as the network you put the data on; never put plaintext in raw chunks; and treat release verification as a process to check against the project's own published limitations, not a box to tick.

What this is not

Not a claim that Autonomi is "quantum-proof." It describes what the developer docs say is in place on 2 November 2026, layer by layer.
Not an audit. We read the documentation and the standards; we did not review the code or test the implementations.
Not a quantum timeline prediction. Nobody can say when a cryptographically relevant quantum computer arrives; the point is knowing what depends on what.
Not token or payment commentary. The payment rail appears only to show which signatures it relies on. No pricing, no recommendation to acquire or use any token.
Not installation guidance. Follow the project's own verification instructions and its stated limitations.