Shadow RPC

Every shadow fork comes with its own Shadow RPC and a standard set of JSON-RPC endpoints. Shadow RPCs look and feel like a normal RPC, but contains additional shadow data that's custom to your shadow fork.

Each Shadow RPC is versioned, which allows you to safely deploy changes to your shadow fork and test them without disrupting previously running jobs.

Since your Shadow RPC behaves like a normal RPC, you can use it as a drop-in replacement in your own infrastructure (e.g. include shadow events in your custom indexer, or add shadow events to your self-hosted subgraph).

API keys

Every request to your Shadow RPC must include the API key in the header of the request. See the API keys page for more details.

Supported endpoints

Shadow RPCs currently support the following endpoints:

1. eth_chainId

2. net_version

3. web3_clientVersion

4. eth_blockNumber

We're working getting to 100% parity for all JSON-RPC endpoints. Don't see one you need? Let us know in our .

RPC frontfills

As soon as you deploy a shadow contract, your shadow fork RPC will start frontfilling new data within seconds. This means that you can request any data that is generated for new blocks that occur after the point of your shadow contract deployment.

RPC backfills

You can also tell Shadow to backfill your shadow fork RPC, which will trigger a background job that populates historical data going back to the genesis block. Once the RPC backfill job is completed, you'll be able to request any historical data for past blocks on your shadow fork.