Abstract

Ripple is a financial services company that looks to facilitate global payments through blockchain-based technologies. Unlike most crypto-related projects, Ripple has carved out a niche by looking to integrate their products with legacy institutions, improving on their infrastructure rather than trying to displace them. The company is built around a novel trust-based consensus mechanism that allows the transmission of any arbitrary asset across its network. However, the system cannot guarantee delivery of the asset, it can only transfer cryptographically provable contracts, subjecting the transacting parties to counterparty risk. To address these dilemmas, the protocol created a native token, XRP, which provides full guarantees of on-chain settlement in a matter of seconds.

Problem/Solution

Systemic friction exists inside the global payments and remittance industries. Institutions can move money within their network seamlessly, but inter-ledger transactions pose a problem due to their complexity. Banks move money across ledgers via multiple correspondent accounts, which usually take days to settle, cannot guarantee finality, and requires substantial capital lockups. Due to endogenous fixed costs, transaction fees are traditionally high while transparency and competition are low.

Trust lines exist between banks which allow for such inter-ledger transactions. If a transfer needs to be made between Bank of America and Chase, and the two have an existing channel where they are willing to accept IOUs from one another, their outstanding balances only need to be settled periodically. If no line of credit exists between the two parties, the transaction must hop through various middlemen until it ultimately reaches the final beneficiary. This process is expensive and takes a significant amount of time.

Ripple looks to improve on this process by creating a unitary network that bridges siloed ledgers. The system routes a direct path between transacting parties, building off this practice of IOU relationships. Imagine Bob and Alice are two individuals who want to transact, but don’t trust one another to extend a line of credit. If both parties have a mutual connection with Steve, they can route the transaction through a lineage of trust. This works by Bob paying Steve, who in turn pays Alice. Bob has now indirectly paid Alice without ever needing to inherently trust her. If the relationships between parties are extremely isolated, we can keep introducing more intermediaries to form a lineage robust enough to facilitate payments.

By having these IOUs compartmentalized onto a single electronic network, Ripple can assist in settling inter-ledger payments with greater transparency, reduced fees, and shortened settlement intervals.

Product Suite

xCurrent:

xCurrent is Ripple’s blockbuster product, consisting of a settlement solution for banks and other financial institutions. xCurrent can support a variety of different assets and instruments. For example, if Bank A wants to pay Bank B with USD, but Bank B wants to be paid in EUR, the network will automatically source a liquidity route for each party to be paid in their respective currencies. xCurrent is conducted through Interledger (ILP), a completely independent protocol layer that uses hash time-lock contracts to facilitate trustless payments over ledger systems.

ILP is trustless by design and works with an escrow-like mechanism analogous to Bitcoin’s lightening network. Once a liquidity route is established, parties deposit the asset of interest to their correspondent by placing it in an escrow account. This sets off a chain reaction, where the correspondent deposits to an escrow account with their subsequent correspondent. This continues down the line until the ultimate beneficiary is reached.

Once the beneficiary sees the money waiting in escrow, they sign a cryptographic receipt acknowledging reception of the funds. Signature of this receipt catalyzes two reactions. First it allows the beneficiary to claim those funds out of the escrow and get paid. Second, that receipt allows the correspondent to claim the money sitting in escrow with their correspondent.

This form of atomic settlement ensures security across each leg of the channel. Correspondents carry just as many incentives as the transacting parties since they post their own collateral to facilitate movement of the funds. If the chain is broken by an intermediary, stakers have full guarantee of being refunded due to the escrow mechanisms.

Overall, xCurrent offers significant benefits compared to legacy financial systems. Payments take mere seconds to complete, while guaranteeing settlement by providing end-to-end visibility. This results in lower operating overhead, fewer risks, and decreased transaction costs.

xRapid:

xRapid is an emerging technology layer imbedded into the xCurrent network that allows sending and recipient parties to use the native XRP token to issue payments. Rather than sourcing liquidity routes through numerous correspondent payment providers, thereby incurring numerous transaction costs, participants can cut out the middle men and transmit funds to one another directly. xRapid transactions are conducted over the novel Ripple Protocol Consensus Algorithm, which we explore in later sections of this article.

