ERC-7893: DeFi Protocol Solvency Proof Mechanism

Interface for DeFi protocols to implement verifiable solvency proofs and monitor financial health status

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.

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 Interfaces

The standard defines a comprehensive interface for solvency verification. Key features include:

1. Asset and Liability Management
   • Protocol assets tracking
   • Protocol liabilities tracking
   • Real-time value updates

// 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
        uint256[] values;    // Value in ETH of each token amount
        uint256 timestamp;   // Last update timestamp
    }

    /**
     * @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
        uint256[] values;    // Value in ETH of each liability
        uint256 timestamp;   // Last update timestamp
    }

    /**
     * @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
     * @param endTime End of time range
     * @return timestamps Array of historical update timestamps
     * @return ratios Array of historical solvency ratios
     * @return assets Array of historical asset states
     * @return liabilities Array of historical liability states
     */
    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;
}

Optional Oracle Management

While not part of the core standard, implementations should consider including oracle management:

// Recommended but not required
event OracleUpdated(address indexed oracle, bool authorized);
function setOracle(address oracle, bool authorized) external;

This provides:

• Flexible price feed management
• Security controls
• Update authorization

The core standard focuses on solvency verification, leaving oracle management implementation details to individual protocols.

How the Interface Works

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.

Asset and Liability Management

Authorized oracles are responsible for updating the protocol’s asset and liability data using the updateAssets and updateLiabilities functions. These updates include the list of tokens, their respective amounts, and their current values denominated in ETH. Each update is timestamped, ensuring that all solvency calculations and historical records are based on the most recent and accurate data available. The interface enforces that all arrays provided must be of equal length, and values must be denominated in ETH with 18 decimals for consistency and comparability.

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 the minimum required solvency ratio (e.g., 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

To support audits, regulatory requirements, 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.

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. If a risk threshold is 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). Only authorized oracles can update asset and liability data, ensuring 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 are expected to:

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

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

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 our 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 our comprehensive test suite covering market crashes, volatility scenarios, and complex asset portfolios as documented in our test cases.

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

For more details please visit: Solvency Proof Implementation

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 Contract Implementation

SolvencyProof.sol provides a complete implementation of the ISolvencyProof interface with:

• Full asset and liability tracking functionality
• Configurable risk thresholds with alert mechanisms
• Historical data management with efficient storage patterns
• Oracle integration with security controls
• Comprehensive event emission for off-chain monitoring

This implementation is under license: MIT

Test Suite

SolvencyProof.test.ts contains an extensive test suite that:

• Validates mathematical accuracy of solvency calculations
• Simulates market volatility scenarios including 50% flash crashes
• Tests threshold breach detection and alert mechanisms
• Demonstrates oracle integration patterns and failure handling
• Provides gas optimization benchmarks for key operations

The implementation has been tested across various market conditions and validated to handle extreme volatility while maintaining accurate solvency reporting.

For more information please visit: Test Case Documentation

Implementation Highlights

1. Risk Management Module
   • Dynamic threshold adjustment based on market conditions
   • Multi-level alerting system with escalation paths
   • Historical trend analysis for early detection
2. Oracle Security Features
   • Price deviation checks preventing manipulation
   • Multiple oracle support with consensus mechanisms
   • Fallback systems for oracle failures
3. Gas Optimization Techniques
   • Batch update mechanisms for token collections
   • Efficient storage patterns for historical data
   • Optimized calculation methods for solvency ratio

This reference implementation demonstrates that the standard is practical, gas-efficient, and provides meaningful protection against insolvency risks in real-world conditions.

Security Considerations

Key security considerations include:

1. Oracle Security:
   • Multiple price feed sources
   • Manipulation resistance
   • Fallback mechanisms
2. Access Control:
   • Authorized updaters
   • Rate limiting
3. Risk Management:
   • Threshold calibration
   • Alert system reliability

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.