☢️"Toxic Flow" Countermeasures
Last updated
Last updated
GMX inspired perp venues liquidities are fuelled by passive liquidity providers, and trades execute at 0 slippage, based on oracle price.
In this context, informed traders can extract value from the platform (see the Avax manipulation incident on GMX Arbitrum).
On a traditional order book based venue, this would not be possible, as the cost of liquidity would be impacted. How can GMX style perp platforms protect themselves against this issue?
The first mechanism that was put in place in the past was quite arcane, and not very user friendly :
On top of this, the built in protection is the high flat fees on any open/close position that make smaller arbitrages less viable.
One way to mitigate this issue is the voluntary introduction of latency prior to each trade. This is done by splitting trades into 2 TXs on GMX, and having check on the eventual open price. The mechanism is explained in the link above.
Jupiter perps seems to have chosen the same approach, using a keeper that receive trades intents and funds, and eventually submit trades.
From a UX perspective this can be quite heavy, as you loose the snappiness of On chain trading only possible on Solana™️. We, as Jupiter perps fans and users, had some hair-pulling moments when you try to place that trade during high volatility period, and nothing can go through. Even during regular periods, when there isn't much liquidity available it's very hard to land a trade, feels like playing a Counter Strike game rubber banding with 400ms latency (here it's closer to 4 seconds).
Since inception, our ethos is to keep it simple and fair, and to provide a user experience on par with what Solana has to offers in term of TX settlement speed.
We have chosen not to use a keeper.
This allow us to have super snappy trade execution, and also to have a more transparent, straight "on-chain" experience that doesn't take detours.
We have similar open and close fees that discourage small arbitrages, and we have added a novel high volatility period fees mechanism based on Pyth price confidence (see Oracles and Price Feeds) which should improve resilience when spread is high.
We are using Pyth pricefeeds, which are updated every ~400ms (Solana block time).
Finally we will progressively rollout in term of position size and size of the pool. Coupled with tight monitoring for "toxic flow", this should give us enough leeway to react in case of abuse at the detriment of the passive liquidity providers.
We will want to monitor markout_1m, 5m and 10m to see the PnL of trades 1/5/10 min after opening. Also similar metric to the chart below