Banks either hold XRP reserves on their balance sheets, or have dedicated liquidity lines facilitated through the xRapid layer. Originating banks convert fiat to XRP, transmit it over the Ripple medium to the Beneficiary bank, who then converts the XRP holdings back to fiat through their local liquidity provider. This process can achieve finality in a matter of seconds and eliminate a great deal of overhead/conversion fees associated with xCurrent.

xVia:

xVia is a standard interface solution for payments conducted across the X-series platforms. The system provides a compliance backed, friendly interface for initiating real time transactions over xCurrent or xRapid networks. The project itself is still under construction, with limited details on the explicit underpinnings of the technical architecture.

In the following sections, we explore the open-sourced Ripple protocol.

Characteristics

Accounts:

Like Ethereum, Ripple uses a configuration model where the ledger marks systematic changes to a specific state of the network. These changes are referred to as transactions, and these transactions alter consensus to the underlying account. Transactions can be a payment from one account to another, offers to trade, or alterations to existing trust lines and account settings. If the network has reached universal consensus of the ledger at time t, any new reflections of consensus at time t+1 can be accounted for via the transactions that occurred during the intermission period.

The bitcoin protocol tracks ownership of UTXO encumbrances to specific addresses. By focusing on a single address, users can determine the history of different UTXOs that have previously been encumbranced to that address, along with bitcoins that are currently being locked. Similarly, individuals can derive information by auditing an XRP account. Accounts on the Ripple network include an identifying base58 encoded address to receive payments, outstanding balance, activation information, and a unique element called the sequence number. The sequence begins at 1 when the account is activated, and tracks each subsequent transaction to the account moving forward.

Signature Algorithms:

Ripple uses elliptic curve based algorithms to generate underlying key pairs. By default, the protocol uses the same secp256k1 scheme found in Bitcoin. However, Ripple also offers a more efficient, Schnorr-based ed25519 algorithm for users to take advantage of. Account owners start by generating a master keypair from which transactions can be signed. The protocol offers also includes subset keypairs called regular keys which can be permissioned with signature properties. Keeping credentialed regular keys on a hot connection proposes an ideal mechanism to maintain security of the underlying master pair. If the integrity of the regular keys is compromised, permissions can be revoked and assigned to a fresh set.

Block Construction:

Blocks do not exist in the Ripple protocol. Rather, they are replaced by ledger versions. Nodes receive incoming transactions and relay them to connected peers. After a specified time interval (currently 2 seconds), nodes gather non-validated transactions sitting in memory, compiling them into an aggregated unit designated as a candidate set. Nodes pass along their individually compiled candidate sets and those from peers, creating an individual perception of the state of the network. This is referred to as the open ledger. Through the Ripple consensus process, differences between nodes’ open ledgers begin to converge, until they reach a canonical agreement on what transactions will ultimately be appended to the ledger. This instance becomes the last closed ledger, and represents the most current state of the network ratified by the consensus process.

Like accounts, the ledger archives information about the state of its contents. Some of this content includes:

Account configuration settings

Trust lines that exist between accounts

Account balances

Transactions specific to that ledger version

Timestamp

Most importantly, each ledger is assigned a unique sequence number, that is always n+1 its parent. By ordering Ledger versions in this manner, a secure hash chain can be formed. Transaction sets advance the ledger and provide a full snapshot of the network at any interval. As a result, prior states of the ledger are not a necessary component and can theoretically be pruned from disk space (though most choose to maintain the entire history). This provides a significant advantage with respect to block synchronization, where bootstrapping nodes can engage in the validation process simply by obtaining a timestamp from the last closed ledger. Once the current sequence number can be extracted, the user only has to follow the block headers to the genesis point. Contrast this to UTXO-based protocols like Bitcoin, where each full node must synch a copy of every transaction in blockchain to compile an authenticated vision of UTXO ownership.

UNLs:

