eBTC will be deployed exclusively on mainnet
The only collateral for eBTC is stETH
All findings contained in theses reports:
- RiskDAO: https://github.com/Risk-DAO/Reports/blob/main/eBTC.pdf
- Trust: https://badger.com/images/uploads/trust-ebtc-audit-report.pdf
- Spearbit: https://badger.com/images/uploads/ebtc-security-review-spearbit.pdf
- Cantina: https://badger.com/images/uploads/ebtc-security-review-cantina.pdf
Acknowledged findings should be considered known and ignored
Fixes to the above findings may have introduced bugs and should be well accepted
We use CREATE3 to predict the addresses, you can also check our testnet deployments which invalidate the finding
If Chainlink performs an upgrade, due to how PhaseId and RoundId are calculated the price will be stale
This is because there will not be a valid price at roundId - 1
The Oracle will resume working as intended once the CL Feed reports 2 prices from the same aggregator (see Spearibit / Cantina Reports for more details)
Badger will:
- Donate up to 2stETH of collateral to the system contracts as a way to prevent any shortfall due to rounding (avoids off by one errors)
- Keep open, at all times, a CDP with at least 2 stETH of Collateral with a CR between 150 and 200% (ensures its the last DP)
For this reason, rounding errors related to stETH should not be accepted as valid unless they can provably break the 2stETH threshold under reasonable circumnstances (e.g. 100 billion people using the protocol would be considered above reasonable)
We acknowledge that and understand that’s a risk
These impacts but are not limited to:
- Mint new eBTC (until extensible minting is revoked)
- Pause Flashloans and Redemptions
- Raise fees for Flashloans and Redemtpions
- Raise the Fee Split of stETH to up to 100%
- Delay Recovery Mode via the Grace Period to an indefinite amount
eBTC governance should not be able to block depositing, minting, adjusting and closing of positions under any circumnstance
Because they use nonces, the malleability cannot be exploited
Position Manager can receive Permanent or One Time abilities to perform any operation on behalf of an address
Ths means that signing delegation to a malicious address can cause a total loss of funds for all CDPs
We recommend:
- Opening a single CDP per address
- Verifying the code of the recipient of the delegation
- Ensure that the recipient of the delegation is a safe zap that rescinds it's ownership after the transaction
- Simulate all your transactions before performing them
They do not require safeTransfer nor SafeApprove, eBTC is deployed exclusively on mainnet
The limitations are capping the value that one call can cause, but by looping, more stETH and more eBTC could be borrowed
Closing a CDP
And Reducing Stake
Are ways to prevent redistribution of bad debt during Normal Mode
We have been able to create scenarios in which the sorting of CDPs is incorrect -> TODO: Test case
Liquidators can maximize their expected profits by liquidating from the lowest risk to the highest risk CDP
Highest Risk CDPs due to the dynamic premium, offer lower premium, (3%, which from our benchmarks requires a 2/1 ratio in stableswap a pool before it becomes a concern)
Was modelled by Risk DAO
3% bad debt is extremely smaller compared to worst case scenarios
And 3% for a stableswap is a crazy high depeg
Because swaps may not use all tokens, some dust would be left in the contract
It can be swept after but may cause operations to be slightly inefficient if slippage occurs between the time the calldata is generated and the call is executed
Liquidations for Recovery Mode will be delayed by at least the recoveryModeGracePeriodDuration
This period can take longer as the countdown must be started, either via any single person performing an operation, or by calling syncGlobalAccountingAndGracePeriod
Grace Period may also be triggered, then the price could raise to "undo recovery mode" and if no action is performed during this period, the next time Recovery Mode is triggered, the Grace Period will be already expired - See the test testL15Debunk which shows how this can happen
To Reiterate: If nobody calls the Start or the End of the Grace Period, then:
- Nobody ends it -> RM Liquidations will have no delay
- Nobody starts it -> RM Liquidations cannot happen until the Grace Period is started and the time has passed
Can be denied by repaying or by depositing more collateral
Repaying or adding more collateral are intended behaviours, they helps the system and reduce the maximum debt that has to be liquidated at a time
Adding collateral raises your CR as well, and it's always cheaper to repay than to deposit collateral
Proper risky Liquidations are not delayed in any way
CrLens is a test contract, it's meant to be used only to prove invariants, it's meant to be used with: https://github.com/code-423n4/2023-10-badger/blob/ec19425ed66dec0f3a654a3b753505ddb7c1b3e3/packages/contracts/contracts/TestContracts/AccruableCdpManager.sol#L35-L37
Which is why the tests pass locally
We anticipate liquidators and redemption arbitrageurs to use Curve and Balancer pools to access on-chain liquidity. Potential economic attacks should be considered taking this into account.
Specifically, the main pairs for eBTC are going to be:
-
StableSwap eBTC - wBTC (Low Fee) Which will allow buying stETH via the highly liquid wBTC - WETH pair
-
50/50 Pool eBTC - stETH - High Fee (50 BPS / 1%)
Which allows delta neutral LPing as well as gas efficient liquidations and leverage for smaller sizes (the pool price imbalances more rapidly)