PayChan enables Ripple Inc to be a lender of XRP, so Traders can Short XRP

[KarmaCoverage]

https://medium.com/@KarmaCoverage/ripple-inc-as-a-lender-of-xrp-risk-exposure-goals-keep-upside-protect-borrower-from-downside-d018095d696f

https://xrpcommunity.blog/payment-channels-ripple-as-a-lender-may-17/

I had been thinking about PayChan, SusPay, ILP and some market dynamics of these features between Ripple inc (lender), Exchanges (borrowers), and Traders (shorting XRP).

Please tear this apart if the logic is not sound.

Cheers

Edit: There is 1 mistake in the chart , but it does not change the conceptual flow.

Edited October 7, 2018 by KarmaCoverage

[Guest]

a lot to digest here -- thanks

quick (possibly dumb) Q!

in a PayChan, when the price of XRP shifts, and you need to pay out, is there some way to adjust the payment AMOUNT in reasonably real-time proportion to the price?

e.g. if a paychan could be setup via some program to automatically adjust payouts based on price metrics/averages

or is it better/simpler to mitigate by just having short timeouts on the extension of credit / payback

??

[KarmaCoverage]

13 minutes ago, zerpdigger said:

a lot to digest here -- thanks

quick (possibly dumb) Q!

in a PayChan, when the price of XRP shifts, and you need to pay out, is there some way to adjust the payment AMOUNT in reasonably real-time proportion to the price?

e.g. if a paychan could be setup via some program to automatically adjust payouts based on price metrics/averages

or is it better/simpler to mitigate by just having short timeouts on the extension of credit / payback

??

I thought about this a bit. 

1. The PayChan only needs to be "topped off" if XRP goes down. This could probably be automated at some trigger point. "USD Value drops by 10%" or something.

2. The PayChan sender can send more Reciepts to make up for Market movements, in the downward direction also.

3. My original thought was that PayChannels would be started and closed rapidly because the longer the value is escrowed the more exposure to Market Volatility Risk, but now I am unsure what I think about this. Other than to say, "if you can create the risk, you can create the inverse, so risk control is doable."

Edited May 16, 2017 by KarmaCoverage

[Eik]

I think I like the idea, but I'm not sure I entirely get the concept. I am also not very familiar with the risk market and how you jump directly to credit market. In the end you want Ripple to lend XRP to e.g. market makers? And Ripple pays if the MM loses due to drop is XRP price? Why do you need paychan for that?

[KarmaCoverage]

32 minutes ago, Eik said:

I think I like the idea, but I'm not sure I entirely get the concept. I am also not very familiar with the risk market and how you jump directly to credit market. In the end you want Ripple to lend XRP to e.g. market makers? And Ripple pays if the MM loses due to drop is XRP price? Why do you need paychan for that?

Those are unrelated concepts, I was just trying to give some background on the author, and hint at what topic I will write about in future writings.

Basically, just ignore the statement about Insurance being a credit market, till some other stuff gets published.  If you want to,  you can think about RCL and the role of IOUs & Trustlines, and find the few threads here where I have previously said, "Risk is the killer app for distributed ledgers"... and I will expand on that with future articles. (although a few here have seen the articles already) KarmaCoveage is closer to Fugger's original thinking.

None of that has to do with using PayChan to enable Ripple Inc to extend XRP based credit to Exchange/MMs, thereby enabling Exchanges to allow Traders to go Short XRP.

Not being able to go Short XRP is something that has been a problem for a while. It is a necessary capability of any market for Traders to manage their Risk. 

Edit: I put in an extra statement at the end of the intro to clarify the rest of the article is not about the Risk Markets. Thanks @Eik for the feedback.

Edited May 16, 2017 by KarmaCoverage

[Eik]

32 minutes ago, KarmaCoverage said:

[...]

None of that has to do with using PayChan to enable Ripple Inc to extend XRP based credit to Exchange/MMs, thereby enabling Exchanges to allow Traders to go Short XRP.

Not being able to go Short XRP is something that has been a problem for a while. It is a necessary capability of any market for Traders to manage their Risk. 

[...]

I understand a bit better now the reason of this scheme. I still don't see the need for a paychan for this. Other than giving a false sense of 'your short position is backed up by this part of Ripple's XRP stash'. In the end it needs Ripple's act of writing a receipt to move this XRP if needed. Whether that happens in a paychan, or without, doesn't seem to make a difference to me.

[KarmaCoverage]

