ARCHIVE/xahau-web
3
0
Fork 0
mirror of https://github.com/Xahau/xahau-web.git synced 2026-08-03 12:10:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

Sublimator notes

Browse Source
This commit is contained in:
Ekiserrepé
2026-06-24 09:43:22 +02:00
parent 84fb564a20
commit dab6d6c738
12 changed files with 36 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/content/docs/docs/features/amendments.mdx
View File

@@ -93,6 +93,18 @@ Adds an optional `HookName` field (4–16 bytes, UTF-8) to the Hook slot in a [S
Adds the `prepare()` Hook API function. `prepare(write_ptr, write_len, read_ptr, read_len)` accepts a partial serialized transaction containing only transaction-type-specific fields and automatically injects all fields required for emission: `Account`, `Sequence`, `SigningPubKey`, `Fee`, `FirstLedgerSequence`, `LastLedgerSequence`, and `EmitDetails`. The output can be passed directly to `emit()`, eliminating the need to manually construct these boilerplate fields in hook code. _(Introduced in 2026.6.21-release+3350)_
##### HookOnV2
Hooks may continue to specify `HookOn` with the existing behaviour, or optionally replace it with two separate fields: `HookOnIncoming` and `HookOnOutgoing`. Both use the same bitmask syntax as `HookOn` but differentiate between transactions originating from the Hook account (`HookOnOutgoing`) and transactions originating from another account (`HookOnIncoming`). _(Introduced in 2026.6.21-release+3350)_
##### PriceOracle
A port of the XRPL PriceOracle (XLS-47d) standard. Enables on-chain price feeds by allowing accounts to publish asset price data as [Oracle ledger objects](/docs/protocol-reference/ledger-data/ledger-objects-types/oracle). Introduces two new transactions: [OracleSet](/docs/protocol-reference/transactions/transaction-types/oracleset) (create or update an Oracle) and [OracleDelete](/docs/protocol-reference/transactions/transaction-types/oracledelete) (remove an Oracle). Also adds the `get_aggregate_price` RPC method for querying aggregated prices across multiple oracles. Each Oracle object stores 1–10 asset/quote price pairs (1–5 pairs consume 1 owner reserve; 6–10 consume 2). The integer `AssetPrice`, together with `Scale`, encodes the price as `AssetPrice` × 10^(-`Scale`). _(Introduced in 2026.6.21-release+3350)_
##### IOURewardClaim
Expands the [ClaimReward](/docs/protocol-reference/transactions/transaction-types/claimreward) transaction type beyond genesis balance adjustments to other IOU currencies. Reward counters are held within the trustline (`LowReward`/`HighReward` objects on the [RippleState](/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state) object) and do not affect genesis balance adjustments. The transaction triggers any Hook installed on the account specified by the `Issuer` field, allowing that Hook to process and optionally pay out the reward. The reward-paying account does not need to be the issuer of the IOU currency. _(Introduced in 2026.6.21-release+3350)_
##### Remit
Implements [XLS-55](https://github.com/XRPLF/XRPL-Standards/discussions/156). A new simple but powerful what-you-see-is-what-you-get push payment transaction type. Enables [Remit transactions](/docs/protocol-reference/transactions/transaction-types/remit) that allow paying multiple currencies and URITokens in the same transaction to the same destination. The transaction automatically pays to create missing trustlines, automatically pays the reserves on transferred tokens, and automatically pays to create the destination account if it doesn't exist. You can mint a receipt or bonus URIToken in-line within the transaction. Optionally inform a third party Hook about the transaction. No partial payments and no pathing.
@@ -187,18 +199,6 @@ Fixes issues with provisional double threading in transaction processing. Ensure
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. After this fix is applied, invalid flags will produce a malformed error as expected. _(Introduced in 2025.10.27-release+2405)_
##### HookOnV2
Hooks may continue to specify `HookOn` with the existing behaviour, or optionally replace it with two separate fields: `HookOnIncoming` and `HookOnOutgoing`. Both use the same bitmask syntax as `HookOn` but differentiate between transactions originating from the Hook account (`HookOnOutgoing`) and transactions originating from another account (`HookOnIncoming`). _(Introduced in 2026.6.21-release+3350)_
##### PriceOracle
A port of the XRPL PriceOracle (XLS-47d) standard. Enables on-chain price feeds by allowing accounts to publish asset price data as [Oracle ledger objects](/docs/protocol-reference/ledger-data/ledger-objects-types/oracle). Introduces two new transactions: [OracleSet](/docs/protocol-reference/transactions/transaction-types/oracleset) (create or update an Oracle) and [OracleDelete](/docs/protocol-reference/transactions/transaction-types/oracledelete) (remove an Oracle). Also adds the `get_aggregate_price` RPC method for querying aggregated prices across multiple oracles. Each Oracle object stores 1–10 asset/quote price pairs (1–5 pairs consume 1 owner reserve; 6–10 consume 2). Prices are stored as scaled integers (`AssetPrice × 10^(-Scale)`). _(Introduced in 2026.6.21-release+3350)_
##### IOURewardClaim
Expands the [ClaimReward](/docs/protocol-reference/transactions/transaction-types/claimreward) transaction type beyond genesis balance adjustments to other IOU currencies. Reward counters are held within the trustline (`LowReward`/`HighReward` objects on the [RippleState](/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state) object) and do not affect genesis balance adjustments. The transaction triggers any Hook installed on the account specified by the `Issuer` field, allowing that Hook to process and optionally pay out the reward. The reward-paying account does not need to be the issuer of the IOU currency. _(Introduced in 2026.6.21-release+3350)_
##### fixCronStacking
Fixes issues with Cron transaction stacking behavior.

2
src/content/docs/docs/hooks/concepts/emitted-transactions.mdx
View File

@@ -24,7 +24,7 @@ Because emitted transactions can trigger Hooks in the next ledger which in turn
The `burden` and `generation` fields collectively prevent [Fork bomb](https://en.wikipedia.org/wiki/Fork_bomb) attacks on the ledger by exponentially increasing the cost of exponentially expanding emtited transactions.
It is important to note that the Hooks API follows the strict rule of _no rewriting_. You _must_ present an emitted transaction in full, valid and canonically formed to xahaud for emission or it will be rejected. With the [HooksUpdate2 amendment](/docs/features/amendments/#hooksupdate2), the [`prepare()`](/docs/hooks/functions/emitted-transaction/prepare) API automates this: the Hook provides only the transaction-type-specific fields and the runtime injects all required emission boilerplate. Without HooksUpdate2, the Hook must construct the complete transaction itself.
It is important to note that the Hooks API follows the strict rule of _no rewriting_. You _must_ present an emitted transaction in full, valid and canonically formed to xahaud for emission or it will be rejected. With the [HooksUpdate2 amendment](/docs/features/amendments/#hooksupdate2), the [prepare()](/docs/hooks/functions/emitted-transaction/prepare) API automates this: the Hook provides only the transaction-type-specific fields and the runtime injects all required emission boilerplate. Without HooksUpdate2, the Hook must construct the complete transaction itself.
### Callbacks

4
src/content/docs/docs/hooks/concepts/hookon-field.mdx
View File

@@ -61,8 +61,8 @@ Instead of specifying a single `HookOn` field, Hooks may optionally replace it w
- **`HookOnIncoming`** — triggers the Hook on transactions **originating from another account** (the Hook account is not the initiator).
- **`HookOnOutgoing`** — triggers the Hook on transactions **originating from the Hook account itself**.
Both fields use the same bit-field syntax as `HookOn`. `HookOnIncoming` and `HookOnOutgoing` are mutually exclusive with `HookOn` — you must use either `HookOn` alone or the `HookOnIncoming`/`HookOnOutgoing` pair, not both. If only one of the pair is specified, the Hook will not fire on the unspecified direction.
Both fields use the same bit-field syntax as `HookOn`. `HookOnIncoming` and `HookOnOutgoing` are mutually exclusive with `HookOn` — you must use either `HookOn` alone or the `HookOnIncoming`/`HookOnOutgoing` pair, not both. If only one of the pair is specified, the Hook will not fire on the unspecified direction.
_Note: The `HookOnIncoming` and `HookOnOutgoing` cannot be configured with exactly the same settings. If you need a Hook to respond to both directions using identical criteria, use the `HookOn` field instead, as it provides a simpler and more appropriate way to define shared trigger behavior._
_Note: The `HookOnIncoming` and `HookOnOutgoing` fields cannot be configured with exactly the same settings. If you need a Hook to respond to both directions using identical criteria, use the `HookOn` field instead, as it provides a simpler and more appropriate way to define shared trigger behavior._
Using `HookOn` alone continues to work exactly as before.

2
src/content/docs/docs/hooks/concepts/named-hooks.mdx
View File

@@ -96,7 +96,7 @@ Hook fee calculation respects the same gating logic: named hooks that would be s
| Error Code | Condition |
| -------------- | --------- |
| `temDISABLED` | `HookName` is present in a Hook slot but the `NamedHooks` amendment is not enabled. |
| `temMALFORMED` | `HookName` present as a top-level transaction field but `featureHooks` or `featureNamedHooks` is not active; or the value fails UTF-8 / length validation. |
| `temMALFORMED` | `HookName` present as a top-level transaction field but `Hooks` or `NamedHooks` is not active; or the value fails UTF-8 / length validation. |
### Use Cases

4
src/content/docs/docs/hooks/concepts/serialized-objects.mdx
View File

@@ -57,8 +57,8 @@ With the [HookAPISerializedType240 amendment](/docs/features/amendments/#hookapi
| STI Type | Code | Examples |
|---|---|---|
| `STI_UINT16` | 1 | `sfTransactionType` |
| `STI_UINT32` | 2 | `sfFlags`, `sfSequence` |
| `STI_UINT64` | 3 | `sfOfferSequence` |
| `STI_UINT32` | 2 | `sfFlags`, `sfSequence`, `sfOfferSequence` |
| `STI_UINT64` | 3 | |
| `STI_HASH128` | 4 | `sfEmailHash` |
| `STI_HASH256` | 5 | `sfLedgerHash`, `sfTransactionHash` |
| `STI_AMOUNT` | 6 | `sfAmount`, `sfFee` |

4
src/content/docs/docs/hooks/functions/emitted-transaction/emit.mdx
View File

@@ -23,7 +23,7 @@ With the [HooksUpdate2 amendment](/docs/features/amendments/#hooksupdate2), use
<TabItem label="JavaScript">
* This function emits the provided transaction JSON.
* On success, it returns the number of emitted transaction hashes.&#x20;
* On success, it returns the emitted transaction hashes.&#x20;
* If there is an error, it returns an error code.
</TabItem>
</Tabs>
@@ -101,7 +101,7 @@ if(typeof emitResult === 'number')
<Tabs>
<TabItem label="C">
<table><thead><tr><th width="127">Type</th><th>Description</th></tr></thead><tbody><tr><td>int64_t</td><td>On success, the number of bytes of transaction hash written (32), or:<br /><br />If negative, an error:<br /><code>OUT_OF_BOUNDS</code><br />- pointers/lengths specified outside of hook memory.<br /><br /><code>PREREQUISITE_NOT_MET</code><br />- <code>emit_reserve</code> must be called first<br /><br /><code>TOO_MANY_EMITTED_TXN</code><br />- the number of emitted transactions is now greater than the promise made when <code>emit_reserve</code> was called earlier<br /><br /><code>EMISSION_FAILURE</code><br />- the transaction was malformed according to the emission rules.</td></tr></tbody></table>
<table><thead><tr><th width="127">Type</th><th>Description</th></tr></thead><tbody><tr><td>int64_t</td><td>On success, the number of bytes of transaction hash written (32), or:<br /><br />If negative, an error:<br /><code>OUT_OF_BOUNDS</code><br />- pointers/lengths specified outside of hook memory.<br /><br /><code>PREREQUISITE_NOT_MET</code><br />- <code>etxn_reserve</code> must be called first<br /><br /><code>TOO_MANY_EMITTED_TXN</code><br />- the number of emitted transactions is now greater than the promise made when <code>etxn_reserve</code> was called earlier<br /><br /><code>EMISSION_FAILURE</code><br />- the transaction was malformed according to the emission rules.</td></tr></tbody></table>
</TabItem>

4
src/content/docs/docs/hooks/functions/emitted-transaction/prepare.mdx
View File

@@ -24,7 +24,7 @@ _(Requires the [HooksUpdate2 amendment](/docs/features/amendments/#hooksupdate2)
<TabItem label="JavaScript">
* This function takes a transaction JSON object and prepares it for emission.
* The transaction must be complete except for the Account field, which should always be the Hook account.
* The transaction must be complete except for the Account, Sequence, SigningPubKey, Fee, FirstLedgerSequence, LastLedgerSequence, and EmitDetails fields.
</TabItem>
</Tabs>
@@ -114,7 +114,7 @@ const prepared_txn = prepare({
| Type | Description |
| -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| int64_t | On success, the number of bytes written to `write_ptr` (the size of the prepared transaction blob). The result can be passed directly as `read_ptr`/`read_len` to `emit()`.<br /><br />If negative, an error:<br />`OUT_OF_BOUNDS` — pointers/lengths fall outside hook memory.<br />`PREREQUISITE_NOT_MET` — `etxn_reserve()` must be called before `prepare()`.<br />`INVALID_ARGUMENT` — the input blob is not a valid serialized transaction, or the transaction cannot be prepared (e.g. fee computation failed).<br />`INTERNAL_ERROR` — failed to generate `EmitDetails` or re-serialize the transaction. |
| int64_t | On success, the number of bytes written to `write_ptr` (the size of the prepared transaction blob). The returned value is the length of the prepared transaction. Pass the original buffer as `read_ptr` and the returned length as `read_len` when calling `emit()`.<br /><br />If negative, an error:<br />`OUT_OF_BOUNDS` — pointers/lengths fall outside hook memory.<br />`PREREQUISITE_NOT_MET` — `etxn_reserve()` must be called before `prepare()`.<br />`INVALID_ARGUMENT` — the input blob is not a valid serialized transaction, or the transaction cannot be prepared (e.g. fee computation failed).<br />`INTERNAL_ERROR` — failed to generate `EmitDetails` or re-serialize the transaction. |
</TabItem>

2
src/content/docs/docs/protocol-reference/ledger-data/ledger-objects-types/hook-definition.mdx
View File

@@ -18,7 +18,7 @@ A `HookDefinition` object describes a hook, which is a piece of code that is exe
"HookParameters": {
"HookParameter": {
"HookParameterName": "DEADBEEF",
"HookParameterValue": "DEADBEEF",
"HookParameterValue": "DEADBEEF"
}
},
"HookApiVersion": 1,

6
src/content/docs/docs/protocol-reference/ledger-data/ledger-objects-types/hook.mdx
View File

@@ -46,8 +46,12 @@ The following fields are used in the hook object:
| Field | JSON Type | Internal Type | Description |
| ---------------- | --------- | ------------- | ------------------------------ |
| `HookHash` | String | Hash256 | The hash of the hook. |
| `CreateCode` | String | Blob | The hex-encoded WebAssembly binary (WASM) that defines the hook's logic. Present when the hook was installed with inline code rather than referencing an existing `HookDefinition` object. |
| `HookGrants` | Array | Array | An array of grant objects specifying which accounts are permitted to set or modify this hook on the hook account's behalf. |
| `HookNamespace` | String | Hash256 | A 32-byte (64 hex character) namespace that segregates this hook's state data from other hooks on the same account. Must be unique per hook slot. |
| `HookParameters` | Array | Array | The parameters of the hook. |
| `HookOn` | String | Hash256 | The transaction/s on which the hook is triggered. Mutually exclusive with `HookOnIncoming`/`HookOnOutgoing`. |
| `HookApiVersion` | Number | UInt16 | The version of the Hooks API used by this hook. Determines which hook API functions are available to the WASM binary at runtime. |
| `HookOn` | String | Hash256 | The transaction type(s) on which the hook is triggered. Mutually exclusive with `HookOnIncoming`/`HookOnOutgoing`. |
| `HookOnIncoming` | String | Hash256 | _(HookOnV2)_ Same syntax as `HookOn`. Triggers the hook on transactions originating from another account. Mutually exclusive with `HookOn`. |
| `HookOnOutgoing` | String | Hash256 | _(HookOnV2)_ Same syntax as `HookOn`. Triggers the hook on transactions originating from the Hook account itself. Mutually exclusive with `HookOn`. |
| `HookCanEmit` | String | Hash256 | Same syntax as `HookOn`. Controls which transaction types the hook is allowed to emit. If absent, the hook may emit any transaction type. |

2
src/content/docs/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state.mdx
View File

@@ -84,7 +84,7 @@ A `RippleState` object has the following fields:
_(Added by the [IOURewardClaim amendment](/docs/features/amendments/#iourewardclaim).)_
Both `LowReward` and `HighReward` are inner objects with the same structure. Which one is present depends on the canonical high/low ordering of the two accounts in the trustline.
Both `LowReward` and `HighReward` are inner objects with the same structure. `LowReward` is present if the low account has opted in to IOU rewards for this trustline, and `HighReward` is present if the high account has opted in. Both can be present if both accounts have opted in. The canonical high/low ordering only determines which side an account maps to.
| Field | JSON Type | Internal Type | Description |
| ---------------------------- | --------- | ------------- | ---------------------------------------------------------------------------------------------------- |

10
src/content/docs/docs/protocol-reference/transactions/transaction-types/claimreward.mdx
View File

@@ -5,7 +5,7 @@ description: >-
accumulated. The rewards can be claimed by the account owner or by a specified
issuer. The account can also opt-out of rewards. With the IOURewardClaim
amendment, this transaction also supports claiming rewards for IOU currencies
issued by accounts with a reward Hook installed.
with a reward Hook installed.
---
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/ClaimReward.cpp)]
@@ -52,7 +52,7 @@ _(Requires the \[IOURewardClaim amendment]\[].)_
| Field | JSON Type | \[Internal Type]\[] | Description |
| --------------- | --------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Account` | String | AccountID | The address of the account that is claiming the reward. |
| `Flags` | Number | UInt32 | _(Optional)_ Can have flag 1 set to opt-out rewards. |
| `Flags` | Number | UInt32 | _(Optional)_ Can have flag 1 set to opt-out of rewards. |
| `Issuer` | String | AccountID | _(Optional)_ The genesis account (XAH rewards) or an IOU account (IOU rewards). |
| `ClaimCurrency` | Object | Issue | _(Optional, IOURewardClaim)_ The IOU currency to claim rewards for, as `{"currency": "...", "issuer": "..."}`. Cannot be XAH. The issuer must not be the genesis account and must not equal `Account`. Requires a trustline to exist between `Account` and the issuer. |
@@ -74,7 +74,7 @@ _(Requires the \[IOURewardClaim amendment]\[].)_
When `ClaimCurrency` is specified, the transaction follows the IOU reward path:
1. The `Issuer` account must have a Hook installed that fires on `ClaimReward` transaction. The Hook is responsible for calculating and distributing the reward payout.
1. The `Issuer` account must have a Hook installed that fires on a `ClaimReward` transaction. The Hook is responsible for calculating and distributing the reward payout.
2. On first claim, a `LowReward` or `HighReward` reward-tracking object is initialised on the trustline ([RippleState](/docs/protocol-reference/ledger-data/ledger-objects-types/ripple-state) ledger object) between `Account` and the issuer. Which side is used depends on the canonical high/low ordering of the two accounts.
3. After every subsequent transaction that changes the trustline balance, the ledger automatically updates `TrustLineRewardAccumulator` inside the tracking object using the same area-under-the-curve formula as genesis XAH rewards.
4. When a `ClaimReward` with `ClaimCurrency` is submitted, the ledger resets the reward counters on the trustline and fires the issuer's Hook, which reads the accumulated value and emits a reward payment.
@@ -89,10 +89,10 @@ Besides errors that can occur for all transactions, ClaimReward transactions can
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `temDISABLED` | Occurs if the required amendment (`BalanceRewards` or `IOURewardClaim`) is not enabled. |
| `temINVALID_FLAG` | Occurs if the flag is set to a value other than 1. _(Requires the \[fixRewardClaimFlags amendment]\[].)_ |
| `temMALFORMED` | Occurs if `ClaimCurrency` is an non-currency or XAH type, if the issuer equals `Account`, or if the transaction fields are otherwise incorrectly set. |
| `temMALFORMED` | Occurs if `ClaimCurrency` is a non-currency or XAH type, if the issuer equals `Account`, or if the transaction fields are otherwise incorrectly set. |
| `temBAD_ISSUER` | Occurs if `ClaimCurrency` is set but the issuer is the genesis account, or if `Issuer` is the genesis account but `ClaimCurrency` is also set. |
| `terNO_ACCOUNT` | Occurs if the sending account does not exist. |
| `tecNO_ISSUER` | Occurs if the `Issuer` account does not exist. |
| `tecNO_PERMISSION` | Occurs if the issuer account is an AMM account. AMM accounts cannot have reward Hooks. |
| `tecNO_TARGET` | Occurs if the issuer account has no Hooks, or none of its Hooks fires on `ClaimReward` transaction. |
| `tecNO_TARGET` | Occurs if the issuer account has no Hooks, or none of its Hooks fires on a `ClaimReward` transaction. |
| `tecNO_LINE` | Occurs if no trustline exists between `Account` and the issuer for the specified `ClaimCurrency`. |

4
src/content/docs/docs/protocol-reference/transactions/transaction-types/sethook.mdx
View File

@@ -98,11 +98,11 @@ _All_ of the following conditions are met:
* The Corresponding Hook does not exist _or_`FLAG_OVERRIDE` is specified.
* `CreateCode` field is specified and is not blank and contains the valid web assembly bytecode for a valid Hook.
* No instance of the same web assembly bytecode already exists on the XRPL. (If it does and all other requirements are met then interpret as an Install Operation — see below.)
* No instance of the same web assembly bytecode already exists on Xahau. (If it does and all other requirements are met then interpret as an Install Operation — see below.)
**Behaviour**:
* A reference counted `HookDefinition` object is created on the Xahau containing the fields in the HookSet Object, with all specified fields (Namespace, Parameters, HookOn) becoming defaults (but not Grants.)
* A reference counted `HookDefinition` object is created on Xahau containing the fields in the HookSet Object, with all specified fields (Namespace, Parameters, HookOn) becoming defaults (but not Grants.)
* A `Hooks` array is created on the executing account, if it doesn't already exist. (This is the structure that contains the Corresponding Hooks.)
* A `Hook` object is created at the Corresponding Hook position if one does not already exist.
* The `Hook` object points at the `HookDefinition`.