Canto — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Canto, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Canto 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 Governance attack, 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
- Governance attack findings disclosed against Canto
- Integer overflow / underflow findings disclosed against Canto
- Logic error findings disclosed against Canto
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Canto: Improper adjustment of Lending Ledger configuration
The Canto LendingLedger approximates elapsed time from block numbers using adjustable parameters, and lets governance reconfigure per-block rewards and block-time parameters via setRewards and setBlockTimeParameters. Because these values apply retroactively from an epoch boundary, any market whose update_market was not called on the exact same block as the reconfiguration receives incorrect reward accrual, over- or under-counting depending on the adjustment direction. The report shows via a foundry PoC that rewards drifted from the expected amount and then demonstrates that the misconfiguration cannot always be safely corrected (e.g., updating all markets may exceed gas limits). Sponsor and judge confirmed the issue, framing it as an operational/timing vulnerability distinct from plain administrator input mistakes.
Canto: Loss of precission when calculating the accumulated CANTO per share
Canto's LendingLedger.update_market accumulates per-share CANTO rewards for each lending market, but the reward accumulation expression divides by 1e18 in the cantoReward computation and then multiplies by 1e18 again in the accCantoPerShare update, causing integer-division rounding that loses precision. This rounding can silently suppress reward accrual — the sponsor confirmed losses of up to roughly 1 CANTO per rounding instance (or a value being rounded to zero when the compounded term is below 1e18), meaning users receive marginally fewer rewards than the protocol intended. The finding was confirmed by the Canto team and upheld as Medium by the judge, with a simple reorder-to-multiply-first fix.
Canto: secRewardsPerShare Insufficient precision
The Canto lending market's `secRewardsPerShare` accumulator accrues secondary rewards used by the Neofinance Coordinator with the same 1e18 precision as the cNOTE `marketSupply` denominator. Whenever market supply exceeds one token and the per-block delta is small relative to supply, the integer division truncates the increment to zero, so the accumulator (and the `secRewardDebt` difference tracking it) never reflects reward growth. Integrated lending platforms consequently compute zero additional yield for borrowers, causing a systemic but non-principal loss of yield. The judge rated the issue Medium, the sponsor confirmed, and the proposed fix raises accumulator precision to 1e27.
Canto: update_market() market weight incorrect
Canto's LendingLedger rewards distribution computes a reward epoch from a block number in update_market() but passes that value as a timestamp into GaugeController.gauge_relative_weight_write(), which internally divides by WEEK (7 days) to look up gauge weight. Since a Canto block number (~7.9M) divides down to a 1970 time period, the gauge weight resolves to zero and the market accrues no Canto rewards even though cantoPerBlock[epoch] is funded. The unit mismatch means the weight lookup hits a non-existent historical slot, collapsing the reward multiplier to zero while still advancing lastRewardBlock. The sponsor confirmed the epoch used "time in the past," and the judge rated it High because at current block heights it causes a total loss of rewards and at other heights an incorrect reward amount.