2025.12.1-release+2609

Fix: fixCronStacking

This fixes a bug that can cause Cron transactions to not be removed correctly from the transaction queue after being executed. This fix should be voted in before FeatureCron is enabled.

Fix: fixHookAPI20251128

This is an omnibus fix for a handful of non-critical edge case bugs in certain Hook APIs

2025.10.27-release+2405

Feature: Cron

This feature allows Hooks to schedule a series of future self-invocations (akin to a cronjob in Linux systems) which can assist Hook developers in writing complex governance structures, games and more.

Once enabled, an account can setup a Cron using the CronSet transaction type as follows:

{
  "TransactionType": "CronSet",
  "Account": <the hook account>,
  "StartTime": <some Ripple Epoc timestamp, or 0>,
  "RepeatCount": 3,
  "DelaySeconds": 500
}

The RepeatCount field and DelaySeconds field may be absent for a one-off-cron. StartTime may be 0 for "as soon as possible".

To delete an existing Cron, omit all of StartAfter, RepeatCount and DelaySeconds and add Flags: 1 (tfCronUnset).

Once a Cron is ready to be executed, the Cron engine will insert a Cron transaction type into the end of the ledger. This transaction is a pseudo transaction and contains a Owner field which points at the Hook account that requested the Cron. To activate your hook on this transaction you must have collect calls enabled, as the Owner is a weak transactional stakeholder.

The maximum number of repeats is 256, however issuing a further CronSet transaction can extend this once the number of repeats crosses a desired minimum threshold.

At present CronSet cannot be delegated to another account, therefore in most circumstances a Hook will need to know how to emit its own CronSet, or be jointly managed by the hook and keys.

Feature: ExtendedHookState

This feature expands the amount of data Hooks can store in their Hook State (key-value system for Hooks) to allow Hooks richer data storage when they need it.

Once enabled, an account may specify a HookStateScale up to 16 using an AccountSet transaction.

The effect of the scale is to scale up both the maximum size of the value you may store in a single hook state, along with the number of reserve units that k-v pair consumes.

A scale of 1 (default) means you pay 1 reserve for up-to 256 bytes stored per Hook State. A scale of 4 means you pay 4 reserve units for up-to 1024 bytes per Hook State. It's important to note that you pay this rate (the scale rate) even if all of your Hook States contain only a single byte, so choosing the scale carefully ahead of time based on the actual number of bytes you need to store is wise.

It is possible to increase the scale after your Hook already has stored state, but not to decrease it. Decreasing the scale requires all HookState to be first deleted.

Fix: InvalidTxFlags

This fixes a bug that currently allows invalid flags to be provided to some transactions. While these invalid flags currently do nothing, they should actually produce a malformed error, and after this fix is applied, they will.

Other

OpenSSL has been upgraded to 3.6.0 which should affect the processing speed of SHA512, which should improve the overall performance of Xahaud.

2025.7.9-release+1951

Feature: IOUIssuerWeakTSH

Ensure that Currency Issuers have their hooks executed in third party transactions that touch or mention their currency, if they have opted into weak execution.

Feature: DeepFreeze

This is a ported feature from the XRPL. See here for details.

Feature: Clawback

This is a ported feature from the XRPL. See here for details.

Fix: ProvisionalDoubleThreading

Ensure the correct PreviousTxnID and PreviousTxnLgrSeq are correctly populated in provisional metadata (for again as week Hooks) and after.

Other

A patch was added to the reference implementation of the governance game to ensure votes from deposed members are correctly cleaned up. This updated Hook still has to be voted in by the existing governance game to be live.

2025.5.1-release+1762

Feature: Touch

This amendment ensures all accounts involved in a transaction (all transactional stakeholders) are forced to appear in its metadata by incrementing a "touch counter" even if nothing else on the account was changed. This is named for the unix file utility touch. This provides better audit consistency and ease of programming automated tools.

Feature: Remarks

The Remarks amendment allow key-value pairs (similar to hook state) to be stored by object owners on those objects. This is akin to flipping over a document and hand-writing a note on it. Remarks can be anything and mean different things to different parties. Remarks can also be set to immutable. Remarks follow an object through a changes of ownership and can be used to achieve novel use cases like dynamic NFTs and simplify some otherwise very complicated hook state operations.

