ERC-7893: DeFi Protocol Solvency Proof Mechanism

Verifiable solvency proofs and financial health monitoring for DeFi protocols

Abstract

A standardized interface that enables DeFi protocols to implement verifiable solvency proofs through smart contracts. This interface works by defining structured data types for assets and liabilities, with oracle-validated price feeds tracking token values in real-time. The technical implementation calculates solvency ratios using configurable risk thresholds (105% minimum solvency ratio), maintains historical metrics for trend analysis, and emits structured events upon threshold breaches. The interface standardizes methods for querying current financial health, retrieving historical data points, and updating protocol positions, all while enforcing proper validation and security controls.

Motivation

The DeFi ecosystem currently lacks standardization in financial health reporting, leading to:

1. Inconsistent reporting methodologies across protocols
2. Limited transparency in real-time financial status
3. Absence of standardized early warning systems
4. Complex and time-consuming audit processes
5. Difficulty in assessing cross-protocol risks

This proposal directly addresses these challenges through a comprehensive interface that standardizes solvency reporting and monitoring:

• Standardized Methodology: By providing a common interface with well-defined asset/liability structures and mathematical models, this EIP eliminates reporting inconsistencies that currently prevent clear comparisons between protocols.

• Real-time Transparency: The proposed event system and query functions enable continuous monitoring of protocol health, rather than relying on periodic manual reporting that can miss critical changes in financial status.

• Automated Risk Alerts: The threshold-based alert system provides early warnings of deteriorating conditions through standardized RiskAlert events, enabling faster response to potential insolvencies than current ad-hoc monitoring approaches.

• Efficient Audit Trail: The historical metrics tracking creates an immutable record of protocol health over time, significantly reducing audit complexity compared to current solutions that require reconstructing historical positions.

• Cross-Protocol Risk Assessment: A common interface enables aggregation of risk data across multiple protocols, allowing systemic risk monitoring that’s impossible with today’s fragmented reporting systems.

Alternative approaches considered include:

1. Off-chain Reporting: While simpler to implement, this lacks the verifiability, real-time nature, and trustless properties of an on-chain solution.

2. Protocol-Specific Standards: These would lack the interoperability benefits of a common standard and would perpetuate fragmentation.

3. Complex Risk Models: More sophisticated models were evaluated but rejected in favor of this proposal’s balance between comprehensiveness and implementability.

This EIP represents the optimal approach by providing a flexible yet standardized framework that can be implemented across diverse protocol types while maintaining reasonable gas efficiency and usability.

The ISolvencyProof interface provides a standardized, on-chain mechanism for DeFi protocols to report, verify, and monitor their solvency status. This interface is designed to be both comprehensive and flexible, supporting a wide range of protocol architectures and risk management strategies.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Core Interface Requirements

Compliant implementations MUST implement the ISolvencyProof interface.

Compliant implementations MUST provide the following functionality:

1. Asset and Liability Tracking: Implementations MUST store and maintain current protocol assets and liabilities with token addresses, amounts, and ETH-denominated values in contract state variables. This data MUST be updated through the updateAssets and updateLiabilities functions called by authorized oracles.

2. Timestamp Recording: Implementations MUST record the timestamp of each asset and liability update.

3. Solvency Calculation: Implementations MUST calculate the solvency ratio as (Total Assets / Total Liabilities) × 10000.

4. Historical Data: Implementations MUST maintain historical records of solvency metrics for querying within specified time ranges. Implementations MAY expire old data after a reasonable retention period (e.g., 1 year) but MUST clearly document their retention policy and available time ranges in their implementation documentation.

5. Event Emission: Implementations MUST emit SolvencyMetricsUpdated events when financial metrics are updated, and SHOULD emit RiskAlert events when risk thresholds are breached.

6. Array Validation: Implementations MUST ensure that all arrays in ProtocolAssets and ProtocolLiabilities structures are of equal length.

7. Value Denomination: Implementations MUST express all values in ETH with 18 decimals for consistency.

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

/**
 * @title ISolvencyProof
 * @author Sean Luis (@SeanLuis) <seanluis47@gmail.com>
 * @notice Standard Interface for DeFi Protocol Solvency (EIP-DRAFT)
 * @dev Interface for the DeFi Protocol Solvency Proof Standard
 * @custom:security-contact seanluis47@gmail.com
 * @custom:version 1.0.0
 */
