How Real Time Proving (RTP) Enhances Intent Bridging
Reduced costs for users, lower capital requirements for solvers.
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.