Call the Post-Quantum Precompiles Yourself

Network parameters

Everything below runs against the public read endpoint. No key material, no cost, no state change.

Two things this table deliberately leaves out. The total coin supply is not in it, because no call on this endpoint returns it, and this page does not print numbers you cannot reproduce here. And the quorum and fault bound are not RPC answers either, they are arithmetic on the size of the set the node hands you.

All ten validators are operated by the Foundation. We state that plainly rather than leaving it to be discovered. It is the honest limit on how decentralised this chain is today, and no amount of cryptography changes it. It also means the fault bound above is an assumption about one operator, not about nine independent ones.

# the validator set, straight from the chain
curl -s -X POST https://rpc.aere.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1}'

1. The one-minute proof

Start here, because this single command needs nothing but curl and settles the central question: is there really cryptographic machinery inside this chain that answers when you call it?

We are calling 0x0AE5, the SHAKE256 extendable-output hash, and asking it for 32 bytes of output over the three ASCII bytes abc.

curl -s -X POST https://rpc.aere.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
        "to":"0x0000000000000000000000000000000000000ae5",
        "data":"0x0000000000000000000000000000000000000000000000000000000000000020616263"
      },"latest"]}'

On Windows PowerShell, quoting rules differ. This form is equivalent and was tested:

$body = '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000ae5","data":"0x0000000000000000000000000000000000000000000000000000000000000020616263"},"latest"]}'
(Invoke-RestMethod -Uri https://rpc.aere.network -Method Post -ContentType 'application/json' -Body $body).result

The answer:

0x483366601360a8771c6863080cc4114d8db44530f8f1e1ee4f94ea37e78b5739

Now check it against something that has nothing to do with us. SHAKE256("abc") is one of the example messages NIST publishes for the SHA-3 extendable-output functions, and its first 32 bytes are exactly that value. Any conforming implementation gives you the same bytes, so run one you already trust:

# Python 3.6 or newer. hashlib is the standard library, nothing to install.
python3 -c "import hashlib; print(hashlib.shake_256(b'abc').hexdigest(32))"

The chain and your laptop agree. You have just verified that a standard cryptographic primitive is executing inside the node, not in a smart contract someone deployed.

2. How to read the answers

Four of the five are signature verifiers. They all behave the same way:

• They return a 32-byte word.
• 0x00...01 means the signature is valid for that public key and that message.
• 0x00...00 means anything else: bad signature, wrong key, wrong message, wrong length, garbage input. They do not revert and they do not distinguish between the reasons.

Throughout this page a returned word is written 0x00...01 or 0x00...00 so it fits in a line of prose. That is our shorthand, not the answer the node gives. The node returns all 32 bytes every time, and so does the tool in section 3, which is why the transcript in section 11 is so wide.

The fifth, SHAKE256, is different and you need to know it before you get confused:

• It returns exactly the number of bytes you asked for, not a fixed word.
• An output length of 0 returns empty (0x), not a word of zeros.
• An input shorter than 32 bytes also returns empty.
• An output length above 65536 is silently capped at 65536. It does not revert.

So for 0x0AE5, and only for it, an empty answer is a shape of input error rather than a cryptographic verdict.

The cap is the one claim in that list you cannot see by eye, so here it is as a command. Ask for 0x20000 bytes, which is 131072, and count what comes back:

curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
        "to":"0x0000000000000000000000000000000000000ae5",
        "data":"0x0000000000000000000000000000000000000000000000000000000000020000616263"
      },"latest"]}' \
  | sed 's/.*"result":"0x//;s/".*//' | tr -d '\n' | wc -c

# -> 131072 hex characters, which is 65536 bytes, not the 131072 you asked for

3. A small tool, so the large inputs are runnable

Falcon and the lattice schemes take inputs of a few thousand bytes. They will not fit on a command line. So that the big four stay reproducible rather than merely described, the conformance vectors are published as a plain file at https://aere.network/quantum-vectors.js, and this short script replays any of them.

Save it as aere-pq.js. It needs Node 18 or newer and installs nothing.

// aere-pq.js  -  call the AERE post-quantum precompiles read-only
const RPC = "https://rpc.aere.network";
const VECTORS = "https://aere.network/quantum-vectors.js";

