Jump to content

Interledger Exchange


Recommended Posts

20 minutes ago, zerpdigger said:

i want to see exactly how this supposed xbt interledger route is better than xrp...

I'm not saying it's better, but that they are the same, so at the end only liquidity and spread matters for the cheapest payment. And BTC has more liquidity IMO.

Link to comment
Share on other sites

1 minute ago, tulo said:

I'm not saying it's better, but that they are the same, so at the end only liquidity and spread matters for the cheapest payment. And BTC has more liquidity IMO.

right, but i still don't see how it works, because you don't describe the operation... it "just happens"

how could the MXN get to XBT then ripple over to the other exchange, and turn into USD then hit a bank the other end?

you have to be specific, because i don't understand your xbt-interledger route, makes no sense to me

bob pays cuallix, cuallix does what?! market maker moves xbt... why? for a fee? why does the exchange accept xbt with no deposit (settlement)?! etc...

Link to comment
Share on other sites

in my head, it goes like this... (not sure why it goes MXN->USD and not vice versa but hey, go with it...) :D

Pedro (Mexico) wants to pay John in USA.

Pedro pays MXN to Cuallix (cuallix.com/en) who purchase(d) XRP (when they run out, they can buy more on-market at Bitso) ; Cuallix send XRP (on-ledger) to a "dude they trust" called Jim in the USA, who can accept XRP no problem, then exchange it at e.g. Bitstamp for USD (for Brian).

Now what I don't get (@miguel!) is this:

Does Jim work direct for Cuallix? Or is he on contract/freelance? What fees are there? Does Jim send a wire/payment to John in the USA because he has a bunch of diff bank accounts e.g. BoA, HSBC, etc? If so can he just accept the exchange's IOU-USD (for now) plus fees in order to get the wire FAST to John? Or, does Jim have a way to pay out (withdraw) from Bitstamp DIRECT to Brian's bank account (unlikely, KYC/AML issues).

Or, is Jim happy to hold on to XRP for a bit?! Does Jim also do the reverse route himself, i.e. he hangs onto those Bitstamp USD until one day Brian wants to send money to a friend in Mexico?!

Link to comment
Share on other sites

On 11/7/2017 at 7:30 AM, zerpdigger said:

in my head, it goes like this... (not sure why it goes MXN->USD and not vice versa but hey, go with it...) :D

Pedro (Mexico) wants to pay John in USA.

Pedro pays MXN to Cuallix (cuallix.com/en) who purchase(d) XRP (when they run out, they can buy more on-market at Bitso) ; Cuallix send XRP (on-ledger) to a "dude they trust" called Jim in the USA, who can accept XRP no problem, then exchange it at e.g. Bitstamp for USD (for Brian).

Now what I don't get (@miguel!) is this:

Does Jim work direct for Cuallix? Or is he on contract/freelance? What fees are there? Does Jim send a wire/payment to John in the USA because he has a bunch of diff bank accounts e.g. BoA, HSBC, etc? If so can he just accept the exchange's IOU-USD (for now) plus fees in order to get the wire FAST to John? Or, does Jim have a way to pay out (withdraw) from Bitstamp DIRECT to Brian's bank account (unlikely, KYC/AML issues).

Or, is Jim happy to hold on to XRP for a bit?! Does Jim also do the reverse route himself, i.e. he hangs onto those Bitstamp USD until one day Brian wants to send money to a friend in Mexico?!

I think the missing point here is that both BitSo and BitStamp are also on the network in this situation.

I think, and might be wrong here since I'm not that caught up on my reading, that ILP ultimately is two things, the messaging system, as well as the escrow system. If you're doing blockchain -> blockchain transactions you can do on-blockchain escrow. But if you're sending to another 'bank' account or institution you need that bank to understand and accept ILP to really let the transaction flow through.

Under your scenario, Jim, especially if he's the ultimate sender into John's account, has the ability to steal the money, which should never, ever happen.

Pedro wants to pay John in the USA.

Pedro sends a request to the ILP network for a payment route to John. The network responds back that by using a connector at Cuallix, then a connector on the XRP ledger to Bitstamp that he can be paid.

Pedro agrees.

Connector Carlos (Cuallix) agrees.

Connector Bob (Bitstamp) agrees.

John agrees.

Pedro's money is then transferred to a holding account at Cuallix (escrowed.)

Carlo's money on the XRP ledger is now escrowed on ledger (or technically could do it through Bitstamp's ledger too but whatever floats your boat).

Bob's money, since he sees his XRP is escrowed is now escrowed into John's account on Bitstamp.

So through a process of three different escrows, three different ledgers, and two diverse financial institutions the payment can be made.

John accepts the escrow and it all release in reverse all the way back.

Link to comment
Share on other sites

1 hour ago, JonHolmquist said:

I think the missing point here is that both BitSo and BitStamp are also on the network in this situation.

do you mean part of xrapid and/or ILP enabled?

if so, as  tulo suggests, why not use e.g. XBT between the two exchanges, instead of faffing about with withdrawal/deposit?

also, i can't work out -- if withdrawals/deposits are required -- how the ILP/escrow can work this way? wouldn't the w/d break this automated route?

1 hour ago, JonHolmquist said:

Under your scenario, Jim, especially if he's the ultimate sender into John's account, has the ability to steal the money, which should never, ever happen.

hmm, not sure about this -- isn't john just receiving a payment anyway?! "somehow" the MXN gets from Bitso to "Bank Tequila" (how??!) and then from "Bank Tequila" to John's account... then again, what if John isn't even banking at "Bank Tequila" but instead prefers "Bank Sombrero"?!?!

we are missing some info here and it's driving me nuts

i would like to think the entire process is automated, since it looks in @miguel's slide like both "FIs" use xRapid and the payment out of the last exchange goes back INTO xRapid again, i guess so that the MXN or USD can find their way (via ILP?) to the specific user's bank account

then again... which part are cuallix doing... if they are the FI at both ends, how does that eliminate nostro/vostro?

Link to comment
Share on other sites

7 minutes ago, zerpdigger said:

do you mean part of xrapid and/or ILP enabled?

if so, as  tulo suggests, why not use e.g. XBT between the two exchanges, instead of faffing about with withdrawal/deposit?

also, i can't work out -- if withdrawals/deposits are required -- how the ILP/escrow can work this way? wouldn't the w/d break this automated route?

hmm, not sure about this -- isn't john just receiving a payment anyway?! "somehow" the MXN gets from Bitso to "Bank Tequila" (how??!) and then from "Bank Tequila" to John's account... then again, what if John isn't even banking at "Bank Tequila" but instead prefers "Bank Sombrero"?!?!

we are missing some info here and it's driving me nuts

i would like to think the entire process is automated, since it looks in @miguel's slide like both "FIs" use xRapid and the payment out of the last exchange goes back INTO xRapid again, i guess so that the MXN or USD can find their way (via ILP?) to the specific user's bank account

then again... which part are cuallix doing... if they are the FI at both ends, how does that eliminate nostro/vostro?

Oh I was just talking ILP.

Link to comment
Share on other sites

2 minutes ago, JonHolmquist said:

Oh I was just talking ILP.

this is where the confusion is... ILP means no need for XRP/settlement if XBT is used... was the point of contention

Link to comment
Share on other sites

The misconception in this thread is that the market maker is somehow in on the payment. Or somehow has some prior knowledge of the payment that is occurring. Or that the market maker needs to create a payment path for the payer. Or that the market maker needs to have funds on every exchange the payment uses for settlement. Instead the reality is that the market maker is placing orders on the orderbook trading as you or I would hoping his orders will fill. He is not guaranteed to make a profit. He is not guaranteed to have his orders filled unless at the moment of the payment he happens to be the BEST AVAILABLE PRICE. 

Say I was sending a payment to someone. And I was using an automated tool such as ILP. The automated tool would search all the available overbooks for the payment path with the best price and execute the payment by purchasing the currency at the best price. Muli hop payment paths (eg USD > EUR > XRP > BTC) would not necessarily be the job of the automated payment tool. It would make more sense if each ledger obfuscated the multi hops into a single hop (USD > BTC). The offer might be "auto bridged" on rcl but the user would not need to know. 

The payer ( or automated tool)would select the best payment path based on price. Sometimes that would be BTC sometimes it would be XRP. From payment to payment whether XRP or BTC is used would be seemingly random but over time due to the fact that a computer algorithm is finding the cheapest path statistically the cheaper currency overall would be used more. Cheaper fee's results in tighter spreads. Therefore statistically given enough liquidity on rcl XRP would be used as the payment path more than btc. 

The only advantage BTC has is liquidity. XRP wins in every other competitive factor. RCL autobridges making it possible for XRP to bridge inefficient corridors without the payer ever knowing he was purchasing XRP. XRP has a cheaper network fee allowing the liquidity providers the ability to tighten his spreads raising the likelihood his orders will fill. 

The other aspects you guys have mentioned such as the market maker having funds on various accounts and providing liquidity and making money off the price difference through arbitrage. These factors are what causes the market to be efficient but has nothing to do with any specific payment path. The market maker could mistime his arbitrage and lose money yet still the payment path would be unaffected. 

Link to comment
Share on other sites

1 hour ago, jargoman said:

The misconception in this thread is that the market maker is somehow in on the payment. Or somehow has some prior knowledge of the payment that is occurring. Or that the market maker needs to create a payment path for the payer. Or that the market maker needs to have funds on every exchange the payment uses for settlement. Instead the reality is that the market maker is placing orders on the orderbook trading as you or I would hoping his orders will fill. He is not guaranteed to make a profit. He is not guaranteed to have his orders filled unless at the moment of the payment he happens to be the BEST AVAILABLE PRICE. 

isn't this a liquidity provider, not a market maker? maybe i misunderstand the diff

1 hour ago, jargoman said:

Say I was sending a payment to someone. And I was using an automated tool such as ILP. The automated tool would search all the available overbooks for the payment path with the best price and execute the payment by purchasing the currency at the best price. Muli hop payment paths (eg USD > EUR > XRP > BTC) would not necessarily be the job of the automated payment tool. It would make more sense if each ledger obfuscated the multi hops into a single hop (USD > BTC). The offer might be "auto bridged" on rcl but the user would not need to know. 

this is v interesting to me, thanks -- so i know a BIT about autobridging and get the general concept, as well as "synthetic orderbooks" and have been wondering when/if they're coming into play here, and if so, whose job it is to implement this... presumably, payments-pathfinding will be an entirely new field popping up around this? but i digress...

do we know if autobridging is operational and/or working as expected as part of ripple's total solution? i feel like it was a big deal when announced and now we hear virtually nothing about it beyond an "academic" mention by the devs...

1 hour ago, jargoman said:

The payer ( or automated tool)would select the best payment path based on price. Sometimes that would be BTC sometimes it would be XRP. From payment to payment whether XRP or BTC is used would be seemingly random but over time due to the fact that a computer algorithm is finding the cheapest path statistically the cheaper currency overall would be used more. Cheaper fee's results in tighter spreads. Therefore statistically given enough liquidity on rcl XRP would be used as the payment path more than btc. 

so in other words, the cheaper xrp would offset the more liquid xbt? and thus become more liquid, etc... ?

1 hour ago, jargoman said:

The only advantage BTC has is liquidity. XRP wins in every other competitive factor. RCL autobridges making it possible for XRP to bridge inefficient corridors without the payer ever knowing he was purchasing XRP. XRP has a cheaper network fee allowing the liquidity providers the ability to tighten his spreads raising the likelihood his orders will fill. 

thanks again, much appreciated, but must ask : tulo's idea was that fees are a NON-ISSUE anyway due to the (currently) more liquid xbt, hypothetically, being sent between exchanges via Interledger and NOT through withdrawal/deposit... wouldn't that make XRP's speed/fees advantage redundant? if so, we're then ONLY left with liquidity as the driving factor (for that given corridor, wthdrawals etc not withstanding)

2 hours ago, jargoman said:

The other aspects you guys have mentioned such as the market maker having funds on various accounts and providing liquidity and making money off the price difference through arbitrage. These factors are what causes the market to be efficient but has nothing to do with any specific payment path. The market maker could mistime his arbitrage and lose money yet still the payment path would be unaffected. 

i think i am clear on that -- will chew on it some more, so complex! thank you

----------------

notes: @nikb's fantastic post from 2014 here: https://ripple.com/dev-blog/introducing-offer-autobridging/

wow, was that really from 2014?! ripple's been so far ahead -- i think i am starting to see how powerful and crucial autobridging is in this whole strategy for gaining liquidity advantage... still slightly muddy though and would love @miguel's input too

i'd also like to know if offer autobridging has progressed and is looking to be implemented as part of the liquidity solution ?? e.g. https://ripple.com/insights/rippled-feature-update-nudb-and-autobridging/

last question: since much of ripple's tech is open source, in future, can other digital assets like XBT become available to autobridging like this or would that require the entire infrastructure e.g. the decentralized exchange behind it like xrp already has? (i believe i am correct in thinking that IOUs on Ripple's XRP Ledger cannot be used this way, since they are liabilities thus can fail)

thanks all -- good stuff

Link to comment
Share on other sites

1 hour ago, Graine said:

I keep looking at the diagram but still can't understand a thing. 
Can anyone lend a hand?

It is from this https://github.com/mojaloop/docs/tree/master/ILP

I personally find the Mojaloop documentation nice to read. If you have a specific questions I'm happy to give it a go.

Here is another version of the flow chart.

block-diagram.png.e3a4792f227f665cdaf210e9a3d2d162.png

The section "Forward Holds, Backwards Execution" may be one to take notice of. I think this is the same rational used with the Pathfinding algo built into RCL. I remember finding some of David's comments very interesting on that a few years ago.

---

On 11/13/2017 at 5:04 PM, zerpdigger said:

isn't this a liquidity provider, not a market maker? maybe i misunderstand the diff

A comment on this thread said something indicating they didnt understand that Market Makers are Liquidity Providers. They function in a similar role as the old Specialists on the floor of NYSE 

 

Edited by KarmaCoverage
Link to comment
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...