AlephZeroAMM — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for AlephZeroAMM, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed AlephZeroAMM 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 AlephZeroAMM
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
AlephZeroAMM: mint_fee` collects fee from adding and removing liquidity
AlephZeroAMM's Uniswap-v2-style pair contract miscomputes the k_last accumulator used by the protocol fee logic when liquidity is first provided. Because k_last is derived from a local reserves tuple that is still (0,0) on the initial mint, the sqrt(k_last)==0 branch in mint_fee is triggered, and roughly one sixth of subsequently added or removed liquidity is minted to the protocol fee collector even when no swaps have occurred. The write-up validates this with a Rust test that shows Charlie, the fee_to beneficiary, receiving one sixth of Bob's second liquidity deposit. The proposed fix is to compute k_last from the updated storage reserves after each mint and burn rather than from the zeroed local tuple.
AlephZeroAMM: The owner of a farm can steal already accumulated rewards
The AlephZeroAMM farm contract books accrued rewards against indices of a reward_tokens vector rather than unique token identities, creating an accounting corruption when the owner lists the same token more than once. By setting reward_tokens to [WOOD, WOOD] and starting a farm with rewards [0, amount], the duplicated first index accrues nothing while genuinely accumulated user rewards land under the second index. When the farm ends, the first index's zero-accrual state makes its computed undistributed balance equal the contract's entire token balance, so the owner's owner_withdraw_token call drains all WOOD that users had legitimately earned, leaving their accrued rewards unclaimable. The bundled Rust test demonstrates the owner ending with the total reward and the pool emptied of WOOD, contradicting the protocol's guarantee that past earned rewards cannot be manipulated.
AlephZeroAMM: Risk of Unintentional or Intentional User Rewards Prevention by Farm Contract Owner
AlephZeroAMM's farm contract allows its owner to withdraw reward tokens through owner_withdraw_token, which guards only on the farm not being currently active. Because that check also passes for a farm merely scheduled to begin in the future, the owner can drain the reward tokens while users still hold unclaimed rewards. When the future farm starts, users accrue additional rewards on top of pending ones and their claim_rewards call reverts with insufficient balance, permanently blocking them from their granted rewards. The finding is a griefing path that violates the farm's trust assumption that the owner cannot impair user claims.