How 𝚝𝟷 Leverages ERC-7683 for Fast and Seamless Cross-Chain Withdrawals

Fast and Seamless Cross-Chain Withdrawals

We recently wrote about how 𝚝𝟷 and Real Time Proving (RTP) increases capital efficiency for solvers and therefore reduces bridging costs for users in intent bridges.

In this post, we will be exploring how integrating ERC-7683 into 𝚝𝟷 allows us to:

1. reduce withdrawal time from 𝚝𝟷 to partner rollups by half and, 

2. enable more efficient cross-chain transactions by eliminating the dependency on t1 bridge contract liquidity.

For readers new to 𝚝𝟷, the 𝚝𝟷 architecture post can be a helpful pre-read.

I’d like to thank Wee Howe, Tokka Labs team, Hart Lambur, Campbell Easton, Bobby Bola and Orest Tarasiuk for their invaluable feedback and contributions.

How do cross-chain withdrawals to partner rollups work on 𝚝𝟷?

𝚝𝟷 has its canonical bridge contract on Ethereum and non-canonical bridge contracts on partner rollups. The canonical bridge contract serves as the ultimate source of truth for 𝚝𝟷’s state.

Before a withdrawal request to a partner rollup can be processed, the corresponding 𝚝𝟷 state must first be verified on Ethereum L1. Once confirmed on the L1, the deposit contracts on the partner rollup will release the funds to the user.

To be more precise, 𝚝𝟷 nodes submit a tuple of trie roots (state trie, withdrawals trie), along with a TEE proof (and later, an AVS consensus proof plus bespoke ZKP), to the canonical bridge contract on Ethereum. Once validated on-chain, this new trie root tuple enables claiming withdrawn funds.

A withdrawal request on 𝚝𝟷 to a partner rollup is a unique transaction that burns funds on 𝚝𝟷 and creates a new entry in the withdrawals trie. The partner rollup bridge contract verifies the claim transaction which must carry a withdrawals trie inclusion proof from the 𝚝𝟷 canonical bridge contract. If valid, the partner rollup bridge contract releases the withdrawn-and-claimed funds to the designated recipient on the partner rollup.

Limitations

A naive approach introduces liquidity limitations and latency during withdrawals. 

Withdrawals from 𝚝𝟷 to partner rollups are capped by the liquidity of the 𝚝𝟷 bridge contract on the partner rollup. This is the case in any liquidity-based bridge.

A further limitation is related to delays involved in withdrawing to partner rollups. The process of withdrawing, as described above, has two steps: 

1. On L1: Canonical bridge contract verifies the 𝚝𝟷 trie root tuple on. This usually takes 1 L1 block.

2. On partner rollup: Partner rollup bridge contract verifies the user’s withdrawal trie inclusion proof (claim tx) accepted by the canonical bridge (L1). This will be slower as the partner rollup contract will want to mitigate the risk that the L1 could reorg such that the withdrawal inclusion proof is no longer acceptable (note: *most* L1 reorgs are shallow, typically only 1 L1 slot deep).
   

In total, withdrawals to partner rollups can, therefore, take several L1 blocks. ERC-7683-enabled RFQ bridges today can do faster bridging in exchange for a small fee.

How does ERC-7683 work?

There are 4 main steps in a cross-chain transaction enabled by ERC-7683

Figure 1: Cross-chain transfers with ERC-7683

Here’s a brief overview of these steps:

1. Alice deposits funds to an escrow contract on the origin chain

2. A filler sends the tokens Alice wants to receive on the destination chain

3. There’s a process to verify settlement (step 2) on the destination chain

4. The proof is presented to the escrow contract on the origin chain, which releases the funds to the filler.

How does ERC-7683 enhance 𝚝𝟷 UX

So the good news is that we can use ERC-7683 to address these limitations. By integrating ERC-7683, we enable anyone with funds on the destination chain to become the counterparty to Alice’s withdrawal transfer. This mitigates liquidity limitations and provides a path to faster withdrawals.

The use-case we are interested in is when Alice has funds on 𝚝𝟷 and wants to withdraw to a partner rollup. Let’s dive deeper:

• The escrow contract shown in Figure 1 can be emulated by the 𝚝𝟷 bridge contract. 

• Since Alice already has her funds on 𝚝𝟷, she only needs to send a simple 𝚝𝟷-native tx to put funds in escrow (step 1). 

• Alice’s account receives funds on a partner rollup from the filler (step 2). 

• Since the partner rollup full node is run inside a 𝚝𝟷 node, 𝚝𝟷 can verify the settlement on the destination chain (i.e., on the partner rollup) and post that proof to L1 (step 3). 

• Thus, 𝚝𝟷 can quickly allow the filler either to claim Alice’s locked funds on 𝚝𝟷 or to withdraw them to L1 or any 𝚝𝟷 partner rollup.

Note: We can delay the payment to the filler to mitigate the risk that the partner rollup reorgs and Alice is out of funds after the filler withdraws funds out of 𝚝𝟷.

What’s Next for 𝚝𝟷 and ERC-7683?

Last week we announced that we are contributing to the Open Intents Framework, spearheaded by the Ethereum Foundation. Our focus is on improving solver profitability and reducing bridging costs by leveraging 𝚝𝟷’s Real-Time Proving (RTP) capabilities. Our approach is pragmatic and is focused on solving user problems and improving the UX.

We have an internal proof-of-concept (PoC) intent bridge using ERC-7683 contracts on L1 to demonstrate sub-1-minute payments to solvers. Here’s the demo video. If you are interested in collaborating, please reach out to us. One idea we have is to build an auction contract on 𝚝𝟷 that allows the highest paying filler to facilitate Alice’s cross-chain transaction.

Let’s work together to make Ethereum faster, more secure, and truly interconnected. Stay tuned for updates and join the conversation on Twitter.

Can Kisagun, CEO & Co-founder of 𝚝𝟷