XRPL discussions expand as Schwartz explores conditions required for possible native staking

The XRP Ledger’s long-standing design is receiving renewed attention following comments from Ripple CTO David “JoelKatz” Schwartz, who stated that the network’s next phase could require re-examining how value flows across its infrastructure.

The discussion emerged as developers and community members examine the expanding role of the XRP Ledger (XRPL) due to ongoing growth in decentralized finance applications, the introduction of new tokenization use cases, and the recent launch of the first XRP spot exchange-traded fund (ETF) by Canary.

Schwartz’s remarks highlighted that emerging demands across the ecosystem have prompted a broader conversation around whether native staking could one day be integrated into the network, despite XRP’s fundamentally different architecture from typical proof-of-stake systems.

Shift in Thinking Around XRPL Functionality

Schwartz noted that the blockchain industry has changed since the XRPL’s release in 2012. He stated that his own views on governance, consensus, and network incentives have also changed. According to him, activity involving XRP across DeFi platforms, such as Flare, MoreMarkets, Axelar, and Doppler, along with ongoing initiatives around programmability and potential smart contract functionality, prompted a reassessment of what additional native capabilities may eventually be supported.

XRP Ledger was created in 2012. The world of blockchain has changed many, many times over since then.

My own thoughts on governance and consensus models have evolved. I’ve been mulling over how XRP is used in DeFi (both organically with apps and protocols like Flare,… https://t.co/XhufcyBzkA

— David ‘JoelKatz’ Schwartz (@JoelKatz) November 18, 2025

His remarks follow a related observation by J. Ayo Akinyele, who cited XRP’s historical use in payments, tokenized asset settlement, and liquidity operations, prompting his comments. According to Akinyele, the launch of the first XRP spot ETF and the anticipated arrival of more issuers signal a change in direction toward more extensive institutional engagement with the asset, including domains such as money-market funds and tokenized treasuries.

Early Concepts Around Native Staking

Ripple CTO clarified that XRP differs from proof-of-stake networks in several structural ways. Transaction fees on the XRPL are destroyed rather than distributed, the ledger is designed to move any asset quickly and at low cost, and validator influence is not determined by token ownership. He stated that for native staking to exist, the network would require both a defined source of staking rewards and a mechanism for fair distribution, which would reshape how value circulates within the ledger.

Community member Vet responded by noting that staking on other chains is generally employed to determine block producers, raising questions about how such a model would apply to the XRPL. In reply, Schwartz outlined two technical concepts he and other contributors have examined, while stating that both remain unlikely to be adopted in the near term.

Two-Layer Model and ZK-Proof Incentives

A two-layer consensus approach is used in the first concept. According to this model, ledger transitions would be advanced by an inner layer of 16 validators who would be chosen via a staking mechanism.

The current XRPL consensus algorithm would form a shell that regulates amendments, fee guidelines, and proper functionality of the inner layer. According to Schwartz, this separation would enable more diversity of validators whilst maintaining fast ledger progression by using smaller, lighter rounds of validators.

A second concept maintains the current consensus mechanism while repurposing transaction fees to compensate for zero-knowledge proofs that verify smart contract execution. According to Ripple CTO Schwartz, this approach would reduce the need for every node to run complex computations, shifting verification costs to ZK-proof generation.

As the discussion progressed, Vet posed the question of whether the two-layer structure would successfully offload tasks that are more compute-intensive into an incentivized environment, while leaving the current payment-oriented consensus logic in place.

Schwartz clarified that ledger progress would be managed by the inner protocol on a per-transition basis, with the outer layer supervising. He also stated that its design may enhance system resilience since the ledger would only halt when both layers cease their operations.

The smartest crypto minds already read our newsletter. Want in? Join them.