When a new server configures to the Ripple network, they must bootstrap to peers in order to determine the sequence number of the current ledger. Once this is accomplished, they can begin verifying integrity of the chain by trailing through the hash tree, iterating through the block headers and verifying alterations to accounts produced through transactions. Doing all this requires the node to compile a unique node list (UNL) of peers they can trust. Not only will this node reach out to its trusted validators to bootstrap their client, they will engage with these peers going forward during the Consensus algorithm to vote on new alterations to the ledger. Because both of these interactions rely on mutual trust between the participants, the node with the largest amount of UNL connections has the greatest influence inside the network.

Validators synching to the network for the first time are often isolated. Peer nodes are pseudonymous by nature, making it hard to establish these trust lines that are so critical to the integrity of the Consensus process. Furthermore, the network exerts no incentive structures for validators to act altruistically, making Sybil attacks a relatively cheap endeavor. The Ripple protocol overcomes this dilemma by establishing a default UNL of trusted validator sets run by Ripple Labs themselves. It is important to note that the protocol does not require the user to interact with the default UNL, and actually encourages those with the resources to configure a custom UNL. However, it is probable that the majority of nodes choose to default to the pre-compiled list, not only due to their exclusivity from the rest of the network, but the fact that these Ripple validator sets are well provisioned. This means the user can request large “fetch packs”, submitting far fewer queries when synching up, thereby expediting the process. While Ripple has worked to increase the number of validator sets and simultaneously pledged to democratize the network by removing themselves as validators in the future, the company currently operates the largest number nodes. Not only do they have the largest number of nodes, but these nodes are the most interconnected, meaning they have the highest degree of influence over the network.

Byzantine Generals Problem

Every distrusted payment system must include some form of Byzantine fault tolerance to prevent against the doublespend problem. Throughout most of history, doublespends have been a trivial matter, since physical assets cannot be permissioned twice. As money evolved into digital form, this problem became much greater, as the code comprising the asset is easily duplicable. The Bitcoin protocol achieved notable recognition by proposing the first known solution to this barrier where no centralized fail point exists. The consensus mechanism is backboned by the Proof of Work algorithm where miners contribute computational hashpower to earn the rights to propose a block. However, the protocol includes a mathematical challenge for each prospective candidate to solve, in order to earn the right to establish a canonical vision. When a claimant proposes a solution, peers can mathematically verify its integrity ensuring the required work was fulfilled by the issuer. Different forms of consensus mechanisms emerged over time, some evolving away from the concept of a computational race altogether to minimize latency, energy resources, and other plaguing challenges associated with this industry standard. These novel consensus systems still face the underlying Byzantine Generals Problem, requiring conception of a unique solution. Ripple has proposed the Ripple Protocol Consensus Algorithm (RPCA) as a circumvention tool to route around these described challenges. The architecture relies on small, independent networks where trust between altruistic actors serves as the consensus mechanism. These independent networks are then cross-referenced with one another, ultimately converging on a universal status of the ledger in a mathematically provable manner, even amidst segments of independent networks behaving nefariously.

Consensus Process

The RCPA process works to ultimately advance the ledger sequence. The process consists of three phases: deliberation, consensus and validation:

Deliberation:

Clients begin by the process by broadcasting a Ripple transaction to the network, where it is received by two types of nodes: validating and tracking. These nodes subsequently flood the network by transmitting it to their peers, who pass it along to their connections. Soon, every connected party in the network has received notice of the broadcast. If the node is a validating node, it initiates the consensus process. The validator checks the authenticity of the message by verifying that the signature data matches the corresponding public key. If it does, the validator adds that transaction to a list L that is stored locally. Simultaneously, the node appends this transaction to its current candidate set. After doing so, the node will check the transaction for correctness. It does this by comparing the logs from sequence t-1 and ensuring alterations to the account have been accounted for. If the transaction utilizes the XRP medium, this means ensuring the spender has necessary funds available in their account. If done with a non-native asset, the validator ensures that a trust line exists between the two parties, and that transaction meet the specified requirements of that relationship.

Consensus:

The validator keeps performing this function of analyzing incoming transactions and appending them to the candidate set. At the conclusion of each phase (every 2 seconds), the validator packages the candidate set into a singular unit, hashing the transactions into a tree and signing the corresponding merkel root. This merkel root, called the proposal, is then broadcast to the peers on the validator’s UNL. When receiving a new proposal, peers ensure its integrity first by checking the identity of the sender against their UNL. If they are not a member, the proposal is immediately discarded. If they are a member, the validator compares the transactions in the bundle against those stored locally in their set L. For each transaction the node iterates through in their peers’ proposal, if the transaction appears inside their local L, they add a vote to a secondary local list V. Nodes continue swapping proposal bundles until they have cross referenced every member on the UNL. After parsing the data, they take all transactions from V that appeared in at least 50% of their peer’s proposals, discarding those that didn’t.

Validation:

Nodes repackage these 50%+ “winners” into a new proposal and submit a hashed version to the UNL for a second iteration round, repeating the cross referencing process. This cycle of new proposals continues in 10% increments until the UNL network hits quorum, the parameter which specifies the minimum number of agreeing nodes in the UNL in order to validate the ledger, currently configured at 80%. Once this interval is achieved, nodes recognize the version hash as the last closed ledger, and begin working on appending a new ledger version n+1.

Consensus is only implemented to solve the double spend problem. Transaction sequencing is a deterministic function, since validators’ only role is to aggregate transactions on a time basis. This is not the case for proof-of-work based protocols, where miners play a hands on role in determining which transactions will be admitted into each block.

Emission:

Ripple does not have a distribution method natively inscribed into the protocol. Rather, all XRP were pre-mined upon creation of the token in 2013 and allocated to entities or persons within the organization. Below is a summary of the provisioning terms:

100B XRP tokens were created upon launch

80B XRP were allocated to Ripple Labs

9.5B XRP to Founder Jeb McCaleb

9.5B XRP to Co-Founder Chris Larsen

1B XRP to Co-Founder Arthur Britto

Concern over Ripple’s ability to manipulate XRP markets increased as market liquidity began to emerge. Investors worried that an arbitrary decision by the company to dump a considerable amount of holdings would devastate XRP price. As we touch on in later sections, this argument holds little rational sense considering that XRP holdings account for more than 98% of the company’s assets. For transparency stake, Ripple decided to lock up 55 billion XRP into escrow smart contracts with provisioned terms. At the beginning of each month, the escrow releases 1B XRP into treasury accounts to finance operations. There are no stipulations that these XRP must be used by the firm. Any excess XRP is refunded into a new escrow contract that is appended at n+55 months. For example, if 500MM XRP remain unused at month 1, these 500MM tokens are locked up into a subsequent escrow contract which become available for use at month 56.

Network Upgrades

Rippled is the official reference client for the Ripple Protocol, written in C++ and actively maintained by Ripple Corporation full time developers. While the code is open sourced, contributors are limited to employees of the firm, meaning the company has effective control over protocol implementations. This has tradeoffs in both directions. It allows system continuity and effective governance to the platform, reducing friction associated with conflicting ideology that tends to plague progress. However, it brings challenges in the face of forced network upgrades, reducing sovereignty at the individual level.

Bitcoin strives to implement network updates that are backward compatible, meaning user software updates are fully functional with underlying consensus rules. These updates are referred to as soft forks, which are non-contentious implementations. Backwards compatibility allows the user to opt-in to new features on a consensual basis; individuals are fully capable of rejecting the upgrades and maintaining legacy software without interruption, even if the overwhelming majority of the network has chosen to implement the new features. Not only does this respect individual sovereignty, these procedures are also considered less risky. Some nodes may not receive message of the new consensus rules. If the network requires all servers to upgrade simultaneously, there is a high probability some will get pushed out.

Backwards-incompatible implementations, often referred to as hard forks, requires changes to the consensus protocol rules rather than the user software that interfaces them. Users that continue to operate under the old parameters are rejected by those running the new (and vice versa). This creates a difficult situation where a minority of participants could be pushed out of the network if a majority upgrades, or a worse, a fork emerges where the network fragments into two separate lineages. This detracts from both user sovereignty and network security.

