The Resurgence of Ripple

Ripple’s native coin XRP, has resurged from relative obscurity to become the third-largest cryptocurrency by market capitalization, overtaking prominent contenders like Solana.

This renewed interest in Ripple is driven by several factors. Recently, XRP, the native cryptocurrency of the Ripple ecosystem, gained significant momentum after Ripple Lab's partial legal victory against the SEC in 2023, where the federal judge determined that the sale of XRP strictly to retail buyers would not be considered an unregistered security. More recently, the SEC has taken the first step to appeal this decision, filling an opening brief on Jan 15, 2025. However, upon reading the contents of this brief, the market deemed the arguments as weak and with no substantial new evidence from the initial case. Hence, XRP has rallied even further, reaching highs last seen in 2018. There is additional speculation that the case will be dismissed by the SEC following the resignation of chair Gary Gensler. The current leading nomination to replace him is Paul Atkins, former SEC commissioner from 2002 to 2008, who is known for having a more crypto friendly stance.

Adding to this, Ripple Labs, the parent company behind XRP, has expanded its offerings, introducing a new stablecoin, RLUSD, built on the XRP Ledger (XRPL). This development highlights the utility of Ripple’s blockchain and its ecosystem, which is designed to streamline cross-border payments and allow developers to build custom protocols, offering real-time settlements and lower costs.

This report delves into Ripple’s utility, distinguishing between Ripple’s native coin XRP, Ripple’s global payment system RippleNet, and the blockchain they are both built on, the XRP Ledger (XRPL). We also deep dive on the mechanics of the XRP Ledger and the additional utility it provides for businesses. With its ability to challenge traditional payment systems like SWIFT, Ripple is once again positioned as a pivotal player in the financial technology space.

RippleNet, a payment system focussed on cross-border transactions, offers transaction fees starting at just 0.00001 XRP, settlement time of 3-5 seconds and a throughput of 1,500 transactions per second. It is primarily targeted at large scale businesses looking to optimise their transactions through cheaper and faster processing.  XRP, the native cryptocurrency of the XRPL, has a pre-mined supply capped at 100 billion tokens, in contrast to Bitcoin’s 21 million supply limit and this is why small movements in the underlying token’s price translate to significant gains for the total market cap.

What is Ripple?

RippleNet

Ripple’s global payment system RippleNet, is designed to address the inefficiencies of traditional systems like SWIFT, which are often slow, costly, and reliant on intermediary currencies, usually USD. Built on Ripple’s blockchain, the XRP Ledger (XRPL), RippleNet offers a faster and more cost-effective solution where XRP can be used as a bridge currency and the transactions are processed on chain. The value proposition of Ripple's native token, XRP, partly lies in this use case of cross-border payments.

By leveraging XRP, users bypass the need for timely and sometimes complex currency conversions. For instance, converting currency A to currency B typically involves two trades - first to USD, then to the target currency. XRP replaces USD as the intermediary currency. With RippleNet’s technology, the conversions are done automatically allowing both parties to send and receive the money in their respective local currency without the need to manually execute the conversions. This is known as autobridging and a synthetic order book is created by consolidating the two trades as one.

With an approximate transaction fee of 0.00001 XRP (approximately $0.000033 as of Jan 16, 2025) per a transaction, RippleNet significantly outpaces traditional systems, where fees on average can range from $0.50 to $50 per transaction depending on transaction size. For businesses like banks, which incur significant operational costs to maintain consistent cross-border payments, this solution dramatically reduces expenses.

Automating processes through the blockchain minimises the need for large operational teams and eliminates the costs associated with hiring staff for manual tasks. Additionally, RippleNet removes the necessity for high-margin pre-funded accounts in destination countries, further cutting overhead. Given the average settlement times ranging between three to five seconds for transactions using XRP, a large portion of FX and timing risk is eliminated in the execution. This compares to processing times of up to 48 hours in traditional finance transactions.

RippleNet also offers direct currency transfers for businesses who opt out of using XRP as a bridge currency but still want to optimise cross currency transfers. These direct transfer options can be selected in the order book which works essentially as a decentralized exchange (DEX) matching buyer and seller together directly. This use of RippleNet’s custom-built path finder helps to identify the most cost-effective route between two currencies, via the system. For example this could include an over the counter (OTC) approach or by incorporating XRP as the intermediary currency. This allows for businesses who have to comply with stricter regulatory policies to still streamline their existing currency transfers while bypassing the use of the cryptocurrency. 

The XRP Ledger

