In 2023 a group of developers forked the XRP Ledger because its validators would not adopt smart contracts. Three years later the parent chain is shipping its own programmability layer, and the drafted specification names the fork’s technology as an inspiration. Here is what actually happened, what it means for XAH, and why three competing architectures now answer the same question.
Summary
- Xahau launched in 2023 as a fork of the XRP Ledger’s rippled codebase, carrying the Hooks amendment that XRPL validators never adopted, with its own token, its own validator set, and a governance system run through a genesis account hook.
- The XRP Ledger is now building programmability natively: XLS-100d Smart Escrows, using WebAssembly, sits among known amendments with a devnet live, and XLS-101 Smart Contracts is a drafted specification that cites both Hooks and the Ethereum Virtual Machine as influences.
- Xahau rejects the sidechain framing entirely, positioning itself as an independent Layer 1 that diverged in its own direction, with features the parent lacks and vice versa, and describing the borrowing as mutual.
- Three architectures now answer the same question for one ecosystem: Hooks on Xahau, Solidity through the EVM sidechain whose first year this publication audited at $25,741 in total value locked, and WebAssembly natively on the main ledger.
- The open question is what a fork is worth once the chain it left ships the capability it forked for, and XAH is the asset where that question gets priced.
Forks in crypto usually happen over money or ideology. This one happened over a feature. In 2023, after years in which the XRP Ledger’s validators declined to adopt Hooks, a lightweight smart-contract system that would let small pieces of code live on accounts and govern the transactions those accounts send and receive, the developers behind it stopped waiting. They took the ledger’s open-source rippled codebase, added Hooks, launched a network called Xahau with its own token and its own validators, and shipped the capability the parent chain would not. Ripple’s chief technology officer publicly supported the move at the time, saying he could not think of a better path forward for the technology. Three years later the parent chain is building programmability after all. XLS-100d, a WebAssembly-based Smart Escrows amendment, is among the known amendments with a devnet running, and XLS-101d, a drafted specification for general smart contracts, explicitly names both Hooks and the Ethereum Virtual Machine among its influences. This piece examines what that convergence actually means: for the ledger that spent years refusing, for the fork that stopped waiting, and for an ecosystem that now has three separate answers to the question of how a payments chain becomes programmable.
What Xahau took, and what it built
Understanding the fork requires understanding what it kept, because Xahau is not a departure from the XRP Ledger’s design so much as an addition to it.
The network preserved the core: the consensus protocol, the native decentralized exchange, and the fee-and-reserve logic that protects the ledger against spam by charging and burning fees in the native token. What it added was Hooks, small pieces of code installed on an account that impose rules on transactions before those transactions execute, enabling functions such as time locks on transfers, social-recovery arrangements for accounts, and self-custodial direct debits. The design philosophy is deliberately narrow. Hooks were never intended to replicate a general-purpose virtual machine; they are lightweight logic reacting to ledger events, executing fast enough to preserve settlement speed and cheap enough to suit a payments chain.
Two further design choices distinguish it. Xahau substituted a simpler token standard for the parent’s NFT implementation, and it built a governance system in which the genesis account itself is controlled by a hook that regulates matters including the emission of new XAH, administered through a two-tiered arrangement with up to twenty independently owned validators as participants. Governance by smart contract, on a chain whose reason for existing is smart contracts, is at least internally consistent. XAH functions as the network’s fee and reserve asset, with a balance-rewards mechanism that has no equivalent on the parent chain.
The launch was contentious in the way ecosystem splits usually are, with parts of the XRP community expressing unease at the lack of official involvement, and with the fork’s supporters arguing that validators refusing an amendment for years had left no alternative. The relevant point for today is that Xahau shipped and kept shipping, accumulating a validator set, an exchange listing history, and a working developer story around a capability the main ledger did not have.
What the parent is shipping now
The XRP Ledger’s current roadmap describes a different route to the same destination, and the specifications are public.
XLS-100d, Smart Escrows, brings WebAssembly-based conditional logic to escrow objects, allowing programmable conditions to govern the release of funds, and it appears among the ledger’s known amendments with a dedicated devnet for developers to test against.
That is a narrow, payments-native form of programmability: not a general computing environment, but escrows that can enforce arbitrary conditions written in a widely supported bytecode format. XLS-101d, Smart Contracts, is the broader specification, drafted in 2025, proposing general smart contract capability on the ledger and citing both Hooks and the EVM among the designs it draws from.
The choice of WebAssembly instead of a bespoke virtual machine is the interesting technical decision, because it imports an existing toolchain and developer base rather than asking builders to learn something proprietary. It is also, in its way, an admission: the ledger that resisted programmability for years is now adopting a mainstream execution standard, and doing so with public acknowledgment of the technology that forked away over exactly this question.
The timing places three approaches in the same ecosystem simultaneously. Hooks run on Xahau. Solidity runs on the XRPL EVM sidechain, whose first year this publication audited and found holding $25,741 in total value locked, a figure that remains the sharpest available evidence that architectural compatibility does not produce developer gravity by itself. And WebAssembly is arriving natively on the main ledger. Three answers, one ecosystem, and no consolidation in sight.
The fork refuses the frame
The narrative that writes itself, that a parent chain has absorbed the innovation its fork proved out, is one Xahau explicitly rejects, and its objection deserves fair treatment because it complicates the story usefully.
The current positioning from the Xahau side is that it is not a sidechain and never was one in any meaningful operational sense: it is an independent Layer 1, built from a fork of the XRPL codebase, that has evolved in a completely different direction with its own validators, its own governance, and its own economics. On this account the two networks occasionally adopt ideas from one another and otherwise develop separately, with features existing on each that do not exist on the other. The sidechain confusion, the argument goes, comes from early marketing history and not from present reality.
That framing is defensible on the technical facts and self-interested at the same time, which is normal for any project describing itself. Independence is real: separate consensus, separate validator set, separate token with its own monetary policy. Mutual borrowing is also real, since specifications flow in both directions among developers who largely know each other. But the asymmetry is equally real and no framing dissolves it. When the parent ledger ships general programmability, a developer choosing where to build weighs Xahau’s head start and Hooks’ elegance against the main ledger’s liquidity, its institutional relationships, its exchange support, and the ecosystem’s marketing gravity. Forks that exist to supply a missing capability face their hardest test at exactly the moment the capability stops being missing, and no amount of correct positioning about independence changes the competitive arithmetic a builder actually runs.
The threshold that decides everything
Everything in this piece depends on a governance mechanic that outsiders consistently underestimate, and the ledger’s own recent history supplies the cautionary case.
XRP Ledger amendments activate only when validators on the default list signal support at or above eighty percent, and that support must hold continuously for two weeks before the change takes effect. Fall below the line at any point in the window and the clock resets. There is no foundation that can force adoption, no core team veto, and no timetable: an amendment can sit in the known-amendments list indefinitely, gathering partial support, activating never. Hooks itself is the proof. The specification existed, the implementation worked, the technology was sound enough that the ledger’s own chief technology officer publicly endorsed the fork that shipped it, and the amendment still never reached the threshold on the main chain. Years of availability produced no activation, which is precisely why Xahau exists at all.
That history should discipline every forecast about XLS-100d and XLS-101d. A specification in the known-amendments list is a proposal that validators may or may not adopt, and a drafted specification like the general smart contracts proposal is a step earlier still. Both could activate this year; both could sit for three years; either outcome would be consistent with the ledger’s record. The ecosystem’s more recent experience cuts the same way in the opposite direction, since a maintenance amendment this summer sat near forty-eight percent support for a month before validators moved and carried it past the threshold at eighty-six percent, showing that stalled votes can turn quickly once the coalition assembles. Prediction is unwise in both directions.
The threshold also shapes the competitive dynamic between the two chains in a way neither side usually discusses. Xahau’s governance runs through a hook on its genesis account under a two-tier arrangement with up to twenty validators, which is a materially different mechanism from the parent’s eighty percent supermajority, and the fork’s ability to ship features it decides to ship is not a small advantage for a network whose entire premise is programmability. A chain that can adopt is structurally different from a chain that must persuade. Whether that speed advantage matters more than the parent’s liquidity is the actual competition, and it is a question about governance architecture more than about virtual machines.
For a reader tracking this, the practical instruction is simple: ignore roadmap announcements and watch the validator vote count, published continuously, on the specific amendments. Announcements are intentions. The count is the only thing that has ever decided what the XRP Ledger does.
What it means for XAH
The honest assessment splits into a bear case and a bull case that are both stronger than the ecosystem’s usual discourse allows.
The bear case is straightforward. XAH’s investment thesis has substantially been that Xahau is where XRPL-ecosystem smart contracts live. If XLS-100d and XLS-101d ship and function, that thesis erodes toward a narrower claim: Xahau is where a particular style of lightweight account-attached logic lives, competing against native WebAssembly contracts on a chain with vastly more liquidity, more integrations, and more attention. Fee-burn value accrual on a chain whose activity moves elsewhere is the same problem this publication has documented across the value-accrual arc, arriving in a smaller ecosystem with less cushion.
The bull case rests on three points that deserve their weight. First, shipping schedules: XLS-101d is a draft, amendments require validator adoption at an eighty percent threshold sustained over two weeks, and the ledger’s own history, including the years Hooks spent unadopted, is the strongest available evidence that XRPL amendments can stall indefinitely. Xahau’s capability exists today; the parent’s is a specification and a devnet. Second, design divergence: Hooks and WebAssembly contracts are not substitutes for every purpose, and lightweight event-triggered logic on accounts has properties a general contract environment does not. Third, and most underrated, the governance experiment: a chain whose emission and genesis account are administered by a hook under a two-tier validator arrangement is running a live test of on-chain governance that the parent has not attempted, and if that works at scale it is an independent reason for the network to exist.
The verdict this piece can honestly offer is narrower than either case: the fork’s premise has changed, and the market has not repriced it because the parent’s capability is not live yet. When XLS-100d activates, the question stops being theoretical, and XAH becomes the cleanest available measure of what a fork is worth after the reason for forking has been addressed at home.
What to watch
XLS-100d’s amendment vote. Smart Escrows crossing the eighty percent validator threshold and completing its two-week activation window is the event that converts this from a roadmap story into a live competitive fact. Watch the vote count, not the announcements.
XLS-101d’s progression. A drafted specification is a long way from an activated amendment. Whether the general smart-contract proposal moves toward candidate status within the year, or joins the long list of XRPL specifications that never reached a vote, determines the scale of the challenge to Xahau.
Developer migration signals. New deployments, tooling investment, and grant activity across the three environments are the leading indicators. The EVM sidechain’s first-year experience is the cautionary baseline: compatibility alone moved nothing.
Xahau’s differentiation response. The fork’s strongest move is to lean into what the parent will not copy, meaning its governance model, its balance rewards, and Hooks’ specific ergonomics. Whether the project pivots toward those or defends the general smart-contract ground is the strategic tell worth watching.
A closing observation about what this episode says about the ecosystem’s decision-making, since the technical story has a governance moral. The XRP Ledger’s amendment threshold is a genuine decentralization feature, the same property this publication has praised when validators declined to follow Ripple’s own signaling on other proposals, and it is also the reason a capability the ecosystem clearly wanted took six years and a fork to arrive. Both statements are true, and the tension between them is the permanent condition of any network that makes protocol change hard on purpose. Chains that can ship quickly capture opportunities and make mistakes quickly; chains that require supermajorities avoid mistakes and miss windows. Neither is a flaw to be fixed.
What the Xahau episode adds is the observation that in an open-source ecosystem, the slow chain does not actually prevent the feature from existing. It only determines where the feature lives, who benefits from it, and which token captures whatever value it generates. The developers who wanted Hooks did not wait; they left, built, and launched, and the parent chain’s caution cost it three years of programmability and handed a competitor its founding purpose. Now the parent is building the capability anyway, on its own timeline, with the fork’s work as a reference. That is either the system working exactly as designed, with experimentation happening safely outside the main ledger before the ideas mature into it, or an expensive way to arrive at a destination the ecosystem could have reached directly. Both readings have adherents, and the amendment vote will not settle which is right.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Protocol specifications, amendment statuses, and roadmaps change, and drafted proposals may never activate. Nothing here is a recommendation to buy, sell, or hold any asset. Always do your own research. Information is accurate as of July 27, 2026.
Frequently Asked Questions
What is Xahau?
An independent Layer 1 blockchain launched in 2023 as a fork of the XRP Ledger’s open-source rippled codebase, created to implement Hooks, a lightweight smart contract system that XRPL validators had not adopted. It retains the parent’s consensus protocol, decentralized exchange, and fee-burning design while adding programmability, its own token XAH, its own validator set, and a governance system administered through a hook on the genesis account.
What are Hooks?
Small pieces of code installed on an account that impose rules on transactions the account sends or receives, executing before those transactions complete. They enable functions such as transaction time locks, social-recovery arrangements, and self-custodial direct debits. Hooks were designed for speed and low cost rather than to replicate a general-purpose virtual machine, which is the core design difference from EVM-style smart contracts.
What is the XRP Ledger building now?
Two things. XLS-100d, Smart Escrows, uses WebAssembly to allow programmable conditions on escrow releases and appears among known amendments with a devnet available. XLS-101d, Smart Contracts, is a drafted specification for general smart contract capability that cites both Hooks and the Ethereum Virtual Machine among its influences. Neither is yet activated on the main ledger.
Is XRPL copying Xahau?
Borrowing openly, in one direction, while the fork maintains that exchange runs both ways. The drafted XRPL specification names Hooks as an influence, which is a public acknowledgment. Xahau’s position is that it is an independent chain that has evolved in its own direction, with features on each network absent from the other, and that both occasionally adopt ideas from the other.
How many ways can you write smart contracts in the XRP ecosystem?
Three, currently. Hooks on Xahau, Solidity via the XRPL EVM sidechain, and WebAssembly natively on the main ledger once the relevant amendments activate. The EVM sidechain’s first year, which this publication audited at $25,741 in total value locked, is the ecosystem’s own evidence that offering an execution environment does not by itself attract developers.
What does this mean for the XAH token?
It puts pressure on the fork’s core premise. If the parent ledger ships working programmability, Xahau’s claim narrows from being the ecosystem’s smart contract chain to offering a particular style of lightweight logic against a far more liquid competitor. The counterweights are timing, since XRPL amendments require sustained eighty percent validator support and can stall for years, and genuine design differences between the two approaches.
Why did XRPL validators never adopt Hooks?
The amendment never reached the sustained supermajority the ledger’s governance requires, and no single public explanation covers it. Ripple’s chief technology officer stated at the time of the fork that he did not believe validators were voting on political grounds and that Xahau had made good decisions, describing the fork as a reasonable path forward for the technology.
What would settle the competition?
Activation and adoption, in that order. The amendment vote on Smart Escrows converts the parent’s programmability from a roadmap to a fact, and developer behavior afterward, new deployments and where tooling investment goes, decides which environment accumulates gravity. Ecosystem history suggests capability alone does not determine the outcome. This is educational analysis, not investment advice.
Be the first to comment