interface ISolvencyProof {
    /**
     * @dev Protocol assets structure
     * @notice Represents the current state of protocol assets
     * @custom:validation All arrays must be equal length
     * @custom:validation Values must be in ETH with 18 decimals
     */
    struct ProtocolAssets {
        address[] tokens;    // Addresses of tracked tokens
        uint256[] amounts;   // Amount of each token (in token decimals)
        uint256[] values;    // Value in ETH (18 decimals) of each token amount
        uint256 timestamp;   // Last update timestamp (Unix timestamp in seconds)
    }

    /**
     * @dev Protocol liabilities structure
     * @notice Represents the current state of protocol liabilities
     * @custom:validation All arrays must be equal length
     * @custom:validation Values must be in ETH with 18 decimals
     */
    struct ProtocolLiabilities {
        address[] tokens;    // Addresses of liability tokens
        uint256[] amounts;   // Amount of each liability (in token decimals)
        uint256[] values;    // Value in ETH (18 decimals) of each liability
        uint256 timestamp;   // Last update timestamp (Unix timestamp in seconds)
    }

    /**
     * @dev Emitted on metrics update
     * @notice Real-time financial health update
     * @param totalAssets Sum of asset values in ETH
     * @param totalLiabilities Sum of liability values in ETH
     * @param healthFactor Calculated as (totalAssets/totalLiabilities) × 10000
     * @param timestamp Update timestamp
     */
    event SolvencyMetricsUpdated(
        uint256 totalAssets,
        uint256 totalLiabilities,
        uint256 healthFactor,
        uint256 timestamp
    );

    /**
     * @dev Emitted when risk thresholds are breached
     * @notice Alerts stakeholders of potential solvency risks
     * 
     * @param riskLevel Risk level indicating severity of the breach (CRITICAL, HIGH_RISK, WARNING)
     * @param currentValue Current value that triggered the alert
     * @param threshold Risk threshold that was breached
     * @param timestamp Alert timestamp
     */
    event RiskAlert(
        string riskLevel,
        uint256 currentValue,
        uint256 threshold,
        uint256 timestamp
    );

    /**
     * @notice Get protocol's current assets
     * @return Full asset state including tokens, amounts and values
     */
    function getProtocolAssets() external view returns (ProtocolAssets memory);

    /**
     * @notice Get protocol's current liabilities
     * @return Full liability state including tokens, amounts and values
     */
    function getProtocolLiabilities() external view returns (ProtocolLiabilities memory);

    /**
     * @notice Calculate current solvency ratio
     * @return SR = (Total Assets / Total Liabilities) × 10000
     */
    function getSolvencyRatio() external view returns (uint256);

    /**
     * @notice Check protocol solvency status
     * @return isSolvent True if ratio >= minimum required
     * @return healthFactor Current solvency ratio
     */
    function verifySolvency() external view returns (bool isSolvent, uint256 healthFactor);

    /**
     * @notice Get historical solvency metrics
     * @param startTime Start of time range (Unix timestamp in seconds)
     * @param endTime End of time range (Unix timestamp in seconds)
     * @return timestamps Array of historical update timestamps (Unix timestamp in seconds)
     * @return ratios Array of historical solvency ratios (scaled by 10000)
     * @return assets Array of historical asset states
     * @return liabilities Array of historical liability states
     * @custom:gas This function may consume significant gas for large time ranges
     */
    function getSolvencyHistory(uint256 startTime, uint256 endTime) 
        external 
        view 
        returns (
            uint256[] memory timestamps,
            uint256[] memory ratios,
            ProtocolAssets[] memory assets,
            ProtocolLiabilities[] memory liabilities
        );

    /**
     * @notice Update protocol assets
     * @dev Only callable by authorized oracle
     */
    function updateAssets(
        address[] calldata tokens,
        uint256[] calldata amounts,
        uint256[] calldata values
    ) external;

    /**
     * @notice Update protocol liabilities
     * @dev Only callable by authorized oracle
     */
    function updateLiabilities(
        address[] calldata tokens,
        uint256[] calldata amounts,
        uint256[] calldata values
    ) external;
}

Oracle Authorization Requirements

Implementations MUST restrict calls to updateAssets and updateLiabilities to authorized addresses only. Implementations MUST revert these function calls when msg.sender is not an authorized oracle.

Implementations MAY provide oracle management functions. If provided, implementations SHOULD emit events when oracle authorization changes.

Example oracle management pattern (OPTIONAL):

// Optional oracle management pattern
event OracleUpdated(address indexed oracle, bool authorized);
function setOracle(address oracle, bool authorized) external;

The core standard focuses on solvency verification requirements. Oracle management implementation details are left to individual protocol needs.

Update Function Requirements

