Kintsu — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Kintsu, 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 Kintsu 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, across EVM-Solidity, Move. 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 Kintsu
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Kintsu: unsynced `staked` value when unbond open for DOS
Kintsu's substrate/ink! staking vault tracks a cached `staked` balance that is only decremented within its own `start_unbond` function. However, the underlying NominationPools `Unbond` call can be invoked permissionlessly by any external party when a pool is undergoing destruction and the member is not the depositor, so the on-chain bonded amount can drop without the cached value being updated. Downstream, `get_weight_imbalances` reads that stale cached value to compute `delegate_unbonding` allocations, so an out-of-sync value corrupts the weight-based distribution of delegated funds. If a `delegate_unbonding` is then executed against the outdated accounting, the computed unbond amount for an agent exceeds the real bonded balance, the underlying call reverts, and the function returns an internal error — denying unbonding operations. The fix is to read the live pool value directly rather than trusting the locally cached `staked`.
Kintsu: Dos in send_batch_unlock_requests function due to invalid range for agent's boned AZERO
Kintsu's batch-unlock flow can be denied by a legitimate unstake request because the delegate_unbonding routine does not enforce the protocol rule that an agent's remaining bond must be either exactly zero or at least the configured minimum_stake. When a request distributes an unstake amount across multiple agents in a way that leaves one agent with a residual stake strictly between 0 and the minimum (0–10 AZERO in the example), that agent's unbond reverts and the revert propagates up, taking down the entire send_batch_unlock_requests call. Because there is no per-agent error isolation, any user that triggers this distribution is locked out of unstaking. The report's suggested fix is to validate each agent's post-unbond balance and adjust the unbond amount to skip the forbidden range.
Kintsu: Minimum Stake Not Checked for Each Nomination Agent
Kintsu's vault applies its 10 AZERO minimum-stake validation to the user's total deposit rather than to the amount each nomination agent receives after weight-based splitting. Because every agent's delegate_bonding call must individually satisfy the minimum, a deposit that splits into below-minimum per-agent allocations passes the initial check but reverts with CallRuntimeFailed. This denial-of-service breaks legitimate staking for correctly-sized deposits. The fix is to validate the smallest per-agent bond against the minimum stake before delegating.
Kintsu: Inconsistency in Nomination Pool Joining Logic
Kintsu's nomination-agent contract tracks pool membership through a single `staked` balance that is decremented during the `start_unbond` step rather than when the unbond completes in `withdraw_unbonded`. As a result, an agent who unbonds but never withdraws is left with `staked = 0` while still holding an open position, so its next deposit attempt hits the join guard that keys on the zeroed balance and reverts. This leaves the agent unable to re-enter the pool, a denial of service on the stake path. The reporter proposes decoupling membership from the burned-down balance with a dedicated `joined` flag that is set on join and cleared on withdrawal, while noting the boolean reset is not triggered in every withdrawal scenario.
Kintsu: KIN-H02: Malicious users can prevent other users from redeeming rewards by manipulating `total_pooled` with duplicate withdrawal requests
Kintsu's AZERO staking vault lets users request token unlocks and later batch-redeem them through send_batch_unlock_requests, which decrements the global total_pooled once per submitted batch id. The function rejects batch ids that were already unlocked but does not reject duplicate occurrences of the same id within a single call, so one withdrawal can be subtracted from total_pooled multiple times. By repeating a duplicate batch id, an attacker can drive total_pooled toward zero, after which legitimate send_batch_unlock_requests calls revert on underflow, permanently griefing every user's withdrawal. A Rust PoC demonstrates a single duplicated batch reducing total_pooled from 5,000,000 to 4,000,220 while only 500,000 was actually being withdrawn.
Kintsu: Potential DOS in `delegate_compound` Function
Kintsu's `delegate_compound` entry point iterates over all configured staking agents and invokes `nomination_agent::compound` on each, but any single reverting agent aborts the entire transaction. Because an agent that has not yet joined its nomination pool, or that has already reaped from it, will revert on compound, routine lifecycle states of one agent can brick compounding and delegation for all agents at once. The failure requires no special attacker capability and self-triggers under normal operation, so it is a genuine denial-of-service on the delegation flow. Two remediations were proposed: gate each agent's compound call with a check that it has joined the nomination pool, or mimic the existing withdraw path that lets the loop continue past a failing agent.