Tigris Trade contest - Tointer's results

Lines of code

https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/StableVault.sol#L44-L72

Vulnerability details

StableVault.sol can be used by anyone to change stables. This is basically AMM pool with x+y = const function and zero fees. It means that:

1. Users are providing liquidity for nothing
2. When users would want to withdraw, it's guaranteed that they would get worst token out of the list. This is because arbitrage bots would provide cheap stablecoins to contract while withdrawing all others. This means that users that want to rotate funds swiftly, would always leak value, trading temporarily cheap stablecoins to other assets.
3. Balance of a whole system equals to stable token amount * cheapest stablecoin in the pool. If one depegs, all users would lose. And there is no compensation for that risk.

Recommended Mitigation Steps

There are different approaches to fix it:

1. Use Curve-like mechanism to compensate for higher risks and LPing
2. Use only one stablecoin
3. Ensure that one user could use only one one stablecoin. This would require manual rebalance of stablecoins from time to time.

Judge has assessed an item in Issue #351 as M risk. The relevant finding follows:

Stable Vault cannot accept tokens with more then 18 decimals because of this lines: https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/StableVault.sol#L49 https://github.com/code-423n4/2022-12-tigris/blob/588c84b7bb354d20cbca6034544c4faa46e6a80e/contracts/StableVault.sol#L67 Consider using different conversion formula. For example: amount * 1e18 / 10token.decimals() for deposit and amount * 10token.decimals() / 1e18 for withdraw