{
  "schema": "aere-verifiable-claims/1",
  "title": "Aere Network machine-verifiable claim layer",
  "canonicalUrl": "https://aere.network/verifiable-claims.json",
  "generatedAt": "2026-09-10",
  "generator": "Generated from measurement, not written by hand. Every number in this file was read from the live public endpoints during the run that produced it. The generator refuses to write anything at all if any check failed to run, if any of its positive and negative controls did not behave, if it would publish fewer claims than the previous revision, if the finished file contradicts its own measurements, if it would state a range drawn from too thin a sample or a narrower range than one already published, if a neighbouring public file disagrees with it about the validator count and the file does not say so, or if a single word of the generator's own working language leaks into this English document. Revision 2 of this file was written by hand and aged in silence: it stated a validator count and a quorum that had stopped being true, in eight places, including inside its own list of the fastest ways to refute it.",
  "staleAfter": "2026-09-17",
  "howToTellIfThisFileIsStale": "Compare `measuredAtBlock` against the current head. If the gap is large, or if today is past `staleAfter`, treat every number here as unverified until you rerun the checks yourself. That is what the `verify` blocks are for. And know the weakness: no scheduled rebuild of this file is known to exist. It is rebuilt when a person runs the generator, so the failure that produced the previous revision, a file aging in silence, is reduced and not removed. Until a rebuild happens on a clock, `staleAfter` is the only protection and it is a weak one. Trust `measuredAtBlock` against the live head over any date written in this file.",
  "chainId": 2800,
  "chainIdHex": "0xaf0",
  "measuredAtBlock": 17965699,
  "readThisFirst": [
    "Every claim in the `claims` array below was executed against the live public endpoints on the date in its `lastMeasured` field, before this file was written. Nothing here is asserted from documentation or memory.",
    "Each claim carries `proves` and `doesNotProve`. The second field is the load-bearing one. A claim whose limits are not stated is marketing, not evidence.",
    "`notClaimed` lists what Aere does NOT assert, with the measurement or public fact that forces the restraint. Read it before believing anything above it.",
    "This file is designed to be run, not read. Copy any `verify.body` into any JSON-RPC client and compare against `verify.expect`. No wallet, no key, no gas, no account, no permission from us."
  ],
  "transport": {
    "endpoints": [
      "https://rpc.aere.network",
      "https://rpc2.aere.network"
    ],
    "note": "Both endpoints answered every CHAIN-DATA check in this file identically. They are two public read endpoints operated by the Aere Foundation; they are NOT independent parties and must not be read as a second opinion. They do not expose an identical method set either: see `second-read-endpoint`. And because QBFT committed seals are assembled locally by each node and are not covered by the block hash, the two can return the identical block hash for a block while the raw extraData bytes differ.",
    "knownObstacle": "Measured 2026-09-10, fetching this very file with five different User-Agent headers: Python-urllib/3.14 -> 403; python-requests/2.31.0 -> 200; curl/8.5.0 -> 200; Go-http-client/1.1 -> 200; (no User-Agent header) -> 200. So the CDN does refuse at least 1 default scripting User-Agent. If you script these checks and get a 403, set any other User-Agent header; the failure has nothing to do with the chain. This sentence is dated and reproducible on purpose: a previous draft downgraded it to \"has been observed\", with no date and no figures, which is a measurement quietly demoted to a memory.",
    "unknownPathsSoft404": "Measured 2026-09-10, and the answer DEPENDS ON THE SHAPE OF THE PATH, so a status code alone proves nothing here: /no-such-file-5208 (no extension) -> 200, 50,833 bytes; /no-such-file-5208.html (.html) -> 200, 50,833 bytes; /no-such-file-5208.json (.json) -> 404, 153 bytes; /no-such-file-5208.txt (.txt) -> 404, 153 bytes; /a/b/no-such-file-5208 (nested, no extension) -> 200, 50,833 bytes. Paths that answer 200 return a client-side application shell of about 50,833 bytes, the same body the site serves for its own pages. An earlier revision probed only one shape, the one that happens to answer 404, and then wrote a sentence about \"any path\". Check `content-type: application/json` and that the body parses before believing a path exists."
  },
  "claims": [
    {
      "id": "chain-identity",
      "claim": "A public blockchain answers at rpc.aere.network with chain ID 2800 and reports itself as a Hyperledger Besu node.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "headers": {
          "content-type": "application/json"
        },
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_chainId",
          "params": [],
          "id": 1
        },
        "expect": {
          "result": "0xaf0"
        },
        "alsoRun": [
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "net_version",
              "params": [],
              "id": 1
            },
            "expect": {
              "result": "2800"
            }
          },
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "web3_clientVersion",
              "params": [],
              "id": 1
            },
            "expectContains": "besu/"
          },
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_syncing",
              "params": [],
              "id": 1
            },
            "expect": {
              "result": false
            }
          }
        ],
        "measured": {
          "clientVersion": "besu/v26.4.0-aere.1-d203201-wt18160dde/linux-x86_64/openjdk-java-25",
          "identicalOnBothEndpoints": true
        }
      },
      "proves": "An EVM JSON-RPC endpoint exists, is reachable, self-reports chain ID 2800, and is not syncing.",
      "doesNotProve": "Nothing about decentralization, security, or who controls the node. A single machine can answer all of this.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "block-interval",
      "claim": "The mean interval between blocks over the most recent 100,000 blocks is 0.592 seconds.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "procedure": "Fetch the latest block header and the header 100,000 blocks earlier, then divide the timestamp difference by 100,000.",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getBlockByNumber",
          "params": [
            "latest",
            false
          ],
          "id": 1
        },
        "then": {
          "jsonrpc": "2.0",
          "method": "eth_getBlockByNumber",
          "params": [
            "<latest minus 100000, hex>",
            false
          ],
          "id": 1
        },
        "expect": "(t_latest - t_older) / 100000 is between 0.56 and 0.63",
        "measured": {
          "window_1000_blocks": "1,071 s total, 1.0710 s per block",
          "window_100000_blocks": "59,189 s total, 0.5919 s per block",
          "window_1000000_blocks": "594,660 s total, 0.5947 s per block",
          "measuredAtHead": "17,965,681 — this is the head this particular measurement used. The file-level `measuredAtBlock` is the head read at the END of the run, a few blocks later, because the chain moves while the file is being built. Two different numbers in one file for one run is not a contradiction, but it does need saying, and until today it was not said."
        },
        "theseBlocksAreEmpty": "Measured 2026-09-10 over 1,024 CONSECUTIVE headers, not a stride sample: 1,014 were empty (99.02%) and the whole window carried 10 transactions and 224,740 gas, against a per-block gas limit of 9,007,199,254,740,991. Producing near-empty blocks on a sub-second timer is cheap. Read this number as a heartbeat, not as performance.",
        "whyConsecutiveAndNotSampled": "The stride sample this file used in earlier revisions undercounts sparse traffic badly. Measured on the same window: sampling 128 headers at a fixed stride finds 2 of the 10 transactions actually present. Scan, do not sample."
      },
      "proves": "Block headers are produced at roughly 0.59-second intervals, sustained over a 100,000-block window.",
      "doesNotProve": "Nothing about throughput and nothing about behaviour under load. 99.02% of the sampled blocks are EMPTY. This measures a timer, not a system doing work. It is also not a finality guarantee under adversarial conditions. The 1,000,000-block window is a different number from the 100,000-block window because it reaches further back across a period of DEGRADED OPERATION; both are reported above so you can see the spread rather than the flattering one. An earlier draft of this file called that \"periods of different operating quality\", which is a euphemism for the same fact and is not how this file is allowed to talk.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "qbft-validator-set-from-header",
      "claim": "The QBFT validator set is 9 addresses, and each block header carries 6 committed seals of 65 bytes, which is the 6-of-9 quorum. The set and the seal count are readable from any block header without trusting any Aere-published document.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getBlockByNumber",
          "params": [
            "latest",
            false
          ],
          "id": 1
        },
        "procedure": "RLP-decode the `extraData` field of the returned header. It is a QBFT list of AT LEAST 5 items: [vanityData(32 bytes), validators(list of 20-byte addresses), vote, round, committedSeals(list of 65-byte signatures)]. Count item 1 and item 4. Do NOT require the list to have exactly five items: some headers carry a sixth, and a decoder that insists on five will throw on those. A decoder that reads the first five and ignores any remainder works on every header. See `pq-certificate-under-block-hash`.",
        "expect": {
          "validators_count": 9,
          "committedSeals_count": 6,
          "each_seal_bytes": 65
        },
        "quorumIsDerivedNotAsserted": "The quorum is not a number we typed. It is ceil(2n/3) for n=9, which is 6, and this generator refuses to publish the file unless that formula reproduces the seal count actually counted in the headers. On 2026-09-10 it did, on 1,024 of 1,024 consecutive headers.",
        "measuredValidatorSet": [
          "0x1bd5514286f5602a6762b0075266379d29af1c9d",
          "0x4bf6f91d84b37454544279cba152581ed6820044",
          "0x5f50fc4e1b129bbd5e6e9f80c57680b0b4a86eb0",
          "0x97473985d04723299559f49b856effb47d7abfad",
          "0xb5e768cb3117ea25175f51aa956b48691025c2a8",
          "0xc3314fd768bb68b986e80c0a14175f6f72630d7a",
          "0xdf09b32c761620c5be77da398b97a64f03c3980c",
          "0xe13aa491abbc1252dd714e7ca0e55717a2143eaf",
          "0xf73bbbd26a82dbc769066550d8d4585eab2fc00d"
        ],
        "sampledEvidence": "1,024 CONSECUTIVE headers, measured 2026-09-10: every one carried exactly 6 committed seals of 65 bytes each, every one carried the identical 9-address validator set above, and block production rotated across all 8 of them (128 to 128 blocks each), which is the QBFT round-robin.",
        "note": "The JSON-RPC method `qbft_getValidatorsByChainHead` is NOT exposed on the public endpoints (it returns -32601 Method not found). `qbft_getValidatorsByBlockNumber` IS exposed and returns the same 9 addresses on both endpoints, but that is a node describing itself. The header decode above is strictly better and is what this claim rests on: it reads consensus data out of the signed block.",
        "oneCaveatAboutSeals": "Committed seals are assembled locally by each node and are NOT covered by the block hash. Two endpoints can therefore return the identical block hash for a block while the raw extraData bytes differ. The seal set you read is the one your endpoint happened to assemble, not a canonical fact about that block. The validator list is different: it IS under the hash, and this file proves that separately."
      },
      "proves": "Exactly 9 validators are encoded in the header, 6 distinct 65-byte committed seals accompany each block, and block production rotates across all 9. The quorum is therefore observable, not asserted.",
      "doesNotProve": "Does NOT prove the 9 keys are held by 9 independent parties. They are all operated by the Aere Foundation, so the effective Nakamoto coefficient is 1, not 9. It also does not prove f=2; f = floor((n-1)/3) = 2 is arithmetic implied by n=9, not a separate measurement. It does not verify the seal signatures themselves; to do that, recover the signers with ecrecover over the QBFT commit payload and check they are members of the set above.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "pq-certificate-under-block-hash",
      "claim": "Some block headers on chain 2800 carry a certificate of validator signatures that Aere states are post-quantum, and the block hash commits to that certificate through a 32-byte digest you can recompute yourself from the header alone. The binding is what is claimed here. The algorithm, and even the category, are NOT: see `doesNotProve`.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getBlockByNumber",
          "params": [
            "0x1122270",
            false
          ],
          "id": 1
        },
        "whyAFixedHeightAndNotLatest": "Headers carrying this material are a minority: measured 2026-09-10, 8 of 1,024 consecutive headers carried it, so a recipe pointed at `latest` is not evaluable on most tries. Block 17,965,680 above is one that does carry it, verified during this run. To find your own, use `howToFindOneWithoutOurHelp` below; do not take ours on trust.",
        "procedure": "Step 1. RLP-decode extraData. Most headers decode to five items. Some decode to SIX. On those, item[0] (vanityData) is a 32-byte digest instead of the usual client version string and item[5] is the certificate. Two shapes of certificate exist on this chain. The earlier shape is a list of [validatorIndex, signature] pairs (Falcon-512). The hybrid shape, the one in use at the time of this run, is [2, [[scheme, validatorIndex, signature], ...]] where scheme 1 is Falcon-512 and scheme 2 is SLH-DSA-SHA2-128s. Block 17,965,680 above carries the hybrid shape. Step 2. Recompute the digest. For the pair shape: D = keccak256( RLP[ \"AERE-PQ-ANCHOR-1\", chainId, parentNumber, parentHash, C ] ) where C is item[5] exactly as decoded. For the hybrid shape: D = keccak256( RLP[ \"AERE-PQ-ANCHOR-2\", chainId, parentNumber, parentHash, BYTES ] ) where BYTES is the RLP encoding of item[5], carried as ONE byte string. In both, chainId is 2800, parentNumber is the header number minus one and parentHash is the parentHash field of the same header. Compare D against item[0]. They are equal. Step 3. Show the digest is under the block hash. Re-encode extraData as FIVE items only: [vanityData, validators, vote, round encoded as the empty byte string (0x80), committed seals as the empty list (0xc0)]. Note what this step does: it DROPS item[5]. Take keccak256 of the header RLP with that extraData and it equals the blockHash the chain reports. Now flip one bit of vanityData and repeat: the hash moves. vanityData is inside the hashed preimage, so the digest is inside it. Step 4. Now do the step that limits the claim, because it is the one an adversary would do. Put a DIFFERENT certificate into item[5], of the same shape, and recompute the block hash exactly as in step 3. It does not move. Remove item[5] entirely and recompute: it still does not move. The certificate bytes are outside the preimage; only their 32-byte digest, sitting in item[0], is inside it. That is the whole of the binding, and it is why the honest word for a swapped certificate is DETECTABLE, not invalid.",
        "expect": {
          "digestEqualsVanityData": true,
          "recomputedBlockHashEqualsReportedBlockHash": true,
          "flippingOneBitOfVanityDataChangesTheBlockHash": true,
          "substitutingTheCertificateLeavesTheBlockHashUnchanged": true,
          "removingTheCertificateLeavesTheBlockHashUnchanged": true
        },
        "whatIsHashedAndWhatIsNot": "The block hash is computed from a RE-ENCODING of decoded extraData, so anything the decoder discards is discarded before hashing. item[5], the certificate itself, is NOT part of the hashed preimage. Its 32-byte digest in item[0] is. Measured 2026-09-10 on block 17,965,680: the reported hash is 0x0f45f3dc884d5626d1f828a46ac85beefc8264d827f8e50966f65e19092c5f19, and after replacing the certificate with same-shaped junk the recomputed hash is 0x0f45f3dc884d5626d1f828a46ac85beefc8264d827f8e50966f65e19092c5f19. Those are the same value.",
        "measured": {
          "consecutiveHeadersScanned": 1024,
          "carryingHeadersInThatConsecutiveWindow": 8,
          "carryingHeadersMeasuredInTotal": 400,
          "windowOfCarryingHeaders": "blocks 17,914,608 to 17,965,680",
          "digestReproducedLocally": "400 of 400",
          "signaturesPerCertificate": "OBSERVED 6 to 9 distinct validators per certificate over 400 carrying headers in the window above, distribution {\"6\":2,\"7\":6,\"8\":46,\"9\":346}. These are observed extremes in a named window, NOT bounds: nodes attach whatever arrives in time, so a wider scan can find more. An earlier revision published a narrower range taken from a few dozen headers and three independent readers broke it on their first scan. In the hybrid shape every validator contributes two signatures, one per scheme, so signature positions are twice the validator count; signatures per scheme over the window: [[1,3536],[2,3536]] as [scheme, count], and signature bytes per scheme [[1,648,663],[2,7856,7856]] as [scheme, min, max].",
          "certificatesBelowFPlusOne": "0 of 400 (0.0%) carried fewer than f+1 = 3 distinct validators, and 0 of 400 carried fewer than the 6-of-9 quorum. In this window no certificate fell below f+1 or below the quorum; that is a measurement of the window, not a rule.",
          "signatureBytes": "observed 648 to 7856 over 7,072 signatures, i.e. variable-length. Observed extremes, not bounds.",
          "extraDataBytes": "ordinary headers 634, carrying headers up to 77407 in the measured window. Also an observed maximum, not a limit.",
          "validatorIndicesObserved": "0, 1, 2, 3, 4, 5, 6, 7, 8 only, across 7,072 signature positions. Every member of the set was observed at least once.",
          "everyValidatorIndexIsInsideTheSet": true,
          "whyThatBooleanIsWeakerThanItLooks": "It only says no index falls outside 0..8. It does NOT say which address an index refers to: the mapping from index to validator is not published and cannot be derived from the header, so an outsider cannot check it. The line above it, the list of indices actually observed, is the one that carries information."
        },
        "negativeControls": "Each of these was run and each one fires, which is what makes the positive result mean anything. Flip one bit inside any signature: the digest changes. Drop one signature from the certificate: the digest changes. Use the wrong parent number, or the wrong chain id: the digest changes. Re-encode the header with the committed seals included instead of emptied: the recomputed block hash stops matching. Re-encode it with the certificate KEPT as a sixth item: the recomputed block hash stops matching too, which is the direct proof that neither the ECDSA seals nor the certificate are under the hash, while vanityData is.",
        "howToFindOneWithoutOurHelp": "Do not sample at a fixed stride. Fetch a few hundred CONSECUTIVE headers and count the ones whose extraData list has more than five items. A stride that does not divide the interval finds none of them, and that is exactly how earlier revisions of this file missed their existence entirely."
      },
      "proves": "A 32-byte digest that commits to the certificate is inside the preimage of the block hash on the live chain. Changing the certificate changes the digest, so a substituted certificate no longer matches the digest carried in the header, and any reader who recomputes it sees that immediately. The property is DETECTION by anyone with two RPC calls and a keccak implementation, using no Aere software.",
      "doesNotProve": "It does NOT prove a swapped certificate makes the block invalid, and an earlier revision of this file said exactly that. Measured 2026-09-10 on block 17,965,680: replacing the certificate with same-shaped junk, and removing it entirely, both leave the block hash unchanged, because step 3 of the procedure above drops item[5] before hashing. Whether a node REJECTS such a header is not established by any measurement in this file, and the next sentence says the material does not decide validity at all. This is a binding, not a security guarantee, and the difference is the whole of it. It does NOT prove the signature blobs are valid post-quantum signatures, and it does not even prove they are post-quantum: Aere does not publish the validators' post-quantum public keys anywhere a stranger can read, so nobody outside Aere can verify a single one of them, and the category rests on our statement plus blob sizes consistent with a compressed lattice signature. This file does not name the algorithm, because naming it would be asserting more than was measured; the same restraint has to apply to the words \"post-quantum\", and where this file uses them about header material it is repeating an Aere claim, not a measurement. It does NOT prove consensus depends on them: a header is accepted on its 65-byte secp256k1 seals, and the post-quantum material does not decide validity. Whether it is a quorum is measured here, not asserted: over 400 carrying headers, certificates carried 6 to 9 distinct validators out of 9, 0.0% of them carried fewer than f+1 = 3 and 0.0% carried fewer than the 6-of-9 quorum, so in this window every certificate reached the quorum; that is a measurement of the window, not a rule.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "pqc-precompiles-declared",
      "claim": "The node declares 5 Aere post-quantum precompiles at addresses 0x0AE1 through 0x0AE5, and does not declare 0x0AE6 or 0x0AE7.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_config",
          "params": [],
          "id": 1
        },
        "expect": {
          "result.current.chainId": "0xaf0",
          "result.current.activationTime": 1783820272,
          "result.current.forkId": "0xce69e400",
          "result.current.precompiles.AereFalcon1024": "0x0000000000000000000000000000000000000ae2",
          "result.current.precompiles.AereFalcon512": "0x0000000000000000000000000000000000000ae1",
          "result.current.precompiles.AereMLDSA44": "0x0000000000000000000000000000000000000ae3",
          "result.current.precompiles.AereSHAKE256": "0x0000000000000000000000000000000000000ae5",
          "result.current.precompiles.AereSLHDSA128s": "0x0000000000000000000000000000000000000ae4",
          "absent": [
            "AereMLKEM (0x0AE6)",
            "AereHashToPoint (0x0AE7)"
          ]
        },
        "measured": {
          "totalPrecompileEntries": 23,
          "aereEntries": 5,
          "entriesAt0x0AE6or0x0AE7": 0,
          "namesMatchingMLKEMorHashToPoint": 0,
          "nextForkScheduled": false,
          "lastForkRecorded": false,
          "identicalOnBothEndpoints": true
        }
      },
      "proves": "The running client declares these precompiles as part of the active fork configuration.",
      "doesNotProve": "A declaration is a node describing itself. It does not prove the code executes. That is proved separately by `pqc-precompiles-execute` below, which does not trust this answer.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "shake256-nist-kat",
      "claim": "The precompile at 0x0AE5 computes SHAKE256, checked against locally computed digests across varying messages and varying output lengths.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_call",
          "params": [
            {
              "to": "0x0000000000000000000000000000000000000AE5",
              "data": "0x0000000000000000000000000000000000000000000000000000000000000020"
            },
            "latest"
          ],
          "id": 1
        },
        "expect": {
          "result": "0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762f"
        },
        "independentControl": "Compute the same value locally with any SHAKE256 implementation and compare. In Python: `hashlib.shake_256(b'').hexdigest(32)`. The point of the control is that the expected answer is fixed by NIST, not by us, so we cannot have chosen it to fit.",
        "inputEncoding": "The call data is the requested output length as a 32-byte big-endian integer, followed by the message bytes. Without that sentence four of the five cases below are described in prose and cannot be run, which is what an earlier revision shipped; every request is now given in full so nothing has to be guessed.",
        "alsoRun": [
          {
            "case": "empty message, 32-byte output",
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x0000000000000000000000000000000000000ae5",
                  "data": "0x0000000000000000000000000000000000000000000000000000000000000020"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": {
              "result": "0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762f"
            }
          },
          {
            "case": "empty message, 64-byte output",
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x0000000000000000000000000000000000000ae5",
                  "data": "0x0000000000000000000000000000000000000000000000000000000000000040"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": {
              "result": "0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762fd75dc4ddd8c0f200cb05019d67b592f6fc821c49479ab48640292eacb3b7c4be"
            }
          },
          {
            "case": "empty message, 17-byte output",
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x0000000000000000000000000000000000000ae5",
                  "data": "0x0000000000000000000000000000000000000000000000000000000000000011"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": {
              "result": "0x46b9dd2b0ba88d13233b3feb743eeb243f"
            }
          },
          {
            "case": "\"abc\", 32-byte output",
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x0000000000000000000000000000000000000ae5",
                  "data": "0x0000000000000000000000000000000000000000000000000000000000000020616263"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": {
              "result": "0x483366601360a8771c6863080cc4114d8db44530f8f1e1ee4f94ea37e78b5739"
            }
          },
          {
            "case": "\"Aere\", 32-byte output",
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x0000000000000000000000000000000000000ae5",
                  "data": "0x000000000000000000000000000000000000000000000000000000000000002041657265"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": {
              "result": "0x673aae3ac6ee30aaa45f6c2bd26a9f7dff84fe1e196a460ceb71468463397771"
            }
          }
        ],
        "variableInputControl": "A single fixed known-answer test cannot distinguish a correct implementation from an address that returns one hardcoded constant, so the input was varied in BOTH dimensions and every answer compared against a locally computed one. Measured 2026-09-10 on both endpoints: empty message, 32-byte output -> 0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762f; empty message, 64-byte output -> 0x46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762fd75dc4ddd8c0f200cb05019d67b592f6fc821c49479ab48640292eacb3b7c4be; empty message, 17-byte output -> 0x46b9dd2b0ba88d13233b3feb743eeb243f; \"abc\", 32-byte output -> 0x483366601360a8771c6863080cc4114d8db44530f8f1e1ee4f94ea37e78b5739; \"Aere\", 32-byte output -> 0x673aae3ac6ee30aaa45f6c2bd26a9f7dff84fe1e196a460ceb71468463397771. All 5 agree byte for byte with a local SHAKE256. A constant-returning stub would fail 4 of the 5.",
        "bothEndpoints": "rpc.aere.network and rpc2.aere.network returned identical values for all 5 inputs."
      },
      "proves": "0x0AE5 computes SHAKE256 correctly, and tracks both the message and the requested output length, against answers fixed by NIST that Aere did not choose and cannot influence.",
      "doesNotProve": "SHAKE256 is a hash function, not a signature scheme, and it is not post-quantum cryptography by itself. It is the extendable-output function the lattice and hash-based schemes are built on. This proves one primitive is correct; it says nothing about the signature verifiers.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "pqc-precompiles-execute",
      "claim": "The post-quantum precompiles consume gas, which is positive proof that code executes at those addresses rather than the addresses merely being empty.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "procedure": "Install a small gas-measuring probe at an unused address with an eth_call state override and read the gas consumed by one STATICCALL to the target. No deployment, no wallet, no gas paid. The program is: GAS; STATICCALL(gas=0x0f4240, target, args 0..32, ret 0..32); POP; GAS; SWAP1; SUB; PUSH1 0; MSTORE; RETURN 32.",
        "body": {
          "jsonrpc": "2.0",
          "id": 1,
          "method": "eth_call",
          "params": [
            {
              "to": "0x000000000000000000000000000000000000b0b0",
              "data": "0x3333333333333333333333333333333333333333333333333333333333333333",
              "gas": "0x1c9c380"
            },
            "latest",
            {
              "0x000000000000000000000000000000000000b0b0": {
                "code": "0x5a6020600060206000730000000000000000000000000000000000000ae1620f4240fa505a900360005260206000f3"
              }
            }
          ]
        },
        "probeCode": "0x5a6020600060206000731111111111111111111111111111111111111111620f4240fa505a900360005260206000f3  -- substitute the 20-byte target address. There is exactly ONE address literal in this program, and the `body` above is generated from this same template, so the shipped request and the described program cannot disagree and there is nothing to substitute twice.",
        "calibrateFirst": "Point the same probe at precompiles whose cost is fixed by specification and not by Aere. Measured 2026-09-10: IDENTITY 0x04 reads 143 raw, SHA256 0x02 reads 197, ECRECOVER 0x01 reads 3125, P256VERIFY 0x100 reads 7025. Those four are addresses the probe has already touched, so you subtract the WARM overhead, 125, and you get 18, 72, 3000 and 6900, exactly the four specification constants.",
        "twoRegimesAndTheyAreNotInterchangeable": "This is the sentence an earlier revision left out, and leaving it out put every Aere row off by 2500. The rows above are read against the WARM control (125). Every 0x0AEx row below is read against the COLD control (2625), because those addresses are cold when the probe reaches them. Apply one number uniformly and you will overstate each Aere row by 2500 gas. The difference between the two controls is not an Aere quantity either: 2625 - 125 = 2500, which is the EIP-2929 cold-versus-warm account access delta (2600 - 100), and this generator refuses to publish if it comes out as anything else. So both regimes are anchored to constants Aere does not control.",
        "negativeControl": "Retarget the same probe at 0x..dead, an address with no code: 2625 raw, 0 above control. The probe therefore reads zero where it should.",
        "measured": {
          "probeOverhead_warmPrecompile": 125,
          "probeOverhead_coldAddress": 2625,
          "control_codeless_0xdead": {
            "rawGas": 2625,
            "aboveControl": 0
          },
          "0x0AE1": {
            "rawGas": 42625,
            "aboveControl": 40000
          },
          "0x0AE2": {
            "rawGas": 77625,
            "aboveControl": 75000
          },
          "0x0AE3": {
            "rawGas": 57625,
            "aboveControl": 55000
          },
          "0x0AE4": {
            "rawGas": 352625,
            "aboveControl": 350000
          },
          "0x0AE5": {
            "rawGas": 2685,
            "aboveControl": 60,
            "note": "cost scales with requested output length, so this is the price for this specific 32-byte probe input, not a fixed per-call price"
          },
          "0x0AE6": {
            "rawGas": 2625,
            "aboveControl": 0
          },
          "0x0AE7": {
            "rawGas": 2625,
            "aboveControl": 0
          },
          "0x100_P256VERIFY": {
            "rawGas": 7025,
            "aboveControl": 6900
          },
          "readThis": "Raw figures include the probe's own overhead, which differs between an already-warm precompile address (125) and any cold address (2625). Compare a target only against a control of the same warmth. That is why the codeless control for 0x0AE6 is 0x..dead and not 0x04."
        },
        "bothEndpoints": "Every figure above was identical on rpc.aere.network and rpc2.aere.network.",
        "absenceArgument": {
          "weakForm": "0x0AE6 and 0x0AE7 consume 0 gas above a codeless control.",
          "whyThatIsNotProof": "Zero above control is CONSISTENT with absence, but a hypothetical precompile that charged nothing would read identically. A cost measurement cannot prove a negative, and this file does not pretend it can.",
          "strongForm": "eth_config is the node enumerating its own active precompile set. Measured 2026-09-10 it returns 23 entries, of which exactly 5 are Aere entries, and there is no entry at 0x0AE6 or at 0x0AE7 and no entry name matching MLKEM or HashToPoint.",
          "residualHonesty": "eth_config is still the node describing itself. Absence is asserted from a self-report that agrees with a cost measurement, which is the strongest statement available over a read-only interface. It is weaker than the positive claims in this file and it is labelled weaker on purpose."
        }
      },
      "proves": "Code executes at 0x0AE1 through 0x0AE5 on the live chain, at costs measured against four constants Aere does not control.",
      "doesNotProve": "Gas consumption proves execution, not correctness: it does not show the verifiers accept valid signatures and reject invalid ones. It also does NOT prove 0x0AE6 and 0x0AE7 are absent, only that they cost nothing. See absenceArgument.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "pqc-historical-receipts",
      "claim": "8 distinct transactions named in Aere's own published evidence files are recorded on chain 2800 with receipt status success, at the block and gas figures listed below.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getTransactionReceipt",
          "params": [
            "0x3a1838deb9f1b4b26f7af5ef1b4609a8aea77a3ebe654e38151caeadfff4fd5c"
          ],
          "id": 1
        },
        "expect": {
          "result.status": "0x1",
          "result.blockNumber": "0x8549e5",
          "result.gasUsed": "0xa01a27"
        },
        "howTheCountIsObtained": "The number above is COUNTED, not asserted. It is the size of the union of the transactions named in this file and the transactions named in https://aere.network/claim-evidence.json, de-duplicated by hash. Measured 2026-09-10: that evidence file names 8 transactions, this file names 2, 2 appear in both, and the union is 8. Count them yourself in the other file before believing this line: an earlier revision said that file named 7, because the collector only looked at one key path and missed a transaction filed under a different one. The total came out right by luck, in the one sentence whose entire purpose is to show the number was counted. The collector now takes every `txHash` at any depth. If a further transaction exists but is published nowhere, then for a file whose whole argument is public verifiability it does not exist.",
        "allOfThem": [
          {
            "tx": "0x3a1838deb9f1b4b26f7af5ef1b4609a8aea77a3ebe654e38151caeadfff4fd5c",
            "to": "0x4e8e9682329e646784fb3bd01430aa4ba54d8ffc",
            "toIsAPublishedAereContract": "AereFalcon512Verifier",
            "block": 8735205,
            "gasUsed": 10492455,
            "status": "0x1"
          },
          {
            "tx": "0xcd1350372f0a61e26e8a3228da599be9211839f378eef0ea49f2025a20920660",
            "to": "0x465d9e3b476bf98aa1393079e240db5d2a9bea6a",
            "toIsAPublishedAereContract": "AerePQCAttestation",
            "block": 9200532,
            "gasUsed": 1386367,
            "status": "0x1"
          },
          {
            "tx": "0xe3fcce571cca808530ef655628cecae7ace900e42f7f3007b6300d87cb129214",
            "to": "0xf3681aa6444f79562683c26f9d5c369a479c87dd",
            "toIsAPublishedAereContract": null,
            "block": 8819084,
            "gasUsed": 10072348,
            "status": "0x1"
          },
          {
            "tx": "0xf84f179f54dd0b4d85abcdba5f1fdb1d6be7573a262b26ef2a3e423f9de80a8f",
            "to": "0xf1bf15d5018a35d21fbb4ec868f062df7c06783c",
            "toIsAPublishedAereContract": null,
            "block": 8741876,
            "gasUsed": 28628,
            "status": "0x1"
          },
          {
            "tx": "0x0dead975e1fba323dbd140279a4fcd12300004753d57f0b57169caeea806207e",
            "to": "0x3a097a459fd26ac79573acb5adb51430e473c2f1",
            "toIsAPublishedAereContract": null,
            "block": 8434909,
            "gasUsed": 303140,
            "status": "0x1"
          },
          {
            "tx": "0x12f8b275d10442195474c289317e1feb5786ed176a033840b26be7aea11ca825",
            "to": "0x8c1a48efa57b66fee743a00e3899c29ad3fd27b4",
            "toIsAPublishedAereContract": null,
            "block": 8941601,
            "gasUsed": 69663,
            "status": "0x1"
          },
          {
            "tx": "0xc606be93490b9944b16c6f1743fd9ed3de046765831d84ec904fdd95a5102903",
            "to": "0xcada54fab6e7ae311d240cf0c2df45e974156488",
            "toIsAPublishedAereContract": null,
            "block": 9991732,
            "gasUsed": 313462,
            "status": "0x1"
          },
          {
            "tx": "0xc27f09365e9bbeb37225bc42d1fc194228326f57352d1c8842159fb7f5a62b2b",
            "to": "0x08b68bd553116dffb99e648cb764aa93930da96f",
            "toIsAPublishedAereContract": null,
            "block": 10074980,
            "gasUsed": 471507,
            "status": "0x1"
          }
        ],
        "whatTheDestinationsShow": "Measured 2026-09-10: of the 8 transactions, 2 were sent to a contract this file publishes by name and the rest went to addresses this file does not identify. That is why the claim above says only that they are named in our evidence and succeeded. Any stronger statement about what they exercised would be one you cannot check.",
        "allRerunToday": "8 of 8 returned status 0x1 on 2026-09-10, and every block number and gasUsed matched the value published for it.",
        "whyReceiptsAndNotState": "Historical account state is pruned on these endpoints, so a historical eth_call will NOT work and eth_getBalance at an old block returns null. Receipts are retained for full history. Any verification recipe that asks you to eth_call an old block is broken by design; this one is not."
      },
      "proves": "These transactions were included and executed successfully at the stated blocks.",
      "doesNotProve": "A successful receipt proves execution did not revert. It does not prove the cryptographic content was meaningful, and it does not prove the input signatures were genuine NIST vectors rather than values chosen by the sender. Earlier revisions of this file added a counterfactual here, that one of these transactions could not have succeeded on a chain without the precompiles. That counterfactual cannot be constructed over a read-only interface and has been withdrawn.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "evm-opcode-parity",
      "claim": "The Cancun opcode set executes on chain 2800: PUSH0 (EIP-3855), TSTORE/TLOAD (EIP-1153), MCOPY (EIP-5656), BLOBHASH (EIP-4844) and BLOBBASEFEE (EIP-7516) all run rather than failing as invalid opcodes.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "procedure": "Run handwritten bytecode through an eth_call state override at any unused address. No deployment, no gas, no wallet. This is stronger than calling an Aere-deployed canary contract, because you supply the bytecode yourself and we cannot have special-cased it.",
        "probes": [
          {
            "eip": "EIP-3855 PUSH0",
            "codeClean": "0x602a5f5260205ff3",
            "expect": "0x000000000000000000000000000000000000000000000000000000000000002a",
            "measured": "0x000000000000000000000000000000000000000000000000000000000000002a"
          },
          {
            "eip": "EIP-1153 TSTORE/TLOAD",
            "codeClean": "0x604260015d60015c60005260206000f3",
            "expect": "0x0000000000000000000000000000000000000000000000000000000000000042",
            "measured": "0x0000000000000000000000000000000000000000000000000000000000000042"
          },
          {
            "eip": "EIP-5656 MCOPY",
            "codeClean": "0x60426020526020602060005e60206000f3",
            "expect": "0x0000000000000000000000000000000000000000000000000000000000000042",
            "measured": "0x0000000000000000000000000000000000000000000000000000000000000042"
          },
          {
            "eip": "EIP-7516 BLOBBASEFEE",
            "codeClean": "0x4a60005260206000f3",
            "expect": "executes, returns 0x0 in an eth_call context",
            "measured": "0x0000000000000000000000000000000000000000000000000000000000000000"
          },
          {
            "eip": "EIP-4844 BLOBHASH",
            "codeClean": "0x60004960005260206000f3",
            "expect": "executes, returns 0x0 in an eth_call context",
            "measured": "0x0000000000000000000000000000000000000000000000000000000000000000"
          },
          {
            "eip": "EIP-1344 CHAINID",
            "codeClean": "0x4660005260206000f3",
            "expect": "0x0000000000000000000000000000000000000000000000000000000000000af0",
            "measured": "0x0000000000000000000000000000000000000000000000000000000000000af0"
          }
        ],
        "bodyTemplate": {
          "jsonrpc": "2.0",
          "id": 1,
          "method": "eth_call",
          "params": [
            {
              "to": "0x00000000000000000000000000000000000000c0",
              "data": "0x"
            },
            "latest",
            {
              "0x00000000000000000000000000000000000000c0": {
                "code": "<codeClean from the probe above>"
              }
            }
          ]
        },
        "negativeControl": "This is the control that makes the zero-returning probes meaningful. Substitute an undefined opcode (0x0c, 0x21, 0xa5) into the same template. Measured 2026-09-10, all 3 returned an explicit error: `Transaction processing could not be completed due to an exception (Invalid opcode: 0x0c)`. Because undefined opcodes produce a loud, distinguishable failure, a probe that returns 0x0 WITHOUT that error has genuinely executed. Without this control, \"BLOBBASEFEE returned zero\" would prove nothing at all.",
        "bothEndpoints": "Every probe returned the same value on both endpoints."
      },
      "proves": "The execution layer implements the Cancun opcode set, demonstrated with bytecode the verifier writes rather than bytecode Aere deployed.",
      "doesNotProve": "Opcode availability is EVM parity, not performance and not security. BLOBBASEFEE and BLOBHASH returning zero in an eth_call is expected and says nothing about blob support in real transactions.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "rip7951-p256",
      "claim": "The secp256r1 (P-256) signature verification precompile at 0x100 accepts a valid signature and rejects a tampered one.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "procedure": "Generate your own P-256 key and signature so the vector is yours, not ours. Build the 160-byte input as sha256(msg) || r || s || pubkeyX || pubkeyY, with s normalised to the low half of the curve order as RIP-7951 requires. Call 0x100 with it. Then flip one byte and call again.",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_call",
          "params": [
            {
              "to": "0x0000000000000000000000000000000000000100",
              "data": "0x<160 bytes>"
            },
            "latest"
          ],
          "id": 1
        },
        "expect": {
          "validSignature": "0x0000000000000000000000000000000000000000000000000000000000000001",
          "tamperedSignature": "0x (empty)"
        },
        "measuredWithFreshlyGeneratedVector": {
          "input": "0x0d7883318b157f47c167fed2cd0a33bc920cccbf0e6a2f1d8617f3989d53348f69db1ff2394826b22304b607f92a985d88f3f9bbb41656d9842cd25fbe1173e6758580e794c7cf84a4ebe2a9d3150658f9a19cc961ec64068df40eb1108af173899373d6f1e9d7004f9c9c89863b52347c1fc7b6b292b2522fbfc0f1e177a31d999873b16a3be26fa6d51f36431dc7367a269c196b749e0c38803c0aaf265748",
          "valid": "0x0000000000000000000000000000000000000000000000000000000000000001",
          "tampered": "0x"
        },
        "note": "The vector above was generated during THIS file's generation run on 2026-09-10 with a key created for that run and then discarded. It is regenerated from scratch every time this file is rebuilt, so it is never carried forward from an earlier day. Do not trust it; generate your own. The check is only meaningful if the vector is yours."
      },
      "proves": "0x100 performs real P-256 verification with a working accept path and a working reject path. Both controls fire.",
      "doesNotProve": "Classical elliptic-curve cryptography, not post-quantum. P-256 is broken by a cryptographically relevant quantum computer exactly as secp256k1 is. It is listed here as EVM parity evidence, not as quantum resistance.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "contracts-have-code",
      "claim": "The contract addresses Aere publishes contain deployed bytecode of the stated size and hash on chain 2800.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getCode",
          "params": [
            "0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC",
            "latest"
          ],
          "id": 1
        },
        "procedure": "Fetch the code and take keccak256 of the returned bytes. Compare to `keccakCode` below.",
        "measured": [
          {
            "name": "AereFeeBurnVault",
            "address": "0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6",
            "codeBytes": 1313,
            "keccakCode": "0x35c9591e2d8f3510cdad371eac09abd1820b91dfff7befafe445ebf94761b365"
          },
          {
            "name": "AereSink",
            "address": "0x69581B86A48161b067Ff4E01544780625B231676",
            "codeBytes": 4164,
            "keccakCode": "0xb32c7048a6ef5886b5e99fe1595cf98da50c7a9e0cd0391f65d04adc2b0510e9"
          },
          {
            "name": "AereCoinbaseSplitter",
            "address": "0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec",
            "codeBytes": 2614,
            "keccakCode": "0x0a80f438a740c3777b6e3ebbd8b47939cb4bf6be97e1a0aff874c2f174ac81d8"
          },
          {
            "name": "AereFalcon512Verifier",
            "address": "0x4E8e9682329e646784fB3bd01430aA4bA54D8fFC",
            "codeBytes": 7333,
            "keccakCode": "0x3f4fdf22a292302aafe4f851d48147d126a4508b4da46ac9b35598a330a93065"
          },
          {
            "name": "AereFalcon1024Verifier",
            "address": "0xF0aFA59BaB2058e4B6e6B424b7f76750F1F66e36",
            "codeBytes": 7334,
            "keccakCode": "0xc873040484c647b81d71e85247dd12d7953fa175d911287c67d70f0d825589bc"
          },
          {
            "name": "AereMLDSA44Verifier",
            "address": "0xf1F7A6Acd82D5DAf9AF3166a2F736EE52C5F85AE",
            "codeBytes": 8654,
            "keccakCode": "0x045fe3cd81181fe11b365a603d97db83cab7e1e887d5dd95f855ddbba80f8aec"
          },
          {
            "name": "AereCancunCanary",
            "address": "0x8DbFC002bB23124cBeCd7B4916c179D2AFd65498",
            "codeBytes": 1541,
            "keccakCode": "0x08ec3644e2b8ead1e81d027127a17ee94edafeb1be5d9173914fcea82ab550f4"
          },
          {
            "name": "AereKZGVerifier",
            "address": "0x6596307BD8f54d9A91FE364EBC3e594F200AC862",
            "codeBytes": 1988,
            "keccakCode": "0x976bf39c13368fd4717227dd9f2e6a6a26f8654519d92ea438492b371b9a02b9"
          },
          {
            "name": "AerePQCAttestation",
            "address": "0x465d9e3b476bf98aa1393079e240db5d2a9bea6a",
            "codeBytes": 4402,
            "keccakCode": "0x2cf54017f8a56b0fdf1c659c3a5bf18504fccdbd7c2761c6c955b38e268774b7"
          }
        ]
      },
      "proves": "Bytecode of exactly this size and hash is deployed at these addresses right now.",
      "doesNotProve": "Does NOT prove the bytecode matches the published Solidity source. Source-to-bytecode verification is a separate exercise; Aere publishes its attempt at https://aere.network/verified-contracts.json, and you should treat that as a claim to check, not as a result. Note also that the document is generated on its own schedule and covers a different and larger set of contracts than the 9 listed here, so the two will not line up one to one. It also does not prove the contracts do anything useful.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "no-upgrade-proxy",
      "claim": "None of the 9 contracts above is an EIP-1967 upgradeable proxy: the implementation, admin and beacon storage slots are all zero.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getStorageAt",
          "params": [
            "0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6",
            "0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc",
            "latest"
          ],
          "id": 1
        },
        "slots": {
          "implementation": "0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc",
          "admin": "0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103",
          "beacon": "0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50"
        },
        "slotsAreDerivedNotCopied": "Each constant above is keccak256(label) - 1, with labels eip1967.proxy.implementation, eip1967.proxy.admin and eip1967.proxy.beacon. Derive them yourself before reading storage. A zero read at the wrong slot proves nothing at all, and it looks exactly like a zero earned honestly.",
        "expect": {
          "result": "0x0000000000000000000000000000000000000000000000000000000000000000"
        },
        "measured": "All three slots read zero on all 9 contracts listed under `contracts-have-code`, measured 2026-09-10 across 27 storage reads with 0 non-zero.",
        "secondCheck": "Scan the deployed bytecode for the PUSH4 selectors of upgradeTo(address) (0x3659cfe6), upgradeToAndCall(address,bytes) (0x4f1ef286), implementation() (0x5c60da1b), admin() (0xf851a440), getAdmin() (0x6e9960c3), changeAdmin(address) (0x8f283970). None were present in any of the 9. Every selector was computed from keccak of its signature rather than typed."
      },
      "proves": "These specific contracts are not behind the standard upgradeable-proxy pattern and expose no standard upgrade entry point.",
      "doesNotProve": "Absence of the EIP-1967 pattern is not proof of immutability in general. A non-standard upgrade mechanism, a custom storage slot, or a DELEGATECALL to a mutable target would not be caught by this check. Read the bytecode if immutability matters to you.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "burn-vault-has-no-owner",
      "claim": "AereFeeBurnVault exposes no ownership or administration entry point. Its only value-moving function, sweepToZero(), is callable by any address and is not gated on a privileged caller.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "procedure": "Walk the deployed bytecode as instructions (skipping PUSH immediates so you do not read data as opcodes) and collect every PUSH4 constant. Then check which known-dangerous selectors appear. Compute each selector from keccak of its signature; do not copy ours.",
        "whatAPush4ConstantIsAndIsNot": "An earlier revision called this list \"the function selectors the dispatcher compares against\". That is false for some of them, and measurably so: this contract contains Panic(uint256) 0x4e487b71 and transferFrom(address,address,uint256) 0x23b872dd, which are not entry points at all. The first is the Solidity 0.8 panic error signature and any outbound-call selector looks the same to this scan. The scan therefore over-collects. That WEAKENS nothing here, because the claim is about ABSENCE: a scan that catches more than the dispatcher cannot miss an entry point that is there. It does mean the list must be called what it is.",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getCode",
          "params": [
            "0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6",
            "latest"
          ],
          "id": 1
        },
        "measured": {
          "push4ConstantsFound": 9,
          "push4Constants": [
            "0x23b872dd",
            "0x44df8e70",
            "0x4e487b71",
            "0x579663e2",
            "0x7f657280",
            "0x972dc3a8",
            "0xce587013",
            "0xd1df306c",
            "0xe26846d3"
          ],
          "push4ConstantsThatAreNotEntryPoints": [
            "Panic(uint256) 0x4e487b71",
            "transferFrom(address,address,uint256) 0x23b872dd"
          ],
          "dangerousSelectorsPresent": [
            "sweepToZero() = 0x579663e2"
          ],
          "dangerousSelectorsAbsent": [
            "owner() 0x8da5cb5b",
            "transferOwnership(address) 0xf2fde38b",
            "renounceOwnership() 0x715018a6",
            "admin() 0xf851a440",
            "upgradeTo(address) 0x3659cfe6",
            "withdraw() 0x3ccfd60b",
            "withdraw(uint256) 0x2e1a7d4d",
            "withdraw(address,uint256) 0xf3fef3a3",
            "emergencyWithdraw() 0xdb2e21bc",
            "rescue(address,uint256) 0x7a4e4ecf",
            "pause() 0x8456cb59",
            "unpause() 0x3f4ba83a",
            "grantRole(bytes32,address) 0x2f2ff15d",
            "initialize() 0x8129fc1c"
          ]
        },
        "confirmCalls": [
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6",
                  "data": "0x8da5cb5b"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": "Execution reverted (owner() does not exist)"
          },
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6",
                  "data": "0x579663e2",
                  "from": "0x000000000000000000000000000000000000dEaD"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": "0x, does not revert even when called from an arbitrary address, i.e. permissionless"
          }
        ],
        "negativeControlOnTheConfirmCalls": "We called this contract with a selector we invented, keccak256(\"definitelyNotAFunction()\")[0:4] = 0x81d414ef. The reply is byte for byte the same as the reply to owner(): \"Execution reverted\". From the reply alone, a function that was never written and a function that was deliberately left out are indistinguishable. That is why this claim does not rest on the reverts and rests on the positive bytecode scan instead.",
        "methodNote": "An empty revert means that NAME is absent from the dispatcher. It never means a capability is absent in general."
      },
      "proves": "The vault's dispatcher contains no owner, admin, pause, upgrade or withdraw selector, and its one outbound-value function is not caller-gated.",
      "doesNotProve": "This is a selector-level check. It does not decompile the contract, does not prove where sweepToZero() actually sends value, and does not rule out logic reachable through the fallback function. To assert that the destination is irrecoverable you must read the bytecode yourself.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "burn-rate-parameter",
      "claim": "AereCoinbaseSplitter stores a burn rate of 3750 basis points (37.5%) and is owned by a single externally-owned account.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "calls": [
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec",
                  "data": "0x53deb3d6"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": "0x0000000000000000000000000000000000000000000000000000000000000ea6 = 3750"
          },
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_call",
              "params": [
                {
                  "to": "0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec",
                  "data": "0x8da5cb5b"
                },
                "latest"
              ],
              "id": 1
            },
            "expect": "0x0243a4f47d44b40b65d33f20329de20d00c6f3c3"
          }
        ],
        "selectorNote": "0x53deb3d6 is the first four bytes of keccak256(\"burnBps()\"). Compute it yourself rather than trusting this line: a mistyped selector returns an empty revert that looks exactly like an absent function. Earlier revisions of this file shipped an unsubstituted placeholder here, in a file whose own instructions say it is made to be run.",
        "measured": {
          "burnBps": 3750,
          "owner": "0x0243a4f47d44b40b65d33f20329de20d00c6f3c3",
          "ownerHasCode": false,
          "ownerCodeHash": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
          "ownerCodeHashIsTheEmptyCodeHash": true,
          "mutatingSelectorsPresent": [
            "owner() 0x8da5cb5b",
            "transferOwnership(address) 0xf2fde38b",
            "renounceOwnership() 0x715018a6",
            "setBurnBps(uint256) 0xaddc831e"
          ]
        },
        "whyCodeHashAndNotGetCode": "ownerHasCode is read from eth_getProof rather than eth_getCode, because the codeHash in a proof is checkable against the state root in the signed header while eth_getCode is the node's word."
      },
      "proves": "The rate is on-chain and readable, and equals 37.5%.",
      "doesNotProve": "This rate is NOT immutable. setBurnBps(uint256) exists in the bytecode and the owner is 0x0243a4f47d44b40b65d33f20329de20d00c6f3c3, which has no code, i.e. a plain single-key account and not a multisig or timelock. One key can change the burn rate. Any Aere copy describing the splitter as having \"no admin\" is wrong, and this entry exists to contradict it. See also `burn-not-currently-flowing` in notClaimed.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "account-facts-via-proof",
      "claim": "Account state can be verified against the state root with a Merkle proof rather than taken on a node's word.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_getProof",
          "params": [
            "0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6",
            [],
            "latest"
          ],
          "id": 1
        },
        "expect": "an accountProof array whose nodes hash up to the stateRoot in the block header",
        "measured": {
          "balanceWei": "137352594046167719",
          "nonce": "0x1",
          "codeHash": "0x35c9591e2d8f3510cdad371eac09abd1820b91dfff7befafe445ebf94761b365",
          "storageHash": "0x4533fa2a8b98ef96d4b7c65a43483d1721f4997363813c4199af37d3d1e92174",
          "accountProofNodes": 4
        },
        "crossCheck": "The codeHash returned by the proof equals keccak256 of the bytes returned independently by eth_getCode, so two different JSON-RPC methods agree on the same account.",
        "whyThisMethod": "Measured 2026-09-10 by probing the same account at increasing depth. eth_getTransactionCount returns the true 0x1 down to 450 blocks back, then, since 2026-09-10, refuses with a world-state-unavailable error from 500 blocks back and deeper, exactly like eth_getProof and eth_getBalance at those depths. Until 2026-09-10 the same method returned a FALSE 0x0 there, with no error and no warning, and a reader who trusted it at depth concluded the account had never been used; that behaviour is gone on both public endpoints, and this file measured the change rather than assuming it. The exact depth at which the window ends was NOT bisected and it moves with the chain head, so treat the two numbers above as a bracket, not as a boundary.",
        "depthLadder": [
          {
            "depth": 0,
            "nonce": "0x1",
            "proof": "answers",
            "balance": "0x1e7f974e119aaa7"
          },
          {
            "depth": 200,
            "nonce": "0x1",
            "proof": "answers",
            "balance": "0x1e7f974e119aaa7"
          },
          {
            "depth": 450,
            "nonce": "0x1",
            "proof": "answers",
            "balance": "0x1e7f974e119aaa7"
          },
          {
            "depth": 500,
            "nonce": "error -32000",
            "proof": "World state unavailable",
            "balance": "error -32000"
          },
          {
            "depth": 512,
            "nonce": "error -32000",
            "proof": "World state unavailable",
            "balance": "error -32000"
          },
          {
            "depth": 1000,
            "nonce": "error -32000",
            "proof": "World state unavailable",
            "balance": "error -32000"
          }
        ]
      },
      "proves": "The endpoint serves Merkle proofs, so an outsider can validate account facts against the block header instead of trusting the RPC response.",
      "doesNotProve": "A proof is only as good as the state root you check it against, and that root comes from a header signed by the same 10 Foundation-operated validators (ten validators since 2026-09-11). This removes trust in the RPC node, not trust in the validator set.",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "basefee-floor",
      "claim": "The base fee is 1,000,000,000 wei at the current head, but the floor is NOT a property of this chain's whole history: sampling across the post-fork range finds base fees below it, as low as 7 wei.",
      "verify": {
        "method": "POST",
        "url": "https://rpc.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_gasPrice",
          "params": [],
          "id": 1
        },
        "expect": {
          "result": "0x3b9aca00"
        },
        "alsoRun": [
          {
            "body": {
              "jsonrpc": "2.0",
              "method": "eth_getBlockByNumber",
              "params": [
                "latest",
                false
              ],
              "id": 1
            },
            "expect": "baseFeePerGas == 0x3b9aca00"
          }
        ],
        "measured": {
          "gasPrice": 1000000000,
          "headerBaseFeePerGas": 1000000000,
          "bothEndpointsAgree": true
        },
        "forkBoundaryIsVisibleFromOutside": "The activation height Aere documents is not taken on trust here; the generator reads the two headers around it and refuses to publish this file unless they behave as the documented fork predicts. Measured 2026-09-10: block 10,141,733 carries 7 wei and block 10,141,734 carries 1,000,000,000 wei.",
        "historyScan": "241 heights sampled at a stride of 32,599 across the whole range from the activation height to the current head: 3 of them read below 1,000,000,000 wei. The lowest value seen is 7 wei, and it is not a single point: 3 of the 3 sampled violations read exactly that value, block 13,075,644 being one of them. The sampled violations span blocks 13,010,446 to 13,075,644, which is AT LEAST 65,199 blocks and may be more: a stride sample can only widen, never narrow, the true window. The exact first and last violating block are NOT established: the property is intermittent, so a scan brackets the window and a binary search on it would return a confident wrong answer.",
        "scanNegativeControl": "The same scan run against an impossible threshold of 1 wei fires on 0 of 241 headers, and against a threshold of twice the floor it fires on 241 of 241. The scan can therefore return both answers and is reading real values rather than a constant."
      },
      "proves": "The current base fee is exactly 1,000,000,000 wei, in both the header and the gas-price estimate, and the documented fork boundary reproduces on the public chain.",
      "doesNotProve": "One reading at one block does not prove a floor exists in the consensus rules, and the history above shows the opposite held for part of this chain's past.  The floor is enforced by client configuration an outsider cannot inspect. We state the effect and not a cause, because we have not measured one. Anyone quoting a floor as a property of chain 2800 should read it as \"the floor holds at the head today\", never as \"the floor has always held\".",
      "lastMeasured": "2026-09-10"
    },
    {
      "id": "second-read-endpoint",
      "claim": "A second public read endpoint, rpc2.aere.network, answers the same chain queries with the same values, but it does not expose the same method set.",
      "verify": {
        "method": "POST",
        "url": "https://rpc2.aere.network",
        "body": {
          "jsonrpc": "2.0",
          "method": "eth_chainId",
          "params": [],
          "id": 1
        },
        "expect": {
          "result": "0xaf0"
        },
        "measured": {
          "latency": "70 ms and 910 ms for a five-call batch, measured during this run FROM ONE PLACE ON THE INTERNET. This is the only number in this file that depends on where the observer is standing, and it is labelled so rather than dropped, because a reader who reproduces it and gets a different figure has not found a defect.",
          "peerCount": [
            10,
            10
          ],
          "syncing": false
        },
        "knownDifference": "txpool_status answers on rpc.aere.network and is refused on rpc2.aere.network with error -32604. The two endpoints are therefore not interchangeable, and any recipe in this file that tells you to repeat a call on the second endpoint says which calls."
      },
      "proves": "Two endpoints are up and agree on chain data. Every gas figure, every known-answer test and every opcode probe in this file was run against both and matched.",
      "doesNotProve": "These are BOTH operated by the Aere Foundation. Agreement between them is not independent confirmation, it is one operator agreeing with itself. There is currently no third-party public RPC for chain 2800, so no outsider-operated cross-check exists. Treat every measurement in this file as coming from a single operator's infrastructure.",
      "lastMeasured": "2026-09-10"
    }
  ],
  "notClaimed": [
    {
      "id": "no-post-quantum-consensus",
      "weDoNotClaim": "That Aere Network has post-quantum consensus.",
      "theTruth": "Consensus on chain 2800 is classical ECDSA over secp256k1, under Hyperledger Besu QBFT. The committed seals in every block header are 65-byte secp256k1 signatures: measured 2026-09-10, 1,024 of 1,024 consecutive headers carried 6 seals of exactly 65 bytes. Post-quantum signature material IS now carried in some headers, and this file claims that separately under `pq-certificate-under-block-hash`, but it is NOT consensus: a header is valid on its secp256k1 seals, and a node that ignored the extra material would follow the chain identically.",
      "whyItMatters": "A quantum adversary that can break secp256k1 can forge Aere block seals. Neither the post-quantum precompiles nor the post-quantum material now carried in headers changes that, because nothing in consensus depends on either of them yet."
    },
    {
      "id": "no-first",
      "weDoNotClaim": "That Aere is the first chain to verify post-quantum signatures on-chain.",
      "theTruth": "Algorand has verified Falcon signatures on its public mainnet since November 2025, and Cellframe's published consensus source signs blocks with post-quantum keys and hashes the block with those signatures attached. Any Aere copy that says \"first\" is wrong.",
      "remeasuredToday": "Re-measured 2026-09-10 from the public internet with a cache-busting parameter: the homepage does not contain the string \"first public EVM\", so there is no defect to record under this heading today. This entry is corrected by measuring again rather than by remembering, every time this file is rebuilt. The field is named for what was found: an absence reported under a field called `knownDefect` is a small lie about a small thing, and this file cannot afford those."
    },
    {
      "id": "no-mainnet-traffic",
      "weDoNotClaim": "That chain 2800 is in use.",
      "theTruth": "Measured 2026-09-10 at head 17,965,699 over 1,024 CONSECUTIVE blocks covering 1,096 seconds of wall clock: 1,014 blocks were empty (99.02%), the window carried 10 transactions in total, and total gas used was 224,740 against a per-block gas limit of 9,007,199,254,740,991. That is 0.0091 transactions per second. Those transactions came from 1 distinct sending address, which is one account and not a user base. txpool_status on the first endpoint reports pending 0x0 and queued 0x0. Reading \"the chain has transactions now\" into these numbers would be misleading, which is why they are printed in full instead of summarised.",
      "whatChangedSinceThePreviousRevision": "Revision 5 of this file, published 2026-09-05, reported a pending transaction backlog of 0x0 that it said had been stuck at that value for days and was NOT draining into blocks, with the cause explicitly unmeasured. Measured 2026-09-10, the same call reports pending 0x0. We never measured why it was stuck, and we did not measure what cleared it. Both of those remain unmeasured, and the earlier admission is repeated here rather than deleted, because a number quietly replaced by a nicer number is how a file like this dies.",
      "whyThisIsHere": "Every performance-adjacent number on this domain is measured on a chain that is close to idle. A reader who does not know that will over-read all of them. The block interval claim above is still a true measurement; it is a measurement of an unloaded system, and it says so.",
      "reproduce": "Fetch a run of CONSECUTIVE blocks with eth_getBlockByNumber and read gasUsed and the length of the transactions array. Scan, do not sample: on this same window a stride sample of 128 headers finds 2 of the 10 transactions that are actually there. Then call txpool_status on https://rpc.aere.network only: the second endpoint refuses that method with error -32604, so this particular check cannot be repeated there.",
      "status": "OPEN, and with an unmeasured cause. The chain is close to idle, the little traffic that exists comes from a very small number of senders, and neither why the earlier backlog sat nor what removed it was ever measured. This entry is not closed by deleting it."
    },
    {
      "id": "tps-273000",
      "weDoNotClaim": "That Aere sustains 273,000 transactions per second.",
      "theTruth": "273,000 TPS has never been measured on mainnet and no benchmark harness in the Aere repository reproduces it. There is no verification method for this number, which is why it appears in this section and not above it.",
      "whatIsMeasured": "Block interval, 0.5919 s over 100,000 blocks, on blocks that are 99.02% empty. That is a real measurement of a timer. Measured throughput over 1,024 consecutive blocks is 0.0091 transactions per second, which makes the gap larger, not smaller.",
      "theStatedDerivationDoesNotWork": "Aere copy has described the figure as arithmetic from the block gas limit and the block time. Check that arithmetic against the live chain and it collapses. Measured 2026-09-10, eth_getBlockByNumber at latest returns a gasLimit of 9,007,199,254,740,991, which is 2^53-1, the largest integer a JavaScript double represents exactly, and the same value appears on every header in the scanned window, so it is a constant of the configuration and not a tuned engineering parameter. Divided by a 21,000-gas transfer over a 0.592 s block, that yields roughly 7.2 x 10^11 transactions per second, not 273,000. A gas limit that is a language artifact is not an engineering parameter, so no throughput figure can honestly be derived from it. The stated derivation does not produce the stated number, and neither figure should be quoted.",
      "knownDefect": "Measured 2026-09-10 with a cache-busting parameter, the homepage carries the 273,000 figure only inside its withdrawal notice; no sentence presents it as a rate or a ceiling.",
      "reproduce": "POST eth_getBlockByNumber with params [\"latest\", false] to https://rpc.aere.network and read the gasLimit field. Then divide it yourself and see what number comes out. Then read the transactions array of a few hundred consecutive blocks and see how many are empty."
    },
    {
      "id": "roadmap-not-live",
      "weDoNotClaim": "That Adaptive QBFT or a native CLOB precompile are live components of Aere today, or that parallel execution buys any throughput on chain 2800 today.",
      "theTruth": "Adaptive QBFT and the order-book precompile are roadmap items; any architecture diagram that shows them as current components is a false statement in visual form. Measured 2026-09-10, the node enumerates 23 active precompiles and none of them is an order-book precompile, which settles that part; Adaptive QBFT is not observable over a public read endpoint, so that restraint rests on our own statement. Parallel execution is different: since 2026-09-05 our own Block-STM-style block processor is switched on on all nine validators and is proven on real blocks with a recorded negative control, but blocks carry at most one transaction, so it has nothing to parallelise, no speed-up is claimed, and none is observable over a public endpoint."
    },
    {
      "id": "supply-2800000000",
      "weDoNotClaim": "That the 2.8 billion AERE supply is verifiable by an outsider.",
      "theTruth": "AERE is the chain's native coin, not an ERC-20. There is no totalSupply() to call, and no JSON-RPC method returns total issuance. We believe the figure is correct from the genesis file, but we have no method a stranger can run, so we do not present it as verified. The same applies to \"zero insider unlocks\".",
      "reproduce": "Confirm for yourself that no archive view exists. Measured 2026-09-10: eth_getBalance and eth_getProof answer at latest and down to about 450 blocks back; from about 500 blocks back eth_getBalance and eth_getProof both report that the world state is unavailable (eth_getBalance returned null there until 2026-09-10), and that includes the genesis block. The header chain is served in full, so you can read headers back to genesis but not the state those headers commit to. Headers are full history here; state is not. That is the precise reason the supply figure has no outsider-runnable proof.",
      "whatWouldFixIt": "A full-history archive node and a sum over genesis allocations plus issuance. Aere has not published one an outsider can query."
    },
    {
      "id": "decentralization",
      "weDoNotClaim": "That Aere is decentralized.",
      "theTruth": "All 9 validators are operated by the Aere Foundation. The effective Nakamoto coefficient is 1. Growing the validator set does not change that number, because adding machines you already control adds no independence; a larger set here buys tolerance to node failure and nothing else. The 6-of-9 quorum you can read out of the header protects against node failure, not against the operator. Validator-set membership is verifiable; independence of the operators is not, because there is none."
    },
    {
      "id": "burn-not-currently-flowing",
      "weDoNotClaim": "That the burn engine is currently burning.",
      "theTruth": "Measured 2026-09-10 at head 17,965,699: the AereFeeBurnVault balance at 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 is 0x1e7f974e119aaa7 wei and is identical at latest, at latest-200 and at latest-450, and identical on both public endpoints. AereCoinbaseSplitter and AereSink both hold a zero balance. The `miner` field of every header in the scanned window is a proposing validator address, not the splitter. The splitter stores burnBps = 3750, which is real and readable. Fees are being paid on this chain, in small amounts, and over the scanned window the vault balance did not move by a single wei. So the honest statement is not \"there are no fees to split\" but \"fees exist and the burn vault is not receiving them\".",
      "whatIsTrue": "The contracts are deployed, the rate is on-chain and readable, the vault holds a non-zero historical balance, and the vault's bytecode exposes no owner selector and no withdrawal selector, re-verified 2026-09-10. That last one is a selector-level check and nothing more: it does not decompile the contract and does not rule out logic reachable through the fallback function, exactly as `burn-vault-has-no-owner` says of itself. An earlier revision wrote it here as \"really does have no owner and no withdrawal path\", which is a stronger sentence than the claim it leans on. What is not true is the present-tense claim that 37.5% of validator rewards is being burned right now.",
      "reproduce": "eth_getBalance on 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6 at `latest` and at `latest - 450`, and compare. Do not go deeper than that: the served state window ends between 450 and 500 blocks back and the call refuses with a world-state-unavailable error (it returned null until 2026-09-10). Then read the `miner` field of any recent block and see that it is a validator address and not the splitter.",
      "andItIsNotSealedEndToEnd": "Aere copy elsewhere calls the burn path sealed and admin-less. That is true of the VAULT and false of the SPLITTER. The vault exposes no owner(), no transferOwnership, no withdrawal and no upgrade selector, and that part stands. The splitter exposes owner(), transferOwnership(address), renounceOwnership(), setBurnBps(uint256), and owner() returns 0x0243a4f47d44b40b65d33f20329de20d00c6f3c3, an address whose codeHash is the empty-code hash, which means a single externally owned key. The rate underneath the ceiling is one signature away from changing. Do not read the word immutable across the whole path."
    },
    {
      "id": "nist-kat-validation",
      "weDoNotClaim": "That an outsider can reproduce our NIST KAT/ACVP validation of the Falcon, ML-DSA and SLH-DSA verifiers.",
      "theTruth": "Aere states these verifiers were validated against official NIST vectors. That validation is not reproducible from the public RPC, because the official vector sets are not what sits on chain. What an outsider CAN verify today is that the precompiles execute and consume gas, and that SHAKE256 matches locally computed digests across varying inputs. Everything beyond that is currently our word, and is marked as such.",
      "andItAppliesToTheHeaderMaterialToo": "The same restraint governs the post-quantum signatures now carried in block headers. Their sizes are consistent with a compressed lattice signature, but no outsider can verify a single one of them, because Aere does not publish the validators' post-quantum public keys anywhere a stranger can read. The digest binding is verifiable; the signatures under it are not. Header material you cannot check is a strong hint, not evidence, and the claim above is written to that limit."
    },
    {
      "id": "explorer-is-not-an-api",
      "weDoNotClaim": "That explorer.aere.network is a machine-readable data source.",
      "theTruth": "It is a client-side rendered UI served from the same static site as the marketing pages. Measured 2026-09-10: its root path answers with content-type text/html and /api/v2/stats answers with content-type text/html and approximately 50,833 bytes that do NOT parse as JSON. The byte count is approximate on purpose: that body is generated, so it moves between reads, and a reader who gets a slightly different length has not found a discrepancy. A machine that trusts the status code alone will parse a web page. If you are a machine, use the JSON-RPC endpoint and ignore the explorer entirely."
    },
    {
      "id": "companion-files-are-stale",
      "weDoNotClaim": "That the rest of aere.network agrees with this file.",
      "theTruth": "Measured 2026-09-10: the homepage, https://aere.network/llms.txt and https://aere.network/verifiable-claims-check.py were checked for validator counts that disagree with the header decode in this file, and none was found. This entry stays regardless, because it is the check that has to keep running, not the result.",
      "measured": {
        "validatorCountThisFileMeasures": 9,
        "quorumThisFileMeasures": 6,
        "validatorCountsFoundOnTheHomepage": [
          9
        ],
        "quorumPairsFoundOnTheHomepage": [],
        "validatorCountsFoundInLlmsTxt": [
          9
        ],
        "quorumPairsFoundInLlmsTxt": [
          [
            6,
            9
          ]
        ],
        "validatorCountsAssertedByTheCheckerScript": [],
        "quorumPairsAssertedByTheCheckerScript": [],
        "committedSealCountsAssertedByTheCheckerScript": [],
        "howToReadThese": "Pairs are [quorum, set size], printed as numbers rather than as the usual \"a-of-b\" text, because this file refuses to write that text with any numbers other than the ones it measured, and that refusal has no exemption for quotation.",
        "checkerScriptStillAssertsAPendingBacklog": false,
        "checkerScriptSamplesAtAFixedStride": true
      },
      "whyThisIsHere": "A file whose whole argument is measured accuracy cannot be measured alone. The generator now reads the neighbouring public files on every run and refuses to write this document unless the disagreement it finds is written down here.",
      "reproduce": "Fetch https://aere.network/, https://aere.network/llms.txt and https://aere.network/verifiable-claims-check.py with a cache-busting query parameter, search each for a validator count, and compare against the header decode described in `qbft-validator-set-from-header`.",
      "status": "No disagreement measured today."
    },
    {
      "id": "audit-status",
      "weDoNotClaim": "That Aere has passed an external third-party security audit.",
      "theTruth": "Aere publishes internal review pages, including static-analysis output. Those are self-reported. No independent audit firm's report is published in machine-readable form, and until one is, no audit claim should be read as external assurance.",
      "note": "This entry is NOT re-measured by the generator that produces this file. It is carried forward deliberately and labelled as carried forward, because a date bumped without a measurement behind it is exactly the failure this file exists to prevent."
    },
    {
      "id": "block-hash-does-not-cover-falcon-cert",
      "weDoNotClaim": "That Aere's post-quantum anchoring work is complete, or that the certificate in the header means the chain is post-quantum secure.",
      "theTruth": "Until 2026-09-10 this entry said the anchoring work was proven on a test network but NOT active on mainnet, and it told you to decode extraData and observe that vanityData carries the client version string. That was wrong, it is corrected here by measuring rather than by remembering, and the instruction it gave you would have refuted it: on headers that carry post-quantum material, vanityData is a 32-byte digest instead. What is now true is stated as a claim above, `pq-certificate-under-block-hash`, with the reconstruction anyone can run. What remains NOT claimed is everything past the binding. The digest commits to the BYTES of the certificate; it does not make those bytes valid signatures, and we publish no public keys against which you could check them. The certificate does not decide block validity, so a chain that ignored it entirely would be indistinguishable to a validating node. Whether the certificate is a quorum is a measurement, not a label: measured 2026-09-10 over 400 carrying headers, certificates carried 6 to 9 distinct validators out of 9, 0.0% of them below f+1 = 3 and 0.0% below the 6-of-9 quorum. Anyone describing this window as proof of a rule, rather than as a measurement, can be corrected in one command.",
      "andTheBindingIsDetectionNotInvalidation": "Measured 2026-09-10: replacing the certificate with same-shaped junk, or removing it outright, leaves the block hash unchanged, because the hash is taken over a five-item re-encoding that drops it. What the digest buys is that the swap no longer matches the header, so a reader who recomputes sees it. It does not make the block invalid, and this file said the opposite for one revision.",
      "idIsLegacy": "This entry's id predates the measurement and is kept only so that nothing published under it disappears silently. It is wrong twice over: the block hash DOES now commit to a digest of the certificate, which is the opposite of what the id says, and the id names an algorithm that this file deliberately does not name anywhere else, because naming it would assert more than was measured. Read the body, not the id, and key on the body."
    }
  ],
  "howToRefuteThisFile": {
    "principle": "Every claim above is written so that it can be shown false. If any expected value does not reproduce, the claim is wrong and we want to know.",
    "fastestRefutations": [
      "Run the gas probe against 0x0AE1 and get 2625 instead of 42625. That would mean the precompiles are not executing and the central post-quantum claim is empty.",
      "Decode extraData and count a validator list that is not 9, or a seal count below 6. That would break the quorum claim.",
      "Recompute the anchor digest as described in `pq-certificate-under-block-hash` on any header whose extraData has six items and get something other than that header's vanityData. That would break the only claim in this file that nobody else can make.",
      "Take any header whose extraData has six items, replace the sixth item with different bytes of the same shape, recompute the block hash as described in step 3, and find that it CHANGES. We measured that it does not change, and that measurement is what pulled our own central claim back from invalidation to detection. If you can make it change, our limit is too harsh and we want to know that as much as the reverse.",
      "Compute SHAKE256 locally for any of the five inputs listed under `shake256-nist-kat` and get something other than what 0x0AE5 returned.",
      "Find any of the absent selectors listed under `burn-vault-has-no-owner` actually present in the deployed bytecode.",
      "Read a non-zero EIP-1967 implementation slot on any of the 9 contracts.",
      "Sample baseFeePerGas across the range around block 13,010,446 to 13,075,644 and find it at or above 1,000,000,000 wei throughout. We measured it below, as low as 7 wei, and said so under `basefee-floor`; if you cannot reproduce that, our own admission is wrong and we want to know that too."
    ],
    "contact": "https://aere.network/.well-known/security.txt"
  },
  "revision": 6,
  "revisionNote": "What changed in this revision, and every item is a correction against us, found by readers who ran the file's own instructions. FIRST and worst: the central claim asserted that a swapped certificate would make the block invalid. Measured: swapping it, and deleting it, leave the block hash unchanged, because the procedure this same file publishes drops that item before hashing. The claim is now DETECTION, and the measurement that limits it is shipped as a step you can run. SECOND: the file told you to test its authenticity by fetching a non-existent path and expecting a 404, and to blame an edge cache if you got a 200. On this host the status depends on the shape of the path; the file failed its own authenticity test and then misdiagnosed the result as our cache. Every shape is now measured and printed. THIRD: a pending-transaction backlog this file had published as unexplained had vanished from the text along with the admission; the comparison against the previously published revision is now made on every run and the unmeasured cause is restated. FOURTH: the signature-count range, the signature byte range and the extraData maximum were extremes from a few dozen headers, published as if they were properties; three readers broke all three on their first scan. They are now measured over hundreds of carrying headers, labelled as observed extremes rather than bounds, and the generator refuses to publish a range from a thin sample. FIFTH: the certificate reaches only part of the validator set, and the file reported only the reassuring half of that fact. Also fixed: a transaction count that was counted wrongly and came out right by luck, two gas regimes described as one, Romanian labels and Romanian JSON keys that had leaked into an English document, a checker script we linked to that still asserts the old validator count, and companion files on this domain that still do. Revision 6 is the first revision of this file produced by a generator rather than by hand, and the reason is that the hand-written revision before it had gone wrong in the simplest possible way. It stated a validator count and a quorum that the chain had stopped having, in eight places, including inside its own list of the fastest ways to refute it: following that instruction refuted the file. A document whose entire argument is measured accuracy cannot be allowed to age in silence, so it is now rebuilt from measurement and it refuses to be written at all if any check did not run or any control did not fire. Three further things changed in this revision and every one of them is a correction against us: the traffic and emptiness numbers were being produced by a stride sample that undercounts sparse traffic, and are now counted over consecutive blocks; the base-fee floor is stated as holding at the head rather than over all history; and the entry declaring the post-quantum anchoring inactive on mainnet was simply false, which is now said plainly and turned into a claim you can run. What an attacker breaks is worth more than what a friendly reader praises, and what a clock breaks is worth more than either.",
  "discoverability": {
    "canonical": "https://aere.network/verifiable-claims.json",
    "runner": "https://aere.network/verifiable-claims-check.py",
    "runnerNote": "Measured 2026-09-10: the published checker script does not contradict this file on the validator count.",
    "referencedFrom": [
      "https://aere.network/robots.txt",
      "https://aere.network/llms.txt",
      "https://aere.network/architecture.html"
    ],
    "howToTellThisFileIsReal": "Measured 2026-09-10: this file answers 200 with content-type application/json and a body that parses. Do not test it by fetching a made-up path and expecting a 404. On this host the status code for a non-existent path depends on its shape: paths ending in a data extension answer 404, while paths with no extension or an .html ending answer 200 with a client-side application shell. The measured figures for every shape are under `transport.unknownPathsSoft404`. A previous revision told you that a 200 there meant you were being served an out-of-date copy by the CDN, and to retry with a cache-busting parameter; that diagnosis was wrong, the 200 is a live property of this site, and following the instruction returns the same 200 and leads a careful reader to a false conclusion about us."
  }
}
