Collateral Models for Synthetic Asset Protocols

core_concepts

Core Collateral Concepts

The foundational mechanisms that determine how value is secured and managed within synthetic asset systems.

Collateralization Ratio

The collateralization ratio is the minimum amount of collateral value required to back a synthetic asset's value. It is a critical risk parameter.

Typically expressed as a percentage (e.g., 150%).
Acts as a buffer against price volatility of the collateral.
If the ratio falls below the minimum due to market moves, positions can be liquidated.
Higher ratios increase safety but reduce capital efficiency for minters.

Cross vs. Isolated Collateral

This defines how collateral pools are structured and risk is shared. Cross-collateralization allows one collateral deposit to back multiple synthetic positions.

Increases capital efficiency by reusing locked value.
Pools risk; a default in one position can affect others in the shared pool.
Isolated collateral confines risk to a single position/asset pair.
Safer for the protocol but requires more locked capital per position.

Liquidation Mechanisms

Automated processes that secure the protocol by closing undercollateralized positions. Liquidation occurs when a position's collateral value falls below the required ratio.

Triggered by price oracles reporting adverse market moves.
Liquidators are incentivized with a discount to buy the collateral and settle the debt.
Designed to keep the system overcollateralized and synthetic assets fully backed.
Parameters like liquidation penalty and grace periods are key design choices.

Collateral Types & Flexibility

Protocols vary in the assets they accept as collateral. Collateral flexibility impacts accessibility and risk profiles.

Single-collateral systems (e.g., only ETH) simplify risk modeling.
Multi-collateral systems accept various assets (e.g., ETH, WBTC, stablecoins), increasing user choice.
Each asset has unique volatility and liquidity characteristics, requiring specific risk parameters.
Exotic collateral (e.g., LP tokens) introduces composability but also complex dependency risks.

Debt Pool & Global Risk

In pooled collateral models, minters share a common debt pool. This represents the total synthetic value issued against the collective collateral.

Individual debt is a share of this global pool.
The pool's health depends on the aggregate collateral ratio.
Minters are exposed to the collective risk of all synthetic assets in the system.
This socializes risk and can lead to more stable synthetic asset prices.

Oracle Dependency

Synthetic asset protocols are fundamentally reliant on price oracles for both collateral valuation and synthetic asset pricing.

Oracles provide the external market data that triggers liquidations and calculates ratios.
Oracle manipulation or failure is a primary systemic risk.
Protocols use delay mechanisms, multiple data sources, and economic incentives to secure oracle feeds.
This dependency makes oracle design a core component of collateral management.

Protocol Model Analysis

Understanding Collateral Backing

At its core, a synthetic asset protocol creates tokens that track the price of real-world assets without holding the underlying. The collateral model defines how these synthetic tokens are backed and secured. The primary mechanism involves users locking collateral, often in the form of a volatile crypto asset like ETH, to mint a stable synthetic asset like sUSD. This creates a debt position for the user, which must remain over-collateralized to absorb price fluctuations and prevent insolvency.

Key Model Types

Single-collateral: Early models like Synthetix v1 used only SNX as collateral. This creates high protocol alignment but concentrates risk.
Multi-collateral: Modern systems like Synthetix v2 and Abracadabra.money accept various assets (e.g., ETH, wBTC, yield-bearing tokens). This improves capital efficiency and accessibility.
Isolated Pools: Protocols like MakerDAO with its PSM (Peg Stability Module) use specific, low-volatility collateral (like USDC) to mint synthetic USD with minimal over-collateralization, reducing risk.

Basic Mechanism

A user deposits $150 worth of ETH as collateral to mint $100 of synthetic gold (sXAU). If ETH's value drops, their collateralization ratio falls. They must either add more ETH or burn some sXAU to avoid liquidation.

Liquidation Engine Mechanics

Process overview

Monitor Health Factors and Trigger Conditions

Identify undercollateralized positions for liquidation.

Detailed Instructions

The liquidation engine continuously monitors the health factor (HF) for each open position. This is calculated as HF = (Collateral Value * Liquidation Threshold) / Debt Value. A position becomes eligible for liquidation when its HF falls below 1.0, indicating the debt is no longer sufficiently backed. For example, a protocol may set a liquidation threshold of 150% for ETH collateral, meaning a position with $100 of ETH debt requires at least $150 of ETH collateral. The engine listens for price feed updates and debt/collateral changes via on-chain events. It uses a keeper network or permissionless function to check positions against the current oracle price.

Sub-step 1: Query the latest price from the designated oracle (e.g., Chainlink ETH/USD).
Sub-step 2: Fetch the user's collateral balance and debt balance from the protocol's smart contracts.
Sub-step 3: Calculate the current health factor using the on-chain formula.
Sub-step 4: If HF < 1.0, add the position address to the liquidation queue.

