How xPool may work? An attempted guess

This will begin with the idea of loaning XRP to Exchanges, for reasons explained in the previous segment, then I will take those ideas about lending XRP and point them towards Banks, and Central Banks as well as other xCurrent users.

Exchanges & Remittance MSBs

Both of these types of Financial Institutions (FIs) are similar in that they specifically focus on managing a ledger upon which, one form of value is converted or “exchanged” for another form of value. This is a simple change in the value’s denominator (like flipping a fraction upside down), or as is more common to say, a “change in the denomination of your money”, from USD to EUR.

One key difference between these two financial services is that Remittance MSBs trade their own money (providing their own liquidity), on their own ledger. While Exchanges dont trade their own money, rather they enable end users (speculators at this point in time) to be traders and trade, aka “change the denomination of their value”.

Another key difference, is that Exchanges only change the value’s denomination. While Remittance MSBs can additionally change the value’s physical location, with or without changing the value’s fiat denomination.

Now, one of Ripple’s key goals, is parings with fiat. So both of these FIs would enable that, they simply need some XRP. They will get more network effects by having XRP trading partners.

So, if Ripple wants to help both of these types of FIs deal in XRP, then the FIs will need some XRP inventory to trade and move around. Ripple either has to…

1. Lend it to them, or
2. Sell it to them direct, or
3. Let them buy it on the open market

Since we are talking about new technology and financial networking, acting as the CEO of one of these companies concerned with risk exposures, it would be responsible to try and borrow some XRP to test things out first, and make sure this is sustainable for the long term. Given the remaining uncertainty of XRP regulations, it would be best to denominate any loan from Ripple to an Exchange or MSB in fiat, and have the loan be compliant with the local fiat’s jurisdiction.

Any lending activity in Fiat, that is collateralized by XRP is effectively accomplishing the Gateway function, of transferring value on-to or off-of the XRPLedger.

Primary issuance (ie the first time XRP is exchanged for Fiat) is a bit of a legal issue, somewhat related to the ICO issue. It appears Ripple has addressed this through their subsidiary XRPII that holds most of their XRP and that is Bitlicensed in NY to sell XRP as a wholesale Utility Settlement Token.

Plus the architect of the Bitlicense joined Ripple’s board. So Ripple appears to be licensed for Primary Issuance of XRP, which I think means they could choose to loan it out, or sell it outright. I doubt using a loan, would skirt the legal issues of Primary Issuance.

If they do individualized loans to each Exchange, the Exchanges will need a wallet on XRPLedger so that Ripple/XRPII can set up a Payment Channel loan to their wallet. Once that is set up, to participate in XRapid, they will need some XRP vested into their account (ie Ripple sent them a receipt for the PayChan that they can “cash in”, to settle and receive the XRP ), and this also gives them some XRP to send to other Exchanges, providing liquidity to support xRapid payment flows.

The rest of the Payment Channel balance acts like a line-of-XRP-credit, that the Exchange has with Ripple/XRPII, but they need to some how request another Payment Channel receipt to “settle” more XRP when their users exhaust their current XRP in inventory. This can be viewed as a measure of increasing Liquidity Flow, easily tracked by Ripple per PayChan receipt as an incentive KPI (I will come back to this point).

With each PayChan receipt to the borrower, more XRP liquidity is available for Settling, creating “deeper liquidity” in the live market. The timing of liquidity deepening, would be driven by real world market dynamics, by individual Trader activity, and by real world Remittance activity.

Each loan would be denominated in fiat, but settled in XRP. The loan terms should spell out, how (via XRP obviously), and when any net settlement between Ripple (the lender) and an Exchange/MSB (the borrower) will be due.

• If Ripple needs to loan the Exchange more, they send another PayChan receipt, so the MSB can increase their XRP inventory.
• If the Exchange needs to pay off the loan, or pay interest on the loan; those payments can be converted from the loan’s nominal fiat amount due, at the current Spot rate into XRP, and be paid directly back to Ripple/XRPII’s wallet on ledger.

At this point xPool software would be comprised of only of a bunch of individualized loan agreements, some tracking and analytics, and tax records. This seems like a reasonable place to start, but looks like a nightmare to manage if scaled up….

Im going to move on to Banks for now, jump down towards the bottom section “How xPool? How single ledger? How multi ledgers?”, to pick up on Exchanges and Remittance MSBs.

