Five NIST post-quantum signature and hash precompiles run live on AERE mainnet. This page replays the published KAT and ACVP conformance vectors against them in your browser, with a read-only eth_call. No wallet. No keys. No writes. Every check is reproducible from your own node.
This proves account and application-layer post-quantum cryptography: the five precompiles at 0x0AE1 to 0x0AE5 verify NIST PQC signatures and compute SHAKE256 fully on-chain, so contracts and accounts on chain 2800 can adopt post-quantum signatures today.
Consensus is still classical ECDSA. AERE's QBFT block production and finality use classical secp256k1 signatures. A hybrid post-quantum consensus mode exists only on an isolated testnet and is audit-gated, not live. This page makes no claim about the consensus layer.
Each vector is a hex blob captured from a NIST Known Answer Test or from the NIST Automated Cryptographic Validation Program. The page sends it as the calldata of a read-only eth_call to the precompile address. The signature precompiles return a 32-byte word: 0x00...01 accepts a valid signature, 0x00...00 rejects a tampered or malformed one. SHAKE256 returns the raw digest bytes. The page compares the live return against the expected output byte for byte, then shows you the exact curl so you can run the same call against https://rpc.aere.network or any AERE node yourself.
Vectors are loaded from a static in-repo fixture (/quantum-vectors.js), copied verbatim from the conformance suite. Nothing is fetched from a third party. Signature verification is a public operation, so none of this input is secret.
1. Ask the network what is active. One call, no wallet, no gas:
curl -s -X POST https://rpc.aere.network -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_config","params":[]}'
The reply carries activationTime: 1783820272 and the live precompile set: AereFalcon512 at 0x0AE1, AereFalcon1024 at 0x0AE2, AereMLDSA44 at 0x0AE3, AereSLHDSA128s at 0x0AE4, AereSHAKE256 at 0x0AE5. Block 9,189,161 is the first block whose timestamp is at or after that activation time, which you can confirm by binary search over eth_getBlockByNumber timestamps. That block contains no transactions, because a fork activation is a configuration change and not a transaction. Its significance is its timestamp, not its contents, so do not expect to find anything by opening it in the explorer. Run the same call against https://rpc2.aere.network for an independent second endpoint.
2. Prove they are executing right now, by measuring gas. This is the strongest live proof. A live precompile consumes gas; an address with nothing at it consumes none. Return values do not settle the question, because an empty address returns empty data and reports success. Gas does. The call below deploys a throwaway measuring probe with an eth_call state override and returns the gas one call to 0x0AE1 consumed:
curl -s -X POST https://rpc.aere.network -H 'content-type: application/json' -d '{
"jsonrpc":"2.0","id":1,"method":"eth_call","params":[
{"to":"0x000000000000000000000000000000000000b0b0",
"data":"0x3333333333333333333333333333333333333333333333333333333333333333",
"gas":"0x1c9c380"},
"latest",
{"0x000000000000000000000000000000000000b0b0":{"code":"0x366000600037600061a0005260006000600060006000730000000000000000000000000000000000000ae1612710f1505a6120006180003660006000730000000000000000000000000000000000000ae16305f5e100f1505a900360005260206000f3"}}]}'
Returns 0x9cbc = 40,124. Swap both occurrences of ...0ae1 for ...dead, a codeless control address, and it returns 0x7c = 124. The difference, 40,000 gas, is the Falcon-512 verification cost.
Calibrate before you trust it. Point the same probe at the IDENTITY precompile 0x04, whose cost the EVM specification fixes at 15 + 3*ceil(len/32). For this 32-byte input it must read exactly 18 above the control. It returns 0x8e = 142 against the control's 124. Exactly 18.
| Address | Gas above control | Meaning |
|---|---|---|
0x04 IDENTITY | 18 | calibration, matches the EVM spec exactly |
0x0AE1 Falcon-512 | 40,000 | live |
0x0AE2 Falcon-1024 | 75,000 | live |
0x0AE3 ML-DSA-44 | 55,000 | live |
0x0AE4 SLH-DSA-128s | 350,000 | live |
0x0AE5 SHAKE256 | 60 + 12 per word | live |
0x0AE6, 0x0AE7 | 0 | not on mainnet, testnet only |
Those figures are literal constants in the client source, so your measurement and our published code can be compared line for line. 0x0AE6 and 0x0AE7 measure exactly the codeless control, and eth_config independently omits them from the precompile list: two methods agreeing that they are not on mainnet.
To check the past instead of the present: historical account state is pruned after 512 blocks, so a historical eth_call will not work. Receipts are kept in full. Receipt 0xcd1350372f0a61e26e8a3228da599be9211839f378eef0ea49f2025a20920660 is a successful post-quantum attestation at block 9,200,532, status 0x1, 1,386,367 gas. That contract reverts unless the precompile returns a valid result, so that receipt could not exist on a chain without the precompile.
Loading conformance vectors,
aerenew/conformance/conformance-vectors.json and is the same set the AERE second-client conformance test replays byte for byte.0x) when the output length is zero or the input is shorter than the 32-byte length prefix. Both behaviours are covered by vectors below and verified live.The precompiles above are the on-chain half. The connection that carries your JSON-RPC is hardened too: the primary endpoint rpc.aere.network negotiates the X25519MLKEM768 hybrid TLS key exchange, NIST FIPS-203 ML-KEM-768 combined with classical X25519. The session key stays secret even against an adversary who records the traffic today and decrypts it with a quantum computer later, the harvest-now-decrypt-later threat.
Verify it yourself with OpenSSL 3.5 or newer, the first release that ships the post-quantum groups:
openssl s_client -groups X25519MLKEM768 \
-connect rpc.aere.network:443 </dev/null 2>/dev/null \
| grep -i "Negotiated TLS1.3 group"
# => Negotiated TLS1.3 group: X25519MLKEM768This is transport-layer confidentiality (the TLS handshake). Certificate authentication is still classical WebPKI, and this is independent of the on-chain precompiles above. A post-quantum handshake on the validator-to-validator devp2p layer is a separate, client-level item and is not claimed here.
Seven contracts deployed 2026-07-19: a Falcon-rooted agent identity and an eIDAS-aligned verifiable-credential stack. Each is independently checkable, fetch the runtime bytecode with eth_getCode and compare it to the published Solidity artifact (solc 0.8.23). Two are byte-identical to the artifact; the other five match once the constructor immutables, the live registry addresses each one is wired to, are masked.
Deployed is not the same as in production use. The trust registry is still owned by the deployer key pending a transfer to the Foundation, and no issuer is accredited yet. These are application-layer contracts. They do not touch consensus, which stays classical secp256k1 ECDSA QBFT.
Precompiles: Falcon-512 0x0AE1 · Falcon-1024 0x0AE2 · ML-DSA-44 0x0AE3 · SLH-DSA-128s 0x0AE4 · SHAKE256 0x0AE5
· Verified contracts · Network status