7 hours ago, Eik said:

I still don't see the need for a paychan for this.

Exactly why I posted it here, to beat the idea up a little bit. 

7 hours ago, Eik said:

Other than giving a false sense of 'your short position is backed up by this part of Ripple's XRP stash'. In the end it needs Ripple's act of writing a receipt to move this XRP if needed.

To go short the Trader needs to be able to sell the XRP on the open market, then wait hoping it goes down so the Trader can buy XRP on the open market for cheaper, and return the XRP to the Exchange.

By using a funded PayChan, the Exchange knows how much XRP it can make available to Traders for going Short. Ripple can manage this, adhering to their XRP MM strategy.

The key is that, the Exchange can enable Traders to go Short without...

1. Borrowing XRP from other Trader's accounts. (this is how it is done in the stock market, sort of)

2. Going to the Open Market to buy XRP with the Exchange's own money, putting the Exchange at risk of price movement from XRP. Plus the Buy transaction sort of negates the whole desire to Sell the XRP once it is in the Trader's acct.

3. The Exchange is not being required to hold XRP in inventory, again exposing the Exchange to risk of price movement from XRP. 

The key here is that a Trader who wants to Short XRP,  wants the Downside Risk of XRP. But there needs to be a way to not expose the Exchange to the Downside Risk.

An Exchange is not in the business of taking on trading risk. Ripple Inc is already exposed to this downside risk, whether or not the XRP is in their Cold Wallet, or stored in a PayChan. 

When the Trader wants to go Short XRP, they place a Short trade with the Exchange, who requests a receipt from Ripple Inc. Then the Receipt is cashed and the XRP moved from the Exchange to the Trader's wallet, and the Trader sells the XRP on the open market.

The Exchange can charge a fee as a % of the value that the Exchange arranged to lend to the Trader in XRP. I think 5% was what the one exchange doing this offered. The Exchange keeps the 5% interest, basically risk free  because they did not expose themselves to XRP.

Now if the Trader's acct gets to low the Exchange will hit the trader with a Margin Call and freeze their accounts, this is how it normally works in the stock market.

When the Trader returns the borrowed XRP to the Exchange. Depending on the terms agreed upon by Ripple Inc & Exchange, the Exchange can use the XRP in lue of future Receipt Requests from Ripple Inc; or the XRP can be kept in a multi-sig wallet with some sort of agreement about when the XRP will be returned to Ripple Inc. 

What does Ripple Inc get out of this whole thing? A solution to risk management for Traders via Shorting XRP, which should help encourage liquidity on RCL, improving the utility value of XRP.

That is the thought, beating the idea up is why I posted it. 

Edited May 17, 2017 by KarmaCoverage

[Guest]

just re-read this today @KarmaCoverage after our private messages -- i think i see it clearer now

quick q: paychans are "one way" traffic, right? but a key is shared between payer and payee and the paychan itself is public ; could there be some automation of payback or top up where one channel checks against another and can offset against it if there are price swings?

[KarmaCoverage]

8 hours ago, zerpdigger said:

quick q: paychans are "one way" traffic, right? but a key is shared between payer and payee and the paychan itself is public 

Paychans are one way, but there is not a shared key between payer and payee. The payer creates the paychan on ledger, then funds it, then sends the payee a series of receipts, which the payee knows they can cash in at any time. Then there is a PayChan Close TX type to close the channel and refund the unclaimed balance to the payer.

Unrelated, but, regarding "but a key is shared", there is this... https://interledger.org/rfcs/0016-pre-shared-key/ 

8 hours ago, zerpdigger said:

could there be some automation of payback or top up where one channel checks against another and can offset against it if there are price swings?

The only thing you can do is "top up" or close a paychan, and reissue a new paychan to reduce the amount originally funded into the channel.

I think there should be some way to have a wallet subject to MofN issue a paychan, then have a smart contract dapp be one of the signers. I'd have to check on how MofN exactly works and how or what that could enable. 

If the goal is to offset price swings, you can always have the receiving party create a paychan in the opposite direction. Then have a smart contract be MofN for both paychans, and each receiver can sign (but only if the dapp does also) to send a receipt to them selves for the amount that would net out the effect of the FX change.

At first thought, I bet this set up could probably be used with some dapp business logic to create a type of XRP derivative, will think on this, (maybe this could be used to help peg value of an IOU on another blockchain, like discussed in the decentralized exchange thread?)

Edited January 15, 2018 by KarmaCoverage