Banks and Central Banks

Why — Why Banks? Why Central Banks?

In the previous segment I had explained the reasons why it would make sense for Ripple to lend XRP to Exchanges and Remittance MSBs (to enable hedging & fiat pairings). That activity would also serve to bring value onto XRPLedger, with those FIs acting like a Gateway. The role of a “Gateway” is on-boarding & off-boarding value, to the RippleNet or the ‘Internet-of-Value’… this was originally proposed as the role for Banks to play. The reason being that, “Banks are the custodians of fiat value”, as Larsen said a few years back.

The original idea was, that banks could have a wallet on the XRPLedger, and then they could issue a balance onto XRPLedger (on boarding value), that would directly correspond to a “mirror account” with the same balance of fiat, on the bank’s corp ledger. This gives you double entry accounting, and a way to balance things out.

This would enable a user to deposit fiat into the bank/gateway’s “mirror account”, a simple internal transfer on the bank’s corp ledger. Then the bank would issue your personal wallet on XRPLedger an equal amount of IOUfiat.bank.

A user could then go on XRPLedger to find orderbooks to trade their IOUfiat.bank for XRP. As well as find other orderbooks pairing IOUfiat.bankA to IOUfiat.bankB. During this timeframe the idea of “XRP as a bridge currency” came about, when they added synthetic orderbooks and Autobridging.

…All of that was rejected by the banks, and more or less scrapped for Interledger Protocol (ILP). I wont expand on how significant this was, but it marked the end of the “one ledger to rule them all” idea, and marked the beginning of the idea that we now call “RippleNet” and it’s parts, or the Internet of Value, is the result.

Reminder: As I wrote in a previous article, the “IoV is RippleNet”, each bank that buys xCurrent from Ripple Inc, Is running their own private Ripple Consensus Ledger (RCL), or what I will now call an “xCurrent Ledger”, behind their own corp firewall.

This means that, each bank running an xCurrent ledger can ILP connect with other banks running an xCurrent ledger via ILP, as well as connect with the XRPLedger directly, all by using Payment Channels. **Another key point that I will come back to later, is that each bank’s xCurrent ledger can preform payment routing functionality, via its pathfinding algorithm. Payment Flow through PayChans would be a great incentive KPI for Ripple to design into xPool.

If banks running an xCurrent ledger want to use existing Nostro/Vostro (N/V) relationships, they can simply mimic those relationships on their own two private xCurrent ledgers. This can be done by either, using IOUs, to reflect fiat cash funded positions held at each other’s bank in the “mirror account”; or if the N/V relationships are managed as lines of credit, Payment Channels between their two xCurrent Ledgers could be used, or most likely a mix between cash & credit/PayChans is probably optimal.

I can see a chance that the combination of features that are cryptographic security being strong enough + settlement being fast enough to improve inventory turnover cycle times significantly; that banks may be able to convert some of their existing foreign cash fiat funded nostro positions, into credit positions (ie, pulling their foreign float back to their own domestic corp ledger). Then net settle very rapidly between their two xCurrent ledgers directly, with a smaller remaining nosto account balance, or through the XRPLedger, or through a Central Bank run xCurrent ledger.

They could certainly do a cross-boarder transaction in this way, using existing N/V relationship connections without XRPLedger being in the payment path (even multi hop transactions! I will come back to this). The issue is the cost of floating the capital, and how the existing N/V cost structure can compete against the xRapid cost structure (note the XRPLedger is the “ Market for Float” part.. combined with.. what in this article is also noteworthy, that Market Maker behavior is emergent, thus making RippleNet a Complex System, I will come back to this) …which should end up emerging into a situation where the bank does not need to allocate near as much value to floating capital in multiple foreign markets. Unless the bank wants to and is actively Market Making for a profit (which can be done on their own private xCurrent ledger).

The other part of the cost comparison equation is the FX pricing component to the cost of floating foreign capital, that is introduced when the cross-boarder hop is introduced. Remember the “change in denomination” and “flipping a fraction” part from above? I will take a look at the math below!

There are three things I want to point out here, that I have eluded to above.

