Introduction

The fragmented nature of blockchain ecosystems presents a significant challenge within the industry. Numerous solutions have emerged to address this, aiming to enhance interoperability across different chains. These include enabling interactions with decentralized applications on other chains, facilitating token swaps between disparate chains, and allowing the exchange of native assets for their wrapped counterparts. However, current solutions tend to focus on specific, point-to-point integrations and often target proprietary smart contract endpoints. These approaches lack the more general-purpose ability that is required for truly unifying systems and liquidity.

Our approach differs by building the first truly unified liquidity lending protocol by verifying interoperability interactions between the different smart contracts with zero knowledge proofs end-to-end. This enables the same atomic composability as shared sequencers and super builders offer without a trust component on sequencer design. As each transaction and proof is ultimately settled on mainnet, we can also achieve Ethereum level security with the Ethereum-like lending experience across rollups.

The protocol design prevents security issues by verifying each transaction on each underlying chain with a zero knowledge proof, ensuring that each transaction has been executed correctly and on the correct execution environment (e.g on the specified chain).

For end users, the underlying infrastructure will be abstracted away, and the interaction with the protocol will provide exactly the same experience as interacting with a traditional lending protocol on a single chain. The protocol will offer a global pool of assets accessible across all supported chains, with a unified interest rate. Users have the ability to select a chain if they are specifically planning to borrow in pursuit of a specific investment opportunity on a given chain, but they can also leave the routing up the to the protocol for gas efficiency.

This is all in stark contrast to existing solutions that merely connect exiting lending protocols across chains, with a centralized bottleneck (General Message Passing protocol) providing communication between these smart contracts.

Architecture: Synchronized Asset Network

Let’s take a look at this from the end-user perspective:

The end user has a free flow between all the supported chains. They can deposit on Linea, borrow on Arbitrum, repay on Optimism and withdraw on Ethereum mainnet. All of the mentioned chains are completely interchangeable with protocol supported chains.

ZK Coprocessors are verifiable computation components that generate a proof off-chain and can be easily verified on-chain to ensure correct computation was employed in each step of the process.

The protocol uses this to prove:

• State of the host chain (Linea) that maintains the state of the protocol on the extension chains

• User transactions on extension chains, recorded on the host chain to reflect state changes

Why is this important? With these two major steps we can ensure the same robustness behind the money market as if it were deployed on a single chain in an asynchronous environment.

This enables us to treat the pools of the same asset across Ethereum mainnet and its major rollups as a global pool, with global interest rates.

The last component that we require is value transfer between the pools in a secure manner, which is solved by intent-based bridging. The protocol submits intent-based orders to rebalance the pools as needed daily, and if unpredictable orders arrive, it can also do so on-demand. By leveraging an intent-based bridging solution, the protocol maintains control of the assets, preventing the loss of funds.

Liquidation Design

While the design of the host chain and extension chains are optimal for latency and security purposes - as the protocol needs to coordinate and unify multiple async environments - liquidations need to enable global repayment of debts.

For this reason, a liquidation transaction can be submitted on either a host or an extension chain, and the transaction requires proof of transfer of the auction price. This can be done on a different chain, it is possible to submit multiple proofs from different chains, therefore enabling global repayments from multiple chains, where the liquidator coordinates the transactions and generates the proofs.

The full list of proofs to successfully liquidate are:

• Proof of negative account liquidity globally

• Proof of repayment of debt on any of the supported chains (can be combination of repayments)

This imposes technical requirements on the liquidator’s side, but this group of protocol users are identified to have the technical capabilities to generate proofs.

By enabling global liquidations, it unifies liquidity for the ecosystem, which also enables a truly scalable unified liquidity lending protocol, as the total fund of liquidators limits the maximum market size of the lending protocol.

User Flow

While unifying the backend is relevant, user accounts are fragmented by each chain, as actions can only be executed from the specific chain.

The main issue is that users would need to switch between chains and sign multiple transactions for each asset on each chain, but instead, we allow one click supply, borrow, repay and withdraw across chains.

To solve this UX issue without existing solutions, the protocol leverages account delegation for end user interactions as the main solution.

This solution works for both smart accounts and EOAs by the following method:

• During an onboarding process, the user delegates limited access to a smart contract component on each chain they use

• Based on the specific delegation, the smart contract interacts with an off-chain trigger of sufficient security

  • For example, users can set spending limit to $100 for supplying, preventing unwanted action by the delegation

• The final controller behind the delegation is a controlled by the user on one chain to enable one click supply from 6 different chains as the optimal user experience.

• This is also suitable for Safe multisig institutional users where the address and access keys can be completely different.

Proof Composition

The protocol uses a design where the ledger of the money market is stored on a host chain (Linea), but each extension chain is able to record and modify transactions on the ledger. Therefore, each transaction on extension chains has a corresponding transaction on the host chain.

To ensure security, we require proofs that verify the computation and state of the host chain on the extension chain and vice versa.

To satisfy this, we verify that each transaction has:

• A computational proof to verify correct execution

• A state proof to verify the correct execution environment

The combination of these two proofs ensures that the transaction was executed in a specific way, and that the execution environment is also correct via the state proof.

Use-cases and examples

Increased capital efficiency and better access to capital for trading activities

• Trading strategies, just like market making activities, gain a similar capital efficiency increase. Users can directly leverage their funds to find the best yields across L2s

• Time-sensitive opportunities can captured better than before, as the user can keep their funds in the protocol and quickly borrow the required funds needed for investments.

Unified global accounts across chains

• The protocol enables the creation of global accounts by combining EOAs and/or SCAs and manages these at the protocol level to provide a quick and easy access and management from one of these with specific actions

• This is supported by the account delegation framework to enable session key-like access to the global accounts

Market making and arbitrage activities across multiple L2s

• These strategies by traders and trading entities can utilize the protocol to increase capital efficiency, let’s use an example to understand the effect:

  • Alice has 6 million USDC that she wants to use to capture value by market making or arbitrage opportunities

  • Currently, she would have to divide that across chains, leaving her with an average of 1 million USDC for such activities

  • More return is generated on the large orders, but the current method caps it at 1 million

  • Using the protocol she would be able to borrow 90% of the funds on any chain, leading to 5.4 million cap for the largest trades (an increase of 5.4x)

Increased utility for native L2 tokens

• Currently, major native tokens cannot be used as a collateral to borrow on other chains

• In the global pools of the protocol, major native L2 tokens will have an increased utility as they will serve as collateral without introducing bridging risks

• It will also reinvigorate value creating in the ecosystem as more and more projects can launch directly on L2s without limiting their scope in the ecosystem. Native L2 stablecoin projects have been gaining traction and they add a lot of value to the ecosystem

Conclusion

The goal of Ethereum scaling was to increase throughput and not to fragment liquidity. Our solution is built to solve this issue. Widespread institutional adoption can’t happen without deep liquidity and global liquidity protocols from the ETH ecosystem - a prerequisite for DeFi to grow. Our protocol builds on two key components made for this to happen, ZK technology which enables verified computation plus Account Abstraction which enables programmable accounts to simplify multi-level, cross-chain interactions for the best UX.