FAQ: Virtual TestNets

For migration to TestNets from Forks or DevNets, contact our support team. The migration process will retain the entire state of your Fork/DevNet and seamlessly move it to a TestNet.
We recommend migrating since TestNets are more performant and scalable.

You can create a TestNet in two ways:

• From the Dashboard UI
• Using the TestNet REST API. See an example here.
• By forking an existing TestNet.

Set a custom chain ID that’s different from the parent network’s chain ID.

Recommendation: Add the prefix 7357 (test) to the original network’s Chain ID. For example, if you’re creating a Virtual TestNet by forking the Ethereum Mainnet (chain ID: 1), set your Virtual TestNet chain ID to something like 73571.

This is recommended for several reasons:

• Since the Virtual TestNet chain is independent of the Mainnet chain, it should have an independent and unique chain ID.
• Using a unique chain ID is a security measure that protects your dapp against transaction replay attacks.
• Wallets, such as MetaMask, will recognize that the original chain ID is already in use and will potentially mistake your TestNet for the parent network unless it uses a unique chain ID.

You can fork an existing TestNet after deploying contracts and setting up your TestNet state by funding accounts, sending transactions or using Admin RPC.

• Intact starting point: By using a forked TestNet to develop or experiment, your starting point remains clean from changes.
• Working copy per team member: After staging smart contracts, your team members can do their work on their own working copy of the network.

When using Virtual TestNets to deploy smart contracts, members of your Tenderly Organization will have direct access to the Virtual TestNet.

After deployment to TestNet, you can distribute chain and contract configuration so builders of other components such as UI, APIs, and data indexing can connect to staged contracts.

Here are some recommendations:

1. Stage contracts to TestNet.
2. Fork the staging TestNet for each team (frontend, backend, etc.) to ensure boundaries between teams and reduce test-data noise in development.
3. Update all relevant git repos with TestNet config and contract information:
• Chain config: share the chain ID and Admin RPC (so other builders can control chain state)
• Contracts’ ABIs
• Contracts’ deployment addresses
4. When developing locally (UI, backend), switch to the TestNet.
5. Share failing transactions to smart contract developers

When staging your dapp for external and demo testing, make sure that:

• Stage your contracts to a Virtual TestNet.
• Stage all your offchain components (backend, data indexing solutions, etc.) and have them connect to the TestNet.
• Connect your staged dapp via Public RPC (not Admin RPC) and connect it to other offchain components.

Instead of reverting state, it’s recommended to fork an existing TestNet instead and do your testing on a disposable working copy.

You can Revert TestNet state if testing steps aren’t repeatable otherwise.

For easier distinction, prefix your TestNets with virtual (e.g. virtualMainnet). This is particularly useful for integrations such as Viem, HardHat, and others.

Alternatively, include the purpose in Virtual TestNet’s name:

• internalTestingMainnet
• demoMainnet
• dataInsightsMainnet
• ciMainnet
• bugBountyBase
• frontEndDevOptimism
• communityTestingAvalanche

Virtual Testnet’s Public explorer adheres to verification visibility for contracts you deploy and verify on the TestNet:

• Full: the public block explorer will display the entire source code of all functions
• ABI-only: the public block explorer shows only function and events’ names and signatures, including argument names. This way your source code remains invisible outside of your project.
• None: only show the final outcomes of transactions, without revealing the source code, or method names.

No, TestNets do not support WebSockets at the time.

State Sync enables TestNet to track the live state of the original network .

• Until a TestNet transaction modifies a storage slot, the TestNet tracks the current value from the original network.
• After a TestNet transaction modifies a slot X in a contract C, any subsequent read will yield that value. The unmodified C.Y will reflect the value from the original network.

State sync tracks state, but does not synchronize nor display original network

• transactions
• event logs
• blocks

Behavior of mainnet contracts that cache block.number is unpredictable when running TestNet transactions, since the block number grows at different rates on mainnet and TestNet.

When using the Unlimted Faucet in the Dashboard, 1 means 1 ETH, both for native and ERC-20 balance. In case of ERC-20 tokens, Tenderly automatically calculates the exact amount in wei, using the ERC-20 number of decimals.

Public RPC allows the standard JSON-RPC interaction. This is the RPC you’ll use to integrate into your dapp’s UI or backend when you’re ready to demo your dapp externally.

Admin RPC supports additional RPC methods allowing higher control over the network state and storage, as well as account balances. This is the RPC you’ll use in your deployment scripts for programmatic network control.

You can successfully send transactions using any sender address via Dashboard. Tenderly will run those transactions on TestNets without checking signatures.

Gas usage reflects the accurate gas usage of all OPCODES from the original network. You can get gas usage:

• in Transaction Overview via Dashboard,
• via tenderly_estimateGas for single-transaction estimations with 100% accuracy
• via tenderly_estimateGasBundle for estimation of multiple transactions with 100% accuracy