async function call(to, data) {
  const res = await fetch(RPC, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0", id: 1, method: "eth_call",
      params: [{ to, data }, "latest"]
    })
  });
  const json = await res.json();
  if (json.error) throw new Error(JSON.stringify(json.error));
  return json.result;
}

async function loadVectors() {
  const src = await (await fetch(VECTORS)).text();
  const w = {};
  new Function("window", src)(w);
  return w.AERE_PQC_VECTORS;
}

(async () => {
  const V = await loadVectors();
  const want = process.argv[2];
  const list = want && want !== "--all"
    ? V.vectors.filter(v => v.id === want)
    : V.vectors;

  if (list.length === 0) {
    console.log("No such vector. Available ids:");
    console.log(V.vectors.map(v => "  " + v.id).join("\n"));
    return;
  }

  let pass = 0, fail = 0;
  for (const v of list) {
    const got = await call(v.address, v.input);
    const ok = got === v.expectedOutput;
    ok ? pass++ : fail++;
    console.log(
      (ok ? "OK  " : "FAIL") + "  " + v.id.padEnd(34) +
      v.precompile.padEnd(20) + ("in=" + v.inputBytes + "B").padEnd(11) +
      "out=" + got
    );
  }
  console.log("\n" + list.length + " vector(s), " + pass + " matched, " + fail + " did not.");
})();

Run one vector like this:

node aere-pq.js falcon512-valid

The file carries 27 vectors. The signature vectors are NIST known-answer and ACVP test cases, plus corrupted variants of them. Nothing in that file is secret: verifying a signature is a public operation, and it contains no private keys.

4. Falcon-512 verify

# positive: a NIST known-answer vector, 1588 bytes of input
node aere-pq.js falcon512-valid
#  -> 0x0000...0001

# negative control: one byte of the compressed signature flipped
node aere-pq.js falcon512-tampered-sig
#  -> 0x0000...0000

5. Falcon-1024 verify

# positive, 3098 bytes of input
node aere-pq.js falcon1024-valid
#  -> 0x0000...0001

# negative control
node aere-pq.js falcon1024-tampered-sig
#  -> 0x0000...0000

6. ML-DSA-44 verify

# positive: an official NIST ACVP test case, 8285 bytes of input
node aere-pq.js mldsa44-valid
#  -> 0x0000...0001

# negative control
node aere-pq.js mldsa44-tampered-sig
#  -> 0x0000...0000

7. SLH-DSA-SHA2-128s verify

# positive: an official NIST ACVP test case, 11740 bytes of input
node aere-pq.js slhdsa128s-valid
#  -> 0x0000...0001

# negative control
node aere-pq.js slhdsa128s-tampered-sig
#  -> 0x0000...0000

8. SHAKE256 extendable-output hash

curl -s -X POST https://rpc.aere.network \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
        "to":"0x0000000000000000000000000000000000000ae5",
        "data":"0x0000000000000000000000000000000000000000000000000000000000000011616263"
      },"latest"]}'

# -> 0x483366601360a8771c6863080cc4114d8d

9. What this does not mean

# native path: the same bytes you already sent in section 4,
# with the input field copied out of any -valid vector in the file
curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_estimateGas","params":[{
        "to":"0x0000000000000000000000000000000000000ae1",
        "data":"<the input field of falcon512-valid>"
      }]}'

# Solidity path: same call, but to the contract address above,
# with the arguments ABI-encoded for verify

curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x8c3729",false]}'

# timestamp 0x6a52f23a, which is 2026-07-12T01:47:38Z

10. Where it stops being a demo

Everything above is a verifier answering a question. The interesting case is an account whose authority actually depends on one.

There is an account on the live chain whose signing authority is a Falcon-512 public key, and whose authorisation path runs through the precompile at 0x0AE1, the one you called in section 4. That is not a sentence you have to believe: the call to 0x0AE1 is in the deployed bytecode, and the checks below put it in front of you.

Read its state yourself. Address 0x5fe732AFaB5F64e01451a2EA6085cA84a9a25733:

# pqcScheme() -> 1, meaning Falcon-512
curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x5fe732AFaB5F64e01451a2EA6085cA84a9a25733","data":"0x537305d4"},"latest"]}'

