Contact Details:
Team: Warptoad
Email: jjvalkema@protonmail.com | danisharbeit@gmail.com | franactis2@gmail.com
Discord: @jimjim.eth | @nodestarQ | @franacc_
Twitter: jimjim_eth | nodestarQ | Franacc_
github
Summary:
Warptoad is a crosschain privacy protocol that uses a privacy primitive we call “Toad Commitments” and the “GIGA-bridge”. Together they can be used to proof: “I deposited from an address from a chain”, not specifying which address or even which chain. This does not only make bridging private, but more importantly: the privacy set is the same on all L2’s. User do not have to bridge to get the best privacy set. And users that do bridge do not have to worry their privacy-set changing.
Users can transfer privately either on the same chain or bridge to another chain, for the user it feels like a native Bridge or in the case of staying on the same chain, like using no Bridge at all. The link between deposit and withdrawal is private and from what chain they came from.
The first implementation will focus on Aztec and other zk-rollups like Scroll and have a simple feature set similar to 0xBow. As our maing Bridge we will be using native messaging bridge.
On the aztec implementation, the bridge transactions are completely shielded.
Further more the “Toad Commitment” is privacy primitive that can be used in other forms of onchain privacy like UTXO based privacy like railgun, aztec or even something like zkWormholes. We believe “Toad Commitment” together with the GIGA-bridge are the way to build generalize crosschain private state.
Timeline:
Start: July 1, 2025
End: September 30, 2025
Milestones:
Unwrapping accounting Logic on L2s
Relayer for evm withdraws
Frontend MVP
Testnet Demo
“Cannonical” Bridge (for Aztec Devs)
About You:
JimJim: passionate about ethereum since 2018, dapp dev since 2022
Danish: Head of Web3 at byte5, Hackathons, 7 year dapp dev experience
Fran: Biomedical engineer. 8 years of product development and marketing.
Technical Approach:
The protocol is like 0xbow where we track commitments in a merkle tree and do inclusions proofs against inside zk like usual. However we deploy on multiple L2’s and then bridge over the roots with the GIGA-bridge to L1 where we hash all the roots off all the L2 instances into another merkle tree we call the GIGA-tree. That root, the GIGA-root is then send over the L2’s so user can prove against the GIGA-root instead. Because the GIGA-root contains all deposits of all chains, no-one know what chain the user deposited on.
We also input the local-root into the circuit, just in case a user that stays on the same chain doesn’t want to wait on a new GIGA-root. This allows users to withdraw withing the same block as their deposit if they have too.
We are allowed to only bridge these roots across asynchronously when ever we please since we used toad-commitments. A toad-commitment is like any other commitment but it also contains the destination chains chainId. Which is later revealed on withdraw to ensure the user can only withdraw on one chain. Which means we also don’t need to bridge the nullifiers!
On aztec we managed to make the bridge txs completely private by using the nullifiers and note-hash tree of aztec directly. And using the archive tree to read the GIGA-root that is bridged over.
Grant Amount Requested:
We request US$5000 for the deployment grant.
Budget Rationale: 2x full time engineers and 1x part time product marketing
future outlook:
With future funding can research internal shielded transfers like Railgun and/or EIP7503.
We also like to explore support hardware wallets.
In a lot of cases users need to swap their asset on aztec. We would like explorer on how to make that process as private as possible. either with p2p shielded trading, co-snarks, or homomorphism.
Exploring a market based solution to speed up bridging times. Something like hop-protocol or intents. But of course we would not reveal what chain we want to initiate the interaction from. Unlike current proposed approaches.
Using warptoad where multiple instance of aztec or aztec-like chains exist. For example: every time aztec upgrades. Users need to withdraw to L1 and deposit to the new L2. This is bad UX, reveals the users balance, and the new aztec chain will have it’s privacy set reset. Building a warptoad bridge would help bootstrap the privacy set, solve UX issues and makes the entire migration process shielded.