Partnered With:

CASPIAN -- A new AMM design powered by Layer 2

Read this article in 13 Minutes

StarkWare's new vision for Layer 2 native AMM.

CASPIAN: A New AMM Design Driven by Layer 2

Original source: Ethereum enthusiasts

conclusion

· Funding efficiency was one of the biggest concerns when building the DEFI solution on Layer 2.

· Reason: Liquidity will be spread between Layer 1 and multiple Layer 2 solutions.

· Caspian: A Layer 2-powered AMM design that we proposed. This AMM keeps assets on Layer 1, effectively preventing liquidity fragmentation and improving capital efficiency.

· Starkex 3.0 (starting in June 2021) will support Caspian. It will contain two new components needed to implement Caspian: Layer 1 Limit orders and batch-long Flash loans for Batch transactions.

background

AMM is an important DeFi tool. Its core features -- autonomy, composability and guided liquidity start-up -- make AMM the first cornerstone of DEFI LEGO. Since the advent of Bancor and Uniswap, the AMM design space has expanded in many directions: from specialized markets (Curve) to general-purpose markets (Balancer) to fickle loss awareness markets (Dodo and Bancor V2).

How does AMM fit into the rapidly evolving Layer 2 domain?

To date, all Layer 2 AMM designs have required the entire AMM to be transferred to Layer 2, including fluidity, resulting in fragmentation of Layer 1 fluidity.

Our proposed Layer 2-driven AMM design preserves liquidity on Layer 1 while allowing users to trade on Layer 2.

This design not only involves the Layer 1 liquidity provider, but also:

Store liquidity in other Layer 1 Defi protocols (such as Bentobox and Balancer V2).

Implement Cross Layer 2 AMM (click here for details).

So what's a Caspian?

concept

Caspian is a Layer 2-powered AMM solution. As in the case of the Caspian Sea, the largest lake in the world, the Caspian AMM not only allows mobility to move between different Layer 2 solutions, but also prevents fragmentation of mobility at Layer 1.

Caspian uses an off-chain operator to batch Layer 2 transactions. This operator is the only entity that trades with the (L2 driven) AMM contract on Layer 1. It mimics the logic of AMM contracts and provides quotes based on the state of the Caspian AMM at the start of a batch of transactions, as well as the Layer 2 transactions included in that batch.

After processing a batch of trades, the operator matches the net balance of the trades with the AMM contract, which is driven by Layer 2, to complete the settlement. The operator must emulate the logic of the contract and apply it to the correct account state to ensure that the Layer 1 contract can act as a counterparty to the Layer 2 trade.

participants

Under the chain

Operator: A risk-free market maker that exists on Layer 1 and each Layer 2 protocol. Operators act as coordinators. Its sole purpose is to match traders for each batch and match the net difference from each batch with the Layer 1 contract. Operators use STARK certificates to settle each transaction. Note that the only assumption of trust here is that the operator will rank the transactions fairly. To solve this single point of centralization, we can decentralize the operators themselves.

Trader: Alice and Bob are both traders with money on Layer 2.

Liquidity provider: Carol is a liquidity provider on Layer 1.

On the chain

AMM smart contract powered by Layer 2: This contract is a standard AMM interface with two major changes:

· Only the Operator can be counterparty to this Layer 1 contract.

· Withdrawal shall be made after AMM Cooldown Period (ACP). Why do you need ACP? Suppose that down the chain, the operator provides a quote to Alice. If Layer 1 AMM's liquidity increases, the quote will be higher. Conversely, if AMM is less liquid, the offer will be lower. So deposits can be immediate, but withdrawals must wait until a batch of transactions has been processed.

Starkex: A smart contract that connects AMM logic to the Starkex scalability engine down the chain.

New features

As mentioned above, Starkex will soon add two features: Layer 1 limit orders and flash credit for batch transactions. We covered the Layer 1 limit order feature in Defi Pooling (see Chinese version at the end of this article). Now let's introduce flash loans for batch transactions.

Lightning credit for batch transactions breaks the previous limit of lightning credit for a single transaction. Instead, it can extend the loan term to the life flow of a batch transaction. L2 operators can use this function to mint tokens on L2, provided that the tokens must be destroyed at the end of the batch transaction.

This improves the efficiency of the operator as an intermediary, simplifying the process of combining multiple limit orders and routing transactions within Layer 2.

Basic operation

Layer 2 trading

1.Alice/Bob asks the operator for a quote/agrees to the operator's quote.

2. These quoted orders are matched by Operator itself. To avoid liquidity idling, operators can initiate flash loans for batch transactions (which, by definition, need to be repaid after the processing of the same batch of L2 transactions).

Under AMM rules, the operator may:

1. Create a Layer 1 limit order in the AMM pool

2. Match the net difference (that is, the amount of the flash credit for the batch trade) with the Layer 1 limit order

3. Generate batch transaction certificates/send certificates

4. Update status

Layer 1 liquidity provider

For liquidity providers, there is no difference between Layer 1 and Layer 2. The liquidity provider interacts with the AMM through Layer 1 smart contracts without having to understand the inner workings of the processes down the chain. Let's look at the two basic operations of a liquidity provider - deposits and withdrawals:

deposit

The deposit is a one-step operation: Carol deposits funds on Layer 1 and receives a liquidity provider token. The operator monitors the Layer 1 blockchain and adjusts the offer based on new deposits.

withdrawals

Withdrawal is done in three steps:

1.Carol locks in her liquidity provider token, triggering the AMM cooling off period.

2. Operator must satisfy Carol's withdrawal request at the end of ACP.

3. If the operator rejects Carol's withdrawal request, Carol can withdraw funds directly from the AMM smart contract at the latest AMM rate after the end of the ACP.

conclusion

To achieve DEFI's goal of financial inclusion, we need to reduce transaction costs and prevent liquidity fragmentation at all costs.

Caspian, an AMM solution powered by Layer 2, is working towards this goal. It minimizes Layer 2 logic while improving capital efficiency by making Layer 2 liquidity superfluid collateral (which generates interest while acting as collateral). We will continue to actively explore and study the Caspian design space.