The XRP Ledger (XRPL) is Ripple's blockchain. With each transaction on the chain, a transaction fee (also known as gas fee in other blockchains) is charged which approximates to 0.00001 XRP. This total gas fee is burnt and constitutes the XRP burn rate.

Each data block in the XRPL, referred to as a "ledger version", is built on top of data outlined in previous blocks. The blockchain progresses in rounds and is sequentially numbered with a ledger index for record keeping. Ledger versions (blocks) contain an encapsulation of the entire current state of the chain, including a record of transactions and a unique block identifier, translated to a single generated hash key. Given this total encapsulation of chain data within each block, new validators joining the network are able to understand the present state immediately from the last block received eliminating the need to retrieve the full XRPL history.

This ability or need to download the chain's history differs between chains impacting how quickly a validator can join or leave the system. For example, Bitcoin enforces the full chain history to be downloaded so a validator is able to verify the state independently and the network remains trustless. In comparison, Ethereum also requires a full chain history download, however there are workarounds in place that offer a streamlined syncing and consolidation of the history. 

To create the blockchain, a decentralised group of servers run XRPL’s specific protocol “Rippled” essentially creating a single network of validators. These individual validators work together to reach consensus on the final ledger versions through XRPL’s custom consensus mechanism - the Ripple Protocol Consensus Algorithm (RPCA). The workings of the blockchain and the consensus mechanism are explained in more detail below. Simplified, the RPCA is based on the trust of its validators and consensus is achieved when 80% of these trusted validators agree that the transactions are valid and they agree on the ordering.

Blocks published on the XRPL are publicly accessible and stored on specific servers configured as "full-history" servers. These can be accessed via connection to a full history XRPL node. Similar to major blockchains like Bitcoin and Ethereum, the XRPL blockchain serves as a transparent and immutable record of all transactions and their outcomes. The full history is stored as a static ledger and trust is placed within the full history nodes to keep the history accurate and unchanged. It also stands that since blocks are built upon each other, the changing of a historical block would require the rewriting of all future blocks downstream requiring significant computational power and a colluding of all full history XRPL nodes to rewrite their records. Additionally, since each working validator has a local record of the most recent state of the blockchain, and no need to refer to the full history nodes, at this point, the protocol will progress using this local history. Therefore, a historical rewrite of the blocks will have no impact on the future state of the chain, essentially deeming a rewrite useless. 

XRPL was created as an open-source blockchain and provides a platform for companies to build their own custom payment and cross-border settlements solutions on. For example, applications include automated payments systems and the creation of new digital tokens. XRPL allows the integration of features including smart contracts and multi-signature wallet capabilities. Ripple's own stablecoin, RLUSD is an example of a standalone product built on the XRP Ledger (XRPL), separate to RippleNet and unrelated to price movements in XRP.

The Deep Dive 

The Consensus Algorithm (RPCA) 

The XRP Ledger (XRPL) operates using a unique consensus protocol, the Ripple Consensus Protocol Algorithm (RCPA). This is distinct from the Proof of Work (PoW) used by Bitcoin and Proof of Stake (PoS) utilised by Ethereum. Unlike traditional decentralised systems, it does not rely on mining or staking but on a trusted validator assumption, explained further in the next section. That is the assumption that each validator acts independently and does not collude so the network remains decentralised.

To fulfil the decentralised assumption, the XRPL is hosted across a distributed network of servers running the XRPL protocol. Each server maintains a local copy of the ledger and can submit transactions to the network. However, not every server acts as a validator – an additional opt-in is necessary to participate in the consensus mechanism. 

The primary objective of the XRP Ledger Consensus Protocol is to produce new ledgers and ensure that all participants agree on the latest state of the ledger before it is published. The transaction lifecycle from user to published ledger is explained in more detail below. Overall, the validators’ job is to check validity, sequence and ensure agreement on the resulting outcomes of the set of submitted transactions within that ledger version. This constitutes consensus and the ledger version is deemed complete and is publicly published. Validators then move on to the next round repeating the same process with new transactions, essentially building the blockchain.

The protocol sets out to remain resilient, tolerating the entering and leaving of validators in the system, and ensuring the ledger can progress in the presence of a fixed percentage of byzantine validators (who diverge from the protocol). A key limiting factor is XRPLs network is that, in the case where too many validators unexpectedly go offline or consensus cannot be reached, implying a number of validators straying away from the system, the network halts and the chain stops progressing. This is given that the XRPL consensus model favours chain integrity over progression. The network will resume following restart of the offline nodes and/or validators resuming the normal protocol, to allow for an 80% agreement on proposed ledger versions. 

