Covalent — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Covalent, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 6
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 6 closed, publicly disclosed Covalent 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, Front-running / MEV, Access control, 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 Covalent
- Front-running / MEV findings disclosed against Covalent
- Access control findings disclosed against Covalent
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Covalent: Validator cannot set new address if more than 300 unstakes in it's array
Covalent's CQT OperationalStaking contract lets a validator rotate its operator address via setValidatorAddress(), but the function only copies over the validator's accumulated Unstaking array and reverts if that array exceeds 300 entries, while no in-scope function can shrink the array. Because every _unstake() call appends a new entry, an attacker can stake a small amount and unstake 301 times to permanently fill a victim's (or their own) unstaking array, locking the validator to its current address. The README advertises an alternative to transfer an address without unstakings, but no such function exists in the audited scope, so a purported documented escape hatch is unavailable. The finding was upheld at medium severity after an escalation to invalid was withdrawn, and the protocol acknowledged and partially fixed the issue by ignoring zero-amount unstakes and enforcing the length cap.
Covalent: New staking between reward epochs will dilute rewards for existing stakers. Anyone can then front-run `OperationalStaking.rewardValidators()` to steal rewards
Covalent's OperationalStaking distributes validator rewards via rewardValidators(), which is callable only by the staking manager. The function weights all current stakes equally regardless of when within the epoch they were placed, so a stake made moments before distribution earns a full epoch's rewards proportionate to its size. A mempool-watching attacker can front-run the manager's distribution call with a large stake and capture a share of rewards without having supported the work during the epoch; the same funds can be recycled through recoverUnstaking() to repeat the attack. The judge confirmed this causes unfair reward distribution and rated it medium because no funds are directly lost, and the fix that shipped added a recoverUnstaking cooldown to deter re-entry cycling.
Covalent: Frontrunning validator freeze to withdraw tokens
Covalent's OperationalStaking contract implements a freeze mechanism to disable malicious validators, and a cooldown timelock on withdrawals. Two external functions, transferUnstakedOut() and recoverUnstaking(), omit the `!v.frozen` state check that gates every other entry point. This lets a validator bypass the freeze entirely by unstaking before (or even without) a freeze transaction lands, then withdrawing after the cooldown — including any unfairly accrued rewards. The finding was adjudicated Medium and confirmed unique, with the fix adding the frozen check to both functions and being signed off by the lead senior Watson.
Covalent: OperationalStaking may not possess enough CQT for the last withdrawal
Covalent's OperationalStaking converts between CQT tokens and staking shares using division that always rounds down against the user. This lets a user stake and unstake in amounts that leave a dust balance of shares on their account, which normally cannot be withdrawn because redemptions below REWARD_REDEEM_THRESHOLD revert. Once the unlocking multiplier rises enough that the accumulated dust crosses that threshold, the user can withdraw slightly more than their deposited stake plus earned rewards; if the net rounding across all other operations is zero for the protocol, the final CQT transfer will fail due to insufficient contract balance. The finding was judged valid at medium severity by Sherlock and fixed by rounding up sharesToBurn and sharesToRemove.
Covalent: OperationalStaking::_unstake Delegators can bypass 28 days unstaking cooldown when enough rewards have accumulated
Covalent's OperationalStaking contract distributes rewards evenly across all shares held for a validator, and redeeming rewards burns the equivalent shares. Because shares are burned rather than rewards tracked separately, a delegator can unstake rather than redeem, keeping the same share count while progressively converting the at-risk posted stake into claimable rewards that are not subject to the 28-day unstaking cooldown. This lets a delegator effectively withdraw funds immediately that should have been locked, creating an unfair risk-free position versus an honest delegator. The protocol acknowledged and fixed the issue in a follow-up PR, and the Lead Senior Watson signed off on the fix.
Covalent: `validatorMaxStake` can be bypassed by using `setValidatorAddress()`
Covalent's validator migration function, `setValidatorAddress()`, merges the old validator address's staked shares and staked amount onto the newly chosen address without re-checking the protocol's `validatorMaxStake` cap. Because the new address may already hold delegated stake, a validator who has reached the maximum can migrate to another address and stack stakes, pushing their combined balance past the enforced ceiling. This lets an individual validator accumulate more self-stake than the protocol intends, inflating their delegation capacity via `maxCapMultiplier` and letting them earn disproportionate rewards relative to other validators. The finding was confirmed and fixed by the Covalent team, which added a check preventing the new validator address's total stake from exceeding `validatorMaxStake`.