All eBTC contracts will be deployed shortly and the assets in the ‘assets in scope’ table above will be updated with the live contracts. These will be fully identical with the code in the github links. 

BadgerDAO’s up to date codebase can be found at https://github.com/ebtc-protocol/ebtc/tree/release-0.7 

**Whitehat Educational Resources & Technical Info**


- [Read the changelog here](https://github.com/ebtc-protocol/ebtc/pull/766) to learn the differences between this release and the [previous Code4rena contest](https://code4rena.com/audits/2023-10-badger-ebtc-audit-certora-formal-verification-competition).
- [Primary documentation](https://docs.ebtc.finance/ebtc/)
- [Primary Readme](https://github.com/code-423n4/2023-10-badger/blob/main/README_EBTC.md)
- [In-depth Introductory Video](https://www.youtube.com/watch?v=QWIB4avTkt4)
- [eBTC Cheatsheet](https://gist.github.com/GalloDaSballo/7b060bb97de09c539ec64c533dd352c6) with additional videos and an up to date list of additional resources
- Website: [ebtc.finance](https://www.ebtc.finance/)
- Twitter: [eBTCProtocol](https://twitter.com/eBTCprotocol)
- [JohnnyTime eBTC Overview](https://www.youtube.com/watch?v=f2numPMZFSI&t=1s)
- [eBTC x Immunefi Technical Walkthrough](https://www.youtube.com/watch?v=0_Tb8GitY8w)




**Is this an upgrade of an existing system? If so, which? And what are the main differences?**

No, this is a net new protocol with no relation to past BadgerDAO projects.



**Where do you suspect there may be bugs?**

We are concerned around core accounting (yield split and debt redistribution), the ability to abuse or significantly DOS the liquidation or redemption mechanics, and significant rounding errors.

Here is our [full list of invariants](https://github.com/ebtc-protocol/ebtc/blob/release-0.7/packages/contracts/contracts/TestContracts/invariants/PropertiesDescriptions.sol).

Calling out accounting invariants:

- Cdps have a pending accounting state that is only updated when that Cdp is interacted with. Cdps can stay out of sync for a long time, there is no way to force them to synchronize unless the owner or approved positionManager interacts with the Cdp. 

- For numerical exploits, the total stETH in existence or that could be in existence must be considered. 
 
- Loss of yield must be considered relative to other changes. For example, if a bunch of positive rebases happen and then there’s a slash, and the system is not updated until that point, those positive rebases will be lost.
 
- Max 1 wei of unallocated debt per Cdp per debt redisttribution event is a theoretical maximum that can happen. This does not scale to a reasonable value with real-world values.
 
- SortedCdps view functions are not for on-chain users.


**What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?**

stETH is supported as collateral, which is a rebasing token. The eBTC token is “standard” as far as these properties go.


**What emergency actions may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?**

Emergency actions could involve:

- pausing flashloans
- pausing redemptions
- switching between the stETH 1:1 fixed oracle to the stETH/ETH market rate oracle



**What Roles are there, and what capacities do they have?**

There are a number of roles maintained by the Governor contract.

It has role-based access control that gates function signatures by role, based on [solmate RolesAuthority](https://github.com/transmissions11/solmate/blob/main/src/auth/authorities/RolesAuthority.sol).


The following roles exist in the system:

Role 0: // The Admin, manages the setting of roles and associated properties

- governor.setRoleName()
- governor.setUserRole()
- governor.setRoleCapability()
- governor.setPublicCapability()
- governor.burnCapability()
- governor.transferOwnership()
- governor.setAuthority()


Role 1: // Extensible minter, can mint eBTC tokens at-will. Unused at the start.

- ebtcToken.mint(address,uint256)

Role 2: // Extensible burner, can burn eBTC tokens at will. Unused at the start.

- ebtcToken.burn(address,uint256)
- ebtcToken.burn(uint256)

Role 3: // Redemption and yield split parameter manager

- cdpManager.setStakingRewardSplit(uint256)
- cdpManager.setRedemptionFeeFloor(uint256)
- cdpManager.setMinuteDecayFactor(uint256)
- cdpManager.setBeta(uint256)
- cdpManager.setGracePeriod(uint256)

Role 4: // Emergency pauser

- cdpManager.setRedemptionsPaused(bool)
- activePool.setFlashLoansPaused(bool)
- borrowerOperations.setFlashLoansPaused(bool)

5: // Flashloan fee parameter manager

- borrowerOperations.setFeeBps(uint256)
- activePool.setFeeBps(uint256)


6: // Token sweeper. Note that the sweeping recipient is pre-set and members of this role can’t claim the tokens to themselves.

- activePool.sweepToken(address,uint256)
- collSurplusPool.sweepToken(address,uint256)

7: // Fee recipient sweeper

- activePool.claimFeeRecipientCollShares(uint256)

8: // Primary oracle manager

- ebtcFeed.setPrimaryOracle(address)

9: // Secondary oracle manager

- ebtcFeed.setSecondaryOracle(address)

10: // Price Feed fallback manager

- priceFeed.setFallbackCaller(address)

11: // stETH 1:1 to market rate switcher, coupled with appropriate redemption rate change. Unused initially, but intended to give to a bot with security guardrails around conditions where sETH/ETH feed is appropriate.

- priceFeed.setCollateralFeedSource(bool)
- cdpManager.setRedemptionFeeFloor(uint256)


**There are five permissioned contracts**

1. High Security Timelock

The ultimate governance administrator also holds most permissions. The only permissions it doesn’t have are eBTC minting and burning (which no contract has in this configuration)

Roles: [0, 3, 4, 5, 6, 7, 8, 9, 10]


2. Low Security Timelock

A faster timelock that can perform all but the most sensitive operations.
It notably doesn’t have admin capabilities on the Governor, or the ability to swap primary oracle.

Roles: [3, 4, 5, 6, 7, 9, 10]


3. Security Multisig

The higher security multisig. It can propose transactions into the high security and low security timelocks and call pausing functions directly

Roles: [4]


4. Tech Ops Multisig

The lower security multisig. It can propose transactions into the low security timelock and call pausing functions directly.

Roles: [4]


5. Fee Recipient Multisig

Manages the yield split fee collections serving as a destination for sweeping tokens.

Roles: [6, 7]



**What external dependencies are there?**

We’ve got a short list for eBTC.

- Chainlink oracles
- stETH token

**Where might whitehats confuse out-of-scope code to be in-scope?**

Files in the repo that are not specifically in scope are the most likely source of confusion, such as test files. This project has a low number of external dependencies and doesn’t interact with much.

Assume the PriceFeed.sol will never have the fallback oracle assigned, this will remain at zero. This governance capability can be permanently burned to enable this spec.
 
Unbounded gas is effectively possible via poor hint selection, this is known and should not constitute an unbounded gas finding

**Are there any unusual points about your protocol that may confuse whitehats?**

The rebasing nature of the stETH token and conversion between balances and shares.


**What is the test suite setup information?**

We have several test suites, they can be found here:

- [Hardhat test directory](https://github.com/ebtc-protocol/ebtc/tree/release-0.7/packages/contracts/test) 
- [Foundry test directory](https://github.com/ebtc-protocol/ebtc/tree/release-0.7/packages/contracts/foundry_test)
- Several Echdina/Medusa configs


**Public Disclosure of Known Issues**

Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk. 

- Account's stETH balance getting lower on 1 or 2 wei due to rounding down integer math: https://github.com/lidofinance/lido-dao/issues/442 

- Steal of shares using transferSharesFrom due to math rounding issues: https://github.com/lidofinance/lido-dao/issues/796

- Redeem to change partial NICR in order to grief redemption, or, open a cdp that front-runs the redemption to grief the redemption: https://github.com/code-423n4/2023-10-badger-findings/issues/226 

- stETH upgrade risk is considered known

- Unbounded gas is via poor hint selection

- Chainlink misbehaviour and single privilege is considered known

- Known Rounding Behaviour: Debt Redistribution Precision Loss:

  - Every time a Cdp updates with one or more pending debt redistribution events, it can possibly lose 1 wei of debt to rounding. This 1 wei of debt will still be accounted for in systemDebt. This is “rounding against the protocol” in the sense that the systemDebt will become 1 wei higher than the sum of all active Cdp debt for each instance of this occuring. It’s unbounded. This leads to a theoretical maximum differential of 1 wei per Cdp per debt redistribution event between the sum of all active Cdp debt and the systemDebt.

- Known Rounding Behaviour: Collateral Rebase Precision Loss:

  - However, this rounding behavior also exists during collateral rebase events. In this case it “rounds against the user”. Each time a Cdp is updated with any pending rebases to apply, it can lose 1 wei of collateral versus what it would have mathematically speaking due to precision loss of division. The systemCollShares becomes 1 wei higher than the sum of all active Cdp collShares in this instance. This leads to a theoretical maximum differential of 1 wei per Cdp per rebase event between the systemCollShares and the sum of all active Cdp collShares.

- SortedCdps list can get out of order with debt redistribution. This is considered acceptable and does not affect liquidations, only redemption ordering.

**Previous Audits**

BadgerDAO’s has provided these completed audit review reports for reference. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.

- 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
- Code4rena: https://code4rena.com/reports/2023-10-badger
- Shung: https://gist.github.com/Shungy/ebeb9366e970ecbf4da1eda296581e47

### Asset In Scope Policies

**Asset Accuracy Assurance**

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

**Private Known Issues Reward Policy**

Private known issues, meaning known issues that were not publicly disclosed, are considered valid, but will be downgraded by one severity.

**Known Issue Assurance**

BadgerDAO commits to providing Known Issue Assurance to bug submissions through their program. This means that BadgerDAO will either disclose known issues publicly, or at the very least, privately via a self-reported bug submission. 

In a potential scenario of a mediation, this allows for a more objective and streamlined process, in order to prove that an issue is known. Otherwise, assuming the bug report is valid, it would result in the report being considered as in-scope, and due a reward.

**Primacy of Impact vs Primacy of Rules**

BadgerDAO adheres to the Primacy of Impact for all impacts.

Primacy of Impact means that the impact is prioritized rather than a specific asset. This encourages security researchers to report on all bugs with an in-scope impact, even if the affected assets are not in scope. For more information, please see [Best Practices: Primacy of Impact ](https://immunefisupport.zendesk.com/hc/en-us/articles/12340245635089-Best-Practices-Primacy-of-Impact)

When submitting a report on Immunefi’s dashboard, the security researcher should select the Primacy of Impact asset placeholder. If the team behind this project has multiple programs, those other programs are not covered under Primacy of Impact for this program. Instead, check if those other projects have a bug bounty program on Immunefi.

If the project has any testnet and/or mock files, those will not be covered under Primacy of Impact.

Stormy

moonsimon

holydevoti0n

shanb1605

savi0ur

cheatcode

cryptonoob2k

OxG0P1

Hunterx2

thomastech

Mirrors

Saediek

https://drive.google.com/file/d/1CrK9PWe8BhGmoWNb5NIjXqN50dF2mwJx/view?usp=sharing

Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results

Direct theft of 2 stETH worth of any user funds, whether at-rest or in-motion, other than unclaimed yield

Permanent freezing of funds

Protocol insolvency

Theft of unclaimed yield

Permanent freezing of unclaimed yield

Temporary freezing of funds for at least 15 minutes

Smart contract unable to operate due to lack of token funds

Block stuffing

Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Theft of gas

Unbounded gas consumption

Contract fails to deliver promised returns, but doesn't lose value

**Proof of Concept (PoC) Requirements**

A PoC, demonstrating the bug's impact, is required for this program and has to comply with the [Immunefi PoC Guidelines and Rules](https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561-Proof-of-Concept-PoC-Guidelines-and-Rules).

**Impacts caused by exploiting external dependencies**

Critical & High severity impacts caused by exploiting external dependencies (such as Chainlink oracles and OpenZepplin libraries) are considered valid and in-scope, however they will be downgraded to Medium severity from the assessed impact.

Medium & Low severity impacts caused by exploiting external dependencies (such as Chainlink oracles and OpenZepplin libraries) are considered invalid and out-of-scope from the assessed impact.

**Feasibility Limitations**

For a Critical or High severity impact related to Loss of Yield, Precision Loss or insolvency the issue needs to demonstrate a loss higher than $500 with a 2 stETH Cdp (which would be the minimal threshold for insolvency for eBTC).

Magnitude matters when evaluating the validity of Critical & High severity impacts. Notably when discussing theft of funds, protocol insolvency, and theft of unclaimed yield. With this protocol, assume:

- System TVL is between $1m and $1b at $2500 ETH. Meaning 400 stETH to 400,000 stETH total collateral
- Absolute value of loss must be greater than 10% to qualify as protocol insolvency because any damage below 10% will not cause protocol insolvency in the worst case scenario due to the minimum Collateral Ratio being 110%.
- 100,000 maximum Cdps 
- No more than 36,500 rebases and 10,000 bad debt redistribution events

POCs that demonstrate impacts with conditions outside of this range will be considered valid but downgraded to Medium severity due to practical infeasibility.

### Miscellaneous Policies

**Eligibility Criteria**

Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:
- On OFACs SDN list 
- Official contributors that are currently involved (past contributors may participate)

**Responsible Publication**

Whitehats may publish their bug reports after they have been fixed & paid, or closed as invalid, with the following exceptions:

- Bug reports in mediation may not be published until mediation has concluded and the bug report is resolved.

Immunefi may publish bug reports submitted to this boosted bug bounty and a leaderboard of the participants and their earnings.

**Feasibility Limitations**

The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.

Therefore, Immunefi has developed a set of [feasibility limitation standards](https://immunefisupport.zendesk.com/hc/en-us/articles/16913132495377-Feasibility-Limitation-Standards) which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.

The reward pool will be fully distributed among participants. The size depends on the bugs found:

- If no High or Critical severity bugs are found the reward pool will be $50,000 USD
- If one or more High severity bugs are found the reward pool will be $100,000 USD
- If one or more Critical severity bugs are found the reward pool will be $200,000 USD


For this boost, duplicates and private known issues are valid for a reward.

These reward terms are a summary, for the full details read our [eBTC Boost Reward Terms](https://immunefisupport.zendesk.com/hc/en-us/articles/22591362396689-eBTC-Boost-Reward-Terms).

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/). 

**Reward Payment Terms**

Payouts are handled by the BadgerDAO team directly and are denominated in USD. However, payments are done in USDC.

Rewards will be distributed all at once based on Immunefi’s distribution terms after the event has concluded and the final bug reports have been resolved.

NAME	EARNINGS	TOTAL VALID BUGS	INSIGHTS	MEDIUM/LOW
1 Stormy	$20,517	2	1	2
2 moonsimon	$11,034	1	2	1
3 holydevoti0n	$10,000	1	0	1
4 shanb1605	$1,724	0	2	0
5 savi0ur	$1,724	0	2	0
6 cheatcode	$1,552	0	3	0
7 cryptonoob2k	$862	0	1	0
8 OxG0P1	$862	0	1	0
9 Hunterx2	$517	0	1	0
10 thomastech	$517	0	1	0
11 Mirrors	$517	0	1	0
12 Saediek	$172	0	1	0

Boost | eBTC

Status