solidity
// Simplified health factor check
function checkHealthFactor(address user) public view returns (uint256) {
    uint256 collateralValue = getCollateralValue(user);
    uint256 debtValue = getDebtValue(user);
    uint256 threshold = liquidationThresholds[collateralAsset];
    return (collateralValue * threshold) / debtValue;
}

Tip: Protocols often set a liquidation buffer (e.g., HF < 1.1) to trigger early, giving keepers time to act before the position becomes insolvent.

Calculate the Liquidation Bonus and Penalty

Determine the incentive for liquidators and the cost to the borrower.

Detailed Instructions

When a position is liquidatable, the engine calculates the liquidation bonus (incentive for the liquidator) and the liquidation penalty (fee paid by the borrower). These are typically expressed as a percentage of the debt or collateral being seized. A common model is to allow liquidators to repay up to a close factor (e.g., 50%) of the debt in a single transaction. For the seized collateral, the liquidator receives it at a discount, such as 5-10%, known as the liquidation discount. The penalty paid by the borrower is often higher, e.g., 15%, with the difference going to the protocol's treasury or stakers. The exact amounts are protocol parameters and can vary by collateral type.

Sub-step 1: Determine the maximum debt that can be liquidated: maxLiquidatableDebt = debt * closeFactor.
Sub-step 2: Calculate the collateral to be seized: collateralToSeize = (debtToRepay * oraclePrice) / (collateralPrice * (1 - liquidationDiscount)).
Sub-step 3: Apply the borrower's liquidation penalty to the remaining debt or seized collateral value.
Sub-step 4: Update the protocol's fee accumulator with the penalty portion.

solidity
// Example calculation for collateral to seize
function calculateSeizedCollateral(
    uint256 debtToRepay,
    uint256 debtPrice,
    uint256 collateralPrice,
    uint256 discount
) public pure returns (uint256) {
    // debtToRepay in USD terms, discount as a decimal (e.g., 0.05 for 5%)
    uint256 collateralValueToSeize = (debtToRepay * debtPrice) / collateralPrice;
    return (collateralValueToSeize * 1e18) / (1e18 - discount); // Apply discount
}

Tip: The liquidation discount must be carefully calibrated to ensure it is high enough to incentivize keepers in times of network congestion but low enough to minimize borrower losses.

Execute the Liquidation Transaction

Process the on-chain liquidation, transferring assets and repaying debt.

Detailed Instructions

A liquidator (keeper or bot) calls the public liquidate() function, providing the target user's address and the amount of debt to repay. The smart contract verifies the position is eligible, then executes the core logic. The liquidator must first approve the protocol to spend the stablecoin or debt asset they are using for repayment. The contract then transfers this asset from the liquidator to itself, burning the equivalent amount of the borrower's synthetic debt. In return, it transfers the calculated amount of discounted collateral from the protocol's vault to the liquidator. This is a atomic transaction; it either fully succeeds or reverts. Gas optimization is critical, so functions often use maxLiquidatableDebt to limit loop iterations.

Sub-step 1: Liquidator calls liquidate(address user, uint256 debtAmount) with the desired debt to cover.
Sub-step 2: Contract validates: healthFactor(user) < 1 and debtAmount <= maxLiquidatableDebt.
Sub-step 3: Contract transfers debtAmount of the debt token (e.g., sUSD) from liquidator to protocol.
Sub-step 4: Contract burns the borrower's debt balance by debtAmount.
Sub-step 5: Contract transfers the calculated collateralToSeize from the protocol vault to the liquidator.

solidity
function liquidate(address user, uint256 debtToRepay) external {
    require(healthFactor(user) < 1e18, "Healthy position");
    require(debtToRepay <= maxLiquidatableDebt(user), "Exceeds close factor");
    
    debtToken.safeTransferFrom(msg.sender, address(this), debtToRepay);
    _burnDebt(user, debtToRepay);
    
    uint256 collateralToSeize = calculateSeizedCollateral(debtToRepay, ...);
    collateralToken.safeTransfer(msg.sender, collateralToSeize);
    
    emit LiquidationExecuted(user, msg.sender, debtToRepay, collateralToSeize);
}

Tip: Use flash loans within the liquidation transaction to capitalize the operation without upfront capital, but be mindful of transaction complexity and risk.

Handle Partial Liquidations and Bad Debt

Manage scenarios where liquidation is incomplete or the position is underwater.

Detailed Instructions

Not all debt may be liquidated in one transaction due to the close factor limit or market depth. The engine must handle partial liquidations where the health factor remains below 1.0 after an execution, leaving the position open for further liquidation. The system recalculates the HF after each liquidation. In extreme market crashes, collateral value may fall so rapidly that the position's debt exceeds the total value of collateral, creating bad debt. Protocols mitigate this with safety modules or insurance funds that cover the shortfall. Some models implement a recursive liquidation process where the protocol itself auctions off the bad debt. The final step is often a full position closure if the debt is fully repaid or collateral is entirely seized.

