Technology / where it fits
A financial ledger with policy at account level.
The requirement
Financial institutions need more than fast transfers. They need issued value, counterparty controls, signing governance, settlement primitives, auditability and business-specific policy.
INFTF contributes to Xahau infrastructure and public ledger data APIs. That work informs our experience with its account-based financial model. For a proposed flow, suitability also depends on the settlement asset, counterparty acceptance, liquidity, custody support and operational requirements.
What Xahau is.
Xahau is a decentralised ledger built on the XRP Ledger’s code base. It inherits the XRP Ledger’s Byzantine fault-tolerant consensus and adds features of its own, most importantly Hooks. It was created in 2023, and its server software, xahaud, is open source. The ledger’s native asset, XAH, pays network fees, which are burnt; accounts hold a small XAH balance to cover fees and the ledger’s account reserve. The money that settles in a payment flow is a separate, issuer-backed currency such as regulated euro e-money.
A native financial model.
Issued currencies, trust lines and account relationships are ledger primitives, not application inventions. Institutions can issue value, require authorisation to hold it, and settle against those relationships using the ledger’s native financial model.
Policy attached to the account.
Hooks are programmable logic on the account that holds or moves value. On a payment, logic can run on the originating account and on the destination as a strong transactional stakeholder, which can reject the transaction. Weak stakeholders run after the transaction is applied: they can observe or follow up, but cannot roll it back. The useful picture for an institution is simpler than the developer detail: the rule evaluates the transaction as it happens, next to the balance.
An issuer can also opt in to weak execution for third-party transactions that involve its currency (protocol identifier IOUIssuerWeakTSH). The issuer’s logic can update issuer state or emit follow-up transactions; it is a visibility and follow-up surface, not a veto over holder payments.
Compare account-attached policy with fixed protocol primitives and separate application contracts in programmable payments.
Issuer controls.
- Holder authorisation
- Require explicit authorisation before a trust line may hold the issued asset. The issuer enables it before any trust lines exist.
- Freeze and deep-freeze
- Restrict movement of an issued asset where the asset model allows it.
- Clawback
- Revoke previously issued balances. The issuer must enable it before its account has trust lines or other ledger objects, and it cannot be combined with a no-freeze commitment.
Native primitives institutions actually use.
- Escrow
- Time-based or conditional hold and release, for XAH and issued currencies, without a bespoke contract for the common case.
- Checks
- A deferred payment the recipient cashes, useful for controlled disbursement.
- Payment channels
- High-frequency settlement between known counterparties.
- Offers
- On-ledger exchange where a pair needs a native book, not a separate venue.
- Remit
- One push payment that can deliver several currencies to a single recipient, paying for any missing trust lines or account activation.
- PriceOracle
- Price providers publish reference prices as on-ledger objects that account logic can read. A price is only as reliable as its publisher.
- Cron
- Schedules an account’s own logic to run again later, once or on a repeating interval, without an external job runner beside the money.
Recent protocol capabilities.
Protocol capabilities determine which controls and operations an institution can implement. Assess them alongside the available assets, custody arrangements and integration requirements.
- Mar 2024Remit
- Aug 2025Clawback, DeepFreeze
- Sep 2025Opt-in issuer transaction hooks (IOUIssuerWeakTSH)
- Dec 2025Cron
- Jul 2026PriceOracle, IOURewardClaim
- Not enabledNamedHooks, HookOnV2
Dates are mainnet enablement. Status as of September 2026: NamedHooks and HookOnV2 are implemented in xahaud but not enabled on mainnet. The public amendments page does not yet list PriceOracle or IOURewardClaim; a running xahaud server reports current status through the feature command.
When Xahau is a strong fit.
- institutional account controls
- issued stablecoins or e-money
- clear issuer and counterparty relationships
- deterministic settlement
- narrow programmable policy
- cross-border settlement
- automated mandates
When another network may make more sense.
The incumbent rail and the full-stack vendor are real alternatives, and in these situations one of them is usually the right answer.
- the required stablecoin exists only elsewhere
- a counterparty mandates another network
- deep EVM or DeFi composability is core to the product
- existing custody and tooling support determine the chain
- the corridor needs network-specific liquidity that is not here
- the product is primarily a general-purpose dApp rather than financial settlement
Discuss your architecture
Start with the payment problem. The ledger is a recommendation, not a premise.
Stablecoin controls · Programmable payments · Europe → Ethiopia remittance settlement