While libraries may deal with fee determination for you (see Transaction Signing), when building your own integrations with the Xahauy ledger, you may have to implement dynamic fee determination based on the transaction, source & destination account.

As the sender of a transaction will have to pay for the fees required for the invoked Hooks for the specific transaction type, where Hooks can live both on the source & destination account, you can send a TX Blob (signed with a dummy account) to the fee command, after which Xahau will return the specific fees required for the specific transaction.

Fee RPC Helper

Transaction fees on a ledger with the Hooks Amendment enabled become non-trivial to compute for end-users and/or wallet applications. This is because strong hooks must be paid for by the originator of a transaction, and there may be as many as 4 strong hooks on the sending account and 4 on the receiving account, as well as any other strong transactional stakeholders involved (as can be the case with some exotic transaction types). Further, if the transaction is a SetHook then the size of the parameters, the size of the code and whether it is a create operation or an install operation all determine the size of the fee.

Therefore it is highly recommended that all transactions be run through the updated fee RPC call before they are submitted to the ledger.

To invoke the RPC call:

1. Open a websocket connection to the Hooks node you will be working with.

2. Compose the serialized transaction you wish to know the fee for with the following:

• Fee: 0

• SigningPubKey: "" (That is: 0 byte VL of type 0x73. In hex:0x7300.)

• Do not sign the transaction.

1. Submit it as a hex blob to the RPC as follows:

{"command":"fee", "tx_blob":"<hex blob>"}

For HTTP POST RPC submit it as follows:

{"method":"fee", "params": [{"tx_blob":"<hex blob>"}] }

The response should look something like

{
  result: {
    drops: {
      base_fee: '130520',
    },
  //...
  },
  type: 'response'
}

Take the base fee and set it as the Fee field in the transaction. Now sign and submit it as per the normal transaction submission process.

If there is an invalid value for tx_blob or tx_blob is missing, a regular JSON result will be returned with a base_fee of 10.

Main differences

1. Hooks-enabled networks allow getting network definitions dynamically. Allowing clients to adapt available transaction types, ledger objects, properties, and value types. When implemented correctly, signing and encoding libraries don't have to be updated when the network adds transaction/object types/properties. The libraries below implement this and will handle this for you.

2. Hooks-enabled networks require a NetworkID with every transaction to prevent transaction replay on another chain. The NetworkID will also be returned by a server_info RPC command in the network_id field (e.g. 21338 for Hooks V3 testnet)

3. Transactions on a Hooks-enabled network may need higher fees to deliver a transaction to another account, based on the Hooks that will be executed sending out of the sending account and receiving on the destination account. A reasonable fee to satisfy the Hooks execution can be dynamically fetched from a node by issuing the fee command while providing a transaction as tx_blob. The libraries below implement this and will handle this for you.

Javascript/Typescript

The npm package xrpl-accountlib can sign transactions for Hooks-enabled networks, as it offers full dynamic network feature support fetching network definitions at runtime.

The npm package xrpl-client integrates nicely with xrpl-accountlib (and comes as a dependency) to dynamically fetch the aforementioned network definitions and account values, helping submit the transaction.

Code Sample

import {
  derive,
  utils,
  signAndSubmit,
} from "xrpl-accountlib"

const wss = 'wss://xahau-test.net'
const account = derive.familySeed("s...")

const networkInfo = await utils.txNetworkAndAccountValues(wss, account)

const tx = {
  TransactionType: "SetHook",
  Hooks: [ { Hook: {
    CreateCode: "0061736D01000000011C0460057F7F7F7F7F017E60037F7F7E017E60027F7F017F60017F017E02230303656E76057472616365000003656E7606616363657074000103656E76025F670002030201030503010002062B077F0141B088040B7F004180080B7F0041A6080B7F004180080B7F0041B088040B7F0041000B7F0041010B07080104686F6F6B00030AC4800001C0800001017F230041106B220124002001200036020C41920841134180084112410010001A410022002000420010011A41012200200010021A200141106A240042000B0B2C01004180080B254163636570742E633A2043616C6C65642E00224163636570742E633A2043616C6C65642E22",
    Flags: 1,
    HookApiVersion: 0,
    HookNamespace: "F".repeat(64),
    HookOn: "F".repeat(58) + "BFFFFE",
  }
  }],
  ...networkInfo.txValues,
  // ^^ This adds autmatically fetched values for you:
  // Sequence, Account, LastLedgerSequence,
  // Fee (Hooks enabled: autodetect (from ledger))
}

/**
 * Note: the code above and `signAndSubmit` results in automatically
 * fetching and setting a fee for you. If you want to check the fee
 * for min/max/..., get your own fee (string in drops) using:
 *    utils.networkTxFee(wss, tx)
 * 
 * e.g.
 *    const Fee = await utils.networkTxFee(wss, tx)
 *    assert(Number(Fee) < 50_000, "Auto fee above 50k drops, abort")
 *    Object.assign(tx, { Fee, })
 */

const submitted = await signAndSubmit(tx, wss, account)

console.log(submitted)