# precompileAddress() -> 0x...0ae1, the Falcon-512 precompile from section 4
curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x5fe732AFaB5F64e01451a2EA6085cA84a9a25733","data":"0xbe47b676"},"latest"]}'

# pqcPubKey() -> length 0x381 = 897 bytes, first byte 0x09: a Falcon-512 key
curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x5fe732AFaB5F64e01451a2EA6085cA84a9a25733","data":"0xb57d65aa"},"latest"]}'

The key length and header byte line up with the Falcon-512 layout in section 4, and the account names the same precompile you called yourself. Now go past what the account says about itself and read what it is made of:

curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x5fe732AFaB5F64e01451a2EA6085cA84a9a25733","latest"]}' \
  > code.json

# the two precompiles, as PUSH2 operands: 0x0ae1 Falcon-512, 0x0ae5 SHAKE256
grep -c 610ae1 code.json ; grep -c 610ae5 code.json

# ERC-4337: v0.7 validateUserOp present, v0.6 absent, EIP-1271 present
grep -c 19822f7c code.json ; grep -c 3a871cdd code.json ; grep -c 1626ba7e code.json

# -> 1  1  /  1  0  1

So the Falcon precompile address is compiled into the account, not merely reported by a getter that could return anything. The v0.7 validateUserOp selector is present and the v0.6 one is absent, which is how you place it as an ERC-4337 v0.7 account without trusting this page. Its EntryPoint is readable in the same style as the three reads above, with selector 0xb0d691fe.

11. Verify it yourself

One command replays every published vector, all five precompiles, positive and negative cases together, against the live chain:

node aere-pq.js --all

When this page was last measured, on 2026-08-10, that produced 27 vectors, 27 matched, 0 did not. Here is the tail of that run, pasted from the terminal without editing. The lines are wide because the tool prints all 32 bytes of every answer rather than an abbreviation, so scroll sideways:

OK    slhdsa128s-malformed-short        SLH-DSA-SHA2-128s   in=2B      out=0x0000000000000000000000000000000000000000000000000000000000000000
OK    shake256-abc-32                   SHAKE256            in=35B     out=0x483366601360a8771c6863080cc4114d8db44530f8f1e1ee4f94ea37e78b5739
OK    shake256-empty-32                 SHAKE256            in=32B     out=0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762f
OK    shake256-abc-64                   SHAKE256            in=35B     out=0x483366601360a8771c6863080cc4114d8db44530f8f1e1ee4f94ea37e78b5739d5a15bef186a5386c75744c0527e1faa9f8726e462a12a4feb06bd8801e751e4
OK    shake256-abc-17                   SHAKE256            in=35B     out=0x483366601360a8771c6863080cc4114d8d
OK    shake256-multiblock-32            SHAKE256            in=1032B   out=0x7ea3adcc3e3b46adcdc481d1309cf131c8703d484e33dcb78d13363324e2972d
OK    shake256-outlen0-empty-return     SHAKE256            in=35B     out=0x
OK    shake256-malformed-short          SHAKE256            in=4B      out=0x

27 vector(s), 27 matched, 0 did not.

The shake256-abc-64 line is worth a second look on its own: its first 32 bytes are the same value as shake256-abc-32, and its first 17 are the same as shake256-abc-17. One input, three lengths, one stream.

Confirm you were talking to the chain you think you were:

# chain id, expect 0xaf0 = 2800
curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# current height, a moving number
curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

The height is a snapshot, not a constant: at 2026-08-10T11:02:29Z it was 0xc994bc, which is 13,210,812. It advances continuously, so yours will be higher. If it is not, something is wrong and that in itself is worth reporting.

A snapshot in a document is normally something you have to take on trust, but this one is not. Ask the chain when that block was produced, and the timestamp should be the instant printed above:

curl -s -X POST https://rpc.aere.network -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0xc994bc",false]}'

# timestamp 0x6a79afc5, which is 2026-08-10T11:02:29Z

Run the same commands against https://rpc2.aere.network and compare. Identical answers from two endpoints tell you the responses are not being made up per connection. As stated in section 9, they do not tell you two independent implementations agree, because both endpoints run the same client.