Salty.IO — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Salty.IO, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 28
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 28 closed, publicly disclosed Salty.IO 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 Governance attack, Oracle manipulation, Reentrancy, Access control, 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
- Governance attack findings disclosed against Salty.IO
- Oracle manipulation findings disclosed against Salty.IO
- Reentrancy findings disclosed against Salty.IO
- Access control findings disclosed against Salty.IO
- Logic error findings disclosed against Salty.IO
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Salty.IO: Some rewards from POL will not be send to team wallet nor burned
The protocol failed to properly account for and distribute rewards generated when removing Protocol Owned Liquidity (POL) during upkeep operations. Because the liquidity removal process triggered automatic reward claims without being captured by the distribution logic, these funds were trapped in the contract instead of being burned or sent to the team as intended. This accounting error resulted in unclaimed rewards accumulating in the contract. The issue was resolved by removing the POL mechanism from the protocol entirely.
Salty.IO: Adversary can prevent updating price feed addresses by creating poisonous proposals ending in `_confirm`
The Salty.IO protocol's DAO governance mechanism was vulnerable to a denial-of-service attack due to predictable ballot naming conventions. By creating proposals with a specific '_confirm' suffix, attackers could block legitimate administrative actions, including the necessary updating of price feed contract addresses. This prevented the DAO from managing critical protocol parameters, which could have led to outdated or incorrect data being used in lending and liquidation operations.
Salty.IO: Impossible to change managed wallets with `proposeWallets` after first rejection
The ManagedWallet contract contained a state-management flaw that caused a permanent denial of service for administrative configuration changes. When the confirmation wallet rejected a proposed wallet change, the contract failed to reset the pending proposal address, leaving it in a non-zero state. Because the contract's logic prevented new proposals if a previous one remained pending, this rejection rendered the functionality permanently unusable for all future administrative updates.
Salty.IO: Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards
Salty.IO suffers from a state-persistence bug where liquidity reward accounting data, specifically arbitrage profits, is not cleared when a pool is unwhitelisted. This creates an opportunity for stale reward accounting to bleed into the active state if the pool is subsequently re-whitelisted. This discrepancy causes an unfair inflation of liquidity rewards for the re-added pool, diluting the rewards legitimately earned by other active pools.
Salty.IO: Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST
The Pools contract at Salty.IO contained a critical validation flaw in the removeLiquidity function intended to protect pool reserves. A typo in the require statement caused the contract to check reserve0 twice, completely omitting the check for reserve1. This allowed liquidity removal operations to leave reserve1 at amounts below the required DUST threshold, potentially destabilizing pool ratios or causing failures in subsequent operations like swaps.
Salty.IO: Attacker can take advantage of Chainlink price not occuring within it's 60 minute heartbeat to make PriceAggregator calls fail
Salty.IO's collateral pricing mechanism contained a vulnerability that allowed an attacker to induce a Denial of Service (DoS) during periods of oracle latency. When the primary Chainlink price feed failed to update within a 60-minute window, the protocol automatically fell back to using spot reserve ratios from internal liquidity pools. An attacker could exploit this by using flash loans to significantly skew these pool reserves, forcing the protocol's PriceAggregator to compare highly divergent price values and revert, effectively halting essential lending operations.
All reports in this group
- Salty.IO: Persistent Contract Call revert prevents finalizing a ballotGovernance attack$0
- Salty.IO: User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidatedReentrancy$0
- Salty.IO: Development Team might receive less SALT because there is no access control on `VestingWallet#release()`Access control$0
- Salty.IO: First Liquidity provider can claim all initial pool rewardsLogic error$0
- Salty.IO: First depositor can break staking-rewards accountingLogic error$0
- Salty.IO: Minimium Collateral Check Can Be BypassedOracle manipulation$0
- Salty.IO: Incorrect assumption in PoolMath.sol can cause underflow when zapping is usedInteger overflow/underflow$0
- Salty.IO: Suboptimal arbitrage implementationInteger overflow/underflow$0
- Salty.IO: Creation of token whitelisting proposals can be DOS'dReentrancy$0
- Salty.IO: MinShares Slippage Parameters Are Ineffective For Initial DepositFront-running / MEV$0
- Salty.IO: StakingRewards pools are not given their promised share of rewards due to incorrect calculationGovernance attack$0
- Salty.IO: When forming POL the DAO will end up stucked with DAI and USDS tokens that cannot handleGovernance attack$0
- Salty.IO: Salt Rewards - Rewards related to Arbitrage profits for pools can be lostPrice manipulation$0
- Salty.IO: No proposal time limit traps sponsors of unpopular proposalsReentrancy$0
- Salty.IO: Attacker Can Inflate LP Position Value To Create a Bad Debt LoanOracle manipulation$0
- Salty.IO: Incorrect calculation to check remaining ratio after reward in StableConfig.solOracle manipulation$0
- Salty.IO: The user who withdraws liquidity from a particular pool is able to claim more rewards than they should by carefully selecting a `decreaseShareAmount` value such that the `virtualRewardsToRemove` is rounded down to zeroInteger overflow/underflow$0
- Salty.IO: If there is only one USDS borrower, he can never be liquidatedOracle manipulation$0
- Salty.IO: changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehandGovernance attack$0
- Salty.IO: Caller of Upkeep may skip step 11 to save gasGovernance attack$0
- Salty.IO: Ballots not yet past their deadline are incorrectly looped too by tokenWhitelistingBallotWithTheMostVotes()Governance attack$0
- Salty.IO: formPOL lacks slippage and deadline protectionOracle manipulation$0