AERE Network, Chain ID 2800

Verify quantum durability yourself

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.

Honest scope

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.

5
PQC precompiles
27
Conformance vectors
,
Verified live
,
Mismatched
,
Verified at block
Idle. The precompiles are active now, and have been since fork activationTime 1783820272 (block 9,189,161).

How this works

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.

Verify the activation yourself, and the live execution

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.

AddressGas above controlMeaning
0x04 IDENTITY18calibration, matches the EVM spec exactly
0x0AE1 Falcon-51240,000live
0x0AE2 Falcon-102475,000live
0x0AE3 ML-DSA-4455,000live
0x0AE4 SLH-DSA-128s350,000live
0x0AE5 SHAKE25660 + 12 per wordlive
0x0AE6, 0x0AE70not 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,

Provenance and honest limitations

Post-quantum transport, live on the RPC

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: X25519MLKEM768

Honest scope

This 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.

Identity and compliance stack, live on chain 2800

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.

AereRandomnessBeaconV20xaDC4…2cfDReal EIP-2537 BLS drand verify, fail-closed. Byte-identical to the artifact.
AereRecoveryRegistry0x7A0A…A1d5Falcon-attested, append-only recovery registry. Byte-identical to the artifact.
AereIdentityRegistry80040x5C65…08BaERC-8004 identity over the Falcon-rooted agent DID. Match, immutables masked.
AereValidationRegistry80040xa880…da8CERC-8004 PQC-verified validation (Falcon and ML-DSA). Match, immutables masked.
AereBitstringStatusList0x3C13…d6CBW3C status list. The zk non-revocation path is off (fail-closed) until its circuit exists. Match, immutables masked.
AereTrustRegistry0x9CF8…BbD1eIDAS-aligned trusted-issuer registry. Match, immutables masked.
AereVerifiableCredential0x2c97…530fW3C verifiable-credential anchor, binds accreditation, Falcon signature, validity and revocation, fail-closed. Match, immutables masked.

Honest scope

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