KarmaCoverage

I had a coworker a few years back who was a big SeekingAlpha reader. We often talked finance stuff, and I tried telling him about XRP, but he assured me that if Seeking Alpha didnt know about it or have any articles on it, than it was probably a scam or something, but it was surly nothing of importance. I wonder if he will end up reading this article now?

If Ripple Inc can earn revenue on the basis of value flows through RippleNet, then Ripple will probably be bigger than Google by 2025. They can earn this revenue based upon liquidity flows, via their "Market Maker" or "Liquidity provider" incentive program by lending XRP to active RippleNet market makers &/or ILP Connectors. (like Kava). When you are in the business of providing liquidity, you have to float value on each crypto-ledger/fiat jurisdiction in which you do business. This requires that you have some inventory of value. If we are talking USD : EUR , then you need some inventory of both USD and EUR. Same goes for any market maker for XRP, they will need some inventory of XRP. Much like a Car Dealer will borrow money to buy their car inventory, a liquidity provider is acting as a Dealer in the market, and as a Dealer they may be interested in borrowing some XRP to lower their initial outlay of value required to begin business operations. Lets say you have $1 million in USD float available and an interest in providing liquidity between USD and XRP. Assuming you have symmetric flows in both directions, you would need to split your float capital in half, holding $500k in USD and $500k in XRP... meaning you have $500k of "value bandwidth", or "liquidity available to trade", or "inventory on both sides of the market". However if Ripple was willing to lend you $1 million of XRP, you could double the amount of liquidity your market making operations would bring to the market. You also get some leverage, because you only really had $1 million in value inventory to trade, but now you are able to trade a total of $2 million of inventory. Make sure you set your spreads higher than the interest cost to Ripple for the XRP loan, and you should be happy with increasing flows and more inventory turn over cycles. RippleNet & XRPLedger as networks win because you are providing double the liquidity, so flow rates of value going through the network can be double. If you are running a network business a key KPI is going to be flow rates. For Ripple this is Liquidity Flow, for Google this is "search flow" through Google's network of back links. Ripple Inc wins because their XRP asset base now generates a cash flow stream. When I say Ripple Inc could be worth more than Google by 2025, I'm basing that only on revenue from value flows. As a reality check, remember that all of Google's income has to flow into Google, and so does every other business/person in the world. I am also assuming that Ripple does not sell XRP, so no capital gains, although XRP would be an asset on their balance sheet.

To make this even funnier, Blockbuster could have bought Netflix when it was young. The CEO wanted to do the deal, and the board moved aginst it. They fired the CEO, waited a few years to realize just how bad they screwed up.. then rehired the CEO and tried/failed to play catch up. The personal irony is that the insurance franchise I left circulated this story as a means of boasting about their innovativeness, which means buying & internally bundling SaaS services. Yet they had a chance to start working on P2P back in 2014, and I brought them other cost saving, service improvement, control of data flow options, and the scoffed like I was crazy. They dont know what game they are playing.

That is what made me point out that RippleNet runs in atomic mode, making no need to financially insure something..that is already insured to succeed/fail from the technical aspects of the process unfolding. I'm not 100% sure if RippleNet can guarantee end-to-end FX rates? Also not sure if, given that it runs in atomic mode, if that would even matter to FX rates in the payment path? In the IoV, running universal mode, there can be some "slippage". I think this risk is mitigated by using Limit Orders. I heard one of the FI/Bank practitioners on stage at SWELL say that their client (assuming a corp treasury dept) basically gives them a limit order. Something like, "I will pay up to $100 USD, if you deposit €90 in this EU bank account." From the Crop's perspective if it comes out to only cost $98, to deliver the €90.. then great! From there the payment needs to be routed, or find a payment path(s) to flow through to get to the destination bank account. In RippleNet, I still dont know for sure how this pathfinding is done, but I have taken guesses at how it could be possible. In the IoV, we have Connectors, and they provide this pathfinding function via the same market mechanics as the Dealers function as described in this thread which links to this video. IMHO it was a very astute design decision, to include the economic role of Dealers, aka ILP Connectors in the architecture for an open IoV. Like Dealers making a market in today's stock : fiat orderbooks, these IoV Connectors are providing liquidity (aka an inventory of value) and making a market between two ledgers.. crypto : fiat, or fiatA : fiatB, or fiatA-here : fiatA-there.. whatever. Given that they hold inventory across time, they are exposed to FX rates in that way, And they are also exposed to FX fluctuations for the time between when they commit to a payment's FX rate, and the time that commitment settles, or expires releasing the committed liquidity. For the Connector, there are two mitigation tactics here.. One is effectively a limit order to allow for some FX slippage. You dont want to use a market order (fully exposed to any FX movement), and if you set your limit price to close to the market price, you risk your order not executing, and miss out on earning the spread... The other is to control Time exposure via order timeouts ..which is like a day order (except in seconds) that can just expire unfilled, if it doesn't execute in the time slot. So in the IoV, what I think happens is the Original Sender sets a Limit Order for the trade, then that full limit order's slippage, can be cut into smaller chunks by all the connectors along the payment path into a series of Per Hop limit orders, each allowing for it's own "per hop slippage". As long as all the Per Hop slippage, sums up to be less than the Full Order slippage, Success - the value should flow, if the opposite, Fail - the value flow should not flow. The same goes for Time Exposure. The initial Corp order will come with a time limit, "end of day", so lets pretend that is 3 hours. Each Connector will extend a shorter and shorter time slot to the next Connector, because each will need time to receive the Fulfill packet, process it, and still have time to relay that fulfill packet to their up-stream Connector. The "insurance" word caught my attention. I think RippleNet can give free "Assurance", but I dont see any need for financial insurance on a transaction. A limit order should be sufficient, and would leave some life and natural fluctuations in the system dynamics, which personally I think is an important attribute. How this dynamic could be accomplished is what I tried to describe as "distributed pathfinding" in the How xPool write up. This could be done in RippleNet, via nostro/vostro relationships being expressed on each xCurrent user's own private Rippled ledger.

