Invariant
This document details a framework of invariants inspired by the Compound protocol's validation logic, which were then applied and validated across other DeFi protocols to ensure consistent reliability and functionality. Invariants are conditions that must always remain true to maintain protocol stability and integrity.
By setting these invariants as a foundation, the document examines how each invariant behaves within different protocols and identifies any significant deviations in implementation.
Items that have a impact on security and trust are categorized as Essential, while those with a minor impact or that may be absent depending on implementation are categorized as Flexible.
Deposit
Collateral deposits should be paused when needed.
Allowing deposits while the protocol is paused could lead users to transact in an abnormal state, exposing assets to potential loss due to system errors, threats, or emergencies.
The collateral market must use the latest state.
Using outdated data for collateral values or market conditions can cause issues like inaccurate interest calculations, leading to potential losses and an unstable system state.
Withdrawal
Withdrawals must maintain LTV ratios.
Allowing withdrawals that violate LTV ratios risks borrower liquidation due to inadequate collateral, which can harm protocol stability and expose users to unexpected liquidations.
Collateral withdrawal market should be updated.
Transacting on outdated market information for collateral could lead to inaccurate interest calculations and potential losses, potentially destabilizing the system's overall financial health.
Borrow
No loans when the protocol is paused.
Allowing loans during a protocol pause may result in transactions in an abnormal state, exposing assets to potential loss.
Borrower must be registered in relevant market.
Allowing unregistered borrowers increases the risk of unauthorized access, leading to abuse and potential unmanageable losses for the protocol.
Total borrow must not exceed set borrow cap after loan execution.
Exceeding borrow cap could deplete liquidity, preventing other users from borrowing or withdrawing and compromising protocol stability.
Borrowers must not exceed LTV limits.
Loans exceeding the LTV limit increase liquidation risk, impacting asset stability and risking collateral depletion that harms overall protocol stability.
Target market must reflect the latest status.
Using outdated data for collateral values or market conditions in borrowing can lead to incorrect interest calculations, system instability, and potential user losses.
Repay
Repayment market should reflect latest status.
Using outdated market information for repayment calculations can cause interest miscalculations, risking user funds and overall system stability.
Repayment cannot exceed borrowed amount.
Allowing excessive repayment could result in user funds becoming locked within the protocol, leading to user frustration and potential asset inaccessibility.
Liquidation
Only borrowers over LTV limits are eligible.
Allowing arbitrary liquidation without LTV limits could lead to unnecessary user asset losses, damaging trust and fairness in the protocol.
Repayment must not exceed close factor.
Over-liquidation could lead to complete liquidation of user assets, negatively impacting protocol liquidity and potentially leading to protocol instability.
Collateral and borrow markets must be latest.
Using outdated market data during liquidation may cause miscalculations, leading to inaccurate asset valuations, potential user losses, and unstable protocol performance.
Liquidator and borrower cannot be same account.
Allowing liquidator and borrower to be the same can lead to abuse, potentially undermining protocol integrity and fairness in liquidation processes.
Liquidator's collateral must be within limit.
If a liquidator receives more than the borrower's collateral balance, this can cause losses to other users' assets, destabilizing the protocol and compromising asset security.
Collateral and borrowed assets need same admin.
Different administrative control could introduce unnecessary transfer processes and cause calculation discrepancies, adding complexity and potential errors in liquidation processes.
Interest and Rewards
Interest calculation must use updated state variables.
If interest calculation uses outdated state variables, inaccuracies may arise, causing financial discrepancies and unfair distribution of earnings or losses among users.
Borrow interest rate must not exceed maximum set value.
Exceeding the maximum interest rate could unfairly burden borrowers, reducing protocol use and damaging user trust.
Interest calculations must reflect the latest protocol state.
Failing to use the latest state for interest calculations can result in incorrect accruals, causing imbalances in protocol finances and impacting trust and protocol stability.
For fixed-point arithmetic, steps should be taken to prevent rounding issues in low decimal places, such as using correct operation order or a fixed-point library.
Tiny values in the calculation of user interest or rewards can be compromised, potentially leading to user losses.
Oracle
Oracle must not return zero price for underlying assets; transaction should halt if zero is returned.
If a zero price is used, it could lead to incorrect calculations and potential exploits, risking significant financial losses and system instability.
Data from oracle must be up-to-date.
Outdated oracle data may result in inaccurate valuations, leading to incorrect transactions, user losses, and diminished protocol reliability.
These invariants provide a comprehensive framework for evaluating protocol safety and reliability, ensuring that essential conditions remain intact across various scenarios. By enforcing such invariant checks, developers can uphold protocol integrity and guard against inconsistencies or vulnerabilities.
Last updated