Sub-step 1: After a liquidation, recalculate the user's new health factor with updated balances.
Sub-step 2: If HF is still < 1.0, flag the position for further liquidation.
Sub-step 3: If the collateral value is less than the debt (HF << 1.0), activate the bad debt resolution process.
Sub-step 4: Draw from the protocol's insurance fund to cover the remaining debt difference.
Sub-step 5: If the position's debt reaches zero, close it and release any remaining collateral to the user.

solidity
// Post-liquidation health check and bad debt handling
function _afterLiquidation(address user) internal {
    uint256 newHF = healthFactor(user);
    if (newHF < 1e18 && newHF > 0) {
        emit PositionStillUnhealthy(user, newHF);
    } else if (newHF == 0) {
        // Collateral value is zero or debt > collateral
        uint256 shortfall = getDebtValue(user);
        insuranceFund.coverShortfall(shortfall);
        _closePosition(user);
    }
}

Tip: Protocols with multiple collateral types must handle cross-collateralization where one asset's bad debt is covered by the surplus of another, requiring complex global health calculations.

Collateral Risk Factor Analysis

Comparison of risk parameters across common collateral types in synthetic asset protocols.

Risk Factor	ETH (Volatile)	USDC (Stablecoin)	LST (e.g., stETH)	LP Token (e.g., ETH/USDC)
Price Volatility (30d Avg.)	~45%	<1%	~40% (correlated)	~25% (diversified)
Liquidity Depth (TVL in $B)	~$50B	~$30B	~$10B	~$5B
Oracle Latency Risk	Low (Chainlink)	Low (Chainlink)	Medium (Dual Oracle)	High (TWAP required)
Liquidation Penalty	10-15%	5-8%	12-18%	15-25%
Protocol Dependency Risk	Low	Medium (Issuer)	High (Underlying Protocol)	Very High (AMM + Staking)
Maximum Collateral Factor	75%	85%	70%	60%
Smart Contract Complexity	Low	Low	Medium	Very High

advanced_models

Advanced and Hybrid Models

Protocols combine collateral mechanisms to optimize for capital efficiency, risk management, and asset diversity.

Multi-Tiered Collateral

Collateral tiers segment assets by risk and liquidity. A primary tier of high-quality assets like ETH backs most of the debt. A secondary tier of volatile or less liquid assets is accepted at higher haircuts. This structure allows for greater asset inclusion while protecting the system's solvency during market stress.

Dynamic Debt Positions

Dynamic collateralization adjusts required ratios based on market conditions. During high volatility, the protocol automatically increases the collateral requirement for specific asset pairs. This is often managed by keeper bots or governance votes. It reduces the need for frequent, manual liquidations and stabilizes the debt pool.

Yield-Bearing Collateral

Staked assets like stETH or cTokens serve as collateral while generating yield. The yield can be used to offset stability fees or is distributed to position holders. This model improves capital efficiency for users. Protocols must manage the additional smart contract and slashing risks associated with these derivative assets.

Cross-Margin and Portfolio Margining

Portfolio margining nets risk across a user's entire portfolio of collateral and synthetic positions. A diversified portfolio can lower the overall collateral requirement compared to isolating each position. This requires sophisticated risk engines to calculate correlated asset behavior. It significantly boosts capital efficiency for advanced users.

Insurance Backstops and Guarantors

Third-party guarantors or dedicated insurance pools provide an extra layer of protection. These entities commit capital to cover shortfalls in the event of a collateral shortfall or oracle failure. In return, they earn fees or token rewards. This hybrid model socializes extreme tail risk away from individual users.

Synthetic Asset Pools with External LP

Liquidity provider tokens from external AMMs (e.g., Uniswap v3 LP positions) are used as collateral. This creates a hybrid of over-collateralization and pooled liquidity models. The synthetic asset is effectively backed by a diversified pool of assets. It introduces complex price exposure and impermanent loss considerations for the protocol.

Frequently Asked Questions

The primary distinction lies in the collateralization ratio. Over-collateralized models, like those used by MakerDAO, require users to lock more value than they mint (e.g., 150% for ETH). This creates a safety buffer against price volatility. Under-collateralized models, such as Synthetix's pooled collateral, rely on a shared collateral pool where the total debt is backed by the entire staked asset supply. The former prioritizes individual risk isolation, while the latter leverages network effects and pooled liquidity but introduces systemic risk.

Protocol Documentation and Audits

Synthetix Protocol Documentation

Technical documentation covering Synthetix collateralization mechanics, debt pools, liquidation logic, and system architecture.

Visit resource

Synthetix Smart Contract Audits

Public audit reports for core Synthetix contracts, including collateral management, issuance, and liquidation modules.

Visit resource

MakerDAO Protocol Documentation

Detailed documentation on MakerDAO’s multi-collateral DAI system, risk parameters, liquidation auctions, and module design.

Visit resource

Frax Protocol Audit Reports

Audit disclosures for Frax’s partially collateralized stablecoin system, including collateral ratios and algorithmic components.

Visit resource