Skip to main content
The Bridge Module connects the networks in a Multichain Virtual Environment. With it enabled, a source-chain transaction that emits a bridge event triggers the corresponding delivery on the destination chain within the same Virtual Environment. Relay runs in the mode you configure (immediate or delayed) and uses no real funds. Fund the source side from the built-in faucet.
The Bridge Module is available on plans that include multichain capabilities. Contact us to enable it on your account.

​
Enabling the Bridge Module

Open the Bridge tab in your Virtual Environment, switch to Settings, and expand the Advanced panel. Check Bridge (“Enable cross-network bridge”), then Save Changes. Once enabled, relay covers every supported protocol on the networks attached to the Virtual Environment. Two settings control how messages are relayed:
  • Relay mode: Auto relay delivers the destination transaction as soon as the source event is detected. Delayed relay holds delivery for a fixed interval so you can test in-flight timing and destination-chain latency.
  • Delayed relay seconds: the delay applied in Delayed relay mode (for example 3600).
Bridge settings Advanced panel showing the Bridge enable checkbox, a Relay mode dropdown set to Delayed relay, a Delayed relay seconds field set to 3600, and the supported protocols Layer Zero, Chainlink, Across, and CCTP with descriptions
The module only relays where the protocol contracts are already deployed. If a protocol is not present on a network in your Virtual Environment, that route is not available. The Bridge contracts panel shows which protocol router contracts are deployed per network.

​
Supported protocols

ProtocolWhat it relays
LayerZeroOmnichain messaging protocol with configurable security. A source PacketSent triggers the destination delivery (lzReceive).
Chainlink CCIPChainlink’s cross-chain interoperability protocol. A source CCIPMessageSent triggers the destination delivery (for example manuallyExecute).
AcrossIntent-based bridge with optimistic verification. A source V3FundsDeposited triggers the destination fill.
CCTPCircle’s Cross-Chain Transfer Protocol for native USDC transfers across chains.

​
Supported networks

Bridge protocol availability is narrower than overall network support because the Bridge Module relies on the real protocol contracts being present on a given network. Initial coverage:
ProtocolInitially supported networks
LayerZeroEthereum, Arbitrum, Optimism, Base, Polygon
Chainlink CCIPEthereum, Arbitrum, Optimism, Base, Polygon
AcrossEthereum, Arbitrum, Optimism, Base, Polygon
CCTPEthereum, Arbitrum, Optimism, Base, Polygon
Coverage expands based on customer demand. If you need a specific network enabled for a bridge protocol, reach out to your Tenderly contact.

​
Bridge dashboard

The Overview tab gives you operational visibility into all bridge activity in the Virtual Environment:
  • Top routes: each source-to-destination network pair, its protocol, and the number of relayed operations.
  • Bridge contracts: the protocol router contracts deployed on each network, with network, contract name, address, and protocol.
  • Bridge transactions: a list of every relayed operation with its status, source network and transaction, destination network and transaction, protocol, and relative time. An auto-refresh interval control keeps the list current.
Bridge Overview tab showing a Top routes panel (route, protocol, relayed count), a Bridge contracts panel (network, name, address, protocol), and a transaction list with status, source and destination networks and transactions, protocol, and relative time
To confirm a round-trip, find the source transaction (for example a LayerZero PacketSent) and follow its row across to the matching destination transaction (lzReceive).

​
Bridge operation detail

Selecting a row opens the bridge operation, which shows the protocol, the overall status, and the chain of transactions that make up the cross-chain message: each step’s network, status, function (for example verify, lzReceive), block, transaction hash, sender, recipient, and gas used. An Input viewer renders the decoded message payload (srcEid, dstEid, guid, options, sendLibrary) with a Decoded/Raw toggle.
Bridge operation detail page showing protocol layerzero with completed status, a table of constituent transactions with functions verify and lzReceive and their gas used, and a decoded input payload with srcEid, dstEid, guid, options, and sendLibrary fields

​
When to use bridging

ScenarioUse
Cross-chain dApps, bridges, governance, and multi-chain protocol logicMultichain Virtual Environment with bridging on
Single-network development with no bridge concernsA standard Virtual Environment per network
Live-network rehearsal on a single chain, with a visible mempoolNetwork Mirror Mode

​
See also