Exactly Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Exactly 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 Exactly Protocol reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, 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 Exactly Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Exactly Protocol: Utilization rates are 0 when average assets are 0, which may be used to game maturity borrows / deposits / withdrawals
Exactly Protocol's interest-rate model returns a utilization ratio of 0 whenever the average floating assets are 0, including the first-block state after a market is deployed when the exponential average dampening factor has not yet kicked in. Combined with floatingAssetsAverage starting at 0, a user can deposit and borrow in the same block (or whenever assets sit at zero) and obtain a fixed-rate loan at the lowest possible interest even while the market is at its highest utilization. The fixed fees owed end up unassigned and later convert to floating assets, effectively letting the borrower pay far less than lenders are owed. Sherlock accepted the reporter's escalation and adjudicated the issue as Medium severity.
Exactly Protocol: borrow() maliciously let others to enter market
In Exactly Protocol's Market contract, the borrow() function lacked a check that the assets argument is non-zero. Because spendAllowance() is skipped when assets is zero, any caller — without any approval from the borrower — could invoke borrow(0, receiver, victim) to force the victim into a market via Auditor's checkBorrow() registration. Sherlock adjudicated this as Medium: the attacker can place a borrower's deposited funds at risk of being seized as collateral during a liquidation, or enable an approved party to borrow against collateral the borrower never intended to be used, despite the borrower being able to exit the market. The team fixed it by reverting on zero borrows.
Exactly Protocol: Liquidation does not prioritize lowest LTV tokens
Exactly Protocol's partial-liquidation flow lets a liquidator select which market to repay/seize, but nothing guarantees the resulting health factor improves. Because a borrower's adjusted collateral and debt scale differently with each asset's risk-adjust factor, liquidating in a high-LTV asset can leave the health factor flat or lower, letting the same liquidator re-liquidate the borrower while the protocol accumulates bad-debt risk. The adjudicated finding (Sherlock Medium, has duplicates) proposes validation that partial liquidation always improves the post-liquidation health factor.
Exactly Protocol: Manipulation of the floating debt by updating `floatingBackupBorrowed`
Exactly's fixed-pool entry points updated the market utilization factor floatingBackupBorrowed without first accruing outstanding floating debt, so the past debt was recomputed at the manipulated utilization. An attacker could call withdrawAtMaturity near maturity to inflate floatingBackupBorrowed, retroactively raising accrued interest paid by floating borrowers, profiting floating lenders at borrowers' expense and pushing some borrowers into liquidation. The issue was confirmed as medium-severity (Sherlock contest 247) and fixed by the protocol in PR 722.
Exactly Protocol: Bad debt isn't cleared when `earningsAccumulator` is lower than a fixed-pool bad debt
Exactly Protocol's Market.clearBadDebt only wipes a fixed-pool borrower's bad debt when the market's earningsAccumulator is greater than or equal to the bad debt amount. When the accumulator is slightly smaller than the debt, the function clears nothing, leaving the bad debt permanently tracked in the system. If this happens repeatedly, untracked/uncleared bad debt accumulates and inflates the tracked floating assets relative to actual funds, which can trigger a bank run where later withdrawers cannot get their funds. The fix is to allow partial clearing of up to the full accumulator amount even when it does not cover the whole bad debt.
Exactly Protocol: Unassigned pool earnings can be stolen when a maturity borrow is liquidated by depositing at maturity with 1 principal
In Exactly Protocol's fixed-rate market, liquidating a borrower's maturity loan calls noTransferRepayAtMaturity() with canDiscount=false, so unassigned pool earnings are not folded into the earningsAccumulator and subtracted from the repay. Those earnings later accrue to floatingAssets and are claimable by the next maturity depositor. An attacker can deposit 1 wei principal, borrow 1 wei at maturity to make floatingBackupBorrowed exceed supply, and then deposit 1 wei at maturity to capture the entire unassigned earnings of the liquidated pool (shown reaching ~6.657e18 token value). The team fixed this by converting unassigned earnings to the time-based earningsAccumulator during liquidation, and the fix was signed off by the Lead Senior Watson.