OEV Liquidation System

Overview

System Architecture

The Curvance OEV Liquidation System integrates on-chain and off-chain components to enable efficient liquidations with dynamic penalty rates.

Key Features

• Dynamic Liquidation Penalties: Adjustable between min and max values

• Transient Storage: Ensures penalties reset after auction transactions

• Atlas Integration: Permissionless MEV capture framework

• Fallback Queuing: Maintains liquidation capability if auctions are unavailable

• Oracle Integration: Curvance's pricing uses a dual-oracle system to prioritize risk mitigation, enhancing reliability and security.

The architecture consists of two primary layers:

Off-Chain Layer:

• Price feed monitoring services detect significant changes

• Atlas auction system coordinates liquidator bidding

• Solver bid collection and ranking mechanism

On-Chain Layer:

• Market Manager handles liquidation execution

• Dynamic Penalty System manages incentive rates

• Fallback Queue ensures liquidation processing when auctions fail

These components work together to process liquidations with optimal penalty rates while maximizing value capture and minimizing bad debt risk.

Atlas workflow

1. Oracle Update & Operation Collection: Price feed updates create liquidation opportunities. Liquidators generate signed UserOps containing bid amounts and execution instructions.

2. Auction & Bundling: Fastlane (auctioneer) receives bids from liquidators in the form of signed AA operations. The auctioneer then selects highest bidding operations and bundles them into a single atomic transaction with itself as tx.origin.

3. Transaction Execution: The bundled transaction executes on the Atlas Entrypoint contract, which:

   • Performs pre-execution balance checks

   • Calls each liquidator's operation in descending bid order

   • Verifies bid payment through post-execution balance checks

   • Continues to the next highest bidder if a liquidator fails to pay

4. DApp Control: The protocol maintains control through specificSequencingActive toggle and whitelist management of approved bundlers.

This mechanism maximizes MEV capture while ensuring liquidations always complete in a timely manner.

Core Dataflows

Price Update to Liquidation Flow

The journey from price change to liquidation execution follows these steps:

1. A price feed detects a significant change affecting position health

2. Fastlane initiates an auction for liquidation rights

3. Liquidators submit bids with penalty preferences and value offers

4. Bids are ranked according to the system's ordering rules

5. An Atlas transaction is constructed with winning bids

6. Upon successful execution, auction value is distributed to stakeholders

This auction typically completes within milliseconds off-chain before submitting the transaction.

Dynamic Penalty Dataflow

The dynamic penalty mechanism operates as follows:

1. Liquidators submit bids indicating their preferred penalty rate

2. During Atlas transaction execution, the DAppControl's PreSolver hook extracts the penalty bid

3. The Market Manager stores this value in transient storage

4. Liquidation executes using the dynamic penalty value

5. Upon transaction completion, the penalty automatically resets to default

6. The system returns to its base state awaiting the next auction

This design ensures that penalties remain active only during the specific liquidation transaction, preventing any persistent state changes.

Penalty Value Transitions

The dynamic penalty system uses transient storage (tstore/tload) to ensure penalties only exist within the context of Atlas transactions.

The liquidation penalty value follows a simple state machine:

• Default Penalty: Base incentive rate configured by governance

• Dynamic Penalty: Temporary value set during Atlas transaction

• Reset to Default: Automatic transition upon transaction completion

The system uses transient storage to ensure dynamic penalties cannot persist beyond their intended scope.

// MarketManagerIsolated.sol
function setPenalty(uint256 newPenalty) external {
    _checkDappControl();
    MarketToken storage pToken = tokenData[positionToken];
    if (
        newPenalty < pToken.liqMinIncentive ||
        newPenalty > pToken.liqMaxIncentive
    ) {
        revert MarketManager__InvalidParameter();
    }

    assembly {
        tstore(TRANSIENT_PENALTY_KEY, newPenalty)
    }
}

function resetPenalty() external {
    _checkDappControl();
    assembly {
        tstore(TRANSIENT_PENALTY_KEY, 0)
    }
}

function getLatestPenalty() public view returns (uint256 result) {
    assembly {
        result := tload(TRANSIENT_PENALTY_KEY)
    }

    if (result == 0) {
        return tokenData[positionToken].liqBaseIncentive;
    }
}

Auction Mechanics

Atlas Auction Structure

The Atlas auction system is the core mechanism for capturing liquidation MEV in Curvance. When a liquidation opportunity arises, the system conducts a brief (typically 300-500ms) auction before submitting an on-chain transaction.

Bid Components

Each liquidation bid consists of these key elements:

• Solver Address: The liquidator's smart contract that will execute the liquidation

