XRPL builds what it once declined – and Xahau got there first
When a blockchain forks, it is usually over money or ideology: who controls the treasury, which roadmap to follow, what values the chain should embody. The XRP Ledger split for a different reason. It forked over a feature.
In 2023, after years of stalled progress on adding smart-contract functionality, a group of developers stopped waiting for XRP Ledger validators to approve Hooks, a proposal for lightweight, event‑driven smart contracts. They took the open-source rippled codebase, integrated Hooks, launched a new network called Xahau, issued a native token (XAH), and began running their own validators. They shipped what the parent chain repeatedly declined to activate.
At the time, Ripple’s chief technology officer publicly framed this route as a valid way forward for the technology. There was no formal blessing, but there was clear acknowledgment: if the main chain would not move, others were free to experiment.
Three years later, the picture looks very different. The XRP Ledger is now working on its own programmability layer. XLS‑100d, a WebAssembly-based “Smart Escrows” amendment, has a devnet and brings conditional logic to escrow objects. XLS‑101d, a drafted specification for general smart contracts, explicitly cites both Hooks and the Ethereum Virtual Machine as design influences.
The parent chain is finally building what it once refused. The fork is already running a production version of that idea. The ecosystem now has three distinct architectures answering the same question: how do you make a high‑throughput payments ledger programmable without breaking what made it fast and cheap?
This is what actually happened, what it means for XAH, and how to interpret the emerging competition.
—
What Xahau kept – and what it changed
To understand Xahau, it helps to start with what it did not modify. The fork is less a rejection of the XRP Ledger’s design and more an extension of it.
Xahau preserved the core characteristics:
– Consensus protocol – It uses the XRP Ledger’s consensus style rather than proof-of-work or proof-of-stake.
– Native decentralized exchange – Order books and pathfinding remain first‑class features.
– Fee and reserve model – The network combats spam by charging and burning transaction fees in the native token and requiring minimum reserves for certain objects.
On top of this familiar base, Xahau added the missing ingredient: Hooks.
Hooks: small pieces of logic on accounts
Hooks are compact programs attached directly to accounts. They are triggered by ledger events and can inspect or influence transactions before they execute. Instead of a global, general-purpose virtual machine, Hooks are targeted and constrained.
With Hooks, an account can:
– Enforce time locks on outgoing transfers
– Implement social recovery, where trusted third parties help restore access
– Enable self‑custodial direct debits, where merchants can pull funds within predefined limits
– Log or reject certain transaction patterns for compliance or security reasons
The philosophy is deliberately narrow: Hooks are not meant to host complex DeFi protocols or arbitrary applications. They are event-driven rules that run quickly and cheaply, preserving the payments‑centric nature and settlement speed of the ledger.
Governance by smart contract
Xahau is not only about programmability at the account level; it also wired programmability into its own governance.
Two choices stand out:
1. Simplified token standard
Instead of replicating the parent chain’s NFT implementation, Xahau introduced a simpler token standard more aligned with its design choices and use cases.
2. Genesis account under Hook control
The genesis account – ordinarily a key source of power and risk on a new chain – is itself governed by a Hook. This Hook regulates critical parameters such as new XAH issuance. Governance operates through a two‑tier structure involving up to twenty independently owned validators.
In other words, a chain whose main reason for existing is smart contracts uses a smart contract system to regulate its own core levers. It is a strong expression of “dogfooding” and internal consistency.
XAH serves multiple roles:
– Fee and reserve asset – Similar to XRP on the parent chain, it is used to pay fees and meet reserve requirements.
– Balance-reward mechanism – Xahau introduced a balance-based reward system without a direct counterpart on XRPL, adding an extra incentive layer for holders and network participants.
—
The launch, the friction, and the reality since
The birth of Xahau was contentious, as most ecosystem splits are.
Critics were uneasy about a prominent fork that did not carry an official organizational stamp. Supporters countered that repeated validator refusals to adopt Hooks had left innovation stuck; for them, forking was not an act of defection but a necessary escalation to keep the technology moving.
Regardless of the emotions around it, the measurable outcome is clear:
– Xahau launched and remained live.
– It accumulated a validator set independent of XRPL’s.
– It built an exchange listing record for XAH.
– Developers began shipping live applications around capabilities the parent chain still lacked.
For several years, anyone wanting Hook-style programmability on an XRPL‑like ledger had one option: Xahau.
—
What the XRP Ledger is building now
The XRP Ledger roadmap now targets the same broad goal – programmability – through a different technical route. Two public specifications are central to this shift.
XLS‑100d: Smart Escrows with WebAssembly
XLS‑100d introduces WebAssembly (WASM)-based logic to escrow objects. Instead of escrows being simple time‑ or condition-based locks, they can now be paired with small WASM programs that define under what conditions funds can be released.
The design is intentionally narrow and payments‑native:
– The logic is attached to escrows, not to arbitrary accounts or global state.
– The goal is to support conditional payments and programmable money flows without turning the entire ledger into a general-purpose smart contract platform.
– There is a devnet specifically for developers to experiment with these features before they appear on mainnet.
This approach keeps the ledger close to its original purpose – high-speed settlement – while opening a door to more sophisticated payment workflows.
XLS‑101d: General smart contracts – inspired by Hooks and EVM
More ambitious is XLS‑101d, a draft standard for general-purpose smart contracts on XRPL. The specification is explicit about its influences: it borrows ideas both from Hooks and from the Ethereum Virtual Machine.
That signals a few things:
– The XRPL ecosystem has studied Xahau’s account‑level programmability.
– It also recognizes the need to support broadly familiar paradigms from EVM chains.
– The aim is neither a straight copy of Ethereum nor a full adoption of Hooks, but a hybrid tuned to XRPL’s performance profile.
While the details and final form of XLS‑101d may change, the direction is clear: programmability is no longer a “whether” question for XRPL; it is a “how” question.
—
Is XRPL copying Xahau?
Technically, both chains share a common origin and draw from each other and from the broader smart‑contract ecosystem. Xahau is a fork of XRPL that integrated Hooks early. XRPL is now pursuing WebAssembly-based contracts that explicitly list Hooks as an influence.
That does not make XRPL a one‑to‑one copy of Xahau. The architectures differ:
– Execution model
– Xahau: event-driven Hooks attached to accounts.
– XRPL (planned): WASM modules tied to escrows and potentially more general contracts.
– Scope
– Xahau: designed from the outset for lightweight, account-based programmability.
– XRPL: adding programmability on top of an existing payments ledger with strict backward-compatibility and performance constraints.
What is unmistakable is the narrative reversal: the main chain that refused Hooks is now building something that openly credits Hooks. In a technical sense, this is convergence; in a political sense, it is a quiet acknowledgment that the feature that justified the fork was, in fact, needed.
—
Three ways to write smart contracts in the XRP ecosystem
As programmability matures, developers orbiting the XRP world now have (or soon will have) at least three distinct options:
1. Hooks on Xahau
– Best suited for event-driven logic on accounts: security rules, payment controls, recovery schemes.
– Lightweight, deterministic, designed to keep settlement fast and fees low.
– Integrated with chain governance from day one.
2. WASM Smart Escrows on XRPL (XLS‑100d)
– Narrow focus on conditional fund releases and programmable escrow conditions.
– Strong fit for payment workflows and specialized financial instruments.
3. General smart contracts on XRPL (XLS‑101d)
– A more flexible environment aimed at broader applications.
– Likely to support richer logic that goes beyond simple payment conditions.
– Intentionally informed by both Hooks and EVM experience.
The immediate consequence is competition. The longer‑term effect may be specialization: each approach can fill a different niche, appealing to different developers, businesses, and regulators.
—
What does all of this mean for the XAH token?
For XAH, the situation is paradoxical but potentially powerful.
On one hand, XRPL’s entrance into smart contracts dilutes Xahau’s role as the only programmable XRPL‑style chain. Developers and projects that might have moved to Xahau for programmability alone may now wait for XRPL’s own contracts or choose them for proximity to the larger network.
On the other hand, Xahau holds three early‑mover advantages:
1. Production-hardened Hooks
Hooks are not theoretical. They are live, used, and tested under real network conditions. That credibility matters to developers choosing where to deploy.
2. Programmable governance as a showcase
Xahau actively demonstrates what its own technology can do by placing key chain functions under Hook control. If that governance experiment proves resilient, it becomes a case study that is hard to replicate quickly elsewhere.
3. Distinct economic design
The balance-reward mechanism and fee model offer a tokenomic profile that differs from XRP. For some participants, that divergence is a feature, not a bug.
In practical terms:
– If Xahau continues shipping new features and attracts real usage, XAH can position itself as the native asset of a specialized, smart‑contract‑first XRPL fork.
– If XRPL’s programmability gains are slow, constrained, or heavily shaped by conservative governance, Xahau may retain an advantage in speed and experimentation.
– If XRPL’s new contracts become widely adopted and out‑innovate Hooks, Xahau will have to differentiate on more than “we were first.”
The token’s trajectory will ultimately be decided less by narratives about who copied whom and more by where developers ship, where volume settles, and which tools solve actual business problems.
—
Why did XRPL validators never adopt Hooks?
The original resistance to Hooks on XRPL can be understood through several lenses:
– Risk management – Validators and major stakeholders often prioritize ledger stability over feature velocity. Hooks, as a new execution environment, introduced new potential attack surfaces and performance risks.
– Governance inertia – Any amendment that significantly changes the ledger’s capabilities faces a high bar. Once initial sentiment turned cautious, it became easier to “do nothing” than to champion an unfamiliar model.
– Strategic positioning – There were differing views on whether XRPL should remain a pure payments system or evolve into a general‑purpose platform. Hooks landed in the middle of that debate.
The fork, therefore, was not only a technical divergence but a governance one: a group unwilling to wait for a supermajority chose to implement the feature elsewhere.
—
What would actually settle the competition?
The competition between XRPL’s emerging programmability and Xahau’s Hooks will not be settled by technical specifications or social media debates. It will be settled by:
– Real-world deployments – Which environment hosts production apps that handle meaningful volume and value?
– Developer satisfaction – Where do developers find better tooling, debugging, documentation, and support?
– Security track record – Which platform avoids catastrophic exploits or consensus failures as complexity grows?
– User experience and cost – Where are transactions reliable, fast, and predictably priced under load?
– Regulatory and institutional comfort – Which architecture aligns more naturally with compliance requirements and institutional risk thresholds?
The most plausible long‑term outcome is not a winner‑takes‑all scenario but a layered ecosystem: XRPL as a dominant payments and liquidity hub, Xahau as a programmable sibling optimized for specific use cases and governance models, and bridges and tooling stitching them together.
—
What to watch next
For observers tracking the impact on XAH and the broader ecosystem, a few milestones matter more than others:
1. Activation of XLS‑100d and XLS‑101d on XRPL
Whether these amendments are approved, how quickly they roll out, and in what final form, will define the competitive baseline.
2. Growth of live Hooks-based applications on Xahau
Total value secured, transaction counts, and genuine product traction will indicate whether Xahau is more than a technical proof.
3. Ecosystem tooling
SDKs, wallets, monitoring tools, and development frameworks will heavily influence where new projects choose to build.
4. Cross‑ledger strategies
Projects that strategically use both XRPL and Xahau – for example, payments on XRPL and programmable logic on Xahau – could demonstrate that the “fork versus parent” framing is too narrow.
5. Governance outcomes
How both chains handle upgrades, security incidents, and economic changes will shape trust and long‑term alignment.
—
Frequently Asked Questions
What is Xahau?
Xahau is a fork of the XRP Ledger that preserved its consensus mechanism, DEX, and fee model, while adding Hooks – lightweight smart contracts – and a programmable governance system overseen partly by Hooks themselves. Its native token is XAH.
What are Hooks?
Hooks are small, event-driven programs installed on accounts. They execute when relevant transactions occur, allowing accounts to impose custom rules and logic on incoming or outgoing payments. They are intentionally constrained to keep execution fast and predictable.
What is the XRP Ledger building now?
XRPL is developing WASM-based smart features. XLS‑100d adds programmable conditions to escrows, and XLS‑101d aims to introduce general smart contracts informed by both Hooks and the EVM model.
Is XRPL copying Xahau?
XRPL is not cloning Xahau’s implementation, but it is pursuing a similar goal – programmability on a payments ledger – and explicitly cites Hooks as an influence. Both chains are now moving toward overlapping feature sets from different starting points.
How many ways can you write smart contracts in the XRP ecosystem?
There are three main approaches: Hooks on Xahau, WASM Smart Escrows on XRPL, and the planned general smart contracts on XRPL. Each offers different trade‑offs in scope, complexity, and performance.
What does this mean for the XAH token?
XAH benefits from being the native asset of the first XRPL‑style chain to ship account-level smart contracts and programmable governance. Its future depends on whether Xahau can maintain a technological and adoption edge as XRPL introduces its own programmability.
—
At its core, the story is simple: a feature that was once too controversial for the parent chain became important enough that the same chain is now reinventing it in its own way. Xahau built first. XRPL is building now. The real verdict will be delivered not by rhetoric, but by code, usage, and time.