Salty.IO - Mitigation Review details

• Total Prize Pool: $30,000 in USDC
• Warden guidelines for C4 mitigation reviews
• Submit findings using the C4 form
• Starts March 1, 20:00 UTC
• Ends March 11, 20:00 UTC

Important note

Each warden must submit a mitigation review for every High and Medium finding from the parent audit that is listed as in-scope for the mitigation review along with the Additional Scope to be Reviewed section. Incomplete mitigation reviews will not be eligible for awards.

Findings being mitigated

Mitigations of all High and Medium issues will be considered in-scope and listed here.

• H-01: Development Team might receive less SALT because there is no access control on VestingWallet#release()

• H-02: First Liquidity provider can claim all initial pool rewards

• H-03: The use of spot price by CoreSaltyFeed can lead to price manipulation and undesired liquidations

• H-04: First depositor can break staking-rewards accounting

• H-05: User can evade liquidation by depositing the minimum of tokens and gain time to not be liquidated

• H-06: When borrowers repay USDS, it is sent to the wrong address, allowing anyone to burn Protocol Owned Liquidity and build bad debt for USDS

• M-01: THE USER WHO WITHDRAWS LIQUIDITY FROM A PARTICULAR POOL IS ABLE TO CLAIM MORE REWARDS THAN HE DULY DESERVES BY CAREFULLY SELECTING A decreaseShareAmount VALUE SUCH THAT THE virtualRewardsToRemove IS ROUNDED DOWN TO ZERO

• M-02: Persistent Contract Call revert prevents finalizing a ballot

• M-03: Creation of token whitelisting proposals can be DOS'd

• M-04: If there is only one USDS borrower, he can never be liquidated

• M-05: Absence of autonomous mechanism for selling collateral assets in the external market in exchange for USDS will cause undercollateralization during market crashes and will cause USDS to depeg.

• M-06: Reusing a SALT that has already been used for voting can allow a malicious proposal to pass and compromise the protocol.

• M-07: Impossible to change managed wallets with proposeWallets after first rejection

• M-08: PriceFeed is likely to be disabled in times of volatility, causing liquidations and borrows to freeze

• M-09: Remove Liquidity has missing reserve1 DUST check, which can make reserve1 to be less than DUST

• M-10: Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards.

• M-11: SALT staker can get extra voting power by simply unstaking their xSALT

• M-12: DOS of proposals by abusing ballot names without important parameters

• M-13: Adversary can prevent updating price feed addresses by creating poisonous proposals ending in _confirm

• M-14: Ballots not yet past their deadline are incorrectly looped too by tokenWhitelistingBallotWithTheMostVotes()

• M-15: Attacker can take advantage of Chainlink price not occuring within it's 60 minute heartbeat to make PriceAggregator calls fail

• M-16: Suboptimal arbitrage implementation

• M-17: Caller of Upkeep may skip step 11 to save gas

• M-18: _getUniswapTwapWei() will show incorrect price for negative ticks cause it doesn't round up for negative ticks.

• M-19: No proposal time limit traps sponsors of unpopular proposals

• M-20: Some rewards from POL will not be send to team wallet nor burned

• M-21: When forming POL the DAO will end up stucked with DAI and USDS tokens that cannot handle.

• M-22: Minimium Collateral Check Can Be Bypassed

• M-23: StakingRewards pools are not given their promised share of rewards due to incorrect calculation

• M-24: Salt Rewards - Rewards related to Arbitrage profits for pools can be lost

• M-25: Incorrect assumption in PoolMath.sol can cause underflow when zapping is used

• M-26: formPOL lacks slippage and deadline protection

• M-27: Attacker Can Inflate LP Position Value To Create a Bad Debt Loan

• M-28: MinShares Slippage Parameters Are Ineffective For Initial Deposit

• M-29: Incorrect calculation to check remaining ratio after reward in StableConfig.sol

• M-30: Chainlink price feed uses BTC, not WBTC. In case of depegging, oracles will become easier to manipulate.

• M-31: changeWallets() can be confirmed immediately after proposalWallets() by manipulating activeTimelock beforehand

Overview of changes

To decrease the risk profile of the exchange and focus on the core features provided by automatic arbitrage, the USDS stablecoin and all associated functionality (price feeds, collateral, liquidizer, etc) have been completely removed. The stablecoin was largely isolated from the rest of the project, but this did refactor the way Upkeep works.

Resulting from the stablecoin being removed all tokens are now paired with WETH and USDC rather than WETH and WBTC (which was previously done to provide increased yield for now removed collateral).

Also, the ManagedWallet contract has been removed - with the teamVestingWallet now targeting a simple teamWallet address.

To prevent any swaps from occurring during performUpkeep, Protocol Owned Liquidity has been removed. Additionally, on user swap any WETH profits that are generated are swapped immediately to SALT - rather than being done in performUpkeep.

In response to a suggestion by one of the wardens in the original competition, the ArbitrageSearch mechanism has been refactored and optimized extensively:
https://github.com/code-423n4/2024-01-salty-findings/issues/419

Users are now limited to one swap per block due to an issue found in which arbitrage could be bypassed by dividing up individual swaps into tens or hundreds of swaps. Without the limitation and due to the protocol's reletively low gas costs for swap and arbitrage, attackers would otherwise be able to perform multiple swaps in one transaction - effectively bypassing arbitrage and the rebalancing done that discourages manipulation. While multiple wallets could still be used on such an attack, the gas costs incurred on the multiple separate swap transactions are considered a sufficient deterrent.

Mitigations to be reviewed

Additional scope to be reviewed

Individual PRs

These are additional changes that will be in scope and were addressed outside of direct mitigation. (EXTRA Scoope)

Out of Scope

Please list any High and Medium issues that were judged as valid but you have chosen not to fix.
M-10
M-17
M-23
M-24