Jump to content
P3T3RIS

xRapid - The Beginning Game

Recommended Posts

Wow, not sure what to do with that. Clear he completely misunderstands how xRapid works given the countless examples by Ripple employees over many months.

Can you explain what David means in this tweet? He clearly states that it's possible for an xRapid transaction to fail half way through, "it might (for example) buy XRP but not sell" Sounds pretty clear to me that xRapid buys XRP with fiat at exchange one, sends XRP payment on XRPL, then sells XRP for destination fiat on exchange two. It is not an atomic transaction given the variables involved (two exchange trades, xrpl payment, and the processing time for the exchange to send the XRP payment, and to process it when receiving it). As David mentions, the hard part of coding xRapid is dealing with all of the edge cases where things didn't go right. 

It is sort of sad that the DEX gateways and IOUs on the ledger never took off. The path finding abilities and single transactions currency conversions seem so much cleaner than all the pieces involved in xRapid.

 

 

Share this post


Link to post
Share on other sites
50 minutes ago, XRPforALL said:

Can you explain what David means in this tweet? He clearly states that it's possible for an xRapid transaction to fail half way through, "it might (for example) buy XRP but not sell" Sounds pretty clear to me that xRapid buys XRP with fiat at exchange one, sends XRP payment on XRPL, then sells XRP for destination fiat on exchange two. It is not an atomic transaction given the variables involved (two exchange trades, xrpl payment, and the processing time for the exchange to send the XRP payment, and to process it when receiving it). As David mentions, the hard part of coding xRapid is dealing with all of the edge cases where things didn't go right. 

 

 

I can try...

What David is saying is that you need to know that the orderbook on sending and receiving end would remain pretty much the same as they were at the time of quoting prices and also consider what are the average moves every second in orderbook depths on both sending and receiving end before xRapid executes, because after that there is nothing no one can do to it anymore. The only time when you can prepare for those changes is between "I have to pay..." -request came in and when payer accepts the cost.

I believe they will handle this with executing smaller xRapid payments more frequently, so bots have time to react.

 I only assume this, can not know 100%

Edited by P3T3RIS

Share this post


Link to post
Share on other sites
16 hours ago, hammertoe said:

That site is just insane. Sorry, but it has to be said. P3teris, all of this is based upon your fundamental misunderstanding of how a trade works. As I have repeatedly said both on Twitter to you, the following four statements describe exactly the same process of operations carried out by xRapid:

-

You are not the only one. I had an epic argument with him in this thread. he just doesn't understand and he never will. BTW he owes me 1,000 XRP from a bet he made but refuses to acknowledge he is wrong and then changed the terms to state a Ripple employee must post on this forum . So nobody should trust his 'win a lambo' competition either. he'll change the terms so he never loses.

Share this post


Link to post
Share on other sites
20 minutes ago, BrownBear said:

 owes me 1,000 XRP from 

Money in to xRapid does not come from trading charts, XRP comes. 

It does not trade, it sells fiat for XRP and buys fiat with XRP and once ledger closes, there is nothing no one can do to fix anything.

This guestion was impossible to answer 100% sure before JK tweeted that correct execution order of xRapid. I knew it, just could not prove it. That is why I tried to source liquidity from all possible places.

If you now leave me alone and let me finish what I’m doing, I might ask Ripple to send you an invite when XRP hits 100

Edited by P3T3RIS

Share this post


Link to post
Share on other sites
1 hour ago, P3T3RIS said:

I can try...

What David is saying is that you need to know that the orderbook on sending and receiving end would remain pretty much the same as they were at the time of quoting prices and also consider what are the average moves every second in orderbook depths on both sending and receiving end before xRapid executes, because after that there is nothing no one can do to it anymore. The only time when you can prepare for those changes is between "I have to pay..." -request came in and when payer accepts the cost.

I believe they will handle this with executing smaller xRapid payments more frequently, so bots have time to react.

 I only assume this, can not know 100%

Not sure, but I thought to be reading somewhere (from David?) that Ripple may offer a kind of assurance/incentive program with xRapid against uncertainties about volatility. 
Don't know how they might do that, but one of the options could be that, when there's a shortcoming on XRP for the outgoing fiat (more XRP needed than negotiated caused by instant volatility), Ripple might compensate and, if possible, get them back when there is less XRP needed on another trade. This could create full assurance in low volume/high volatile markets for trades/payments executing faster and with lesser fails or hick-ups and most important: guarantee on "no loss on volatility" for early adopting partners.

Share this post


Link to post
Share on other sites
4 minutes ago, kanaas said:

Not sure, but I thought to be reading somewhere (from David?) that Ripple may offer a kind of assurance/incentive program with xRapid against uncertainties about volatility. 
Don't know how they might do that, but one of the options could be that, when there's a shortcoming on XRP for the outgoing fiat (more XRP needed than negotiated caused by instant volatility), Ripple might compensate and, if possible, get them back when there is less XRP needed on another trade. This could create full assurance in low volume/high volatile markets for trades/payments executing faster and with lesser fails or hick-ups and most important: guarantee on "no loss on volatility" for early adopting partners.

I get back to this once my fixed version is live. Read it first with thought a few times. It is not the same it was yesterday.

PM me and I can come back to this subject and answer you 

Share this post


Link to post
Share on other sites
Guest
17 minutes ago, kanaas said:

Not sure, but I thought to be reading somewhere (from David?) that Ripple may offer a kind of assurance/incentive program with xRapid against uncertainties about volatility. 
Don't know how they might do that, but one of the options could be that, when there's a shortcoming on XRP for the outgoing fiat (more XRP needed than negotiated caused by instant volatility), Ripple might compensate and, if possible, get them back when there is less XRP needed on another trade. This could create full assurance in low volume/high volatile markets for trades/payments executing faster and with lesser fails or hick-ups and most important: guarantee on "no loss on volatility" for early adopting partners.

I have no idea if they make such guarantees.

But another way could be from monthly escrow. 

And again, I've no idea if they make such guarantees. 

Edited by Guest

Share this post


Link to post
Share on other sites
24 minutes ago, LordVetinari said:

I have no idea if they make such guarantees.

But another way could be from monthly escrow. 

And again, I've no idea if they make such guarantees. 

They have a program I believe call the “Accelerator” program that rewards institional xrp usage.  Like Reward points but for Xrp.  It depends on volume but can be up to double rewards.  

This was announced ages ago (in crypto time) so I don’t know if it still runs but I would think so...  it’s cheap to Ripple since they have a war chest and it’s encouraging adoption.

Share this post


Link to post
Share on other sites

I now updated the text, it´s the same link.... Please read it a few times before replying anything counterproductive. I definitely like to hear if there is something still wrong, but unless you can not prove what is is wrong, please don´t attack me. I did not invent xRapid, it is not my fault.

 

https://p3t3ris.com

 

Here you are.

I hope this serves XRP community well!

Share this post


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

Not sure, but I thought to be reading somewhere (from David?) that Ripple may offer a kind of assurance/incentive program with xRapid against uncertainties about volatility. 
Don't know how they might do that, but one of the options could be that, when there's a shortcoming on XRP for the outgoing fiat (more XRP needed than negotiated caused by instant volatility), Ripple might compensate and, if possible, get them back when there is less XRP needed on another trade. This could create full assurance in low volume/high volatile markets for trades/payments executing faster and with lesser fails or hick-ups and most important: guarantee on "no loss on volatility" for early adopting partners.

Indeed, as with any engineering problem, there are risks and uncertainties. What you do is try to minimise them as best you can and then insure against the rest in some other way. ie. Ripple might [made up numbers here] look at it and say, there is a 99.9% chance the payment will go through, we are happy to just say that we'll cover any losses on the 0.1% of times it fails.

-Matt

Share this post


Link to post
Share on other sites
4 hours ago, P3T3RIS said:

Money in to xRapid does not come from trading charts, XRP comes. 

It does not trade, it sells fiat for XRP and buys fiat with XRP and once ledger closes, there is nothing no one can do to fix anything.

This guestion was impossible to answer 100% sure before JK tweeted that correct execution order of xRapid. I knew it, just could not prove it. That is why I tried to source liquidity from all possible places.

If you now leave me alone and let me finish what I’m doing, I might ask Ripple to send you an invite when XRP hits 100

I've no idea what the original bet was, but just to say what you've written above (if I understand it correctly) is wrong.

I could be say here 'trading charts' and have put a buy order in to buy some USD with my XRP. xRapid comes along and needs to buy some XRP and places an order to buy XRP with USD which matches my order and is fulfilled.

xRapid does 'trade' in the fact that it 'trades' one currency for another at a specific price. There is a buyer and there is a seller. They are matched and some of the assets from the buyer are assigned to the seller, and the assets from the seller are assigned to the buyer. This is what a trade is. Does xRapid sit on tradingview and talk **** in the chat box about "Fibonacci's" and "barts", no, it doesn't.

-Matt

Share this post


Link to post
Share on other sites
11 hours ago, P3T3RIS said:

 

I have to say now I disagree with myself when I said value of XRP in xRapid is either 1 or 0. It can not. It is always 0.

That was just trying to explain better, but value is 0 always.

This makes no sense either.

The value of XRP is whatever the market (and in particular the counterparty in the specific trade you make at the time) decides it wishes to buy it for.

-Matt

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...