Improvements to Ripple frequently require changing the consensus-critical codebase rather than user software. If individuals fail to upgrade, they run the risk of operating outside of Consensus parameters and being removed by their UNL peers. Network hard forks tend to be less of a risk for protocols with fewer node operators and a smaller user base like XRP has. This is because the majority of the participants tend to exhibit similar visions for the network. That being said, as the system begins to expand, operating under these parameters does come at a tradeoff to sovereignty. Ripple Corporation can implement new features with or without community consensus. Node operators that disagree with the implementations could refuse to upgrade, but because Ripple’s servers are connected to so many UNL’s due to default configuration, they would most likely be pruned from the network very quickly.

Challenges

UNL Trust Model:

XRP critics tend to vocalize their discontent with the Ripple Consensus process, stating that it inherently contradicts the decentralized ethos. Criticism of the process algorithm can usually be summarized in two regards: a network that relies on altruism between participants revokes guarantees of a decentralized system, and Ripple’s default configuration to point bootstrapping nodes towards company-run servers ultimately grants them permissioned advantages over other nodes in the network, thereby revoking decentralization.

Critics outline some fair points, and the Ripple company does face inherent dilemmas due to the manner in which the Consensus model is constructed. As official documentation on the website states, nodes inherently rely on peers inside its UNL to engage in the consensus process. Reliance on these validators involves allocating a level of trust in each party to perform their validation tasks honestly:

“Chosen validators represent a subset of the network which, when taken collectively, is “trusted” not to collude in an attempt to defraud the node evaluating the proposals. This definition of “trust” does not require that each individual chosen validator is trusted. Rather, validators are chosen based on the expectation they will not collude in a coordinated effort to falsify data relayed to the network.”

As interaction between UNLs starts to converge at higher levels of the consensus process, the structure starts providing provable security guarantees. However, this doesn’t necessarily solve any of the described challenges, as potential “pollution” occurs at the ground level, compromising the integrity of anything that follows.

Consensus models with some form of security validation provide an inherently greater level of safety than a trust-based model, because they configure financial incentives that induce the actor to purse altruism out of rationale self-interests. This occurs because these protocols punish individuals that attempt to operate outside of the defined parameters. In Proof of Stake, this means revoking the validator’s deposit. In Proof of Work, this involves burning a tremendous amount of energy, hardware and bandwidth the miner can never reclaim. The incentive structures create game theory scenarios where the marginal cost of a network attack are much higher than the economic benefit that they could potentially gain.

Placing blind faith in an entity to perform their role in an honest fashion seems to illustrate a reversion to trust-based models decentralized systems seek to pivot away from. Critics argue that nodes inside a UNL can never validate the ledger independently, because the consensus process ultimately converges on an upper bound quorum threshold. Once that quorum is reached, opponent’s vision is deemed meaningless. Unlike in bitcoin, there is simply no guarantee of security on an independent basis. This is because the UNL proposals are ratified on the basis of majority-rule. If an overwhelming number of servers in the UNL are nefarious, an honest participant has no hedging mechanism against bad behavior and ultimately will be overruled. Even worse, the honest participant is subjected to the negative externalities of the group’s conduct. They are essentially forced to sign off on the nefarious proposal as a member of that UNL, even if they personally refuse to validate incoming proposals from their peers. In bitcoin, nodes work on a completely independent basis aggregating UTXO ownership and relaying transactions according to consensus rules. This means they have full have full jurisdiction over what they choose (or don’t choose) to relay across the network, and are not subjected to the actions of others.

UNL Centralization:

Contrary to popular belief, every distributed system relies on some degree of a majority behaving honestly. In bitcoin for example, we operate under the notion that 51% of the hashpower acts in accordance with the protocol rules. However, it is important to note how incentive structures in these networks are constructed. In the long run, participants will always act according to rational self-interest. We cannot assume inherent altruism. It is possible to predict a majority of honest actors when incentives reward participants for doing good, but if the payoffs for operating against the consensus protocols are high, expect a system of nefarious conduct.