Implementations MUST validate input parameters for updateAssets and updateLiabilities functions:

1. Implementations MUST revert if the tokens, amounts, and values arrays are not of equal length.
2. Implementations MUST update the timestamp field to the current block timestamp (block.timestamp) when processing updates.
3. Implementations MUST emit a SolvencyMetricsUpdated event after successfully updating assets or liabilities.

Query Function Requirements

Implementations MUST provide the following query capabilities:

1. getProtocolAssets() MUST return the current state of protocol assets including all token addresses, amounts, values, and the timestamp of the last update.

2. getProtocolLiabilities() MUST return the current state of protocol liabilities including all token addresses, amounts, values, and the timestamp of the last update.

3. getSolvencyRatio() MUST calculate and return the solvency ratio as (totalAssets * 10000) / totalLiabilities. If totalLiabilities is zero, implementations SHOULD return a value indicating maximum solvency or revert with an appropriate error.

4. verifySolvency() MUST return both a boolean indicating solvency status and the current health factor (solvency ratio).

5. getSolvencyHistory(startTime, endTime) MUST return historical data for all recorded snapshots where the timestamp falls within the specified range (inclusive).

Interface Detection Support

Compliant implementations MUST implement the ERC-165 supportsInterface function and MUST return true for the ISolvencyProof interface ID.

Rationale

The standard’s design prioritizes:

1. Reliability through robust calculations
2. Efficiency via optimized data structures
3. Flexibility through modular design
4. Transparency via standardized metrics

Asset and Liability Management

Authorized oracles update the protocol’s asset and liability data through the updateAssets and updateLiabilities functions, which accept parallel arrays of token addresses, amounts, and ETH-denominated values. The interface enforces data consistency by requiring all input arrays to be of equal length and all values to be denominated in ETH with 18 decimal precision. Each update automatically timestamps the data using block.timestamp, ensuring chronological ordering of financial state changes and enabling accurate historical analysis.

Solvency Calculation and Verification

The getSolvencyRatio function computes the current solvency ratio, defined as the total value of assets divided by the total value of liabilities, scaled by a factor of 10,000 for precision. The verifySolvency function checks whether the protocol meets a minimum required solvency ratio (commonly 105%), returning both a boolean status and the current health factor. This allows both on-chain and off-chain systems to quickly assess the protocol’s financial health and respond accordingly.

Historical Data and Trend Analysis

The getSolvencyHistory function enables retrieval of historical solvency metrics, including timestamps, ratios, and the corresponding asset and liability states over a specified time range. This historical data is crucial for reconstructing past events, analyzing risk trends, and providing transparency to stakeholders. This supports audits, regulatory requirements, and trend analysis needs.

Event Emission and Risk Alerts

Whenever the protocol’s financial metrics are updated, the SolvencyMetricsUpdated event is emitted, providing real-time data for off-chain monitoring and analytics. When risk thresholds are breached (for example, if the solvency ratio falls below a critical level), the RiskAlert event is triggered, signaling the severity and nature of the risk. These events enable automated monitoring systems, auditors, and users to receive timely notifications and take appropriate action.

Oracle Integration and Security

The interface is designed to be oracle-agnostic, allowing protocols to integrate with a variety of price feed solutions (e.g., Chainlink, API3, custom oracles). The requirement that only authorized oracles can update asset and liability data ensures that updates are secure and resistant to manipulation. The optional setOracle and OracleUpdated event pattern is recommended for managing oracle permissions and maintaining robust security controls.

Intended Usage and Integration

Protocols implementing this interface integrate with trusted oracles for price feeds and position updates, maintain up-to-date records of their financial positions, emit standardized events for off-chain monitoring and risk management, and provide transparent, verifiable, and standardized information about their solvency status to all stakeholders. External consumers (such as auditors, users, or other smart contracts) can query the protocol’s current and historical solvency status using the provided view functions, and can listen for events to receive timely notifications of significant changes or risks. This design ensures that all stakeholders have access to reliable, real-time information about a protocol’s financial health, enabling more robust risk management and greater trust in the DeFi ecosystem.

Data Structure Design Rationale

The interface defines two primary data structures (ProtocolAssets and ProtocolLiabilities) with specific attributes:

1. Array-based token tracking was selected over mapping-based approaches for:
   • More efficient state retrieval for monitoring systems
   • Better compatibility with historical tracking requirements
   • Simplified batch updates in volatile market conditions
2. Timestamp embedding within structures rather than separate mappings provides:
   • Atomic updates with data consistency guarantees
   • Protection against partial-update scenarios during price volatility
   • Single-transaction verification of data freshness
