`VaderMath.sol#calculateSwap()` Wrong design/implementation of slippage control

[code423n4]

Handle

WatchPug

Vulnerability details

Per the whitepaper:

The liquidity model includes a liquidity-sensitive slip-based fee ... Slip-based fees break path-independence and a member can theoretically achieve better price execution by making smaller trades.

However, as we examined and tested the algorithm of swap and slippage control, we believe the current design/implementation is flawed.

PoC

Given:

• A Vader pool with the reserves of 200,000 USDV and 2 BTC;
• A Uni V2 (0.3% fee) pool with the same reserves (200,000 USDC and 2 BTC).

The pricing premium only applies to very small trades (<0.025% of the reserve), and it starts to become negative very fast:

1. If Alice swap 0.005 BTC to USDV via the Vader pool, the output will be 497.50 USDV;
2. If Bob swap 0.005 BTC to USDV via the Uni v2 pool, the output will be 497.26 USDV (Vader premium: 0.05%);
3. If Alice swap 0.015 BTC to USDV via the Vader pool, the output will be 1477.75 USDV;
4. If Bob swap 0.015 BTC to USDV via the Uni v2 pool, the output will be 1484.40 USDV (Vader premium: -0.45%).

Essentially, to make a relatively small trade favorable through the Vader pool, considering the avg gas cost, let's say for a trade of $2,500 worth of assets, would need at least $10M worth of reserve, or $20M of total liquidity in that LP pool. Otherwise, it's not favorable in comparison to a 0.3% Uni v2 pool.

Furthermore, the slip-based fee on the Vader pool can be bypassed simply by creating a wrap contract that splits larger swaps into smaller ones:

1. If Alice swap 1 BTC to USDV via the Vader pool, the output will be 44444.44 USDV;
2. If Alice swap thru a wrapper contract that splits it into 10 trades of 0.1 BTC each, the total output will be 64427.80 USDV.

[SamSteinGG]

This is the intended design of the CLP model as it clearly states small trades are favored over large ones and it is a liquidity sensitive AMM.

[alcueca]

Dispute accepted as a design decision.