Cap is a stablecoin protocol on Ethereum with two products: cUSD and stcUSD. cUSD is a digital dollar, backed by blue chip dollar assets like BENJI and USDC. stcUSD is a savings product that generates yield via an autonomous layer of operators.
Scope
On what chains are the smart contracts going to be deployed?
Ethereum
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
We are integrating stablecoins like USDC, USDT, pyUSD. All ERC20, no weird tokens.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
Owner and admin is trusted, and will correctly adjust settings.
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
Is the codebase expected to comply with any specific EIPs?
stcUSD is ERC4626, cUSD is ERC20.
Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
We expect MEV to handle the liquidations and feeAuction distributions in a timely manner, we will have automation to backstop this
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?
No
Please discuss any design choices you made.
In stcUSD we have a 24 hour linear release of rewards, I know that this is not 100% fair for all parties but we see this a more fair distribution then other options.
We have a fractional reserve which allows the unused funds to still earn via an underlying strategy. There is a known issue that the last withdraw can revert since we can get 1 wei less funds back. We will seed the vault with 1 wei to offset this. Also this fractional reserve will be a yVault that has 1 depositor which is our vault. This is locked to just our vault as depositor and is completely owned and run by the cap team.
We will have a symbiotic vault factory that will be used to remove some features from the symbiotic vaults to add risk to the system. This includes having the burner router admin be address(0). It also will require instant slashing. Each vault gets added by the admin and will be expected to have the correct config.
The epoch in the delegation contract is not the same as the epoch on the symbiotic contracts. The delegation epoch will be shorter than the symbiotic epoch as its purpose is to find us a slashable timestamp in which delegations were backing the borrow.
The mint fees are to counter the possibility of sandwiching a chainlink price update, so it will be set 2x the deviation of the largest asset update deviation from chainlink. We would trust parties that are whitelist for 0 mint fee. The fees are use to repay an system bad debt.
We have the ability to use funds in the vault to realize interest for both the stcUSD token and restakers. These are in two different functions, realizeRestakerInterest and realizeInterest. We also know that the interest rate can differ when realizeRestakerInterest is called by adding to the vault debt. This is because the restaker interest is a fixed rate and the underlying rate is variable.
There is an edge case where the added debt tokens of all parties are greater than the total supply of the debt token by 1 wei. This is a known issue in using the index to calc balances. It doesnt cause a systemic issue.
Please provide links to previous audits (if any) and all the known issues or acceptable risks.
Please list any relevant protocol resources.
Additional audit information.
A deep look at the symbiotic integration, and the open functions of Mint, Burn, Redeem, Liquidate, Repay, RealizeInterest and RealizeRestakerInterest.
Changed severity definitions that will apply to this contest:
High severity:
Direct loss of protocol TVL without (extensive) limitations of external conditions. The loss of the protocol TVL must exceed >1%. This can include >1% of the individual user cUSD collateral that is uniform at any size of user deposit (min $10 requirement still applies).
That means if the issue leads to loss of yield or fees, then it's not sufficient for High severity.
Medium severity:
Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The loss must be relevant to the affected party.
Breaks core contract functionality, rendering the contract useless or leading to loss of funds that's relevant to the affected party.
Any yield or fees losses >0.01% are considered Medium. Hence, if the issue leads to a 50% loss of yield or fees, then it's still Medium severity.
Total Rewards
Contest Pool
Lead Senior Watson
Lead Judge
93,100 USDC
25,000 USDC
6,000 USDC
Status
Scope
Start Time
End Time
Judging Rules