Paladin — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Paladin, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 11
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 11 closed, publicly disclosed Paladin reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Reentrancy, Signature replay, Front-running / MEV, 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 Paladin
- Reentrancy findings disclosed against Paladin
- Signature replay findings disclosed against Paladin
- Front-running / MEV findings disclosed against Paladin
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Paladin: Unbounded proxy length in LootVoteController can cause function to become unusable
Paladin's LootVoteController stores every voter proxy a user approves in an ever-growing array, and its internal _clearExpiredProxies cleanup iterates the full array on each setVoterProxy call. Because approved proxy managers can append new entries without limit, the loop's gas cost scales linearly with the number of historical proxies. Once enough additions accrue, any setVoterProxy or proxy-management transaction for that user — including calls by a legitimately separate manager — reverts from gas exhaustion, permanently locking the victim's voting setup. A Foundry PoC confirms roughly five thousand additions pushes the cleanup loop past millions of gas.
Paladin: Division by Zero in `_createLoot` when Distributor change `lootCreator`, prevent Users from creating previous Loot
Paladin's Merkle-based rewards pipeline pairs a MultiMerkleDistributorV2, which allows users to claim past-period rewards after the current cycle, with a LootCreator that mints loot proportional to a user's period reward ratio. The Distributor's setLootCreator lets the owner swap the LootCreator address without restriction, and every claim forwards a notifyQuestClaim to whichever creator is currently installed. Because the replacement LootCreator never inherits the old contract's totalQuestPeriodRewards for earlier periods, a user claiming a past-period reward hits a divide-by-zero during the reward ratio computation in _createLoot, reverting the entire claim. After any LootCreator change, users are unable to create loot for any prior period, an availability break that blocks legitimate, already-earned rewards.
Paladin: There's no guarantee that the period updates continuously in LootCreator
Paladin's LootCreator distributes weekly PAL and extra-token bribes to gauges, tracking the current reward period via the state variable nextBudgetUpdatePeriod. That checkpoint is initialized in the constructor and advanced by exactly one WEEK inside _updatePeriod, which also has an early-return guard when block.timestamp is still before the checkpoint. Because _updatePeriod only runs piggybacked on distributor notifications, the checkpoint can lag real time by many weeks whenever claim activity is sparse. When a distributor then notifies a quest for a period ahead of the checkpoint, that period's budget was never materialized, so periodBudget, gaugeBudgetPerPeriod, and periodBlockCheckpoint are zero or stale; the gauge gets flagged allocated once with zero funds and _createLoot derives user reward shares from an uninitialized block checkpoint, permanently preventing users from claiming the expected rewards for that period.
Paladin: Some rewards are being duplicated
Paladin's LootCreator double-counts quest reward budget whenever a gauge's relative weight exceeds its configured cap. In notifyDistributedQuestPeriod the cap-exceeding excess is folded into the pending budget for future periods, yet that same excess is never recorded in the current period's allocated budget history. On the next _updatePeriod, the pre-pended excess plus the recomputed remainder from the understated allocation record cause the excess to be counted twice, permanently inflating every subsequent period's reward budget. The write-up marks this as an accounting/logic error reachable through ordinary gauge weight fluctuations and supplies a fix that also marks the excess as allocated.
Paladin: Incorrect Allocation results in `getQuestAllocationForPeriod` when `questRewardToken` has Decimals other than 18
Paladin's quest-reward distribution logic miscalculates per-vote allocations whenever a granted quest rewards voters in a token that doesn't use 18 decimals (such as USDC's 6). The MultiMerkleDistributorV2 stores the raw per-period reward amount for the quest, and LootCreator._getQuestAllocationForPeriod then divides the budget by that total while fixing the UNIT multiplier at 1e18, producing palPerVote and extraPerVote values scaled to roughly 30 decimals instead of the intended precision. Because USDC is explicitly whitelisted and offered in the quest-creation UI, the faulty path is reachable in normal operation. The result is that voter incentive entitlements are mathematically wrong for any quest paid in a non-18-decimal token, misallocating rewards rather than enabling direct theft. The fix is to normalize the quest total to 18 decimals via a conversion factor based on the token's own decimal count.
Paladin: userQuestPeriodRewards` will be overwritten on second claim
Paladin's quest reward claim flow keys each user's claim record by the Merkle-tree index rather than by the user's address for a given quest and period. When an emergency update to a quest period publishes a new Merkle root that grants an additional claim index to a user who already claimed for that same questId and period, that user may legitimately claim twice. Each claim invokes LootCreator's notifyQuestClaim, which writes userQuestPeriodRewards with an '=' assignment rather than accumulating with '+='. As a result the second claim overwrites the first, permanently under-recording the user's aggregate rewards for that distributor, quest and period.
All reports in this group
- Paladin: Past loots can be indefinitely recreated Logic error$0
- Paladin: Changes of `questRewardsPerPeriod` didn't reflected on LootCreator's `totalQuestPeriodRewards`Reentrancy$0
- Paladin: Loot.sol - Updating the vestingDuration with active vests can lead to unexpected slashingLogic error$0
- Paladin: EIP712 chainId is hardcoded which can cause replay attacks in case of hardforkSignature replay$0
- Paladin: Possible to grief and prevent all users from claiming via front-running `multiClaim()` callsFront-running / MEV$0