Exactly Protocol Update - Staking Contract — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Exactly Protocol Update - Staking Contract, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed Exactly Protocol Update - Staking Contract 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 Integer overflow / underflow, 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
- Integer overflow / underflow findings disclosed against Exactly Protocol Update - Staking Contract
- Logic error findings disclosed against Exactly Protocol Update - Staking Contract
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 Update - Staking Contract: Precision Loss in `notifyRewardAmount` Function Causes Unclaimable RewardToken
The StakedEXA staking contract computes its reward distribution rate with integer division that truncates the remainder, so when notifyRewardAmount is called the actual distributable amount (rate * duration) falls short of the tokens deposited. Because the contract has no function to recover the leftover dust, the truncation permanently locks a small portion of each reward deposit inside the contract. The report demonstrates this with a PoC using WBTC as the reward token, where roughly 0.0026 WBTC (worth over $100) remains stranded after a 30-week distribution to a single staker. The protocol acknowledged and fixed the issue, and Sherlock's lead senior Watson signed off on the fix.
Exactly Protocol Update - Staking Contract: Depositing to another receiver othan than `msg.sender` will lead to stuck funds by increasing `avgStart` without claiming
Exactly's StakedEXA staking contract calls its internal reward-claiming routine for msg.sender whenever a new deposit is recorded in _update(), but credits the newly minted staked position to the `to` receiver rather than msg.sender. When a deposit is made to an already-staked address, the receiver's avgStart timestamp is advanced to weight the new principal, yet the receiver's accrued rewards are never claimed first, so those rewards stop being claimable via the normal path; if the receiver then unstakes they are swept to savings and lost. The flaw was judged Medium and fixed by making the claim target the actual receiver.
Exactly Protocol Update - Staking Contract: Some bad debt will not be cleared when it should which will cause accrual of bad debt decreasing the protocol's solvency
In Exactly's staking contract update, `Market::clearBadDebt()` compares the `earningsAccumulator` against the bad debt to clear BEFORE adding the fixed pool's unassigned earnings into the accumulator. When a liquidated borrower's bad debt is larger than the accumulator on its own, the function bails out even though adding the pool's unassigned earnings would have made the accumulator sufficient. As a result, bad debt that could have been absorbed is left uncleared, gradually eroding the protocol's solvency and increasing insolvency risk for users. The issue was acknowledged by the protocol and assigned a medium severity finding in the Sherlock contest.
Exactly Protocol Update - Staking Contract: Liquidator will leave a pool with unassigned earnings on `Market::clearBadDebt()` free to claim for anyone when the repaid maturity is not the last
In Exactly's Market contract, the earningsAccumulator is only credited with a maturity pool's unassigned earnings during clearBadDebt when fixedPools[maturity].borrowed equals position.principal, which is always zero after the borrower's fixed borrow position is deleted. As a result, unassigned earnings are only swept to the accumulator when the repaid maturity is the last one with outstanding borrows. If other maturities remain borrowed, the unassigned earnings stay stranded in the pool, and any user can capture the full amount by supplying a dust deposit at maturity. The finding is a medium-severity logic error that lets an attacker extract value belonging to the protocol's earnings accumulator, sometimes with a deposit of only 1 wei.
Exactly Protocol Update - Staking Contract: Market utilization ratio near 100% will DoS deposits as harvest tries to withdraw and reverts
StakedEXA's deposit flow triggers a harvest that withdraws supply from the underlying Exactly market without first checking whether the market holds enough protocol liquidity to satisfy the withdrawal. When borrowers drive the market's utilization ratio to its ceiling (~100%), that withdrawal reverts, which makes every subsequent deposit revert in turn. The result is a denial of service on staking deposits that freezes new depositors out and lets existing depositors capture the surplus yield; the finding was accepted as Medium and fixed in a follow-up PR.
Exactly Protocol Update - Staking Contract: Frozen/paused Market that is harvested from in StakedEXA will DoS deposits leading to loss of yield
In Exactly's StakedEXA staking contract, the mint path triggers harvest(), which unconditionally withdraws accumulated rewards from the designated provider market. If that market has been paused or frozen, the withdrawal reverts, which propagates up through _update and causes every StakedEXA deposit to revert. Because users' EXA deposits never sit in the market — they stay in the StakedEXA contract while the market merely supplies yielded rewards — there is no reason deposits should halt when the market is paused. As a result new users are locked out of accruing rewards while existing depositors enjoy a disproportionate share of the yield. The finding was contested on the ground that admin pausing is out of scope, but the judge upheld it as Medium/Unique because the paused entity is a separate integration contract with its own admin; the fix (skip harvesting when the market is paused/frozen) was applied and signed off.
All reports in this group
- Exactly Protocol Update - Staking Contract: Setting a new market will make depositing to the market impossible when harvesting, DoSing depositsLogic error$0
- Exactly Protocol Update - Staking Contract: Having no deposits in `StakedEXA` will lead to stuck rewards when harvestingLogic error$0
- Exactly Protocol Update - Staking Contract: Attackers will reset `avgStart` of any user making rewards stuck for longer and get lost to savingsLogic error$0