3. Combined value and amount tracking was implemented for:
   • Enhanced resilience during high market volatility
   • Ability to detect oracle manipulation by comparing historical value/amount ratios
   • Clear audit trails for post-mortem analysis

Test-Driven Design Decisions

Our implementation testing significantly shaped the final design:

1. Market Crash Simulation Tests
   • Tests simulate extreme scenarios (80% ETH price drop, 70% BTC price drop)
   • Validates the system correctly identifies insolvency when ratios fall below critical thresholds
   • Confirms proper functionality of emergency protocols during rapid market movements
2. Volatility Testing
   • Test suite subjects implementation to sinusoidal price movements
   • Validates consistent health factor calculation across 5 distinct price points
   • Confirms historical metrics are properly recorded with sequential timestamps
   • Verifies that price volatility is accurately reflected in solvency ratios
3. Oracle Integration
   • Tests confirm proper authorization controls for price updates
   • Validates calculation consistency across different token types
   • Demonstrates resilience against unexpected price movements

Threshold Selection Methodology

The recommended threshold values (105%, 110%, 120%) were selected based on:

1. Market Crash Testing
   • 105% represents the critical threshold where recovery becomes unlikely
   • Testing confirms this threshold successfully identifies insolvency scenarios
   • System correctly triggers warnings at appropriate levels
2. Complex Portfolio Analysis
   • Tests with diverse portfolios (ETH, BTC, USDC, LP tokens, etc.)
   • Complex liability structures (stablecoins + volatile assets)
   • Thresholds provide appropriate buffer against normal market fluctuations
3. Gas Optimization vs. Precision
   • The selected ratio calculation method balances computational efficiency with accuracy
   • Implementation uses fixed-point math for consistent results
   • Storage optimizations maintain historical data while minimizing costs

Implementation Insights

Key insights from comprehensive implementation and testing:

1. Efficient Asset Tracking
   • The parallel arrays approach for token data minimizes storage costs
   • Implementation maintains constant-time lookups for critical operations
   • Bounded array sizes prevent out-of-gas scenarios
2. Oracle Integration Patterns
   • Permissioned oracle design prevents manipulation
   • Clean separation between price data and protocol logic
   • Flexible design supports various oracle implementations
3. Risk Management System
   • Multi-tier alert system provides graduated responses to deteriorating conditions
   • Historical metrics enable trend analysis across market cycles
   • Verification functions support both on-chain and off-chain monitoring systems

These insights are derived from comprehensive testing covering market crashes, volatility scenarios, and complex asset portfolios.

Mathematical Model

The solvency verification system is based on comprehensive mathematical models:

1. Core Solvency Calculations

$SR = (TA / TL) × 100$

Where:

• $TA = \sum(A_i × P_i)$ // Total Assets
• $TL = \sum(L_i × P_i)$ // Total Liabilities
• $A_i$ = Amount of asset i
• $P_i$ = Price of asset i
• $L_i$ = Liability i

2. Risk-Adjusted Health Factor

$HF = \frac{\sum(A_i × P_i × W_i)}{\sum(L_i × P_i × R_i)}$

Where:

• $W_i$ = Risk weight of asset i $(0 < W_i \leq 1)$
• $R_i$ = Risk factor for liability i $(R_i \geq 1)$

3. Risk Metrics

Value at Risk (VaR)

$VaR(\alpha) = \mu - (\sigma × z(\alpha))$

Where:

• $\mu$ = Expected return
• $\sigma$ = Standard deviation
• $z(\alpha)$ = z-value for confidence level $\alpha$

Liquidity Coverage Ratio (LCR)

$LCR = \frac{HQLA}{TNCO} × 100$

Where:

• HQLA = High Quality Liquid Assets
• TNCO = Total Net Cash Outflows (30 days)

4. System Health Index

$SI = \frac{SR × w_1 + LCR × w_2 + (1/\sigma) × w_3}{w_1 + w_2 + w_3}$

Where:

• $w_1,w_2,w_3$ = Weighting factors
• $\sigma$ = System volatility

5. Default Probability

$PD = N(-DD)$ $DD = \frac{ln(TA/TL) + (\mu - \sigma^2/2)T}{\sigma\sqrt{T}}$

Where:

• DD = Distance to Default
• T = Time horizon
• N() = Standard normal distribution

Risk Thresholds

The following thresholds have been validated through extensive testing:

Testing has confirmed that:

1. The system correctly handles 50% market drops
2. Ratios are calculated accurately in all scenarios
3. State updates maintain consistency
4. Ratio limits are effective for early detection