• Execution Data: Calldata specifying which account to liquidate and method parameters

• Penalty Bid: The liquidation penalty rate the liquidator is willing to accept

• OEV Bid Amount: Payment offered to the protocol and other stakeholders

• Signature: Cryptographic verification of the bid's authenticity

Bid Classification

The auction system automatically classifies bids into two distinct categories:

Minimum Penalty Bids:

• Uses the protocol-defined minimum penalty (e.g., 5%)

• Must include a positive OEV payment amount

• Typically used during normal market conditions

Higher Penalty Bids:

• Specifies a penalty above the minimum (e.g., 6-20%)

• No OEV payment required

• Used during high volatility or significant slippage

Bid Ranking Algorithm

The auction employs a specialized ranking system with these core rules:

Primary Ranking by Penalty Tier:

• Minimum penalty bids compete exclusively against other minimum penalty bids

• Higher penalty bids compete based on the penalty rate offered

Secondary Ranking Rules:

• For minimum penalty bids: Higher OEV payment receives priority

• For higher penalty bids: Lower penalty rate receives priority

• Tertiary Sorting: When OEV payments or penalty rates are identical, bids are ordered by timestamp

Ranking Examples

Example 1: Minimum Penalty Competition

Consider these bids at the minimum 5% penalty:

Liquidator	Penalty	OEV Payment	Timestamp
LiquidatorA	5%	10 ETH	10:00:01
LiquidatorB	5%	8 ETH	10:00:00
LiquidatorC	5%	12 ETH	10:00:02

Ranking order: LiquidatorC → LiquidatorA → LiquidatorB (sorted by highest OEV payment)

Example 2: Higher Penalty Competition

Consider these bids with penalties above minimum:

Liquidator	Penalty	OEV Payment	Timestamp
LiquidatorA	7%	0	10:00:01
LiquidatorB	8%	0	10:00:00
LiquidatorC	6%	0	10:00:02

Ranking order: LiquidatorC → LiquidatorA → LiquidatorB (sorted by lowest penalty)

Example 3: Mixed Competition

When both minimum and higher penalty bids exist:

Liquidator	Penalty	OEV Payment	Timestamp
LiquidatorA	5%	10 ETH	10:00:01
LiquidatorB	7%	0	10:00:00
LiquidatorC	5%	12 ETH	10:00:02

Ranking will attempt LiquidatorC first (highest OEV at min penalty), then LiquidatorA (second highest OEV at min penalty), then LiquidatorB (lowest penalty among higher penalty bids).

Execution Flow

The Atlas transaction processes these bids sequentially:

• The highest-ranked bid's solver contract is called first

• If execution succeeds, the transaction completes and value is distributed

• If execution fails, the next-ranked bid is attempted

• This continues until either a liquidation succeeds or all bids fail

• If all bids fail, the position remains liquidatable via the fallback queue

Value Distribution

When a bid succeeds, the value is distributed according to the protocol's configured rules:

For Minimum Penalty Bids with OEV:

• As specified in the DAppControl contract, the allocateValue hook distributes the OEV payment between:

• The bundler (who submits the transaction)

• Oracle (price feed provider)

• Fastlane (Operations Relay infrastructure)

• The app (Curvance protocol treasury)

• The exact distribution percentages are configured by Curvance governance

• OEV bids are only present when a solver wins with a penalty bid equal to the minimum penalty

For Higher Penalty Bids:

• No OEV payment is included or distributed

• All excess value from the higher penalty accrues to the liquidator

• No value distribution to protocol or infrastructure stakeholders occurs

This dual economic model aligns incentives effectively: during normal market conditions, the protocol captures value through OEV payments, while during stressed market conditions, liquidators retain more value to offset increased risk and ensure liquidations complete successfully.

Oracle Data Flow

1. Push vs. Pull Model:

   1. Atlas OEV requires a push-based oracle model where price updates trigger on-chain events

   2. Each price update can initiate liquidation opportunities

2. Transaction Sequencing:

   1. When an oracle update transaction lands on-chain, it may trigger liquidations

   2. Atlas integrates with the oracle update process to capture OEV (Optimal Extractable Value)

Data Storage Model

The system employs two distinct storage layers:

Permanent Storage:

• Queue data (timestamps, liquidator addresses, nonces)

• Penalty ranges (min, max, default values)

• Account health statuses

• System configuration parameters

Transient Storage:

• Dynamic penalty values during Atlas transactions

• Temporary state for execution environment

• Values automatically reset after transaction completion

This separation ensures critical data persists while dynamic values remain ephemeral.

---

Resources:

Atlas Docs: https://atlas-docs.pages.dev/atlas/introduction