What each public endpoint is, and what it is not good for.
The endpoints
| Endpoint | What it is |
|---|---|
https://rpc.aere.network | Public JSON-RPC read endpoint |
https://rpc2.aere.network | Second public JSON-RPC endpoint |
https://client2.aere.network | Public JSON-RPC read endpoint served by the second, Nethermind-derived client, the tenth validator since 2026-09-11 (eth, net and web3 methods only; row added 2026-10-27) |
wss://wss.aere.network | WebSocket, for eth_subscribe |
wss://api.aere.network/ws | Second WebSocket endpoint |
https://explorer.aere.network | Block explorer, human-facing |
https://api.aere.network | Data API: recent blocks and transactions, an address balance; no per-address history (corrected 2026-10-27: this row said indexed history) |
All of them are operated by the AERE Foundation.
Which one for which job
Reading the chain right now: any of the three HTTPS endpoints (the third, client2.aere.network, serves the eth, net and web3 methods only). eth_blockNumber, eth_getBlockByNumber, eth_call, eth_sendRawTransaction and the rest of the standard set. (Corrected 2026-10-27: this said either HTTPS endpoint, from the time the table had two.)
Watching for new blocks: a WebSocket endpoint with eth_subscribe. Subscriptions are not available over HTTPS.
History for an address: not the RPC, and not the public data API either. Scanning blocks over RPC to find an address's transactions is slow and will time out, and the data API at api.aere.network keeps no per-address history: it serves recent blocks and transactions and an address balance (see Indexer API). Transfer history for an address is on Aere Cloud, /v1/data/transfers, with a key (corrected 2026-10-27: this said the indexer serves it).
Proving something about an account: eth_getProof, and only that. See the state window below.
The state window, and the false zero
The public RPC keeps state for 512 blocks. Beyond that window, state reads are refused: -32000 World state unavailable, and -32603 Internal error for eth_call (measured on rpc.aere.network and rpc2.aere.network on 2026-10-15). Until 2026-09-10, eth_getTransactionCount beyond the window returned a false 0x0 rather than an error.
client2.aere.network keeps state for a few hundred blocks, less than 512 and varying (measured 2026-10-27: it answered 250 to 300 blocks back and refused beyond), and refuses with -32002 No state available for block N (eth_call, eth_getBalance, eth_getCode, eth_getProof) or -32000 missing trie node (eth_getStorageAt): other codes and other messages than the first two endpoints. (Paragraph added 2026-10-27, and corrected the same day: it put eth_getProof under -32000 missing trie node; measured, it refuses with -32002.)
The false zero was the dangerous shape: an answer that looks like a measurement. A tool that read a nonce at an old block and concluded "this account has never transacted" was wrong, and nothing told it so. If your code was written against that behaviour, treat any error at an old height as "not answerable here", whatever its code or message, and never as zero. Prove facts about accounts with eth_getProof inside the window, which either answers or fails.
At 512 blocks and about 0.62 seconds per block, the window is roughly five minutes of chain.
A node that is down is not a node that says zero
If you build monitoring against these endpoints, treat "no answer" as its own state and never as zero. A node that is catching up may not answer RPC at all, and a peer count or a height read as zero in that moment is not a measurement of anything.
Rate limits and etiquette
The endpoints are public and unauthenticated. They are also a small number of real machines. If you need sustained throughput, run your own node: the package, the genesis and the exact options are published for that. See Run a node.