Risk Assessment Framework

The standard implements a multi-tiered risk assessment system:

1. Primary Metrics:
   • Base Solvency Ratio (SR)
   • Risk-Adjusted Health Factor (HF)
   • Liquidity Coverage Ratio (LCR)
2. Threshold Levels:

Oracle Integration (Optional)

This standard intentionally leaves oracle implementation flexible. Protocols MAY implement price feeds in various ways:

1. Direct Integration
   • Using existing oracle networks (Chainlink, API3, etc.)
   • Custom price feed implementations
   • Internal price calculations
2. Aggregation Strategies
   • Multiple oracle sources
   • TWAP implementations
   • Medianized price feeds

Implementation Requirements

1. Asset Management:
   • Real-time asset tracking
   • Price feed integration
   • Historical data maintenance
2. Liability Tracking:
   • Debt obligation monitoring
   • Collateral requirement calculation
   • Risk factor assessment
3. Reporting System:
   • Event emission for significant changes
   • Threshold breach notifications
   • Historical data access

Implementation Considerations

Implementation Notes

Based on conducted tests, it is recommended:

1. Liability Management:
   • Maintain constant liabilities during price updates
   • Validate that liabilities are never 0 to avoid division by zero
   • Update liabilities only when actual positions change

2. Ratio Calculation:

   function calculateRatio(uint256 assets, uint256 liabilities) pure returns (uint256) {
       if (liabilities == 0) {
           return assets > 0 ? RATIO_DECIMALS * 2 : RATIO_DECIMALS;
       }
       return (assets * RATIO_DECIMALS) / liabilities;
   }
   

3. State Validation:
   • Verify values before updating
   • Maintain accurate history
   • Emit events for significant changes
4. Gas Considerations:
   • Optimize history storage
   • Batch updates for multiple tokens
   • Limit array sizes in updates

Backwards Compatibility

This EIP is compatible with existing DeFi protocols and requires no changes to existing token standards.

Reference Implementation

The reference implementation provides a comprehensive example of the standard in action:

Core Implementation Requirements

Implementations of the ISolvencyProof interface should provide robust solvency monitoring with:

• Advanced state management with atomic updates and timestamp tracking
• Multi-layered security including access control, rate limiting, and circuit breakers
• Historical data management with bounded storage and configurable retention
• Oracle integration with consensus validation and staleness detection
• Emergency response systems with automatic pausing and guardian controls
• Comprehensive event emission for real-time monitoring and risk alerts

Recommended Implementation Patterns

State Management with Security Constants

// Security constants for production deployment
uint256 private constant RATIO_DECIMALS = 10000;
uint256 private constant MIN_SOLVENCY_RATIO = 10500;
uint256 private constant CRITICAL_RATIO = 10200;
uint256 private constant WARNING_RATIO = 11000;

// Enhanced security constants
uint256 private constant MAX_PRICE_DEVIATION = 500;    // 5%
uint256 private constant MAX_TOKENS_PER_UPDATE = 50;   // DoS protection
uint256 private constant STALENESS_THRESHOLD = 3600;   // 1 hour
uint256 private constant CIRCUIT_BREAKER_THRESHOLD = 2000; // 20%
uint256 private constant UPDATE_COOLDOWN = 5;          // 5 blocks
uint256 private constant MAX_HISTORY_ENTRIES = 8760;   // ~1 year
uint256 private constant MIN_ENTRY_INTERVAL = 3600;     // 1 hour

// Role-based access control
bytes32 public constant ORACLE_ROLE = keccak256("ORACLE_ROLE");
bytes32 public constant EMERGENCY_ROLE = keccak256("EMERGENCY_ROLE");
bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");

// Enhanced state variables
ProtocolAssets private currentAssets;
ProtocolLiabilities private currentLiabilities;

// Multi-oracle price tracking
mapping(address => mapping(address => uint256)) public oraclePrices;
mapping(address => uint256) public oracleLastUpdate;
mapping(address => uint256) public lastUpdateBlock;

// Emergency controls
bool public emergencyPaused;
uint256 public pauseEndTime;
address public emergencyGuardian;

// Historical data with metadata
struct HistoricalMetric {
    uint256 timestamp;
    uint256 solvencyRatio;
    ProtocolAssets assets;
    ProtocolLiabilities liabilities;
    address updatedBy;
}

HistoricalMetric[] private metricsHistory;
uint256 private lastHistoricalEntry;

Advanced Security Features

Access Control System

