Orderflow Auction System

Overview

System Architecture

The Curvance orderflow auction system integrates on-chain and off-chain components to enable efficient liquidations with dynamic liquidation sizes and 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.

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

• Liquidation Buffer: 10 basis point margin ensuring Atlas transactions get priority for liquidations.

• Efficient Batch Liquidations: Support for processing multiple liquidations in a single transaction.

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.

• Atlas Buffer System provides priority access to liquidations.

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 (Account Abstraction) 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.

Liquidation Buffer System

The Atlas buffer system provides priority access to liquidations:

1. Buffer Mechanism: A 10 basis point (0.1%) buffer gives Atlas transactions priority for liquidations.

2. Implementation: When Atlas transactions are detected via transient storage, liquidation health checks apply the buffer.

3. Benefits:

   1. Captures liquidations from interest accrual.

   2. Handles LST (Liquid Staking Token) yield accumulation.

   3. Compensates for network latency.

/// @notice Buffer to ensure Orderflow auction can do
///      interest-triggered liquidations.
/// @dev 0.999e18 = 99.9%. multiplied then divided
///      by WAD = 10 bps buffer.
uint256 public constant AUCTION_BUFFER = 0.999e18;

/// @notice Will revert and block liquidations of collateral that are not
///         currently allowed by Atlas, only if this is an Atlas tx.
function _checkCollateralUnlocked(
    address eTokenToLiquidate
) internal view returns (uint256) {
    uint256 result;
    assembly {
        result := tload(_TRANSIENT_COLLATERAL_UNLOCKED_KEY)
    }

    // CASE: This is not an Atlas tx, so allow all collaterals,
    // and return no buffer. 
    if (result == 0) {
        return 0;
    }

    address unlockedCollateral = address(uint160(result));

    // This is an Atlas tx, and Atlas liquidator attempted wrong
    // collateral so revert.
    if (unlockedCollateral != eTokenToLiquidate) {
        _revert(_UNAUTHORIZED_COLLATERAL_SELECTOR);
    }

    // if we reach this point this is an Atlas tx and collateral is valid,
    // so return the atlas buffer. 
    return AUCTION_BUFFER;
}

Dynamic Penalty Dataflow

The dynamic penalty mechanism operates as follows:

1. Liquidators submit bids indicating their preferred penalty and close factor rate.

2. During Atlas transaction execution, the DAppControl calls setAtlasParameters() .

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.

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

Fallback Mechanism

The system includes an effective fallback process for scenarios when Atlas is temporarily unavailable:

• When Atlas is down, the system automatically falls back into using the base liquidation incentive and close factor values.

• Regular liquidations proceed without the 10 bps advantage.

• The fallback occurs seamlessly without delays.

• Price feeds continue to function through a secondary oracle service.

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

/// Sets new dynamic close factor and liquidation penalty values in transient storage.
function setAtlasParameters(uint256 newPenalty, uint256 newCloseFactor) external {
    _checkAtlasPermissions();

    // Validate new Liquidation Penalty value. 
    MarketToken storage pToken = tokenData[positionToken];
    // Validate new penalty is within configured allowed penalty.
    if (newPenalty < pToken.liqMinIncentive || newPenalty > pToken.liqMaxIncentive) {
        revert MarketManager__InvalidParameter();
    }

    // Validate new Close Factor value.
    if (newCloseFactor < pToken.minEffectiveCloseFactor || newCloseFactor > pToken.maxEffectiveCloseFactor) {
        revert MarketManager__InvalidParameter();
    }

    // Set new Risk Parameters in transient storage. 
    // tstore(key, value): store `newPenalty` under TRANSIENT_PENALTY_KEY.
    assembly {
        tstore(_TRANSIENT_PENALTY_KEY, newPenalty)
    }

    // tstore(key, value): store `newCloseFactor` under TRANSIENT_CLOSE_FACTOR_KEY.
    assembly {
        tstore(_TRANSIENT_CLOSE_FACTOR_KEY, newCloseFactor)
    }
}

/// Resets the Atlas risk parameters in transient storage to zero.
function resetAtlasParameters() external {
    _checkAtlasPermissions();

    assembly {
        // Clear the transient storage slot by writing zero. 
        tstore(_TRANSIENT_PENALTY_KEY, 0)
    }

    // Clear the transient storage slot by writing zero.
    assembly {
        tstore(_TRANSIENT_CLOSE_FACTOR_KEY, 0)
    }
    
}

/// @notice Returns the current Atlas parameters.
function getLatestAtlasParameters() public view returns (
    uint256 penalty,
    uint256 closeFactor
) {
    assembly {
        penalty := tload(_TRANSIENT_PENALTY_KEY)
        closeFactor := tload(_TRANSIENT_CLOSE_FACTOR_KEY)
    }
    // Fallback scenarios where a parameter(s) MUST based handled
    // separately based on lFactor
}

Collateral Locking Mechanism

The system enforces that only specific collateral can be liquidated during Atlas transactions:

function unlockAtlasCollateral(address collateralToUnlock) external {
    uint256 collateralToUnlockUint = uint256(uint160(collateralToUnlock));
    _checkAtlasPermissions();

    assembly {
        tstore(_TRANSIENT_COLLATERAL_UNLOCKED_KEY, collateralToUnlockUint)
    }
}

function lockAtlasCollateral() external {
    _checkAtlasPermissions();

    assembly {
        tstore(_TRANSIENT_COLLATERAL_UNLOCKED_KEY, 0)
    }
}

Batch Liquidation Support

The system supports efficient multi-liquidation processing:

1. Bulk Processing: Can handle multiple liquidations in a single transaction.

2. Cached Pricing: Retrieves asset prices once per transaction rather than per liquidation.

3. Consolidated Transfers: Aggregates debt repayments into a single transfer.

4. Gas Optimization: Significantly reduces gas costs during liquidation cascades.

This design allows for processing thousands of liquidations in a single transaction, improving efficiency during market stress.

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 300ms) 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.

• Close Factor Bid: The percentage of debt the liquidator wants to liquidate.

• 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.

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 Curvance 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).

3. Oracle Compatibility:

   1. Designed to work with any push-based oracle.

   2. RedStone push feeds are the primary integration target.

   3. Support for LST (Liquid Staking Token) redemption rate oracles.

Data Storage Model

The system employs two distinct storage layers:

Permanent Storage:

• Penalty ranges (min, max, default values).

• Account health statuses.

• System configuration parameters.

Transient Storage:

• Dynamic penalty values during Atlas transactions.

• Close factor values.

• Collateral unlock status.

• 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