Jump to content
tar

Balance sheet operations of a cross-border settlement process with the use of XRP

Recommended Posts

1 hour ago, BrownBear said:

xCurrent and by nature xRapid are bi-directional messaging systems. The transaction process only take places once the negotiations have been agreed to. Everyone knows the steps to be taken in the transaction before it happens. There are no assumptions and there are no 'Bank at Ger does not know about it yet' type of scenario.

I blame people for still propagating the outdated corresponding push style banking system when explaining how xRapid works . It has done so much damage in explaining just what xRapid is that people still think the transaction is taken in steps BEFORE negotiation instead of after negotiation. EG: I send $10m USD worth of XRP to Brazil only to find out there is not enough liquidity and I am forced to pay huge slippage in order to fill the transaction in Brazil when in reality, the transaction would never be initiated because the negotiations wouldn't have been able to be completed within the acceptable and predetermined slippage threshold.

I'll say again. xCurrent and thus xRapid are bi-directional messaging systems. This is why they are so efficient, cheap and fast.

Great explenation. Thanks. 

Share this post


Link to post
Share on other sites

In my opinion the document highlights nicely how crucial role the market makers (often the xRapid preferred crypto exchanges) play in terms of success of xRapid. As you can see only MMs hold XRPs in their balance sheets. If anything negative (hack, for instance) happens to these MMs it would basically abort the functionality of xRapid in the relevant corridors until the problem has been fixed.

Some MMs incur often surplus of XRPs whereas the others incur often deficit of their XRPs. I think a good example of this is BItso in Mexico. They probably have (or will have) surplus of XRPs because they receive lots of remittances from USA and Euro zone countries. On contrary, Bittrex in USA and Bitstamp in Europe sometimes suffers deficit of their XRPs. I can see there are at least three ways how these imbalances of XRPs can be equalized:

1) MMs who will experience deficit of XRPs can buy more from Ripple OTC probably with fixed price as much they want for now (*).

2) MMs can even out their XRP imbalances via their mutual OTC trading whatever price they agree.

3) MMs can buy/sell their XRPs in an open market if needed.

(*) Assuming that there will be lots of demand for XRPs in future then Ripple will run out short of their XRP reserve. If this point is reached then the above option 1 pretty much dies out. Ripple will probably never sell all of their XRPs.

Share this post


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

xCurrent and by nature xRapid are bi-directional messaging systems. The transaction process only take places once the negotiations have been agreed to. Everyone knows the steps to be taken in the transaction before it happens. There are no assumptions and there are no 'Bank at Ger does not know about it yet' type of scenario.

I blame people for still propagating the outdated corresponding push style banking system when explaining how xRapid works . It has done so much damage in explaining just what xRapid is that people still think the transaction is taken in steps BEFORE negotiation instead of after negotiation. EG: I send $10m USD worth of XRP to Brazil only to find out there is not enough liquidity and I am forced to pay huge slippage in order to fill the transaction in Brazil when in reality, the transaction would never be initiated because the negotiations wouldn't have been able to be completed within the acceptable and predetermined slippage threshold.

I'll say again. xCurrent and thus xRapid are bi-directional messaging systems. This is why they are so efficient, cheap and fast.

I think @tar was pretty clear about this point in his quick write up, not sure why you posted this, or maybe I'm missing something. 

Share this post


Link to post
Share on other sites
5 hours ago, Wandering_Dog said:

We're missing the CB's, or assuming people bank directly with the CB. 

In my provided example, the balance sheet of any central bank is not affected, at all. They do not change by the settlement with XRP except when the corresponding local market maker would be not directly connected to the private bank of the private sender or receiver of the actual payment. Even that could be solved by further middle men without affecting the balance sheet of any central bank.

Edited by tar

Share this post


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

I think @tar was pretty clear about this point in his quick write up, not sure why you posted this, or maybe I'm missing something. 

Because his write up makes assumptions along the settlement chain. tar wrote:

Quote

For the liabilities from M USA to M GER a transaction of XRP on the XRP Ledger will be executed.
In this example, it is assumed that the market maker at the source country (M USA) already has a sufficient amount of XRP which otherwise would be rather strange for an XRP market maker.

This implies a transaction can be initiated without prior negotiation. XRP is a liquidity tool, there is no need for this correspondent push type banking system on the assuption something 'may' be filled. I was pretty clear on this.

 

Share this post


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

xCurrent and by nature xRapid are bi-directional messaging systems. The transaction process only take places once the negotiations have been agreed to. Everyone knows the steps to be taken in the transaction before it happens. There are no assumptions and there are no 'Bank at Ger does not know about it yet' type of scenario.

I guess, you are referencing to the paragraph at 3.1. - there is a difference between 1) the payment order of a customer to his private bank and 2) the actual execution of this payment order by his private bank. Therefore, of course the receiver and the receivers bank do not have the slightiest clue when 1) happens until 2) is processed.

3 hours ago, BrownBear said:

I blame people for still propagating the outdated corresponding push style banking system when explaining how xRapid works . It has done so much damage in explaining just what xRapid is that people still think the transaction is taken in steps BEFORE negotiation instead of after negotiation.

That is not what I wrote :scratch_one-s_head:

Share this post


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

Because his write up makes assumptions along the settlement chain. tar wrote:

This implies a transaction can be initiated without prior negotiation. XRP is a liquidity tool, there is no need for this correspondent push type banking system on the assuption something 'may' be filled. I was pretty clear on this.

 

