Truflation — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Truflation, 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 Truflation 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 Truflation
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Truflation: TrufVesting.cancelVesting calculates end of vesting incorrectly
TrufVesting.cancelVesting is an owner-only function that stops a user's token vesting, but it incorrectly computes whether a vesting has already finished. The function's reverting check compares block.timestamp against startTime plus only the per-period token distribution window, omitting the initialReleasePeriod and the cliff that occur first in the vesting schedule. Because of this, once the initial release window and cliff have elapsed but the final distribution is still ongoing, the check prematurely treats the vesting as completed and the owner cannot cancel it, preventing cancellation of still-active vestings.
Truflation: Users can fully drain the `TrufVesting` contract
Truflation's TrufVesting contract had a flaw in its `claimable` accounting: during the window after the initial release start but before the cliff, the function always returned the full `initialRelease` amount without subtracting tokens already claimed. Because `claim()` trusts `claimable` to bound the payout, any user could call `claim` repeatedly and withdraw `initialRelease` every time, letting them drain the entire contract balance through enough iterations. The issue was found by a large group of contestants, ruled Valid High by the judge, and fixed via a PR that subtracts `userVesting.claimed` from the returned amount.
Truflation: Ended locks can be extended
Truflation's VotingEscrowTruf lock-extend function lacked a validation check for whether a lock had already expired. A user whose stake had fully elapsed could call extendLock and set a new end timestamp that was still earlier than the current block time, leaving the "locked" position instantly unstakable while retaining its points and any voting weight. This effectively converted rigid escrow locks into flexible, withdraw-any-time positions, breaking the intended points-locking design and creating unfair conditions versus holders who kept funds genuinely locked.
Truflation: `cancelVesting` will potentially not give users unclaimed, vested funds, even if giveUnclaimed = true
The TrufVesting `cancelVesting` function intends to cancel a vesting grant and, when `giveUnclaimed` is true, pay the user any funds that have vested but not yet been claimed. The owner-triggered flow first unstakes a user's locked position and sets the local `userVesting.locked` to zero so the subsequent `claimable()` computation treats those newly-unlocked funds as claimable. Because `userVesting` is a `memory` copy, this zeroing never reaches on-chain storage, so `claimable()` still sees the full amount as locked and returns zero. As a result, a user who staked all their tokens receives nothing on cancellation even when `giveUnclaimed = true`, silently losing unclaimed vested funds. The sponsor confirmed the bug and fixed it by switching the struct to storage type so the `.locked = 0` write persists.