# Table of Contents - [Introduction | cap](#introduction-cap) - [Why Cap? | cap](#why-cap-cap) - [Protocol Actors | cap](#protocol-actors-cap) - [Protocol Overview | cap](#protocol-overview-cap) - [FAQs | cap](#faqs-cap) - [cUSD Mechanics | cap](#cusd-mechanics-cap) - [Risks | cap](#risks-cap) - [Shared Security Networks | cap](#shared-security-networks-cap) - [stcUSD Mechanics | cap](#stcusd-mechanics-cap) - [Symbiotic | cap](#symbiotic-cap) - [EigenLayer | cap](#eigenlayer-cap) - [Operator Onboarding | cap](#operator-onboarding-cap) - [EigenLayer | cap](#eigenlayer-cap) - [Delegator Onboarding | cap](#delegator-onboarding-cap) - [Symbiotic | cap](#symbiotic-cap) - [Overview | cap](#overview-cap) - [Minter | cap](#minter-cap) - [Symbiotic | cap](#symbiotic-cap) - [Fractional Reserves | cap](#fractional-reserves-cap) - [Addresses | cap](#addresses-cap) - [Interest Rates | cap](#interest-rates-cap) - [Terms and Conditions | cap](#terms-and-conditions-cap) - [Delegation | cap](#delegation-cap) - [Access Controls | cap](#access-controls-cap) - [Frontier Program | cap](#frontier-program-cap) - [Liquidation | cap](#liquidation-cap) - [Audits | cap](#audits-cap) - [Lender | cap](#lender-cap) - [Fee Auction | cap](#fee-auction-cap) - [Privacy Policy | cap](#privacy-policy-cap) - [Helpful Links | cap](#helpful-links-cap) - [Oracles | cap](#oracles-cap) - [Platform Terms of Use | cap](#platform-terms-of-use-cap) - [Borrow | cap](#borrow-cap) - [Vault | cap](#vault-cap) - [Email Protection | Cloudflare](#email-protection-cloudflare) --- # Introduction | cap Cap is a stablecoin protocol that provides credible financial guarantees via two products: the dollar-denominated cUSD and the yield-bearing stcUSD. cUSD is a digital dollar issued on the Ethereum blockchain that can be used on any network. cUSD's reserve is backed by blue chip stablecoins such as USDC, USDT, pyUSD, BUIDL, and BENJI, i.e. issued by regulated institutions with transparent attestations. It is 1:1 redeemable for any of the available reserve assets. stcUSD is a savings product issued by staking cUSD. Any cUSD holder has open access to stcUSD. Yield is generated via an autonomous layer of operators, who self-select in and out based on the current hurdle rate of the protocol. The risk of yield generation is covered, meaning users have full downside protection that is verifiable by code. Please find us at the [community forum](https://capcommunity.discourse.group/c/questions/2) if you have any questions. [NextWhy Cap?](https://docs.cap.app/why-cap) Last updated 6 months ago --- # Why Cap? | cap In the ever-evolving landscape of crypto, Cap functions as the credibly neutral and open aggregate layer atop the currently fragmented landscape of stablecoins and yield opportunities. At any given time, cUSD represents a composite of the most stable and accessible dollar-denominated stablecoins, while stcUSD dynamically allocates to the most effective yield strategies available. Cap is designed by two guiding principles: * Open protocols: Open-source, autonomous systems foster innovation, transparency, and resilience. Financial guarantees must be credible, based on verifiable code. * Market driven: Well-designed rewards and penalties minimize reliance on human judgement. By combining the verifiability of smart contracts and the economic strength of markets, Cap aims to serve as the financial backbone of the digital economy. Let us break down the thesis for each of the products. ### [](https://docs.cap.app/why-cap#why-cusd) Why cUSD? There is no question that stablecoins are a better payment system compared to legacy financial systems. They are faster, safer, more transparent and more accessible, removing inefficiencies plaguing the traditional payment networks (read settlement latency, opaque intermediaries, costly conversions). This technological leap, alongside regulatory receptiveness, has spurred governments and financial institutions to issue their own stablecoins. However, the rapid adoption of institution-led stablecoins leads to a fragmentation problem. As more stablecoins are introduced, the ecosystem fractures into incompatible siloes, negating the whole value proposition of stablecoins: frictionless global value transfer. Money derives its value from network effects: the more users accept it, the more useful it becomes. The dollar is a strong form of money, since dollars held at Bank A are functionally equivalent to those at Bank B thanks to centralized clearinghouses and regulatory harmonization. Stablecoins today lack such unifying infrastructure. For stablecoins to truly have “moneyness”, the lack of interoperability is a problem that must be addressed. Solving fragmentation necessitates credibly neutral protocols that aggregate individual stablecoins. cUSD offers singleness of money, by aggregating compliant stablecoins into a unified reserve, creating an interconnected web of assets. It serves as a neutral bridge between the reserve assets, where users can redeem cUSD for any underlying asset. All logic is on-chain, enabling fast, secure, and 24/7 swaps without preferential treatment of any reserve asset. As more institutions join Cap, the protocol can serve as a settlement layer, offering an open standard for interoperability. ### [](https://docs.cap.app/why-cap#why-stcusd) Why stcUSD? Many of today’s yield-bearing stablecoins are no different from tokenized hedge funds, relying on centralized teams to manage strategies. This model faces two major issues: 1. Scalability: A single team is limited by its resources and capacity, regardless of their capabilities. There are only so many strategies a dApp team can run, and no strategy can infinitely scale. They quickly become obsolete as market conditions change, and users are left chasing the next dApp. 2. Safety: Centralized management exposes users to uncovered risks that are opaque and subject to change at the discretion of the team. Users occupy the most junior position within protocol hierarchies, often lacking verifiable protection and remaining exposed to risk during adverse events. stcUSD addresses these challenges by decentralizing the capital allocation process and providing verifiable recourse. An open network of operators competes to deliver the best yield, with their strategies underwritten by restakers’ delegated capital. This model enables: 1. Verifiable Downside Protection: End users are covered from the risk of yield generation via Shared Security Networks. Operators must secure credit delegations via restaking to participate. All risk coverage is transparent and enforced by smart contracts, allowing users to verify protections on-chain. 2. Perpetual competitive yield: An autonomous layer of operators ensures continuous access to the most effective yield strategies. Smart contracts and game theory dynamically dictate capital allocation, ensuring stcUSD to deliver competitive yield invariant to market condition or scale. 3. Democratization of Yield: By opening participation to a global network of operators, stcUSD provides access to yield opportunities that were previously constrained by geographic or institutional barriers. [PreviousIntroduction](https://docs.cap.app/) [NextProtocol Overview](https://docs.cap.app/protocol-overview) Last updated 5 months ago * [Why cUSD?](https://docs.cap.app/why-cap#why-cusd) * [Why stcUSD?](https://docs.cap.app/why-cap#why-stcusd) --- # Protocol Actors | cap ### [](https://docs.cap.app/protocol-overview/protocol-actors#protocol-actors) **Protocol Actors** * **cUSD holders** receive cUSD in exchange for depositing whitelisted assets to the collateral pool. The underlying assets are always redeemable. * **stcUSD holders** receive stcUSD by staking cUSD. stcUSD earns auto-compounding yield generated by Cap's network of operators. Yield can be redeemed at any time. * **Operators** generate yield by borrowing reserve capital to execute proprietary strategies . To be eligible to borrow, they are required to secure delegations from restakers. * **Restakers** delegate locked assets to operators via shared security markets. Each restaker selects an operator they wish to underwrite the risk of. Restaker delegations are used to protect cUSD holders against default risk. * **Liquidators** slash undercollateralized positions via permissionless Dutch auctions once the operator's loan-to-value falls under the safety threshold. ### [](https://docs.cap.app/protocol-overview/protocol-actors#aligning-incentives) **Aligning incentives** * **cUSD holders** can spend cUSD on any network with transparency guarantees. The reserve is always transparent via fully on-chain contracts. They can also use cUSD to off-ramp to any of reserve assets. * **stcUSD holders** earn yield regardless of market condition and size. More importantly, their principal is protected by verifiable recourse. * **Operators** can source additional capital with no cost basis, retaining any surplus yield after restaker and hurdle rate fees. Furthermore, borrow terms are flexible as operators are able to negotiate with their restaker underwriting them. * **Restakers** earn fees in exchange for their delegations. They have full autonomy to charge risk premium per operator, paid out in blue chip assets such as ETH and USD. * **Liquidators** earn liquidation bonuses. Dutch auctions facilitate faster liquidations as liquidators earn higher bonuses if they are able to liquidate faster. [PreviousProtocol Overview](https://docs.cap.app/protocol-overview) [NextcUSD Mechanics](https://docs.cap.app/protocol-overview/cusd-mechanics) Last updated 6 months ago * [Protocol Actors](https://docs.cap.app/protocol-overview/protocol-actors#protocol-actors) * [Aligning incentives](https://docs.cap.app/protocol-overview/protocol-actors#aligning-incentives) --- # Protocol Overview | cap ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FAv3sOZJRigtLFQtKdrlp%252Fimage.png%3Falt%3Dmedia%26token%3D637968a5-da3c-4ba6-94d3-e243e55b73f3&width=768&dpr=4&quality=100&sign=f0052bcb&sv=2) High-level Overview of Cap's Design Cap is a three-sided marketplace designed to run autonomously via economic incentives. Cap outsources the generation of yield via a diverse layer of institutional operators ranging from banks, HFT firms, and market makers. The trust marketplace of Shared Security Networks enables Cap to generate perpetual competitive yield under any market conditions. [PreviousWhy Cap?](https://docs.cap.app/why-cap) [NextProtocol Actors](https://docs.cap.app/protocol-overview/protocol-actors) Last updated 6 months ago --- # FAQs | cap [](https://docs.cap.app/faqs#operator-control-and-restrictions) Operator Control and Restrictions ------------------------------------------------------------------------------------------------------ **Q: Do operators have full control over collateral once disbursed?** No. The operator set will be comprised of regulated financial institutions that enter into legal agreements with restakers to restrict permissible strategies. **Q. How does the protocol ensure there are no risky strategies?** Restakers bear direct risk for their delegation choices. By underwriting specific operators, restakers incentivize due diligence on strategy viability. **Q: Are there caps on collateral lent to operators?** Yes. Delegation limits and nominal exposure thresholds prevent concentration risk. [](https://docs.cap.app/faqs#loan-security) Loan Security -------------------------------------------------------------- **Q: Does the protocol impose minimum overcollateralization requirements on restakers?** Yes, the protocol checks the collateralization ratio before the operator can borrow. The overcollateralization ratio is different for every collateral asset and is set conservatively to prevent any unexpected liquidations. **Q: Which assets are accepted as restaker collateral?** Only blue-chip cryptocurrencies: ETH, wBTC, Liquid Staking Tokens (LSTs), and stablecoins. **Q: What happens if restakers withdraw their delegation mid-loan?** Restakers and operators should have a prior agreement when restakers intend to remove delegation for position unwinding. Unilateral withdrawals will trigger slashing. Note that there is a built-in buffer period in Shared Security Networks to mitigate an accidental withdrawal. [](https://docs.cap.app/faqs#shared-security-network) Shared Security Network ---------------------------------------------------------------------------------- **Q. How is Slashing and Redistribution used in Cap?** Malicious or undercollateralized operators are autonomously slashed, where restaker delegations are redistributed back to the stablecoin holders. **Q. How does Cap differ from other restaking protocols?** Cap replaces passive Proof-of-Stake rewards with productivity-based incentives: * Restakers earn premiums tied to operator performance. * Operators retain surplus yield, fostering competitive strategy innovation. Cap takes an innovative approach of rewarding restakers on an operator basis, where counterparty risk is established one-to-one with the operator they are underwriting. This architecture allows operators to take more agency and be rewarded for their productivity. For details, please check out our [Productivity Based Incentives](https://mirror.xyz/0x83c21bb4Bf0EC116f5a1945AaeF847Fe3b321B32/Xg7gCAqgmcxgXhuwaWXVJDSCEIMn3_dewNWAie2Tn_k) article. [PreviousRisks](https://docs.cap.app/risks) [NextOperator Onboarding](https://docs.cap.app/guides/operator-onboarding) Last updated 6 months ago * [Operator Control and Restrictions](https://docs.cap.app/faqs#operator-control-and-restrictions) * [Loan Security](https://docs.cap.app/faqs#loan-security) * [Shared Security Network](https://docs.cap.app/faqs#shared-security-network) --- # cUSD Mechanics | cap cUSD is a US dollar-backed stablecoin redeemable against reserve assets. Users can interact with cUSD via three operations: • **Mint**: Deposit reserve assets to mint cUSD at oracle value • **Burn**: Redeem cUSD for reserve assets at the asset price of the highest deviation • **Redeem**: Multi-collateral redemption to ensure peg stability [](https://docs.cap.app/protocol-overview/cusd-mechanics#key-highlights) Key highlights -------------------------------------------------------------------------------------------- ### [](https://docs.cap.app/protocol-overview/cusd-mechanics#peg-stability-module-psm) Peg Stability Module (PSM) The cUSD contract acts as a Peg Stability Module (PSM), providing mechanisms for users to mint, burn, and redeem cUSD directly against a diversified basket of whitelisted backing assets (e.g., USDC, pyUSD, BENJI, BUIDL). The PSM’s primary objective is to ensure that cUSD’s market price remains close to $1, while managing the risk and distribution of its underlying collateral. Effectively, this design ensures that cUSD is always liquid and can be swapped for any of the underlying assets at transparent, market-based rates. ### [](https://docs.cap.app/protocol-overview/cusd-mechanics#redeem-addressing-depegs) **Redeem:** Addressing Depegs When a user redeems cUSD, the system calculates the output as a proportional basket of the underlying assets, based on their current weights and market prices. This prevents “last man standing” problem, where late redeemers could be left with only depegged assets. The loss from a depeg of any of the underlying assets is socialized: the system disincentives users to burn once the distribution of assets deviates from the optimal level. ### [](https://docs.cap.app/protocol-overview/cusd-mechanics#fractional-reserves) **Fractional Reserves** When deposited assets are not being actively borrowed, the idle capital earns rewards via revenue sharing of the underlying asset (MMFs) or through integration with crypto lending markets such as Aave. Each asset in the Fractional Reserve Vault accrues interest until they are divested when needed for withdrawing, redeeming, or borrowing. [PreviousProtocol Actors](https://docs.cap.app/protocol-overview/protocol-actors) [NextstcUSD Mechanics](https://docs.cap.app/protocol-overview/stcusd-mechanics) Last updated 3 months ago * [Key highlights](https://docs.cap.app/protocol-overview/cusd-mechanics#key-highlights) * [Peg Stability Module (PSM)](https://docs.cap.app/protocol-overview/cusd-mechanics#peg-stability-module-psm) * [Redeem: Addressing Depegs](https://docs.cap.app/protocol-overview/cusd-mechanics#redeem-addressing-depegs) * [Fractional Reserves](https://docs.cap.app/protocol-overview/cusd-mechanics#fractional-reserves) --- # Risks | cap Below are the main risks associated with Cap's current design. **Smart Contract Risk:** * Cap operates without reliance on third-party custodians, regulatory frameworks, or manual oversight. cUSD holder protections are enforced exclusively by code-based adherence to Cap’s protocol rules. While Cap’s smart contracts have been rigorously audits, users should be aware of risks associated with potential code vulnerabilities. **Counterparty Risk:** * **Shared Security Models**: Cap is built on Shared Security Marketplaces like EigenLayer. As such, it is exposed to their platform risk. * **Reserve collateral**: If the reserve assets may depeg, users are exposed to these changes of price. Underlying reserve assets may also be frozen, seized or forfeited for illegal or sanctioned use. * **Delegation collateral**: If the delegation assets are volatile (i.e. levered via looping), this increases the chance of liquidations as collateral value may fluctuate. Cap restricts the type of collateral to mitigate this risk. * **Bridge and Oracle Risk**: If users wish to interact with cUSD from any chain, they will be exposed to the risk of third-party bridges that transfer cUSD from Ethereum and oracles that price cUSD. * **Idle Asset Risk**: Idle assets may be deposited into integrated protocols such as Aave and Morpho until they are borrowed. As such, Cap is exposed to these protocol risks. **cUSD Depeg Risk:** * A force majeure event may create a mismatch between cUSD and the reserve assets. However, the highly liquid and regulated nature of the reserve assets render this unlikely. **Protocol Risk:** * **Redemption Risk:** Redemptions are guaranteed at all times for cUSD holders. However, redemptions may be delayed if the reserve assets are fully utilized. Dynamic interest rates prevent full utilization, always ensuring liquidity to be withdrawn atomically. * **Slashing Risk:** Malicious or undercollateralized operators put restakers in slashing risk. However, restakers can preemptively mitigate these risks, due to the fact that operators in Cap are whitelisted regulated financial institutions. * **Guarantor Agreements**: restakers are able to sign off-chain Guarantor Agreements (GAs) with their counterparties. These agreements can specify recourse provision, loan terms, and strategy constraints. Hence, the chance of an actual slashing event is equivalent to these regulated entities filing for bankruptcy. * **Quantifying risk**: It is possible to model the risk premium via credit spread. Particularly, the [return per unit of risk](https://docs.google.com/spreadsheets/d/1D04AYjvRBMCg09kSLpL8yN94tSrCpVhD8lBBT9037R4/edit?gid=0#gid=0) can be measured based on the institution's credit ratings, credit spread and default rates. [PreviousShared Security Networks](https://docs.cap.app/protocol-overview/shared-security-networks) [NextFAQs](https://docs.cap.app/faqs) Last updated 6 months ago --- # Shared Security Networks | cap Cap is a decentralized stablecoin protocol that leverages Shared Security Networks (SSNs) such as Symbiotic and EigenLayer to separate yield generation from risk. Instead of relying on centralized decision making to allocate capital, Cap empowers independent operators to borrow funds and deploy them into yield-generating strategies. The operators are not trusted by default; rather, they must secure economic guarantees from delegators from SSNs who lock up capital as performance bonds. Hence, SSNs regulate the permissionless collective of operators that generate yield for users. The result is a trustless, modular stablecoin architecture where risk is underwritten by the market, rather than being absorbed by users. Let's dive deeper into how Cap utilizes SSNs. [](https://docs.cap.app/protocol-overview/shared-security-networks#id-1.-productivity-based-incentives) 1\. Productivity-based Incentives ---------------------------------------------------------------------------------------------------------------------------------------------- Cap builds on the idea of Shared Security Networks as a trust marketplace, extending the common usage as Proof of Stake (PoS) networks to a productivity based platform. ### [](https://docs.cap.app/protocol-overview/shared-security-networks#higher-operator-agency) Higher Operator Agency Traditionally, SSNs have focused on validation services. In these models, operators perform uniform validation tasks such as verifying signatures, and rewards are distributed passively and evenly amongst participants. Newer models, such as network wide insurance-based services, have been introduced, where delegators underwrite a generic event rather than individual operator risk. While serving a different usecase, these models also provide passive rewards. Cap’s approach to SSNs provides a more granular and productivity-based incentive structure. Cap enables operators to take on more agency, such that they can be rewarded in proportion to their individual value creation. Operators participate in Cap based on their borrowing competitiveness, taking the delta between their returns and the hurdle rate. Accordingly, delegators opt in to a subset of the operators by evaluating their strategies, rates and legal agreements. ### [](https://docs.cap.app/protocol-overview/shared-security-networks#customizable-rewards) Customizable Rewards Cap innovates reward mechanisms for delegators on SSNs. Delegators are able to charge premiums based on the productivity and risk of the specific operators they underwrite. The premium is paid out in blue chip assets like ETH and USD, rather than inflationary governance tokens or offchain points programs. This stands in stark contrast to the passive, network-wide reward structures of PoS services on SSNs. ### [](https://docs.cap.app/protocol-overview/shared-security-networks#defined-counterparty-risk) Defined Counterparty Risk Cap's delegation model isolates risk, ensuring that slashing events—penalties for malicious or failed activity—are tied directly to the operator in question, rather than affecting the entire network. As a result, contagion risk is minimized, and delegators gain greater control and visibility over their exposure. More specifically, because all operators in Cap are regulated financial entities, delegators can enter into legal agreements with their counterparties. Hence, the chance of an actual slashing event is equivalent to these regulated entities filing for bankruptcy. [](https://docs.cap.app/protocol-overview/shared-security-networks#id-2.-credible-financial-guarantees) 2\. Credible Financial Guarantees ---------------------------------------------------------------------------------------------------------------------------------------------- The key innovation in Cap is that stablecoin holders are fully protected from yield-related losses via credible financial guarantees. If a slashing condition is triggered on a particular operator, the delegators backing that operator are slashed. Rather than burning them, the slashed funds are redistributed via the SSNs to cover the shortfall, ensuring cUSD remains fully collateralized at all times. Redistribution enables verifiable downside protection for end users via transparent code. ### [](https://docs.cap.app/protocol-overview/shared-security-networks#slashing-conditions) Slashing conditions The slashing conditions are automated, objective and verifiable onchain. Rather than relying on human judgement to penalize malicious behavior, Cap powers a robust, decentralized trust marketplace, where the recourse provision is fully transparent. Slashing conditions are akin to liquidations in lending markets and thus depend on the ratio of two variables: the amount of collateral (delegations) and debt. Slashing is deterministically triggered when the health factor of the borrower (operator) drops below the liquidation threshold. Slashing is executed instantly and permissionlessly. There are no delay periods nor veto committees for liquidations to occur, or for the slashed funds to be redistributed. As a buffer, grace periods are introduced, where borrowers are given a fixed time period to regain their position’s health. [](https://docs.cap.app/protocol-overview/shared-security-networks#id-3.-unlocking-capital-efficiencies) 3\. Unlocking Capital Efficiencies ------------------------------------------------------------------------------------------------------------------------------------------------ Crypto lending markets require borrowers to overcollateralize their own position (post 1 USDC worth of ETH as collateral to borrow 0.7 USDC). While this design ensures the most verifiable form of credit, it is capital inefficient, especially when the borrowers themselves are the ones posting the collateral. Cap improves on credit in DeFi via SSNs. Cap is able to achieve _insured_ private credit via credit delegations backed by restaked crypto assets and off-chain legal agreements. This model is possible because of the inherently different cost of capital between crypto-denominated delegation assets and the dollar-denominated reserve assets. There is a lack of use case for locked crypto assets- staked ETH on the Beacon chain can only be used as limited form of _trust._ As such, the cost of capital for using ETH as delegation is much cheaper than it would be on the dollar. The delegation model is not limited to ETH; rather, the market size of delegations easily extends to all crypto asset types such as BTC. [PreviousstcUSD Mechanics](https://docs.cap.app/protocol-overview/stcusd-mechanics) [NextRisks](https://docs.cap.app/risks) Last updated 3 months ago * [1\. Productivity-based Incentives](https://docs.cap.app/protocol-overview/shared-security-networks#id-1.-productivity-based-incentives) * [Higher Operator Agency](https://docs.cap.app/protocol-overview/shared-security-networks#higher-operator-agency) * [Customizable Rewards](https://docs.cap.app/protocol-overview/shared-security-networks#customizable-rewards) * [Defined Counterparty Risk](https://docs.cap.app/protocol-overview/shared-security-networks#defined-counterparty-risk) * [2\. Credible Financial Guarantees](https://docs.cap.app/protocol-overview/shared-security-networks#id-2.-credible-financial-guarantees) * [Slashing conditions](https://docs.cap.app/protocol-overview/shared-security-networks#slashing-conditions) * [3\. Unlocking Capital Efficiencies](https://docs.cap.app/protocol-overview/shared-security-networks#id-3.-unlocking-capital-efficiencies) --- # stcUSD Mechanics | cap stcUSD is the yield-bearing stablecoin of Cap that enables users to earn rewards via a decentralized lending framework. A network of operators can borrow from Cap's reserves based on their ability to generate yield over the hurdle rate of the asset.Borrowing in Cap is always over-collateralized: whitelisted Operator can permissionlessly access liquidity, provided that they receive sufficient collateral from Delegators. Under-collateralized loans trigger liquidation events, slashing Delegators from their Shared Security Networks. The slashed funds are redistributed back to the stablecoin holder, such that cUSD is backed 1:1 at all times. Let us exemplify the mechanics of stcUSD. [](https://docs.cap.app/protocol-overview/stcusd-mechanics#how-does-stcusd-work) How does stcUSD work? ----------------------------------------------------------------------------------------------------------- ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FxuqFuyiYKCzalswf8RTm%252Fimage.png%3Falt%3Dmedia%26token%3D1f5a8afe-1766-490a-ad60-3998d22c63b8&width=768&dpr=4&quality=100&sign=391b317f&sv=2) Happy Path: Yield is distributed to all stakeholders 1. **Minting and Staking**: Alice deposits ~$100 worth of $stable (a dollar-pegged asset) to the reserve to mint ~100 cUSD. She then stakes her cUSD in exchange for ~100 stcUSD. 2. **Idle Asset Rewards**: The idle $stable in the reserve automatically accrues rewards. Rewards can come directly from the underlying of $stable, or via integrated protocols (e.g. Aave, Morpho), determined programmatically depending on the rates. 3. **Restaker Delegations:** 1. An operator identifies a yield opportunity exceeding Cap’s 8% hurdle rate\* for $stable. In order to borrow, the operator must first secure overcollateralized delegations from a willing restaker. 2. A restaker runs due diligence on the operator and decides to delegate $stake. Restakers and operators can optionally enter into a bilateral agreement to negotiate terms such as loan tenor and fixed restaker rates (risk premium). 4. **Operator Borrowing**: The operator permissionlessly borrows $stable via Cap's smart contracts. \*Note, 8% is an arbitrary number set as an example. The actual hurdle rate is a dynamic rate: for more information, refer to [Borrow Rates](https://docs.cap.app/protocol-overview/stcusd-mechanics#borrow-rates) There are two possible paths the flow can go from here. ### [](https://docs.cap.app/protocol-overview/stcusd-mechanics#happy-path-competitive-yield) Happy Path: Competitive Yield Let us first examine the happy path, where the operator successfully repays the loan and the value of $stake remains stable. 1. **Generate Yield**: The operator executes the strategy and generates yield. The operator successfully repays the loan and the associated interest in $stable. 2. **Yield Distribution**: Yield is distributed across all stakeholders. If the operator generates 15% yield on the principal, then 8% (hurdle rate) flows back to the stcUSD holders. The fixed restaker rate (assume 2%) is rewarded to the restakers, leaving the excess 5% as operator profit. ### [](https://docs.cap.app/protocol-overview/stcusd-mechanics#unhappy-path-slashing-and-redistribution) Unhappy Path: Slashing and Redistribution In Cap, the slashing logic is triggered under two objective conditions: * Stake collateral value falls below safe thresholds * The operator defaults on repayment of the loan ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FlD7YhgEqv9yghX2y1RMe%252Fimage.png%3Falt%3Dmedia%26token%3Dbc7e09ff-334b-4312-9c48-1ddcbc62e08f&width=768&dpr=4&quality=100&sign=cb16dd26&sv=2) Unhappy Path: Stablecoin Holders are protected against yield-generation risk When such an event happens, the path forks from step 5. 1. **Slashable Event**: A slashing event is triggered during an open loan. A dutch auction kicks off to clear the $stable debt of the operator. 2. **Liquidations**: Liquidators slash the restakers' $stake up to the point where the operator's position is restored to a healthy state. The slashed $stake is sold to the liquidators at a discounted price in exchange for $stable. 3. **Redistribution**: Th collected $stable is redistributed back to Cap’s reserve, ensuring stcUSD holders like Alice remain whole at all times. [](https://docs.cap.app/protocol-overview/stcusd-mechanics#borrow-rates) Borrow Rates ------------------------------------------------------------------------------------------ The borrow rate that the operator has to repay is a function of restaker rate and hurdle rate. The **restaker rate** is the fixed annual premium negotiated with restakers. The **hurdle rate** is a dynamic rate that is a function of market rate and utilization rate. The market rate is the minimum rate for the borrow rate, and acts as a benchmark yield from external protocols such as Aave. The utilization rate adjusts via a piecewise linear function, where the rate escalates sharply when reserve utilization exceeds target thresholds. Both market and utilization rate are applied per collateral asset. This mechanism ensures that there is always liquidity available for withdrawals, while setting a competitive floor for the hurdle rate. [PreviouscUSD Mechanics](https://docs.cap.app/protocol-overview/cusd-mechanics) [NextShared Security Networks](https://docs.cap.app/protocol-overview/shared-security-networks) Last updated 3 months ago * [How does stcUSD work?](https://docs.cap.app/protocol-overview/stcusd-mechanics#how-does-stcusd-work) * [Happy Path: Competitive Yield](https://docs.cap.app/protocol-overview/stcusd-mechanics#happy-path-competitive-yield) * [Unhappy Path: Slashing and Redistribution](https://docs.cap.app/protocol-overview/stcusd-mechanics#unhappy-path-slashing-and-redistribution) * [Borrow Rates](https://docs.cap.app/protocol-overview/stcusd-mechanics#borrow-rates) --- # Symbiotic | cap Registering to Cap's Symbiotic Network as an operator is very straightforward: simply provide the operator's Ethereum address, referred to _agent_ in Cap's system, to 1. Cap's onboarding team: registers the Symbiotic Vault to Cap's system with loan parameters such as Loan-to-Value, Liquidation Threshold and restaker fees. 2. Delegator you wish to be receiving stake from: the delegator will then create the agent-specific Symbiotic Vault To isolate slashing risk, each operator can only receive effective stake from one Symbiotic Vault. Delegations from other Vaults will not count as collateral. The operator must create a new address for each new Vault. Deployed addresses cannot be changed. Under the hood, the onboarding process happens as the following: 1. The delegator first creates a vault via the [CapSymbioticVaultFactory](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/providers/symbiotic/CapSymbioticVaultFactory.sol#L57) including the agent address. The call will register the operator in Symbiotic's [Operator Registry](https://docs.symbiotic.fi/modules/registries/#2-operatorregistry) and complete the [Operator to Network Opt-in](https://docs.symbiotic.fi/modules/registries/#2-operator-to-network-opt-in) and [Operator to Vault Opt-in](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/delegation/providers/symbiotic/SymbioticNetwork.sol#L77) process via the [SymbioticOperator](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/providers/symbiotic/SymbioticOperator.sol#L4) contract. 2. Once the Vault is deployed, Cap will register the agent via to Cap's system via the [addAgent](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/interfaces/ISymbioticAgentManager.sol#L45) function. The function takes in the following struct: Copy struct AgentConfig { address agent; address vault; address rewarder; uint256 ltv; uint256 liquidationThreshold; uint256 delegationRate; } This function will add the agent to the [Delegation](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/Delegation.sol) contract, register the Vault and Agent to Cap's [Symbiotic Network Middleware](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/providers/symbiotic/SymbioticNetworkMiddleware.sol) and set restaker rates Delegations will take up to 6 days to be effective stake. Operators can start borrowing via the Asset page on Cap's app. [PreviousOperator Onboarding](https://docs.cap.app/guides/operator-onboarding) [NextEigenLayer](https://docs.cap.app/guides/operator-onboarding/eigenlayer) Last updated 3 months ago --- # EigenLayer | cap Coming Soon [PreviousSymbiotic](https://docs.cap.app/guides/delegator-onboarding/symbiotic) [NextOverview](https://docs.cap.app/concepts/overview) Last updated 1 month ago --- # Operator Onboarding | cap The following outlines the process for onboarding as an operator to borrow from Cap. ### [](https://docs.cap.app/guides/operator-onboarding#id-1.-setup) 1\. Setup Ensure you have: * **Delegator Profile**: the list of active delegators can be found [here](https://cap.app/delegators) . * **Restaker Rate**: Operators and restakers should agree on a fixed restaker rate to pay the Delegator * **Wallet**: an Ethereum Externally Owned Account (EOA) or multisig wallet to serve as your operator identity Operators must generate a new wallet for each new delegator to receive stake from. Addresses cannot be changed after deployment. For best practices, we recommend using a multisig for the address. ### [](https://docs.cap.app/guides/operator-onboarding#id-2.-register-to-a-ssn-of-choice) 2\. Register to a SSN of choice Currently, Cap supports the following Shared Security Networks. 1. [Symbiotic](https://docs.cap.app/guides/operator-onboarding/symbiotic) 2. EigenLayer ### [](https://docs.cap.app/guides/operator-onboarding#id-3.-complete-legal-agreements-optional) 3\. Complete Legal Agreements (Optional) Operators and delegators may enter into legal agreements outlining terms of delegation, responsibilities, and compliance. ### [](https://docs.cap.app/guides/operator-onboarding#id-4.-participate-in-loan-activity) 4\. Participate in Loan Activity At this step, operators may engage in borrowing activities. They can verify delegations and borrowing power from Cap's Operator Page. Review the risk parameters prior to loan: * **LTV (Loan-to-Value)**: Maximum borrowing capacity (e.g., 50% = 0.5e27) * **Liquidation Threshold**: Health factor at which liquidation can occur (e.g., 80% = 0.7e27) * **LTV Buffer**: Minimum gap between LTV and liquidation threshold (10% = 0.05e27) ### [](https://docs.cap.app/guides/operator-onboarding#id-5.-updating-parameters) 5\. Updating Parameters Should delegators and operators wish to change loan parameters, please contact the Cap team to do so. Namely, delegation admin can update the restaker rate via the [setRestakerRate](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/Delegation.sol) function, and the LTV and LT via the [modifyAgent](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/Delegation.sol#L97) function. [PreviousFAQs](https://docs.cap.app/faqs) [NextSymbiotic](https://docs.cap.app/guides/operator-onboarding/symbiotic) Last updated 1 month ago * [1\. Setup](https://docs.cap.app/guides/operator-onboarding#id-1.-setup) * [2\. Register to a SSN of choice](https://docs.cap.app/guides/operator-onboarding#id-2.-register-to-a-ssn-of-choice) * [3\. Complete Legal Agreements (Optional)](https://docs.cap.app/guides/operator-onboarding#id-3.-complete-legal-agreements-optional) * [4\. Participate in Loan Activity](https://docs.cap.app/guides/operator-onboarding#id-4.-participate-in-loan-activity) * [5\. Updating Parameters](https://docs.cap.app/guides/operator-onboarding#id-5.-updating-parameters) --- # EigenLayer | cap Coming Soon [PreviousSymbiotic](https://docs.cap.app/guides/operator-onboarding/symbiotic) [NextDelegator Onboarding](https://docs.cap.app/guides/delegator-onboarding) Last updated 1 month ago --- # Delegator Onboarding | cap The following outlines the process for onboarding delegators to Shared Security Networks (SSNs) in Cap's protocol. Onboarded delegators may delegate to operators approved in the Cap system. ### [](https://docs.cap.app/guides/delegator-onboarding#id-1.-setup) 1\. Setup Ensure you have: * **Operator Address:** Operator's Ethereum address that will receive delegations. The operator must be already registered in Cap's system. * **Restaker Rate**: Agree on a fixed rate to receive from the Operator * **Collateral Asset:** The asset to be used as vault collateral (ETH/BTC-denominated ERC20s) ### [](https://docs.cap.app/guides/delegator-onboarding#id-2.-choose-ssn) 2\. Choose SSN Select SSN of choice for delegations, and follow the corresponding onboarding guide to complete set up and start delegating. 1. [Symbiotic](https://docs.cap.app/guides/delegator-onboarding/symbiotic) 2. EigenLayer Collateral management, i.e. delegations and withdrawals, are handled within each SSN. Delegators are advised to monitor delay periods specific to the SSN. Withdrawing delegations immediately lowers coverage. Delegated assets in the withdrawal queue are slashable until the end of the withdrawal delay. Hence, a withdrawal below the liquidation threshold makes the delegation asset slashable. While a time buffer is in place to mitigate risk, it is recommended that Delegators whitelist depositors prevent malicious/accidental withdrawals that may trigger unintended slashing. ### [](https://docs.cap.app/guides/delegator-onboarding#id-3.-complete-legal-agreements-optional) 3\. Complete Legal Agreements (Optional) Operators and Delegators may enter into legal agreements outlining terms of delegation, responsibilities, and compliance. [PreviousEigenLayer](https://docs.cap.app/guides/operator-onboarding/eigenlayer) [NextSymbiotic](https://docs.cap.app/guides/delegator-onboarding/symbiotic) Last updated 1 month ago * [1\. Setup](https://docs.cap.app/guides/delegator-onboarding#id-1.-setup) * [2\. Choose SSN](https://docs.cap.app/guides/delegator-onboarding#id-2.-choose-ssn) * [3\. Complete Legal Agreements (Optional)](https://docs.cap.app/guides/delegator-onboarding#id-3.-complete-legal-agreements-optional) --- # Symbiotic | cap [](https://docs.cap.app/guides/delegator-onboarding/symbiotic#overview) Overview ------------------------------------------------------------------------------------- Vault curators on Symbiotic can easily deploy Cap-specific Symbiotic Vaults using the [CapSymbioticVaultFactory](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/delegation/providers/symbiotic/CapSymbioticVaultFactory.sol) directly on the app's [Create Vault page](https://cap.app/delegators/create-vault) . Cap must first approve the Vault before delegated stake can be used as collateral. ### [](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-1.-deploy-symbiotic-vault) 1\. Deploy Symbiotic Vault Curators can deploy Cap-specific Symbiotic Vaults either via 1. Cap's [UI](https://cap.app/delegators/create-vault) for creating Vault 2. Vault Factory contract's [createVault](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/providers/symbiotic/CapSymbioticVaultFactory.sol#L57) function on Etherscan. As most of the parameters and modules are preconfigured, curators only have to specify the operator address and Collateral asset address when creating the Vault. The factory contract will create Symbiotic's Delegator, Burner, Slasher and Rewarder modules as needed in Cap's Symbiotic Vault requirements. Copy /// @param _owner The owner of the vault, will manage delegations and set deposit limits /// @param asset The asset of the vault /// @param _agent The agent of the vault /// @param _network The network of the vault /// @return vault The address of the new vault function createVault(address _owner, address asset, address _agent, address _network) external returns (address vault, address delegator, address burner, address slasher, address stakerRewards); To ensure that all parameters are set-up as intended in Cap's design, Cap only accepts Vaults deployed via the factory contract. Once the Vault is deployed, Cap will add the operator-delegator pair to the system with loan parameters via SymbioticAgentManager's [`addAgent`](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/providers/symbiotic/SymbioticAgentManager.sol#L42) function. The function handles necessary registry of the Vault. Once this part is complete, delegators can start using delegated stake as collateral. Vault creation will revert if the operator's address is already receiving delegations from another Vault. ### [](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-2.-admin-controls) 2\. Admin Controls Key administrative functions available to vault admins include configuring admin fees, setting deposit limits, and whitelisting depositors. Admin fees are taken from the rewards distributed to depositors, as a percentage of the total rewards. ### [](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-3.-collecting-rewards) 3\. Collecting Rewards Rewards are automatically distributed to the StakerRewarder when an operator repays a loan. Delegators can also manually claim rewards via the realizeRestakerInterest function on the [Lender](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/lendingPool/Lender.sol) contract. The contract will distribute accrued interest on the operator's borrowed amount to the StakerRewarder. Vault admins can claim the admin fee via the claimAdminFee function of the Symbiotic StakerRewards. ### [](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-4.-managing-withdrawals) 4\. Managing Withdrawals Withdrawals from Symbiotic Vaults take up to 2 epochs to process. Specifically, withdrawals start after the current epoch plus another epoch. Since an epoch is 7 days for Cap Symbiotic Vaults, it takes 8-14 days to complete the withdrawal. While the withdrawal is processed, the delegation assets are still slashable. If the withdrawal triggers an unhealthy position for the Operator, then the asset may be slashed (after the grace period). It is thus crucial that the withdrawal amount does not affect the Operator's position: it is best advised for Delegators to coordinate the withdrawal with the Operator. [PreviousDelegator Onboarding](https://docs.cap.app/guides/delegator-onboarding) [NextEigenLayer](https://docs.cap.app/guides/delegator-onboarding/eigenlayer) Last updated 1 month ago * [Overview](https://docs.cap.app/guides/delegator-onboarding/symbiotic#overview) * [1\. Deploy Symbiotic Vault](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-1.-deploy-symbiotic-vault) * [2\. Admin Controls](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-2.-admin-controls) * [3\. Collecting Rewards](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-3.-collecting-rewards) * [4\. Managing Withdrawals](https://docs.cap.app/guides/delegator-onboarding/symbiotic#id-4.-managing-withdrawals) Copy // Set an admin fee stakerRewards.setAdminFee(adminFee); // Enable/disable deposit limit vault.setIsDepositLimit(status); // Set deposit limit vault.setDepositLimit(amount); // Enable/disable deposit whitelist vault.setDepositWhitelist(status); // Add/remove whitelisted depositors vault.setDepositorWhitelistStatus(depositor, status); --- # Overview | cap Cap consists of the six main modules: 1. [**Vault**](https://docs.cap.app/concepts/vault) : Stores reserve assets and issues cUSD tokens, providing liquidity to Lender 2. [**Lender**](https://docs.cap.app/concepts/lender) : Handles borrowing, repayment, liquidation, and interest calculations 3. [**Fee Auction**](https://docs.cap.app/concepts/fee-auction) : Converts generated yield and fees to cUSD via a Dutch auction 4. [**Delegation**](https://docs.cap.app/concepts/delegation) :Connects to shared security networks for delegated collateral, rewards, and slashing 5. [**Oracles**](https://docs.cap.app/concepts/oracles) : Price oracles for asset valuation and rate oracles for interest calculations 6. [**Access Controls**](https://docs.cap.app/concepts/access-controls) : Function-level granular access controls across all protocol operations [PreviousEigenLayer](https://docs.cap.app/guides/delegator-onboarding/eigenlayer) [NextVault](https://docs.cap.app/concepts/vault) Last updated 2 months ago --- # Minter | cap The [Minter](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/vault/Minter.sol) contract handles fee calculation for the minting, burning and redeeming of cUSD, where dynamic fees are used to maintain the exposure of each backing asset to its optimal level. A balanced reserve composition reduces centralization of a particular asset, ensuring that the protocol is resilient to black swan events. Fees accrue to the treasury used for protocol safety. [](https://docs.cap.app/concepts/vault/minter#mechanics) Mechanics ----------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/vault/minter#dynamic-mint-burn-fees) Dynamic Mint/Burn Fees Fees are dynamically adjusted according to the exposure of assets in the system. For each asset, there are two predefined piecewise linear functions that determine the mint/burn fees. Fees increase as they deviate from the optimal ratio, increasingly sharply beyond the kink ratio. #### [](https://docs.cap.app/concepts/vault/minter#process-flow-for-mint-burn) **Process Flow for Mint/Burn**: 1. **Pre-fee Calculation**: Calls `_amountOutBeforeFee` to get base amount and new ratio 2. **Whitelist Check**: Bypasses fees if user is whitelisted 3. **Fee Application**: Applies dynamic fees using `_applyFeeSlopes` if not whitelisted #### [](https://docs.cap.app/concepts/vault/minter#fee-calculations) Fee Calculations ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FGDUDa7dGiyIzHHYqv6oG%252Fimage.png%3Falt%3Dmedia%26token%3D46f685e7-9d21-434c-b28c-97197a0f8ae2&width=768&dpr=4&quality=100&sign=59f48c46&sv=2) The fee system operates across three distinct zones based on where the current ratio is: 1. `current ratio <= optimal ratio`: Minimum mint fee to mint, 0 fees for burn 2. `optimal ratio < current ratio < kinkRatio`: Linear fee increase using the first slope 3. `current ratio > kinkRatio`: Steep fee increase using the second slope Price Oracles are used for fee calculations and amount determination. A minimum mint fee is placed to prevent manipulation around price oracles. The current minimum mint fee is set to 10bps, capped to 5% maximum. #### [](https://docs.cap.app/concepts/vault/minter#fee-parameters) Fee Parameters Parameter Description Validation `minMintFee` Base fee for minting ≤ 0.05e27 (5%) `optimalRatio` Target allocation ratio 0 < ratio < 1e27 `mintKinkRatio` Mint fee kink point 0 < ratio < 1e27 `burnKinkRatio` Burn fee kink point 0 < ratio < 1e27 `slope0` First slope coefficient `slope1` Second slope coefficient ### [](https://docs.cap.app/concepts/vault/minter#redeem-fees) Redeem Fees Redeem fees in Cap Protocol are simple percentage-based fees applied to proportional redemption operations. Same fees apply to all assets proportional to their asset allocation. Whitelisted users pay 0% redeem fee **Process Flow for Redeem**: 1. **Fee Determination**: Sets redeem fee (0 if whitelisted) 2. **Share Calculation**: Calculates user's share of total supply 3. **Amount Calculation**: Calculates proportional amount for each asset 4. **Fee Application**: Applies redeem fee to each asset amount ### [](https://docs.cap.app/concepts/vault/minter#whitelisting) Whitelisting Whitelisted users can bypass fees for larger scale operations. Whitelist management is restricted to authorized admins. [](https://docs.cap.app/concepts/vault/minter#architecture) Architecture ----------------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/vault/minter#minter) Minter #### [](https://docs.cap.app/concepts/vault/minter#core-functions) Core Functions `**getMintAmount**`: Calculates mint amount and fees for a given asset input * `_asset`: Asset address to mint with * `_amountIn`: Amount of asset to use for minting * **Returns**: Amount of cUSD to mint and fee to be paid `**getBurnAmount**`: Calculates burn amount and fees for a given cUSD input * `_asset`: Asset address to burn for * `_amountIn`: Amount of cUSD to burn * **Returns**: Amount of asset to receive and fee to be paid `**getRedeemAmount**`: Calculates redemption amounts for multi-asset withdrawal * `_amountIn`: Amount of cUSD to redeem * **Returns**: Amounts of each asset to receive and redeem fees **Admin Functions** `**setFeeData**`: Sets the fee parameters for an asset * `_asset`: Asset address to configure * `_feeData`: Complete fee configuration structure **Parameters**: * **minMintFee**: Minimum mint fee (maximum 5%) * **slope0**: Fee slope below kink ratio * **slope1**: Fee slope above kink ratio * **mintKinkRatio**: Mint fee kink ratio threshold * **burnKinkRatio**: Burn fee kink ratio threshold * **optimalRatio**: Optimal allocation ratio `**setRedeemFee**`: Sets the global redeem fee * `_redeemFee`: Redeem fee percentage in ray format (1e27 = 100%) `**setWhitelist**`: Sets whitelist status for a user * `_user`: User address to modify * `_whitelisted`: True to whitelist (exempt from fees), false to remove **View Functions** * `**whitelisted**`: Checks if a user is whitelisted ### [](https://docs.cap.app/concepts/vault/minter#minter-logic) **Minter Logic** The MinterLogic library provides four main functions that handle the complete lifecycle of minting, burning, and redeeming operations: 1. `**amountOut**` - Main entry point for mint/burn calculations with fee application 2. `**redeemAmountOut**` - Handles proportional redemption calculations 3. `**_amountOutBeforeFee**` - Internal function for calculating the base amount and new asset ratio before applying fees 4. `**_applyFeeSlopes**` - Internal function for dynamic fee application based on the current ratio ### [](https://docs.cap.app/concepts/vault/minter#data-structures) Data Structures #### [](https://docs.cap.app/concepts/vault/minter#minterstorage) MinterStorage #### [](https://docs.cap.app/concepts/vault/minter#feedata) FeeData #### [](https://docs.cap.app/concepts/vault/minter#feeslopeparams) FeeSlopeParams #### [](https://docs.cap.app/concepts/vault/minter#amountoutparams) AmountOutParams #### [](https://docs.cap.app/concepts/vault/minter#redeemamountoutparams) RedeemAmountOutParams [PreviousFractional Reserves](https://docs.cap.app/concepts/vault/fractional-reserves) [NextLender](https://docs.cap.app/concepts/lender) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/vault/minter#mechanics) * [Dynamic Mint/Burn Fees](https://docs.cap.app/concepts/vault/minter#dynamic-mint-burn-fees) * [Redeem Fees](https://docs.cap.app/concepts/vault/minter#redeem-fees) * [Whitelisting](https://docs.cap.app/concepts/vault/minter#whitelisting) * [Architecture](https://docs.cap.app/concepts/vault/minter#architecture) * [Minter](https://docs.cap.app/concepts/vault/minter#minter) * [Minter Logic](https://docs.cap.app/concepts/vault/minter#minter-logic) * [Data Structures](https://docs.cap.app/concepts/vault/minter#data-structures) Copy function getMintAmount(address _asset, uint256 _amountIn) external view returns (uint256 amountOut, uint256 fee) Copy function getBurnAmount(address _asset, uint256 _amountIn) external view returns (uint256 amountOut, uint256 fee) Copy function getRedeemAmount(uint256 _amountIn) external view returns (uint256[] memory amountsOut, uint256[] memory redeemFees) Copy function setFeeData(address _asset, FeeData calldata _feeData) external checkAccess(this.setFeeData.selector) Copy function setRedeemFee(uint256 _redeemFee) external checkAccess(this.setRedeemFee.selector) Copy function setWhitelist(address _user, bool _whitelisted) external checkAccess(this.setWhitelist.selector) Copy struct MinterStorage { address oracle; // Oracle address for pricing uint256 redeemFee; // Global redeem fee mapping(address => FeeData) fees; // Fee data per asset mapping(address => bool) whitelist; // Whitelist status per user } Copy struct FeeData { uint256 minMintFee; // Minimum mint fee (maximum 5%) uint256 slope0; // Fee slope below kink ratio uint256 slope1; // Fee slope above kink ratio uint256 mintKinkRatio; // Mint fee kink ratio threshold uint256 burnKinkRatio; // Burn fee kink ratio threshold uint256 optimalRatio; // Optimal allocation ratio } Copy struct FeeSlopeParams { bool mint; // True if applying to mint, false if burn uint256 amount; // Amount of asset to apply fee to uint256 ratio; // Ratio of fee to apply } Copy struct AmountOutParams { bool mint; // True if minting, false if burning address asset; // Asset address uint256 amount; // Amount of asset to mint or burn } Copy struct RedeemAmountOutParams { uint256 amount; // Amount of cap token to redeem } --- # Symbiotic | cap Cap integrates Symbiotic's restaking infrastructure to create a delegation-based lending system where delegators provide coverage for Operators (agents). Delegators can deploy Vaults to provide stake to Operators as coverage, where depositors can deposit and withdraw out of the vault. [](https://docs.cap.app/concepts/delegation/symbiotic#overview) Overview ----------------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/delegation/symbiotic#vault-to-operator-relationship) Vault to Operator relationship * **Unique Operator-Vault pair**: Each Symbiotic Vault can only delegate to one Operator. An operator must use a different Ethereum address in order to receive delegations from a new Vault. Likewise, a Delegator must deploy a new Vault in order to delegate to a new operator. * Once an Operator starts receiving delegations, the Operator address is immutable. ### [](https://docs.cap.app/concepts/delegation/symbiotic#lifecycle-of-symbiotic-vault) Lifecycle of Symbiotic Vault 1. Vault Creation: Delegator creates a Vault via the Cap Symbiotic Vault Factory Contract, which accepts one ERC20 collateral type 2. Cap Whitelisting: After the Vault is deployed, Cap adds the Vault and Operator address to Cap system along with loan parameters and restaker rates 3. Vault Management: Once the Operator-Vault pair is live, delegators have access control over depositors and claiming rewards. Liquidations will trigger slashing events on the Vault. Let's dive deeper into each of the steps. [](https://docs.cap.app/concepts/delegation/symbiotic#vault-creation) Vault Creation ----------------------------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/delegation/symbiotic#deploy-vault) Deploy Vault ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FD4WfVKt2Jz5OxsgKQeVs%252Fimage.png%3Falt%3Dmedia%26token%3Dd3ed6a06-7b5f-4ef5-a72f-33908a9c46fd&width=768&dpr=4&quality=100&sign=2a7401ff&sv=2) Cap Symbiotic Vault creation and deposit flow The `createVault` function is the core deployment function in the `CapSymbioticVaultFactory` contract. Vaults that are not registered using the Vault Factory will not be accepted in Cap's system. Specifically, the function executes the following: 1. deploys a Symbiotic operator for the specified agent to manage delegation 2. deploys Symbiotic Vault and modules according to Cap requirements Let us dive deeper into the specific requirements of Cap Symbiotic Vaults. #### [](https://docs.cap.app/concepts/delegation/symbiotic#id-1.-burner) 1\. Burner The burner specifies where assets are transferred to when slashing happens. A burner router is deployed to set the receiver of the slash. By setting the owner of the router to be the zero address, the global receiver is immutably set to be Cap's middleware. #### [](https://docs.cap.app/concepts/delegation/symbiotic#id-2.-delegator) 2\. Delegator The Delegator specifies whether restaking is allowed across networks and operators, and the allocation of assets. Cap requires that staked assets are solely used as coverage for the specific operator receiving delegations (i.e. stake cannot be shared with other networks/operators). As such, the [OperatorNetworkSpecificDelegator](https://docs.symbiotic.fi/modules/vault/delegation#3-operatornetworkspecificdelegator) is used to ensure delegations are siloed. Each vault can only delegate to one operator. #### [](https://docs.cap.app/concepts/delegation/symbiotic#id-3.-slasher) 3\. Slasher The Slasher handles slash requests from Cap’s middleware, by fetching stake from the Delegator and calling the Vault to transfer the assets to the Burner. The vault uses `INSTANT` slasher type for immediate slash execution, so that liquidation bonuses can be redistributed immediately. #### [](https://docs.cap.app/concepts/delegation/symbiotic#id-4.-vault) 4\. Vault The Vault handles deposit and withdrawals on an epoch basis. Assets leave Symbiotic vaults only when there is a withdrawal or slashing event. Deposits are instant. Withdrawals take until the end of the next epoch to withdraw. The epoch is fixed to 7 days, hence withdrawals take up to 14 days to execute. #### [](https://docs.cap.app/concepts/delegation/symbiotic#id-5.-staker-rewards) 5\. Staker Rewards The stakerRewards contract creates a rewards contract to distribute interest to delegators ### [](https://docs.cap.app/concepts/delegation/symbiotic#whitelisting) Whitelisting After the Vault is created, the Vault needs to be added to Cap's system. Cap whitelists the Agent-Vault pair via the addAgent function in the [SymbioticAgentManager](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/delegation/providers/symbiotic/SymbioticAgentManager.sol#L42) contract. The contract acts as a bridge between the Cap delegation system and the Symbiotic restaking infrastructure, ensuring proper registration and configuration of agents in the system. The function takes in the following parameters: First, the pair is added to the delegation contract, configuring loan parameters such as LTV and LT. By default, LTV is set to 50%, with the liquidation threshold at 80%. Notice, the delegation rate is also configured in this step. Next, the Vault, rewarder and agent are registered to Cap's Middleware, completing necessary Symbiotic Opt In processes. In particular, a subnetwork identifier is created for the operator. The identifier is used to enforce the one-to-one relationship between the agent and the vault. Delegations to other subnetwork identifiers will not count as effective stake. [](https://docs.cap.app/concepts/delegation/symbiotic#vault-management) Vault Management --------------------------------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/delegation/symbiotic#rewards) Rewards `**distributeRewards**`: Distributes rewards through Symbiotic network * `_agent`: Agent address for reward distribution * `_token`: Reward token address ### [](https://docs.cap.app/concepts/delegation/symbiotic#slashing) Slashing `**slash**`: Executes slashing through Symbiotic network via the Burner * `_agent`: Agent address to slash * `_recipient`: Address to receive slashed collateral * `_slashShare`: Share of collateral to slash * `_timestamp`: Timestamp for slashing ### [](https://docs.cap.app/concepts/delegation/symbiotic#admin-control) Admin Control * `DEFAULT_ADMIN_ROLE` - Full vault management * `DEPOSIT_WHITELIST_SET_ROLE` - Manage deposit whitelist * `DEPOSIT_LIMIT_SET_ROLE` - Set deposit limitst [PreviousDelegation](https://docs.cap.app/concepts/delegation) [NextOracles](https://docs.cap.app/concepts/oracles) Last updated 2 months ago * [Overview](https://docs.cap.app/concepts/delegation/symbiotic#overview) * [Vault to Operator relationship](https://docs.cap.app/concepts/delegation/symbiotic#vault-to-operator-relationship) * [Lifecycle of Symbiotic Vault](https://docs.cap.app/concepts/delegation/symbiotic#lifecycle-of-symbiotic-vault) * [Vault Creation](https://docs.cap.app/concepts/delegation/symbiotic#vault-creation) * [Deploy Vault](https://docs.cap.app/concepts/delegation/symbiotic#deploy-vault) * [Whitelisting](https://docs.cap.app/concepts/delegation/symbiotic#whitelisting) * [Vault Management](https://docs.cap.app/concepts/delegation/symbiotic#vault-management) * [Rewards](https://docs.cap.app/concepts/delegation/symbiotic#rewards) * [Slashing](https://docs.cap.app/concepts/delegation/symbiotic#slashing) * [Admin Control](https://docs.cap.app/concepts/delegation/symbiotic#admin-control) Copy function createVault( address _owner, // Vault owner/admin address address _asset, // Collateral asset address (e.g., wstETH) address _agent, // Agent address for delegation coverage address _network // Cap Symbiotic network address ) external returns ( address vault, // Deployed vault contract address address delegator, // Deployed delegator contract address address burner, // Deployed burner router address address slasher, // Deployed slasher contract address address stakerRewards // Deployed staker rewards contract address ); Copy function _deployBurner(address _collateral) internal returns (address) { return burnerRouterFactory.create( IBurnerRouter.InitParams({ owner: address(0), // No owner (immutable) collateral: _collateral, // Asset to burn delay: 0, // Instant execution globalReceiver: middleware, // Cap network middleware networkReceivers: new IBurnerRouter.NetworkReceiver[](0), operatorNetworkReceivers: new IBurnerRouter.OperatorNetworkReceiver[](0) }) ); } Copy stakerRewards = defaultStakerRewardsFactory.create( IDefaultStakerRewards.InitParams({ vault: vault, adminFee: 0, // Initial admin fee (0%) defaultAdminRoleHolder: _owner, // Vault owner gets admin role adminFeeClaimRoleHolder: _owner, // Vault wner can claim admin fees adminFeeSetRoleHolder: _owner // Vault owner can set admin fees }) ); Copy struct AgentConfig { address agent; // Agent address (operator) address vault; // Associated Symbiotic vault address rewarder; // Staker rewards contract uint256 ltv; // Loan-to-value ratio (e.g., 0.5e27 = 50%) uint256 liquidationThreshold; // Liquidation threshold (e.g., 0.7e27 = 70%) uint256 delegationRate; // Delegation rate for interest calculation } Copy // Add agent to delegation contract IDelegation(delegation).addAgent( agentAddress, // Agent address middleware, // Network middleware 0.5e27, // LTV (50%) 0.8e27 // Liquidation threshold (80%) ); Copy ISymbioticNetworkMiddleware($.networkMiddleware).registerVault( _agentConfig.vault, _agentConfig.rewarder, _agentConfig.agent ); Copy function distributeRewards(address _agent, address _token) external checkAccess(this.distributeRewards.selector) Copy function slash(address _agent, address _recipient, uint256 _slashShare, uint48 _timestamp) external checkAccess(this.slash.selector) --- # Fractional Reserves | cap The [Fractional Reserve](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/vault/FractionalReserve.sol) contracts allows the Vault to deploy idle capital into yield-generating strategies per reserve asset. In order to ensure sufficient liquidity for immediate withdrawals and redemptions, a fixed amount of capital can be set in the buffer reserve. The yield strategies are restricted to safe, verifiable sources such as direct revenue sharing from the reserve assets, or deployment into leading crypto lending markets such as Aave. This design ensures capital efficiency of the underlying assets while maintaining redeemability guarantees and reserve transparency. [Gelato](https://www.gelato.cloud/web3-functions) is used in Cap's Fractional Reserve system to automate capital deployment, yield harvesting, and fee distribution. [](https://docs.cap.app/concepts/vault/fractional-reserves#mechanics) Mechanics ------------------------------------------------------------------------------------ ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FAyKCkTx5FoTl16DkD6KR%252Fimage.png%3Falt%3Dmedia%26token%3Dcc6bee1d-27ed-4cc9-af8b-e06c04e8e46a&width=768&dpr=4&quality=100&sign=371c86d2&sv=2) Flow of Funds: Fractional Reserves The flow is as follows: 1. cUSD minters deposit assets into Cap Vault 2. Excess capital is invested into Fractional Reserve Vaults, where TokenHolder strategies will generate passive yield 3. Accrued yield is sent to the Fee Auction, sold for cUSD 4. The cUSD is transferred to the Fee Receiver which then periodically distributes rewards to stcUSD holders Fractional Reserve Vault & Gelato Mechanics * A ERC4626 [TokenHolder](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/fractionalReserve/TokenHolder.sol) Fractional Reserve Vault is deployed for the underlying reserve asset (i.e. USDC) that acts as a strategy following Yearn V3's [Tokenized Strategy](https://github.com/yearn/tokenized-strategy) pattern. (i.e. lending to Aave V3). Only the Fractional Reserve Vault can deposit and withdraw from the Vault. * The [CapSweeper](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/gelato/CapSweeper.sol) contract automatically invests excess assets every 6 hours * The strategy earns interest in the asset supplied until divested. [CapInterestHarvester](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/gelato/CapInterestHarvester.sol) is used to automate yield harvesting from the fractional reserve strategies to the Fee Auction ### [](https://docs.cap.app/concepts/vault/fractional-reserves#key-fractional-reserve-parameters) Key Fractional Reserve Parameters * **Reserve Level**: Minimum amount of each asset to keep in the vault (not invested) * **Loaned Amount**: Total amount of each asset currently invested in fractional reserve strategies * **Interest Receiver**: Address that receives realized interest (set to [Fee Auction](https://docs.cap.app/concepts/fee-auction) ) * **Claimable Interest**: Amount of interest available to be realized from strategies * **Investment Threshold**: Minimum amount required to invest in strategies [](https://docs.cap.app/concepts/vault/fractional-reserves#architecture) Architecture ------------------------------------------------------------------------------------------ The Fractional Reserve system consists of several interconnected components: 1. **FractionalReserve Contract** - Main logic for capital deployment 2. **TokenHolder** - ERC4626 Fractional Reserve Vault holding idle assets for strategy 3. **Harvester** - Orchestrates yield collection from all fractional reserve strategies 4. **LimitModule** - Restricts fractional reserve vault access to only the Cap vault 5. **Gelato Intergrations:** 1. **CapSweeper:** Periodically deploys capital into the Fractional Reserve ### [](https://docs.cap.app/concepts/vault/fractional-reserves#fractional-reserves) Fractional Reserves The Fractional Reserve contract manages the deployment and withdrawal of idle capital into yield-generating strategies. The implementation logic can be found in the [FractionalReserveLogic](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/vault/libraries/FractionalReserveLogic.sol) contract. #### [](https://docs.cap.app/concepts/vault/fractional-reserves#core-functions) Core Functions `**investAll**`: Invests excess capital above reserve level to the ERC4626 vault. The excess capital is calculated as the difference between asset balance in the Vault and the reserve balance. * `_asset`: Asset address to invest `**divestAll**`: Divests all invested capital for an asset from fractional reserve strategies * `_asset`: Asset address to divest Key features: * All of the Vault shares are redeemed from the Fractional Reserve Vault * Supports [partial divests](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/vault/libraries/FractionalReserveLogic.sol#L84) in case of user withdrawals or emergency `**realizeInterest**`: Withdraws accumulated interest from fractional reserve strategies * `_asset`: Asset address to realize interest for Key features: * Claimed interest is sent them to interest receiver ([Fee Auction](https://docs.cap.app/concepts/fee-auction) ) * Permissionless call #### [](https://docs.cap.app/concepts/vault/fractional-reserves#admin-functions) Admin Functions `**setFractionalReserveVault**`: Sets the fractional reserve vault for an asset * `_asset`: Asset address * `_vault`: New fractional reserve vault address Key features: * **Vault Migration**: Supports migration from old to new vault * **Automatic Divestment**: Divests from old vault before setting new one `**setReserve**`: Sets the reserve level for an asset * `_asset`: Asset address * `_reserve`: Reserve level in asset decimals #### [](https://docs.cap.app/concepts/vault/fractional-reserves#view-functions) View Functions * `**claimableInterest**`: Get the amount of interest available to be realized * `**fractionalReserveVault**`: Get the fractional reserve vault address for an asset * `**fractionalReserveVaults**`: Get all fractional reserve vault addresses * `**reserve**`: Get the reserve amount for an asset * `**loaned**`: Get the loaned amount to the fractional reserve strategy for an asset * `**interestReceiver**`: Get the interest receiver address ### [](https://docs.cap.app/concepts/vault/fractional-reserves#data-structures) Data Structures #### [](https://docs.cap.app/concepts/vault/fractional-reserves#fractionalreservestorage) FractionalReserveStorage The FractionalReserveStorage stores all fractional reserve configuration and state. ### [](https://docs.cap.app/concepts/vault/fractional-reserves#token-holder) Token Holder A TokenHolder Vault contains a simple strategy for holding the underlying asset. The implementation is inherited from Yearn V3's [Tokenized Strategy](https://github.com/yearn/tokenized-strategy) . The Vault is deployed via the [TokenHolderFactory](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/fractionalReserve/TokenHolderFactory.sol) . **Key features** * Only allows the Cap vault to deposit/withdraw via the Limit Module * Zero performance fees **Core Functions** * `**_deployFunds**`: Empty implementation (funds stay in contract) * `**_freeFunds**`: Empty implementation (funds stay in contract) * `**availableDepositLimit**`: Only allows Cap vault to deposit * `**availableWithdrawLimit**`: Only allows Cap vault to withdraw ### [](https://docs.cap.app/concepts/vault/fractional-reserves#limit-module) Limit Module The Limit Module provides access control for fractional reserve vault operations, ensuring only the Cap vault can interact with strategies **Core Functions** * `**available_deposit_limit**`: Only Cap vault can deposit * `**available_withdraw_limit**`: Only Cap vault can withdraw ### [](https://docs.cap.app/concepts/vault/fractional-reserves#harvester) Harvester The Harvester contract harvests yield from fractional reserve vaults. Specifically, for each strategy, the contract * Calls [report](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/fractionalReserve/Harvester.sol#L20) on to record claimable interest * Claims interest from the fractional reserves **Key Functions**: * `**harvest**`: Process all strategies and realize interest ### [](https://docs.cap.app/concepts/vault/fractional-reserves#gelato-integrations) Gelato Integrations #### [](https://docs.cap.app/concepts/vault/fractional-reserves#capsweeper) CapSweeper Automates capital deployment into fractional reserve strategies by calling investAll **Configuration Parameters:** * sweepInterval: 6 hours * minSweepAmount: 10k cUSD **Execution Conditions**: * **Time Interval**: Respect minimum time between sweeps per asset * **Asset Status**: Only sweep non-paused assets * **Minimum Amount**: Only sweep if balance exceeds minimum threshold [](https://docs.cap.app/concepts/vault/fractional-reserves#assets-and-corresponding-strategies) Assets and corresponding strategies ---------------------------------------------------------------------------------------------------------------------------------------- Currently, USDC is supported with the [Aave V3 lending strategy](https://github.com/cap-labs-dev/tokenized-aave-v3) . More assets and strategies coming soon! [PreviousVault](https://docs.cap.app/concepts/vault) [NextMinter](https://docs.cap.app/concepts/vault/minter) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/vault/fractional-reserves#mechanics) * [Key Fractional Reserve Parameters](https://docs.cap.app/concepts/vault/fractional-reserves#key-fractional-reserve-parameters) * [Architecture](https://docs.cap.app/concepts/vault/fractional-reserves#architecture) * [Fractional Reserves](https://docs.cap.app/concepts/vault/fractional-reserves#fractional-reserves) * [Data Structures](https://docs.cap.app/concepts/vault/fractional-reserves#data-structures) * [Token Holder](https://docs.cap.app/concepts/vault/fractional-reserves#token-holder) * [Limit Module](https://docs.cap.app/concepts/vault/fractional-reserves#limit-module) * [Harvester](https://docs.cap.app/concepts/vault/fractional-reserves#harvester) * [Gelato Integrations](https://docs.cap.app/concepts/vault/fractional-reserves#gelato-integrations) * [Assets and corresponding strategies](https://docs.cap.app/concepts/vault/fractional-reserves#assets-and-corresponding-strategies) Copy function investAll(address _asset) external; Copy function divestAll(address _asset) external checkAccess(this.divestAll.selector) Copy function realizeInterest(address _asset) external Copy function setFractionalReserveVault(address _asset, address _vault) external checkAccess(this.setFractionalReserveVault.selector) Copy function setReserve(address _asset, uint256 _reserve) external checkAccess(this.setReserve.selector) Copy struct FractionalReserveStorage { address interestReceiver; // Interest receiver address mapping(address => uint256) loaned; // Loaned amount per asset mapping(address => uint256) reserve; // Reserve amount per asset mapping(address => address) vault; // Fractional reserve vault per asset EnumerableSet.AddressSet vaults; // Set of all fractional reserve vaults } --- # Addresses | cap Ethereum Mainnet ### [](https://docs.cap.app/developers/addresses#cap-vault) **Cap Vault** Contract Address cUSD 0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC stcUSD 0x88887bE419578051FF9F4eb6C858A951921D8888 Debt USDC 0xfa8C6D0b95d9191B5A1D51C868Da2BDFd6C04Ff9 ### [](https://docs.cap.app/developers/addresses#cap-infra) **Cap Infra** Contract Address Oracle 0xcD7f45566bc0E7303fB92A93969BB4D3f6e662bb Lender 0x15622c3dbbc5614E6DFa9446603c1779647f01FC Access Control 0x7731129a10d51e18cDE607C5C115F26503D2c683 Delegation 0xF3E3Eae671000612CE3Fd15e1019154C1a4d693F Fee Auction 0xa1a20aBdc873CF291c22Ce3C8968EC06277324D0 Fee Receiver 0x0036c7b9b62c53F47c804a5643F0c09f864beF0b USDC Fractional Reserve Vault 0x3Ed6aa32c930253fc990dE58fF882B9186cd0072 cUSD Adapter 0xAcc9ce4C15A0F6A2bec49C3F81261d60553D2Faf stcUSD Adapter 0xdf48Eb321B38bc19E7F5b2CCA8242Cc6B9a6EcD0 Timelock 0xD8236031d8279d82E615aF2BFab5FC0127A329ab ### [](https://docs.cap.app/developers/addresses#symbiotic) Symbiotic Contract Address Network 0x98e52Ea7578F2088c152E81b17A9a459bF089f2a Network Middleware 0x09A3976d8D63728d20DCDFEe1e531C206Ba91225 Vault Factory 0x0B92300C8494833E504Ad7d36a301eA80DbBAE2e Agent Manager 0x08A728CF4E6b39f4AFa059c6eE376103722953eA ### [](https://docs.cap.app/developers/addresses#oracles) Oracles Contract Address [Redstone cUSD](https://app.redstone.finance/app/feeds/ethereum-mainnet/cusd_fundamental/) 0x9A5a3c3Ed0361505cC1D4e824B3854De5724434A [Morpho stcUSD](https://etherscan.io/address/0x8E3386B2f6084eB1B0988070c3d826995BD175c0) 0x8E3386B2f6084eB1B0988070c3d826995BD175c0 [PreviousFrontier Program](https://docs.cap.app/rewards/frontier-program) [NextTerms and Conditions](https://docs.cap.app/resources/terms-and-conditions) Last updated 5 days ago * [Cap Vault](https://docs.cap.app/developers/addresses#cap-vault) * [Cap Infra](https://docs.cap.app/developers/addresses#cap-infra) * [Symbiotic](https://docs.cap.app/developers/addresses#symbiotic) * [Oracles](https://docs.cap.app/developers/addresses#oracles) --- # Interest Rates | cap Cap's interest rate mechanism consists of benchmark rates, market rates, utilization rates, and restaker rates to ensure sustainable lending operations and proper compensation for risk-takers. [](https://docs.cap.app/concepts/lender/interest-rates#mechanics) Mechanics -------------------------------------------------------------------------------- The total interest that Operators pay can be summarized as: * Minimum Rate + Utilization Rate + Restaker Rate where Minimum rate is the maximum of the Benchmark Rate and the Market Rate Each rate is defined as below: 1. **Benchmark Rate**: Minimum interest rates set by protocol, in fixed yearly rates 2. **Market Rate**: Dynamic rates fetched from external lending markets and oracles 3. **Utilization Rate**: Dynamic rates based on asset utilization. Calculated via a piecewise linear function and a rate multiplier 4. **Restaker Rate**: Fixed annual rate set paid by the Operator to the Delegator underwriting them ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252FMRZdBZ9LS1mby0WLRCQ8%252Fimage.png%3Falt%3Dmedia%26token%3D505b0830-3049-44e9-8d38-61ff73b23202&width=768&dpr=4&quality=100&sign=8797a9a1&sv=2) Let us breakdown the interest formula: #### [](https://docs.cap.app/concepts/lender/interest-rates#id-1.-minimum-rate) 1\. Minimum rate The minimum rate represents a lower bound on the interest rates, and is determined by the greater value of the preconfigured benchmark rate and the market rate. The rationale for the minimum rate stems from the Fractional Reserves. Because Cap earns base yield from the underlying idle assets, Operators must be able to provide more than the base yield in order to borrow from Cap. For instance, if the benchmark yield set by Cap is set at 5%, and the current strategy for the Fractional Reserve of USDC is AAVE v3 earning rate is 4.5%, the minimum rate would be 5%. The minimum rate ensures that Cap’s interest rates is greater than the base yield at all times. #### [](https://docs.cap.app/concepts/lender/interest-rates#id-2.-utilization-rate) 2\. Utilization Rate The utilization rate is a function of a piecewise linear-kink model and a rate multiplier. The piecewise function allows interest rates to rise linearly along the first slope up to the "kink", or target utilization rate, set at 90%, after which rates increase rapidly along the second slope. This allows short term modulation of the rate where borrowing is disincentivized beyond the kink. The rate multiplier is determined by the deviation of the current utilization rate from the target rate. If the current rate is far below the target rate, and remains there for a long period, then it must be the case that the current target rate is too high to incentivize borrowing. Based on the elapsed duration of the deviation and the degree of the difference between the current utilization rate and target, the multiplier will decrease the current rate, effectively shifting the piecewise function down. This control allows for a longer term modulation, optimizing Cap's interest rates in an autonomous way. #### [](https://docs.cap.app/concepts/lender/interest-rates#id-3.-restaker-rate) 3\. Restaker Rate The restaker rate is the fixed yearly rate that Operators pay to the Delegators that collateralize them,. The rate is determined as a bilateral agreement between the Operator and Delegator, and is unique per each pair. Putting the pieces together, when calculating the interest rate, the system does the following: 1. Fetch market rate from oracle 2. Compare with benchmark rate (minimum floor) 3. Use higher of market or benchmark rate 4. Add utilization rate on top [](https://docs.cap.app/concepts/lender/interest-rates#architecture) Architecture -------------------------------------------------------------------------------------- 1. **RateOracle** - Manages and provides access to various interest rate sources 2. **Lender Contract** - Handles borrowing, repayment, and interest accrual 3. **Debt Token** - Minting and burning of debt tokens, bookkeeping current interest 4. **Vault Adapter** - Calculates utilization rate using slopes and multiplier 5. **SymbioticAgentManager** - Restaker rate management for Symbiotic Delegator compensation ### [](https://docs.cap.app/concepts/lender/interest-rates#core-functions) Core Functions `**nextInterstRate**`: updates interest every time there is an interaction with the Debt Token, i.e. borrowing and repaying assets and realizing interest via the [updateIndex](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/lendingPool/tokens/DebtToken.sol#L26) modifier #### [](https://docs.cap.app/concepts/lender/interest-rates#utilization-rate-calculation) Utilization Rate Calculation The Vault Adapter calculates the interest rate via the rate function. `**rate**`: Calculates utilization rate in the VaultAdapter contract The function processes as the following: 1. Fetch current utilization 2. Calculate elapsed time of deviation since last update, update utilization and timestamp 3. If the current utilization is higher than the target kink, the multiplier is updated according to the following formula: The interest rate is then calculated as: 1. If the current utilization is lower than the target kink, the multiplier is updated as such: where minimum and maximum multiplier ensure the bounds of the multipliers. The interest is then calculated as: #### [](https://docs.cap.app/concepts/lender/interest-rates#admin-controls) Admin Controls `**setBenchmarkRate**`: Set benchmark rate for an asset `**setRestakerRate**`: Set restaker rate for an agent * Called by SymbioticAgentManager for Symbiotic Delegation rates `**setMarketOracleData**`: Configure market rate oracle `**setUtilizationOracleData**`: Configure utilization rate oracle Specifically, the following functions are used for the utilization rate `**setSlopes**`: Defines the kink and slopes per asset `**setLimits**`: Defines multiplier rates, upper and lower bounds of the multiplier #### [](https://docs.cap.app/concepts/lender/interest-rates#rate-queries) Rate Queries The rates are queried via the [Rate Oracle](https://docs.cap.app/concepts/oracles#rate-oracle) , where the respective adapter is called to fetch the rate. The market rate queries Aave rates via the [AaveAdapter](https://docs.cap.app/cdn-cgi/l/email-protection#295c474d4c4f40474c4d) and the utilization rate uses the [VaultAdapter](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/oracle/libraries/VaultAdapter.sol) to set fee parameters and calculate utilization rates. Since the benchmark rate and restaker rate are static, they are looked up directly in storage. ### [](https://docs.cap.app/concepts/lender/interest-rates#vault-adapter-data-structures) Vault Adapter Data Structures The Vault Adapter data structure stores the parameters for the utilization rate. The slope data defines the piecewise linear function: where * **kink**: Utilization threshold where slope changes (0 < kink < 1e27) * **slope0**: Interest rate slope for utilization below kink * **slope1**: Additional interest rate slope for utilization above kink The utilization data defines the multiplier for longer term modulation: * **multiplier**: Time-based multiplier that adjusts based on utilization duration * **index**: Cumulative utilization index from the vault * **lastUpdate**: Timestamp of last utilization data update [PreviousLiquidation](https://docs.cap.app/concepts/lender/liquidation) [NextFee Auction](https://docs.cap.app/concepts/fee-auction) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/lender/interest-rates#mechanics) * [Architecture](https://docs.cap.app/concepts/lender/interest-rates#architecture) * [Core Functions](https://docs.cap.app/concepts/lender/interest-rates#core-functions) * [Vault Adapter Data Structures](https://docs.cap.app/concepts/lender/interest-rates#vault-adapter-data-structures) Copy // From DebtToken.sol function _nextInterestRate() internal returns (uint256 rate) { DebtTokenStorage storage $ = getDebtTokenStorage(); address _oracle = $.oracle; uint256 marketRate = IOracle(_oracle).marketRate($.asset); uint256 benchmarkRate = IOracle(_oracle).benchmarkRate($.asset); uint256 utilizationRate = IOracle(_oracle).utilizationRate($.asset); rate = marketRate > benchmarkRate ? marketRate : benchmarkRate; rate += utilizationRate; } Copy function rate(address _vault, address _asset) external returns (uint256 latestAnswer) Copy newMultiplier = oldMultiplier × (1 + (excess_utilization / (1 - kink)) × elapsed_time × rate) Copy interestRate = (slope0 + slope1 × (utilization - kink) / (1e27 - kink)) × multiplier Copy newMultiplier = oldMultiplier / (1 + ((kink - utilization) / kink) × elapsed_time × rate) Copy interestRate = (slope0 × utilization / kink) × multiplier Copy function setBenchmarkRate(address _asset, uint256 _rate) external; Copy function setRestakerRate(address _agent, uint256 _rate) external; Copy function setMarketOracleData(address _asset, IOracleTypes.OracleData calldata _oracleData) external; Copy function setUtilizationOracleData(address _asset, OracleData calldata _oracleData) external; Copy function setSlopes(address _asset, SlopeData memory _slopes) external; Copy function setLimits(uint256 _maxMultiplier, uint256 _minMultiplier, uint256 _rate) external; Copy struct VaultAdapterStorage { mapping(address => SlopeData) slopeData; // Per-asset slope configuration mapping(address => mapping(address => UtilizationData)) utilizationData; // Per-vault-per-asset utilization tracking uint256 maxMultiplier; // Maximum slope multiplier uint256 minMultiplier; // Minimum slope multiplier uint256 rate; // Rate at which multiplier shifts } Copy struct SlopeData { uint256 kink; // Kink point (utilization threshold) uint256 slope0; // Slope before kink (low utilization) uint256 slope1; // Slope after kink (high utilization) } Copy struct UtilizationData { uint256 multiplier; // Dynamic multiplier (adjusts over time) uint256 index; // Utilization index from vault uint256 lastUpdate; // Last update timestamp } --- # Terms and Conditions | cap By using our platform, you agree to comply with and be bound by the following terms and conditions, as well as all policies referenced herein. * [Platform Terms of Use](https://docs.cap.app/resources/terms-and-conditions/platform-terms-of-use) * [Privacy Policy](https://docs.cap.app/resources/terms-and-conditions/privacy-policy) Last updated: June 2, 2025 [PreviousAddresses](https://docs.cap.app/developers/addresses) [NextPlatform Terms of Use](https://docs.cap.app/resources/terms-and-conditions/platform-terms-of-use) Last updated 5 months ago --- # Delegation | cap The Delegation module serves as a middleware between Shared Security Networks and the lending protocol, enabling: * **Operator Management:** Register SSN Operators to Cap, setting their LTV/liquidation ratio and restaker fees * **Collateral Provision**: Delegators can collateralize Operators for borrowing capacity * **Slashing:** Execute slashing of delegated collateral during liquidations * **Reward Distribution**: Distribute rewards to delegators proportionally to their coverage Cap supports multiple SSNs. Currently integrated SSNs include: * [Symbiotic](https://docs.cap.app/concepts/delegation/symbiotic) * EigenLayer [](https://docs.cap.app/concepts/delegation#overview-of-cap-ssn-requirements) Overview of Cap SSN Requirements ------------------------------------------------------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/delegation#isolated-coverage) Isolated Coverage Delegation coverage is isolated both on a Network level and an Operator level. Each Operator is uniquely mapped to a SSN and a Delegator. Each Operator receives unique, isolated stake from a single Delegator such that slashing risk is not shared. Network level isolation means that delegations cannot be "restaked" across multiple slashable restaking protocols - because delegations are used as collateral in Cap, a slashing event in a different Network other than Cap would result in bad debt for Cap. Similarly, restaking across multiple Operators within Cap is not allowed. When multiple Delegators are delegating to the same operator, a withdrawal from one of the Delegators can result in a slashing event for other Delegators. In other words, a Delegator's stake can only be used for a single Operator in Cap. Alternatively, an Operator cannot receive stake from multiple Delegators. If the Operator were to receive delegations from a new Delegator, then the Operator can simply create a new Ethereum address to do so. ### [](https://docs.cap.app/concepts/delegation#restaker-fees) Restaker Fees Each Operator-Delegator agree upon a predetermined fee for restaking. As such, each Operator-Delegator have an unique fixed yearly rate that can be updated via Admin controls. The rates are set in the respective SSN upon deployment. Restaker fees are distributed per each SSN's reward handler. ### [](https://docs.cap.app/concepts/delegation#slashing-and-redistribution) Slashing and Redistribution Slashing conditions in Cap are objective: they are akin to liquidations and thus triggered when the health factor of the Operator drops below the liquidation threshold. Liquidations can be called permissionlessly, and verified onchain. Slashed funds are redistributed back to the liquidators, ensuring the cUSD is always backed 1:1. To incentivize liquidations, slashing and redistribution happen instantly. There are no veto committees nor delay periods for slashing to occur, nor for the slashed funds to be redistributed. ### [](https://docs.cap.app/concepts/delegation#whitelisted-participants) Whitelisted Participants While the protocol can function fully autonomously, to prevent malicious actors from attacking the protocol, Cap will initially whitelist Delegators and Operators. Delegators and Operators that seek to join the protocol should refer to the Onboarding Guides to do so. [](https://docs.cap.app/concepts/delegation#architecture) Architecture --------------------------------------------------------------------------- 1. **Delegation Contract** - Main contract managing agents, networks, and delegation operations 2. **SymbioticNetworkMiddleware** - Adapter for Symbiotic network integration 3. **SymbioticNetwork** - Network management and operator deployment ### [](https://docs.cap.app/concepts/delegation#delegation-contract) Delegation Contract #### [](https://docs.cap.app/concepts/delegation#core-functions) Core Functions `**slash**`: Executes slashing of delegated collateral during liquidations * `_agent`: Agent address to slash * `_liquidator`: Address to receive slashed collateral * `_amount`: USD value of delegation to slash `**distributeRewards**`: Distributes rewards to networks covering an agent * `_agent`: Agent address for reward distribution * `_asset`: Reward token address #### [](https://docs.cap.app/concepts/delegation#admin-functions) Admin Functions `**addAgent**`: Adds a new agent (operator) to the delegation system * `_agent`: Agent address to add * `_network`: Network address for the agent * `_ltv`: Loan-to-value ratio for the agent * `_liquidationThreshold`: Liquidation threshold for the agent `**modifyAgent**`: Modifies an existing agent's configuration * `_agent`: Agent address to modify * `_ltv`: New loan-to-value ratio * `_liquidationThreshold`: New liquidation threshold `**registerNetwork**`: Registers a new shared security network * `_network`: Network address to register `**setLtvBuffer**`: Sets the LTV buffer between LTV and liquidation threshold `**setFeeRecipient**`: Sets the fee recipient for cases with no coverage #### [](https://docs.cap.app/concepts/delegation#view-functions) View Functions * `**coverage**`: Gets the amount of delegation available to back an agent's borrows * `**slashableCollateral**`: Gets the amount of slashable collateral for an agent * `**slashTimestamp**`: Gets the appropriate slash timestamp for an agent * `**ltv**`: Gets the loan-to-value ratio for an agent * `**liquidationThreshold**`: Gets the liquidation threshold for an agent * `**agents**`: Gets all registered agent addresses * `**networkExists**`: Checks if a network is registered * `**epochDuration**`: Gets the epoch duration in seconds * `**epoch**`: Gets the current epoch * `**ltvBuffer**`: Gets the LTV buffer * `**feeRecipient**`: Gets the fee recipient address ### [](https://docs.cap.app/concepts/delegation#data-structures) Data Structures Delegation Storage Agent Data [PreviousFee Auction](https://docs.cap.app/concepts/fee-auction) [NextSymbiotic](https://docs.cap.app/concepts/delegation/symbiotic) Last updated 2 months ago * [Overview of Cap SSN Requirements](https://docs.cap.app/concepts/delegation#overview-of-cap-ssn-requirements) * [Isolated Coverage](https://docs.cap.app/concepts/delegation#isolated-coverage) * [Restaker Fees](https://docs.cap.app/concepts/delegation#restaker-fees) * [Slashing and Redistribution](https://docs.cap.app/concepts/delegation#slashing-and-redistribution) * [Whitelisted Participants](https://docs.cap.app/concepts/delegation#whitelisted-participants) * [Architecture](https://docs.cap.app/concepts/delegation#architecture) * [Delegation Contract](https://docs.cap.app/concepts/delegation#delegation-contract) * [Data Structures](https://docs.cap.app/concepts/delegation#data-structures) Copy function slash(address _agent, address _liquidator, uint256 _amount) external checkAccess(this.slash.selector) Copy function distributeRewards(address _agent, address _asset) external Copy function addAgent(address _agent, address _network, uint256 _ltv, uint256 _liquidationThreshold) external checkAccess(this.addAgent.selector) Copy function modifyAgent(address _agent, uint256 _ltv, uint256 _liquidationThreshold) external checkAccess(this.modifyAgent.selector) Copy function registerNetwork(address _network) external checkAccess(this.registerNetwork.selector) Copy function setLtvBuffer(uint256 _ltvBuffer) external checkAccess(this.setLtvBuffer.selector) Copy function setFeeRecipient(address _feeRecipient) external checkAccess(this.setFeeRecipient.selector) Copy struct DelegationStorage { EnumerableSet.AddressSet agents; // Registered agent addresses mapping(address => AgentData) agentData; // Per-agent configuration EnumerableSet.AddressSet networks; // Registered network addresses address oracle; // Oracle for price feeds uint256 epochDuration; // Epoch duration in seconds uint256 ltvBuffer; // LTV buffer from liquidation threshold address feeRecipient; // Fee recipient address } Copy struct AgentData { address network; // Associated network address uint256 ltv; // Loan-to-value ratio (ray) uint256 liquidationThreshold; // Liquidation threshold (ray) uint256 lastBorrow; // Last borrow timestamp } --- # Access Controls | cap The Access Control system implements granular, function-level permissions across all contracts of Cap. It provides a sophisticated role-based access control mechanism that allows precise management of who can call specific functions on specific contracts, building on OpenZeppelin's [AccessControlEnumberable](https://docs.openzeppelin.com/contracts/3.x/access-control) Integration. Roles are managed by the Access Control admin, currently set to Cap's multisig address [](https://docs.cap.app/concepts/access-controls#mechanics) Mechanics -------------------------------------------------------------------------- * Each function on each contract has its own unique 32-byte role ID * The role ID is generated by combining: * The function selector (first 4 bytes of the function signature) * The contract address * Permissions can be granted/revoked at the function level * Contracts inherit access control through the `Access` abstract contract and uses the checkAccess modifier on protected functions [](https://docs.cap.app/concepts/access-controls#architecture) Architecture -------------------------------------------------------------------------------- * Access.sol: Inheritable abstract contract that provides the base functionality for access control * AccessControl.sol: Central contract that implements the access control logic ### [](https://docs.cap.app/concepts/access-controls#access-control) Access Control #### [](https://docs.cap.app/concepts/access-controls#core-functions) Core Functions `**grantAccess**`: Grants permission to call a specific function on a specific contract * `_selector`: Function selector (4-byte identifier) of the method to grant access to * `_contract`: Address of the contract containing the method * `_address`: Address to grant access to `**revokeAccess**`: Revokes permission to call a specific function on a specific contract * `_selector`: Function selector (4-byte identifier) of the method to revoke access from * `_contract`: Address of the contract containing the method * `_address`: Address to revoke access from `**checkAccess**`: Verifies if an address has permission to call a specific function * **Returns**: True if access is granted, false otherwise When a access controlled function is called, the checkAccess modifier calls [\_checkRole](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/access/Access.sol#L35) with the function's selector, contract and message sender. `**role**`: Gets the role identifier for a specific function selector on a contract * `_selector`: Function selector (4-byte identifier) of the method * `_contract`: Address of the contract containing the method * **Returns**: Unique role identifier derived from selector and contract address [](https://docs.cap.app/concepts/access-controls#role-hierarchy) Role Hierarchy ------------------------------------------------------------------------------------ 1. **DEFAULT\_ADMIN\_ROLE**: Can upgrade the AccessControl contract 2. **Access Management Roles**: Can grant/revoke permissions 3. **Function-Specific Roles**: Control access to individual functions [](https://docs.cap.app/concepts/access-controls#permission-types) Permission Types ---------------------------------------------------------------------------------------- **1\. Administrative Permissions** * Contract upgrades (`bytes4(0)`) * Access management (`grantAccess`, `revokeAccess`) **2\. Operational Permissions** * Vault operations (`borrow`, `repay`, `mint`, `burn`) * Oracle managements (`setOracleData`, `setStaleness`, `setRates`) * Asset management (`addAsset`, `removeAsset`, `pauseAsset`, `setReserve`) * Fee Auctions (`setDuration`, `setStartPrice` ,`setPaymentToken`) * Delegations ( `addAgent`, `modifyAgent` ,`registerNetwork`) **3\. Emergency Permissions** * Protocol pause (`pauseProtocol`, `unpauseProtocol`) * Emergency functions (`emergencyWithdraw`, `rescueERC20`) [PreviousOracles](https://docs.cap.app/concepts/oracles) [NextFrontier Program](https://docs.cap.app/rewards/frontier-program) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/access-controls#mechanics) * [Architecture](https://docs.cap.app/concepts/access-controls#architecture) * [Access Control](https://docs.cap.app/concepts/access-controls#access-control) * [Role Hierarchy](https://docs.cap.app/concepts/access-controls#role-hierarchy) * [Permission Types](https://docs.cap.app/concepts/access-controls#permission-types) Copy function grantAccess(bytes4 _selector, address _contract, address _address) external Copy function revokeAccess(bytes4 _selector, address _contract, address _address) external Copy function checkAccess(bytes4 _selector, address _contract, address _caller) external view returns (bool hasAccess) Copy function role(bytes4 _selector, address _contract) public pure returns (bytes32 roleId) Copy DEFAULT_ADMIN_ROLE ├── access_control_admin │ ├── oracle_admin │ ├── rate_oracle_admin │ ├── lender_admin │ ├── delegation_admin │ └── vault_config_admin └── Emergency Admin --- # Frontier Program | cap The Frontier Program marks a pivotal launch phase for Cap, opening its doors to the public on Ethereum mainnet. The program aims to foster a vibrant, committed community at the heart of Cap’s ecosystem. The Frontier Program incentivizes early and consistent participation to earn "Caps". Those who join and remain active from the outset stand to earn the highest number of Caps. Users can start accruing Caps by exploring Cap's flagship products: cUSD and stcUSD. Below is the link to all venues where users can participate in the Frontier Program. Detailed information about the Program can be found [here](https://mirror.xyz/0x83c21bb4Bf0EC116f5a1945AaeF847Fe3b321B32/BNYypWfT0CyrV2De1_MM5_KqInuONerxJFi1anNHWPU) . #### [](https://docs.cap.app/rewards/frontier-program#pendle) Pendle * [PT cUSD](https://app.pendle.finance/trade/markets/0x307c15f808914df5a5dbe17e5608f84953ffa023/swap?view=pt&chain=ethereum) * [PT stcUSD](https://app.pendle.finance/trade/markets/0xcc781b043933c10a04409b22aada3a3d1a7f29d4/swap?view=pt&chain=ethereum) * [Penpie PT cUSD](https://www.pendle.magpiexyz.io/stake/0x307c15f808914df5a5dbe17e5608f84953ffa023) * [Penpie PT stcUSD](https://www.pendle.magpiexyz.io/stake/0xcc781b043933c10a04409b22aada3a3d1a7f29d4) * [Equilibria PT stcUSD](https://equilibria.fi/stake) #### [](https://docs.cap.app/rewards/frontier-program#yield-optimizer) Yield Optimizer * [Beefy penpie stcUSD](https://app.beefy.com/vault/pendle-stcusd-29jan26) * [Beefy equilibria stcUSD](https://app.beefy.com/vault/pendle-eqb-stcusd-29jan26) #### [](https://docs.cap.app/rewards/frontier-program#lending-markets) Lending Markets * [Morpho stcUSD / USDC](https://app.morpho.org/ethereum/market/0xeb17955ea422baeddbfb0b8d8c9086c5be7a9cfdefb292119a102e981a30062e/stcusd-usdc) * [Morpho PT-stcUSD-29JAN2026 / USDC](https://app.morpho.org/ethereum/market/0x03f715ef1ae508ab3e1faf4dffdbf2a077d1f0ad10c5aad42cf4438d5e3328af/pt-stcusd-29jan2026-usdc) Caps are rewarded to USDC suppliers to the markets above [PreviousAccess Controls](https://docs.cap.app/concepts/access-controls) [NextAddresses](https://docs.cap.app/developers/addresses) Last updated 3 months ago --- # Liquidation | cap When an Operator's health factor drops below 1, liquidators can purchase the Operator's delegated collateral by repaying their outstanding debt. [](https://docs.cap.app/concepts/lender/liquidation#mechanics) Mechanics ----------------------------------------------------------------------------- The liquidation process is as follows: 1. The liquidation process kicks off with a liquidator calling the initiateLiquidation function 2. After the liquidation has been initiated, the Operator has a grace period of 12 hours to improve the health of the loan 1. If the current Loan-to-Value is less than the emergency liquidation threshold, the grace period is overridden, opening the liquidation window immediately. 3. At the end of the grace period, liquidators can call the liquidate function until the expiry of the liquidation period. Liquidations will expire in 3 days after the end of the grace period. 4. A successful liquidation will execute a repayment of the borrowed asset, reducing the debt by the liquidation amount 5. The liquidated amount and the liquidation bonus is slashed from the Shared Security Network, transferring the collateral to the liquidator 6. The liquidation window will close once the Operator's health is recovered, i.e. over 1 #### [](https://docs.cap.app/concepts/lender/liquidation#liquidation-threshold) Liquidation Threshold By default, the liquidation threshold is set to 80% LTV. If the current LTV exceeds the liquidation threshold, then a liquidation may be opened. An emergency liquidation mechanism is used to override the grace period if the health threshold drops significantly. The emergency liquidation threshold is set to 90% LTV. #### [](https://docs.cap.app/concepts/lender/liquidation#liquidation-expiry) Liquidation Expiry All liquidations have an expiry window. The window ensures that once the position becomes healthy again, the Operator will no longer be liquidatable. Hence, if the Operator were to be liquidatable again, the Operator will be ensured another grace period. If the Operator's health factor is below 1 after the expiry, any liquidator can initiate the liquidation process again. #### [](https://docs.cap.app/concepts/lender/liquidation#target-health-and-maximum-liquidatable-amount) Target Health and Maximum Liquidatable Amount Target health is a health ratio threshold that defines the desired health level that liquidations should restore an Operator's position to, currently set at 1.25. It acts as a "safety buffer" that liquidations aim to achieve. The target health defines the the maximum liquidatable amount. The maximum liquidatable amount is calculated as: ((Target Health \* Total Debt) - (Total Delegation \* Liquidation Threshold)) / ((Target Health - Liquidation Threshold) \* Asset Price) In other words, the goal is for the health factor, i.e. Total Delegation \* Liquidation Threshold / (TotalDebt - Liquidated Amount) to be equal to the target health ratio. #### [](https://docs.cap.app/concepts/lender/liquidation#liquidation-bonus) Liquidation Bonus The protocol implements a dynamic liquidation bonus system that provides incentives for liquidators. The liquidation bonus rises linearly with time from the grace period until the maximum amount reaches the bonus cap. At expiry, liquidators earn the maximum bonus which is set to 10%. If an emergency liquidation is triggered, liquidators bypass the grace period, immediately earning the maximum bonus. Note that the bonus is only available when the total delegation exceeds total debt. The protocol prevents over-liquidating beyond available collateral [](https://docs.cap.app/concepts/lender/liquidation#architecture) Architecture ----------------------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/lender/liquidation#liquidation-logic) Liquidation Logic The **LiquidationLogic** library is the core component responsible for managing liquidation operations ### [](https://docs.cap.app/concepts/lender/liquidation#key-functions) Key Functions `**openLiquidation**`: Opens a liquidation window for an unhealthy operator **Process Flow**: 1. **Health Check**: 2. **Validation**: 3. **Window Opening**: **Validation Rules**: * Agent health must be below 1e27 (100%) * Previous liquidation window must have expired * Cannot open multiple concurrent windows `**closeLiquidation**`: Closes a liquidation window when an Operator becomes healthy **Process Flow**: 1. **Health Verification**: 2. **Validation**: 3. **Window Closure**: **Validation Rules**: * Agent health must be above 1e27 (100%) * Only healthy agents can have windows closed `**liquidate**`: Executes liquidation of unhealthy positions with bonus incentives **Process Flow**: 1. An Operator must be eligible to be liquidated: health factor below 1, and have outstanding debt to be liquidated. 2. Checks for emergency liquidations, and whether liquidate timestamp is within the liquidation window. 1. Asset Pricing and Bonus Calculation 2. Calculate Max Liquidatable Amount 3. Repay Debt: 4. Liquidation Value Calculation 5. Execute Slashing 6. Close Window #### [](https://docs.cap.app/concepts/lender/liquidation#admin-functions) Admin Functions `**setGrace**`: Set grace period for liquidations `**setExpiry**`: Set expiry period for liquidations **Set Bonus Cap for liquidations** #### [](https://docs.cap.app/concepts/lender/liquidation#view-functions) View Functions `**grace**`: View grace period in seconds `**expiry**`: Returns the expiry period after which liquidation rights expire `**maxLiquidatable**`: Max liquidatable amount for an agent borrowing a particular asset `**bonus**`: Calculates the maximum bonus percentage for liquidating an agent `**bonusCap**`: Returns the maximum bonus percentage for liquidations `**emergencyLiquidationThreshold**`: Returns the health threshold below which grace periods are ignored `**liquidationStart**`: Returns the timestamp when liquidation was initiated for an agent [PreviousBorrow](https://docs.cap.app/concepts/lender/borrow) [NextInterest Rates](https://docs.cap.app/concepts/lender/interest-rates) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/lender/liquidation#mechanics) * [Architecture](https://docs.cap.app/concepts/lender/liquidation#architecture) * [Liquidation Logic](https://docs.cap.app/concepts/lender/liquidation#liquidation-logic) * [Key Functions](https://docs.cap.app/concepts/lender/liquidation#key-functions) Copy function openLiquidation(ILender.LenderStorage storage $, address _agent) external Copy (,,,,, uint256 health) = ViewLogic.agent($, _agent); Copy ValidationLogic.validateOpenLiquidation(health, $.liquidationStart[_agent], $.expiry); Copy $.liquidationStart[_agent] = block.timestamp; Copy function closeLiquidation(ILender.LenderStorage storage $, address _agent) external Copy (,,,,, uint256 health) = ViewLogic.agent($, _agent); Copy ValidationLogic.validateCloseLiquidation(health); Copy _closeLiquidation($, _agent); Copy function liquidate(ILender.LenderStorage storage $, ILender.RepayParams memory params, uint256 _minLiquidatedValue) external returns (uint256 liquidatedValue) Copy ValidationLogic.validateLiquidation( health, totalDelegation * $.emergencyLiquidationThreshold / totalDebt, $.liquidationStart[params.agent], $.grace, $.expiry ); Copy (uint256 assetPrice,) = IOracle($.oracle).getPrice(params.asset); uint256 bonus = ViewLogic.bonus($, params.agent); Copy uint256 maxLiquidation = ViewLogic.maxLiquidatable($, params.agent, params.asset); uint256 liquidated = params.amount > maxLiquidation ? maxLiquidation : params.amount; Copy liquidated = BorrowLogic.repay( $, ILender.RepayParams({ agent: params.agent, asset: params.asset, amount: liquidated, caller: params.caller }) ); Copy liquidatedValue = (liquidated + (liquidated * bonus / 1e27)) * assetPrice / (10 ** $.reservesData[params.asset].decimals); if (totalSlashableCollateral < liquidatedValue) liquidatedValue = totalSlashableCollateral; Copy if (liquidatedValue > 0) IDelegation($.delegation).slash(params.agent, params.caller, liquidatedValue); Copy if (health >= 1e27) _closeLiquidation($, params.agent); Copy function setGrace(uint256 _grace) external; Copy function setExpiry(uint256 _expiry) external; Copy function setBonusCap(uint256 _bonusCap) external; Copy function grace() external view returns (uint256 gracePeriod) Copy function expiry() external view returns (uint256 expiryPeriod) Copy function maxLiquidatable(address _agent, address _asset) external view returns (uint256 maxLiquidatableAmount) Copy function bonus(address _agent) external view returns (uint256 maxBonus) Copy function bonusCap() external view returns (uint256 cap) Copy function emergencyLiquidationThreshold() external view returns (uint256 threshold) Copy function liquidationStart(address _agent) external view returns (uint256 startTime) --- # Audits | cap Ongoing bug bounties: [Sherlock Bug Bounty](https://audits.sherlock.xyz/bug-bounties/114) : Up to $1m in rewards Auditors Start Date Report Scope Certora Sep 15th 2025 [certora-report](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-09-15-Certora%20(EigenAVS).pdf) EigenLayer SSN Sherlock Jul 10th 2025 [sherlock-bug-bounty](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-09-03-Sherlock.pdf) Cap protocol Recon May 28th 2025 [recon-invariant-testing](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-07-04-Recon.pdf) Invariant testing Electisec May 25th 2025 [electisec-report](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-05-25-Electisec.pdf) LZ vault Spearbit Lead Security Researchers Apr 14th 2025 [spearbit-report](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-06-23-Spearbit.pdf) Cap protocol Trail of Bits Mar 3rd 2025 [tob-report](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-05-15-TrailOfBits.pdf) Cap protocol Zellic Feb 17th 2025 [zellic-report](https://github.com/cap-labs-dev/cap-audits/blob/main/2025-03-17-Zellic.pdf) Cap protocol [PreviousPrivacy Policy](https://docs.cap.app/resources/terms-and-conditions/privacy-policy) [NextHelpful Links](https://docs.cap.app/helpful-links) Last updated 1 month ago --- # Lender | cap The Lending Pool module manages the borrowing, repayment, and liquidation processes for Operators. [](https://docs.cap.app/concepts/lender#overview-of-operations) Overview of Operations ------------------------------------------------------------------------------------------- 1. [**Borrow/Repay**](https://docs.cap.app/concepts/lender/borrow) : Operators can borrow reserve assets against their delegated collateral 2. [**Liquidation**](https://docs.cap.app/concepts/lender/liquidation) : Multi-stage liquidation with grace periods and bonus incentives 3. [**Interest Rate Calculation**](https://docs.cap.app/concepts/lender/interest-rates) **:** Dynamic protocol rates and fixed Operator specific rates [](https://docs.cap.app/concepts/lender#key-loan-parameters) Key Loan Parameters ------------------------------------------------------------------------------------- * **Total Delegation:** Total amount of an Operator's received collateral from Delegators * **Total Slashable Collateral:** Total amount of collateral that can be slashed from a Delegator * **Total Debt:** An Operator's total debt denominated in USD. Interest accrues to Total Debt * **Initial Loan-to-Value (LTV):** The maximum amount an Operator can borrow relative to the Total Slashable Collateral. A 50% LTV implies that delegations must be at least 2x the size of the borrow. * **Current LTV**: An Operator's current Loan-to-Value ratio, calculated as * (Total Debt / Total Delegation) \* 100% * **Liquidation Threshold**: Threshold that determines when an Operator's position becomes slashable in LTV ratio. By default, the threshold is set to 80%. * **Health Factor**: Represents an Operator's loan health * Calculated as (Total Delegation \* Liquidation Threshold) / Total Debt * Liquidations are triggered when Health is below 1 * **Grace Period**: Period for Operators to recover the health before liquidation can occur. Set to 12 hours * **Expiry Period:** Period after which liquidation rights expire. Set to 3 days * **Target health:** Target health ratio that liquidators aim to achieve when slashing an Operator. Set to 125% * **Bonus Cap:** Maximum bonus for liquidators, set to 10%. [](https://docs.cap.app/concepts/lender#debt-management) Debt Management ----------------------------------------------------------------------------- The protocol has two distinct types of interest: 1. **Vault Interest**: Interest paid to the Vault (stcUSD holders) 2. **Restaker Interest**: Interest paid to Delegators who provide collateral coverage Debt in Cap is managed via Debt tokens. Debt tokens are non-transferrable ERC-20 tokens that track an Operator's debt. Debt tokens are minted when an Operator borrows, and burned when the debt is repayed. Interest automatically accrues to the debt token per asset, where the interest rate is calculated based on the [interest rate mechanism](https://docs.cap.app/concepts/lender/interest-rates) . Accrued interest is handled automatically via index-based scaling, inherited from the ScaledToken base class. [](https://docs.cap.app/concepts/lender#architecture) Architecture ----------------------------------------------------------------------- The Lending Pool module is designed as an upgradeable proxy with modular logic libraries for maintainability and security. 1. **BorrowLogic Library** - Core logic for borrowing, repaying, and interest management 2. **LiquidationLogic Library** - Advanced liquidation mechanisms and bonus calculations 3. **ReserveLogic Library** - Reserve management and configuration 4. **ViewLogic Library** - View functions and calculations 5. **ValidationLogic Library** - Comprehensive validation systems ### [](https://docs.cap.app/concepts/lender#lender-contract) Lender Contract The Lender contract is the main interface for all lending operations. #### [](https://docs.cap.app/concepts/lender#core-functions) Core Functions #### [](https://docs.cap.app/concepts/lender#borrowing-operations) Borrowing Operations `**borrow**`: Allows agents to borrow assets from the lending pool via the BorrowLogic library * `_asset`: Asset to borrow * `_amount`: Amount to borrow * `_receiver`: Address to receive the borrowed assets `**repay**`: Allows agents to repay assets from the lending pool via the BorrowLogic library * `_asset`: Asset to repay * `_amount`: Amount to repay * `_agent`: Agent whose debt is being repaid **Liquidation** `**openLiquidation**`: Opens a liquidation window for an unhealthy operator `**liquidate**`: Liquidate debt and slash collateral `**closeLiquidation**`: End liquidation window when position is healthy **Interest Distribution** Convert accrued interest into debt tokens via the BorrowLogic library **Types**: * Vault Interest: System-wide interest realization * Restaker Interest: Agent-specific interest for restakers #### [](https://docs.cap.app/concepts/lender#admin-functions) **Admin Functions** `**addAsset**`: Adds new assets to the lending pool Parameters: * **asset**: Asset address to add * **vault**: Vault address for the asset * **debtToken**: Debt token address * **interestReceiver**: Interest receiver address * **bonusCap**: Liquidation bonus cap * **minBorrow**: Minimum borrow amount `**removeAsset**`**:** Removes assets from the lending pool, if there are no outstanding debt before removal `**papuseAsset**`: Pause asset from being borrowed, prevents new borrows when paused `**setInterestReceiver**`: Sets interest receiver for an asset `**setMinBorrow**`**:** Set Minimum Borrow **Set Liquidation Parameters** More details can be found in the [Liquidation](https://docs.cap.app/concepts/lender/liquidation) page #### [](https://docs.cap.app/concepts/lender#view-functions) **View Functions** `**Agent**`**:** View agent(Operator) information `**maxBorrowable**`**:** Maximum Borrowable Amount for an agent for an asset `**Debt**`: Get the current debt balances for an agent for a specific asset ### [](https://docs.cap.app/concepts/lender#data-structures) Data Structures The LenderStorage stores the list of all the Reserve Data along with agent (Operator) configuration and liquidation parameters. The reserve data struct stores all relevant Vault information for an underlying asset. Agent (Operator) configuration is stored in the AgentConfigurationMap struct that contains a single uint256 field called data. This field is a bitmap, where each bit represents a boolean of whether an agent is borrowing for a specific reserve. Agent specific loan information such as collateral amount, liquidation threshold is stored in the Delegation contract and can be read via the ViewLogic contract. [PreviousMinter](https://docs.cap.app/concepts/vault/minter) [NextBorrow](https://docs.cap.app/concepts/lender/borrow) Last updated 2 months ago * [Overview of Operations](https://docs.cap.app/concepts/lender#overview-of-operations) * [Key Loan Parameters](https://docs.cap.app/concepts/lender#key-loan-parameters) * [Debt Management](https://docs.cap.app/concepts/lender#debt-management) * [Architecture](https://docs.cap.app/concepts/lender#architecture) * [Lender Contract](https://docs.cap.app/concepts/lender#lender-contract) * [Data Structures](https://docs.cap.app/concepts/lender#data-structures) Copy function borrow(address _asset, uint256 _amount, address _receiver) external returns (uint256 borrowed) Copy function repay(address _asset, uint256 _amount, address _agent) external returns (uint256 repaid) Copy function openLiquidation(address _agent) external Copy function liquidate(address _agent, address _asset, uint256 _amount, uint256 _minLiquidatedValue) external returns (uint256 liquidatedValue) Copy function closeLiquidation(address _agent) external Copy function realizeInterest(address _asset) external returns (uint256 actualRealized) function realizeRestakerInterest(address _agent, address _asset) external returns (uint256 actualRealized) Copy function addAsset(AddAssetParams calldata _params) external checkAccess(this.addAsset.selector) Copy function removeAsset(address _asset) external checkAccess(this.removeAsset.selector) Copy function pauseAsset(address _asset, bool _pause) external checkAccess(this.pauseAsset.selector) Copy function setInterestReceiver(address _asset, address _interestReceiver) external checkAccess(this.setInterestReceiver.selector) Copy function setMinBorrow(address _asset, uint256 _minBorrow) external checkAccess(this.setMinBorrow.selector) Copy function setGrace(uint256 _grace) external checkAccess(this.setGrace.selector) function setExpiry(uint256 _expiry) external checkAccess(this.setExpiry.selector) function setBonusCap(uint256 _bonusCap) external checkAccess(this.setBonusCap.selector) function setTargetHealth(uint256 _targetHealth) external checkAccess(this.setTargetHealth.selector) Copy function agent(address _agent) external view returns ( uint256 totalDelegation, // Total delegation in USD (8 decimals) uint256 totalSlashableCollateral, // Total slashable collateral in USD (8 decimals) uint256 totalDebt, // Total debt in USD (8 decimals) uint256 ltv, // Loan to value ratio (1e27) uint256 liquidationThreshold, // Liquidation threshold (1e27) uint256 health // Health factor (1e27) ) Copy function maxBorrowable(address _agent, address _asset) external view returns (uint256 maxBorrowableAmount) Copy function debt(address _agent, address _asset) external view returns (uint256 totalDebt); Copy struct LenderStorage { // Addresses address delegation; // Delegation contract managing agent permissions address oracle; // Oracle for price feeds // Reserve configuration mapping(address => ReserveData) reservesData; // Asset to reserve data mapping mapping(uint256 => address) reservesList; // Reserve ID to asset mapping uint16 reservesCount; // Total number of reserves // Agent configuration mapping(address => AgentConfigurationMap) agentConfig; // Agent configuration data mapping(address => uint256) liquidationStart; // Liquidation start timestamps // Liquidation parameters uint256 targetHealth; // Target health ratio (1e27) uint256 grace; // Grace period in seconds uint256 expiry; // Liquidation expiry period uint256 bonusCap; // Maximum liquidation bonus (1e27) uint256 emergencyLiquidationThreshold; // Emergency liquidation threshold } Copy struct ReserveData { uint256 id; // Reserve ID address vault; // Vault address address debtToken; // Debt token address address interestReceiver; // Interest receiver address uint8 decimals; // Asset decimals bool paused; // Pause state uint256 debt; // Total debt uint256 totalUnrealizedInterest; // Total unrealized interest mapping(address => uint256) unrealizedInterest; // Per-agent unrealized interest mapping(address => uint256) lastRealizationTime; // Last interest realization time uint256 minBorrow; // Minimum borrow amount } --- # Fee Auction | cap The [Fee Auction](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/feeAuction/FeeAuction.sol) facilitates permissionless Dutch auctions where collected protocol fees are sold to the winning bidder. The proceeds are sent to the [Fee Receiver](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/feeReceiver/FeeReceiver.sol) to convert to cUSD and distribute to stcUSD holders. The Fee Auction module provides an efficient and transparent way to distribute accumulated fees to participants while ensuring fair price discovery through time-based price decay. [](https://docs.cap.app/concepts/fee-auction#mechanics) Mechanics ---------------------------------------------------------------------- ### [](https://docs.cap.app/concepts/fee-auction#overview-of-operations) Overview of Operations 1. **Interest Harvesting**: Interest Harvester realizes accumulated interest and sends it to Fee Auction 2. **Dutch Auction**: Fee Auction sells accumulated assets via a Dutch auction mechanism 3. **Fee Distribution**: Fee Receiver collects cUSD from auction sales and distributes to stcUSD token holders ![](https://docs.cap.app/~gitbook/image?url=https%3A%2F%2F315632032-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FkRZQBMptsoesj7n1mr8a%252Fuploads%252F2uStIQVV65YigzjJ10JE%252Fimage.png%3Falt%3Dmedia%26token%3Db15c218b-2238-44cc-8907-1cee3843658f&width=768&dpr=4&quality=100&sign=eb393168&sv=2) Flow of Funds: Fee Auction ### [](https://docs.cap.app/concepts/fee-auction#dutch-auction-mechanics) Dutch Auction Mechanics * Admin sets a starting price (in cUSD) and the duration of auctions. * The price decays linearly over time (up to 90% or until minimum price is reached) until a winning bidder makes a purchase. All accumulated fees are distributed to the buyer. * The purchase triggers the start of the next auction, where the starting price is set to be double the settled price. ### [](https://docs.cap.app/concepts/fee-auction#key-auction-parameters) Key Auction Parameters * **Starting Price**: Initial price set by admin for each auction (in cUSD) * **Duration**: Auction duration set to 24 hours by default * **Minimum Start Price**: Minimum starting price set to 100 cUSD * **Payment Token**: cUSD is used as the payment token for all auctions * **Recipient**: Fee Receiver contract receives all auction proceeds * **Price Multiplier**: New auction starts at 2x the settled price of the previous auction [](https://docs.cap.app/concepts/fee-auction#architecture) Architecture ---------------------------------------------------------------------------- The Fee Auction system consists of three main components: 1. **FeeAuction Contract** - Facilitates Dutch auction mechanism for selling fees 2. **FeeReceiver Contract** - Manages fee distribution to stakeholders 3. **Gelato Automations** \- Automates harvesting interest and distributing rewards ### [](https://docs.cap.app/concepts/fee-auction#fee-auction) Fee Auction The [FeeAuction](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/feeAuction/FeeAuction.sol) contract implements a Dutch auction mechanism for selling accumulated yield. #### [](https://docs.cap.app/concepts/fee-auction#core-functions) Core Functions `**buy**`: Allows permissionless purchase of accumulated fees at current auction price * `_maxPrice`: Maximum price willing to pay * `_assets`: Array of assets to purchase * `_minAmounts`: Minimum amounts to purchase for each asset * `_receiver`: Address to receive the purchased assets * `_deadline`: Deadline for the auction purchase **Admin Functions** `**setStartPrice**`: Sets the starting price for the current auction `**setDuration**`: Sets the duration for future auctions `**setMinStartPrice**`: Sets the minimum starting price for future auctions `**setPaymentToken**`: Sets the payment token for the auction ### [](https://docs.cap.app/concepts/fee-auction#fee-receiver) Fee Receiver The Fee Receiver distributes fees collected from the auction to stakeholders. The protocol can take a percentage of the accumulated yield for protocol treasury. The protocol fee is currently configured to 0. #### [](https://docs.cap.app/concepts/fee-auction#core-functions-1) Core Functions `**distribute**`: Distributes fees to staked cap token holders The [`notify`](https://github.com/cap-labs-dev/cap-contracts/blob/25f3fc8a4aa186070381c7d19c170e524a815c5a/contracts/gelato/CapNotify.sol#L25) function is called when the vesting period is complete. The vesting period is configured to 24 hours. #### [](https://docs.cap.app/concepts/fee-auction#admin-functions) Admin Functions `**setCapToken**`: Sets the Cap token address `**setStakedCapToken**`: Sets the staked Cap token address `**setProtocolFeePercentage**`: Sets protocol fee percentage `**setProtocolFeeReceiver**`**:** Sets protocol fee recipient ### [](https://docs.cap.app/concepts/fee-auction#gelato-integrations) Gelato Integrations Gelato is used in the Fee Auction to automate yield harvesting and fee distribution via CapInterestHarvester and CapNotify respectively. #### [](https://docs.cap.app/concepts/fee-auction#capinterestharvester) CapInterestHarvester `**harvestInterest**`: Harvests yields from multiple sources and triggers fee distribution Harvests yields from many sources via the [harvestInterest](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/gelato/CapInterestHarvester.sol#L61) function. The function executes the following: 1. **Fractional Reserve Harvesting**: Calls the Harvester contract to realize yields from FR strategies 2. **Lender Interest Claiming**: Claims accumulated interest from lending operations 3. **Flash Loan Optimization**: Uses Balancer flash loans to efficiently buy interest from fee auction 4. **Fee Distribution**: Triggers distribution of collected fees **Execution Conditions**: * Time-based: Execute if 24 hours have passed since last harvest * Profit-based: Execute if minting cUSD and buying interest is profitable * Gas Optimization: Only execute when profitable to cover gas costs #### [](https://docs.cap.app/concepts/fee-auction#capnotify) CapNotify `**notify**`: Automates fee distribution to stcUSD holders **Execution Conditions**: * **Vesting Period**: Only execute after lock duration has passed * **Time-based**: Respect profit vesting schedules * **Staked CAP**: Ensure proper distribution to token holders ### [](https://docs.cap.app/concepts/fee-auction#data-structures) Data Structures #### [](https://docs.cap.app/concepts/fee-auction#feeauctionstorage) FeeAuctionStorage The FeeAuctionStorage stores auction configuration and state information. #### [](https://docs.cap.app/concepts/fee-auction#feereceiverstorage) FeeReceiverStorage The FeeReceiverStorage stores fee distribution configuration. [PreviousInterest Rates](https://docs.cap.app/concepts/lender/interest-rates) [NextDelegation](https://docs.cap.app/concepts/delegation) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/fee-auction#mechanics) * [Overview of Operations](https://docs.cap.app/concepts/fee-auction#overview-of-operations) * [Dutch Auction Mechanics](https://docs.cap.app/concepts/fee-auction#dutch-auction-mechanics) * [Key Auction Parameters](https://docs.cap.app/concepts/fee-auction#key-auction-parameters) * [Architecture](https://docs.cap.app/concepts/fee-auction#architecture) * [Fee Auction](https://docs.cap.app/concepts/fee-auction#fee-auction) * [Fee Receiver](https://docs.cap.app/concepts/fee-auction#fee-receiver) * [Gelato Integrations](https://docs.cap.app/concepts/fee-auction#gelato-integrations) * [Data Structures](https://docs.cap.app/concepts/fee-auction#data-structures) Copy function buy( uint256 _maxPrice,address[] calldata _assets, uint256[] calldata _minAmounts, address _receiver, uint256 _deadline ) external; Copy function setStartPrice(uint256 _startPrice) external checkAccess(this.setStartPrice.selector) Copy function setDuration(uint256 _duration) external checkAccess(this.setDuration.selector) Copy function setMinStartPrice(uint256 _minStartPrice) external checkAccess(this.setMinStartPrice.selector) Copy function setPaymentToken(address _paymentToken) external checkAccess(this.setPaymentToken.selector) Copy function distribute() external; Copy function setCapToken(address _capToken) external checkAccess(this.setCapToken.selector) Copy function setStakedCapToken(address _stakedCapToken) external checkAccess(this.setStakedCapToken.selector) Copy function setProtocolFeePercentage(uint256 _protocolFeePercentage) external checkAccess(this.setProtocolFeePercentage.selector) Copy function setProtocolFeeReceiver(address _protocolFeeReceiver) external checkAccess(this.setProtocolFeeReceiver.selector) Copy function harvestInterest() external; Copy function notify() external; Copy struct FeeAuctionStorage { uint256 startPrice; // Starting price for current auction uint256 duration; // Auction duration in seconds uint256 minStartPrice; // Minimum starting price address paymentToken; // Payment token (cUSD) address recipient; // Fee receiver address uint256 auctionStartTime; // Current auction start time uint256 currentPrice; // Current auction price bool auctionActive; // Whether auction is active } Copy struct FeeReceiverStorage { address capToken; // Cap token address address stakedCapToken; // Staked cap token address uint256 protocolFeePercentage; // Protocol fee percentage address protocolFeeReceiver; // Protocol fee recipient uint256 vestingPeriod; // Vesting period in seconds uint256 lastDistributionTime; // Last distribution timestamp uint256 totalFeesDistributed; // Total fees distributed } --- # Privacy Policy | cap **COVERED AGENTS S.A. PRIVACY POLICY** Last Revised: March 26, 2025 Covered Agents S.A., a corporation incorporated under the laws of the Republic of Panama (“Company”) is committed to protecting User’s privacy. Company has prepared this Privacy Policy (this “Policy”) to describe to User Company’s practices regarding the Personal Information (as defined below) Company collects, why Company collects it, and how Company uses and discloses it. This Policy should be read in conjunction with Company’s Terms of Use (the “Terms”), into which this Policy is incorporated by reference. User is encouraged to read the Terms first, as certain terms used in this Policy are defined in the Terms. 1. ACCEPTANCE OF THE POLICY User’s privacy matters to Company, so User should take the time to get to know Company’s policies and practices. Please understand that Company reserves the right to change any of Company’s policies and practices at any time, but User can always find the latest version of this Policy here on this page. User’s continued use of the Platform after Company makes changes is deemed to be acceptance of those changes, so please check this Policy periodically for updates. This Policy describes the types of information Company collects from User or that User may provide when User uses the Platform and Company’s practices for collecting, using, maintaining, protecting, and disclosing that information. Please read this Policy carefully to understand Company’s practices regarding User’s information and how Company will treat it. If User does not agree with Company’s policies and practices, then please do not use the Platform. By using the Platform, User agrees to the terms of this Policy. 2. PERSONAL INFORMATION COMPANY COLLECTS As used herein, “Personal Information” means information that identifies or is reasonably capable of identifying an individual, directly or indirectly, and information that is capable of being associated with an identified or reasonably identifiable individual. 2.1 Personal Information Company Collects from User. Company (or Company’s Affiliates) may collect and store the following categories of Personal Information directly from User: (a) Online identifier information, such as IP address and login information, domain names, and similar identifying names or addresses (collectively, “Online Identifier Information”); (b) Device information, such as hardware, software, operating system, browser, device name, language preferences (collectively, “Device Information”); (c) Usage data, such as system activity, internal and external information related to the Platform, clickstream information (collectively, “Usage Data”); and (d) Geolocation data, such as information about User’s device location (“Geolocation Data”). Automatic collection of Personal Information may involve the use of Cookies, described in greater detail below. Company does not currently store Online Identifier Information, Device Information, Usage Data, or Geolocation Data on Company’s systems; however, please be aware that third-parties with which Company might interact might store such information. 2.2 Personal Information That May Be Collected Automatically. Company (or Company’s Affiliates) may collect and store the following categories of Personal Information automatically through User’s use of the Platform: (a) Online Identifier Information; and (b) Additional information, at Company’s discretion, to comply with legal obligations. 2.3 Personal Information Company Collects from Third Parties. Company (or Company’s Affiliates) may collect and/or verify the following categories of Personal Information about User from third parties: (a) Online Identifier Information; (b) Wallet (as defined in the Terms) information, and information connected to User’s use of the Platform; and (c) Additional information, at Company’s discretion, to comply with legal obligations. 2.4 Accuracy and Retention of Personal Information. Company takes reasonable and practicable steps to ensure that User’s Personal Information held by Company is (i) accurate with regard to the purposes for which it is to be used, and (ii) not kept longer than is necessary for the fulfillment of the purpose for which it is to be used. 3. INTENDED FOR USERS 18+ Company does not knowingly collect data from or market to anyone under 18 years of age. Company does not knowingly solicit data from or market to anyone under 18 years of age. By using the Platform, User represents that User is at least 18 years old, or that User is the parent or guardian of such a minor and consents to such minor dependent’s use of the Platform. If Company learns that Personal Information, from Users less than 18 years of age has been collected, Company will discontinue User’s access to the Platform, to the extent that is possible, and take reasonable measures to promptly delete such data from Company’s records. If User becomes aware of any data Company may have collected from anyone under age 18, please contact Company at [\[email protected\]](https://docs.cap.app/cdn-cgi/l/email-protection) . 4. HOW COMPANY USES USER’S PERSONAL INFORMATION Company collects Personal Information about User in an attempt to provide User with the best experience possible, protect User from risks related to improper use and fraud, and help Company maintain and improve the Platform. Company may use User’s Personal Information to: 4.1 Provide User with the Platform. Company uses User’s Personal Information to provide User with the Platform pursuant to the Terms. 4.2 Comply with Legal and Regulatory Requirements. Company processes User’s Personal Information as required by applicable laws and regulations. 4.3 Detect and Prevent Fraud. Company processes User’s Personal Information to detect and prevent fraud. 4.4 Protect the Security and Integrity of the Platform. Company uses User’s Personal Information to maintain the security of User’s Wallet and the Platform itself. 4.5 Other Business Purposes. Company may use User’s Personal Information for additional purposes if disclosed to User before Company collects User’s Personal Information or if Company obtains User’s consent. 5. HOW COMPANY SHARES USER’S PERSONAL INFORMATION Company will never sell, share, rent, or trade User’s Personal Information with third parties for their commercial purposes. Further, Company will not share User’s Personal Information with third parties, except as described below: 5.1 Third-Party Service Providers. Company may share User’s Personal Information with third-party service providers for business or commercial purposes, including fraud detection and prevention, security threat detection, customer support, data analytics, information technology, advertising and marketing, network infrastructure, storage, and transaction monitoring. Company shares User’s Personal Information with these service providers only so that they can provide Company with their services, and Company prohibits its service providers from using or disclosing User’s Personal Information for any other purpose. 5.2 Law Enforcement. Company may be compelled to share User’s Personal Information with law enforcement, government officials, and/or regulators. 5.3 Corporate Transactions. Company may disclose Personal Information in the event of a proposed or consummated merger, acquisition, reorganization, asset sale, or similar corporate transaction, or in the event of a bankruptcy or dissolution. 5.4 Professional Advisors. Company may share User’s Personal Information with Company’s professional advisors, including legal, accounting, or other consulting services for purposes of audits or to comply with Company’s legal obligations. 5.5 Consent. Company may share User’s Personal Information with User’s consent. If Company decides to modify the purpose for which User’s Personal Information is collected and used, Company will amend this Policy. 6. COOKIES When User accesses the Platform, Company may make use of the standard practice of placing tiny data files called cookies, flash cookies, pixel tags, or other tracking tools (herein, “Cookies”) on User’s computer or other devices used to visit the Platform. Company uses Cookies to help Company recognize User as a customer, collect information about User’s use of the Platform to better customize the Platform and content for User, and collect information about User’s computer or other access devices to: (i) ensure that User’s Account security has not been compromised by detecting irregular, suspicious, or potentially fraudulent activities; and (ii) assess and improve the Platform and advertising campaigns. User can also learn more about Cookies by visiting http://www.allaboutcookies.org, which includes additional useful information on Cookies and how to block Cookies on different types of browsers and mobile devices. Please note that if User rejects Cookies, User will not be able to use some or all of the Service. If User does not consent to the placing of Cookies on User’s device, please do not visit, access, or use the Service. 7. INFORMATION SECURITY No security is foolproof, and the Internet is an insecure medium. Company cannot guarantee absolute security, but Company works hard to protect Company and User from unauthorized access to or unauthorized alteration, disclosure, or destruction of Personal Information Company collects and stores. Measures Company takes include encryption of Company website communications with SSL; periodic review of Company’s Personal Information collection, storage, and processing practices; and restricted access to User’s Personal Information on a need-to-know basis for Company’s employees, contractors and agents who are subject to strict contractual confidentiality obligations and may be disciplined or terminated if they fail to meet these obligations. 8. INFORMATION FOR PERSONS SUBJECT TO EU DATA PROTECTION LAW While customers who are located in the European Union (“EU”), European Economic Area (“EEA”) or the Channel Islands, or other locations subject to EU data protection law (collectively, “Europe”) are customers of Company’s Panamanian entity, Company recognizes and, to the extent applicable to Company, adheres to relevant EU data protection laws. For purposes of this section, “personal data” has the meaning provided in the General Data Protection Regulation (EU) 2016/679 (“GDPR”). 8.1 Lawful Bases for Processing. Company processes personal data subject to GDPR on one or more of the following legal bases: (a) Legal Obligations: to conduct anti-fraud and to fulfill Company’s retention and other legal obligations; (b) Contractual Obligations: to satisfy Company’s obligations to User under the Terms, including to provide User with the Platform and customer support services, and to optimize and enhance the Platform; (c) Legitimate Interest: to monitor the usage of the Platform, conduct automated and manual security checks of the Platform, to protect Company’s rights; and (d) Consent: to market Company and the Platform. User may withdraw User’s consent at any time without affecting the lawfulness of processing based on consent before consent is withdrawn. 8.2 European Privacy Rights. European residents have the following rights under GDPR, subject to certain exceptions provided under the law, with respect to their personal data: (a) Rights to Access and Rectification: User may submit a request that Company disclose the personal data that Company processes about User and correct any inaccurate personal data. (b) Right to Erasure: User may submit a request that Company delete the personal data that Company has about User. (c) Right to Restriction of Processing: User has the right to restrict or object to Company’s processing of User’s personal data under certain circumstances. (d) Right to Data Portability: User has the right to receive the personal data User has provided to Company in an electronic format and to transmit that personal data to another data controller. To submit a request to exercise these rights, please contact Company using the methods described at the end of this Policy. When handling requests to exercise European privacy rights, Company checks the identity of the requesting party to ensure that he or she is the person legally entitled to make such request. This will require User to provide Company with User’s unique Wallet identification. While Company maintains a policy to respond to these requests free of charge, should User’s request be repetitive or unduly onerous, Company reserves the right to charge User a reasonable fee for compliance with User’s request. 9. COLLECTION AND TRANSFER OF DATA OUTSIDE THE EEA The Platform operates with many of Company’s systems based in the United States. As a result, Company may transfer personal data to Europe, the United States, or other third countries, under the following conditions: 9.1 Contractual Obligation. Where transfers are necessary to satisfy Company’s obligation to User under the Terms, including to provide User with the Platform and customer support services, and to optimize and enhance the Platform; and 9.2 Consent. Where User has consented to the transfer of User’s personal data to another country. Where transfers to a third country are based on User’s consent, User may withdraw User’s consent at any time. Please understand, however, that the Platform may not be available if Company is unable to transfer personal data to other countries. When Company transfers personal data to third countries, Company endeavors to ensure adequate safeguards are implemented, for example through the use of standard contractual clauses or Privacy Shield certification. 10. CCPA Pursuant to the California Consumer Privacy Act (the “CCPA”), and in addition to the disclosures elsewhere in this Policy, this section describes the types of Personal Information that Company may have collected, disclosed for business purposes, or sold to third parties in the last 12 months. 10.1 Personal Information Collected. Internet or other electronic network activity information, geolocation information, and inferences drawn from the foregoing. To learn more about the information Company collects, please see “Personal Information Company Collects,” above. The sources of the information are Users of the Platform and Company’s Affiliates. 10.2 Disclosure of Personal Information. In the last 12 months, Company may have disclosed the following categories of Personal Information to Company’s Affiliates or to third-party service providers for business purposes: internet or other electronic network activity information, geolocation information, and inferences drawn from the foregoing. To learn more, please see “How Company Shares User’s Personal Information” above. 10.3 “Sale” of Personal Information. In the last 12 months, Company may have “sold” (as defined in the CCPA) the following categories of Personal Information: internet or other electronic network activity information, geolocation information, and inferences drawn from the foregoing. Company does not have actual knowledge that Company sells Personal Information of consumers under 21 years of age. To learn more, please see “How Company Shares User’s Personal Information” above. 10.4 Explanation of “Sales” under CCPA. Company is not in the business of collecting and selling data, but, in some cases, Company may share information with Company’s Affiliates or third-party service providers in a transaction that constitutes a “sale” of Personal Information under California law. [PreviousPlatform Terms of Use](https://docs.cap.app/resources/terms-and-conditions/platform-terms-of-use) [NextAudits](https://docs.cap.app/resources/audits) Last updated 6 months ago --- # Helpful Links | cap If you have a question that is not covered in our documentation, please post it as a topic on our [community forum](https://capcommunity.discourse.group/c/questions/2) . ### [](https://docs.cap.app/helpful-links#helpful-links) Helpful links Twitter: [https://x.com/capmoney\_](https://x.com/capmoney_) Website: [https://cap.app](https://cap.app/) Media kit: [https://cap.app/media-kit](https://cap.app/media-kit) [PreviousAudits](https://docs.cap.app/resources/audits) Last updated 6 months ago --- # Oracles | cap The Oracle module in CAP is responsible for providing reliable, up-to-date price and rate data to the protocol. It acts as the backbone for all value calculations, including minting, burning, borrowing, and liquidation processes. [](https://docs.cap.app/concepts/oracles#oracle-data-sources) Oracle Data Sources -------------------------------------------------------------------------------------- The protocol leverages multiple oracle sources for different types of data: * [**RedStone Oracles**](https://www.redstone.finance/) : Primary source for reserve asset pricing ([USDC, USDT, pyUSD & cUSD](https://app.redstone.finance/app/feeds/?page=1&sortBy=popularity&sortDesc=false&perPage=32&networks=1) ) * [**Chainlink Oracles**](https://chain.link/) : Used for delegation asset pricing (wstETH, wBTC) on shared security side * [**Cap Token Adapter**](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/oracle/libraries/CapTokenAdapter.sol) : Calculates weighted average of underlying basket for cUSD pricing * [**Staked Cap Adapter**](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/oracle/libraries/StakedCapAdapter.sol) : Accounts for accrued yield and cUSD price for stcUSD pricing * [**Aave Adapter**](https://docs.cap.app/cdn-cgi/l/email-protection#14617a7071727d7a7170) : Fetches current borrow rates from external markets * [**Vault Adapter**](https://docs.cap.app/cdn-cgi/l/email-protection#a7d2c9c3c2c1cec9c2c3) : Calculates utilization-based interest rates [](https://docs.cap.app/concepts/oracles#architecture) Architecture ------------------------------------------------------------------------ The Cap oracle system uses a unified approach where both price and rate oracles are combined into a single [Oracle](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/oracle/Oracle.sol) contract: Copy contract Oracle is IOracle, UUPSUpgradeable, Access, PriceOracle, RateOracle 1. **Oracle Contract** - Main contract combining PriceOracle and RateOracle functionality 2. **PriceOracle Module** - Handles asset price data with dual oracle configuration 3. **RateOracle Module** - Manages interest rate data for lending operations 4. **Modular Adapters** - Pluggable adapters for different data sources 5. **Access Control** - Role-based access control for oracle configuration ### [](https://docs.cap.app/concepts/oracles#price-oracle) Price Oracle The [price oracle](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/oracle/PriceOracle.sol) provides asset price data with the following features: * **Primary and Backup Sources**: Dual oracle configuration for reliability * **Staleness Protection**: Configurable staleness periods for each asset * **Modular Adapters**: Pluggable price source adapters * **Error Handling**: Graceful fallback to backup sources `**getPrice**`: retrieves price, falls back to backup oracle if prices are stale. If both timestamps revert, then relevant protocol functions are disabled until updated. * **Returns**: Current price and last updated timestamp ### [](https://docs.cap.app/concepts/oracles#rate-oracle) Rate Oracle The [rate oracle](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/oracle/RateOracle.sol) provides interest rate data for lending operations: * **Market Rates**: Returns the current borrow rate from external markets (e.g., Aave). Uses the [AaveAdapter](https://github.com/cap-labs-dev/cap-contracts/blob/1064b6a969d55c822dcf0b2c4b733ceb4118737e/contracts/oracle/libraries/AaveAdapter.sol) to fetch and relay the rate * **Utilization Rates**: Returns the interest rate based on asset utilization * **Benchmark Rates**: Returns the Cap’s minimum rate floors, set by admin * **Restaker Rates**: Agent-specific fixed delegation rates #### [](https://docs.cap.app/concepts/oracles#core-functions) Core Functions `**marketRate**`: Fetches current market borrow rate for an asset `**utilizationRate**`: Fetches utilization-based interest rate for an asset `**benchmarkRate**`: Gets the minimum interest rate floor for an asset `**restakerRate**`: Gets the restaker rate for a specific agent **Admin Functions** * `**setPriceOracleData**`: Sets primary oracle data for an asset * `**setPriceBackupOracleData**`: Sets backup oracle data for an asset * `**setStaleness**`: Sets staleness period for asset prices in seconds * `**setMarketOracleData**`: Sets market rate oracle data for an asset * `**setUtilizationOracleData**`: Sets utilization rate oracle data for an asset * `**setBenchmarkRate**`: Sets minimum interest rate floor for an asset * `**setRestakerRate**`: Sets restaker rate for an agent **View Functions** * `**priceOracleData**`: Gets primary oracle data for an asset * `**priceBackupOracleData**`: Gets backup oracle data for an asset * `**staleness**`: Gets staleness period for an asset * `**marketOracleData**`: Gets market rate oracle data for an asset * `**utilizationOracleData**`: Gets utilization rate oracle data for an asset ### [](https://docs.cap.app/concepts/oracles#data-structures) Data Structures #### [](https://docs.cap.app/concepts/oracles#priceoraclestorage) PriceOracleStorage #### [](https://docs.cap.app/concepts/oracles#rateoraclestorage) RateOracleStorage #### [](https://docs.cap.app/concepts/oracles#oracledata) OracleData [PreviousSymbiotic](https://docs.cap.app/concepts/delegation/symbiotic) [NextAccess Controls](https://docs.cap.app/concepts/access-controls) Last updated 2 months ago * [Oracle Data Sources](https://docs.cap.app/concepts/oracles#oracle-data-sources) * [Architecture](https://docs.cap.app/concepts/oracles#architecture) * [Price Oracle](https://docs.cap.app/concepts/oracles#price-oracle) * [Rate Oracle](https://docs.cap.app/concepts/oracles#rate-oracle) * [Data Structures](https://docs.cap.app/concepts/oracles#data-structures) Copy function getPrice(address _asset) external view returns (uint256 price, uint256 lastUpdated) Copy function marketRate(address _asset) external returns (uint256 rate) Copy function utilizationRate(address _asset) external returns (uint256 rate) Copy function benchmarkRate(address _asset) external view returns (uint256 rate) Copy function restakerRate(address _agent) external view returns (uint256 rate) Copy struct PriceOracleStorage { mapping(address => IOracleTypes.OracleData) oracleData; // Primary oracle data per asset mapping(address => IOracleTypes.OracleData) backupOracleData; // Backup oracle data per asset mapping(address => uint256) staleness; // Staleness period per asset } Copy struct RateOracleStorage { mapping(address => IOracleTypes.OracleData) marketOracleData; // Market rate oracle data per asset mapping(address => IOracleTypes.OracleData) utilizationOracleData; // Utilization rate oracle data per asset mapping(address => uint256) benchmarkRate; // Benchmark rate per asset mapping(address => uint256) restakerRate; // Restaker rate per agent } Copy struct OracleData { address adapter; // Adapter contract address for calculation logic bytes payload; // Encoded call to adapter with all required data } --- # Platform Terms of Use | cap **COVERED AGRENTS S.A. PLATFORM TERMS OF USE** Last Revised: March 26, 2025 The website located at cap.app is published, owned, and operated by Covered Agents S.A., a corporation incorporated under the laws of the Republic of Panama (“Company”), its Affiliates, and related entities. These Platform Terms of Use (the “Terms,” or “Agreement”) govern the user’s (“User”) access to and use of the Platform’s (as defined below) front-end, whether accessed via computer, mobile device, or otherwise (individually and collectively, the “Website”), as well as any products and services provided by Company (the “CAP Services”) (the Website, together with the CAP Services, collectively referred to as the “Service”). 1. ACCEPTANCE OF AGREEMENT THESE TERMS SET FORTH THE LEGALLY BINDING TERMS AND CONDITIONS THAT GOVERN USER’S USE OF THE SERVICE AND ALL RELATED TOOLS, MOBILE APPLICATIONS, WEB APPLICATIONS, DECENTRALIZED APPLICATIONS, SMART CONTRACTS, AND APPLICATION PROGRAMMING INTERFACES (“APIS”) LOCATED AT ANY COMPANY WEBSITE INCLUDING WITHOUT LIMITATION, SUCCESSOR WEBSITE(S) OR APPLICATION(S) THERETO (COLLECTIVELY, THE “PLATFORM”). THESE TERMS SET OUT USER’S RIGHTS AND RESPONSIBILITIES WITH RESPECT TO USER’S USE OF THE PLATFORM FOR ANY PURPOSE, INCLUDING BUT NOT LIMITED TO DEPOSITING VARIOUS DIGITAL ASSETS AS COLLATERAL INTO THE PLATFORM’S SMART CONTRACTS, ENABLING THEM TO MINT cUSD, PROVIDE LIQUIDITY, OR GENERATE YIELD. BY USING THE SERVICE OR ACCESSING THE PLATFORM IN ANY MANNER, USER ACCEPTS AND AGREES TO BE BOUND AND ABIDE BY THESE TERMS AND ALL OF THE TERMS INCORPORATED HEREIN BY REFERENCE. BY AGREEING TO THESE TERMS, USER HEREBY CERTIFIES THAT USER IS AT LEAST 18 YEARS OF AGE. IF USER DOES NOT AGREE TO THESE TERMS, USER MAY NOT ACCESS OR USE THE WEBSITE OR THE PLATFORM. PLEASE BE AWARE THAT THESE TERMS REQUIRE THE USE OF ARBITRATION (SECTION 14.5) ON AN INDIVIDUAL BASIS TO RESOLVE DISPUTES, RATHER THAN JURY TRIALS OR CLASS ACTIONS, AND LIMIT THE REMEDIES AVAILABLE TO USER IN THE EVENT OF A DISPUTE. By accessing, browsing, submitting information to, and/or using the Platform, User accepts and agrees to be bound and abide by these Terms and Company’s Privacy Policy, incorporated herein by reference, and to comply with all applicable laws, including, without limitation, all federal, state and local tax and tariff laws, regulations, and/or directives. Accordingly, under Article 6 of the General Data Protection Regulation, or “GDPR,” Users in the European Union acknowledge and consent to Company’s processing of personal data as necessary for the performance of these Terms, any applicable agreements, and use of the Website. If User does not agree to the Terms, please do not use the Platform. 2. AMENDMENTS Company reserves the right to amend this Agreement and/or Company’s Privacy Policy described in Section 4 below, at any time with or without notice, as determined by Company in its sole discretion. Company will post any amendment on the Website. User should check this Agreement and Company’s Privacy Policy regularly for updates. By continuing to use the Platform, the Website, or the Service after such amendment is made, User accepts and agrees to such amendment. If User does not agree to any amendment to any of these agreements, User must stop using the Platform, the Website, and the Service. If User has any questions about the terms and conditions in this Agreement or Company’s Privacy Policy, please contact Company at [\[email protected\]](https://docs.cap.app/cdn-cgi/l/email-protection) . 3. DEFINITIONS AND INTERPRETATION 3.1 Defined Terms. Capitalized terms not otherwise defined in these Terms will have the following meanings: (a) “Affiliate” means, with respect to a party, any person, firm, corporation, partnership (including, without limitation, general partnerships, limited partnerships, and limited liability partnerships), limited liability company, or other entity that now or in the future, directly controls, is controlled with or by or is under common control with such party. (b) “Applicable Law” means all laws, statutes, rules, regulations, ordinances, and other pronouncements having the effect of law of any Governmental Authority, including the Republic of Panama. (c) “Blockchain” generally means a peer-to-peer distributed and public immutable ledger that maintains a record of all transactions occurring on such ledger, through a growing list of records (blocks) that are securely linked together via cryptographic hashes. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. (d) “Business Day” means any day (other than a Saturday, Sunday, or legal holiday) on which financial institutions in the Commonwealth of Virginia are authorized or obligated to close. (e) “CAP Ecosystem” means all the projects and functionalities listed at cap.app including without limitation any transactions, communications, and collaborations with other established projects. (f) “Governmental Authority” means any court, tribunal, arbitrator, authority, agency, commission, official, or other instrumentality of the United States or any state, county, city, or other political subdivision or similar governing entity. (g) “Smart Contract” means a program hosted on a Blockchain, consisting of code specifying predetermined conditions that, when met, trigger self-executing outcomes. (h) “Wallet” means a secure digital wallet, created through a combination of private and public cryptographic keys, that enables users to interact with, and transact on, blockchain networks including but not limited to cryptographically signing smart contracts, and sending, receiving, and monitoring cryptocurrencies and other digital tokens. 4. PRIVACY By using the Platform, Website, or Service, User agrees to, and is bound by, the terms of Company’s Privacy Policy, which is incorporated by reference into this Agreement as if it were set forth herein in its entirety. The Privacy Policy describes how Company collects, uses, and discloses information provided by User. 5. COMMUNICATION WITH USERS User affirms that it is aware of and acknowledges that Company is a Blockchain service provider and has designed the Platform to be directly accessible by Users without any involvement or actions taken by Company or any third-party. 6. THIRD-PARTY LINKS, PRODUCTS, AND APPLICATIONS 6.1 Third-Party Sites. The Website may contain links to websites controlled or operated by persons and companies other than Company (“Linked Sites”), including but not limited to any sites related to digital transactions occasionally hyperlinked, such as X, Discord, Discourse, Gitbook, and Telegram, and websites referencing or supporting Blockchain Technology projects, marketplaces, and trading platforms. Linked Sites are not under the control of Company, and Company is not responsible for the contents of any Linked Site, including without limitation any link contained on a Linked Site, or any changes or updates to a Linked Site. Company is not responsible if the Linked Site is not working correctly or for any viruses, malware, or other harms resulting from User’s use of a Linked Site. Company is providing these links to User only as a convenience, and the inclusion of any link does not imply endorsement by Company of the site or any association with its operators. User is responsible for viewing and abiding by the privacy policies and terms of use posted on the Linked Sites. User is solely responsible for any dealings with third parties who support Company or are identified on the Website, including any delivery of and payment for goods and services. Company does not store any information shared with a Linked Site and is not responsible for any personally identifiable information shared with any Linked Site. 6.2 Third-Party Smart Contracts. User acknowledges and understands that Company uses certain third-party Smart Contracts that it has no ownership of, or control over, which are core components of the Platform. Company is not responsible for any coding errors, glitches, or any functionality, or lack thereof, of such third-party Smart Contracts. 6.3 Release. To the fullest extent permitted by law, User hereby releases and forever discharges Company (and its Affiliates, officers, employees, agents, successors, and assigns) from, and hereby waives and relinquishes, each and every past, present, and future dispute, claim, controversy, demand, right, obligation, liability, action and cause of action of every kind and nature (including personal injuries, death, and property damage), that has arisen or arises directly or indirectly out of, or that relates directly or indirectly to, the Platform (including any interactions with, or act or omission of, Company’s partners or any other third-party or any Linked Sites). IF USER IS A CALIFORNIA RESIDENT, USER HEREBY WAIVES CALIFORNIA CIVIL CODE SECTION 1542 IN CONNECTION WITH THE FOREGOING, WHICH STATES: “A GENERAL RELEASE DOES NOT EXTEND TO CLAIMS WHICH THE CREDITOR DOES NOT KNOW OR SUSPECT TO EXIST IN HIS OR HER FAVOR AT THE TIME OF EXECUTING THE RELEASE, WHICH IF KNOWN BY HIM OR HER MUST HAVE MATERIALLY AFFECTED HIS OR HER SETTLEMENT WITH THE DEBTOR.” 7. THE PLATFORM 7.1 Purpose of the Platform and Website. The Platform is a fully decentralized lending protocol. The Platform allows Users to mint cUSD by staking USDC or USDT. Similarly, the Platform can provide liquidity to Users by allowing Users to borrow from the collateral pool. Stakers and restakers can earn yield by providing collateral to the Platform’s pools. The Website is provided for Users to access the Platform, use the Service, and to provide updates about the CAP Ecosystem to Users. 7.2 Website Content. Company does not warrant the accuracy, completeness, or usefulness of this information at any particular time for any particular purpose. Any reliance User places on such information is strictly at User’s own risk. Company disclaims all liability and responsibility arising from any reliance placed on such content by User, or by anyone who may be informed of any of its contents. 7.3 Use of the Website, Platform and Service; Licenses. Subject to this Agreement, Company grants User a limited, revocable, non-exclusive, non-transferable, non-sublicensable license to access and use the Platform, including the Website and the data, material, content, or information herein (collectively, the “Content”) solely for User’s personal use. User’s right to access and use the same shall be limited to the purposes described in these Terms unless User is otherwise expressly authorized by Company, in writing, to use the Platform for User’s own commercial purposes. User agrees to use the Platform only for lawful purposes, comply with all rules governing any transactions on and through the Platform and comply with the law. Any rights not expressly granted herein are reserved, and no license or right to use any trademark of Company or any third-party is granted to User. 7.4 Additional Considerations (a) Transactions Are Recorded on Public Blockchains. The transactions that take place on the Platform are managed and confirmed via public Blockchains. User understands that its Wallet address will be made publicly visible whenever it engages in a transaction on the Platform. Company does not own or control any Blockchain that Company chooses to interface with, or any other third-party site, product, or service that User might access, visit, or use for the purpose of enabling User to access and utilize the various features of the Platform. Company is not liable for the acts or omissions of any such third parties, and will not be liable for any damage that a User may suffer as a result of its transactions or any other interaction with any such third parties. (b) Gas. All transactions on the Platform are facilitated by Smart Contracts. Public Blockchains require the payment of a transaction fee (a “Gas Fee”) for every transaction that occurs on its network, and thus every transaction occurring on the Platform. The value of the Gas Fee changes, often unpredictably, and is entirely outside of the control of Company or the Platform. User acknowledges that under no circumstances will a transaction on the Platform be invalidated, revocable, retractable, or otherwise unenforceable on the basis that the Gas Fee for the given transaction was unknown, too high, or otherwise unacceptable to User. 7.5 Prohibitions and Restrictions (a) Prohibited Uses. User agrees that it will not: (i) Use the Platform or the Service in any manner that could damage, disable, overburden, or impair the Website or the Platform or interfere with any other party’s use and enjoyment of the same; (ii) Attempt to gain unauthorized access to any website or platform, computer systems, or networks associated with Company, the Platform, or the Website; (iii) Obtain or attempt to obtain any materials or information through the Website by any means not intentionally made available or provided by Company; (iv) Use any robot, spider, or other automatic device, process or means to access the Website for any purpose, including monitoring or copying any of the material on the Website; (v) Introduce any viruses, Trojan horses, worms, logic bombs, or other material which is malicious or technologically harmful; (vi) Send unsolicited messages or use the Website to send unsolicited messages such as spam; (vii) Perform any benchmark tests or analyses related to the Website or the Platform without express written permission of Company; (viii) Send spam or engage in phishing. Spam is unwanted or unsolicited bulk email, postings, contact requests, or similar electronic communications. Phishing is sending emails or other electronic communications to fraudulently or unlawfully induce recipients to reveal personal or sensitive information, such as passwords, dates of birth, Social Security numbers, passport numbers, credit card information, financial information, or other sensitive information, or to gain access to Wallets or records, exfiltration of documents or other sensitive information, payment and/or financial benefit; (ix) Attack the Website or the Platform via a denial-of-service attack or a distributed denial-of-service attack; (x) Impersonate or attempt to impersonate Company, a Company employee, another User or any other person or entity (including, without limitation, by using email addresses associated with any of the foregoing); (xi) License, sell, rent, lease, transfer, assign, distribute, host, or otherwise commercially exploit the Service, whether in whole or in part, or any Content displayed on the Service except as permitted herein; (xii) Modify, make derivative works of, disassemble, reverse compile or reverse engineer any part of the Service or the Platform; or (xiii) Access the Platform in order to build a similar or competitive website, product, or service. (b) Restrictions. Except as expressly stated herein, no part of the Platform may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means. Unless otherwise indicated, any future release, update, or other addition to functionality of the Platform will be subject to this Agreement. All copyright and other proprietary notices related to the Platform (including on any Content displayed on the Website) must be retained on all copies thereof. User will not use the Website or Platform for any illegal purpose. 7.6 Modification. Company reserves the right, at any time, to modify, suspend, or discontinue the Platform (in whole or in part) with or without notice to Users. User agrees that Company will not be liable to User or to any third-party for any modification, suspension, or discontinuation of the Platform or any part thereof. 7.7 Affiliates. The rights, duties and/or obligations of Company under this Agreement may be exercised and/or performed by Company and/or any of Company’s Affiliates, or any of their subcontractors and/or agents. User agrees that any claim or action arising out of or related to any act or omission of any of Company or its Affiliates, or any of their respective subcontractors or agents, related to the subject matter hereof, shall only be brought against Company, and not against any of Company’s Affiliates, licensors, or any subcontractor or agent of Company or any its Affiliates. 8. INTELLECTUAL PROPERTY 8.1 Company Intellectual Property. The contents of the Platform, including the Website, are intended for User’s personal, noncommercial use. User acknowledges and agrees that Company (or, as applicable, Company’s licensors) owns all legal right, title, and interest in and to all elements of the Platform, Company’s logo, graphics, design, systems, methods, information, computer code, software, services, “look and feel,” organization, compilation of the content, code, data, and all other elements of the Platform (collectively, the “Company Materials”). The Website, Platform, Company Materials, and Content are protected by copyrights, trademarks, trade secrets, database rights, sui generis rights and other intellectual or proprietary rights therein pursuant to U.S. and international laws. Accordingly, User is not permitted to use the Website or Content in any manner, except as expressly permitted by Company in these Terms. The Website or Content may not be copied, reproduced, modified, published, uploaded, posted, transmitted, performed, or distributed in any way, and User agrees not to modify, rent, lease, loan, sell, distribute, transmit, broadcast, or create derivatives without the express written consent of Company. Except as expressly set forth herein, User’s use of the Platform does not grant User ownership of or any other rights with respect to any Content, code, data, or other materials that User may access on or through the Platform. Company reserves all rights in and to Company Materials not expressly granted to Users in the Terms. User may not use any of Company’s Content to link to the Website or Content without Company’s express written consent. User may not use framing techniques to enclose any such Content without Company’s express written consent. In addition, the “look and feel” of the Website and Content, including without limitation, all page headers, custom graphics, button icons, and scripts constitute the service mark, trademark, or trade dress of Company and may not be copied, imitated, or used, in whole or in part, without Company’s prior written consent. 8.2 Non-Company Intellectual Property. Excluding Company Materials, all other trademarks, product names, logos, and similar intellectual property on the Platform are the property of their respective owners and may not be copied, imitated, or used, in whole or in part, without the permission of the applicable owner. 8.3 Aggregate Data. Company shall have the right to collect and analyze data and other information relating to provision and use of various aspects of the Platform. Company will be free to (i) use the data to improve and enhance the Service and for other development, diagnostic, and corrective purposes in connection with the Platform and (ii) disclose data solely in aggregate or other de-identified form in connection with its business. 9. INDEMNIFICATION User agrees to release, indemnify, and hold harmless Company and its Affiliates, and their respective officers, directors, employees and agents, from and against any claims, liabilities, damages, losses, and expenses, including, without limitation, reasonable legal and accounting fees, arising out of or in any way related to: (a) User’s access to, use of, or inability to use the Platform, the Website, or Service; (b) User’s breach of this Agreement; (c) User’s violation of any rights of a third party; (d) User’s violation of any Applicable Law; and (e) any and all financial losses User may suffer, or cause others to suffer, due to utilizing, transferring, staking, or re-staking cryptocurrency, or any other digital assets. 10. ASSUMPTION OF RISK 10.1 User Acknowledges the Risk of Cryptocurrency and Smart Contracts. USER REPRESENTS AND WARRANTS THAT IT UNDERSTANDS AND IS WILLING TO ACCEPT THE RISKS ASSOCIATED WITH CRYPTOGRAPHIC SYSTEMS SUCH AS SMART CONTRACTS, THRID PARTY BRIDGES, PUBLIC BLOCKCHAINS (INCLUDING, BUT NOT LIMITED TO, THE ETHEREUM BLOCKCHAIN), LIQUIDITY PROTOCOLS, AND THE INTERPLANETARY FILE SYSTEM. 10.2 Company is Not Responsible for Technical Errors on Any Blockchain. COMPANY IS NOT RESPONSIBLE FOR LOSSES ARISING FROM THE USE OF BLOCKCHAINS OR ANY OTHER FEATURES OF ANY BLOCKCHAIN NETWORK OR WALLET THAT COMPANY OR USER MAY INTERFACE WITH, INCLUDING, BUT NOT LIMITED TO, LATE REPORT BY DEVELOPERS OR REPRESENTATIVES (OR NO REPORT AT ALL) OF ANY ISSUES WITH A BLOCKCHAIN NETWORK OR ANY ASSOCIATED LAYER 2 BLOCKCHAINS THAT COMPANY OR USER MAY INTERFACE WITH, INCLUDING FORKS, TECHNICAL NODE ISSUES, OR ANY OTHER ISSUES RESULTING IN LOSS OF FUNDS. 10.3 User Acknowledges the Risks of the Platform. User acknowledges that the Platform is subject to flaws and that User is solely responsible for evaluating any information provided by the Platform. This warning and others provided in this Agreement by Company in no way evidence or represent an ongoing duty to alert User to all of the potential risks of utilizing or accessing the Platform. The Platform may experience sophisticated cyber-attacks, cryptocurrency based economic exploits, unexpected surges in activity, or other operational or technical difficulties that may cause interruptions to or delays on the Platform. The Platform utilizes shared security marketplaces like EigenLayer, accordingly, the User may be exposed to the risks associated with such platforms. User agrees to accept the risk of the Platform failure resulting from unanticipated or heightened technical difficulties, including those resulting from sophisticated attacks, and User agrees that it will not hold Company accountable for any related losses. Company will not bear any liability, whatsoever, for any damage or interruptions caused by any viruses that may affect User’s computer or other equipment, or any phishing, spoofing or other attack. 10.4 Company Does Not Make Any Representations Regarding the Value of Cryptocurrency or Other Digital Assets. The prices of blockchain assets, including USDT and USDC, are extremely volatile. Fluctuations in the price of other digital assets could materially and adversely affect the value of cryptocurrency, which may also be subject to significant price volatility. A lack of use or public interest in the creation and development of distributed ecosystems could negatively impact the development, potential utility, or value of cryptocurrency. The CAP Ecosystem and other digital assets could be impacted by one or more regulatory inquiries or regulatory actions. For all of the foregoing reasons, as well as for reasons that may not presently be known to Company, Company makes absolutely no representations or warranties of any kind regarding the value of cryptocurrency or other digital assets. 10.5 User Acknowledges Financial Risk of Digital Assets. The risk of loss associated with the use of digital assets can be substantial. User should, therefore, carefully consider whether creating, buying, selling, or otherwise using digital assets is suitable for User in light of its circumstances and financial resources. By using the Platform, accessing the Website, and/or purchasing cryptocurrency, User represents that it has been, is and will be solely responsible for making its own independent appraisal and investigations into the risks of a given transaction and the underlying digital assets. User represents that it has sufficient knowledge, market sophistication, professional advice, and experience to make its own evaluation of the merits and risks of any transaction conducted via any digital asset. Under no circumstances will the operation of all or any portion of the Platform be deemed to create a relationship that includes the provision or tendering of investment advice. 10.6 Company is Not Responsible for Losses Due to Jurisdictional Blocks. User acknowledges that Company has no control over jurisdictional blocks which may prevent User from utilizing the Website. Under no circumstances will Company be liable for User’s inability to access the Website due to a jurisdictional block. 10.7 Violations by Other Users. User irrevocably releases, acquits, and forever discharges Company and its subsidiaries, Affiliates, officers, and successors for and against any and all past or future causes of action, suits, or controversies arising out of another User’s violation of these Terms. 11. LIMITATION OF LIABILITY AND WARRANTY DISCLAIMER 11.1 Limitation of Liability. TO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT WILL COMPANY (OR COMPANY’S AFFILIATES) BE LIABLE TO USER OR ANY THIRD-PARTY FOR ANY FINANCIAL LOSS, LOST PROFITS, LOST DATA, COSTS OF PROCUREMENT OF SUBSTITUTE PRODUCTS, OR ANY INDIRECT, CONSEQUENTIAL, EXEMPLARY, INCIDENTAL, SPECIAL OR PUNITIVE DAMAGES ARISING FROM OR RELATING TO THESE TERMS OR USER’S USE OF, OR INABILITY TO USE, THE PLATFORM, THE WEBSITE OR THE SERVICE, CONTENT OR INFORMATION ACCESSED VIA THE WEBSITE OR ANY HYPERLINKED WEBSITE, OR ANY DISRUPTION OR DELAY IN THE PERFORMANCE OF THE WEBSITE, THE PLATFORM, OR THE SERVICE EVEN IF COMPANY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ACCESS TO, AND USE OF, THE PLATFORM IS AT USER’S OWN DISCRETION AND RISK, AND USER WILL BE SOLELY RESPONSIBLE FOR ANY MONETARY LOSS AND/OR DAMAGE TO ITS DEVICE OR COMPUTER SYSTEM, OR LOSS OF DATA RESULTING THEREFROM. SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT APPLY TO USER. 11.2 No Warranties. ALL INFORMATION OR SERVICE PROVIDED BY COMPANY TO USER VIA THE WEBSITE AND THE PLATFORM, INCLUDING, WITHOUT LIMITATION, ALL CONTENT, IS PROVIDED “AS IS” AND “WHERE IS” AND WITHOUT ANY WARRANTIES OF ANY KIND. COMPANY AND ANY THIRD-PARTY LICENSORS WITH CONTENT ON THE WEBSITE EXPRESSLY DISCLAIM ALL WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT. NOTWITHSTANDING ANY PROVISION CONTAINED HEREIN TO THE CONTRARY, COMPANY AND AFFILIATES MAKE NO REPRESENTATION, WARRANTY OR COVENANT CONCERNING THE ACCURACY, QUALITY, SUITABILITY, COMPLETENESS, SEQUENCE, TIMELINESS, SECURITY OR AVAILABILITY OF THE WEBSITE, THE PLATFORM OR ANY CONTENT POSTED ON OR OTHERWISE ACCESSIBLE VIA THE PLATFORM OR THE WEBSITE. USER SPECIFICALLY ACKNOWLEDGES THAT COMPANY AND AFFILIATES ARE NOT LIABLE FOR ANY DEFAMATORY, OBSCENE OR UNLAWFUL CONDUCT OF THIRD-PARTIES OR USERS OF THE WEBSITE OR THE PLATFORM AND THAT THE RISK OF INJURY FROM THE FOREGOING RESTS ENTIRELY WITH USER. NEITHER COMPANY NOR ANY OF ITS AFFILIATES REPRESENT, WARRANT, OR COVENANT THAT THE WEBSITE AND/OR THE PLATFORM WILL BE SECURE, UNINTERRUPTED OR ERROR-FREE. COMPANY FURTHER MAKES NO WARRANTY THAT THE WEBSITE WILL BE FREE OF VIRUSES, WORMS, OR TROJAN HORSES OR THAT IT WILL FUNCTION OR OPERATE IN CONJUNCTION WITH ANY OTHER PRODUCT OR SOFTWARE. USER EXPRESSLY AGREES THAT USE OF THE PLATFORM IS AT USER’S SOLE RISK AND THAT COMPANY, ITS AFFILIATES AND THEIR THIRD-PARTY LICENSORS SHALL NOT BE RESPONSIBLE FOR ANY TERMINATION, INTERRUPTION OF SERVICE, DELAYS, ERRORS, FAILURES OF PERFORMANCE, DEFECTS, OR OMISSIONS ASSOCIATED WITH THE WEBSITE AND/OR THE PLATFORM OR USER’S USE THEREOF. USER’S SOLE REMEDY AGAINST COMPANY FOR DISSATISFACTION WITH THE WEBSITE, THE PLATFORM, OR THE CONTENT IS TO CEASE ITS USE OF THE PLATFORM AND THE WEBSITE. SOME JURISDICTIONS DO NOT PERMIT THE EXCLUSION OR LIMITATION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO USER. USER MAY HAVE OTHER RIGHTS, WHICH VARY BY JURISDICTION. WHEN THE IMPLIED WARRANTIES ARE NOT ALLOWED TO BE EXCLUDED IN THEIR ENTIRETY, USER AGREES THAT THEY WILL BE LIMITED TO THE GREATEST EXTENT AND SHORTEST DURATION PERMITTED BY LAW. 12. TERM AND TERMINATION This Agreement will remain in full force and effect while User uses the Platform, the Website, or the Service (the “Term”). Company may suspend or terminate User’s rights to use the Platform, the Website, or the Service at any time for any reason at Company’s sole discretion, including for any use of the Website, the Platform, or the Service in violation of this Agreement. User may terminate this Agreement at any time by ending User’s use of the Platform and notifying Company at [\[email protected\]](https://docs.cap.app/cdn-cgi/l/email-protection) . Such notice to Company must include User’s Wallet address(es). Upon termination of User’s rights under this Agreement, User’s right to access and use the Platform will terminate immediately. Company will not have any liability whatsoever to User for any termination of User’s rights under this Agreement. All provisions of the Agreement which by their nature should survive, shall survive termination of Service, including without limitation, ownership provisions, warranty disclaimers, and limitation of liability. 13. GENERAL TERMS 13.1 General Terms. These Terms, together with the Privacy Policy and any other agreements expressly incorporated by reference into these Terms, are the entire and exclusive understanding and agreement between User and Company regarding User’s use of the Service. User may not assign or transfer these Terms or its rights under these Terms, in whole or in part, by operation of law or otherwise, without Company’s prior written consent. Company may assign these Terms at any time without notice or consent. The failure to require performance of any provision will not affect Company’s right to require performance at any other time after that, nor will a waiver by Company of any breach or default of these Terms, or any provision of these Terms, be a waiver of any subsequent breach or default or a waiver of the provision itself. Use of section headers in these Terms is for convenience only and will not have any impact on the interpretation of any provision. Throughout these Terms the use of the word “including” means “including but not limited to”. If any part of these Terms is held to be invalid or unenforceable, the unenforceable part will be given effect to the greatest extent possible, and the remaining parts will remain in full force and effect. 13.2 Electronic Communications. By using the Website, the Platform, or the Service, User consents to receiving certain electronic communications from Company as further described in the Privacy Policy. Please read the Privacy Policy to learn more about Company’s electronic communications practices. User agrees that any notices, agreements, disclosures, or other communications that Company sends to User electronically will satisfy any legal communication requirements. Any electronic communications will be deemed to have been received by User immediately after Company posts the same to the Website, whether or not User has received or retrieved the communication from Company. User agrees that these are reasonable procedures for sending and receiving electronic communications. If User wish to withdraw User’s consent to receive Communications electronically, User must discontinue use of the Platform. Company reserves the right, in its sole discretion, to discontinue the provision of electronic communications, or to terminate or change the terms and conditions on which Company provides electronic communications. Company will provide User with notice of any such termination or change as required by Applicable Law. 13.3 Changes to these Terms of Use. Company may update or change these Terms from time to time in order to reflect changes in any offered services, changes in the law, or for other reasons as deemed necessary by Company. The effective date of any Terms will be reflected in the “Last Revised” entry at the top of these Terms. User’s continued use of the Website after any such change is communicated shall constitute User’s consent to such change(s). 13.4 Governing Law & Jurisdiction. These Terms are governed by the laws of the Republic of Panama, without regard to its conflict of law principles. User hereby irrevocably consents to the exclusive jurisdiction and venue of the competent courts of the Republic of Panama for all disputes arising out of or relating to the use of the Platform, the Website, or the Service not subject to the Arbitration Agreement outlined in Section 14.5. 13.5 Dispute Resolution (a) Arbitration Agreement Generally. Please read the following arbitration agreement (“Arbitration Agreement”) carefully. It limits the manner in which User may seek relief from Company, is part of User’s contract with Company, and contains provisions concerning MANDATORY BINDING ARBITRATION AND WAIVER OF THE RIGHT TO A TRIAL BY JURY OR TO PARTICIPATE IN A CLASS ACTION. (b) Exceptions. Nothing in these Terms will be deemed to waive, preclude, or otherwise limit the right of either party to seek injunctive relief in a court of law in aid of arbitration or to file suit in a court of law to address an intellectual property infringement claim. (c) Applicability of Arbitration Agreement. In the interest of resolving disputes between Company and User in the most expedient and cost-effective manner, and except as set forth in Section 14.5(b), User and Company agree that every dispute arising in connection with these Terms that cannot be resolved informally, whether based in contract, tort, statute, fraud, misrepresentation, or any other legal theory, including any unresolved dispute, claim, interpretation, controversy, or issues of public policy arising out of or relating to the Website, the Platform, the Service, these Terms, and the determination of the scope or applicability of this Section 14.5 will be resolved by binding arbitration on an individual basis under the terms of this Arbitration Agreement. Unless otherwise agreed to, all arbitration proceedings shall be held in English. This Arbitration Agreement applies to User and Company, and to any subsidiaries, Affiliates, agents, employees, predecessors in interest, successors, and assigns, as well as all authorized or unauthorized users or beneficiaries of services or goods provided under the Agreement. This Arbitration Agreement shall apply, without limitation, to all disputes or claims and requests for relief that arose or were asserted before the effective date of this Agreement or any prior version of this Agreement. (d) Arbitration Rules. Arbitration will be conducted and administered by the Center for Conciliation and Arbitration of the Chamber of Commerce, Industries, and Agriculture of Panama (“CeCAP”) and its dispute resolution rules (“CeCAP Rules”), as modified by these Terms. The CeCAP rules are available online at https://cecap.com.pa/en/reglamento-de-cecap/, or by contacting Company. A single arbitrator will be appointed unless otherwise required by the CeCAP rules. (e) Notice Requirement and Informal Dispute Resolution. Before either party may seek arbitration, the party must first send to the other party a written Notice of Dispute (“Notice”) describing the nature and basis of the claim or dispute, and the specific relief requested. A Notice to Company should be sent by certified U.S. Mail or by Federal Express (signature required) to: Covered Agents S.A. c/o Pacifica Legal Boulevard Costa del Este, PH Financial Park Tower, Piso 17 OV320 Ciudad de Panamá Panamá Company may send User a Notice by electronic mail if User has provided Company with such an address. Company may also provide Notice to User’s Wallet by sending an NFT to User’s Wallet. After the Notice is received, User and Company may attempt to resolve the claim or dispute informally. If User and Company do not resolve the claim or dispute within thirty (30) days after the Notice is received, either party may begin an arbitration proceeding. All arbitration proceedings between the parties will be confidential unless otherwise agreed by the parties in writing. (f) Fees; Location. Each party shall be responsible for the payment of its own fees and costs associated with an arbitration, except as otherwise required by the CeCAP Rules. Any arbitration hearing will take place in Panama City, Panama, or another location mutually agreed upon by the parties; provided, however, notwithstanding the foregoing, the parties shall endeavor, where possible, to cause the arbitration proceeding to be conducted: (i) solely on the basis of documents submitted to the arbitrator; or (ii) through a non-appearance-based telephone hearing or videoconference. If the arbitrator finds that either the substance of User’s claim or the relief sought in User’s arbitration demand is frivolous or brought for an improper purpose, in the arbitrator’s reasonable discretion, then the payment of all arbitration fees will be governed by the CeCAP Rules. In that case, User agrees to reimburse Company for all monies previously disbursed by Company that are otherwise User’s obligation to pay under the CeCAP Rules. Regardless of the manner in which the arbitration is conducted, the arbitrator must issue a reasoned written decision sufficient to explain the essential findings and conclusions on which the decision and award, if any, are based. Notwithstanding anything herein to the contrary, each party will be responsible for their own attorneys’ fees associated with an arbitration under these Terms, and in no event may the arbitrator award any party their attorneys’ fees. (g) Enforcement. The parties irrevocably submit to the exclusive jurisdiction of any court of competent jurisdiction with respect to this section to compel arbitration, to confirm an arbitration award or order, or to handle court functions permitted under the CeCAP Rules. The parties irrevocably waive defense of an inconvenient forum to the maintenance of any such action or other proceeding. The parties may seek recognition and enforcement of any court judgment confirming an arbitration award or order in any court having jurisdiction with respect to recognition or enforcement of such judgment. (h) Waiver of Jury Trial. THE PARTIES HEREBY WAIVE THEIR CONSTITUTIONAL AND STATUTORY RIGHTS TO GO TO COURT AND HAVE A TRIAL IN FRONT OF A JUDGE OR A JURY, instead electing that all claims and disputes shall be resolved by arbitration under this Arbitration Agreement. Arbitration procedures are typically more limited, more efficient and less costly than rules applicable in a court and are subject to very limited review by a court. In the event any litigation should arise between User and Company in any state or federal court in a suit to vacate or enforce an arbitration award or otherwise, USER AND COMPANY WAIVE ALL RIGHTS TO A JURY TRIAL, instead electing that the dispute be resolved by a judge. (i) Waiver of Class or Consolidated Actions. ALL CLAIMS AND DISPUTES WITHIN THE SCOPE OF THIS AGREEMENT, INCLUDING THE ARBITRATION AGREEMENT MUST BE ARBITRATED OR LITIGATED ON AN INDIVIDUAL BASIS AND NOT ON A CLASS BASIS, AND CLAIMS OF MORE THAN ONE CUSTOMER OR USER CANNOT BE ARBITRATED OR LITIGATED JOINTLY OR CONSOLIDATED WITH THOSE OF ANY OTHER CUSTOMER OR USER. (j) Severability. If any part or parts of this Arbitration Agreement are found under the law to be invalid or unenforceable by a court of competent jurisdiction, then such specific part or parts shall be of no force and effect and shall be severed and the remainder of the Arbitration Agreement shall continue in full force and effect. (k) Right to Waive. Any or all of the rights and limitations set forth in this Arbitration Agreement may be waived by the party against whom the claim is asserted. Such waiver shall not waive or affect any other portion of this Arbitration Agreement. 13.6 Attorneys’ Fees and Costs. In the event a party files an action in a court of competent jurisdiction pursuant to Section 14.5(b), the party found to be the substantially losing party in any dispute shall be required to pay the reasonable attorneys’ fees and costs of any party determined to be the substantially prevailing party. In the context of this Agreement, reasonable attorneys’ fees and costs shall include but not be limited to legal fees and costs, the fees and costs of witnesses, accountants, experts, and other professionals, and any other forum costs incurred during, or in preparation for, a dispute. It is understood that certain time entries that may appear in the billing records of such party’s legal counsel may be redacted to protect attorney-client or work-product privilege, and this will not prevent recovery for the associated billings. 13.7 Third-Party Beneficiaries. This Agreement and the rights and obligations hereunder shall bind and inure to the benefit of the parties and their successors and permitted assigns. Nothing in this Agreement, expressed or implied, is intended to confer upon any person, other than the parties and their successors and permitted assigns, any of the rights hereunder. 13.8 No Support or Maintenance. User acknowledges and agrees that Company will have no obligation to provide User with any support or maintenance in connection with the Platform, Website, or Service. [PreviousTerms and Conditions](https://docs.cap.app/resources/terms-and-conditions) [NextPrivacy Policy](https://docs.cap.app/resources/terms-and-conditions/privacy-policy) Last updated 5 months ago --- # Borrow | cap Whitelisted Operators in Cap can borrow and repay the underlying Vault assets, provided they have secured sufficient collateral from a Delegator. [](https://docs.cap.app/concepts/lender/borrow#mechanics) Mechanics ------------------------------------------------------------------------ ### [](https://docs.cap.app/concepts/lender/borrow#borrow) Borrow The borrow process flow is as follows: 1. Operator calls the borrow function on the Lender contract 2. Restaker interest is realized first to prevent charging for compounded interest 3. If eligible to borrow\*, assets are lent out from the Vault to the Opeartor 4. Debt tokens are minted to track the loan **Key Validations\***: * Operator must have sufficient collateral and health factor * Operator must be whitelisted and not paused * Asset being borrowed should not be paused * Borrow amount must meet minimum requirements, and may not exceed maximum borrows * Minimum: set by Admin via the setMinBorrow function * Maximum: The smaller value of the Operator's remaining borrowable capacity, and the remaining available amount to be borrowed from the Vault ### [](https://docs.cap.app/concepts/lender/borrow#repay) Repay The repay process flow is as follows: 1. Operator calls the repay function on the Lender contract 2. Restaker interest is realized first to ensure all interest is accounted for 3. The repayment is processed in the following order: 1. Unrealized restaker interest (if any) 2. Vault principal debt 3. Vault interest 4. Debt tokens corresponding to the total amount repaid are burned If the repayment is not in full, the system will maintain a minimum borrow amount for the Operator. #### [](https://docs.cap.app/concepts/lender/borrow#interest-distribution) Interest Distribution The repaid assets are distributed back to the shareholders: 1. **Vault Principal**: Sent to [Vault](https://docs.cap.app/concepts/vault) contract's reserves 2. **Vault Interest**: Sent to `interestReceiver` (set to [FeeAuction](https://docs.cap.app/concepts/fee-auction) ). Any excess interest will go to the interest receiver 3. **Restaker Interest**: Sent to [Delegation](https://docs.cap.app/concepts/delegation) contract for distribution to Delegators 4. **Unrealized Interest**: Added to agent's debt balance for future repayment ### [](https://docs.cap.app/concepts/lender/borrow#realizing-interest) Realizing Interest Interest in Cap is **accrued continuously** but **realized discretely**: * **Accrued Interest**: Calculated in real-time based on elapsed time and rates * **Realized Interest**: Actually borrowed from vault and distributed to recipients * **Unrealized Interest**: Accrued but not yet realized due to vault liquidity constraints As can be seen, interest can be realized prior to repayment in Cap. Both stcUSD holders and Delegators may permissionlessly realize interest by borrowing from the vault and distributing to interest receivers. There are two functions to realize interest: realizeInterest and realizeRestakerInterest RealizeInterest: * Realizes vault interest (interest paid to the stcUSD holders) * Interest is borrowed from the Vault and paid to the interest receiver RealizeRestakerInterest: * Realizes restaker interest (interest paid to Delegators) * Interest is borrowed from the Vault and paid to the Delegation Contract For both functions, the process flow is as follows: 1. Determine available interest to realize 2. Increase reserve debt 3. Borrow interest amount from Vault 4. Transfer assets to recipient [](https://docs.cap.app/concepts/lender/borrow#architecture) Architecture ------------------------------------------------------------------------------ ### [](https://docs.cap.app/concepts/lender/borrow#borrow-logic) Borrow Logic The **BorrowLogic** library is the core component responsible for managing borrowing and repayment operations in the CAP lending system. **Key Dependencies:** * **IDebtToken**: Manages debt token minting/burning * **IDelegation**: Handles restaker interest distribution * **IVault**: Manages asset storage and transfers * **ValidationLogic**: Validates borrowing operations * **ViewLogic**: Calculates borrowing capacity and health metrics * **AgentConfiguration**: Tracks agent borrowing status per reserve #### [](https://docs.cap.app/concepts/lender/borrow#debt-token) Debt Token Debt tokens are core to accounting an Operator's loan. Debt tokens are non-transferrable ERC20 tokens minted when an Operator borrows, and burned when the debt is repayed. #### [](https://docs.cap.app/concepts/lender/borrow#vault) Vault Assets are transferred from/to the Vault once validation checks and interest calculations are done in the Lender. ### [](https://docs.cap.app/concepts/lender/borrow#key-functions) Key Functions `**borrow**`: Borrow an asset where the borrow params are: **Process Flow**: 1. **Interest Realization**: 2. **Amount Calculation**: 3. **Validation**: 4. **State Updates**: 5. **Asset Transfer**: `**repay**`: Repay an asset where the repay params are: **Process Flow**: 1. **Interest Realization**: 2. **Amount Calculation**: **prevents repaying more than owned** 3. **Minimum Debt Protection**: 4. **Repayment Allocation**: 5. **Asset Distribution**: 6. **Debt Token Burning**: `**realizeInterest**`: Realize interest for an asset `**realizeRestakerInterest**`: Realize interest for restaker debt of an agent for an asset Unrealized interest support: Can track interest that couldn't be realized due to liquidity constraintss #### [](https://docs.cap.app/concepts/lender/borrow#admin-functions) Admin Functions `**setInterestReceiver**`**:** Set Interest Receiver for an asset `**setMinBorrow**`**:** Set minimum borrow amount for an asset #### [](https://docs.cap.app/concepts/lender/borrow#view-functions) View Functions `**accruedRestakerInterest**`: Accrued Restaker Interest `**unrealizedInterest**`: Unrealized Restaker Interest `**maxRealization**`: Calculates the maximum vault interest that can be realized for an asset `**maxRestakerRealization**`: Calculates the maximum restaker interest that can be realized for an agent * `newRealizedInterest`: Maximum realizable interest * `newUnrealizedInterest`: Interest that will become unrealized [PreviousLender](https://docs.cap.app/concepts/lender) [NextLiquidation](https://docs.cap.app/concepts/lender/liquidation) Last updated 2 months ago * [Mechanics](https://docs.cap.app/concepts/lender/borrow#mechanics) * [Borrow](https://docs.cap.app/concepts/lender/borrow#borrow) * [Repay](https://docs.cap.app/concepts/lender/borrow#repay) * [Realizing Interest](https://docs.cap.app/concepts/lender/borrow#realizing-interest) * [Architecture](https://docs.cap.app/concepts/lender/borrow#architecture) * [Borrow Logic](https://docs.cap.app/concepts/lender/borrow#borrow-logic) * [Key Functions](https://docs.cap.app/concepts/lender/borrow#key-functions) Copy interface IDebtToken { function mint(address to, uint256 amount) external; function burn(address from, uint256 amount) external; function balanceOf(address account) external view returns (uint256); } Copy interface IVault { function borrow(address _asset, uint256 _amount, address _receiver) external; function repay(address _asset, uint256 _amount) external; function availableBalance(address _asset) external view returns (uint256); } Copy function borrow(ILender.LenderStorage storage $, ILender.BorrowParams memory params) external returns (uint256 borrowed) Copy struct BorrowParams { address agent; // Borrower address address asset; // Asset to borrow uint256 amount; // Amount to borrow address receiver; // Receiver of borrowed assets bool maxBorrow; // Whether to borrow maximum available } Copy realizeRestakerInterest($, params.agent, params.asset); Copy if (params.maxBorrow) { params.amount = ViewLogic.maxBorrowable($, params.agent, params.asset); } Copy ValidationLogic.validateBorrow($, params); Copy IDelegation($.delegation).setLastBorrow(params.agent); $.agentConfig[params.agent].setBorrowing(reserve.id, true); Copy IVault(reserve.vault).borrow(params.asset, borrowed, params.receiver); IDebtToken(reserve.debtToken).mint(params.agent, borrowed); reserve.debt += borrowed; Copy function repay(ILender.LenderStorage storage $, ILender.RepayParams memory params) external returns (uint256 repaid) Copy struct RepayParams { address agent; // Agent to repay for address asset; // Asset to repay uint256 amount; // Amount to repay address caller; // Address making the repayment } Copy realizeRestakerInterest($, params.agent, params.asset); Copy uint256 agentDebt = IERC20(reserve.debtToken).balanceOf(params.agent); repaid = Math.min(params.amount, agentDebt); Copy if (remainingDebt > 0 && remainingDebt < reserve.minBorrow) { repaid = agentDebt - reserve.minBorrow; } Copy // Calculate interest repayment if (repaid > reserve.unrealizedInterest[params.agent] + reserve.debt) { interestRepaid = repaid - (reserve.debt + reserve.unrealizedInterest[params.agent]); } // Calculate restaker repayment if (remaining > reserve.unrealizedInterest[params.agent]) { restakerRepaid = reserve.unrealizedInterest[params.agent]; } // Calculate vault repayment uint256 vaultRepaid = Math.min(remaining, reserve.debt); Copy // Send to restakers IERC20(params.asset).safeTransfer($.delegation, restakerRepaid); IDelegation($.delegation).distributeRewards(params.agent, params.asset); // Send to vault IVault(reserve.vault).repay(params.asset, vaultRepaid); // Send to interest receiver IERC20(params.asset).safeTransfer(reserve.interestReceiver, interestRepaid); Copy IDebtToken(reserve.debtToken).burn(params.agent, repaid); Copy function realizeInterest(ILender.LenderStorage storage $, address _asset) external returns (uint256 realizedInterest) Copy function realizeRestakerInterest(ILender.LenderStorage storage $, address _agent, address _asset) public returns (uint256 realizedInterest) Copy function setInterestReceiver(address _asset, address _interestReceiver) external checkAccess(this.setInterestReceiver.selector) Copy function setMinBorrow(address _asset, uint256 _minBorrow) external checkAccess(this.setMinBorrow.selector) Copy function accruedRestakerInterest(address _agent, address _asset) external view returns (uint256 accruedInterest) Copy function unrealizedInterest(address _agent, address _asset) external view returns (uint256 _unrealizedInterest) Copy function maxRealization(address _asset) external view returns (uint256 _maxRealization) Copy function maxRestakerRealization(address _agent, address _asset) external view returns (uint256 newRealizedInterest, uint256 newUnrealizedInterest) --- # Vault | cap The Vault is the core module responsible for the storage, issuance, and redemption of cUSD, and for managing the underlying collateral assets. It plays a pivotal role as the protocol's liquidity backbone by enabling minting and burning of cUSD, facilitating liquidity for borrowers, and ensuring capital efficiency through the Fractional Reserves. [](https://docs.cap.app/concepts/vault#overview-of-operations) Overview of operations ------------------------------------------------------------------------------------------ * **Mint/Burn:** cUSD can be minted/burned _~1:1_ for any of the supported backing assets. Fees are dynamically calculated according to the allocation ratio of the asset. * **Redeem:** cUSD can be redeemed for a proportional amount of the basket of assets for a fixed fee. * [**Fractional Reserves**](https://docs.cap.app/concepts/vault/fractional-reserves) : Idle capital in the Vault is deployed into yield-generating strategies (US T-bill yield, crypto lending markets) until borrowed or withdrawn. * **Borrow/Repay**: When operators borrow/repays assets, the Vault tracks utilization of the pool [](https://docs.cap.app/concepts/vault#mechanics) Mechanics ---------------------------------------------------------------- ### [](https://docs.cap.app/concepts/vault#mint-burn) Mint/Burn The Vault is the main interface for liquidity providers to mint and burn cUSD. cUSD can be minted/burned at Oracle value for any of the assets. Fees are calculated in the [Minter](https://docs.cap.app/concepts/vault/minter) contract according to the allocation of the assets. When a user mints/burns, the flow is as follows: 1. **User Call**: User calls `Vault.mint()` (or burn) with asset and amount 2. **Fee Calculation**: Vault calls `Minter.getMintAmount()` (or getBurnAmount) to calculate fees 3. **Logic Processing**: MinterLogic calculates amount out and fees at current Oracle value 4. **State Update**: VaultLogic handles asset transfer and state updates 5. **Token Minting**: cUSD is minted/burned in exchange for underlying assets Mint and burn functions are disabled if Oracle prices are stale, until Oracles are back in sync ### [](https://docs.cap.app/concepts/vault#redeem) Redeem A depeg event of any of the underlying assets can result in a last man standing problem where the last to withdraw will be left with the depegged asset. When such events occur, the protocol incentivizes users to withdraw proportionally to the ratio of the assets, effectively socializing the losses. Redeem fees are charged at a fixed percentage, whereas burn fees are dynamic, making it economically infeasible to burn for USDT beyond the burn kink ratio. For instance, if the basket contains 50% of USDC valued at $0.9 and 50% of USDT valued at $1, then the redeem request for $100 cUSD should withdraw $45 worth of USDC and $50 worth of USDT minus fees. When a user redeems, the flow is as follows: 1. **User Call**: User calls `Vault.redeem()` with cUSD 2. **Fee Calculation**: Vault calls `Minter.getRedeemAmount()` to calculate proportional amounts 3. **State Update**: cUSD is burned from user, assets are divested from strategies 4. **Asset Transfer**: All underlying assets are transferred to user ### [](https://docs.cap.app/concepts/vault#borrow-operations) Borrow Operations Registered Operators can borrow assets from the Vault via the Lender, provided they are sufficiently collateralized by delegated assets from shared security networks. While assets are lent out from the Vault, the core borrow logic is implemented in the Lender contract. When the Operator requests to borrow via the Lender, the Lender calls `Vault.borrow()` to transfer assets to the Lender, updating the utilization and reserve state of the Vault. Similarly, Operators can repay via the Lender, which transfers borrowed assets back to the Vault. ### [](https://docs.cap.app/concepts/vault#vault-management) Vault Management Assets must first be whitelisted in order to be used in Cap. Only regulated dollar-denominated crypto assets are accepted as a backing assets. Interest rates for borrowing each asset of the reserve is a function of the utilization rate of the asset. The [current utilization rate](https://github.com/cap-labs-dev/cap-contracts/blob/main/contracts/vault/Vault.sol#L198) of each asset can be queried in the Vault contract. ### [](https://docs.cap.app/concepts/vault#configurations) Configurations * **Whitelist minters**: Supports fee bypass for privileged users * **Pause mechanisms**: * Asset-Level Pause: Individual assets can be paused while others remain active * Protocol-Level Pause: Complete protocol shutdown capability ### [](https://docs.cap.app/concepts/vault#key-vault-parameters) Key Vault Parameters * **Total Supplies**: Total amount of each asset deposited in the vault * **Total Borrows**: Total amount of each asset borrowed from the vault * **Utilization Rate**: Ratio of borrowed assets to total supplies, calculated as (Total Borrows / Total Supplies) \* 100% * **Available Balance**: Amount of asset available for borrowing, calculated as Total Supplies - Total Borrows * **Utilization Index**: Cumulative utilization tracking for interest rate calculations * **Insurance Fund**: Address that receives fees from mint/burn operations * **Pause States**: Individual asset pause states and protocol-wide pause capability [](https://docs.cap.app/concepts/vault#architecture) Architecture ---------------------------------------------------------------------- The Vault module inherits from the Fractional Reserve and Minter contracts 1. **Vault** - Manages asset storage, accounting, and cUSD minting/burning 2. [**Fractional Reserve**](https://docs.cap.app/concepts/vault/fractional-reserves) - Manages idle capital deployment 3. [**Minter**](https://docs.cap.app/concepts/vault/minter) - Handles dynamic fee calculation for minting operations ### [](https://docs.cap.app/concepts/vault#vault-contract) Vault Contract The Vault Contract is the main user-facing contract that enables minting and borrowing, as well as reserve asset management. #### [](https://docs.cap.app/concepts/vault#core-functions) Core Functions `**mint**`: Allows users to deposit approved assets and receive cUSD in return * `_asset`: Whitelisted asset to deposit * `_amountIn`: Amount of asset to use in the minting * `_minAmountOut`: Minimum amount to mint (slippage protection) * `_receiver`: Receiver of the minting * `_deadline`: Deadline of the transaction Key features: * **Slippage Protection**: `_minAmountOut` parameter * **Deadline Protection**: Transaction deadline validation * **Dynamic Fees**: Fees based on asset allocation ratios `**burn**`: Burns cUSD in exchange for one of the underlying assets. * `_asset`: Asset to withdraw * `_amountIn`: Amount of cap token to burn * `_minAmountOut`: Minimum amount out to receive * `_receiver`: Receiver of the withdrawal * `_deadline`: Deadline of the transaction `**redeem**`: Allows users to burn cUSD in exchange for multi-collateral withdrawal, proportional to the ratio of the underlying assets. * `_amountIn`: Amount of Cap token to burn * `_minAmountsOut`: Minimum amounts of assets to withdraw * `_receiver`: Receiver of the withdrawal * `_deadline`: Deadline of the transaction Key features: * **Proportional Withdrawal**: Withdraws assets proportional to current ratios * **Fee Avoidance**: Avoids dynamic fees by withdrawing proportionally `**borrow**`: Allows whitelisted agents to borrow assets from the vault * `_asset`: Asset to borrow * `_amount`: Amount of asset to borrow * `_receiver`: Receiver of the borrow `**repay**`: Allows repayment of borrowed assets * `_asset`: Asset to repay * `_amount`: Amount of asset to repay #### [](https://docs.cap.app/concepts/vault#admin-functions) Admin Functions * `**addAsset**`: Adds new assets to the vault * `**removeAsset**`: Removes assets from the vault (only if no supplies) * `**pauseAsset**`: Pauses operations for specific assets * `**unpauseAsset**`: Resumes operations for specific assets * `**pauseProtocol**`: Pauses all protocol operations * `**unpauseProtocol**`: Resumes all protocol operations * `**setInsuranceFund**`: Sets the insurance fund address * `**rescueERC20**`: Rescues unsupported tokens from the vault #### [](https://docs.cap.app/concepts/vault#view-functions) **View Functions** * `**assets**`: Get the list of assets supported by the vault * `**totalSupplies**`: Get the total supplies of an asset * `**totalBorrows**`: Get the total borrows of an asset * `**utilization**`: Get the utilization rate of an asset * `**availableBalance**`: Get available balance to borrow an asset * `**paused**`: Get the pause state of an asset * `**currentUtilizationIndex**`: Get up-to-date cumulative utilization index * `**insuranceFund**`: Get the insurance fund address ### [](https://docs.cap.app/concepts/vault#data-structures) Data Structures #### [](https://docs.cap.app/concepts/vault#vaultstorage) VaultStorage The VaultStorage stores all vault configuration and state information. #### [](https://docs.cap.app/concepts/vault#mintburnparams) MintBurnParams Parameters for minting or burning operations. #### [](https://docs.cap.app/concepts/vault#redeemparams) RedeemParams Parameters for redemption operations. #### [](https://docs.cap.app/concepts/vault#borrowparams) BorrowParams Parameters for borrowing operations. #### [](https://docs.cap.app/concepts/vault#repayparams) RepayParams Parameters for repayment operations. [PreviousOverview](https://docs.cap.app/concepts/overview) [NextFractional Reserves](https://docs.cap.app/concepts/vault/fractional-reserves) Last updated 2 months ago * [Overview of operations](https://docs.cap.app/concepts/vault#overview-of-operations) * [Mechanics](https://docs.cap.app/concepts/vault#mechanics) * [Mint/Burn](https://docs.cap.app/concepts/vault#mint-burn) * [Redeem](https://docs.cap.app/concepts/vault#redeem) * [Borrow Operations](https://docs.cap.app/concepts/vault#borrow-operations) * [Vault Management](https://docs.cap.app/concepts/vault#vault-management) * [Configurations](https://docs.cap.app/concepts/vault#configurations) * [Key Vault Parameters](https://docs.cap.app/concepts/vault#key-vault-parameters) * [Architecture](https://docs.cap.app/concepts/vault#architecture) * [Vault Contract](https://docs.cap.app/concepts/vault#vault-contract) * [Data Structures](https://docs.cap.app/concepts/vault#data-structures) Copy function mint(address _asset, uint256 _amountIn, uint256 _minAmountOut, address _receiver, uint256 _deadline) external returns (uint256 amountOut) Copy function burn(address _asset, uint256 _amountIn, uint256 _minAmountOut, address _receiver, uint256 _deadline) external returns (uint256 amountOut) Copy function redeem(uint256 _amountIn, uint256[] calldata _minAmountsOut, address _receiver, uint256 _deadline) external returns (uint256[] memory amountsOut) Copy function borrow(address _asset, uint256 _amount, address _receiver) external Copy function repay(address _asset, uint256 _amount) external Copy struct VaultStorage { EnumerableSet.AddressSet assets; // List of supported assets mapping(address => uint256) totalSupplies; // Total supplies per asset mapping(address => uint256) totalBorrows; // Total borrows per asset mapping(address => uint256) utilizationIndex; // Utilization index per asset mapping(address => uint256) lastUpdate; // Last update time per asset mapping(address => bool) paused; // Pause state per asset address insuranceFund; // Insurance fund address } Copy struct MintBurnParams { address asset; // Asset to mint or burn uint256 amountIn; // Amount of asset to use uint256 amountOut; // Amount of cap token to mint or burn uint256 minAmountOut; // Minimum amount to mint or burn address receiver; // Receiver of the operation uint256 deadline; // Deadline of the transaction uint256 fee; // Fee paid to insurance fund } Copy struct RedeemParams { uint256 amountIn; // Amount of cap token to burn uint256[] amountsOut; // Amounts of assets to withdraw uint256[] minAmountsOut; // Minimum amounts of assets to withdraw address receiver; // Receiver of the withdrawal uint256 deadline; // Deadline of the transaction uint256[] fees; // Fees paid to insurance fund } Copy struct BorrowParams { address asset; // Asset to borrow uint256 amount; // Amount of asset to borrow address receiver; // Receiver of the borrow } Copy struct RepayParams { address asset; // Asset to repay uint256 amount; // Amount of asset to repay } --- # Email Protection | Cloudflare Please enable cookies. Email Protection ================ You are unable to access this email address docs.cap.app -------------------------------------------------------- The website from which you got to this page is protected by Cloudflare. Email addresses on that page have been hidden in order to keep them from being accessed by malicious bots. **You must enable Javascript in your browser in order to decode the e-mail address**. If you have a website and are interested in protecting it in a similar way, you can [sign up for Cloudflare](https://www.cloudflare.com/sign-up?utm_source=email_protection) . * [How does Cloudflare protect email addresses on website from spammers?](https://developers.cloudflare.com/waf/tools/scrape-shield/email-address-obfuscation/) * [Can I sign up for Cloudflare?](https://developers.cloudflare.com/fundamentals/setup/account/create-account/) Cloudflare Ray ID: **9ab7b01f5d4b8254** • Your IP: Click to reveal 54.237.218.47 • Performance & security by [Cloudflare](https://www.cloudflare.com/5xx-error-landing) ---