1. Single Ledger (XRPLedger) — Triangular arbitrage, aka “Multi-Hop payments paths”, and how that ties in with the fraction math, and Trustline Quality in/out.
2. Multi Ledgers (RippleNet) — The very key role of Routing (like ISPs), aka “Pathfinding”, through the various connection types with in the RippleNet architecture, and where & how it happens.
3. RippleNet Topology (this became the next segment)— The combination of those first two functionalities with Market Making activity; and how this enables the emergence of an actual Decentralized and Complex global monetary system

Banks and Central Banks

How xPool? How single ledger? How multi ledgers?

I will tackle each of these three in order, to round out this segment. Starting with a pool of IOUs on a single ledger… XRPLedger

Where I left off at the top portion about Exchanges and Remittance MSBs with the idea that Ripple could approach these FIs with individualized loan terms, and effectuate those terms via individual Payment Channels… In this set up all the XRP:fiat paring would be accomplished off of XRPledger, and on the ledgers of the Exchange or MSB.

The problem this leaves lingering is one of difficulty in managing multiple relationships, as well as not really enabling automation and information to flow about FX prices in all avaliable Exchanges.

So to address those issues I will toy with the idea of fiat IOUs being issued on XRPLedger in support of xPool. (I will later walk this back, as Central Bank xCurrent ledgers is where the fiat IOUs should live)

There are two ways this could be set up. 1. Borrower issues fiat IOUs on XRPLedger, using the authorized accounts flag (this also prevents ledger bloat), and then only Ripple can receive the IOUs that are set up to account for the individualized loan terms; or 2. A third party, potentially a subsidiary of Ripple Inc or partnership, could issue IOUs on XRPLedger to account for a more common set of loan terms across multiple borrowers.

The first setup is the most simple. Say a loan is for $1000 USD, the borrower would set up an XRPLedger wallet, Ripple would probably fund it with enough XRP to do the setup transactions. Then Ripple would setup a Payment Channel with $1000 worth of XRP to the borrower’s wallet. Then Ripple would setup a new collections wallet on XRPLedger so the individualized loan cash flows dont get mixed up (clean accounting). Now the borrower can make the $1000 amount of XRP stored in the Payment Channel available to their users.

For Exchanges, when someone wants to buy XRP, the exchange would send Ripple a request for a XRP payment receipt, Ripple would send it, the Exchange would cash it in or Settle it, keep a spread themselves, and credit their user’s trading account.

For Remittance MSBs, when someone wants to send a payment cross boarder, the MSB will need to have pre setup multiple accounts. One for each jurisdiction or business unit (either on their own xCurrent ledger, or it could be easier on XRPLedger). Then they can bounce XRP between these accounts with payment transactions to move the value.

Alternatively if they did this through their own private xCurrent ledger they would only be able to tap their own liquidity provisions.

The other option would be to use xRapid via ILP, to tap into an Exchange’s Trader Liquidity. Then they would not have to use their own liquidity provisions, and eventually with deep enough trader provided liquidity, they may be able to pull back some or all of their float.

While being pretty easy to set up, this does not create a level playing field (multiple IOUs reflecting multiple loan terms). Nor is this decentralized, as Ripple Inc is the hub and all the borrowers are spokes. In addition to solving the management issues, we can also address the other issues, by using a third party issuer for the IOUs to standardize the loan terms across all borrowers.

The second setup

Maybe more likely… is a third party issuer could be used for issuing the fiatIOUs, and they make the IOUs only available to Exchanges and MSBs with a loan agreement (via authorized acct flag), then all the borrowers would share the same loan terms and FX rates to XRP.*demurrage

Now all we need, is to have an orderbook between these IOUs : XRP with deep enough liquidity. Which could be liquidity sourced from the interest payment cash flows, or the third party issuer could provide the liquidity since they are the counter party to the IOUs. If they did this, I imagine they would use a fixed Quality in/out, so both Ripple & the third party issuer could get a piece of the payment flows.

Using DepositAuth gives another layer of protection to anyone who is transacting directly on the XRPLedger. DepositAuth is a way to reject payments, even in XRP, from non-verified accounts enabling FIs to meet compliance requirements, and not get mixed up with unknown parties sending them value.

…As I noted at the top, there are 2 ways for loan payments to be made, Ripple can send a PayChan receipt to the borrower when they need more XRP to supply their users; or when the borrower needs to pay Ripple interest payments, which would be marketed-to-market at the Spot rate when due and then paid with XRP. (prior appreciation accrues to borrower)

