Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing readme #809

Merged
merged 3 commits into from
Sep 24, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
179 changes: 4 additions & 175 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,185 +5,14 @@ After locking up stETH as collateral in a smart contract and creating an individ

The redemption and liquidation mechanisms help ensure that stability is maintained through economically-driven user interactions and arbitrage, rather than through active governance or monetary interventions.

## eBTC Audit - What's in scope


|File|[SLOC](#nowhere "(nSLOC, SLOC, Lines)")|Description|
:-|:-:|:-|
|_Core Protocol Contracts (10)_|
|[/packages/contracts/contracts/ActivePool.sol]()|[221]|Manages system-level internal accounting and stETH tokens.|
|[/packages/contracts/contracts/BorrowerOperations.sol]()|[751]|Entry point to Open, Adjust, and Close Cdps as well as delegate positionManagers.|
|[/packages/contracts/contracts/CdpManager.sol]()|[578]|Cdp operations and entry point for non-borrower operations on Cdps (Liquidations, Redemptions).|
|[/packages/contracts/contracts/LiquidationLibrary.sol]()|[700]|Contains liquidation-related functions. Split off due to maximum contract size, delegateCalled by CdpManager.|
|[/packages/contracts/contracts/CdpManagerStorage.sol]()|[550]|Shared storage variables between CdpManager and Liquidation Library, and common functions.|
|[/packages/contracts/contracts/CollSurplusPool.sol]()|[83]|Isolated storage of excess collateral owed to users from liquidations or redemptions. Not considered part of system for accounting.|
|[/packages/contracts/contracts/EBTCToken.sol]()|[223]|ERC20 EbtcToken, with permit approvals and extensible minting.|
|[/packages/contracts/contracts/Governor.sol]()|[107]|Roles-based authorization contract, adapted and expanded from solmate Authority. Expanded with more convenience view functions and ability to permanently burn capabilities.|
|[/packages/contracts/contracts/PriceFeed.sol]()|[491]|PriceFeed with primary and secondary oracles and state machine to switch between them and handle failure cases.|
|[/packages/contracts/contracts/SortedCdps.sol]()|[399]|Data storage for the doubly-linked list of Cdps. Sorting of Cdps is used to enforce redemptions from lowest ICR to highest ICR.|
|_Lens / Helper Contracts (4)_|
|[/packages/contracts/contracts/HintHelpers.sol]()|[142]|Generate approximate locations for proper linked list insertion locations for Cdps.|
|[/packages/contracts/contracts/CRLens.sol]()|[98]|Simulate state changes and view results, to compare to expected results in testing env.|
|[/packages/contracts/contracts/MultiCdpGetter.sol]()|[92]|Get data from multiple Cdps in one call.|
|[/packages/contracts/contracts/SyncedLiquidationSequencer.sol]()|[76]|Generate sequences of Cdps available for liquidation, for use with batchLiquidate|
|_Leverage Macros & Smart Wallets (5)_|
|[/packages/contracts/contracts/LeverageMacroBase.sol]()|[353]|Common base implementation of the LeverageMacro.|
|[/packages/contracts/contracts/LeverageMacroDelegateTarget.sol]()|[30]|LeverageMacro variant for use with delegateCall with compatible smart wallets.|
|[/packages/contracts/contracts/LeverageMacroFactory.sol]()|[46]|Factory for deploying LeverageMacroReference|
|[/packages/contracts/contracts/LeverageMacroReference.sol]()|[38]|LeverageMacro variant for use as a zap with an individual owner.|
|[/packages/contracts/contracts/SimplifiedDiamondLike.sol]()|[109]|Smart wallet with custom callback handler support.|
|_Modified Dependencies (7)_|
|[/packages/contracts/contracts/Dependencies/Auth.sol]()|[33]|Inherited by contracts consuming authorization rules of Governor.|
|[/packages/contracts/contracts/Dependencies/AuthNoOwner.sol]()|[36]|Inherited by contracts consuming authorization rules of Governor. Removes owner address that has global 'admin' permission from Auth.|
|[/packages/contracts/contracts/Dependencies/ERC3156FlashLender.sol]()|[10]|Base for standardized flash loans|
|[/packages/contracts/contracts/Dependencies/EbtcBase.sol]()|[78]|Common definition and base functions for system contracts.|
|[/packages/contracts/contracts/Dependencies/EbtcMath.sol]()|[62]|More common math functions for system contracts.|
|[/packages/contracts/contracts/Dependencies/ReentrancyGuard.sol]()|[12]|Simple, optimized reentrancy guard.|
|[/packages/contracts/contracts/Dependencies/RolesAuthority.sol]()|[102]|Role-based authorization from solmate. Expanded functionality for use with Governor.|


## Known issues from Previous Audits

All findings contained in theses reports:
## eBTC Audit 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

## More information

- [Introducing eBTC - A Decentralized Bitcoin Powered by Ethereum Staking](https://forum.badger.finance/t/introducing-ebtc-a-decentralized-bitcoin-powered-by-ethereum-staking/5952)
- See the [eBTC Cheatsheet](https://gist.github.com/GalloDaSballo/7b060bb97de09c539ec64c533dd352c6) for an up to date list of additional resources.

## Known issues

### There is no fallback oracle as of now
We should gracefully handle the case of no fallback oracle, as well as switching to a fallback oracle from having none.

### If Chainlink dependencies burn all gas, or the contract is destructed, then the Price Feed will revert

### 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)

### We understand some rounding errors can happen
Badger will:
- Donate up to 2 stETH 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)


### stETH contract can be arbitrarily upgraded
We acknowledge that and understand that’s a dependency risk.

### eBTC Governance has the ability to cause substantial damage
These impacts but are not limited to:

- Mint new eBTC (until extensible minting capability is burned)
- 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 however not be able to block depositing, minting, adjusting and closing of positions under any circumstance.

### Permit Signatures are malleable
Because they use nonces, the malleability cannot be exploited.

### Malicious Position Managers can steal all tokens from borrowers that grant them approvals
Position Managers 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

### The tokens of the system are fixed: StETH and eBTC

They do not require safeTransfer nor SafeApprove, eBTC is deployed exclusively on mainnet

### Flashloan Limits can be bypassed

The limitations are capping the value that one call can access, but looping to borrow more stETH and more eBTC can occur.

### Prevening Bad Debt Redistribution
Closing a CDP or reducing Stake are ways to prevent or minimize redistribution of bad debt during Normal Mode.

Sandwiching the redistribution:
* close or reduce position
* bad debt redistribution event occurs
* re-open or increase position

### Incorrect Sorting due to Pending Debt and Yield
We have been able to create scenarios during fuzz testing in which the sorting of CDPs invariant is violated. Anticipate example cases shown here. The impact is believed to be minimal in practice.

### Liquidators can behave in ways that are not ideal to the protocol security
Liquidators can maximize their expected profits by liquidating from the lowest risk CDP -> highest risk CDP.

Lower risk CDPs (e.g. 109%) offer more due to the dynamic premium than higher risk CDPs (e.g. 103%)

From our benchmarks, assuming liquidations happen at 3% premium requires a 2/1 eBTC ratio in a stableswap pool vs like-kind BTC asset before it becomes a concern (see riskDAO report).

### Liquidations Premium
Was determined via modelling by RiskDAO

3% bad debt is extremely smaller compared to worst case scenarios

And 3% for a stableswap is a crazy high depeg

### Leverage Macro
Because swaps may not use all tokens, some dust could 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.

### Grace Period Desynchs

#### Grace Period Cannot start if no interaction happens

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 will not re-start if the system exists recovery mode but no interaction re-sets it

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

### Grace Period can be denied by repaying
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.


## Other Notes
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)
- Cantina Part 2: https://cantina.xyz/portfolio/e7dac53a-6098-4aa1-aa0f-ea44ee87050e
- C4 Contest: https://code4rena.com/reports/2023-10-badger

## eBTC System Summary
- [eBTC Overview](#ebtc-overview)
Expand Down
Loading