1 Signature scheme 0/10, weighted 30%
Band 0: Classical signatures only on mainnet, with nothing post-quantum protecting live funds. Short-lived devnets and one-off benchmarks sit here: they demonstrate research rather than something a user can hold keys on.
The node accepts two transaction signature types: RSA-PSS with 4096-bit keys and public exponent 65537, the default, and ECDSA on secp256k1, accepted on format 2 transactions from the 2.9 fork height. Shor's algorithm breaks both, and nothing post-quantum protects AR on mainnet.
source
2 Deployment stage 1/10, weighted 25%
Band 1: Tier 5: Exposed.
Tier 5: Exposed. The signatures securing AR are quantum-vulnerable, and no post-quantum proposal, plan or research programme from the Arweave team or from the Digital History Association, which prepared the 2.9.1 and 2.9.6 node releases, was found: none in the node repository's code, issues or release notes, the developer documentation, the yellow paper or the lightpaper. Work by projects built on Arweave, such as AO, is not work on Arweave's own signatures.
source
3 NIST alignment 0/10, weighted 15%
Band 0 to 2: No post-quantum scheme named for the chain’s fund-protecting signatures, or a proprietary scheme with no public cryptanalysis.
No post-quantum scheme has been named for Arweave's transaction or block signatures by anyone with authority over the chain, so there is nothing to align with a NIST standard. The one signature type added in recent years, ECDSA on secp256k1, is classical.
source
Placement in the band The floor of the band rather than a 1 or a 2: no scheme has been named for Arweave's signatures at all, not even as an example or candidate, so there is no partial alignment to credit.
4 Migration path 2/10, weighted 15%
Band 0 to 2: No agreed migration path, or the proposals on the table would strand or freeze holder funds.
No migration plan exists. Arweave does have working machinery a migration could use: transactions carry a signature type, and the 2.9 hard fork used it to add ECDSA keys beside RSA without disturbing existing wallets, while the 2.9.6 fork of September 2026 retired format 1 transactions. There is no in-place key rotation, since the documentation says there is no account delegation mechanism, so a holder would move AR to a new address.
source
Placement in the band The top of the band rather than a 0 or a 1: Arweave has added a signature scheme through a coordinated hard fork and retired an old transaction format through another, which is the route a post-quantum key type would take. Not a 3, because no one with authority over Arweave has acknowledged quantum migration as a problem.
5 Exposure 2/10, weighted 10%
Band 0 to 2: Public keys are exposed for effectively all accounts, or a large, measured share of total supply sits in exposed addresses.
An Arweave address is the SHA-256 hash of the public key, so a wallet that has only received AR keeps its key off the chain. Sending reveals it: the owner field of an RSA transaction is the full RSA modulus of the sending wallet, and an ECDSA key is recovered from the transaction's signature. Uploading data is itself a signed transaction, and every block records the miner's public key.
source
Placement in the band The top of the band rather than a 1: hashed addresses do keep the keys of receive-only wallets hidden. Not a 3, because any wallet that has paid for storage or sent AR has published its key, and no measurement of the exposed share of supply has been published.
6 Verification 2/10, weighted 5%
Band 0 to 2: No post-quantum component exists, or the claims rest on marketing.
No post-quantum component exists for Arweave: no code, specification or testnet implementation for its signatures was found. The node is open source, but under v1.8 the openness of the classical code earns nothing here.
source
Placement in the band The top of the band rather than a 0 or a 1: there is no post-quantum component to verify, but nothing about Arweave is marketed as quantum-safe by the project, so its position does not rest on marketing.