The Consensus process can work efficiently, as long as the participants act altruistically. As mentioned in previous sections, default UNL configuration points bootstrap nodes to servers operated by Ripple themselves. Nodes can safely allocate trust in these peers since the Ripple Company has a high incentive to see the network operate functionally. Undoubtedly though, this configuration comes at a tradeoff to decentralization. Even Ripple themselves has articulated the need to improve in this regard:

“Decentralization of XRP Ledger is a process that started right at its inception and has been ongoing since. We intentionally haven’t rushed the process and have been making continuous progress all along. To meet the growing demands of our customers, we need to diversify the validator ecosystem to further increase resiliency and robustness.”

XRP critics are quick to point fingers at the degrees of centralization exhibited in the Ripple network, but fail to recognize that decentralization is an extensive and ongoing process. In fact, the majority of distributed systems we see today are centralized to some degree. No system is immediately endowed with decentralization, but accrues it after years of expanding its network. Every new protocol is configured with training wheel support as its infrastructure builds out. Ultimately, subsidiaries hope to remove intervention and allow the system to operate on its own.

Given current outlooks, questions still remain whether this will prove functional for the Ripple protocol, based off the alignment of incentives and the way the protocol is inherently constructed. While the Consensus process relies on trusted behavior between UNL participants, critics argue that the system lacks inherent incentive structures for a rationally motivated participant to behave accordingly. If the Ripple Corporation relinquishes UNL support prematurely, it opens up the door for a wave of Sybil attacks. It is relatively inexpensive to operate a node, validators contribute directly to progressing the ledger, and nodes have huge financial incentives if they can disrupt the ledger through double-spends. Furthermore, the protocol exhibits a “nothing at stake” problem where nodes are not reprimanded for attempting to push faulty transactions through the system.

UNLs have the ability to prune lagging nodes or nodes that exhibit nefarious behavior. This feature is effective under stable conditions when a minority group is acting to disrupt the consensus process. However, it also has the ability to further problems under chaotic situations. If Ripple validators were removed from the system (ie a governmental shutdown, internal corruption etc) and a large scale Sybil attack was simultaneously launched, the nefarious nodes could theoretically gain significant influence over fragmented UNLs. This collusion could be used to push out honest nodes, creating a furthered downward spiral.

Node Incentives:

There is little rational incentive for the average individual to run an XRP validating node. Some argue that this is the same case for bitcoin, but that is not necessarily true. Operating a full node is the only way to guarantee full security and privacy in the bitcoin network. Having a full sequence of transactional history is the only way to ensure authentic compilation of UTXO ownership, using an SPV client simply outsources this task to someone else. Running a ripple node does not inherently guarantee that same layer of sovereignty, as a minority group inside a UNL could be overruled by a majority of bad actors. Furthermore, unless an individual node has an extensive layer of trust with other servers, it is highly doubtful any peer servers would configure their UNL with that individual. Thus, adding more nodes doesn’t necessarily help contribute to the robustness of the ripple network. The system needs corporate/institutional partners to operate servers for people to feel confident trusting that node. However, one could argue that large financial institutions will be incentivized not to run an XRP validating node under a fully distributed RCPA model, due to potential legal recourse that could ensue. Imagine the PR backlash a bank would receive if it came out that one of its UNL peers was a darknet market, and the bank themselves played a direct role relaying drug and money laundering related transactions. Operating an XRP validating server means operating under a system that is permissionless and filled with unknown participants. Given the stringent KYC/AML banks and financial institutions face, it is highly unlikely many would want to participate in the process given the risk of not knowing the identities of other participants in the ecosystem.

This creates a chicken and the egg problem for the XRP network. In summary, the consensus model inherently relies on trust between UNL participants. It is hard to accumulate trust when dealing with anonymous servers. Most individuals will default to a Ripple Corp UNL due to these described risks. This creates centralization around Ripple validating nodes and an easy shutdown point for a state sponsored authority. Ripple can try to hedge this risk by enticing its X-suite clients to run servers, but many of the companies will not want to engage due to potential legal challenges that could ensue. Even if they find participants, these companies would still be quite limited and easily censorable. Ripple cannot afford to leave the validation process without stable infrastructure in place, lest the network becomes heavily disrupted by low-cost Sybil attacks.

