Skip to main content
A Multichain Virtual Environment is a single testing environment that contains more than one blockchain network. You might attach Ethereum mainnet, Arbitrum, Optimism, and Base to one Virtual Environment, then work with all four under a shared identity. Each network keeps its own RPC endpoints, explorer view, and faucet, but they live together in one resource that you create, fund, and tear down as a unit. What a Multichain Virtual Environment adds on top of running separate per-network Virtual Environments is awareness across chains. The Bridge Module can detect cross-chain messages on one network and relay them to another in the same Virtual Environment, and the dashboard shows you one timeline of transactions across the whole environment.
Multichain Virtual Environments and the Bridge Module are available on plans that include multichain capabilities. Contact us to enable them on your account.
Virtual Environments list showing one Virtual Environment with Mainnet network, Network Mirror sync mode, and created timestamp

​
Common uses

  • Cross-chain protocol testing across Mainnet, Arbitrum, and Optimism, with bridge transactions running end-to-end.
  • Bridge integration validation against LayerZero, CCIP, and Across, with instant relay for happy paths and manual controls for failure modes.
  • Security testing for replay attacks, oracle configurations, and light-client implementations.
  • CI/CD pipelines that deploy and regression-test across multiple chains on every push.
  • Staging environments where a dApp runs against a multichain backend without real funds.
See the quickstart to create one, or Bridges for the bridge relay model.

​
How a Multichain Virtual Environment is organized

A Multichain Virtual Environment is one environment with one or more networks attached. The Virtual Environment has a consistent identity (name and slug). Adding or removing a network does not change the others. 
Organization
  > Project
    > Virtual Environment
        > Network: Ethereum
        > Network: Arbitrum
        > Network: Optimism
      > Enabled Features
          > Block Explorer (ON)
          > Bridges (ON)
          > State Sync (OFF)
You can mix production chains and testnets in the same Virtual Environment, drawing from any of the 100+ EVM networks Tenderly supports. Production chains appear first in the creation flow. See supported networks for the full list.
Create Virtual Environment form with the network dropdown open showing multiple EVM networks to choose from, and Bridge / Public Explorer toggles in the Advanced section

​
RPC URLs

Every network in your Virtual Environment gets a predictable RPC URL. The URL is unique per organization and Virtual Environment, with the network name as a first-class part of the path: 
https://virtual.<network>.<region>.rpc.tenderly.co/<org-slug>/<vnet-slug>
If your org is acme-protocol and your Virtual Environment is staging-v2: 
Ethereum:  https://virtual.mainnet.eu.rpc.tenderly.co/acme-protocol/staging-v2
Arbitrum:  https://virtual.arbitrum.eu.rpc.tenderly.co/acme-protocol/staging-v2
Optimism:  https://virtual.optimism.eu.rpc.tenderly.co/acme-protocol/staging-v2
Base:      https://virtual.base.eu.rpc.tenderly.co/acme-protocol/staging-v2
Each network endpoint follows the same pattern, so all URLs for a given Virtual Environment share the same org and Virtual Environment slug.
Virtual Environment detail page showing the Integrate Virtual RPC tab with Admin RPC URL, Public RPC toggle, Chain ID, and RPC endpoint setup steps

​
Virtual Chain IDs

By default, each network in a Multichain Virtual Environment uses a Virtual Chain ID. It combines a 7667xx prefix (hex for “tdly”) with the real chain ID. This prevents accidental replay between your Virtual Environment and the real network: a transaction signed for your virtual mainnet will not validate on real Ethereum, and vice versa. You can override this at creation time if your setup requires it, for example when a contract verifies a specific chainid value. Use the real chain ID, or a custom one, on a per-network basis.

​
Supported networks

Multichain Virtual Environments work on the same 100+ EVM networks the rest of Tenderly supports. See the supported networks page for the full list, including which products are available on which network. Bridge protocol coverage is narrower than overall network coverage. See Bridges for which protocols are live on which chains.

​
How it works with other Virtual Environment features

State Sync is per-network. Each network in a Multichain Virtual Environment can independently enable State Sync to track live mainnet state until a Virtual Environment transaction modifies a storage slot. Mix and match per network as needed. Network Mirror Mode is single-network. Combining Mirror Mode with a Multichain Virtual Environment isn’t currently supported. Each network has its own Admin RPC. Cheatcodes apply per network. tenderly_setBalance on the Ethereum leg will not affect balances on the Base leg. Each network has its own block time. The Virtual Environment does not synchronize clocks across networks. You control time per network using the Admin RPC time methods.

​
Programmatic access

Everything you can do in the dashboard is also available through the Tenderly REST API and the CLI. The tenderly-virtual-testnet-setup GitHub Action automates provisioning of parallel Virtual Environments for CI/CD pipelines, which is useful when you want a fresh multichain environment per pull request.

​
Next steps

Quickstart

Create a Multichain Virtual Environment, wire it into Foundry or Hardhat, fund accounts, and run your first cross-chain transaction.

Bridges

How the Bridge Module relays LayerZero, CCIP, and Across messages between networks, with dashboards and manual controls for failure testing.