Today, we will explore how programmability and real-time proving enabled by 𝚝𝟷 create further efficiency gains in the intent-based interoperability efforts of the Open Intents Framework introduced by the Ethereum Foundation.

In an earlier post, we introduced how 𝚝𝟷 and Real Time Proving (RTP) increases capital efficiency for solvers and therefore reduce bridging costs for users in intent bridges. While RTP can reduce the capital requirement, programmability allows us to:

1. Offer efficient cross-chain swaps for users

2. Provide cross-chain loans to reduce cross-chain liquidity fragmentation for solvers.

At 𝚝𝟷, we are driven to create pragmatic solutions that push cross-chain user experience. For readers new to 𝚝𝟷, the 𝚝𝟷 architecture post can be a helpful pre-read. 

Before we dive in, I’d like to thank Wee Howe, Hart Lambur, Joshua Baker, Luca Donno, Evan Chipman and Orest Tarasiuk for their invaluable feedback and contributions.

How does programmability increase cross-chain swap efficiency?

In our earlier post, we also discussed using auctions on 𝚝𝟷 to provide improved execution to users in intent bridges.

To quickly recap, Across, the most popular intent-based bridge, has two different modes to identify the solver for Alice. The first model is First Come First Serve (FCFS), where solvers compete on speed. The downside of this model is higher gas cost for solvers: multiple solvers can send onchain TXs and pay gas, yet only one solver gets to fill Alice’s order. The second model, which is currently being slowly rolled out, is an exclusivity-based method where a single relayer (solver) can to fill Alice’s order on the destination chain. We propose running an auction to determine which solver would pay Alice the highest amount on the destination chain. We believe competition improves execution for Alice. We propose to run an auction where solvers compete to fill the cross-chain swap order.

When we look at cross-chain swap bridges like Squid, deBridge and Mayan, they run centralized off-chain auctions similar to UniswapX and 1inchFusion. Off-chain auctions create an efficiency gain by outsourcing the expensive on-chain price matching (price discovery) and allowing efficient liquidity allocation free of transaction fees. Yet these auctions sacrifice pricing transparency and create a single point of failure.

We think we can do better with 𝚝𝟷! Let’s consider the use case where Alice has ETH on Arbitrum and wants to get USDC on Base. With 𝚝𝟷, we can enable the following workflow:

1. Alice deposits ETH to an escrow contract on Arbitrum, with an intent to receive USDC on Base. This escrow contract is the 𝚝𝟷 bridge contract on the origin chain. Based on ERC-7683, Alice’s intent also includes the minimum USDC she’s willing to receive on Base.Note: Escrow contract does not need to be the 𝚝𝟷 bridge contract on the origin chain

2. Once step 1 is verified in 𝚝𝟷, Alice’s deposit is directed to an auction contract on 𝚝𝟷. The reservation price for this auction is the minimum USDC Alice is willing to receive based on her intent.

3. An auction is run on 𝚝𝟷 where solvers bid USDC to fill Alice’s order and receive ETH on 𝚝𝟷. The solver, Bob, has the highest bid to fill Alice’s order. The auction contract creates a list of the highest-bidding solvers, the fill amount, and an expiry block on the destination chain until the listed solvers can fill Alice’s order.Note: This approach does not require the solver to have funds on 𝚝𝟷

4. Bob, the winning solver, sends tokens they bid in the auction to Alice on the destination chain (L1 or a 𝚝𝟷 partner rollup).Note: We can only allow the smart contract to accept fill orders from the winning solver for a given block/slot to avoid fill collusions on the destination chain 

5. Step 4 is verified on 𝚝𝟷. Bob, the solver is credited with Alice’s tokens on 𝚝𝟷 (with a potential delay to account for reorg risk on the destination chain). The solver is then, as always, able to withdraw them to L1, or  partner rollups.

We believe running a transparent smart-contract-based auction on 𝚝𝟷 is a significant improvement over running an opaque centralized auction on a centralized server. We believe transparency improves execution for users and we are here to enhance cross-chain user experience.

Cross-chain lending: Borrowing on Destination Chains with Collateral on 𝚝𝟷

While real-time proving (RTP) reduces the capital requirement for solvers, liquidity fragmentation remains a challenge. Even with ERC-7683, solvers still need pre-funded liquidity on multiple chains to fill cross-chain orders, making the system capital-inefficient. 