This is a key design feature which sets it apart from the more well known blockchains. Ripple’s approach is designed with a focus on efficiency (speed) and has safety nets in place to maintain security, based on trusted validators.

Validator Rounds

XRPL is based on trust-based validation, where validators are assumed to act honestly adhering to the protocol. As a decentralized network there is the assumption that all validators act independently, proposing ledgers and corrections on their own accord. 

Each validator has a unique node list (UNL). This list consists of trusted validators through the lens of the single validator and is therefore unique and individually managed by each validator. As determined by the rippled protocol, trusted validators embody certain key traits that promote reliability and confidence within the decentralised system. This is defined by four key values: Availability, Agreement, Promptness and Identification. That is, a trusted validator maintains constant availability; submits proposed ledgers in every round and in a timely manner; is in overall agreement with the network, i.e. its vote matches the outcome of the system and the validator is clearly identified, with verified ownership to safeguard the impartiality and decentralisation of the network

For example in a 5 validator system, Validator A may trust Validators B,D, and E but not Validator C. Therefore its UNL would consist of only Validators B,D, and E and, in each round, Validator A would only listen and accept proposals from these 3 validators on its UNL, disregarding Validators C’s inputs. As the UNLs are independently managed, following the same example, validator C could be trusted by validators B,D or E, therefore still contributing to the system.

However, the protocol outlines what constitutes trust in a validator and on the basis that all validators are adhering to this protocol, it is presumed that they will also have similar and overlapping UNLs therefore excluding byzantine validators and excluding their inaccurate block proposals. This again is dependent on the trusted validator assumption- that they each work independently and honestly, excluding byzantine validators from their UNL. 

The Transaction Timeline

Transactions are first requested by the account owner who places an order, digitally signing the transaction request through the API or wallet application. This transaction request is then submitted to the XRPL server, joining the network as a "candidate transaction”. The local server will take ownership of the first check of this transaction, ensuring that the request is in the correct format to be read by the system. Unreadable transaction requests are immediately rejected at this point, ensuring that they go no further past this stage and the user is immediately sent back a rejection confirmation. 

All other transactions which are in the correct format are assigned a provisional status of success or fail and are progressed to the next stage in the transaction process regardless of this provisional status. For example a provisional fail could be assigned on the lack of available funds or submitting a transaction with an exchange rate which does not align with current market rates. However, since these assigned initial outcomes are provisional, they are not final and both a success or fail can be flipped.

For example, if an order is sent with the instructions that the whole order must be executed at a given limit price or cancelled (sometimes referred to as a Fill-or-Kill order), the transaction could have a provisional success. However, in future steps when execution order is determined, the transaction/s executed immediately before within the same ledger version, could wipe out the liquidity on the order book at the given limit price resulting in a fail on the Fill-or-Kill order. 

All payments which are not immediately rejected by the local server are charged the gas fee price of approximately 0.00001 XRP, regardless of the outcome, which covers the network usage cost. The local XRPL servers individually process the transactions sequentially, applying a provisional order status and local proposal for the order of transactions to be executed, based on the order submission timestamp. This provisional server-side lineup typically differs from the final execution sequence applied to the ledger. This is due to the combining of transactions across local servers within the validation process. There is also the possibility that local servers receive transactions not in a chronological order, due to latency in the system or network issues. The consensus mechanism described below accounts for this and employs a majority vote driven mechanism to create a final ordering of execution lineup. 

Achieving Consensus

Applicable transactions from each server are then sent to all the validators who individually construct a ledger version proposal. They will order the transactions, initially by chronological order, combining the candidate transactions received from the different servers into one single ledger proposal. With this encompassing view of the whole network, validators are able to assign a new proposed state of success, failure and more detailed metrics of fill price and fill quantity. Validators will also do secondary checks such as ensuring that there are sufficient funds in the sender's account to cover the transaction quantity and gas fees associated with the order. During this process, all validators are working individually to construct the initial series of events and outcomes. 

Once processed, the individual validators will each construct a proposed ledger containing their version of events and distribute this to the network. Simultaneously, they will receive other validators’ proposals. The XRPL consensus mechanism progresses in rounds and this sending of the proposed ledgers constitutes round one. 

After receiving other validators' proposed ledgers, each validator will filter to consider only the trusted proposals (from validators on their UNL). Each validator will then compare their own proposal with their peers. This is to ensure agreement and validity of their own proposals with the majority. A supermajority of 80% of the validators having matching proposed ledgers is required to reach consensus. 

