Setting an RPC
Every read and every send goes through an endpoint you choose, per chain.
The console does not run its own node. It talks to whatever RPC endpoint you give it, and it stores that choice per chain. A single shared endpoint would keep pointing at the previous chain after a switch, where every read is wrong and every send is rejected, so there is one field for each.
Where it lives
Settings, the RPC field. Switch the chain, set the endpoint for it. A saved endpoint in your browser always wins over the deployment's default; clearing the field falls back to the default.
Defaults
Each chain ships with a default public endpoint so the console is usable before you have found your own. Those defaults are served to every browser, which is why they never carry an API key. They are adequate for reading balances and for small runs; they are not what you want under a launch.
Public endpoints rate-limit. If you see reads failing in bursts, balances that lag, or a launch that cannot price itself, the endpoint is the reason before anything else is.
Choosing one
- Latency and head freshness matter more than throughput for launches. A lagging endpoint reports an old block height, and a bundle aimed at a block that has already passed cannot land. The launch runs six rounds, each aimed five blocks ahead of what the endpoint says is current; an endpoint two blocks behind eats most of that window.
- Archive access is not needed for day-to-day use. Nothing here reads historical state.
- On BNB Smart Chain the bundle builders are contacted directly by the server, not through your RPC. Your RPC still matters: it is where the console reads nonces, balances and receipts, and where non-bundled transactions are broadcast.
- On Robinhood Chain every transaction goes through your RPC, so a slow endpoint costs you the ordering the sequencer would otherwise have given you.
An endpoint sees every transaction you send through it, including the ones you would rather not broadcast. For a launch that matters, prefer an endpoint you control or one that offers a private mempool. On BNB Smart Chain the non-bundled paths already use a private relay for sending, but reads still go to your endpoint.
Symptoms of a bad endpoint
| What you see | What is happening |
|---|---|
| Balances that do not change after a transfer you can see on the explorer | The endpoint serves a stale state. Wait, or switch endpoint. |
could not be quoted in a log | An eth_call failed or timed out. Usually rate limiting. |
| A bundle "accepted" by both builders that never lands, round after round | The endpoint's head is behind the chain, so the target window has already passed. |
| Balances that flicker between two values | Requests are being load-balanced across nodes at different heights. |
429 or rate limit anywhere | Exactly what it says. Fewer wallets per run, or a paid endpoint. |
A quick test: set the endpoint, open Wallets and press refresh. The whole book is read in one call; if that takes more than a couple of seconds or fails, the endpoint is not good enough for a launch.