Jump to content
leobel

Why Ripple (the company) typically discourages issuers from trusting one another directly?

Recommended Posts

Posted (edited)

Hi. Recently I started learning about XRP ledger and reading the documentation I found this line from the Default Paths section:

Quote

Ripple (the company) typically discourages issuers from trusting one another directly

I'd like to someone explain me the reason behind this statement. I guess that if a gateway A (an issuer) wants to get access to the on demand liquidity that other gateways (supposing they allow ripple) could provide, there are two options to accomplish that.

  1. Create trust lines directly to those gateways.
  2. Wait until an account create trust lines (maybe indirectly through an offer) with those gateways and with gateway A.

It seems to me options 2 is out of gateways A control since it cannot force other accounts (I'm thinking about customers from the gateway A perspective) to create trust lines with other gateways and the better they can do is provide a sort of list of gateways for the accounts to choose from, but it'll be a more complex and extra step process. Also if the account decide to (or have) disable ripple, you won't get access to the other gateway on demand liquidity right? 

Maybe there are more ways to get access to other market on demand liquidity and I'm not seen it? 

Edited by leobel

Share this post


Link to post
Share on other sites
6 hours ago, leobel said:

Hi. Recently I started learning about XRP ledger and reading the documentation I found this line from the Default Paths section:

I'd like to someone explain me the reason behind this statement. I guess that if a gateway A (an issuer) wants to get access to the on demand liquidity that other gateways (supposing they allow ripple) could provide, there are two options to accomplish that.

  1. Create trust lines directly to those gateways.
  2. Wait until an account create trust lines (maybe indirectly through an offer) with those gateways and with gateway A.

It seems to me options 2 is out of gateways A control since it cannot force other accounts (I'm thinking about customers from the gateway A perspective) to create trust lines with other gateways and the better they can do is provide a sort of list of gateways for the accounts to choose from, but it'll be a more complex and extra step process. Also if the account decide to (or have) disable ripple, you won't get access to the other gateway on demand liquidity right? 

Maybe there are more ways to get access to other market on demand liquidity and I'm not seen it? 

First of all, it is important to realise that ODL is not making use of the IOU/DEX mechanism, it only makes use of simple XRP transfers.

The IOU/DEX functionality is another aspect of the XRPLedger. From a technical point of view more interesting imo, but not used in ODL :-)

Anyways, beside that, I kinda agree with you that issuers trusting each other is an interesting concept. But it would expose the gateway A to the systemic risk of gateway B. Let's say that gateway B gets hacked and turns out to be insolvable, then a fully automated bankrun will take place where gateway A will end up will all useless IOU's from gateway B. Gateway A could reduce that risk to the amount of trust as defined in the trust line. I have been playing with that concept to see what it would look like:

 

Share this post


Link to post
Share on other sites
Posted (edited)

@jn_r thanks for the response. If I get it right ODL is basically obtained by offers that will provide you the asset the offer is trying to exchange whether XRP or IOU's. How would you get access to an asset X if there isn't anyone else trying to exchange it? If you get ODL through a XRP transfer that means there is someone "out there" wanting to exchange/offer those XRP. By "out there" I mean there is a path you can follow to get to that exhange/offer without generating undesired debts along the way. 

What do you mean with

Quote

ODL is not making use of the IOU/DEX mechanism, it only makes use of simple XRP transfers

Like IOU/DEX mechanism, you have XRP/DEX mechanism and both together give you all the possibilities to have ODL.

Edited by leobel

Share this post


Link to post
Share on other sites
2 hours ago, leobel said:

@jn_r thanks for the response. If I get it right ODL is basically obtained by offers that will provide you the asset the offer is trying to exchange whether XRP or IOU's. How would you get access to an asset X if there isn't anyone else trying to exchange it? If you get ODL through a XRP transfer that means there is someone "out there" wanting to exchange/offer those XRP. By "out there" I mean there is a path you can follow to get to that exhange/offer without generating undesired debts along the way. 

What do you mean with

Like IOU/DEX mechanism, you have XRP/DEX mechanism and both together give you all the possibilities to have ODL.

ODL works with 'normal' exchanges, such as Bitstamp and Bitso. Each has its own 'proprietary' ledger. On Bitstamp there is an orderbook USD<->XRP and on Bitso there is an orderbook XRP<->MXN. An ODL order basically looks like this: 

  1. Exchange USD on exchange A (Bitstamp) for XRP
  2. Send the XRP to exchange B (Bitso)
  3. Exchange XRP on exchange B (Bitso) for MXN

Those are the simple steps. As it turns out there is more to it and Ripple is not very open about it how it works exactly. Imo it could look something like this:

  1. ClientA wants to send MXN to clientB using USD. He checks with Moneygram for a price offer
  2. Moneygram checks with (a set of) MarketMakerA (working on Bitstamp USD/XRP) and asks for a price offers USD/XRP
  3. Moneygram checks with (a set of) MarketMakerB (working on Bitso XRP/MXN) and asks for price offers XRP/MXN
  4. Money gram now offers ClientA the price USD/MXN
  5. The ClientA accepts
  6. Moneygram offers the USD at Bitstamp USD/XRP exchange for the agreed price from MarketMakerA
  7. MarketMakerA then takes the trade (if not already taken)
  8. Moneygram sends the XRP to Bitso exchange
  9. Moneygram offers the XRP at Bitso XRP/MXN exchange for the agreed price from MarketMakerB
  10. MarketMakerB then takes the trade (if not already taken)
  11. Moneygram sends the MXN to clientB

Something like that. The thing that might raise questions is, how do the market makers determine the price and how do they rebalance their USD, MXN, or XRP. Because in the end MarketMakerA will have a lot of USD and needs XRP, and MarketMakerB will have a lot of XRP but needs MXN. There is some discussion about this elsewhere on the forum, but my take on it is, that the market makers will have to rebalance simply via other liquidity sources. Those other liquidity sources are perhaps less fast than ODL, but this is exactly what marketmakers are for, this is part of the service they deliver. On top of that the market makers could probably do a better job if there were financial instruments for XRP available, such as lending, borrowing, leverage, etc. As it seems, Ripple is currently working on these instruments for XRP.

So, quite a story, yet nowhere are IOU's used that are available on the XRPLedger. Might be an interesting thought experiment to imagine one of the exchanges (or both?) as a gateway on the XRPLedger-DEX, but that is not how ODL is currently used. btw, everything you read at https://xrpl.org is not about ODL (except for the sending XRP part)

Share this post


Link to post
Share on other sites
3 hours ago, leobel said:

If I get it right ODL is basically obtained by offers

If you are referring to the ODL (On Demand Liquidity) that Ripple talk about as one of their product offerings,  you are looking in the wrong layer of the stack.

ODL is NOT on the XRPLedger.  (Although there is a possibility to implement such a thing using the almost totally idle DEX built into XRPLedger, which is what you appear to have been looking at)

ODL is Ripple provided software that only uses the XRPLedger for the middle part of its trip.  The XRPL is only used to transfer XRP between crypto exchanges.

Share this post


Link to post
Share on other sites

@Dogowner5 I think you are right, I was looking into the wrong layer of the stack. I was trying to get access to liquidity using DEX on XRPLedger and after reading this: https://ripple.com/ripplenet/on-demand-liquidity/? I notice ODL from the Ripple point of view is something quite different . Looking to @jn_r example, steps 7 and 10 seems to me are critical in a business model since the company who provided the services (Moneygram on this example) could end without liquidity if there is no such offer by the time it'll try to take it on both steps (loosing the transaction atomicity) or could end with a total different exchange rate than the one presented to the client initially. When I was thinking on get liquidity using DEX upon XRPLedger that was the main concern, though we won't have the atomic issue, we will have the problem to guaranteed the execution of the transaction at the given exchange rate. We can preserve the exchenge rate with tfLimitQuality flag but we can't guaranteed that the execution will be executed successfully.

Thanks for the time to reply to me, I'm just starting to understand all this technology and I don't have any previuos experience in the field, so I really appreciate your effort and explanation.

Share this post


Link to post
Share on other sites
32 minutes ago, leobel said:

I'm just starting to understand all this technology and I don't have any previuos experience in the field, so I really appreciate your effort and explanation.

I would also suggest you get and understanding of how payments work so you can get a better understanding of how Ripple/XRP add value.

These are good.

http://jpkoning.blogspot.com/2020/02/transferwise-why-so-fast.html

https://www.saveonsend.com/blog/bitcoin-blockchain-money-transfer/

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, xerxesramesepolybius said:

That means centralised database doesn't it?

 

Yes that's what I meant, a ledger technically implemented with some sort of private database managed by one entity without consensus mechanism. But since it is private we can't know that last part for sure :-) So, a private database.

Edited by jn_r

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...