fakereum sandbox

Forked EVM sandbox

A signed transaction sent here executes locally; this server's sandbox state is layered atop https://arbitrum-one-rpc.publicnode.com (+5 failover) and never reaches the real chain.

Network name
Fake Arbitrum One
Chain ID
42161 (0xa4b1)
RPC endpoint
Etherscan API
Currency
FETH
upstream chain
Network
Arbitrum One (42161 / 0xa4b1)
RPC
https://arbitrum-one-rpc.publicnode.com
https://arb1.arbitrum.io/rpc
https://arbitrum.drpc.org
https://arb-pokt.nodies.app
https://arbitrum.gateway.tenderly.co
https://arbitrum-one.public.blastapi.io
replay guard

Anti-replay protection is on. A transaction whose signer already holds a native balance on Arbitrum One is refused — this sandbox shares that chain's ID, so such a signed tx could be replayed onto the real chain. Such an account sends signed messages instead; a wallet that is empty upstream transacts directly.

explore
etherscan api

The /api and /v2/api endpoints are an Etherscan v2-compatible proxy. Pass your own Etherscan API key (apikey=…) — it is required and forwarded upstream as-is. Requests go to Arbitrum One's explorer with chainid forced. Currently only the logs&action=getLogs module is supported; its response is merged with this sandbox's logs so your tooling sees local state alongside the real chain. Both paths are also returned by discovery below (etherscanApi / etherscanApiV2).

discovery

Detect this sandbox from a dapp without any custom RPC method. Wallets refuse to forward fakereum_* calls but always relay eth_call, so a call to the sentinel below (calldata ignored — no real chain has code there) returns the sandbox config, ABI-encoded as a single string of JSON:

eth_call({ to: "0x000000000000000000000000000000000000fa4e" })
↳ abi-decode the result to a string, then JSON.parse:

{
  "chainId":          "0x…",      // this sandbox
  "upstreamChainId":  "0x…",      // forked chain
  "networkName":      "…",
  "symbol":           "…",
  "rpc":              "…/rpc",     // JSON-RPC
  "etherscanApi":     "…/api",     // Etherscan v2 proxy
  "etherscanApiV2":   "…/v2/api",  // same proxy, /v2/api path
  "explorer":         "…",         // this explorer
  "upstreamRpc":      "…",         // real chain's RPC — check an account's upstream balance here
  "upstreamExplorer": { "name": "…", "url": "…" }   // optional
}
balances

Every account starts out holding 1000× its native balance on Arbitrum One, automatically — eth_getBalance and transactions here see that figure until the account's first sandbox transaction lands, after which the sandbox tracks the balance itself. Funds on another chain (Ethereum, Arbitrum, Base, Robinhood Chain) can be imported once per account at the same multiplier, authorized by a personal_sign message.

send with a signed message

Besides eth_sendRawTransaction, a transaction can be submitted as a plain personal_sign (EIP-191) message. The signature is chain-agnostic, so the wallet can sit on any network — no sandbox chain added, no switch. The message binds nonce, recipient, value and calldata; gas limit and fee terms are passed unsigned alongside (defaulted wallet-style when omitted). The sandbox then runs a normal transaction from the signer. Ask for the text (pass from and the sandbox reads the nonce for you), have the wallet sign it, post fields + signature straight to /rpc:

fakereum_transactionMessage [{ from?, to, value?, data?, nonce? }]   → { message, nonce }
fakereum_sendTransaction    [{ to, value?, data?, nonce, gas?, gasPrice? | maxFeePerGas?, maxPriorityFeePerGas?, signature }]
                            → tx hash

Fakereum Tx #13 on Fake Arbitrum One
To: 0x…                                   (EIP-55 checksummed)
Value: 0.001                              (only if > 0; up to 10 decimals, so wei % 1e8 == 0)
Data: 0x12345678 and 68 bytes with hash 0x…   (only if data non-empty; tail only past 4 bytes)

Fields are named and hex-encoded as in eth_sendTransaction. The same signed message is accepted once — a resend answers already known.

Which path an account should take is the sandbox's call: fakereum_accountKind [address] answers { kind: "upstream" | "sandbox", pinned }upstream (holds native token on the real chain) must send signed messages and must not be asked for EIP-712 signatures; sandbox uses the normal wallet flows. The verdict is pinned for good by the account's first sandbox transaction; reads before that follow the live upstream balance.