aere-docs/AERE-BENCHMARK-REPORT.md

Aere Network: Reproducible Benchmark Report (spec-18)

Status date: 2026-07-19 Chain: Aere Network mainnet, chain ID 2800 (Hyperledger Besu QBFT). Scope: chain performance, zkVM proof-verification economics, and post-quantum cryptographic-operation gas, stated with a hard separation between what is freshly measured, what is cited from a committed repo artifact, and what still needs a measurement command run.

The absolute rule this report obeys

No performance number (TPS, latency, gas, proof size, proving time) appears here unless it was either (a) freshly measured by running a command this session, or (b) found in a committed repo artifact that is cited by path. Anything that cannot be measured or sourced is written as a measurement command and marked [MEASURE]. Anything sourceable only from memory and not yet confirmed against code is marked [VERIFY]. A fabricated benchmark would be a catastrophic failure of this document, so the labels below are load-bearing, not decoration.

Label legend

Label	Meaning
[MEASURED-FRESH]	Run by this report on this machine, output shown or summarized.
[CITED: path]	Value read from a committed repo artifact at the cited path.
[MEASURE: cmd]	Not measured here. The command that would measure it is given.
[VERIFY: note]	Sourceable but needs confirmation against live code or a live node.

Scope boundary that never moves

Aere Network validators sign classical secp256k1 QBFT consensus messages. Nothing in this report makes Aere consensus post-quantum. The post-quantum work is an application and account layer capability. Any claim of post-quantum consensus would be false and is not made here.

---

PART A: CHAIN PERFORMANCE

A.0 The one honesty point, stated first

The "273,000 TPS" figure is an ARCHITECTURAL CEILING derived from block-space arithmetic under ideal conditions. It is NOT the live mainnet transaction rate, it has never been a measured result, and it is not asserted as one. Three distinct quantities must never be conflated:

Quantity	Value	Label
Architectural ceiling (design maximum)	~273,000 TPS	[CITED], explicitly labeled a ceiling
Testnet-measured L1 throughput	none exists	see A.1
Live-mainnet-observed throughput	far below the ceiling, demand-limited	see A.1

[CITED: aerenew/docs/WHITEPAPER-V2.md lines 73, 117, 633; aerenew/docs/wp2-sections/01-overview.md:59; 02-architecture.md:21; 09-governance-roadmap.md:294] The whitepaper states it verbatim: the block parameters "admit a design ceiling on the order of 273,000 transactions per second; this is a theoretical maximum implied by the gas and block configuration, not a measured or sustained figure, and realized throughput on the live network is a small fraction of it." It is described as "a design ceiling derived from block-space arithmetic under ideal conditions" that "has never been a measured result."

On the derivation itself. The repo labels 273,000 as a block-space-arithmetic ceiling but does not publish the explicit factors. The two facts that are sourceable:

• Block period 0.5 s. [CITED: aerenew/docs/wp2-sections/02-architecture.md:19; genesis-subsecond.json (blockperiodmilliseconds: 500)]
• Genesis block gas limit is ambiguous across genesis artifacts: 0x2625a00 (40,000,000) in aerenew/genesis.json, versus 0x1fffffffffffff (9,007,199,254,740,991, effectively unbounded) in aere-genesis-current.json and genesis-subsecond.json. [VERIFY: which gas limit is live on 2800]

Implied arithmetic (transparent, not a new claim): 273,000 TPS at a 0.5 s block is 136,500 tx per block, and at the 21,000-gas simple-transfer floor that is about 2.87 billion gas per block. That is far above the 40M limit and far below the effectively-unbounded limit, so the ceiling presumes an effectively- unbounded block gas limit AND the cheapest possible transaction, not the EIP-7825-capped realistic workload the chain actually runs. [VERIFY: publish the explicit block-space arithmetic behind 273,000 so the ceiling is reproducible]

A.1 Testnet-measured and live-observed throughput (the honest gap)

There is no testnet measurement that validates 273,000 TPS for L1. The closest measured throughput number in the repo is a rollup-executor microbenchmark, and the artifact that produces it says plainly it neither reaches nor implies the ceiling.

