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.

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.

  1. Mar 2024Remit
  2. Aug 2025Clawback, DeepFreeze
  3. Sep 2025Opt-in issuer transaction hooks (IOUIssuerWeakTSH)
  4. Dec 2025Cron
  5. Jul 2026PriceOracle, IOURewardClaim
  6. 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.