Transaction Signing
As Hooks-enabled networks require specific transaction fields & offer more transaction types, not all clients will work out of the box. `xrpl-accountlib`
Main differences
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.
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 thenetwork_id
field (e.g.21338
for Hooks V3 testnet)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 astx_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
Last updated