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.
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.