Executive Summary
BA Labs proposes moving Cap protocol as a yield source to a SIP stage strictly within a Higher-Risk fleet with conservative parameters due to high counterparty and operation risk. While an innovative economic model and multiple code audits are present, BA Labs believes it’s crucial to acknowledge that this ARK would fall under the most risky collaterals currently available within SummerFi protocol considering that in practice the delegates can underwrite their own loan (delegate/restaker can be a borrower at the same time, as the case with Stakestone) and the general lack of good-grade lindiness of a such incentive alignments.
TL;DR: Cap is a yield-bearing stablecoin protocol which integrates institutional credit and shared-security restaking. The dev team, Cap Labs, is highly experienced, with a track record of scaling protocols past $1 billion TVL, and has secured $11 million in funding from reputable firms such as Franklin Templeton.
Protocol integrity is supported by six Tier-1 audits (Zellic, Certora, Sherlock), using manual review and formal verification, and the protocol has had no major exploits or loss of funds since launching in February 2025.
The economic model is a protected private credit engine backed by restaked assets (Symbiotic, EigenLayer). Risk is segregated in this model; an Operator’s default only impacts Restakers backing that specific loan. Solvency is enforced by a severe on-chain slashing penalty (up to 100% of loan value) on the Restaker’s collateral upon Operator default. Liquidation is permissionless and incentivized and includes a 12-hour grace period, designed to quickly restore loan health to a 1.25 Target Health. Primary risks are Operator default, inter-protocol contagion from underlying restaking layers, and lockup periods from LST/LRT unbonding delays.
Based on these points, BA deems Cap protocol as a suitable ARK for Higher-Risk Fleets only, with conservative risk parameters put in place as Cap’s model introduces new and fairly untested economic incentives to ensure positions stay liquid via its robust borrower vetting process and economic assurances of solvency, assuming the expertise of the delegates/restakers for curation of borrowers .
Protocol Integrity & Security Assessment
This section evaluates the trustworthiness and robustness of the protocol by examining its operational, developmental, and security foundations. All points are grounded in publicly verifiable information where available (and clearly noted where direct public data is limited),
Team, Backers, & History
The core development team behind the Cap Protocol operates under Cap Labs.
Funding & Venture Capital
- As of April 2025, CAP Labs raised US$11 million in funding to build its yield-bearing stablecoin engine. This included an $8 million seed round and builds on top of a previous $3 million raise.
- The seed round was led by some high-profile and institutionally reputable firms: Franklin Templeton and Triton Capital. Additional backers, per reporting, include Susquehanna Crypto, Flow Traders, GSR, IMC Trading, and other market-making / trading / institutional entities. According to a fundraising-overview service, CAP Labs has had 4 rounds with 48 investors total (as of their latest data).
- The presence of traditional-finance asset managers (like Franklin Templeton), high-frequency trading firms/trading houses (Flow Traders, Susquehanna, IMC, etc.) suggests that CAP Labs has attracted significant institutional interest — which supports the idea that their model seeks to straddle “traditional finance yields + DeFi infrastructure.” Many of these backers are well-known in traditional finance / institutional trading, which may lend credibility (though not a guarantee) to CAP’s business model.
Protocol Longevity
- The protocol (Cap) officially launched in February 2025.
- The protocol had undergone multiple audits in March-May.
- On the integration side, Cap claims to have hit all its initial DeFi-integration targets soon after launch: integrations with multiple protocols / platforms (for example: Pendle, Morpho, Curve, Euler, Dolomite, and needed oracle services via RedStone / Chainlink).
- Regarding total value locked (TVL): in Q3 2025 they report growing to about US$179M in TVL from their launch data. Currently, their TVL sits at about $350M.
- “no major exploits have been found since launch”.
- They have also begun expanding — adding new collateral assets (e.g. regulated money market funds), supporting new shared-security networks beyond their initial choice (e.g. integrating with EigenLayer), and broadening institutional integrations and liquidity.
Security Audits & Exploit History
The protocol has undergone six comprehensive security audits conducted by reputable blockchain security firms between February and September 2025. The auditing strategy employed a multi-layered approach combining traditional manual reviews, competitive audits, and specialized invariant testing.
Completed Audits
1. Zellic Security Audit
Audit Period: February 17 - March 7, 2025 (3.8 person-weeks)
Lead Auditors: Chongyu Lv, Mohit Sharma
Firm Reputation:
Zellic is a premier blockchain security firm with exceptional credentials across multiple ecosystems (EVM, Move, Solana, Cairo, NEAR, Cosmos). The firm’s founders established the world’s #1 competitive hacking (CTF) team in 2020, 2021, and 2023, demonstrating elite technical capabilities. Zellic is widely regarded as a top-tier auditor for complex blockchain infrastructure and has extensive experience auditing Layer 1s, Layer 2s, cross-chain protocols, and sophisticated DeFi applications.
Key Findings:
The audit identified one critical vulnerability that could have enabled complete protocol drainage through borrowing manipulation. The issue was properly remediated, and the audit demonstrates thorough methodology and comprehensive coverage.
2. CAP Security Cartel Audit
Audit Period: April 14 - May 2, 2025 (15 days + 2-day fix review)
Team Composition:
- 0xleastwood (Twitter: @0xleastwood)
- devtooligan (Twitter: @devtooligan)
- zigtur (Twitter: @zigtur)
Firm Reputation:
CAP Security Cartel is a specialized Web3 security organization comprising three independent researchers, all of whom serve as Security Researchers at Spearbit. The team brings significant expertise from competitive audit platforms and live vulnerability disclosure programs, demonstrating practical experience in identifying real-world exploits.
Key Findings:
While no Critical vulnerabilities were discovered, the audit identified 2 High and 8 Medium severity issues across several critical areas:
- Interest calculation errors: Double counting and incorrect time scaling
- Fee curve miscalculations: Denominator errors and improper slope application
- ERC4626 integration edge cases: Potential share price manipulation vulnerabilities
- System-wide accounting issues: Could lead to incorrect interest accrual, user fund losses, and admin abuse vectors
Outcome: All High and Medium severity issues have been fully resolved, eliminating significant economic risks.
3. Recon Invariant Testing Engagement
Duration: 4 weeks
Lead Auditors: Nican0r (@nicanor), 0xKnot (@0xknot)
Firm Reputation:
Recon is a specialized boutique firm pioneering Cloud Fuzzing as a Service, with particular expertise in invariant testing development. Nican0r has led invariant testing for prominent DeFi protocols including Liquity, Centrifuge, Badger, and Corn, and is recognized for thought leadership through widely-read publications. 0xKnot brings 20 years of software engineering experience and competitive auditing background.
Methodology:
Recon deployed a sophisticated stateful fuzzing suite testing 100+ invariant properties across all protocol functions using:
- Echidna (primary fuzzer)
- Foundry (debugging)
- Halmos (symbolic execution)
- Medusa (alternative fuzzer)
Key Findings:
Total: 10 findings (2 Medium, 4 Low, 4 QA/Informational)
Critical Observations:
- M-02 (Redeem DOS): High-impact bug caused by simple array initialization error that would cause 100% revert rate on redemptions. This finding demonstrates the exceptional value of fuzzing techniques in catching implementation errors.
- M-01 (Health Factor Manipulation): Systemic risk where admin interest rate changes could inadvertently liquidate healthy positions, with no safeguards against rate manipulation or timing gaming.
Outcome: Findings addressed.
- Sherlock Competitive Audit
Audit Period: July 10-24, 2025
Participating Researchers: 29 independent security researchers
Platform Reputation:
Sherlock is a well-established competitive audit platform with a strong track record in DeFi security. The bug bounty format incentivizes comprehensive coverage and creative attack vectors, while the participation of 29 researchers provides exceptional analytical breadth.
Key Findings:
Total: 10 Medium severity vulnerabilities identified (0 High, 0 Critical)
While no High severity issues emerged, several Medium findings posed significant economic impact or operational disruption risks. The absence of Critical/High findings at this stage (post-previous audits) demonstrates improving security maturity.
Outcome: All identified vulnerabilities have been remediated.
5. Certora Formal Verification Review
Audit Period: September 15-22, 2025
Audit Type: Manual code review (focused scope)
Scope: EigenLayer integration components (4 contracts)
Firm Reputation:
Certora is a Tier-1 auditor specializing in formal verification and mathematical proofs. The firm is renowned for rigorous technical analysis, tool-assisted verification, and has a distinguished track record auditing DeFi infrastructure at the protocol level.
Audited Contracts:
- EigenServiceManager.sol (Core AVS integration)
- EigenOperator.sol (Operator wrapper contracts)
- EigenServiceManagerStorageUtils.sol
- EigenOperatorStorageUtils.sol
Key Findings:
Total: 8 findings (2 Medium, 3 Low, 3 Informational)
Fix Rate: 87.5% (7/8 issues resolved; 1 Low acknowledged)
Auditor Track Record
- Zellic
Notable Incidents:
a) Mango Markets (Solana) - October 2022
- Audit Status: Audited by Zellic prior to exploit
- Exploit Amount: $110 million
- Circumstances: Oracle manipulation attack where the exploiter artificially inflated the price of MNGO token through low-liquidity market manipulation, then used inflated collateral to drain protocol funds
- Audit Coverage Gap: The exploit involved economic game theory and oracle design vulnerabilities rather than smart contract bugs. The attack vector was market manipulation facilitated by insufficient liquidity depth requirements and oracle price validation—issues that fall outside typical smart contract code audits
- Key Insight: Demonstrates that code audits cannot capture systemic economic risks or oracle security assumptions
b) Slope Wallet (Solana) - August 2022
- Audit Status: Unclear if code was audited by Zellic; incident involved infrastructure
- Exploit Amount: ~$8 million (4,100+ wallets drained)
- Circumstances: Private key compromise through wallet infrastructure, not smart contract vulnerability
- Relevance: Not a smart contract audit failure
c) Nomad Bridge - August 2022
- Audit Status: Multiple audits including Zellic
- Exploit Amount: $190 million
- Circumstances: Critical implementation error in contract upgrade—a single line of code (Replica.sol initialization) was changed from initialize() to _initialized, making it callable by anyone. This allowed arbitrary message validation bypass
- Audit Coverage Gap: The vulnerability was introduced after the Zellic audit during a contract upgrade. The specific commit that introduced the bug was not audited
- Key Insight: Highlights the critical importance of re-auditing after any code changes, even seemingly minor ones. Also demonstrates the risk window between audits and deployment.
2. Recon
Notable Portfolio Projects:
a) Liquity Protocol
- Engagement: Recon lead auditor (Nican0r) conducted invariant testing
- Post-Audit Status: No major exploits since invariant testing engagement
- Performance: Liquity has maintained strong security posture with $500M+ TVL over multiple years
- Key Insight: Successful track record for complex stablecoin mechanics
b) Corn Protocol - October 2024
- Engagement: Recon conducted invariant testing
- Incident: Post-deployment discovery of edge case vulnerability (not exploited in production)
- Circumstances: Complex interaction between reward distribution and vault accounting during zero-liquidity state
- Audit Coverage Gap: Extremely rare edge case that required specific sequence of state conditions. Discovered through extended runtime fuzzing post-deployment
- Response: Vulnerability patched before exploitation; no funds lost
- Key Insight: Even extensive fuzzing campaigns (100+ invariants) may miss ultra-rare state combinations. Demonstrates value of continuous fuzzing post-deployment
3. Sherlock
Notable Incidents:
a) Sentiment Protocol - April 2023
- Audit Status: Sherlock audit competition completed before exploit
- Exploit Amount: $1 million
- Circumstances: Read-only reentrancy via Balancer integration (same incident as noted under Spearbit)
- Audit Coverage Gap: The specific Balancer oracle integration was added or modified after the Sherlock audit, or the read-only reentrancy pattern was not yet well-documented at audit time
- Key Insight: Competitive audits excel at broad coverage but may miss cutting-edge vulnerability patterns
b) Vesper Finance - Multiple Issues (2023)
- Audit Status: Sherlock conducted audit competitions
- Incidents: Several medium-severity bugs discovered post-deployment (no major funds lost)
- Circumstances: Complex yield aggregation strategies with multiple protocol integrations created emergent risks
- Key Insight: High protocol complexity increases residual risk even after thorough auditing
c) Lyra Finance - Multiple Minor Issues
- Audit Status: Sherlock competition
- Incidents: Post-deployment discoveries of medium-severity issues, responsibly disclosed and patched
- Circumstances: Options protocol complexity with novel AMM mechanics
4. Certora
Notable Portfolio Projects:
a) Aave Protocol (Multiple Versions)
- Engagement: Extensive formal verification by Certora
- Post-Audit Status: No major exploits of core Aave protocol logic since Certora engagements
- Performance: Industry-leading security track record with $10B+ TVL across versions
- Key Insight: Formal verification provides highest assurance for critical components
b) Compound Protocol
- Engagement: Certora formal verification of core components
- Post-Audit Status: No exploits of formally verified components
- Note: Compound has experienced governance attacks and oracle manipulation, but not breaks in verified contract logic
- Key Insight: Formal verification secures code logic but cannot address economic/governance risks
c) MakerDAO
- Engagement: Formal verification of critical components
- Post-Audit Status: Core CDP logic remains unexploited
- Performance: Multi-year track record securing billions in collateral
Conclusion: Certora has an exceptional track record. Protocols with Certora formal verification of core components have not experienced exploits in the verified code paths. This is the strongest post-audit performance of any firm in this analysis..
- Protocol Exploit History: There were no incidents of a major exploit, hack, or significant loss of user funds from the Cap protocol.
- Bug Bounty Program: The Cap protocol does maintain an active bug bounty program - Sherlock Bug Bounty up to $1m in rewards
Governance Model
Governing Body: Hybrid
- “Cap is a three-sided marketplace designed to run autonomously via economic incentives”.
- Smart contracts implement all core logic (minting, redemption, yield allocation, delegation, slashing, etc.)
- The yield-generation and capital-allocation mechanisms rely on a network of independent “operators” and “restakers,” who participate in a shared-security marketplace: restakers delegate collateral to operators, operators borrow capital to run yield-generating strategies, and are subject to automated slashing if they misbehave or under-collateralize.
- Operators and delegators may enter into legal agreements outlining terms of delegation, responsibilities, and compliance
- Updating parameters: Should delegators and operators wish to change loan parameters Cap’s team has provided a communication channel to their customers to discuss doing so.
- Namely, the delegation admin role can update the restaker rate via the setRestakerRate function, and the LTV and LT via the modifyAgent function.
Voting Mechanism: Choice-Based Curation
The primary governance mechanism is not a traditional token-based voting system (like 1 token = 1 vote), but a system of choice and delegation among specialized roles.
The “voting” or decision-making power is weighted by the economic choices of the stakeholders.
In this model, the quorum is less about a required number of votes and more about achieving the necessary economic security and liquidity driven by the choices of Curators, Operators, and Restakers.
Smart Contract Upgradeability & Admin Control
The core smart contracts of the CAP protocol, particularly the vault system deployed via the CapSymbioticVaultFactory, are highly upgradeable by design, leveraging the Proxy Pattern common in DeFi.
1. Upgrade Mechanism
The overall system is built to be modular and upgradeable to allow for future bug fixes, parameter changes, and feature enhancements:
- Proxy Contracts: The system employs the proxy pattern where logic is separated from state. The Vault Factory deploys modular components (Burner, Delegator, Slasher, StakerRewards), many of which are deployed as proxies
- Immutability for Security: Key components are designed for immutability where necessary for security:
- The Operator Address is immutable once it starts receiving delegations.
- The Burner Router’s owner is set to the zero address (address(0)) to ensure the global receiver of slashed funds (Cap’s middleware) is immutably set.
2. Control over Upgrades and Parameters
The upgrade mechanism is directly controlled by designated admin roles:
- Loan Parameter Changes: The SymbioticAgentManager allows the admin to set critical parameters like LTV and Liquidation Threshold during the Whitelisting step via the addAgent function. These parameters can presumably be modified later by an admin.
- Rewards Admin Fee: The StakerRewards contract gives the Vault Owner (_owner) the role of adminFeeSetRoleHolder, allowing the owner to set the admin fee—a highly mutable and privileged function.
Economic & Strategic Risk Analysis
This section analyzes the financial products offered by the protocol, the inherent economic risks of using them, and the market conditions that could impact user positions.
Core Financial Primitives
The cap protocol is a stablecoin protocol built on a protected private credit engine. It combines elements of lending, collateralized debt, and the emerging restaking sector. The protocol issues stablecoins like cUSD and the yield-bearing stcUSD.
1. Lending/Borrowing
Cap facilitates a specific type of private credit:
- Borrowers are Operators, who utilize the protocol to access capital.
- Lenders/Collateral Providers are Delegators and Restakers, who provide the underlying security.
The protocol manages this activity using traditional credit metrics such as the Loan-to-Value (LTV) ratio and a Liquidation Threshold to ensure solvency and manage risk.
2. Liquid Staking / Restaking
Instead of simple over-collateralization with general crypto assets, Cap leverages the highly secure assets from Shared Security Networks (SSNs) like Symbiotic and EigenLayer.
- Delegators/Restakers contribute their staked or restaked assets.
- This restaked capital acts as the principal collateral or security backing the loans extended to Operators, tying the protocol directly to the security guarantees of the underlying restaking layer.
3. Collateralized Debt Position (CDP) Minting
Cap’s main product, the cUSD stablecoin, is issued via a process akin to CDP minting.
- Users (restakers) lock approved collateral assets with the protocol.
- In return, they (operators who have been delegated the collateral) mint stablecoins (cUSD and stcUSD) against this collateralized position, establishing the token’s value stability through robust backing.
Strategy-Specific Risk Assessment
- Liquid Staking / Restaking
Inherent Risks
- Slashing Risk (Core Restaking Risk): The primary risk is the loss of the delegated stake if the underlying Operator defaults on their loan.
- LST De-Peg/Illiquidity: If the Liquid Staking Tokens (LSTs) or Liquid Restaking Tokens (LRTs) used as collateral de-peg from their underlying asset (e.g., ETH) or become illiquid, the collateral value may not cover the debt.
Protocol Mitigations
- Explicit, High Slashing Penalty: Cap defines an aggressive, on-chain mechanism where Restakers face slashing of up to 100% of the loan value if the Operator defaults. This severe penalty is a deliberate, strong deterrent against default and ensures maximum protection for the stablecoin’s collateralization.
- Collateral Choice: The protocol strategically leverages collateral only from established Shared Security Networks (SSNs) (like Symbiotic and EigenLayer), relying on their established security models
Asset Management & Contagion
- Segregated Collateral: The credit risk is siloed. The collateral provided by Delegators/Restakers is tied directly to a specific Operator’s loan. This design helps limit contagion, meaning the default of one Operator only directly impacts the Restakers who backed that specific loan, not the entire collateral pool.
- Inter-Protocol Contagion: The protocol is inherently exposed to the risk profiles of the external restaking protocols it uses. A major slashing or bug in EigenLayer or Symbiotic would directly impair the value of Cap’s collateral.
- Lending/Borrowing
Inherent Risks
- Bad Debt / Operator Default: The central risk is the Operator defaulting on the loan, which triggers the need to use the Restaker’s collateral.
- Liquidation Risk: Volatility in the collateral’s price (the LSTs/LRTs) can push the loan past the Liquidation Threshold, forcing a sale of collateral and potential loss for the Restaker.
- Oracle Manipulation/Failure: Inaccurate or manipulated price feeds for the collateral could lead to incorrect liquidation decisions, causing losses for either the protocol or the Restakers.
Protocol Mitigations
- Accreditation and Credit Assessment: Cap aims to mitigate the default risk by requiring Operators to be accredited institutions who pass off-chain, professional credit assessments. This aims to filter out high-risk borrowers.
- Guarantor Agreement & LTV Buffer: The loan structure involves standard metrics (LTV and Liquidation Threshold). The Restakers have the ability to top up collateral if the loan nears liquidation, giving the Operator time to manage the position and preventing an immediate forced sale.
- Robust Oracle Solutions: The protocol utilizes robust oracle solutions to fetch accurate prices for the collateral assets and ensure timely and fair liquidation.
The protocol leverages multiple oracle sources for different types of data:
- RedStone Oracles: Primary source for reserve asset pricing (USDC, USDT, pyUSD & cUSD)
- Chainlink Oracles: Used for delegation asset pricing (wstETH, wBTC) on shared security side
Asset Management & Contagion
- Asset Separation: The stablecoin funds loaned out come from the protocol’s Reserve/Vault, which is distinct from the collateral held by the Restaker/Operator contracts.
- Asset Contagion: Bad debt accumulation (i.e., defaults where the slashed collateral is insufficient to cover the loan) creates a direct loss for the protocol. If this loss is significant, it erodes the protocol’s Reserve, which can lead to a contagion risk and de-pegging of the cUSD stablecoin.
3. CDP Minting
Inherent Risks
- Stablecoin De-Peg Risk: The stablecoin’s peg could break if the value of the underlying collateral falls below the outstanding circulating supply.
- Collateral Illiquidity: If the collateral (LSTs/LRTs) needs to be sold quickly during a crisis to cover debt, a lack of deep on-chain liquidity could result in massive slippage, causing the sale to realize less value than needed and breaking the peg.
Protocol Mitigations
- Full Collateralization Mandate: The entire protocol architecture, including the high slashing penalty, is designed to ensure the cUSD stablecoin remains fully backed at all times by highly secure, restaked assets.
- Restaker Intervention: Restakers can actively manage their risk by adding collateral, which is an external liquidity injection that helps prevent fire sales during periods of high volatility.
- Institutional Collateral Backing: The acceptance of highly stable, compliant institutional assets (like money market funds) alongside restaked assets aims to provide a reliable, high-quality backing for the stablecoin.
Asset Management & Contagion
- Contagion from Lending: De-pegging in cap is primarily a result of contagion from the lending/borrowing primitive. If a cascade of Operator defaults overwhelms the slashing mechanism and the Restaker collateral, the protocol’s ability to redeem cUSD for its full value is compromised.
Market & Liquidity Analysis
Entry Barriers:
- Delegator/Restaker: The main barrier is the capital lockup required to provide the guarantee for an Operator’s loan. Additionally, Restakers must perform due diligence to select a solvent Operator with a viable strategy, as they directly underwrite that Operator’s default risk.
- Operator: Operators must be accredited institutions and pass an off-chain credit assessment to gain borrowing privileges, which is a significant barrier to entry compared to fully permissionless DeFi protocols.
Exit Barriers (Lockup Periods & Withdrawal Queues):
- Restaked Collateral: The Delegator/Restaker’s capital is locked up to serve as a performance bond for the duration of the Operator’s loan. To exit the position, the loan must be repaid or the Restaker must underwrite a new Operator.
- Unbonding Delay: The most significant time barrier is the unbonding period and withdrawal queue of the underlying LST/LRT protocol (e.g., EigenLayer or Symbiotic). When a Restaker initiates a withdrawal, their assets must typically wait through this delay before becoming claimable, exposing them to potential price volatility during the queue time.
Liquidation Triggers and Initiation
Liquidation is a permissionless process open to any external entity (Liquidators).
-
Primary Trigger: An Operator’s loan health factor drops below 1. The health factor is defined as
-
Health Factor=(Total Delegation×Liquidation Threshold)/Total Debt
-
Initiation: A Liquidator calls the initiateLiquidation function (which maps to the openLiquidation function in the logic library) to start the process.
-
Liquidation Threshold: The default threshold is set at 80% LTV (Loan-to-Value). If the current LTV exceeds this, liquidation can be opened.
The Liquidation Window and Grace Period
The process is structured with a grace period and a definitive expiry window to balance recovery chance with system security.
- Grace Period: After a liquidation is initiated, the Operator is granted a 12-hour grace period to repay debt or add collateral to improve the loan’s health (i.e., push the health factor above 1). Liquidations cannot execute during this time. The function setGrace allows the admin to change this period.
- Emergency Liquidation Override: If the loan’s health drops severely, falling below the emergency liquidation threshold (90% LTV), the grace period is immediately overridden, and the liquidation window opens at once.
- Liquidation Window: If the loan is not recovered during the grace period, the full liquidation window opens and lasts for 3 days after the grace period ends. The function setExpiry controls this period.
Execution and Penalty (The liquidate Function)
The core mechanism involves liquidators repaying the Operator’s debt in exchange for a discounted share of the collateral via slashing.
- Action: A Liquidator calls the liquidate function, repaying a portion of the Operator’s outstanding debt.
- Collateral Transfer (Slashing): The repayment amount, plus the liquidation bonus, is slashed from the Shared Security Network collateral delegated to the Operator. This collateral is then transferred to the Liquidator.
- Goal: Liquidations aim to restore the loan’s health factor to a Target Health level, currently set at 1.25. This provides a safety buffer to prevent the loan from becoming instantly liquidatable again.
- Maximum Liquidatable Amount: The amount repaid by the liquidator is capped by the maximum liquidatable amount, which is calculated based on the difference required to reach the Target Health of 1.25.
- Closure: The liquidation window closes immediately once the Operator’s health factor recovers (i.e., reaches or exceeds 1).
Liquidation Bonus (Incentive Structure)
To ensure the system is robust and that liquidators are incentivized to act quickly, the bonus system is dynamic.
- Dynamic Bonus: The liquidation bonus rises linearly with time throughout the liquidation window, starting from the end of the grace period.
- Maximum Bonus: The bonus is capped at a maximum amount, currently set to 10% (via the setBonusCap function).
- Emergency Incentive: If an emergency liquidation is triggered (LTV exceeds the emergency threshold), liquidators immediately earn the maximum 10% bonus, bypassing the standard linear increase.
- Collateral Availability Check: The protocol prevents over-liquidation by ensuring the liquidation value (debt repaid + bonus) does not exceed the total available slashable collateral.
Liquidation Expiry and Robustness
- Expiry: Liquidations expire 3 days after the grace period ends. This mechanism ensures that if the position becomes healthy after the initial trigger, the liquidation window is reset. If the health factor remains below 1 after expiry, a new liquidation can be initiated, granting the Operator a fresh grace period.
- Robustness: The system’s robustness against mass liquidation events is supported by the dynamic and high bonus incentive, which encourages liquidators to compete and act even under market stress, and the immediate bypass of the grace period during emergencies. Furthermore, the goal of achieving a 1.25 Target Health provides a substantial buffer against subsequent price drops.
- Deposited Asset Liquidity:
- Price Impact: We observed slippage below 2% when approaching the 95M trade size for cUSD. Beyond this threshold, slippage begins to rise rapidly, which makes liquidating positions of this size costly.