[CITED: aerenew/parallel-executor/BLOCKSTM-ENDTOEND-THROUGHPUT-2026-07-13.md section 7] The Block-STM end-to-end harness measured about 247,000 to 270,000 TPS at gas=80 on a 16-vCPU box, but this is (a) the rollup executor with a light commit proxy, not L1, not a real Merkle Patricia Trie, and (b) entirely a function of the assumed per-transaction cost: the same box reports 115,000 to 500,000 TPS as the per-transaction weight changes. The gas=80 proximity to 273,000 is called out in the artifact as a coincidence, not a validation.

Live mainnet 2800 runs far below the ceiling, and this is by demand, not by capacity. [CITED: aerenew/research/specs/spec-zk-stack.md section 0.2; aerenew/docs/wp2-sections/01-overview.md:59] On-chain usage is thin (single-digit proof records for most verifiers; six genesis user wallets per project memory). Real throughput is demand-limited, not capacity-limited: the chain has ample block-space headroom and almost no load to fill it. [MEASURE: sample a live window with eth_getBlockByNumber over N recent blocks against https://rpc.aere.network and divide total tx by elapsed time to publish an observed sustained TPS; expected result is near zero on an idle chain]

A.2 Block time and finality

Deterministic single-slot QBFT finality at a 0.5 s block period. Because QBFT finalizes on commit rather than by accumulation of work, a transaction is irreversible in well under a second from inclusion, with no confirmation count and no reorg. [CITED: aerenew/docs/wp2-sections/02-architecture.md:19]

The 0.5 s period was reached by a mid-chain QBFT parameter change at block 2,138,451, halved from the launch value of one second, with no re-genesis. [CITED: aerenew/docs/wp2-sections/01-overview.md:59; aerenew/docs/WHITEPAPER-V2.md:73; genesis-subsecond.json (blockperiodseconds: 0, blockperiodmilliseconds: 500)]

Finality is a latency-to-irreversibility claim and is separate from throughput. The 0.5 s finality claim follows mechanically from QBFT plus the block period; it says nothing about TPS.

A.3 Parallel execution (Block-STM): the honest result

The honest result has three parts, and only the first is a mainnet-relevant guarantee. No end-to-end L1 throughput win is claimed, and Block-STM is NOT enabled on L1.

(1) Correctness proven bit-identical to sequential. [MEASURED-FRESH] This session ran the executor's bench on this Windows dev machine. The parallel==sequential gate (committed state and keccak state root identical to the sequential oracle) passed on all four conflict profiles:

LOW-CONFLICT      parallel==sequential check: PASS
MEDIUM-CONFLICT   parallel==sequential check: PASS
HIGH-CONFLICT     parallel==sequential check: PASS
PATHOLOGICAL      parallel==sequential check: PASS

This corroborates the cited larger runs: a 6,000-comparison correctness harness with 0 mismatches, and a re-import plus validation of 253 real exported blocks with zero state-root mismatch. [CITED: aerenew/parallel-executor/BLOCKSTM-ENDTOEND-THROUGHPUT-2026-07-13.md section 3 and section 8]

(2) Near-linear execution-phase scaling on parallelizable workloads. [MEASURED-FRESH] on this machine (fewer physical cores than the reference 16-core Linux box, so absolute speedup is lower, which is expected and honest):

Workload (this box, 16 threads)	speedup vs sequential	abort%
Low-conflict (~2%)	4.36x	0.3%
Medium-conflict (~15%)	4.96x	2.3%
High-conflict (single hot counter)	1.92x	24.8%
Pathological (all same slot)	0.43x (correctly slower)	11.5%

[CITED: same artifact, section 4-5] The reference 16-core Linux box measured about 8.3x to 9.4x execution-phase and about 8.3x to 9.1x end-to-end on realistic 0 to 50 percent conflict. The pathological all-same-slot profile is honestly slower than sequential (correct Block-STM behavior), on both boxes.

(3) No end-to-end throughput win claimed, and not on L1. [CITED: aerenew/research/specs/spec-parallel-execution.md section 9; BLOCKSTM-ENDTOEND section 7-8] The Aere L1 mainnet executes sequentially on Besu. The parallel executor is a bounded four-kind VM (Transfer, Sweep, Increment, AmmSwap) over a balance and storage map, not a full EVM, and its measured speedups are single-machine microbenchmarks, not a network throughput or TPS claim. The real forked client's commit path was separately measured to anti-scale (parallel commit was slower than sequential), so the real-client end-to-end ceiling is tighter than the Rust harness, not looser. The invariant deliverable is the correctness gate plus the speedup curve and its Amdahl bound, not an absolute TPS.

---

PART B: ZKVM COMPARATIVE (SP1 vs RISC Zero vs Halo2)

Every cell is labeled. Gas and proof-size values that are cited come from repo deployment artifacts and are measured single-run values, not benchmarked averages (the source spec states this explicitly). [CITED: aerenew/research/specs/spec-zk-stack.md footer]

B.1 Comparison table

Prover (version)	Proving time (off-chain)	On-chain gas to verify	Proof size	Verification latency
SP1 Groth16 (v6.1.0)	app-dependent, CITED single-runs: zkscreen ~72 to 75 s, over18 ~71 to 73 s, zkml-mnist ~200 to 205 s, aggregation Groth16 526.1 s [CITED: contracts/deployments/proof-aggregator-scale.json]	~300k typical [CITED: spec-zk-stack section 2]; measured records: storage-proof 348,345, zkML 326,492, aggregation ~390k flat [CITED: proof-aggregator-scale.json, zkml/storage-proof artifacts]	~260 to 356 bytes [CITED: spec-zk-stack section 2]	one staticcall, final at next block (~0.5 s) [MEASURE: time eth_call wall-clock]
SP1 Plonk (v6.1.0)	[MEASURE: prove a fixture with the Plonk prover]	"somewhat higher than Groth16" [CITED: spec-zk-stack section 2], exact [MEASURE]	[MEASURE]	one staticcall [MEASURE]
RISC Zero Groth16 (5.0.0-rc.1)	[MEASURE: r0vm prove the factor-guest], not recorded in repo	[MEASURE: eth_call gas on RiscZeroVerifierRouter.verify], no gas number committed	seal 260 bytes [CITED: contracts/deployments/risc0-verifier-fix.json sealLen]	one staticcall [MEASURE]
Halo2 (bn254 / KZG, SHPLONK)	[MEASURE: halo2 prover on the cubic circuit]	~449,517 gas [CITED: contracts/deployments/halo2-cubic.json; spec-zk-stack section 6] (revm gas ~300,144)	1,152 bytes [CITED: same]	one call [MEASURE]
KZG / EIP-4844 point-eval precompile (0x0A)	n/a (precompile, no prover)	~255,719 gas [CITED: contracts/deployments/kzg-verifier.json; spec-zk-stack section 5]	192-byte precompile input [CITED: same]	one staticcall

Notes on the two recursion facts worth keeping, both [CITED: proof-aggregator-scale.json; spec-zk-stack section 7]:

• A 10-proof recursive SP1 aggregation records on-chain in ~393,844 gas, roughly flat versus the 3-proof fold (~387,858 gas). Constant on-chain verification cost regardless of fold count is the point of recursion.
• The proving side of that same 10-fold cost 526.1 s for the aggregation Groth16 plus 988 s of inner proving (measured, off-chain, single run).

B.2 Routing logic (which prover for which job, and why)

[CITED: aerenew/research/specs/spec-zk-stack.md sections 1-3, 7-11] Routing is by selector: the first 4 bytes of the proof pick the concrete verifier.

• SP1VerifierGateway routes SP1 proofs by leading selector (Groth16 route 0x4388a21c, Plonk 0x5a093a2f).
• RiscZeroVerifierRouter routes a RISC Zero seal by leading selector (0xef6cb709 for 5.0.0-rc.1).

Which prover is chosen:

• SP1 is the workhorse. Every Aere application circuit routes through SP1: zk-KYC screen, over-18, zkML MNIST, compliance pool, storage-proof coprocessor, rollup validity anchor, and the recursive aggregator. The reason is concrete: smallest proofs (~260 to 356 bytes), lowest typical verify gas (~300k), one Rust guest toolchain, and native recursion via verify_sp1_proof inside the zkVM.
• RISC Zero is the diversity path. A second independent RISC-V zkVM, kept so the verification surface is not single-prover; a real Groth16 factorization receipt is recorded on-chain.
• Halo2 / KZG is the direct-circuit path. For circuits authored directly as a PLONK arithmetization (bn254 / KZG / SHPLONK), plus the raw EIP-4844 point-evaluation precompile for blob and commitment openings.

The honest framing the source insists on: this is a multi-prover verification surface behind one gateway, unusual to have in one place, but not a claim that no other chain can verify any one of these.

B.3 Why the on-chain-gas column motivates the STARK-verifier roadmap

SP1 Groth16, RISC Zero Groth16, and Halo2 all terminate their on-chain check in a BN254 pairing (Groth16 or KZG). Two problems live in that column: the check costs ~300k to ~450k gas, and BN254 pairing security rests on discrete-log / pairing hardness, which is Shor-breakable. That single elliptic-curve link is the only quantum-vulnerable step in an otherwise hash-based SP1 proof chain.

Roadmap item: replace the BN254 Groth16 wrap with a direct hash-based STARK verifier. [CITED: aerenew/pqc-fork/pq-stark/README.md; aerenew/docs/PQ-STARK-VERIFIER-PRECOMPILE-2026-07-18.md] The design is a native precompile at 0x0AE8. The generic verifier skeleton built so far verifies a BabyBear / Plonky3 FRI STARK directly, with no BN254 wrap, so its security rests only on hash collision-resistance and Reed-Solomon proximity gaps.

Scope caveat (2026-07-19 research finding) [CITED: aerenew/docs/AERE-STARK-SP1-RECURSION-AIR-PORT-SPEC-SUMMARY.md]: the six generic components confirmed so far verify BabyBear + FRI STARKs (Aere's OWN Plonky3 circuits), NOT SP1 6.1.0 proofs. The pinned SP1 6.1.0 is a Hypercube release (KoalaBear multilinear: BaseFold plus sumcheck-zerocheck plus LogUp-GKR), so its inner proof is hash-based but NOT a BabyBear FRI STARK, and FRI plus DEEP-ALI do not apply to it. Replacing the SP1 BN254 Groth16 wrap on real SP1 proofs is therefore a SEPARATE ~22 to 32 person-week retarget and a founder decision, not a completion of the skeleton below.

Honest status of that roadmap item, stated plainly [CITED: same README, "HONEST STATUS"]: it is a REFERENCE SKELETON plus DESIGN. It is NOT audited, NOT a working verifier for SP1 proofs, and NOT activated on any Aere network. It fail-closes (returns "not verified" for every input, cannot emit a false accept). The SP1-recursion-specific crypto core is un-ported, and per the caveat above the SP1 target is a different (Hypercube) proof system entirely. Mainnet 2800 has exactly the five PQC precompiles 0x0AE1..0x0AE5; 0x0AE8 is not live anywhere.

---

PART C: CRYPTO-OP GAS (PQC vs ECDSA)

C.1 Table (measured marginal precompile verify-op gas, with sources)

Operation	Address	Marginal gas	Full verify-and-record tx gasUsed	Source
ECDSA (ecrecover)	0x01	~3,000	n/a	protocol constant [VERIFY: G_ecrecover = 3000 is a fixed EVM constant, not Aere-specific]
P-256 / passkey (RIP-7951, aka RIP-7212)	0x100	~3,450	n/a	[CITED: aerenew/docs/wp2-sections/02-architecture.md:36; aerenew/research/aip-draft-pqc-precompiles.md section 4, "repo-sourced from the Fusaka notes"]
SHAKE256 (FIPS 202)	0x0AE5	60 base + 12/word	21,470	[CITED: aerenew/pqc-fork/precompiles/HashToPointPrecompiledContract.java lines 51-52 (BASE_GAS=60, GAS_PER_WORD=12); aip-draft section 3 table]
Falcon-512 (NIST round-3)	0x0AE1	40,000	86,336	[CITED: aip-draft section 4 and Reference table]
ML-DSA-44 (FIPS 204)	0x0AE3	55,000	351,050	[CITED: aip-draft section 6 and Reference table]
ML-KEM-768 (FIPS 203, encapsulation)	0x0AE6	60,000 (fixed)	n/a (KEM, testnet-only)	[CITED: aerenew/pqc-fork/precompiles/MLKEM768PrecompiledContract.java line 73 (GAS = 60_000)]
Falcon-1024 (NIST round-3)	0x0AE2	75,000	145,496	[CITED: aip-draft section 5 and Reference table]
SLH-DSA-SHA2-128s (FIPS 205)	0x0AE4	350,000	558,276	[CITED: aip-draft section 7 and Reference table]

All marginal-gas values are the scratch-fork (chain 28099) measured constants; the verify-and-record tx gasUsed values are on-chain receipts. [CITED: aerenew/research/aip-draft-pqc-precompiles.md Reference Implementation table] The five signature and hash precompiles (0x0AE1..0x0AE5) are live on mainnet 2800, activated at block 9,189,161. ML-KEM-768 (0x0AE6) and Falcon HashToPoint (0x0AE7) are KAT-validated on an isolated testnet and remain founder-gated for mainnet. [CITED: aerenew/pqc-fork/README chain, pqc-fork memory]

Scope reminder attached to this table: these precompiles are an application and account layer capability. They do not make Aere consensus post-quantum.

C.2 Two fresh cross-checks run this session

[MEASURED-FRESH] The SHAKE256 gas schedule (60 base plus 12 per word) is confirmed present in source, and the HashToPoint precompile's own gas was freshly computed from that exact source formula (gasRequirement, lines 78-93):

Falcon-512  (n=512)  32-byte message, 73-byte input:  words=38  -> gasRequirement = 516
Falcon-1024 (n=1024) 32-byte message, 73-byte input:  words=73  -> gasRequirement = 936

516 gas matches the source javadoc's "one ~500-gas staticcall" claim, which is the mechanism by which HashToPoint cuts a full Solidity Falcon-512 verify. This is the precompile's own intrinsic gas; it is distinct from the end-to-end verify gas below, and the two must not be conflated.

[CITED: aerenew/pqc-fork/results/bench-results.json] The HashToPoint-precompile optimization measured on the scratch fork (chain 28777), full Falcon-512 verify: 9,140,858 gas in pure EVM dropping to 7,186,367 gas with the precompile, a 21.4 percent reduction across 8 test vectors, all accept and tamper-reject checks passing.

C.3 The honest story the numbers tell

Post-quantum verification is materially more expensive than ECDSA. Ratios below are fresh arithmetic from the cited marginal-gas constants divided by the 3,000-gas ecrecover:

Scheme	Marginal gas	Cost vs ECDSA (3,000)
Falcon-512	40,000	~13.3x
ML-DSA-44	55,000	~18.3x
ML-KEM-768	60,000	~20.0x
Falcon-1024	75,000	~25.0x
SLH-DSA-SHA2-128s	350,000	~116.7x

So PQC verification runs roughly 13x (Falcon-512) to about 117x (SLH-DSA-SHA2-128s) the cost of an ECDSA recover. That premium is exactly what motivates two roadmap directions:

• Aggregation. Amortize one expensive PQC verify across many authentications rather than paying per signature. [VERIFY: the specific "AerePQAggregate" contract name is not found in the repo; PQC aggregation is a documented roadmap direction, see aerenew/docs/FRONTIER-PROGRAM-2026-07-12.md]
• Finality certificate. Carry post-quantum finality as a certificate over a finalized block rather than re-verifying PQC signatures per transaction. This ties to the dual-quorum PQ-consensus design work. [CITED: aerenew/docs/PQ-CONSENSUS-STEP2-2026-07-18.md] Note the scope line: this is design and attestation alongside QBFT, it does not make consensus post-quantum.

---

PART D: INDEPENDENT REPRODUCTION

D.1 The strongest benchmarks should be third-party reproduced

The credibility of every number above rises sharply when a party other than Aere reruns it. The honest reproduction candidates, in priority order:

• The Nethermind team (warmest angle). Aere already runs a patched Nethermind as a second client that validates and follows live chain 2800, and it runs the PQC precompiles and can produce QBFT blocks Besu accepts. [CITED: aerenew/docs/wp2-sections/09-governance-roadmap.md:199, 253; NETHERMIND-2ND-CLIENT-LIVE memory] That existing relationship makes them the natural first ask for an independent client-side reproduction of the precompile gas and the consensus behavior.
• A university lab. Cheap under a research grant and citable in a way a vendor benchmark is not; a good fit for the Block-STM correctness-and-scaling harness and the zkVM proving-time measurements, which are self-contained and need no Aere infrastructure.
• Explicitly NOT the expensive audit firms. The audit-firm budget is reserved for the security audit, which is a different deliverable from a performance reproduction. [CITED: aerenew/docs/mainnet_authority context; AUDIT-OUTREACH-2026-07-12.md]

The outreach kit is prepared by us. The actual third-party run and the relationship are founder and business gated, not something this report initiates.

D.2 The run-it-yourself manifest (REPRODUCE)

This report is the NUMBERS and how they were measured. The run-it-yourself commands live in the reproducibility bundle. Today that bundle is split across several committed files rather than one consolidated REPRODUCE.md; the honest recommendation is to consolidate them, but each is real and runnable now:

Domain	Where to run it	File
Block-STM correctness + scaling (Part A.3, freshly run here)	cd aerenew/parallel-executor && cargo test --release && cargo run --release -- bench and -- endtoend	aerenew/parallel-executor/BLOCKSTM-ENDTOEND-THROUGHPUT-2026-07-13.md section 10
PQC precompile KATs + gas (Part C)	aerenew/pqc-fork/run-kats.sh, aerenew/pqc-fork/bench/bench.py	aerenew/pqc-fork/ (results in results/bench-results.json, results/kat-results-*.json)
Reproducible Besu client build	docker build ... -f aerenew/node/Dockerfile.reproducible then aerenew/scripts/verify-besu-image.sh	aerenew/node/REPRODUCIBLE.md (note: public digest manifest publication is still roadmap, so the third-party comparison step is not yet live)
PQ-consensus reproduction	committed harness	aerenew/research-stage/formal-consensus/REPRODUCE.md, aerenew/audit-package-pq-consensus/REPRODUCE.md

[MEASURE: create a single top-level aerenew/REPRODUCE.md that indexes all four domains above with pinned commands, so a third party has one entry point]

---

Appendix: provenance summary of every number

Freshly measured this session [MEASURED-FRESH]:

• Block-STM parallel==sequential gate: PASS on all 4 conflict profiles (this Windows box).
• Block-STM 16-thread execution-phase speedup this box: low 4.36x, medium 4.96x, high 1.92x, pathological 0.43x.
• HashToPoint precompile intrinsic gas from source formula: 516 gas (Falcon-512, 32-byte message), 936 gas (Falcon-1024).

Cited from committed repo artifacts [CITED]:

• 273,000 TPS is a design ceiling, never measured (WHITEPAPER-V2, wp2-sections).
• 0.5 s block period, halved at block 2,138,451, single-slot QBFT finality (wp2-sections, genesis-subsecond.json).
• Rollup end-to-end harness ~247k to 270k TPS at gas=80, swinging 115k to 500k, not the L1 ceiling (BLOCKSTM-ENDTOEND section 7).
• Reference 16-core Block-STM ~8.3x to 9.4x exec, ~8.3x to 9.1x end-to-end (same artifact).
• SP1 Groth16 ~300k gas, ~260 to 356 byte proofs; measured records storage-proof 348,345, zkML 326,492, aggregation ~390k (spec-zk-stack; deployment artifacts).
• SP1 proving times: zkscreen ~72 to 75 s, over18 ~71 to 73 s, zkml-mnist ~200 to 205 s, aggregation Groth16 526.1 s (proof-aggregator-scale.json).
• RISC Zero Groth16 seal 260 bytes, 5.0.0-rc.1 (risc0-verifier-fix.json).
• Halo2 ~449,517 gas, 1,152-byte proof; KZG point-eval ~255,719 gas (deployment artifacts, spec-zk-stack).
• PQC marginal gas: Falcon-512 40,000, Falcon-1024 75,000, ML-DSA-44 55,000, SLH-DSA-128s 350,000, ML-KEM-768 60,000, SHAKE256 60+12/word; verify-and-record tx: 86,336 / 145,496 / 351,050 / 558,276 / 21,470 (aip-draft, precompile source, bench-results.json).
• P-256 ~3,450 gas (wp2-sections, aip-draft).
• HashToPoint optimization 9,140,858 to 7,186,367 gas, -21.4% (bench-results.json).

To measure [MEASURE] or verify [VERIFY] (open items):

• [MEASURE] Observed live mainnet sustained TPS over a real block window.
• [MEASURE] SP1 Plonk proving time, gas, proof size.
• [MEASURE] RISC Zero on-chain verify gas and proving time.
• [MEASURE] Halo2 proving time.
• [MEASURE] Wall-clock verification latency per prover.
• [MEASURE] Consolidated top-level aerenew/REPRODUCE.md.
• [VERIFY] The explicit block-space arithmetic behind 273,000 TPS.
• [VERIFY] Which genesis gas limit is live on 2800 (40M vs effectively unbounded).
• [VERIFY] ECDSA ecrecover 3,000 is a fixed protocol constant (not Aere-specific).
• [VERIFY] The "AerePQAggregate" contract name (not found in repo; aggregation is a documented roadmap direction).