If 80% agreement is not reached, individual validators will modify their own proposal to more closely match with those of the validators they trust. This will lead to a convergence of results and hence agreement. The prerequisite for amending one’s own proposed ledger is that 80% or more of the other validators include that specific proposition. An example of this is given below in figure__ represented visually by the purple blocks in the top row. Validator 2 sees 80% of the proposals have included it in their round 1 proposal so therefore adds this in round 2.

In the case where less than 80% of the validators have included a specific transaction in their proposed ledger, then all the validators will remove it from their proposals. Removed but valid transactions are stored locally, readily available to be proposed in the next ledger version. For example shown visually in the figure above by the green blocks. In round 1 only 60% include this proposition. In round 2, validator 1 and 3 have removed this block as per the protocol. Validator 5 however remains unchanged, straying away from the protocol. Regardless, consensus is achieved as 80% of the validators have proposed matching ledgers.

Although the UNL sets out to filter out ledger proposals from untrustworthy validators, it is conceivable that validators will be indirectly influenced by proposals not on their UNL. For example, take an arbitrary transaction X and validator A who has excluded validator B from their UNL. In round 1, validator A does not initially include transaction X in their proposed ledger. Yet from a full network point of view, validator B and others, totalling exactly 80% of the whole network do include the given transaction.

From validator A’s point of view, under 80% (since validator B’s contribution is excluded) of the network did not include transaction X and therefore no change was made to validator A’s proposal. Validator C however, who can see the whole network and also did not include the transaction X in their initial proposal, notes that 80% of the proposed ledgers include transaction X. As per the protocol, validator C now adds transaction X to their updated proposed ledger. As everyone resubmits their proposals in round 2, validator A looks again at the network and sees that validators C and others have been updated to include transaction X. This now takes the percentage of those who include transaction X to above 80% from validator A’s point of view and hence, as per the protocol, validator A will include it in their next proposition for round 3. By this effect, the consensus outcome has been influenced by validator B despite not appearing on validator A’s UNL.

This process repeats over an indefinite number of rounds, with the proposed ledgers converging to create an identical record. As per the protocol, since the outcome is either to add, keep or remove a transaction based on the 80% threshold, this results in a stronger agreement with each round as the proposals converge. When 80% agreement is reached amongst the network on the final complete proposed ledger, “consenseus” is reached. In the case where these 80% requirements are not found i.e.more than 20% but less than 80% agree on a final ledger, the network halts and consensus cannot be met. This could happen for example when multiple validators go unexpectedly offline or stray from the protocol and block progress by repeatedly suggesting incorrect proposals. 

It is worth noting that historically this is not common. However, errors are not unheard of on the XRPL. For example, Nov 25, 2024 saw a 2 hour halt of the network briefly impacting ledgers 92346896-92347095 as nodes went offline. Equally, a more concerning error occurred early in the chain's history, in June 2012, when historical records were wiped for ledgers 1 through 32569, which approximates to the first week of launch. These transactions were lost forever. Since then, in the past 12.5yrs of running, an incident of similar severity has not occurred. 

The network is expected to recover independently as validators return back online and/or they return to running the protocol as intended. In a doomsday style scenario where this doesn’t happen, theoretically the network could be halted forever. Halting of the XRPL in outlier conditions is part of Ripple’s decision that safety outweighs progress and is a key separating factor of XRPL to other blockchains. 

This 80% consensus requirement allows for a fixed tolerance of byzantine or slow validators, remaining resilient and allowing consensus to be achieved as long as the conditions are met. This would be considered a high network requirement when compared to BTC’s 51% and SUI’s ⅔ assumptions. By definition, for an invalid transaction to be confirmed, over 80% of trusted validators would need to agree on the invalid transaction/s and ordering (in turn having to work together to agree on these two facts). 

When "consensus" is achieved, the ledger is considered final and each validator will update their own record, publishing the validated ledger as a final immutable record in the XRPL blockchain history.

Executing transactions on the XRPL involves transaction costs starting at approximately 0.00001 XRP. However, as the network load increases, transactions with the highest costs will be prioritised, indirectly regulating demand through surge pricing. This transaction fee is burnt with each transaction.

Validator Incentives 

