Dango DEX — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Dango DEX, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Dango DEX 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 Cosmos-SDK. 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 Dango DEX
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Dango DEX: The first Liquidity Provider can perform a fee less swap by providing unbalanced liquidity.
Dango DEX's initial liquidity provisioning for empty pools skips the simulated-swap fee charge that applies to unbalanced liquidity in non-empty pools. As a result, the first liquidity provider can deposit a single-sided amount into an empty pool, wait for a subsequent balanced deposit from another LP, and then withdraw their share of the now-balanced reserves — capturing the price differential without paying any swap fee. This effectively grants the first LP a fee-free swap that normal users would be charged for, violating the protocol's fee accounting invariant.
Dango DEX: A newly deployed pool can be DoS
A freshly deployed Dango DEX pool can be permanently bricked (DoS) by any caller supplying exactly zero of both base and quote assets as the very first liquidity provision. Because the code never validates that the initial deposit amounts or the first LP token mint are non-zero, the pool ends up in a state where reserves are still zero but LP supply is non-zero. Every subsequent liquidity provision then invokes add_subsequent_liquidity, which divides by the zero invariant/reserve value and reverts with an arithmetic error, leaving the pool unable to ever operate.