SAFE Swapping: How to Protect Users from Bad Trades

​

Keeping Users Safe on your Application

1. Execute swaps & transfers they don’t understand at unfavorable prices using money they cannot afford to lose (e.g. Spending $1000 on a new, illiquid meme coin within 2 hours of launch)
2. Accuse you (& Skip) of responsibility for their losses (even if your software & ours worked as expected), demand a refund, and publicly vilify & troll you if you do not give one.

1. Share all available information about expected execution price
2. Alert when info indicates an action might be harmful
3. Fail transactions that trigger your alerts (i.e. transactions that seem likely to harm users)
4. Enforce additional approval stages for users who want to create these transactions anyhow

​

S.hare Info

• Estimated USD value of the amount in (response.usd_amount_in)
• Estimated USD value of the amount out (response.usd_amount_out)
• Price Impact (response.swap_price_impact_percent) — This measures how much the user’s expected execution price differs from the current on-chain spot price at time of execution. A high price impact means the user’s swap size is large relative to the available on chain liquidity that they’re swapping against, which makes a bad price very likely.
• Swapping Venue (Available in the swap_venue field of the swap operation in response.operations) - This tells the user what DEX they’re actually performing the underlying swap on, which helps avoid confusion about prices. This can be useful information in the event the API returns an usual route and routes the user to a DEX they’re unfamiliar with / don’t want to use or to a DEX where there’s not much liquidity of the token they’re swapping (e.g. SEI liquidity on Osmosis is sparse at the time of this writing)
• Bridge Fee Amounts (Available in the transfer and axelar_transfer entries in response.operations under fee_asset and fee_amount) — These represent the fees that bridges take from the user along the route, denominated in the token(s) they’re taking. It’s important to show because sometimes bridges take fees unexpectedly (e.g. Noble used to take 0.10% fee on IBC transfers), and sometimes they take large fees (e.g. During periods of high gas prices, Axelar fees can be as high as $200)
• USD value of bridge fee amounts (Available in the transfer and axelar_transfer entries in response.operations under usd_fee_amount) — This gives the user a sense of the actual cost of their fee amounts. In cases of more complex swaps and transfers, the user might have a hard time making sense of the underlying fee tokens because the fees are being charged at an intermediate point in the route

​

A.lert users to bad prices

1. High Price Impact (swap_price_impact > PRICE_IMPACT_THRESHOLD) : This indicates the user’s swap is executing at a considerably worse price than the on-chain spot price — meaning they’re probably getting a worse price than they think they should. It also indicates the size of their trade is large relative to the available on chain liquidity. We recommend usingPRICE_IMPACT_THRESHOLD = 2.5 in your calculations
2. High difference in relative USD value in and out ((usd_amount_in - usd_amount_out)/usd_amount_in)*100 > USD_REL_VALUE_THRESHOLD ): This estimates the underlying value the user will lose instantly as a result of swapping, represented as a percentage of the value of their input. A high value for this figure indicates the user is instantly losing a large percentage of the value of their starting tokens. For example, a value of 50 indicates the user loses 50% of the estimated value of their input. We recommend using USD_REL_VALUE_THRESHOLD=2.5
3. High fees ( usd_fee_amount / usd_amount_in > FEE_THRESHOLD) : This indicates that the value of fees charged by bridges used in the route amount to a large percentage of the underlying amount being transferred. If this value is high, user might want to wait until bridging more funds to execute (since bridge fees rarely scale with volume). We recommend setting FEE_THRESHOLD=.25

• Bolding unusually high/low quote numbers — or otherwise making them larger than surrounding text/numbers
• Automatically opening drop downs / detail panes that are usually closed by default to display the alert field
• Highlighting the offending quote number in red, yellow, or some other loud color indicating danger and/or greying out other numbers

​

F.ail Transactions when they’re likely to cause user harm

1. Greater than 10% difference in relative USD value in and out (usd_amount_in - usd_amount_out)/usd_amount_in)*100 > 10
2. Greater than 10% price impact (swap_price_impact > 10)

​

E.nforce explicit, additional approval

• It’s very clear that our expectation is that the swap will harm the user with the “Bad Trade Warning” across the top
• The page explicitly reminds the user what the problem is — foregrounding the predicted price impact and forcing them to acknowledge it again
• The “happy path” or “default” path is to go back — not to finish the swap (Notice that the “Go Back” button is highlighted)

1. Greater than 5% difference in relative USD value in and out (usd_amount_in - usd_amount_out)/usd_amount_in)*100 > 5
2. Greater than 5% price impact (swap_price_impact > 5)
3. Price impact AND relative-USD-value-difference cannot be calculated (i.e. swap_price_impact, usd_amount_out, and/or usd_amount_in are missing)

​

Choosing the right level of protection: warnings, additional approvals, and outright failures

1. None: Just let it rip. Don’t give the user any heads up. Don’t do anything to slow them down or prevent them from trading.
2. Alert: Use some visual cue to indicate to the user that they should be wary about swap
3. Enforce additional approval: Require additional clicks to actually execute the swap and foreground the warning — so the user needs to approve it explicitly.
4. Fail: Just block / fail / prevent transactions that exceed your safety tolerance bounds outright

1. Set lower trigger thresholds for weaker forms of security and more conservative thresholds for stronger forms of security (e.g. You could alert users about high price impact at 2.5%, require an additional stage of approval at 10%, and fail the transaction outright at 25%) This approach is nice because it gives users who may be very conservative some indication that they may face some danger without getting in their way too much, while still hard-stopping more inexcusable failures that are probably never acceptable to any trader
2. Use stronger forms of security when safety tolerances are exceeded for higher value transactions (e.g. You could use warnings when price impact is greater than 10% for transactions where the amount in is $0-100, additional approvals when amount in is$1,000 - 10,000, and block transactions above $10k outright if price impact is greater than 10%.