// Multi-role access control with backward compatibility
modifier onlyOracle() {
    require(
        assetOracles[msg.sender] || hasRole(ORACLE_ROLE, msg.sender),
        "Not authorized oracle"
    );
    require(!emergencyPaused || block.timestamp > pauseEndTime,
        "Emergency paused");
    _;
}

// Rate limiting to prevent spam
modifier rateLimited() {
    require(
        block.number >= lastUpdateBlock[msg.sender] + UPDATE_COOLDOWN,
        "Update too frequent"
    );
    lastUpdateBlock[msg.sender] = block.number;
    emit RateLimitTriggered(msg.sender, block.number);
    _;
}

Circuit Breaker Implementation

function _checkCircuitBreaker(uint256 previousTotal, uint256 newTotal) internal {
    if (previousTotal > 0) {
        uint256 assetChange = newTotal > previousTotal
            ? ((newTotal - previousTotal) * 10000) / previousTotal
            : ((previousTotal - newTotal) * 10000) / previousTotal;

        if (assetChange > CIRCUIT_BREAKER_THRESHOLD) {
            emergencyPaused = true;
            pauseEndTime = block.timestamp + 3600; // 1 hour pause
            emit CircuitBreakerTriggered("Large asset change",
                assetChange, CIRCUIT_BREAKER_THRESHOLD);
            emit EmergencyPaused(address(this), pauseEndTime);
        }
    }
}

Multi-Oracle Consensus Validation

function _validatePriceConsensus(address token, uint256 proposedPrice)
    internal returns (bool) {
    address[] memory activeOracles = _getActiveOracles();
    if (activeOracles.length < 3) return true;

    // Collect and validate prices from multiple oracles
    uint256[] memory prices = new uint256[](activeOracles.length);
    uint256 validPrices = 0;

    for (uint256 i = 0; i < activeOracles.length; i++) {
        if (oraclePrices[activeOracles[i]][token] > 0) {
            prices[validPrices] = oraclePrices[activeOracles[i]][token];
            validPrices++;
        }
    }

    if (validPrices < 2) return true;

    // Calculate median and check deviation
    uint256 median = _calculateMedian(prices, validPrices);
    uint256 deviation = proposedPrice > median
        ? ((proposedPrice - median) * 10000) / median
        : ((median - proposedPrice) * 10000) / median;

    if (deviation > MAX_PRICE_DEVIATION) {
        emit PriceDeviationAlert(token, deviation, activeOracles);
        return false;
    }

    return true;
}

Historical Data Management

function getSolvencyHistory(uint256 startTime, uint256 endTime)
    external view returns (uint256[] memory, uint256[] memory,
        ProtocolAssets[] memory, ProtocolLiabilities[] memory) {

    // Two-pass approach for gas optimization
    uint256 count = 0;
    for (uint256 i = 0; i < metricsHistory.length; i++) {
        if (metricsHistory[i].timestamp >= startTime &&
            metricsHistory[i].timestamp <= endTime) {
            count++;
            if (count >= 100) break; // Gas limit protection
        }
    }

    // Allocate exact size arrays
    uint256[] memory timestamps = new uint256[](count);
    uint256[] memory ratios = new uint256[](count);
    ProtocolAssets[] memory assets = new ProtocolAssets[](count);
    ProtocolLiabilities[] memory liabilities = new ProtocolLiabilities[](count);

    // Populate arrays
    uint256 index = 0;
    for (uint256 i = 0; i < metricsHistory.length && index < count; i++) {
        if (metricsHistory[i].timestamp >= startTime &&
            metricsHistory[i].timestamp <= endTime) {
            timestamps[index] = metricsHistory[i].timestamp;
            ratios[index] = metricsHistory[i].solvencyRatio;
            assets[index] = metricsHistory[i].assets;
            liabilities[index] = metricsHistory[i].liabilities;
            index++;
        }
    }

    return (timestamps, ratios, assets, liabilities);
}

function getHistoricalDataInfo() external view returns (
    uint256 totalEntries, uint256 maxEntries,
    uint256 oldestTimestamp, uint256 newestTimestamp,
    uint256 minInterval) {

    totalEntries = metricsHistory.length;
    maxEntries = MAX_HISTORY_ENTRIES;
    minInterval = MIN_ENTRY_INTERVAL;

    if (totalEntries > 0) {
        oldestTimestamp = metricsHistory[0].timestamp;
        newestTimestamp = metricsHistory[totalEntries - 1].timestamp;
    }

    return (totalEntries, maxEntries, oldestTimestamp,
        newestTimestamp, minInterval);
}

Emergency Response System

