0060 XLS-60d: DefaultAutoBridge

[tequdev]

Abstract

Currently, if the Path field is not specified in an IOU-IOU Payment transaction, only direct pairs of two currencies are used internally. This proposal would change this default behavior to use IOU-XRP-IOU as well as OfferCreate transaction's.

Changes

If the Path field is unspecified in the IOU_A->IOU_B Payment transaction, the path through IOU_A/XRP and IOU_B/XRP is used in addition to the IOU_A/IOU_B path.

If existing transaction types or future transaction types to be implemented are similarly cross-currency transactions, it will be possible to use bridge paths in addition to direct paths by default.

Technical

Add an additional path with XRP as the intermediate between two currencies to in flow() method in Flow.cpp when defaultPaths=true.

Use XRP-mediated paths to the paths under the following conditions:

• Path is not specified
• SendMax is set.
• The issuer and currency of Amount and SendMax are different.

Payment transaction

If the Path field is not specified and the SendMax field is set, the transaction will use the XRP-mediated path.

No impact if the NoRippleDirect flag is set.

OfferCreate transaction

No impact as Path is always set.

CheckCash transaction

(using flow())

No impact as it only processes when the fields corresponding to Amount and SendMax are the same.

If future amendments allow cross-currency checks, composite paths will be available.

XChainBridge transaction

(using flow())

No impact as SendMax is processed as null.

PathFind command

(using flow())
No impact as DefaultPaths is false.

[xVet]

[tequdev]

I don't know how many cross-currency payments or token swaps are currently being made using the IOU-IOU direct path.

The processing load will increase somewhat for these transactions.

On the other hand, if the direct path does not have sufficient liquidity and users using more complex paths through PathFind, they will gain sufficient liquidity through AutoBridge paths without using PathFind. If they no longer use the PathFind paths, and use the AutoBridge paths. transaction load is reduced.

AutoBridge path is already being used by OfferCreate transactions and is by far more processed than Cross Currency Payment.

[SFsourDoh]

Certainly would be helpful when no direct market is available. How do you see this working if both direct and XRP-bridged markets exist?

[JoelKatz]

I'm stunned this doesn't happen already. Autobridging should cause AAA->XRP->BBB to be considered any time the AAA->BBB order book is used.

[JoelKatz]

My statement above is incorrect. Autobridging only affects offer crossing, not payments. XRP liquidity is used for payments through pathfinding, and the patfinding engine preferentially looks for liquidity through XRP. (It can't always check every possible asset in complex payment cases because there may be too many.)

I'm curious if there's a need for this change though. My expectation would be that anyone making cross-currency payments is using pathfinding and not just hardcoding one particular order book. Are there a lot of people who just pick an order book for their payment transactions? And, if so, is the fact that they're not getting liquidity through XRP really the biggest of their problems?

[tequdev]

Your thoughts are correct, as currently cross-currency can be done only with Payment.

However, it is undeniable that cross-currency will be used for NFToken and Check etc. in the future. In this case, it would be very useful to be able to use auto-bridging without specifying the Path.

[shortthefomo]

The same could be said for deposits into a AMM pool, it could be useful to pathfind the assets needed to deposit into a pool (im sure there other examples as well). However I do think that the Batch amendment will/should solve a lot of this. If the interfaces understand that they can get better rates using paths beforehand in some cases. Do believe this also provides a way for better interfaces to differentiate them selves over time.

[f1f47a23-spare]

hello
help needed (probably OT here)

using the "payment" transaction
the swap token1 -> xrp -> token2
works with the two DEX offers created

1. token1 -> xrp
2. xrp -> token2

but not so with two AMM pools with same couples

all simple swaps work correctly in both systems

https://testnet.xrpl.org/transactions/2530BB32F519113E7CB93C60CD2BCB9038821E4E4CE28AC690FE53BE9840F155/raw