eBTC Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for eBTC Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 7
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 7 closed, publicly disclosed eBTC Protocol reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Oracle manipulation, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against eBTC Protocol
- Oracle manipulation findings disclosed against eBTC Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
eBTC Protocol: Attacker can utilize function `CdpManager.redeemCollateral()` to break the order of sortedCdps
eBTC's CdpManager.redeemCollateral() corrupts the SortedCdps ordering invariant because the redemption loop reinserts a partially-redeemed Cdp into the sorted list (using caller-supplied upper/lower hints) before the fully-redeemed nodes in the same batch are removed via a post-loop batchRemove. An attacker can leave the final Cdp with a tiny debt and very high NICR and place it in an arbitrary sorted position, and subsequent openCdp calls using stale hint data can compound the misordering. The impact is a transiently corrupted sorted order and potentially unfair redemption priority with no direct asset theft, and the ordering self-corrects on the next redemption. The judge ultimately downgraded the finding from medium to Low/Non-critical QA after a working PoC confirmed the minimal, self-healing impact.
eBTC Protocol: The way fees are accounted can break the sorted list order
eBTC adapts Liquity's corrected-stake redistribution but breaks the CDP sorted-list invariant. When the protocol takes a fees cut from staking rewards, totalCollateral decreases while totalStakesSnapshot stays fixed, so newly opened CDPs are assigned disproportionately larger stakes. Since fees and debt redistributions are distributed pro-rata by stake, new CDPs' NICR decays faster than older troves', allowing older CDPs to cross newer ones and corrupt list order. The reporter's Foundry test opens 100 CDPs, applies a 40% index jump, opens one more CDP, and demonstrates a failing ordering assertion. Left unaddressed, the non-unique insertion positions cascade into list disorder, denial-of-service, and incorrect redemption ordering.
eBTC Protocol: Batched liquidations doesn't distribute bad debt on next batches in the list
In the eBTC CDP protocol, the batched liquidation flow processes multiple positions in a loop and only redistributes newly-generated bad debt once, during the finalize step that runs after the whole batch. Because the global redistribution index is not updated between individual liquidations, any CDP that generates bad debt early in the batch leaves the subsequently-processed CDPs being debt-synced against stale values. The result is that roughly 3% of the batch's bad debt is never redistributed to later positions, making those liquidations more favorable and shifting the uncovered remainder onto other stakers. The maintainer acknowledged this as a known issue and the judge upheld it as Medium, recommending that bad debt be redistributed after each liquidation within the batch.
eBTC Protocol: When calling LeverageMacroBase.doOperation to open a CDP, the POST CALL CHECK may use the wrong cdpId
eBTC's LeverageMacroBase.doOperation runs a POST CALL CHECK after opening a leveraged CDP that assumes the freshly created CDP is the last one in the owner's ownership list. The contract records the owner's current CDP count before opening and then does cdpOfOwnerByIndex with that same index afterward. Because SortedCdps orders CDPs by descending NICR, a newly opened CDP can be inserted ahead of an existing CDP of the same owner, so the lookup returns the wrong cdpId and validates the wrong CDP record. The impact reaches from spurious reverts that waste gas to a check able to pass on an unintended position for the second and later CDPs, though the sponsor adjudicated the realistic impact as usage reverts rather than direct loss of funds.
eBTC Protocol: Loss of user funds, as LeverageMacroReferences can't do an arbitrary system call to the function claimsSurplusCollShare in order to claim the extra surplus collateral gained from their liquidated or fully redeemed Cdps
eBTC's LeverageMacroReference is a user-deployable automation contract for opening, adjusting, and closing CDP positions plus performing swaps. When a CDP owned by a macro is fully redeemed or liquidated in recovery mode, the surplus stETH is deposited into CollSurplusPool and can only be reclaimed through borrowerOperations.claimSurplusCollShares(). Because the macro's _ensureNotSystem guard forbids arbitrary calls to borrowerOperations, and no dedicated claim-surplus operation exists in the macro, owners cannot withdraw that surplus, permanently trapping user funds. The sponsor confirmed the finding and the judge rated it high because assets are directly lost; a PoC demonstrating the revert is included.
eBTC Protocol: Redemptions are inconsistent with other cdp's operations
In the eBTC Protocol (Badger's Ethereum CDP lending system), redemptions are validated under weaker criteria than every other CDP-modifying operation. Closing a CDP or reducing its collateral is forbidden when doing so would push the system into recovery mode or keep it there, whereas a redemption only requires the system TCR and each target CDP's ICR to exceed the MCR. As a result, a redeemer can target a healthy CDP that is keeping the global system collateralized and drive the overall TCR below the recovery-mode threshold—a state unreachable through sanctioned operations. The most severe consequence is a fully undercollateralized system; the more probable one is an unintended entry into recovery mode. The sponsor confirmed the finding as valid under the specific condition of bad-debt CDPs, and plans to add a check, monitor the situation, and reserve eBTC for bad-debt liquidations rather than implement a complete code fix.