XRPL-Labs / Xaman-Issue-Tracker

Bugs, improvements, suggestions & release progress (Project boards)
https://xumm.app
14 stars 9 forks source link

[CFED] Implement "Open" Swap functionality in Xaman #493

Open WietseWind opened 6 months ago

WietseWind commented 6 months ago

Context

With the launch of AMM on the XRPL, the available liquidity & consequences of a proposed swap, for any specific pair isn't s straight forward anymore: before AMM we could simply read an order book, take book depth & spread into account, and calculate a likely outcome of a proposed trade (swap).

Current situation / problem

Right now, the order book only paints part of the picture: the potential available liquidity in AMM pools could allow for less slippage, better quotes, etc.

In Xaman, when tapping a Trust Line, one can tap the "Exchange" button, after which an XRP-{selected asset} 'instant swap' can be signed. It shows a possible quote, slippage limits, and allows for a one review - one slide swap.

After the launch of AMM we put a refactor on our backlog (#477) - which has now been closed. The initial idea was we would replace our order book interpreting for pathfinding, to get quotes taking into account auto bridging and AMM pools, but while discussing this backlog item, we came up with a better solution.

Vision

At XRPL Labs, with Xaman, we have aimed from the start to build an 'open platform' for developers and end users to interact. We do the security & signing, trusted Devs & users can interact securely. This way, we're a platform for devs, and have a much more complete offering to end users (we're stronger together).

Solution (decision)

We decided we're going to do the same we did when XLS20 launched: we offer a simple "xApp launchpad" for the "Swap" functionality, so ecosystem devs can get users straight into their Swap implementation. For end users, the flow will be:

  1. Tap TrustLine
  2. Tap Exchange (rename to Swap?)
  3. Pick Swap platform provider
  4. Launch xApp with input paramter to indicate it's about Swap + the issuer & asset (context) using standard xApp context params (meaning your implementation gets this information in the OTT data).

Requirements

For a Swap implementation to be eligible for inclusion in the Swap list opened by Xaman, the following requirements have been identified (this list may be expanded!)

  1. Existing working product (doesn't have to be an xApp, can be web app as well)
  2. Solution must be built as an xApp, and may contain more than Swap, but must at least contain Swap
  3. Swap must be directly opened based on the xApp OTT input data, with the right pair selected
  4. Swap must show user a quote based on entered amount, which must take into account both DEX and AMM, the price impact must be displayed
  5. Swap must show a warning to users if the slippage exceeds a percentage we pass on in the OTT data for the specific pair
  6. Swap must take into account a maximum slippage in both directions: the OTT passes two slippage percentages: one for the trade in one direction, one for the return path. This means 'under the hood' the trade back must also be calculated/found, and if the trade in slippage + the trade back slippage exceeds the given percentage, the user must be warned that due to lack of liquidity, the trade cannot be reverted without taking a significant loss

Obviously, regular xApp requirements apply.

Identified potential platforms

Platforms that came to mind, others out there: open invitation to reach out & ask/participate!

PLEASE REACH OUT FIRST, then build. Just to make sure we're aligned & questions are answered in advanced.

Reward

  1. Visibility to end users straight from in the Xaman app when users tap a TrustLine
  2. Good vibes
  3. 20k XAH (native asset on Xahau) - which isn't really much compared to the effort but it's more "nice to have, for fun"

Technical

The xApp OTT data (example below truncated to show only the relevant pieces for this integration) that will be provided will look like:

{
  "issuer": "rcEGREd8NmkKRE8GE424sksyt1tJVFZwu",
  "asset": "5553444300000000000000000000000000000000",
  "action": "SWAP",
  "slippage_tolerance_pct_1way": 3,
  "slippage_tolerance_pct_2way": 6.5
}
Jbekker commented 6 months ago

Just a small suggestion, please allow setting a default ‘swap provider’ so the end-user does that have to look through the list every time to find his/her/its favourite.

WietseWind commented 6 months ago

Just a small suggestion, please allow setting a default ‘swap provider’ so the end-user does that have to look through the list every time to find his/her/its favourite.

We considered this, but for the sake of allowing people to try and discover other options, and for the sake of giving the entire ecosystem a shot, I think muscle memory will take people to the button for their fav. platform, while being reminded every time that other options exist (and who knows, they might try others as well).

Jbekker commented 6 months ago

Just a small suggestion, please allow setting a default ‘swap provider’ so the end-user does that have to look through the list every time to find his/her/its favourite.

We considered this, but for the sake of allowing people to try and discover other options, and for the sake of giving the entire ecosystem a shot, I think muscle memory will take people to the button for their fav. platform, while being reminded every time that other options exist (and who knows, they might try others as well).

Fair enough, I do think there are other ways to give people options. The top-left of an xApp (logo+name) could open like a list of similar apps based on category or something. For a swap it could show the others? I’m just a lazy IT guy, less clicks is always better 😅.

WietseWind commented 6 months ago

Questions from DeXfi:

  1. The OTT data suggests that it will only be exchanged for XRP and no other tokens, right?
  2. Can the data also be found in the URL or only in the xApp context?
  3. Just a warning if one of the slippages is not met, or also restrict the swap?
  4. slippage_tolerance_pct_2way gives the total slippage for both trades, not just the reverse trade?

Answers:

  1. No it can be against any other token, we're just sending the pair the user tapped on, the counter trade can be anything, they can just select on your platform?
  2. Only xApp context
  3. Up to you, I assume there will be some blockcing, some warning: the most important part is that the user is warned & based on their own preferences and risk appetite of the platform (you) certain actions can be allowed or not
  4. Exactly, so that's a round trip. E.g. if someone decides they screwed up and didn't want to trade and go back into whatever asset they came from.