Validators as part of the XRPL network do not receive financial incentives or specific delivery based rewards for progressing the blockchain. Ripple instead runs on a “natural stakeholders” philosophy, where they believe that the motivation for being a validator comes from preserving the network's ability to function as intended. This for example would be those who benefit from XRPL’s consistent performance such as businesses and organisations with a “natural stake” in the XRPL. 

However, the XRPL Foundation maintains a centralised list of trusted validators called the “Default Unique Node List” (UNL). Validators on this list receive voting rights on XRP Ledger governance, including on protocol development, technical amendments, governance changes, and fee adjustments that impact the network's evolution.

This default UNL also serves as a preset when new validators are set up and as its name suggests, it is literally the default UNL. However, as validators progress, they develop their own unique UNL based on consensus. Not all trusted validators are on the default UNL, meaning not all have voting rights. To be considered for the default list, validators must apply via the XRPL Foundation and undergo assessment against additional criteria to be considered.

The lack of an economic incentive for being a validator however, has led to fewer validators and therefore a higher risk of centralisation. There are currently over 150 registered validators, but only “35+” are listed on a Unique Node List (UNL) and actively participate in the network. The XRPL chain has been running for over 12 years so the discrepancy in registered validators and running validators can be partly attributed to those who previously ran the protocol and have since been switched off. Ripple Labs operates one of the validator nodes, ensuring it is treated equally within the system as per the protocol.

Anyone can be a validator with the appropriate tech set up and computer knowledge to install the software. GPU and electricity usage is comparable to an “email server” according to xrpl.org and there are no extra fees or stakes directly chargeable from the network. In comparison, Proof-Of-Stake chains, such as Ethereum and Solana reward validators and stakers through a proportion of the generation of gas fees. Equally, Proof-Of-Work chains, such as Bitcoin and generally rewards stakers through the mining of tokens. However, XRPL has no financial incentive - for the average crypto user, financial incentives are an important factor when deciding the allocation of limited resources. 

XRP Tokenomics

At launch, a fixed supply of 100 billion XRP tokens were created. 80 billion XRP were allocated to Ripple Labs and 20 billion XRP tokens were distributed amongst the network’s three co-founders who now have personal custody over them. Ripple Labs keeps their share in its escrow accounts and releases periodically, ensuring a constant supply of XRP within the ecosystem. The current rate of sale is approximately 1 billion XRP released monthly and sold at market price, generating a source of revenue for Ripple Labs. There is no fixed condition of a 1 billion release meaning that Ripple Labs can amend the distribution rate in the ecosystem at will. A share of this revenue is reinvested into the XRPL to support the ecosystem as necessary. However, as a private company, Ripple’s fund allocations and investments remain private. 

Transaction fees on the XRPL are burnt resulting in a decreasing supply. The impact currently can be considered negligible due to the extremely low fee of approximately 0.00001 XRP, especially when compared to the total supply of 100 billion. Although this burn rate is an intentional design choice, there is limited information about why it was created. Some speculate it is to ward off malicious spam attacks due to the price associated with spamming the network. However, although low, this is a feature normally associated with the implementation of a  transaction fee and does not explain the choice to burn. Others relate the deflationary effect of burning tokens to an increase in XRP’s token value. With mass adoption of the protocol, there is the possibility that this will have more of an effect, however at present, with a total of approximately 13.5 million XRP burnt, as of Jan, 2025, this will not be immediate. Moreover, the current release of approximately 1 billion XRP tokens from Ripple’s escrow monthly, results in a synthetic net inflationary effect on the token. 

Although with minimal immediate effect on the supply of XRP, it is possible that this “deflationary effect” is a marketing tool to invest in the token. This is in the same way a 21 million supply limit of Bitcoin is boasted. This can be seen in threads and comments of certain XRP holders who quote this deflationary effect as a reason to hold the token. 

Overall, XRP provides real world utility such as serving as a bridge currency within RippleNet and covering transaction fees on the XRP Ledger (XRPL). However, many misconceptions surround the network and tokenomics such as the extent of decentralisation, the transaction fee and deflationary/ synthetic inflationary effect of the burn rate and monthly release of tokens respectively. Ultimately, XRP's fundamental value hinges on the widespread adoption of the XRPL, through direct use of the blockchain and indirectly, through layer 2 protocols and products built on the XRPL. This will drive tokens out of market circulation and into business’ reserves (for future usage) possibly impacting supply and demand dynamics. Also a currently negligible factor is the slow burn of XRP through frequent transactions. However, its price movements are more often influenced by broader trends such as Ripple’s developments, market trends, and speculative trading activity, as many investors hold XRP primarily as an investment rather than for its utility.