function emergencyPause() external onlyEmergencyGuardian {
    emergencyPaused = true;
    pauseEndTime = block.timestamp + 4 * 3600; // 4 hour default
    emit EmergencyPaused(msg.sender, pauseEndTime);
}

function emergencyUnpause() external onlyEmergencyGuardian {
    emergencyPaused = false;
    pauseEndTime = 0;
    emit EmergencyUnpaused(msg.sender);
}

function getEmergencyStatus() external view returns (
    bool isPaused, uint256 endTime, address guardian) {
    return (emergencyPaused, pauseEndTime, emergencyGuardian);
}

Gas Optimization Strategies

Bounded Operations

• Maximum array sizes (50 tokens per update) to prevent out-of-gas
• Historical data pagination (max 100 entries per query)
• Efficient storage patterns with bounded retention periods

Storage Optimization

• Circular buffer approach for historical data rotation
• Rate-limited historical entries (minimum 1-hour intervals)
• Compact data structures minimizing storage overhead

Testing and Validation Requirements

Comprehensive Test Coverage

• Mathematical precision validation for ratio calculations
• Security feature testing (access control, rate limiting, circuit breakers)
• Oracle reliability testing under various market conditions
• Gas consumption analysis with stress testing
• Emergency scenario simulation with pause/unpause cycles

Production Deployment Requirements

Production implementations should ensure:

• Multi-oracle consensus mechanism implemented and tested
• Circuit breaker triggers validated with historical data
• Rate limiting prevents spam without blocking legitimate updates
• Emergency pause/unpause mechanisms tested with time delays
• Gas optimization prevents DoS while maintaining functionality
• Access controls follow principle of least privilege
• Historical data storage bounded and efficient
• Security parameters documented and transparent

Integration Patterns

Oracle Integration

• Primary oracle feeds (Chainlink, API3) with fallback mechanisms
• TWAP integration for manipulation resistance
• Staleness detection with automatic fallback to secondary oracles

Liquidation System (Optional Enhancement)

struct LiquidationConfig {
    uint256 maxLiquidationRatio;  // Max % liquidatable
    uint256 liquidationBonus;     // Liquidator bonus
    uint256 minHealthFactor;      // Minimum health factor
    uint256 maxSlippage;          // Slippage tolerance
    bool isActive;
}

function safeLiquidation(address protocol, address user,
    uint256 debtAmount, uint256 expectedCollateral, uint256 maxSlippage)
    external returns (uint256 actualCollateral, uint256 liquidationBonus) {
    // Comprehensive liquidation logic with health factor validation
    // Slippage protection and bonus calculation
    // Position updates and event emission
}

This implementation demonstrates production-ready patterns for DeFi protocol solvency monitoring with enterprise-grade security, gas optimization, and comprehensive risk management.

Security Considerations

When implementing solvency monitoring for DeFi protocols, security isn’t optional—it’s essential. We’ve learned hard lessons from protocol failures, oracle manipulation attacks, and market crashes. This section covers the practical security measures you need to implement, drawn from what actually works in production systems like Aave, Compound, and MakerDAO.

Oracle Security - Implementation Requirements

Price Feed Validation

• Minimum 3 independent oracle sources with median aggregation to prevent single points of failure
• Deviation threshold checks: Reject price updates exceeding 5% difference between sources
• Staleness validation: ETH/USD and major crypto pairs should use 1-hour maximum staleness (3600 seconds)
• Circuit breaker integration: Pause solvency updates when price movements exceed 20% in single block

Implementation patterns for price validation should include median calculation, deviation checks, and appropriate error handling.

Real-world reference: Chainlink’s Feed Registry and Aave’s AaveOracle provide solid patterns for oracle integration.

TWAP Integration

• 30-minute minimum windows for manipulation resistance (based on Uniswap V3 security analysis)
• Minimum $1-5M liquidity in reference pools for oracle reliability
• Combined validation: Primary Chainlink feeds with Uniswap V3 TWAP backup verification

Oracle Failure Handling

Implementations should include fallback mechanisms for oracle failures, including timestamp validation, secondary oracle integration, and graceful degradation patterns.

Access Control - Specific Implementation

Role-Based Permissions

Implementations should use established access control patterns such as OpenZeppelin’s AccessControl for role management, including oracle roles, emergency roles, and administrative functions.

Rate Limiting Implementation

• Maximum 1 update per 5 blocks per authorized oracle to prevent spam attacks
• Daily update limits: 288 updates per day (every 5 minutes) for high-frequency protocols
• Emergency cooldowns: 1-hour minimum between emergency pause activations