There is one other concept of value flow to be aware of at play here. In the previous segment I mentioned Ripple having duel risk exposure goals for xPool. Risk exposure goals: 1. keep upside appreciation, 2. protect borrower from downside. For the downside check the previous segment.

The upside risk in this case is the appreciation of XRP, which is effectively an increase in Ripple Inc’s seignorage profits. Both of these two setups allow Ripple to accomplish both of these goals, because as XRP appreciates, Ripple will be less likely to need to send the borrower more XRP PayChan receipts, because the fiat value of the XRP they already have settled is enough, or because Ripple simply does not need to send as many XRP relative to fiat (meaning Ripple keeps the appreciation) to fulfill the borrower’s needs.

Either way, individualized Bank Issued IOUs on XRPLedger, or Third Party issued IOUs on XRPledger, would both enable Ripple Inc to denominate the loan arrangements in Fiat, all while accomplishing the Gateway role, in a way which would align with local regulatory lending laws, and achieve the duel risk goals I assume Ripple Inc would pursue.

Some remaining thoughts… Remember the “Banks are the custodians of value” comment I brought up at the top from Larsen? One of the reasons I think a third party issuer is more likely, than individualized IOUs is in part, because of the Custodian aspect.

These banks and exchanges and MSBs dont need to or want to be crypto experts and manage their own keys, etc. So, let a custodian take that risk, think of CoinBase and their soon to go live Institutional Custodian service.

The Big Picture.. When you think of a user going to a Remittance MSB, who is then going to be using xRapid to source liquidity from Exchange trading activity… this is exactly the same type of payment flow as xVia is intended to enable Banks, to offer their Corp Treasury users. I think the scaled up goal here is to enable Banks to offer Corp Treasury departments Just-In-Time (JIT) global liquidity, to fund the cross boarder liquidity needs of the Corp client.

Now as I explained here, Corp Treasury users can benefit from pulling back their own float, by directly holding XRP. However, if Banks can borrow enough XRP to service all their Corp xVia users… then banks can add a spread, and effectively offer their clients the savings of holding XRP directly; but do so without technically or legally having the Corp or the Bank directly touch XRP.

Each party, only has a fiat denominated loan. The bank has a loan from the third party IOU issuer in fiat; and the Corp Treasury only has a loan from the Bank. However the “loan” to Corp from the bank, would be settled by the bank debiting the Corp bank account immediately. Thereby Not exposing the Bank (or Corp) to FX or Leg risk, meaning the bank earns a spread that is a very low risk profit.

Ripple’s phase in strategy, is to increase the depth of liquidity on XRPLedger.

1. start with the little guys (remittance users),
2. then get the big guys (corp treasury users, xVia).

—

Those are the two setups to enable single ledger IOUs. Now lets look at how a pool of IOUs on Multiple Ledgers could work… ie RippleNet

This section will focus a lot on the importance of Pathfinding.

To explain this I will start with a single ledger example. Assuming a third party, like an EarthPort Inc, actually decided to issue IOUs in multiple fiats on XRPLedger. If this were the case, we would be looking at something similar to the original vision for XRPLedger.

One of the significant advantages that XRPLedger as a technology has over the Bitcoin technology, and a reason the Bitcoin technology is not well suited to being the core technology underpinning an IoV or RippleNet… is because it is eclipsed by XRPLedger’s ability to do Pathfinding across many IOU orderbooks, trustlines, and XRP.

Now, I will focus on reducing computational power usage (nothing to do with mining, just forget all about that), The computational power usage is in running the pathfinding algorithm that preforms the routing function.

The pathfinding algorithm is embedded in the core of Rippled, and therefore also exists on the XRPLedger, as well as on all paying Bank’s xCurrent ledgers.

The pathfinding algo, will calculate and identify the cheapest path a payment can take across many hops all within that single ledger.

At one point I thought the Pathfinding algo had a limit of seven hops in a payment path that it would look for and calculate, then it would pick the cheapest path to route the payment through. Back then I think it took 7 seconds for a ledger to close, in part, because the Pathfinding algo needed a few seconds to calculate all the paths and identify the cheapest path.

I’m guessing here, but I’d guess that David Schwartz and crew observed that rather than calculating all the possible paths, by simply using XRP as a bridge currency they could reduce all payment paths down to maximum of 3 hops (fiat A > XRP > fiat B). Auto-bridging via synthetic order books, makes XRP a bridge currency, and should reduce the computational power needed for the Pathfinding algo to find the best path.