{
  "TransactionType": "SetRemarks",
  "ObjectID": "<32 byte hex keylet here>",
  "Remarks": [  // this array is a delta allowing adding or removing entries
    {
      "RemarkName": "<hex up to 256 bytes>",
      "RemarkValue": "<hex up to 256 bytes, or empty to delete the key at this entry>",
      "Flags": 1, // immutable if 1, mutable if 0
    }, ... // more entries as desired up to 32 remarks per object.
}

Most object types can have remarks attached to them by the obvious owner, including Account Root, Offer, Escrow, Ticket, Paychan, Check, URIToken, etc.

Feature: HookCanEmit

This amendment adds a new field to HookSet objects: HookCanEmit is syntactically identical to the HookOn field, except that it controls which transaction types the Hook is allowed to emit rather than which transaction types trigger the hook. Note that it uses the same active-low semantics as HookOn with SetHook being active high. However if the field is absent it's taken to be that the Hook may emit any transaction including SetHook.

Feature: Catalogue

This is a non-amendment feature which allows full history to be saved into solidly compressed "catalogue files" and then subsequently loaded on other machines.

{
  "command":"catalogue_create",
  "output_file":"/root/cat.12650000.12950000.hashed",
  "min_ledger": 12650000,
  "max_ledger":12950000,
  "compression_level":9
}

{
  "command":"catalogue_load",
  "input_file":"/root/cat.3"
}

{
  "command":"catalogue_status"
}

Fixes: fixRewardClaimFlags, other non-amendment fixes.

Fix for invalid flags on certain transactions. Various minor fixes for consistency and RPC performance.

2025.2.6-release+1299

Rippled 1.11.0 Sync

Xahaud is a code fork of Rippled and periodically improvements from Rippled are ported into Xahaud. We call this a sync. This sync 1.11.0 should improve the stability and memory use of Xahaud nodes.

Fixes: fixReduceImport, fixXahauV3, fix20250131

These three fix amendments ensure consistency and sensible outcomes for various edge cases. They are default YES voted. If validators wish to vote against any of these they must manually change their vote to no.

Feature : Datagram monitor

If enabled, your Xahaud node will send periodic UDP packets to a monitoring address. This can be used to monitor several Xahaud nodes you are responsible for. Please keep in mind that some of the information in these datagrams is sensitive, so you should only send to endpoints you trust. Entry for your config is as follows:

[datagram_monitor]
<ip> <port>

To receive datagrams use a monitoring tool such as https://github.com/RichardAH/xdgm

Feature: UDP RPC

Experimental
Connectionless RPC is now supported using the config options below. This is an ADMIN rpc endpoint. Do not expose it to the public internet. Please note subscriptions and responses are sent to the IP-PORT tuple from which their request originated. To cancel a subscription send unsubscribe from the same. This feature is experimental and intended for operators who prefer to unwrap inbound websocket connections and load balance queries across a large number of Xahaud nodes.

[server]
port_rpc_admin_udp

[port_rpc_admin_udp]
port = 55555
ip = 127.0.0.1
protocol = udp
admin = 127.0.0.1

2024.11.18-release+1141

Feature : rwdb Memory mode

• New backend and relational database mode rwdb that only uses RAM, no disk IO required.
• Improved performance when using this mode to service RPC, submission nodes, hubs, validators.
• Example config:

[ledger_history]
256

[node_db]
type=rwdb
online_delete=256
advisory_delete=0

[relational_db]
backend=rwdb

[database_path]
/var/lib/xahaud/db

[debug_logfile]
/var/log/xahaud/debug.log

Fix: FloatDivide

• Small fix amendment set to default: yes voting.
• Changes the behaviour of the float_divide hook api to correct a small error.

Misc changes

• RPC performance improvements.
• Update to boost 186.
• Various small fixes and performance improvements.

2024.10.15-release+1020

Expanded ledgers

• Increase the target number of transactions per ledger from 256 to 1000 (before fee escalation kicks in).
• This fix does not have an amendment because the size of the next ledger is an inherent part of consensus that validators are allowed to disagree about. As more validators adopt this version, and as new projects join the network, the average size of ledgers will progressively grow.

2024.9.11-release+985

Fix amendment

• Fix for edge case on rewards claim

2024.9.7-release+977

Remove directory page limit and improve sync logic

• Remove cap on the maximum directory index
• Sync ledger acquisition logic with rippled

2024.8.20-release+962

Xahaud 2024.8.20-release+962 Release Notes

Connectivity & other fixes

• Improved WebSocket stability.
• Peer reservation behaviour fixes.
• Reduced erroneous error messages in logs.
• Other misc. fixes.