While rollups have helped scale Ethereum’s throughput by 15x, they have also introduced fragmentation. This fragmentation leads to siloed liquidity and breaks composability, making it challenging for users to interact across different applications within the broader Ethereum ecosystem. At 𝚝𝟷, our mission is to create a composable scalability solution leveraging Real Time Proving. RTP reduces capital requirements for solvers and reduces cost of bridging for users.
In this post, we’re introducing two new ideas:
Using 𝚝𝟷 and TEE-proofs in ERC-7683, we can reduce solver payment times and improve their capital efficiency by up to 60x (assuming a 1-minute vs. 60-minute payment window). In turn, this will lower bridging costs for users.
Using 𝚝𝟷 we can build an auction-based ERC-7683 bridge that delivers improved execution to users.
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 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:
Alice deposits funds to an escrow contract on the origin chain
A filler sends the tokens Alice wants to receive on the destination chain
There’s a process to verify settlement (step 2) on the destination chain
The proof is presented to the escrow contract on the origin chain, which releases the funds to the filler.
Current ERC-7683 settlement systems, such as Across Protocol, have demonstrated how cross-chain intents can unite Ethereum. Our 𝚝𝟷 settlement system builds on ERC7683, introducing key enhancements to further unify the Ethereum ecosystem.
How does 𝚝𝟷 contribute to ERC-7683 and intent bridges?
In the use case we described above, we replace the optimistic settlement verification process with Real Time Proving (RTP) enabled by 𝚝𝟷. By integrating TEE-enabled proofs, 𝚝𝟷 eliminates the need for Optimistic settlement. In other words, 𝚝𝟷 can reduces the settlement time from several hours (the time required for humans to manually dispute incorrect bundles coming through) to a few minutes. This reduces the payment time to solvers and creates tremendous capital efficiency gains and vastly improves solver profitability. The general take-away is capital requirement and payment time is positively correlated, meaning if we cut payment time by half, we also reduce capital requirement by half. These improvements are transferred to the user in reduced bridging costs.
Let’s do a back of the envelope calculation;
According to DeFiLlama (on February 12, 2025), Across facilitated ~$19.1mn bridging volume and 9507 bridge transactions in the last 24 hours on Ethereum, Optimism and Arbitrum.
Assuming bridge TXs happen in uniformed intervals, we have 1 txn approximately every 20 seconds on Ethereum and every 40 seconds on the rollups
Assuming bridge TXs are equal in size, if a solver is paid every 60 minutes, they need to hold $800K in inventory across 3 chains. If a solver is instead paid every minute, they only need to approximate $13,500 in inventory across 3 chains. This is a 60x improvement in capital efficiency.
This enhancement reduces fees for users bridging funds, as the relayer incurs a lower opportunity cost for fronting the funds.
Thanks to the ERC-7683 shared relayer network, relayers currently filling on Across can seamlessly start filling with the 𝚝𝟷 settlement system from day one, allowing both relayers and users to benefit immediately.
Additionally, emerging designs like Optimism’s Superchain ERC-7683 and Arbitrum’s Broadcast Standard align with ERC7683, further strengthening cross-chain interoperability.
The verifiable computation guarantees of TEEs, reiforced by 𝚝𝟷’s defense-in-depth, not only increase solver profitability but also allow us to improve execution quality for users. If you are thinking about auctions, you are right!
Auction-enabled RFQ bridges
Let’s first expand on our previous example. Instead of having funds on 𝚝𝟷 already, let’s assume Alice’s funds are on an origin chain, which happens to be a 𝚝𝟷 partner rollup. 𝚝𝟷 can serve as an auction-enabled RFQ bridge. Imagine the following workflow:
Alice deposits funds to an escrow contract on the origin chain (L1 or a 𝚝𝟷 partner rollup), with an intent to receive them on the destination chain. This escrow contract is the 𝚝𝟷 bridge contract on the origin chain.
Once step 1 is verified in 𝚝𝟷, Alice’s deposit is directed to an auction contract on 𝚝𝟷.
An auction is run on 𝚝𝟷 where fillers bid to fill Alice’s order and receive her tokens on 𝚝𝟷. The filler that pays Alice the most wins the auction. The auction contract creates a list of the highest-bidding fillers, the fill amount, and an expiry block on the destination chain until when the listed fillers can fill Alice’s order.Note: This approach does not require the filler to have funds on 𝚝𝟷
The winning filler sends tokens they bid in the auction to Alice on the destination chain, which is L1 or a 𝚝𝟷 partner rollup.Note: We can allow the smart contract to only accept fill orders from the winning filler for a given block/slot.
Step 4 is verified on 𝚝𝟷. The filler is credited with Alice’s tokens on 𝚝𝟷 (with a potential delay to account for reorg risk on the destination chain). The filler is then, as always, able to withdraw them to L1 or a partner rollups.
Today, the most popular intents bridge Across uses a leader-based method where a single relayer has exclusivity to fill Alice’s order on the destination chain. We believe an auction mechanism will be an improvement over existing implementations as filler competition will result in better execution for users.
What’s Next for 𝚝𝟷 and ERC-7683?
First, we want to acknowledge the amazing work that the Ethereum community, especially Across, Uniswap and Hyperlane, has done to put forward this standard.
Today, we’re excited to announce that we are part of 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’re currently building a proof-of-concept (PoC) intent bridge using ERC-7683 contracts on 𝚝𝟷 to demonstrate sub-1-minute payments to solvers. If you are interested in collaborating, please reach out to us. 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 𝚝𝟷
Appendix
The table below shows the capital requirement calculation based on Across bridge volume according to DeFiLlama on Feb 12, 2025. In our analysis we make the following assumptions;
All transactions are equal in size (avg. order size)
Bridge TXs follow a Poisson distribution, in other words bridge transaction occur in fixed intervals (time between TXs)
This calculation assumes a profit maximizing filler needs to have enough inventory to fill all of bridge demand on Across. Given these assumptions, the capital efficiency gains should be treated as a theoretical limit. Here’s a link to the spreadsheet.

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.