Forking

To interact with contracts deployed on mainnet or testnet, you can use forking. Simulate the origin and experiment with it locally, making no changes to the origin itself.

$ starknet-devnet --fork-network <URL> [--fork-block <BLOCK_NUMBER>]

The value passed to --fork-network should be the URL to a Starknet JSON-RPC API provider. Specifying a --fork-block is optional; it defaults to the "latest" block at the time of Devnet's start-up. All calls will first try Devnet's state and then fall back to the forking block.

How it works

When you send a request to a forked Devnet instance, it first queries Devnet's local state, then tries the forking origin. Forking is not a step simply performed on Devnet startup, but happens continuously while the Devnet instance is alive.

Forking and ACCEPTED_ON_L1

Assume you have run Devnet as a fork from an origin at a block that is not yet ACCEPTED_ON_L1, but only ACCEPTED_ON_L2. If in your state queries you specify block_id: "l1_accepted", and there are no local blocks marked as ACCEPTED_ON_L1, Devnet will assume the forking block has become ACCEPTED_ON_L1.

Read more about marking blocks as ACCEPTED_ON_L1 on Devnet: link.

Account impersonation

Here you can read more about acting as an account deployed on the origin.

Deploying an undeclared account

Here you can read about deploying an account not declared on Devnet.

Checking forking status

To see if your Devnet instance is using forking or not, fetch the current configuration, and check the url property of its fork_config property. If Devnet is forked, this property contains the string of the origin URL specified on startup.