If it is anything at all, xPool just sounds like a “pool of liquidity”.
(You can skip the intro by starting after the link to the previous article)
Liquidity is going to be a defining KPI for any blockchain to achieve success. I say this because these are fundamentally Transaction Networks, and if you are desiring to improve the health of a transaction network, you want to increase flow through the network. In this case the blockchain tool is being applied to create an Internet of Value, so the thing which should flow through the network is Value, and the flowing of value is called, “Liquidity”.
There are many types of “Financial Services” that IMHO honestly boil down to acting as liquidity providers, and I think blockchain as a technology is uniquely able to help address various liquidity risks. In my attention towards the Risk Markets, I have observed that the idea of Insurance as a “financial service”, is essentially providing a “liquidity service”, callable due when the agreed upon risk event has occurred.
What follows is nothing more than a combination of my personal observation of Ripple Inc’s development efforts around building an Internet of Value. How their product offering has been built up, split apart, and now appears to potentially be expanding into new solutions (xPool)... Plus my personal thinking about how to configure an application of the tools Ripple has built, albeit with the financial service redesigned specifically for the Risk Markets (instead of payments), which I have expanded on here.
For basically Ripple’s entire existence there have been a few finance folks hanging around, myself included, saying in various ways that “XRP markets will eventually need to develop derivatives and enable hedging”. This is a tough challenge for all cryptos, because as Miguel says, “If you want to sell something, you either need to have it, or borrow it”, but since you cant poof crypto into the world like a bank can with a fiat loan, and most crypto is held by very few folks, a borrowing arrangement is needed. Setting up lending and borrowing of any crypto has proven difficult to say the least.
We need a few things in place before someone will be willing to lend their crypto. We need a method to a) consider a segment of time, and b) some method of collections enforcement for both interest and the return of initial capital. In the fiat world these are easily addressed with contracts backed up by legal systems.
In crypto before PayChan, and Escrow there was no on-ledger method to consider time, and there was no on-ledger method to enforce an outcome at the end of that time.
When PayChan first came out I started thinking about using it to structure a borrowing arrangement, which is a topic that has been discussed various times over the years. Here are my original thoughts on PayChan and XRP Lending, and here is a discussion on XRPchat.
Sidenote: I saw one of the Ripple folks recently say they could get a loan in USD backed by XRP, but that it had to be over collateralized by 30%, so it would take $130 of XRP to get a loan for $100 USD. I have wondered if this was done using a payment channel, or just a legally enforceable contract addressing key control between friendly parties.
Ripple Inc as a lender of XRP. Risk exposure goals: keep upside, protect borrower from downside
To avoid repeating myself, I am just going to pick up from where I left off, and going forward I will assume Ripple is using Payment Channels to effectuate loans.
Since writing that previous article just shy of a year ago, I have seen a few new communications from Ripple folks.
In this video, (listen to the full answer) Miguel mentions lending, and exotic derivatives where Ripple is a counter party on “XRP Lending”. Before that he says something to the effect of recognizing that the XRP markets need the ability to hedge, if it is going to gain global institutional use. I agree.
Interledger Protocol (ILP) seems to be finishing up and preparing to go into a new phase of production soon. With his final point # 12 of his article, Evan Schwartz explained that in the new ILP architecture, what I called the, “set em up, and knock em down” (backwards first, then forward settlement execution) approach using the Escrow feature has been abandoned, because “simple payment channels” are enough to get the job done. Here is a conversation about these ILP changes for those interested.
The key point for this article is, “PayChan is taking center stage in ILP”, as the connection method for the Internet of Value, and as I articulated in the prior article this Payment Channel feature can be, but does not have to be, used for the creation of a credit facility.
This is where I start making stuff up (or maybe the whole thing, idk)… What would the goals of xPool be?
At the top I started off discussing Liquidity and how important it is to the success of Ripple, and really any blockchain or network. So I believe the goal of something like xPool would be to…
Prime the pump for new fiat:XRP markets where necessary, both supply & demand side
Improve competitiveness of Ripple Rails where the pump is already primed. This could be by improving Depth or by reducing Costs of the corridor.
Enable hedging and derivatives to be designed, the financial engineering work
Step 1: Priming the Pump… I imagine each time Ripple Inc is “Signing up” an exchange, that, in the process they will discuss individualized loan terms, denominated in the local fiat currency, but settled in XRP.
This is a similar to the commodity futures/forwards that are traded in dollars, but settled in cows, xrp, corn, gold, or port bellies. Note: Miguel’s comment in the video above about needing institutional custodians. Custodians are used with commodities also. I will also come back to the distinction of futures and forwards, and draw an analogy to the distinction between Payment Channels and on-ledger IOUs, within the framework of Ripple managing fiat loans settled in XRP.
Step 2: Improving competitiveness of Ripple Rails… Next, the Exchange’s API will be integrated into Ripple’s xRapid product, and in doing so the exchange may have to improve their API services to be RippleNet compliant.
There are likely Market Maker incentives in the “loan terms” for the Exchange to act in ways that best enable value flowing through xRapid, I would expect these to be something like a near 0% rate on XRP used directly in payments flowing through XRPLedger, but where the Exchange still gets to keep their fees, and maybe some spread. This makes the depth of liquidity equal to the amount of XRP in the Payment channel, and reduces the cost improving the competitiveness of using Ripple Rails
Step 3: Enable hedging and derivatives… If there is not a loan of XRP to the Exchange, then the Exchange must have paid cash for their inventory of XRP. In any case, the Exchange has to consider it’s XRP risk exposures, and they are in a unique position to solve one of the technically difficult challenges to lending crypto… Enforcement!
Most Exchanges will hold the XRP acting as custodians, “on behalf” of their trader user base, not giving each user their own wallet on the XRPLedger. This is good for many reasons, although many crypto enthusiasts scoff at the idea of “Hosted Wallets”. This is important because custodians need to get business insurance, and Lloyds while not offering insurance on crypto assets directly, may be offering insurance on a Crypto-Exchange’s business operations. This passes a “but in reality” scratch and sniff test, often needed in the crypto world.
What this functionally means is, that if a trader borrows 100 XRP from the Exchange to go short on XRP and those XRP are held in a wallet that the Exchange controls the wallet’s keys for, aka a “hosted wallet”, and then suddenly XRP goes against the trader and through the roof… Then the Exchange can liquidate the trader’s position at some threshold to control the Exchange’s loss exposure to the trader’s bad trade (remember they lent the trader some XRP, and he has to pay them back in XRP that he may now not be able to afford). The Exchange will be acting like any stock brokerage firm and will liquidate the trader’s positions, if the trader does not pay a margin call, which this hypothetical trader would probably be in.
If the Exchange were to send the borrowed XRP to a wallet on the XRPLedger controlled by the trader, then the Exchange would lose the controls necessary to enable the hedging / shorting activity. Should the trader never want to speak to the Exchange again, there is no way for the Exchange to do anything to make a transaction from the wallet with the lent XRP without having that wallet’s keys.
This has turned into a longer post than intended, and I haven't even got into How this could be worked out. So, I will wrap it up here.
To summarize, if the above is near true, Ripple Inc will end up in a situation where they have all these Payment Channels to various Exchanges, involving many fiat currencies, governed by many jurisdictions, and with each relationship being defined legal agreements with varying terms… and while I think this makes good enough sense for now (pump priming season), this just seems like an absolute nightmare to manage if scaled up to 100s of Exchange relationships.
This somewhat chaotic emerging situation is what I’m guessing will ultimately mature into a streamlined xPool service offering, if not a wholly owned subsidiary. I will try to expand on How xPool may come together, then morph as it matures, in what is apparently another forthcoming article.
That is it for now.
Thanks for reading.
For conversation on this topic, click here.