In xRapid the, XRP > XRP leg, of the payment flow does not even need to run the pathfinding algo.

This is similar to how Bitcoin blockchain cant/dosen’t need to preform the routing or pathfinding function… which is absolutely required to enable an IoV, Bitcoin tech only supports a single unit of account.

Check the math section below to see the details on how this works within a single ledger. The math mostly focuses on articulating how Triangular arbitrage works, which is basically what I believe the pathfinding algo to be calculating (not sure how else it would work, but there are other network arbitrage algos that ISPs use).. and how that math works using FX ratios expressed as fractions, and being converted over into a value that can be expressed in Trustline Quality in/out, thus enabling the pathfinding algo to preform it’s function.

Now with all that said… back to RippleNet

1. How is RippleNet stitched together?
2. How can fiat IOUs find a path through multiple ledgers without a single centralized routing table?!!
3. How can pathfinding help if it can only calculate paths through on-ledger trustlines?

The simply answer to all these questions is, ILP + Payment Channels.

• Problem introduction: ILP necessarily abstracts away the pathfinding

In an ILP world, Payment Channels play the role that Trustlines play on-XRPLedger.

Payment Channels can only be used with XRP on the XRPLedger, and can only use the native token that would be on each bank’s xCurrent ledger. Now, I think in the first segment on PayChans, I have shown how Payment Channels can be used to create credit, aka trustline connections between ledgers.

Accounting for the value of this native token is easy on the XRPLedger, because XRP has a market price.

To make this doable on each bank’s xCurrent ledger, there is an old accounting concept we need to employ to make this work…called “Notional Value”

The notional amount (or notional principal amount or notional value) on a financial instrument is the nominal or face amount that is used to calculate payments made on that instrument. This amount generally does not change and is thus referred to as notional.

I’d imagine that each bank using xCurrent could easily assert that the native token on their own xCurrent ledger has a notional value pegged at $1 fiat, in whatever the jurisdiction is, in which the bank operates. This is important because it enables banks to make direct cross currency xCurrent ledger > xCurrent ledger transactions that include the FX pricing.

As an an example of notional value, SWIFT uses this idea here, with it’s “notional value” of a SWIFT share being $125/share.

Now that we have solved the issue regarding the value of the native token on a bank’s xCurrent ledger, that it should be pegged to $1 local fiat. We are free to deploy Payment Channels in a bidirectional way directly between banks using xCurrent.

Once we can use PayChan directly between xCurrent > xCurrent ledgers, we can begin to layer in the bank’s existing Vostro relationships (aka: the value other partner banks deposit as float with the xCurrent bank) by simply expressing the fee each partner bank wants (reflecting the terms in the N/V agreement) as the Quality in/out spread on the IOUs.

Additionally, given that the partner bank’s Vostro accounts would be denominated in the xCurrent bank’s local fiat (that is the whole point) all the IOUs on a given bank’s xCurrent ledger would be denominated in the same local currency code.

This would make pathfinding computationally easier, because the FX rate has been abstracted away from the pathfinding, into the send amount of the payment. The Quality in/out represents the fee due to the bank who floated the Nostro account’s value.

The big idea… Once you have a series of banks, each with their N/V terms expressed on each other’s xCurrent ledgers via Quality in/out… then finding the best combination of many xCurrent ledger paths to send a payment through, is effectively preforming distributed pathfinding across all relationships, in an automated way!!!

That may be where RippleNet’s development currently is (or maybe not, this may require new xPool functionality, as I’m about to explain) but xRapid will introduce XRP as an additional possible path for the payment. When the bank’s xCurrent ledger runs a pathfind process, where it will stack rank the cheapest paths (or most profitable paths)… if the XRP path ends up at the top of the stack.. either because the bank does not have to use their own liquidity, making the XRP path more profitable; or if they simply dont have liquidity on the destination ledger… then the payment will likely be routed through the XRPLedger.

It is unlikely that as you continue to add hops (ie: lengthen the payment path) through more private bank xCurrent ledgers existing N/V relationships that the end-to-end cost of the payment will be remain competitive with the XRP path, because each step in the path adds an additional spread.

