Basin — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Basin, 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 Basin 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 Access control, Integer overflow / underflow, 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
- Access control findings disclosed against Basin
- Integer overflow / underflow findings disclosed against Basin
- Logic error findings disclosed against Basin
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Basin: `WellUpgradeable` can be upgraded by anyone
The `WellUpgradeable` contract, which utilizes the UUPS proxy pattern, incorrectly implements its upgrade authorization logic, allowing any arbitrary user to upgrade the contract. By failing to include an `onlyOwner` modifier on the internal `_authorizeUpgrade` function, the contract exposes its upgrade functionality to unauthorized parties. This vulnerability permits an attacker to deploy a malicious contract implementation, effectively allowing them to hijack the proxy and compromise the entire contract's integrity and assets.
Basin: Incorrectly assigned `decimal1` parameter upon decoding
A logic error in the Stable2.sol contract's decimal decoding function incorrectly defaults token decimals to 18. Due to a faulty conditional check, the contract fails to normalize decimal values for the second token when the first token's decimal value is non-zero, leaving the second token with zero decimals. This error propagates to critical pricing and liquidity functions, resulting in arithmetic panics and incorrect asset valuation during pool operations.
Basin: For extreme ratios, `getRatiosFromPriceSwap` will return data for which is impossible to converge into a reserve
The Basin protocol's `Stable2LUT1` lookup table implementation contains a logic error where certain price ranges return a `PriceData` struct with an excessively large gap between high and low price boundaries. This misconfiguration causes the `calcReserveAtRatioSwap` and `calcReserveAtRatioLiquidity` functions to fail during their iterative reserve calculation process. Instead of converging on the target price, the calculation creates large jumps that cause the price to move further away from the target in each iteration, leading to significantly inaccurate reserve results or function failure.
Basin: In `Stable2LUT1::getRatiosFromPriceLiquidity`, in extreme cases, `updateReserve` will start breaking
The Basin protocol's `Stable2LUT1` liquidity calculation logic suffers from numerical instability due to overly aggressive parameterization in its lookup table. Under extreme price conditions, the solver attempts to perform reserve corrections that exceed the current reserve balance, triggering a revert via integer underflow. In cases where the step size is reduced to prevent underflow, the excessive width of the defined price ranges prevents Newton's method from converging within its iteration limit, causing the function to fail and return incorrect data. This combination of issues renders the affected liquidity functions unusable under specific, reachable market conditions.