massive swap (relative to liquidity) destroys the pool (just happened on DIS)
- Dominant language
- C++
- Stars
- 397
- Forks
- 129
- PR merge metrics
- No merged PRs in 30d
Description
As just happened on mainnet after DIS was added: the pool was still nearly empty and someone tried to swap 4500$ into DIS, moving the pool by 20897985072.5% basically clearing the DIS side.
state of the pool afterwards:
```
"69": {
"symbol": "DIS-DUSD",
"name": "dDIS-Decentralized USD",
"status": true,
"idTokenA": "65",
"idTokenB": "15",
"reserveA": 2.7e-7,
"reserveB": 5595.15430529,
"commission": 0.002,
"totalLiquidity": 0.03880735,
"reserveA/reserveB": 0,
"reserveB/reserveA": 20722793723.296295,
"tradeEnabled": false,
"ownerAddress": "8UAhRuUFCyFUHEPD7qvtj8Zy2HxF5HH5nb",
"blockCommissionA": 0,
"blockCommissionB": 0,
"rewardPct": 0,
"rewardLoanPct": 0,
"creationTx": "a6808654ee52eeec740ffa7984b22f0ecddf211c4a5bc24283d72ad5a6e532eb",
"creationHeight": 1755379
}
```
since reservesA is now < SLOPE_SWAP_RATE you can't even bring it back cause it always returns "Lack of Liquidity". and adding enough liquidity will need huge amounts of $ (roughly 200k) which will get lost due to IL afterwards.
Contributor guide
Research direction
Start by reproducing the DIS-DUSD scenario on mainnet or in a controlled pool with very small reserves, then trace the swap path around SLOPE_SWAP_RATE and the “Lack of Liquidity” response. Define the expected behavior for swaps that would nearly exhaust a reserve and for restoring a pool afterward; done means the agreed behavior is covered by regression tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- blockchain
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100