All ILP related, & how ledgers are connected. It is somewhat trivial, yet somewhat technically critical, due to risk exposure and mitigation tactics. The ILP white paper explains the two modes of operation. Section 3 & 4, intro of 4 gives a tldr.

& @Hodor remember RippleNet operates in Atomic Mode. Therefore there is no "settlement risk", meaning there is a 0% chance of less than 100% of the legs/hops in the payment path not executing. So the idea of "per transaction insurance" would be essentially an arbatrage (risk free) service, because it is the atomic nature of the network that assures an "all-or-nothing" transaction execution. In contrast to RippleNet, the IoV is run in Universal mode, which cant guarantee end-to-end transaction execution.

You're mixing up "unit price" and "market cap", which in this context you correctly observe would move in inverse directions.

I outlined how this can be done with Payment Channels here.. https://xrpcommunity.blog/payment-channels-ripple-as-a-lender-may-17/ I think it makes a while hell of a lot of sense for Ripple to loan both Exchanges, and any Banks who want to act as a multi-hop liquidity provider on RippleNet. Edit: just re-skimmed that one, it does not make the point made in the How xPool one, that "if loans are denominated in Fiat, yet settled in XRP"... than the loans are accomplishing the "Gateway Role" of on/off-boarding value to the XRPLedger from fiat.

Blue sky laws are a state by state compliance effort, but they should be able to get all 50 within a year.

It's because @miguel has a firm grasp on the mechanisms which make markets function. He understands the types of market players and each's motive for engaging with a market (hedgers, speculators, arbitragers). He also knows all the types of markets available to work with.. regular equity markets, bonds, options, SWAPs, futures/forwards. Each of these has it's own set of mechanisms which make it work. I guess we can now add XRPLedger to the list as a new type of "market making tool", and he seems to understand it's capability also (bitcoin cant make markets, it only has a unit of account on ledger).

On mobile so havent looked at orderbook details. However, if it can be observed that "large Bid orders & large Ask orders" are hitting the same time slot's ledger close... this would seem to be xRapid liquidy order flow matching. Idk

Yeah, sorry for the mini rant. Financially abusive things really get under my skin. There can be no pride had by fooling someone who does not have the capacity to understand. It'd be like Usain Bolt running iin the Special Olympics and then somehow thinking he accomplished something because he got a gold trophy. For real though, as I was typing that out, I realized there must be a pretty easily prosecuted and extremely lucrative class action lawsuit which could be repeated and brought against bank after bank after bank. The Florida law reads... here is the laws by state https://www.independentagent.com/Education/VU/SiteAssets/Reference Lists/170317 - Over Insurance Statutes by State.pdf Literally every single agent puts their license at risk with every "new purchase" policy sold. This is just another reason I got out of the industry. Not only do I find it fully distasteful to screw clients who come to me for help as a means of earning a living... but I was breaking the law and putting the whole business at risk (it was all based upon my license) as a normal course of doing business. I tried, and did hold firm temporarily on a few policies. I even sent a few Bank underwriters the Florida statutes and refused to over insure the client. I did not make any friends, and p!ssing some people off... eventually leading to the client knowingly asking for to be "over insured" just to get the deal done. Oh man, this still irks me to no end! I'd think this would be a very easy, very large, open & shut case for a good law firm to bring against some deep pocket banks... and there is an ROI sweetener for the law firm... once the first case is settled, there are dozens of deep pocket banks in the cue to settle without all the additional costs and effort of prosecuting each case.

What does this have to do with CBDC? I can sort of see where it may help, but I havent seen any technical system architecture specs that show using Corda. IMHO the Fed would be best to spin up a Rippled ledger, with the Fed branches as the Validators, and only allow regulated financial institutions to connect to their CBDC USD network. This is a great thread you started btw.

I think they do this to avoid being accused of running a rigged bidding process. I've been simi watching this FPTF since inception. I hope their conclusions will be meaningful and actionable.