Network Mirror Mode

Network Mirror Mode keeps a Virtual Environment continuously aligned with its parent network. New mainnet blocks are absorbed into the Virtual Environment as they’re produced, and a UI-visible mempool collects any transactions you submit. Your transactions are prepended to the next synced block in the order they arrive.

​

When to use it

Use Network Mirror Mode when you need to evaluate behavior against live network conditions rather than a frozen fork:

• Test how your contracts behave against today’s oracle prices, pool reserves, or governance state.
• Stage a transaction and control when it executes relative to the next synced block.
• Pause the live network at a specific block to inspect state, then continue replaying.
• Compare your Virtual Environment’s storage, balances, or gas usage against mainnet baselines over time.

If you need a frozen point-in-time fork, use a standard Virtual Environment. If you need real-time state without mempool semantics or block-for-block ticking, use State Sync.

​

How sync works

A mainnet tick produces a Virtual Environment tick within roughly 12 seconds. Each tick brings in the next block’s transactions and applies them on top of your Virtual Environment’s current state. Transactions you submit sit in the Virtual Environment’s mempool until the next sync tick, at which point they’re prepended to the synced block in FIFO order. Your transactions execute first; the synced mainnet transactions execute after them, against the resulting state. A “live” indicator shows whether the Virtual Environment is keeping up:

​

Time controls

The time-control strip lets you move the Virtual Environment’s clock relative to mainnet. Each control maps directly to an RPC call you can also invoke from your own code: The speed picker (1×, 2×, 4×, realtime) maps to the tick delay between sync calls (12s, 6s, 3s, and no delay respectively). To check sync progress programmatically, use tenderly_getSyncStatus.

​

State drift lens

The State Drift lens shows where your Virtual Environment has diverged from mainnet. Useful for finding the contract or wallet your test actually moved. Three sub-views share one surface: The lens is scoped to the contracts and wallets you’re watching plus any contracts the current session has touched. It caps at 100 rows per sub-view.

​

Block-context fidelity

Network Mirror Mode commits to one-to-one parity with the parent network on the dimensions that most often affect contract behavior:

• Block-context alignment: block.timestamp, baseFee, coinbase, and prevrandao reflect mainnet values.
• Gas-market parity: current mainnet gas pricing applies to transactions you submit.
• Sub-tick latency: a mainnet tick produces a Virtual Environment tick within roughly 12 seconds.

​

Cheatcode behavior

Because Network Mirror Mode is continuously importing real blocks, some Admin RPC cheatcodes behave differently than on a standard Virtual Environment. The rule most users trip over: on a Network-Mirror-Mode Virtual Environment with sync active, cheatcodes called over RPC won’t take effect. Solidity precompile cheatcodes still work, but they apply on the next synced block, not immediately. Pause sync first if you need an Admin RPC cheatcode to take effect right away. See the Admin RPC reference for the full cheatcode list.

​

Mode comparison

​

Known limitations

• Single-network only. Network Mirror Mode applies per Virtual Environment; combining it with multichain Virtual Environments isn’t currently supported.
• No CSV/JSON export on the State Drift lens.
• No timeline scrubber. You can rewind by block count or click to jump, but there isn’t a draggable scrubber yet.

​

See also

• Admin RPC: sync methods
• State Sync
• Multichain Virtual Environments