RippleX engineer explores potential for native XRP staking as David Schwartz weighs in on future XRPL design

RippleX Head of Engineering J. Ayo Akinyele and outgoing Ripple CTO David Schwartz sparked a discussion on how the XRP Ledger (XRPL) might evolve to expand XRP's utility across decentralized finance.

RippleX is Ripple’s developer division focused on building tools and infrastructure for the XRP Ledger.

In a post on Wednesday, Akinyele said XRP's role now spans tokenized assets, settlement, real-time value transfer, DATs, and, most recently, the launch of Canary's first pure spot U.S. XRP ETF, reflecting its growing place in institutional markets.

Akinyele argued that this expansion naturally raises questions about future incentive models and participation, including whether native staking might make sense on XRPL.

Staking in other networks aligns validators and token holders through financial rewards. "For holders, these models can offer a more direct way to participate in network governance, though they can also introduce new complexities around fairness and distribution," he said.

However, such incentives would challenge long-standing design principles on the XRPL, Akinyele continued, where under its current model, fees are burned rather than redistributed and validator trust is earned through their performance, not their stake.

The developer said native staking would require two foundations: a sustainable source of staking rewards and a fair distribution mechanism. The current fee-burning model would need to be reconsidered, with new programmability fees potentially directed to a rewards pool, he suggested. Staking could strengthen engagement, he added, but introduces governance and fairness trade-offs that must be handled carefully.

Akinyele emphasized that the XRPL's existing Proof of Association model has remained stable for more than a decade by prioritizing trust and reliability over financial incentives. He also pointed to existing ecosystem experimentation — including Uphold, Flare, Doppler Finance, Axelar, and MoreMarkets — as evidence that developers are already exploring staking-like models without requiring protocol-level changes.

Ripple CTO David Schwartz weighs in

Ripple CTO David Schwartz — who recently announced his decision to depart the role at the end of this year after a decade at the firm — weighed in on the discussion. Schwartz noted on X that his "own thoughts on governance and consensus models have evolved" and that the ecosystem has reached a moment where it makes sense to discuss potential new designs.

Ongoing programmability and smart contract initiatives make this an appropriate time to explore what native DeFi capabilities could look like on XRPL, he said, especially given that the network's original model was built in 2012, long before the current DeFi landscape.

Schwartz outlined two technically compelling but likely impractical short-term ideas currently being discussed in the community.

One would introduce a two-layer consensus model in which a small inner validator set — selected based on stake — advances the ledger, while the existing outer layer governs fees, amendments, and oversight. This structure, he said, could increase validator diversity without slowing throughput, allow faster and lighter consensus rounds, and ensure the network only halts if both layers fail.

The second idea would keep XRPL's current consensus mechanism but use transaction fees to fund zero-knowledge proofs that verify smart contract execution. That would let nodes avoid running smart contracts directly while still guaranteeing correctness, he said.

Both ideas, Schwartz noted, are "awesome technically but probably not realistically likely to be good, at least not any time soon."

Community members raised concerns about incentive alignment, fee dynamics, and competition among validators. One user argued that incentives often create tension between validators and users over fees and validator count. Schwartz responded that in the two-layer model, outer validators would still police inner validators without staking, while the inner set would rely on slashing protections against double-signing. Even so, he questioned whether the potential performance gains justify the added complexity and risks.

In both Akinyele's and Schwartz's view, the point of these early discussions is not to advocate for immediate changes but to understand how emerging incentive models, programmability features, and governance structures might influence the network's long-term trajectory. As the ecosystem grows, they said, examining ideas like staking clarifies what the XRPL should preserve and where new capabilities could fit, welcoming the community's input.