To address this, we introduce cross-chain lending, allowing solvers to borrow liquidity on the destination chain from retail users while using their assets on 𝚝𝟷 as collateral. This approach increases solver capital efficiency and creates a yield opportunity for retail liquidity.

Instead of requiring solvers to hold idle funds across multiple chains, 𝚝𝟷 allows them to borrow from users on the destination rollup while securing the loan with collateral on 𝚝𝟷. We call this cross-chain lending with 𝚝𝟷.

Let’s go over the following use case:

• Alice wants to move 1000 USDC from Arbitrum to Base.

• solver Bob has 1 ETH deposited in a cross-chain margin (collateral) account on t1. Bob has received the 1 ETH on t1 after filling Alice’s cross-chain swap order earlier (see example above).Note: By allowing solvers to get paid on t1 by default, we can enable the solvers to accumulate collateral on t1 required for cross-chain margin accounts.

• Charlie is a DeFi user on Base with USDC. He deposited his USDC to a smart contract (lending pool) on Base to earn yield. The lending pool on Base has provided spending permissions to the t1 bridge contract. Note: The lending pool on Base can also be the t1 bridge contract on Base.

Bridging stage:

1. Alice deposits 1000 USDC to an escrow (t1 bridge contract) on Arbitrum, with an intent to receive USDC on Base. Based on ERC-7683, Alice’s intent also includes the minimum USDC she’s willing to receive on Base.

2. Once step 1 is verified in 𝚝𝟷, Alice’s deposit is directed to an auction contract on 𝚝𝟷. The reservation price for this auction is the minimum USDC Alice is willing to receive based on her intent.

3. An auction is run on 𝚝𝟷 where solvers bid USDC to fill Alice’s order. The maximum solver Bob can bid is equal to his collateral on t1 multiplied by a collateralization ratio. Note: Let's assume that the lending pool on Base has sufficient deposits to fulfill the order. 

4. Bob wins the auction and sends a TX to the t1 canonical bridge contract on L1 to prove i) he has won the auction and ii) he has locked funds in the cross-chain margin account. 

5. Bob sends a request to borrow funds on Base. Smart contract on Base checks L1 for proof of collateral on t1 and disperses 1000 USDC to Bob. At this point, Bob starts to accrue interest. Bob’s collateral on t1 is locked. 

6. Bob transfers the funds to Alice.At this point, the bridging operation is complete.

Loan repayment stage:To unlock his collateral on t1, Bob must repay the principal and the interest. 

• Happy path: Bob pays back Charlie (lending contract) the principal and interest on Base to unlock his funds on 𝚝𝟷

• Default: Bob fails to pay. Charlie sends a t1 transaction to liquidate Bob’s collateral on t1.

Note: Since Base is a t1 partner rollup, t1 can track Bob’s position and verify payment or default on the loan.

By managing solver collateral and allowing them to fill bridging demand on different rollups, t1 becomes a cross-chain clearing house. This approach also reduces the capital requirement to become a cross-chain solver. Solvers on L1 DEXs and intent bridge solvers are different entities and the latter need to take inventory risk. The proposed method will allow players like PropellerHeads to potentially participate in these cross-chain fills.

How do all of the pieces come together?

𝚝𝟷 enabled intent bridges to create a faster and cheaper user experience by creating a more capital-efficient system for solvers, accelerating solver repayments, and reducing capital requirements for solvers. Each solver has a profitability target. If they get paid once a day, they need to make that profit in a single TX. If they are getting paid 100 times a day, then the profit can be spread out across 100 trades, resulting in better pricing for users.

Solvers are repaid on 𝚝𝟷 and can choose to move funds to the chain with the most opportunity in a manual or automated manner. 

Each step we take to enable a more efficient system for solvers is a step towards a better and cheaper user experience.

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

In the last few weeks, we announced that we are contributing to the Open Intents Framework, spearheaded by the Ethereum Foundation. We presented a solution in the L2 Interop Working Group that reduces solver repayment time from 60 minutes to a minute. Two weeks later, we built a working demo, which shows a solver getting repaid in less than a minute!

We focus is on improving solver profitability and reducing bridging costs by leveraging 𝚝𝟷’s Real-Time Proving (RTP) capabilities. Our pragmatic approach focuses on solving user problems and improving the UX. When all rollups will achieve RTP, we will not need solvers. Until that day arrives, they play a huge role in solving cross-chain liquidity fragmentation.

In the future, we want to add auction functionality and cross-chain loan contracts to t1-enabled intent bridges. 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.