Did you miss 3.2 ("It finds the path ...") and 3.3 ("As soon as the path is validated there are various balance sheet operations triggered at once as the global settlement process with xRapid is atomic.")?

Share this post


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

Because his write up makes assumptions along the settlement chain. tar wrote:

This implies a transaction can be initiated without prior negotiation. XRP is a liquidity tool, there is no need for this correspondent push type banking system on the assuption something 'may' be filled. I was pretty clear on this.

 

He explicitly states that transactions are pre-arranged and then executed atomically. There was no sequential execution, execution was simultaneous. The balance sheets may look like a sequential transaction, but that's the nature of a balance sheet, if you want to show each part of the transaction. Otherwise you'd just see a start state and end state and all the flows would be invisible. 

Share this post


Link to post
Share on other sites
34 minutes ago, Wandering_Dog said:

He explicitly states that transactions are pre-arranged and then executed atomically. There was no sequential execution, execution was simultaneous. The balance sheets may look like a sequential transaction, but that's the nature of a balance sheet, if you want to show each part of the transaction. Otherwise you'd just see a start state and end state and all the flows would be invisible. 

I literally quoted the text in the transaction stage where an assumption was made. You are a practised arguer and I have no reason to listen to you anymore. This whole document was formed on the basis of correspondent banking where one party offloads liabilities to another. With the ILP there is no counter-party risk and no 'debts' are based from one person to another. The entire value in all it's glory is passed from one to the next where is is negotiated and secured prior to transaction over the ILP. Then initiated and completed in four seconds.

No counter party = no liabilities.

Unless we are going to change the meaning of Debt to Value Held?

Share this post


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

I literally quoted the text in the transaction stage where an assumption was made. You are a practised arguer and I have no reason to listen to you anymore. This whole document was formed on the basis of correspondent banking where one party offloads liabilities to another. With the ILP there is no counter-party risk and no 'debts' are based from one person to another. The entire value in all it's glory is passed from one to the next where is is negotiated and secured prior to transaction over the ILP. Then initiated and completed in four seconds. 

Would you please be so kind and explain how you exactly think value can be transfered by the ILP without any party holding a bridging asset inbetween (even for a fraction of a second)?

15 minutes ago, BrownBear said:

No counter party = no liabilities.

Unless we are going to change the meaning of Debt to Value Held?

Where in the world is any business done without any liabilities, at all? Even if you buy your morning roll from the local bakery, you will still be liable to the baker for a few seconds, which will only be settled with the payment (and payment processing: mostly cash).

Share this post


Link to post
Share on other sites
1 minute ago, tar said:

Would you please be so kind and explain how you exactly think value can be transfered by the ILP without any party holding a bridging asset inbetween (even for a fraction of a second)?

 

Your document does't talk about a transfer of value. You explicitly used the term liabilities. A liability is a debt. The fact you are now using transfer of value makes me think you either don't know what a liability is or you are trying to change your argument. But then you you pointed out that you don't think it is a transfer of value but a debt with your next sentence.

Quote

Where in the world is any business done without any liabilities, at all? Even if you buy your morning roll from the local bakery, you will still be liable to the baker for a few seconds, which will only be settled with the payment (and payment processing: mostly cash).

No debts were held at any stage in the process. The ILP is a fund mover, not an IOU mover. 

As for your morning roll comment, no debts are owed unless you promise to pay for the roll AFTER receiving said roll. Other wise until you pay, the roll still belongs to the Baker.

 

Do you know the difference between a debt and a transfer of value? Do you know what the term liability means? With a debt there is a risk the counter party doesn't pay what is owed. With a transfer of value, there is no risk as you know they have it to pass on and it's been secured prior to the transaction even starting.

Your post history search reveals you have misunderstood this concept for over a year now and had it explained to you several times.
 

 

 

Share this post


Link to post
Share on other sites
1 minute ago, BrownBear said:

Your document does't talk about a transfer of value. You explicitly used the term liabilities. A liability is a debt.

Of course, as the document describes the cross-border settlement of payment transaction and payments are only used when fulfilling liabilities (of which the corresponding claims have a fixed nominal valuation, by the way).

1 minute ago, BrownBear said:

The fact you are now using transfer of value makes me think you either don't know what a liability is or you are trying to change your argument. But then you you pointed out that you don't think it is a transfer of value but a debt with your next sentence.

No debts were held at any stage in the process. The ILP is a fund mover, not an IOU mover. 

Which process you are talking about? The ILP (as the XRP Ledger) is used as bridging tool inbetween the overall payments process which of course fulfills liabilities (and yes: liabilities are not part of e.g. the XRP Ledger).

1 minute ago, BrownBear said:

As for your morning roll comment, no debts are owed unless you promise to pay for the roll AFTER receiving said roll. Other wise until you pay, the roll still belongs to the Baker.

Sure - and P_usa already received a product from P_ger which P_usa has to pay (hello liability). Where exactly do you see the discrepance?

1 minute ago, BrownBear said:

Do you know the difference between a debt and a transfer of value? Do you know what the term liability means? With a debt there is a risk the counter party doesn't pay what is owed. With a transfer of value, there is no risk as you know they have it to pass on and it's been secured prior to the transaction even starting.

Your post history search reveals you have misunderstood this concept for over a year now and had it explained to you several times.

What the heck are you talking about?

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