XRP Token Analysis

Debate whether or not XRP meets the definition of a security has long plagued the project, especially as the price of the token has ballooned over the past 18 months. Some argue that it fits the criteria outlined in the Howey Test, while others disagree. I do not intend to digress into that argument, and will assume current legal status of XRP holds and token is not classified as a security.

Ripple Corporation and the XRP token are two entirely distinct entities. Ripple Corporation generates revenue on fees they charge their enterprise clients for using X-suite products, along with sales of company owned XRP in treasury. Ripple (the company) is a San Francisco based C corporation that has raised over $93.6MM of venture capital funding. As such, the firm’s fiduciary responsibility is limited to that of its shareholders. Although there is a strong correlation between XRP and Ripple due to their large allocation of tokens, autonomy over the consensus protocols/user software, and executive board that consists of 2/3 original founders, Ripple believes that XRP network is a completely independent system outside the jurisdiction of the company. Similarly, Ripple maintains that the company was gifted 80B XRP by the founders, rather than the company creating the protocol and allocating tokens internally. This viewpoint illustrates that Ripple has no fiduciary duties to XRP holders. While the company would love to see all stakeholders in the ecosystem accumulate wealth, their legal obligations of returning value are confined only to Ripple Corp investors.

While this may not come across as striking, it is an extremely important concept to consider when assessing XRP token value. When investors buy stock in a company, they are obtaining a percentage of equity in exchange for front running capital. This capital helps the firm finance operations and expand their business model, ultimately to produce higher earnings. Investors hope that the management teams can use this fresh capital to deliver on promises. If the business does become more profitable as a result of this investment, this capital will be returned in the form of appreciated equity, dividends, or both. An investor could then turn around and trade their equity on a public market for cash value. Ideally, the price this equity fetches is [significantly] higher than their original investment.

What’s important to understand in this scenario is this capital is not free money for the corporation. Equity shares are a way to determine allocation of cash flows associated with that company’s business operations. Each time a company takes in money from an investor, they are swapping present capital for future cash flows. These claims on future cash flows are represented by stock ownership, and scale linearly with the growth of that company’s business. If the company’s profits grow 10x over the course of a few years, obligations to shareholders (in commitments of USD) have subsequently expanded 10x as well.

By treating the 80B XRP as a gift, Ripple accrues additional assets on its balance sheet without having to subsequently dilute equity. Ripple has accrued the monetary benefits of the XRP token while simultaneously pushing fiduciary obligations onto another party. This party is a decentralized piece of software that can’t be regulated by a governing body. Considering that Ripple owns 60.85B XRP, this amounts to a staggering $51.71B of assets to finance current business projects. This means that at current market prices, capital accumulated from shareholders whom Ripple has fiduciary obligations amounts to a mere 18 basis points. The remaining 99.82% of the company’s assets were essentially granted for free.

Critics argue that the company plays both sides of the line, crossing over whenever it is advantageous to do so. Ripple maintains that XRP is not a security and the network operates outside the jurisdiction of the company. But opponents feel like Ripple seriously blurs the lines when marketing X-series products and their correlation to the XRP token. They feel the company not only fails to educate XRP investors that token ownership does not mean a slice of the pie from X-series business operations, but that the company actually goes out of their way to imply a false narrative. Company press releases consistently highlight XRP liquidity volumes, proceeds from sale of treasury XRP, and overall price appreciation of the XRP token. Few details are given whether these volumes are a result of retail adoption through exchanges compared to enterprise use cases, revenues streams accumulated through core X-series products, and deal transparency surrounding new enterprise clients/liquidity providers.

The Ripple business model has taken a unique approach by bootstrapping XRP speculators to their business operations. The company is front running capital, most of which is accumulated through retail markets, in order to build out a network that can match the daunting liquidity and network effects necessary to facilitate global payments at an enterprise level. XRP investors are happy to put down money, believing the company has well positioned itself to build out this infrastructure, first through onboarding customers to xCurrent products then transitioning them over to xRapid layers once they recognize the improved cost savings, security and settlement times. In doing so, institutions will be incentivized to hoard XRP reserves on their balance sheets, since they will be conducting business on them so frequently. If this occurs, a huge rebalancing of capital will transition away from fiat currencies into XRP, causing the price to greatly appreciate in value given the scarcity model of the token.