If in the alternative case, the XRPLedger is not the cheapest, or most profitable path… then the payment can be automatically routed though a series of xCurrent bank ledgers.

With the Pathfinding algo on each xCurrent ledger finding the cheapest path available through the various IOUs that the bank’s xCurrent ledger has avaliable, due to the bank’s existing N/V deals, to find the cheapest path, along which to pass the value onto the next leg/ledger of the end-to-end payment path.

Here is where xPool may come into play to enable “Distributed Pathfinding”… One reason for ditching Escrow for ILP may be that xCurrent already does the messaging layer, where all the prices can be pinged for passing value across many ledgers. This is where xPool could live, in the messaging layer, receive the Quality in/out quote info and stack rank the total end-to-end cost of all possible payment paths using the existing N/V relationship of downstream xCurrent ledgers… and then the sum total all the Quality in/out fees for each hop along the entire payment’s path.

The xPool could use the same math Crowdfunding Loan platforms use just like Prosper the crowdfunding platform where Larson was previously Founder, when xPool is calculating the borrower’s interest rate (the sender’s interest rate fee in this case).

The weighted average method could be used, to look at all the possible paths end-to-end, and preform a minimization stack ranking.

This would enable the xPool service to be “smart”, and when it is beneficial, xPool could automatically split a payment into many paths (check the math example below, this is simple arithmetic) to achieve fully funding the payment across multiple paths at the cheapest cost to the Corp xVia sender.

Now we can achieve “Streaming Payments” broken into multi paths, and crossing multiple ledgers, with the paths being found via “Distributed Pathfinding”, which employs each xCurrent ledger along the path to identify the cheapest path through that ledger.. and then consolidating all those path petitions into a stack ranked weighted average by the xPool service. I think this is the holy grail.

That is it for now. Thanks for reading.

For conversation on this topic, click here.

The Math example…

How to multiply fractions is essentially the same math as how Quality in/out is expressed on a Trusline.

Pathfinding basically calculates multi-leg arbitrage (more than 3 legs) just like like Triangular Arbitrage, but honestly I haven't read an English version of the pathfinding algo embedded in Rippled.

Here is an attempt at describing the pathfinding process, and Here is some old documentation on Trustline Quality in/out. Here is where the next quote is from.

qualityIn — number — Optional Incoming balances on this trustline are valued at this ratio.

qualityOut — number — Optional Outgoing balances on this trustline are valued at this ratio.

…and here is the source (look on the left for “limit quality”) for the following example of how converting spreads & fees into a Trustline Quality in/out values works.

Consider the following example. If I am trying to send you 100 Chinese Yuan (Amount = 100 CNY) for 20 United States dollars (SendMax = 20 USD) or less, then the limit quality is 5. Imagine one trader is offering ¥95 for $15 (a ratio of about 6.3 CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of 2.5 CNY per USD). If I were to take both offers to send you 100 CNY, then it would cost me 17 USD, for an average quality of about 5.9.

So with the quality limit of the end-to-end path needing a quality of 5 or higher, the one path option with a quality of 2.5 does not meet the threshold, however when combined with the other legs in the payment path via weighted average (the process xPool could preform), the total payment’s weighted average of the path’s end-to-end Quality, is above the quality limit of 5.

• 1st leg costs $15 to buy ¥95 so this would be 95/15 = 6.33 Quality, or 15 in and 95 out
• 2nd leg costs $2 to buy the last ¥5, so this would be 5/2 = 2.5 Quality

To calculate the path’s weighted average Quality, like xPool would do, first xPool keeps the denominator expressed as the original sending currency, in this case $17 USD.

• $15/$17 or 88% of the payment got a quality above 5, of 6.33 quality
• $2/$17 or 12% of the payment got a quality below 5, of 2.5 quality

Second, to combine these paths into the weighted average xPool could simply multiply the quality by the percentage of the payment… (88%*6.33)+(12%*2.5)=(5.56+0.3)=5.9 end-to-end payment quality.

limitQuality — boolean — Optional Only take paths where all the conversions have an input:output ratio that is equal or better than the ratio of destination.amount:source.maxAmount.

A cheat code way to think about this, is the inflow is the denominator, while the outflow is the numerators. In the next step the outflow from the first step, becomes the denominator, while the outflow from the second step becomes the numerator in the next, until both are the same and the value has reached the destination. Just a mental trick to think through multi hop payment paths.