Virtual Lab’s goal is to take useful, existing crypto products and make them simple to use. First, we reimagined the traditional rollup and eliminated latency with the Virtual Rollup. Next, we cut wallet frictions and gas fees with the Virtual Wallet. Now, we continue our mission of onboarding the first billion users into Web3 with the announcement of the Virtual Bridge.
.png)
Web3 Is Walled Off
Some dApps are only on specific chains. Crypto users must then spread their assets across multiple accounts to access all of what Web3 has to offer. It’s difficult to do this, so users tend to remain on their preferred blockchain. This lowers dApp participation, increases redundancy, and inhibits growth for new chains who face the “cold start” problem.
The first solution is for dApps to deploy on multiple chains, but this creates a lot of technical overhead and security risks. The second solution is on the user-side: bridging.
The issues with bridging, however, are obvious. There have been billions lost to hacks, wait times are long and cumbersome, and cost is high even on L2s. Furthermore, the user must also research and interact with a new website just to use an application on a different chain. It is too complicated.
The best solution is one that allows dApps to deploy on one chain, but access all Web3 users, and empowers users to do this without wait, cost, or risk: A Virtual Bridge.
Virtual Bridge
As with every “virtual” product, whether it be a Virtual Rollup, Virtual Wallet, or Virtual Network, Virtual Lab's goal is to drastically eliminate overhead for the developer and create a better user experience.
The Virtual Bridge will be an SDK that can be installed in under an hour that expands a dApp’s possible audience from the users on just their chain to all Web3 users. Before, a game built on Arbitrum could only be played by the chain’s 2.1 million users. But with the future Virtual Bridge, the Arbitrum-based game could be played by all 26 million (excluding BTC) Web3 users (Source: DUNE). Installing the Virtual Bridge SDK could expand a dApp’s audience over 10x.
Even more, this is good for the blockchains themselves. The Virtual Bridge provides a boost to new chains without active users or developers suffering from the cold start problem. It is a risk for developers to build on new chains before there are people there. Now, dApps can have the same access to users previously only possible by building in the biggest ecosystems like Polygon, Arbitrum, and Optimism.
For the user, this means storing funds on their desired chain - Ethereum, Solona, ZKSync - and engaging with a dApp without ever realizing they were on a different chain. Finality is reached on the dApp’s desired chain, and the complicated experience of changing gas tokens, waiting, and revoking permissions on a bridge is eliminated for the user.
Too Good to be True
You would be hard pressed to find a Web3 native who does not believe this is a serious problem in crypto that needs a solution. The issue is purely on the technical side - making the Virtual Bridge a reality. While this vision is some time away, here is how we imagine it in practice.
The Virtual Bridge will utilize atomic swaps. According to Chainlink, “Atomic swaps are a way for two people to trade tokenized assets across different blockchain networks without relying on a centralized intermediary to facilitate the transaction.” Let’s walk through an example to see how this works:
Scenario: Alice is on Polygon and wants to buy a derivative asset on a dApp on Arbitrum using USDC.
Bridge: Before, Alice would need to bridge USDC from Polygon to Arbitrum. Next, she would need to bridge $MATIC for $ARB to pay for gas. Finally, she could buy the asset. This process would cost several dollars in bridging fees and take between 10 and 20 minutes. Here’s the alternative:
Virtual Bridge: Alice sends the necessary USDC from her Polygon environment and receives the derivative instantly.
Here’s how this is possible:
1. Alice and the dApp create a multisig
2. Alice’s USDC on Polygon is paid for by her existing $MATIC and enters a holding contract on Polygon
- Unlock condition 1: The contract will forward the USDC to the dApp’s wallet on Polygon if it receives the full multisig
- Unlock condition 2: The contract returns the USDC to Alice’s Polygon wallet if the multisig is not received within two minutes
3. The dApp’s derivative asset enters a holding contract on Arbitrum
- Unlock condition 1: The contract will forward the derivative asset to Alice’s wallet on Arbitrum if it receives the full multisig
- Unlock condition 2: The contract returns the derivative asset to the dApp’s Aribtrum wallet if the multisig is not received within one minute
4. The dApp signs their part of the multisig and sends this to Alice over a P2P network
5. Alice then signs the multisig herself and sends it to the Arbitrum contract, releasing the asset and delivering it to her Arbitrum wallet
6. The dApp is now guaranteed to have access to the complete multisig as it is publicly viewable in the Arbitrum contract. It takes this and commits to Polygon, atomically releasing Alice’s USDC
7. The transaction has been trustlessly completed!
Benefits:
- Trustless with no third party or centralized entity involved
- Maximum wait period is two minutes, but the minimum is several seconds, assuming both parties are live
- Cost is no more than 2x gas on the more expensive network
- No third party application to revoke permissions on. The user communicates directly with dApp
- The dApp expands their possible user base from those just on Arbitrum to on all chains
Drawbacks:
- Alice must have gas tokens on Arbitrum
- The dApp’s USDC is stuck in Polygon
- Alice’s derivative asset is stuck in Arbitrum, and not viewable in her Polygon wallet
- This only works within networks that share a public/private key pair, i.e., EVM
Virtual Labs can improve the atomic swap process to create a Virtual Bridge, further removing the inefficiencies outlined above through a Virtual Sequencer, Virtual Liquidity, and a Virtual Wallet:
Virtual Sequencer
Alice will not need to have gas tokens on Arbitrum, or even ever open another chain through the introduction of the Virtual Sequencer. The Virtual Sequencer, run by Virtual Labs, can receive Alice’s multisig and commit it to Arbitrum on her behalf - so she does not need to obtain $ARB and open the network. Because Ontropy cannot forge the multisig, the Virtual Sequencer cannot release the funds without her permission.
In the best scenario, Virtual Labs submits the multisig for Alice, delivering the asset to her without her need to hold $ARB for gas or ever even need to open an Arbitrum RPC. However, there are some concerns of which you should be aware.
In a bad scenario, Virtual Labs does not submit Alice’s multisig and the transaction does not go through. Again, because Alice controls her own keys, only she can sign the multisig and only she can release funds. But if she orders Virtual Labs to send the multisig to Arbitrum, so she doesn’t need to switch RPCs, Virtual Labs could refuse, or experience an outage. This could be harmful with quickly moving asset prices, but incentives would not often align to make this attack profitable.
There is a worse scenario. Virtual Labs could receive the multisig and let the Arbitrum locking period expire, allowing the derivative to be returned to the dApp. Virtual Labs could then share the multisig with the dApp directly and allow them to withdraw Alice’s USDC from the Polygon holding contract, which has not yet expired.
For those wondering why there is an offset in the locking periods, it is because the dApp must first sign the multisig, theoretically placing them in a vulnerable situation as their counterparty, Alice, has their agreement, but they do not have hers. The extra minute between the Arbitrum and Polygon release periods ensures that the dApp will have enough time to collect the full multisig that Alice commits on Arbitrum, and commit it to Polygon.
Returning to the worst case scenario, trustlessness can be achieved through the usage of other sequencers: a decentralized sequencer network. Because the multisig must only be submitted once, Virtual Bridges maintain a minimum trust assumption. Therefore, Alice should not submit her multisig to just the Virtual Sequencer, but to FairBlock, Astria, and Espresso as well. This decentralization of the sequencer network means that the Virtual Sequencer cannot refuse to submit the transaction, as another one of the hundreds of sequencers within these other protocols will complete it to earn the reward.
Again, because the multisig will be shared with the decentralized sequencer network, and the Arbitrum holding contract must only receive it once, only a single sequencer would need to be trusted, a far more secure model than the traditional 51% trust assumption.
This system of Virtual Sequencers means that Alice can easily use any dApp on any chain directly from within her Polygon wallet. This is huge.
Virtual Liquidity Pool
To address the fact that the traditional atomic swap model will leave the dApp’s USDC stuck on Polygon, when they prefer finality and all assets in one place on Arbitrum, a Virtual Liquidity Pool must be created.
Now, there is a common belief that cross-chain bridging is technically challenging. This is true, evidenced by the $2.6 billion in exploits. However, atomic swaps have enabled trustless transfers for some time but have never taken off, despite support from Vitalik.
The reason is that this technical challenge is paired with an immense need for liquidity. To “transfer” the dApp’s USDC from Polygon to Arbitrum, what is really happening is that the USDC is given to a middleman on Polygon and distributed to the dApp on Arbitrum. This middleman owns both wallets, so their value doesn’t change.
The same atomic swap/Virtual Bridge process can be used to complete this transfer, but the challenge is coordinating liquidity so that this process can be completed quickly. There are a few solutions to this:
- Third party liquidity providers
- Virtual Labs-supplied liquidity
- Virtual Liquidity Pool
The simplest solution to bridging this USDC is to use existing liquidity. Virtual Labs could initiate and process a bridge using well known protocols like Wormhole or Hop. The problem here is quite obvious: these relatively centralized bridges can be hacked, and are also quite expensive and slow.
Virtual Labs cannot unilaterally supply this liquidity either as volume on the Virtual Bridge would quickly rise above our current capital capacity.
The final option is a coordinated effort from Virtual Labs, blockchains, dApps, and users to form liquidity pools on desired chains. If, say, $100,000 was raised on each of Polygon and Arbitrum, then the dApp could initiate an atomic swap with the Virtual Liquidity Pool, depositing some capital into the VLP’s Polygon wallet, and removing some from its Arbitrum wallet.
Of course, demand could unbalance liquidity between chains, but this could be rebalanced through lowering the Virtual Bridge fee and increasing liquidity provider rewards on chains with low liquidity. Or, it could be done through making large, infrequent bridges to other protocols.
While Virtual Labs could deposit some liquidity as a show of trust, the vast majority of the pool would be supplied by blockchains, dApps, and users.
These incentives make sense. L1s and L2s are incentivized to deposit liquidity so that protocols on their network can access the Virtual Rollup. The Virtual Bridge will begin on a small number of chains, so depositing more liquidity will help the strength of the entire protocol and accelerate the possibility for Virtual Labs to expand to their chain.
For dApps, providing liquidity ensures that their users can easily access their application. Although the example we’ve been using did not demonstrate this, some protocols that have P2P interaction, like games and DEXs, bypass the dApp entirely. These protocols involve two counterparties on different chains that want immediate finality—the transaction cannot result in assets being stuck on different chains like the dApp’s USDC on Polygon. These parties will need to transact directly, so liquidity is needed upfront. This will encourage dApps to provide some capital to lower onboarding time for users outside of the main chain.
Finally, users may want to become liquidity providers to earn yield. Users can deposit funds into the Virtual Wallet to engage with protocols using Virtual Rollups. When dormant, this capital can be used for liquidity, and users can be compensated for it.
It should also be noted that while chains, dApps, and users are all possible sources of liquidity, it may not be necessary for all of them to participate in the Virtual Liquidity Pool. I predict that chains will be the VLP’s biggest source of liquidity, and that providing capital may be too high of a burden for many dApps. In times of high traffic, those dApps and chains that have supplied their own liquidity can be prioritized, and those who did not may experience higher wait times until liquidity becomes available.
The point of creating “Virtual” products is to make them easier to use. The Virtual Bridge accomplishes this for users and our partner dApps: zero-wait finality and zero-gas transactions for users, and zero-hassle installation for protocols. On the user and protocol level, risk is completely mitigated as well, with atomic swaps being theoretically trustless. Of course, nothing is ever 100% risk free, and malware and misrepresented UIs can cause problems. However, compared to bridges and their billions in losses, the Virtual Bridge eliminates counterparty and third-party risk by ensuring atomicity and enabling user-validated swaps.
Virtual Wallet
The penultimate concern to address is that Alice’s derivative asset is stuck on Arbitrum, whereas she uses Polygon. In the scenario where this asset was a token, like USDC, then the above Virtual Liquidity Pool solves this problem. However there are some assets, like NFTs or derivatives, which must remain on the host chain to fit into larger protocols. Virtual Labs makes no claim that these assets can be ported over to other chains and still function properly within an ecosystem. After all, an individual Y00tz owner cannot bridge their NFT from Polygon back to Solana without the entire collection moving.
Instead, what Ontropy aims to do is to create an experience where the user becomes unaware of underlying chains and complexity. The equivalent is a stock trader opening an account with Fidelity, but being indifferent to where assets are boused between the Nasdaq, NYSE, or other exchanges.
The Virtual Wallet accomplishes this. You can see a proto-version of the Virtual Wallet. Assets are stored between all accounts and displayed in one place. So, Alice would see her $MATIC tokens that live on Polygon and her derivative asset on Arbitrum in the same place. No manually adding tokens or networks to MetaMask.
.png)
Beyond EVM
The final drawback I’ve considered is that this approach would only work when the user’s public key can be used on the dApp’s chosen chain. For example, Alice’s address on Polygon is the same on Arbitrum, so assets can be sent and stored there even if she has never directly interacted with the network. A valid question is, how can this be done for chains like Solana or Polkadot?
This is a much more difficult product to build. With non-EOA users, the same auth key could be used to control funds on multiple chains. Similarly, a scheme could be developed to create a wallet on, say, Solana and store these keys on the user’s device. When the asset needed to be moved, the user could unlock the funds biometrically.
For users with EOAs, Virtual Labs could tie a smart contract wallet on the new chain to the user’s existing wallet. The SC wallet would be predefined to listen to events from 0xAB…89, so the user would only need to initiate an on-chain transaction on the blockchain they are accustomed to in order to access these assets. However, this would require a cross-chain messaging or relayer system in a way that might not be fully trustless.
In short, we’re doing research into this area, but supporting our existing and prospective customers, who predominantly use EVM, as well as proving the viability of the concept first, is our top priority.
Security Benefits
As with all of Virtual Lab’s products, the Virtual Bridge uses a user-validated, minimum trust assumption model. This means that every participant can individually prove the fairness of the events, and there is no social consensus or majority-rule mechanism.
There are also indirect security benefits through the reduction of dApp overhead. The protocol can build on the best chain that supports their features, not compromising to attain more users that may not support privacy or security curves, for example. Reaching finality on the dApp’s preferred chain further improves overall Web3 health and security as protocols need not worry about deploying multiple contracts in multiple languages and receiving multiple audits.
The Virtual Bridge is decentralized. The user and protocol swap cross-chain through atomic swaps, which involves minimal risk compared to bridges that are centrally processed through a company-operated multisig. Here’s why that’s a problem:
.png)
The Virtual Bridge enables cross-chain transactions to be as secure as the underlying blockchain itself, while improving accessibility to all.
Thank you for reading! If you enjoyed this post, follow me and Virtual Labs on X and subscribe below to receive next week’s article directly in your inbox.
Sources
Bridge Exploits Cost $2B in 2022
Another crypto bridge attack: Nomad loses $190 million in ‘chaotic’ hack
Wormhole digs out of its hole with new security measures to move on from $320M hack
Axie Infinity’s Ronin bridge halted after a massive $600 million hack
Binance Hit By $570 Million Blockchain Bridge Hack
Arbitrum Boasts More Active Users Than Base and Optimism: Report