Other proponents have an alternative narrative for a bullish unfolding. They see XRP as the chosen one engineered to match the current state of regulatory affairs. The cypherpunk dream of a fully decentralized monetary system is simply too radical for politicians and positioned incumbents to ever allow through the gate, regardless of how efficient their new technology proves to be. A more centralized blockchain that assists, not challenges, current status-quo while simultaneously increasing transparency and control for statist intervention seems much more realistic. If Ripple does meet this standard, any bank that voluntarily revokes a huge chunk of its revenue models however are going to demand an arm and a leg in reverse compensation. Fortunately, due to the XRP pre-mine model and Ripple’s gift allocation, they can construct incentives packages and re-distribute these tokens to potential partners on a subjective basis. If the company can attract even a small network of big players, the smaller ones will quickly follow.

Critics point back to some major flaws and/or assumptions that exist under these hypotheses. For xRapid to gain even minor support, a mountain of liquidity must exist for these banks to pull from. Ripple has chosen to facilitate this by marketing XRP through exchanges at the retail sector. However, this allocates tokens into the hands of many uneducated speculators who often trade off emotional impulse or trend analysis. Without XRP being tied to Ripple Company’s cash producing assets, an intrinsic value is impossible to derive, leading to further volatility. This creates a liquidity trap where the sheer price fluctuations make it impossible for any rational institution to hold XRP on their balance sheets. Imagine a bank executive trying to explain to a board of shareholders how company assets dropped 75% in the past quarter due to a pullback in the crypto markets. Far more likely is a system of designated liquidity providers acting as ramps where institutions source XRP and transmit payments in real time. Recipient parties then immediately sell back that XRP for fiat to correspondent liquidity providers. The problem with this scenario is XRPs near-instantaneous settlement speed leads to a system of exponentially increasing velocity. One would expect the price of a token to increase linearly with usage of the network. However, assets with unbounded velocity will struggle to maintain long-term price appreciation unless a hoarding incentive/ burn mechanism exists.Opponents believe the system lacks such features, making current XRP prices are hard to justify, considering 60% of the inflation supply has yet to be injected into the ecosystem.

Furthermore, this does nothing to address the volatility dilemma, it merely transfers the risk onto the liquidity providers. If banks aren’t willing to subject themselves to volatility, why would we consider anything different for liquidity providers?

This is where Ripple’s war chest comes into play. The company can offer compelling incentive packages and loans to providers willing to facilitate liquidity channels the business depends so heavily upon. Like most banks, the liquidity providers won’t purchase unless they can derive a high conviction of profitability in doing so. This means Ripple will have to heavily subsidize the XRP sold to these partners to ensure safety on their investment. If Ripple sets a precedent of mouthwatering deals for small players, these incentives will need to scale linearly as they approach bigger targets. The problem with these subsidies is that they require a continual influx of retail money to offset the costs of accruing new enterprise clients, until the flood of capital runs out. Paradoxically, this could lead to a situation where retail investors, many of whom are looking to disrupt the incumbent financial institutions, voluntarily contribute money to a project that hands over free money to the same financial institutions originally thought to be displaced.

Conclusion

Ripple Corporation exhibits many promising products that will undoubtedly penetrate the global payments ecosystem for future years to come. The company has positioned itself as a leader in blockchain sphere by taking a unique approach, working with and improving legacy institutions rather than trying to displace them. Some proponents believe that the system’s native token XRP will appreciate in value by becoming a dominant global reserve currency, due to superior advantages in efficiencies and cost savings it will provide to customers. Critics argue such hypotheses involve many radical assumptions which are unlikely to align, given economic factors and institutional game theory.

Disclaimer: The author does not hold a position, long or short, in XRP.

Follow me on twitter for more Crypto insight!

Special thanks to Derek Hsue and Pietro Moran for feedback on this piece.