How SEAL Simulates Cross-Chain Communication on Virtual TestNets
"Virtual TestNets are critical when doing the drills and setting everything up in a consistent, repeatable, and easy way. If I were just testing locally, I would probably be able to set it up using Anvil, but the purpose of these drills is collaboration, so Virtual TestNets are a key component of our EVM-based drills."
Isaac Patka
SEAL Wargames initiative lead and co-founder of Shield3
Security Alliance (SEAL) and Shield3 run emergency response drills, called Wargames, to prepare protocol teams for operating in crisis mode. Starting as a non-profit community of security experts and researchers, the team has always strived to secure DeFi for users, which is crucial as the space continues to see greater adoption.
The team provides essential training for emergencies, such as exploits, phishing attacks, and critical failures by simulating realistic scenarios in well-structured drills, also known as wargames. The teams can practice detection and response in a controlled environment before real incidents take place, thus increasing success rates in emergencies.
The teams undergoing drills come from different backgrounds, such as DeFi protocols, L2 scaling solutions, and infrastructure providers. Some of the teams that previously completed the drills include Compound, Aave, Yearn, Uniswap, Optimism, Base, Lido, and Origin Protocol.
The technical setup for each drill involves L1 and L2 network forks on Virtual TestNets, replicated production environments with a built-in block explorer and debugging tools. It also requires a monitoring service for tracking cross-chain flows. Depending on the specificities of each team, frontend and backend are set up and connected to fork RPCs, as well as any additional services that teams usually use in real emergency responses.
The manual work behind the initial setup
The initial setup required Isaac Patka, the SEAL Wargames initiative lead, to run Anvil on a Digital Ocean Droplet. He would then connect this instance to a Blockscout Explorer. While the setup itself was straightforward, syncing the explorer was time-consuming, adding even a couple of days of work on top of the initial setup.
The setup also required a lot of manual steps and configuration. The team had to set up a Docker container to run Anvil and make sure the right ports were exposed. He would also set up Nginx for routing and DNS.
Additionally, since most of the teams deploy on multiple L2s in addition to Ethereum Mainnet, a cross-chain setup became even more time-consuming, For instance, for a cross-chain scenario that tested rollup mechanisms, the drill required the SEAL team to launch a rollup using Conduit and live networks on top of Sepolia before hooking up all the additional infrastructure. The team would then deal with a lot of configuration to set up and connect a bridging UI to the rollups.
The cross-chain setup on Virtual TestNets
A lot of teams deploy their DeFi contracts on Ethereum Mainnet and different L2s, with governance interfaces between chains using a messaging system to pass commands. For instance, when a governance proposal or an emergency action happens on L1, requiring a contract change on L2, the message needs to be relayed and executed on L2.
The SEAL drills simulate this L1<> L2 message passing on Virtual TestNets in a realistic and consistent way, expanding their initial setup on Virtual TestNet to simulate cross-chain messaging on parallel network forks.
“It’s trivially easy to set up a fork of Mainnet and a fork of Optimism with Virtual TestNets, and with a single click, you also get an explorer.” – Isaac Patka, SEAL Wargames initiative lead & co-founder of Shield3
How cross-chain messaging works on Virtual TestNets
To set it all up, the SEAL team uses Tenderly API to spin Virtual TestNets at the correct block number and output RPCs to a local network config file. This file is integrated with the rest of the infrastructure scripts, including a cross-domain messenger service and monitoring service.
Simulating cross-chain interactions using scripts
When using scripts, the drill generates a random wallet and uses the unlimited faucet on Virtual TestNet to fund USDC balance to the address on L1. He then uses the new wallet to submit 1000 USDC to the standard Optimism bridge (proxy) contract on L1.
This action emits an event, i.e. a new transaction to be relayed on L2. The L2 message gets relayed by impersonating a messenger address. On L2, the relay message comes from the same messenger address Optimism uses to relay messages, recreating the actual onchain behavior.
For this purpose, the SEAL team uses a Virtual TestNet Admin RPC method to impersonate the messenger address and send a transaction. So, on Virtual TestNets, the drill impersonates a transaction from this address using the message that needs to be relayed which ends up minting the USDC and relaying the message on L2.
In the Tenderly Dashboard, the team can inspect the list of all emitted events, including ERC deposit initiated, bridge initiated, transaction deposited, and send message. These are all standard Optimism events that teams usually monitor onchain.
Simulating cross-chain interactions using bots
In addition, the SEAL team runs a message relayer bot, a monitoring service, and bots to impersonate actual users. This setup picks up all of the messages relayed from L1, adds them to a queue, and sends the messages that haven’t been relayed to L2.
This cycle involves 3-6 wallets to initiate random bot actions and relay all the messages. The unlimited faucet on Virtual TestNet comes in handy, allowing SEAL to easily fund bot accounts with any amount of test tokens.
What scenarios SEAL simulates on Virtual TestNets
Each SEAL Wargame is unique to the protocol team itself, replicating their day-to-day setup to ensure realistic emergency training. However, while the drills are different, they usually involve bridging tokens or arbitrary message passing between two Virtual TestNets.
To write and test the drills, the SEAL team typically uses Foundry as most of them are written in Solidity, except when using JavaScript/TypeScript and Hardhat for offchain infrastructure or bots and monitoring.
Here are some of the scenarios simulated on Virtual TestNets:
- Bridging ETH and ERC-20 tokens from L1 to L2
- Pushing an oracle update through an arbitrary messenger
- Simulating a governance action where a standard governance executor on L2 accepts messages from an L1 messenger contract. In this case, when a contract on L2 needs to be upgraded, the proposal is passed on L1, gets sent across the bridge, and upgrades the contract on L2 using the governance executor as the contract owner.
When simulating these scenarios on Virtual TestNets, the SEAL team introduces a subtle bug to initiate an emergency drill. For this purpose, the team uses Virtual TestNet Admin RPC or, more precisely, the tenderly_setCode method to impersonate a specific action.
{
"jsonrpc": "2.0",
"method": "tenderly_setCode",
"params": [
"0x1",
"0x1"
],
"id": "1234"
}
For instance, emergencies may involve a multisig doing a faulty contract upgrade that has a bug, an oracle update from a faulty source causing tokens to get overvalued, or gas optimizations causing unexpected contract behavior.
For all of these scenarios, getting production data is essential to ensure realistic conditions. So, all balances and contract states on Virtual TestNets are in sync with real network conditions. Otherwise, the SEAL team would have to redeploy contracts every time when running drills.
How protocol teams use Virtual TestNets during drills
Once the setup is ready, the teams undergoing the drills connect to Virtual TestNets using public RPC URLs. They can use the RPC URLs to run any code on top of them as if they were a real production network.
For this purpose, having distinct Admin and Public RPC URLs on Virtual TestNets is helpful as the teams can participate publicly without interfering with the drill setup on Virtual TestNets. However, in some cases, SEAL shares Admin RPC with the teams as well, allowing them to impersonate accounts when needed.
“Virtual TestNets are critical when doing the drills and setting everything up in a consistent, repeatable, and easy way. If I were just testing locally, I would probably be able to set it up using Anvil, but the purpose of these drills is collaboration, so Virtual TestNets are a key component of our EVM-based drills.” – Isaac Patka
Most importantly, a lot of teams already use Tenderly in their incident response processes, so having the same UI during the SEAL drills makes them more realistic. For instance, Lido would do a cast from the local command line to simulate transactions in Tenderly or use Tenderly Debugger to inspect contract upgrades, troubleshoot errors, and see where tokens aren’t adding up.
Making DeFi safer with SEAL Wargames on Virtual TestNets
With the DeFi space becoming increasingly multichain and reaching greater adoption, ensuring protocol teams’ resilience and emergency preparedness is essential for securing end users. Virtual TestNets allow the SEAL team to run realistic cross-chain scenarios while minimizing the manual work needed. As the underlying infrastructure, Virtual TestNets streamline the entire setup, enabling both SEAL and the teams undergoing the drills to focus on what matters.
As SEAL continues to expand the Wargames framework with new chains, Virtual TestNets will continue to be a key infrastructure component. To try them out yourself, head over to the Tenderly Dashboard and fork a chain using Virtual TestNets.
