EVM Compatibility
Chain 2800 runs the EVM under Ethereum's Prague and Osaka rules, with one named exception; contracts and tooling work unchanged, and post-quantum additions live in precompiles, the header and one extra transaction type.
EVM compatibility means a chain runs the same execution environment as Ethereum: the same bytecode, the same account and transaction model, and the same JSON-RPC interface. A contract compiled for Ethereum deploys unchanged. Wallets, libraries, and developer tools connect without modification, because the surface they depend on is identical: opcodes, state layout, and RPC methods such as eth_call and eth_getStorageAt. On chain 2800 the rule set is Ethereum's Prague and Osaka, with one exception: the EIP-4788 beacon-roots system contract has no code here, so a contract that reads beacon block roots through it gets an empty answer.
AERE Network is a public EVM L1 with chain id 2800. Blocks are produced roughly every 0.62 s (500 ms target) under QBFT consensus among ten validators, with a quorum of seven. Any standard Ethereum client library can point at the public RPC, https://rpc.aere.network, and a second public read endpoint exists. A second, independently implemented client validates the chain alongside the first, Besu-derived client, and since 2026-09-11 it also proposes and seals blocks as the tenth validator (nine of the ten run the first client; corrected 2026-10-28: this sentence called the first client the producing client), which is what client diversity means in practice.
Where chain 2800 extends the EVM, it uses the EVM's own extension mechanism: the precompile. Five post-quantum precompiles have been live since block 9,189,161 at addresses 0x0AE1 through 0x0AE5, covering the Falcon-512, ML-DSA, and SLH-DSA families, validated against NIST test vectors on-chain. The post-quantum anchor lives in the block header, outside the execution layer, so contracts and tooling see an ordinary EVM chain. One addition does reach the transaction model: since block 19,900,000 (2026-09-23) the chain also accepts a native post-quantum transaction (AIP-20, type 0x50, signed with ML-DSA-87); ordinary transactions are unaffected and remain the default. Since block 24,300,000 (AIP-22 stage 4) every validator attributes a consensus vote only through its verified post-quantum seal, and since block 25,080,000 (AIP-22 stage 5) headers no longer carry ECDSA secp256k1 commit seals, while a commit still carries the ECDSA commit seal of its validator as an additional check (see finality); the post-quantum work adds to the EVM rather than forking away from it.
Verify it yourself
Verify it yourself: POST {"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1} to https://rpc.aere.network; the result is 0xaf0, which is 2800 in hex.