Rate limiting should be implemented using block-based cooldowns and per-oracle tracking.

Multi-signature Requirements

• 3/5 multisig for parameter changes (threshold updates, oracle management)
• 4/7 multisig for critical upgrades (we borrowed this from Compound V3)
• Separate emergency pause authority from main governance (Aave’s Guardian model works well here)

Risk Management - Concrete Parameters

Threshold Calibration with Production Values

Alert System Implementation

Risk threshold monitoring should include graduated alerts (CRITICAL, HIGH_RISK, WARNING) with appropriate automated responses.

Historical Data Protection

• Immutable storage patterns to prevent historical data manipulation
• Checksum validation for stored historical ratios using merkle trees
• Maximum storage limits: 8760 hourly records (1 year) to prevent unbounded growth

Emergency Response Mechanisms

Circuit Breaker Integration

Circuit breaker mechanisms should monitor for dramatic value changes and automatically pause operations when thresholds are exceeded. Implementation should include emergency pause states, time-based recovery, and appropriate event emission.

• Automatic pause triggers: Oracle deviation >20%, liquidity drop >50% in 1 hour
• Initial pause duration: 1-4 hours with exponential backoff for repeated triggers
• Gradual resume: 25% → 50% → 75% → 100% capacity with 30-minute monitoring between phases

Time Delays for Critical Operations

• Protocol upgrades: 7 days (604,800 seconds) following MakerDAO governance pattern
• Threshold parameter changes: 48 hours (172,800 seconds)
• Oracle authority changes: 24 hours (86,400 seconds) with immediate emergency override

Gas Optimization Security

Bounded Operations

Implementations should enforce reasonable limits on array sizes, historical data storage, and operation complexity to prevent denial-of-service attacks and ensure predictable gas consumption.

DoS Attack Prevention

• Maximum 50 tokens per update to prevent out-of-gas scenarios
• Pagination for historical queries with max 100 records per call
• Input validation: Reject empty arrays, validate array length consistency
• Reentrancy protection: Use OpenZeppelin’s ReentrancyGuard for all external calls

Integration Security Patterns

Liquidation Protection Pattern

Note: This is a recommended integration pattern for protocols implementing this ERC. The core solvency monitoring contract focuses on solvency monitoring; liquidation logic should be implemented in the consuming protocol.

Liquidation integrations should include health factor validation, partial liquidation limits, and slippage protection mechanisms.

• Health factor buffers: 110% warning threshold before 105% liquidation
• Partial liquidation limits: Maximum 50% of debt in single transaction
• Slippage protection: 3% maximum slippage for automated liquidations

Validation and Testing Requirements

Stress Testing Scenarios

• 50% market crash simulation with proper threshold triggers
• Oracle manipulation attempts with 20%+ false price movements
• High-frequency update scenarios testing rate limiting effectiveness
• Network congestion testing with increased gas prices

Audit Requirements

• Formal verification of solvency calculation logic
• Oracle integration testing across multiple price feed providers
• Emergency scenario testing including pause/unpause cycles
• Gas consumption analysis for all operations under stress conditions

Production Deployment Requirements

Production implementations should ensure:

• Multi-oracle consensus mechanism implemented and tested
• Circuit breaker triggers validated with historical data
• Rate limiting prevents spam without blocking legitimate updates
• Emergency pause/unpause mechanisms tested with time delays
• Gas optimization prevents DoS while maintaining functionality
• Access controls follow principle of least privilege
• Historical data storage bounded and efficient

These security considerations are based on production implementations from Aave V3, Compound V3, MakerDAO, and Synthetix protocols, incorporating lessons learned from actual security incidents and governance responses in the DeFi ecosystem. The specific parameters and thresholds have been validated through extensive testing scenarios including market crashes, oracle manipulation attempts, and high-frequency trading conditions.

Production-Validated Security Parameters

All security parameters have been validated against real-world DeFi protocols:

Security Documentation: Security validation reports and fork testing guides are available for detailed parameter validation and mainnet validation instructions.

Test Coverage: Implementations should include comprehensive test suites covering core functionality, security features, and edge cases. Every security-critical code path should be tested.

Testing Approach: Test contracts should simulate attack scenarios and consensus mechanisms. They should provide comprehensive coverage of potential attack vectors and edge cases that protocols implementing this ERC should be prepared to handle.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Sean Luis Guada Rodríguez (@SeanLuis) <seanluis47@gmail.com>, "ERC-7893: DeFi Protocol Solvency Proof Mechanism [DRAFT]," Ethereum Improvement Proposals, no. 7893, January 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7893.