xrpl-ruby 0.7.0 → 0.9.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e07e1a6fd2b134d36dbbdaaa977cc39e8e9176499a29e69bd84e69ddfd6f6979
-  data.tar.gz: bcca5b159608288c0cdeffc562a76332fe4e831e4dc9813676f66d46c53546ac
+  metadata.gz: 1b52d066f91b01da1ccdbbe8229cadc3b40b54d79a1234f0ac96f0f131159a06
+  data.tar.gz: 57fc035044049efff0bae7418e48e6ffee589a2cec5d763b056b07d6c23d0b10
 SHA512:
-  metadata.gz: fffeb72058c2a328c01bda6e6bfd63718147fc12326385c18c304b9d0e92013e60ba9ad11424af2ee6bd72c69e016494113db5c05ed26e10ee2501bc0873288a
-  data.tar.gz: 3aa7f43f67c50faaf0139a5f42737a35c5fd59408dc3098144a7a0b3a57bab5dad3eac3fa68fb9819749ba2dd0b7f91460de5e87899279e49b6ab07fcae87c83
+  metadata.gz: 4fd54f7b3c12b2cdf35ceecf7a226526900e31e866f16ad3b138d86ac98571e8cf501904b478fa5fa3ace4a8f49ae0e7ee160a33ba8fbd7031d0563cb59876eb
+  data.tar.gz: 5e61d8a4da0bf7e517b22ae77d3b5ea2580ae36f2751fba690051482c449d2778fb3be9886167e0160ad45d08cc1639afd9eb9b39fefa074163d712b06f1f64b

data/CHANGELOG.md

@@ -5,6 +5,267 @@ All notable changes to this project are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+## [0.9.0] - 2026-11-02
+
+Batch (XLS-56) and permission delegation (XLS-75), both enabled on Mainnet
+since October, are fully supported now:
+- `autofill` prepares and prices a Batch.
+- Accounts sign their part with `Wallet#sign_batch`.
+- `Wallet.combine_batch_signers` merges the parts.
+- Delegated transactions are proven on the Testnet.
+
+All Testnet specs pass on the release commit: a Batch of one account, a swap
+between two accounts, a signer list, tickets, and delegation with and
+without permission.
+
+The codec now also reads UInt Strings the way rippled 3.4.1 does, which is
+the one breaking change. It fixes a serialisation bug that could make a
+multisigned transaction invalid: about one `Signers` entry in 256 lost its
+end marker. Codec fixtures are unchanged: 39/39 transactions and 263/263
+ledger entries, both directions.
+
+### Breaking
+
+- **UInt Strings are read the way rippled reads them.** rippled 3.4.1
+  (`STParsedJSON`) and ripple-binary-codec read these field types like this:
+  - **UInt8, UInt16, UInt32:** a whole decimal number.
+  - **UInt64:** hex of any length, except in the base-10 fields
+    (`MPTAmount`, `MaximumAmount`, `OutstandingAmount`, `LockedAmount`,
+    `ConfidentialOutstandingAmount`), which are decimal.
+  - **Int32, Int64:** a signed decimal number.
+
+  A leading `+` is accepted where rippled accepts it (UInt32, Int32,
+  Int64), not for UInt8, UInt16 or UInt64.
+
+  This codec differed in two places, and both now follow rippled:
+  - A UInt8/16/32 String in its full width was read as hex. `"00000065"`
+    as a `Sequence` was 101 here and is 65 in rippled; `"0000000A"` was 10
+    and now raises.
+  - An unpadded UInt64 String was read as decimal. `"100"` as `IndexNext`
+    was 100 and is `0x100` in rippled; `"36d6"` was 36.
+
+  Names count only for their own field: `TransactionType` and
+  `LedgerEntryType` take type names, `TransactionResult` result codes,
+  `PermissionValue` permission names. Before, any field of the same width
+  took them, so `TicketSequence: "TrustSet"` was ticket 21 and
+  `TransferFee: "Payment"` was 0.
+
+  Integers and the names in their own fields are unchanged, as is everything
+  the codec decodes: it renders UInt8/16/32 as Integers and UInt64 as 16 hex
+  digits, which round-trips. Affected is only code that passes
+  - UInt8/16/32 values as hex Strings,
+  - unpadded UInt64 values meant as decimal, or
+  - a name in a field it does not belong to, such as
+    `TicketSequence: "TrustSet"` or `TransferFee: "Payment"`, which now
+    raises, or
+  - an Int64 as a hex String: `Int64.from("DEAD")` was 57005 and now raises.
+    Int64 also decodes to a decimal String (`"-9"`) instead of 16 hex digits
+    (`"FFFFFFFFFFFFFFF7"`), so it round-trips. rippled 3.4.1 has no Int64
+    field, so this concerns direct use of the type only.
+
+  Where ripple-binary-codec accepts a value,
+  `json_to_binary` now produces the same bytes; it also accepts decimal
+  UInt8/16 Strings, which rippled reads and ripple-binary-codec refuses.
+
+### Added
+
+- **Permission delegation is verified on the Testnet** (XLS-75,
+  PermissionDelegationV1_1 enabled on Mainnet since 2026-10-08). The library
+  needed no change:
+  - `Wallet#sign` signs a transaction whose `Account` is another account.
+  - `autofill` takes the `Sequence` from `Account`.
+  - The codec translates `PermissionValue` names (since 0.8.0).
+
+  `spec/integration/xrpl/delegation_spec.rb` covers the whole flow:
+  - a `DelegateSet`,
+  - then a `Payment` with `Delegate`, signed by the delegate,
+  - checked against rippled 3.4.1: the account pays the amount and the
+    delegate pays the fee,
+  - and a delegate without the permission is refused with
+    `terNO_DELEGATE_PERMISSION`.
+
+  The README has a section on it, including the warning from xrpl.org not to
+  delegate `PaymentBurn` before `fixCleanup3_4_0` is enabled.
+- **Batch signing across accounts.** `Wallet#sign_batch` produces the
+  `BatchSigners` entry for an account with inner transactions in the Batch:
+  the wallet's own account, another account it is the regular key of
+  (`batch_account:`), or one signer of a signer list (`multisign:`). For a
+  delegated inner transaction the `Delegate` signs.
+  `Wallet.combine_batch_signers` merges the signed copies, given as Hashes
+  or hex. It sorts the entries by numeric AccountID, drops the outer
+  account's entry, and merges signatures from one signer list into a single
+  entry. It refuses copies of different Batches and an outer transaction that
+  is already signed.
+  `BinaryCodec.signing_batch_data` builds the payload rippled 3.4.1 verifies:
+  `BCH\0`, the outer account, the sequence value (the `TicketSequence` when
+  `Sequence` is 0), Flags, the inner transaction IDs and the signer accounts.
+  Signatures match the xrpl.js vectors byte for byte, and a swap between two
+  accounts validates on the Testnet. `examples/batch.rb` shows both flows.
+- **`BinaryCodec.transaction_id`** gives the ID of any transaction, signed or
+  unsigned (SHA512Half of `TXN\0` and its serialisation), and
+  `BinaryCodec.inner_transaction_ids` the IDs of a Batch's inner
+  transactions. `Wallet#sign` uses it for its `hash`.
+- **`autofill` prepares a Batch** (XLS-56, BatchV1_1 enabled on Mainnet
+  since 2026-10-09). Every inner transaction gets `tfInnerBatchTxn`, `Fee`
+  `"0"` and an empty `SigningPubKey`; sequences follow `autofillBatchTxn` in
+  xrpl.js: the outer account's inner transactions continue after the outer
+  `Sequence`, every other account starts at its own, a given `Sequence` or
+  `TicketSequence` is kept, and the account's following inner transactions
+  continue after an explicit `Sequence` (xrpl.js hands it out a second time). What the ledger would refuse raises
+  `ArgumentError` before anything is signed: not exactly one mode flag,
+  fewer than two or more than eight inner transactions, an entry that is not
+  a `RawTransaction` wrapper, a nested Batch, an inner signature, fee or key.
+  The rules live in `XRPL::Batch`, which needs no network.
+
+### Fixed
+
+- **A Sequence next to a TicketSequence is refused in a Batch.** On a ticket
+  `Sequence` is 0, and rippled refuses anything else (`temSEQ_AND_TICKET`).
+  `autofill` kept a nonzero one on an inner transaction and counted it, so
+  the account's later inner transactions got sequences that were too high.
+  It now raises `ArgumentError` before handing out any sequence, for the
+  outer transaction as well as the inner ones. Every inner transaction is
+  checked before the first sequence is fetched. A `Sequence` given as a
+  String is read the way the codec encodes it, also in the BatchSigner
+  payload, rather than with `#to_i`; a name or a malformed String raises.
+- **`autofill` gives a transaction on a ticket `Sequence` 0.** With a
+  `TicketSequence` and no `Sequence`, it fetched the account's sequence,
+  which rippled refuses next to a ticket. This affected every transaction
+  type, not only a Batch.
+- **Batch sequences around tickets.** Two cases of `autofill` were wrong
+  for a Batch:
+  - An inner transaction on a ticket got no `Sequence`. The field is
+    required and is 0 on a ticket, and rippled refuses the Batch without it.
+  - An inner `TicketCreate` did not reserve the sequences of the tickets it
+    creates, so the next inner transaction of that account repeated one of
+    them.
+
+  Both now follow rippled: a transaction on a ticket consumes no sequence,
+  and a `TicketCreate` takes one per ticket after its own, or from the
+  current sequence when it is itself on a ticket. Found through the Testnet
+  tests of xrpl-php, which fixed the first case the same day.
+- **A Batch over several accounts was charged too little.** The fee is
+  `(2 + n) × base fee` plus the inner fees (XLS-56 §2.2), with n the
+  signatures in `BatchSigners`; 0.8.0 left n out unless it came in as
+  `signers_count:`. `Fee.calculate` now counts `BatchSigners` itself, a
+  signer-list entry by its nested `Signers`. Because the signatures cover
+  the finished Batch, its fee is set before they exist:
+  `autofill(batch, batch_signatures: 2)` says how many will come. It is a
+  keyword, not a field, so it never reaches the codec. The 2 XRP cap applies
+  to a Batch as it does in xrpl.js.
+
+- **An STArray element could lose its ObjectEndMarker on encode.** The
+  codec closed an element with `0xE1` only when its last byte was not
+  already `0xE1`, so the marker went missing whenever an element ended in
+  that byte by chance: a `Signer` or `RawTransaction` whose last AccountID
+  ends in `0xE1` (about one address in 256), a `Memo` whose data does, or an
+  element ending in a nested object (`AffectedNodes`). Such a transaction
+  was serialised, and therefore signed, differently from rippled and was
+  rejected. Every element now gets its marker; the binaries match
+  ripple-binary-codec byte for byte. The codec fixtures contain no such
+  element, which is why they never showed it.
+- **Decoding wrote a nested object's end marker twice** when re-serialising
+  it, which surfaced as stray `ArrayEndMarker` / `ObjectEndMarker` keys in
+  decoded metadata.
+
+### Changed
+
+- **UInt fields refuse malformed values.** A String that is not a number in
+  the field's reading (see Breaking) raises `ArgumentError`. Before, it went
+  through `#to_i`:
+  - `"101junk"` became 101, `"12.5"` became 12.
+  - `"abc"`, `"-1"` and `"0x10"` became 0.
+
+  A number outside the field's range also raises now. Before, `2**32` as a
+  UInt32 came out five bytes long, and a negative number became 0.
+- **`STObject.from_parser` raises on malformed input** instead of ending
+  the object silently. The last `rescue => e; break` of the codec is gone;
+  a truncated blob used to decode into a partial object.
+
+## [0.8.0] - 2026-09-24
+
+The codec now targets **rippled 3.4.0** (released 2026-09-17) and passes the
+ripple-binary-codec 2.11.0 fixture set: 39 transactions and 263 ledger
+entries, both directions (302 cases; 287 before). Measured before the change:
+transactions 38/39, accountState 262/263 decode.
+
+### Breaking
+
+- **`definitions.json` is rippled 3.4.0.** It is what a 3.4.0 node reports
+  through `server_definitions` (s1.ripple.com), with the node's own digest in
+  `hash`. FIELDS 381 → 357: the 27 `Hook*` fields plus `EmitGeneration` and
+  `EmittedTxn` are gone, because rippled dropped Hooks; a blob carrying one
+  of them no longer decodes. Added: `VaultKind`, `SubscriptionDate`,
+  `RedemptionDate`, `LEVersion`, `ContractResult` (LendingProtocolV1_1,
+  closed-ended vaults), and `CredentialIDs` on `VaultWithdraw` and
+  `LoanBrokerCoverWithdraw`. ripple-binary-codec's `main` additionally
+  carries four `*KeyEpoch` fields from rippled's development branch; they
+  are in no release and deliberately not here.
+- **`PermissionValue` decodes to its name.** A `DelegateSet` permission is
+  a UInt32 that rippled renders by name: a transaction type as its code plus
+  one (`"Payment"` = 1), the twelve granular permissions from 65537
+  (`"TrustlineAuthorize"`). Encoding accepts the names; they were silently
+  serialised as 0 before.
+
+### Added
+
+- **Ledger entry models** — `XRPL::LedgerEntry::AccountRoot`,
+  `::RippleState`, `::Offer` and the other 28 types, generated from
+  `LEDGER_ENTRY_FORMATS` the way the transaction models are generated from
+  `TRANSACTION_FORMATS`. `XRPL::LedgerEntry.from(node)` builds the right
+  class from anything `ledger_entry`, `account_objects` or `ledger_data`
+  returns and keeps rippled's `index` alongside. Every `lsf` flag is a
+  constant on its type. All 263 reference ledger entries round-trip through
+  their model unchanged.
+- **Flag helpers** on transactions and ledger entries: `#flag?` takes the
+  ledger's name, the constant's name or the bit, `#flag_names` lists what
+  is set.
+- **Fees by transaction type.** `autofill` now charges what rippled charges:
+  `EscrowFinish` pays for its `Fulfillment` (base × (33 + bytes / 16)),
+  `AccountDelete`, `AMMCreate` and `VaultCreate` cost the owner reserve
+  from `server_state`, a `Batch` pays two base fees plus those of its inner
+  transactions, the confidential MPT transactions cost ten base fees, and
+  multisigning adds one base fee per signature. Ordinary fees are capped at
+  2 XRP (`Client.new(url, max_fee_drops:)`); the reserve-priced types are
+  not. The rules are a pure module, `XRPL::Fee.calculate`, and the same
+  ones xrpl.js applies. Before, every transaction paid the base fee, so an
+  AccountDelete or an EscrowFinish with a fulfillment could not be
+  autofilled.
+- **Payment channel claims.** `Wallet#sign_payment_channel_claim(channel,
+  drops)` and `#verify_payment_channel_claim`, plus
+  `Wallet.verify_payment_channel_claim(..., public_key)` for the receiving
+  side; `BinaryCodec.signing_claim_data` underneath. Checked against the
+  xrpl.js signature vector byte for byte.
+- The hash prefixes for batch, counterparty and sponsor signatures
+  (`fixCleanup3_4_0`) are in `BinaryCodec::HASH_PREFIX`; the signing
+  helpers for them are not written yet.
+- `Definitions#delegatable_permissions`, and readers for the transaction
+  type, ledger entry type and result tables the codec resolves names
+  against.
+
+### Changed
+
+- `XRPL::Transaction` is built on a new `XRPL::Model` base shared with
+  `XRPL::LedgerEntry`. Its public surface is unchanged;
+  `Transaction::ValidationError` is now `Model::ValidationError`, reachable
+  under both names. A model rejects a hash whose type field contradicts the
+  class (`Payment.new('TransactionType' => 'TrustSet')`), where it used to
+  keep the foreign value and serialise a TrustSet.
+- The transaction models pick up the 3.4.0 fields without a code change:
+  `VaultCreate.new(vault_kind:, subscription_date:, redemption_date:)`.
+- A parity spec that pins `definitions.json` to the 3.4.0 digest and fails
+  if a Hook or development-branch field comes back.
+
+### Fixed
+
+- `ConfidentialOutstandingAmount` renders in base 10 like the other MPToken
+  amounts, not as a 16 digit hex string.
+- `Definitions#get_field_instance` returns `nil` for an unknown field name.
+  Serialising a hash with a foreign key now fails with "Field x is not
+  defined" instead of a `NoMethodError` on `nil`.
+
 ## [0.7.0] - 2026-08-26
 
 The binary codec now passes the full ripple-binary-codec reference fixture set

data/README.md

@@ -12,14 +12,19 @@ A pure-Ruby library to interact with the [XRP Ledger](https://xrpl.org) (XRPL) b
 ## Features
 
 - Key and wallet management (secp256k1 and ed25519)
-- Address codec and binary (transaction) codec
+- Address codec and binary codec, conformant with rippled 3.4.0 and the
+  ripple-binary-codec reference fixtures
+- Transaction and ledger entry models generated from the ledger's own
+  definitions
 - WebSocket client for the XRP Ledger public API
 - Testnet faucet helper to create and fund wallets
-- Transaction lifecycle: autofill, sign, submit, and reliable "submit and wait"
+- Transaction lifecycle: autofill with per-type fees, sign, submit, and
+  reliable "submit and wait"
+- Payment channel claims, signed and verified locally
 
 ## Requirements
 
-- Ruby 3.0 or later
+- Ruby 3.2 or later
 
 ## Installation
 
@@ -111,6 +116,158 @@ hash, which is useful for anything read back off the ledger. Note that
 `validate!` follows rippled's formats: it checks what the ledger requires for
 serialisation, which is not always what a transaction needs to be meaningful.
 
+Flags can be asked about by any of their names:
+
+```ruby
+payment.flag?(:tf_partial_payment)   # => true
+payment.flag_names                   # => ["tfPartialPayment"]
+```
+
+### Fees
+
+`autofill` sets the fee the transaction type actually needs, following the
+same rules as xrpl.js: an `EscrowFinish` pays for the size of its
+`Fulfillment`, `AccountDelete`, `AMMCreate` and `VaultCreate` cost the owner
+reserve, a `Batch` pays for its signatures and its inner transactions, and multisigning adds one
+base fee per signature. Ordinary fees are capped at 2 XRP; pass
+`max_fee_drops:` to `Client.new` to change that. The rules are available on
+their own as `XRPL::Fee.calculate`.
+
+## Ledger entries
+
+The objects that make up the ledger's state - `AccountRoot`, `RippleState`,
+`Offer`, `Escrow` and the rest - have models too, generated from
+`LEDGER_ENTRY_FORMATS` the same way:
+
+```ruby
+node  = client.request_with_retry('ledger_entry', account_root: address).dig('result', 'node')
+entry = XRPL::LedgerEntry.from(node)
+
+entry.class                       # => XRPL::LedgerEntry::AccountRoot
+entry.balance                     # => "370000000"
+entry.flag?(:lsf_default_ripple)  # => true
+entry.flag_names                  # => ["lsfDefaultRipple", "lsfDisableMaster"]
+entry.index                       # the entry's hash, as rippled reports it
+```
+
+Every flag rippled defines is a constant on its type, e.g.
+`XRPL::LedgerEntry::AccountRoot::LSF_DEPOSIT_AUTH`.
+
+## Batch
+
+A `Batch` (XLS-56, enabled on Mainnet since 2026-10-09) applies up to eight
+inner transactions together. `autofill` prepares them: the `tfInnerBatchTxn`
+flag, `Fee "0"`, an empty `SigningPubKey` and their sequences. It also refuses
+a Batch the ledger would refuse. A Batch of one account is signed like any
+other transaction:
+
+```ruby
+batch = client.autofill({
+  'TransactionType' => 'Batch',
+  'Account' => alice.classic_address,
+  'Flags' => XRPL::Batch::FLAGS['Batch']['tfAllOrNothing'],
+  'RawTransactions' => [
+    { 'RawTransaction' => { 'TransactionType' => 'Payment', 'Account' => alice.classic_address,
+                            'Destination' => bob.classic_address, 'Amount' => '1000000' } },
+    { 'RawTransaction' => { 'TransactionType' => 'Payment', 'Account' => alice.classic_address,
+                            'Destination' => carol.classic_address, 'Amount' => '1000000' } }
+  ]
+})
+client.submit_and_wait(batch, wallet: alice, autofill: false)
+```
+
+When inner transactions come from other accounts, each of those accounts
+signs the finished Batch. The outer account signs it last. The signatures
+cover the inner transaction IDs, so the Batch has to be complete before
+anyone signs, and that includes its fee. `batch_signatures:` tells `autofill`
+how many signatures will be collected, one per other account:
+
+```ruby
+batch = client.autofill(swap, batch_signatures: 1)       # Alice pays Bob, Bob pays Alice
+signed = Wallet::Wallet.combine_batch_signers([bob.sign_batch(batch)])
+client.submit_and_wait(signed, wallet: alice, autofill: false)
+```
+
+- `sign_batch(batch, batch_account:)` signs for another account whose
+  regular key the wallet holds.
+- `multisign: true` signs as one member of that account's signer list.
+- `combine_batch_signers` sorts the entries the way rippled requires and
+  drops the outer account's entry. It also merges signatures from one signer
+  list into a single entry.
+- For an inner transaction with a `Delegate`, the delegate signs.
+
+**An outer `tesSUCCESS` does not mean the inner transactions succeeded.**
+Under `tfOnlyOne`, `tfUntilFailure` or `tfIndependent` some of them can fail
+while the Batch itself succeeds. Look up each one by its ID and check its own
+result:
+
+```ruby
+BinaryCodec.inner_transaction_ids(signed).each do |id|
+  result = client.tx_response(transaction: id).dig('result', 'meta', 'TransactionResult')
+  # an inner transaction that was not applied is not found at all
+end
+```
+
+`examples/batch.rb` runs both flows against the Testnet.
+
+## Delegation
+
+An account can let another account send certain transactions on its behalf
+(XLS-75, enabled on Mainnet since 2026-10-08). A `DelegateSet` grants the
+permissions. A permission is either a transaction type, such as `"Payment"`,
+or one of the granular permissions, such as `"TrustlineAuthorize"` or
+`"PaymentMint"`. The codec translates both names.
+
+> **Do not delegate `"PaymentBurn"` until the `fixCleanup3_4_0` amendment is
+> enabled on the target network.** Before that fix, a delegate holding
+> `PaymentBurn` can in certain circumstances also mint fungible tokens
+> (trust line tokens or MPTs). The `feature` method of a node reports
+> whether it is enabled there; [Known Amendments](https://xrpl.org/resources/known-amendments)
+> has the Mainnet status. Source:
+> [Permission Values](https://xrpl.org/docs/references/protocol/data-types/permission-values).
+
+```ruby
+client.submit_and_wait({
+  'TransactionType' => 'DelegateSet',
+  'Account' => isaac.classic_address,
+  'Authorize' => alice.classic_address,
+  'Permissions' => [{ 'Permission' => { 'PermissionValue' => 'Payment' } }]
+}, wallet: isaac)
+```
+
+The delegate then sends the transaction with `Account` set to the delegating
+account and `Delegate` set to itself, and signs it with its own wallet:
+
+```ruby
+client.submit_and_wait({
+  'TransactionType' => 'Payment',
+  'Account' => isaac.classic_address,
+  'Delegate' => alice.classic_address,
+  'Destination' => bob.classic_address,
+  'Amount' => '1000000'
+}, wallet: alice)
+```
+
+- **Sequence:** `autofill` takes it from `Account`, as rippled expects.
+- **Signature and fee:** both belong to the delegate. Isaac pays the amount,
+  Alice pays the fee.
+- **Without the permission:** the transaction comes back as
+  `terNO_DELEGATE_PERMISSION`.
+- **Inside a Batch:** for a delegated inner transaction, the delegate signs
+  the `BatchSigners` entry (see above).
+
+## Payment channel claims
+
+A claim is signed off-ledger and redeemed later with a `PaymentChannelClaim`
+transaction. Amounts are in drops:
+
+```ruby
+signature = wallet.sign_payment_channel_claim(channel_id, '1000000')
+
+# On the receiving side, against the channel's PublicKey:
+Wallet::Wallet.verify_payment_channel_claim(channel_id, '1000000', signature, public_key)
+```
+
 The client is silent by default. To see diagnostic output, pass a logger:
 
 ```ruby

data/lib/binary-codec/binary_codec.rb

@@ -1,12 +1,23 @@
 # frozen_string_literal: true
 
+require 'digest'
+
 module BinaryCodec
   # Hash prefixes for serialization.
   HASH_PREFIX = {
+    transaction_id: 0x54584E00, # 'TXN\0'
     transaction_sig: 0x53545800, # 'STX\0'
     transaction_multi_sig: 0x534D5400, # 'SMT\0'
     validation: 0x56414C00, # 'VAL\0'
-    proposal: 0x50525000 # 'PRP\0'
+    proposal: 0x50525000, # 'PRP\0'
+    payment_channel_claim: 0x434C4D00, # 'CLM\0'
+    batch: 0x42434800, # 'BCH\0'
+    # Role-specific prefixes from fixCleanup3_4_0, so a signature made for
+    # one role cannot be replayed as another.
+    counterparty_sig: 0x43505400, # 'CPT\0'
+    counterparty_multi_sig: 0x43504D00, # 'CPM\0'
+    sponsor_sig: 0x53504E00, # 'SPN\0'
+    sponsor_multi_sig: 0x53504D00 # 'SPM\0'
   }.freeze
 
   # from here: https://github.com/XRPLF/xrpl.js/blob/main/packages/ripple-binary-codec/src/binary.ts
@@ -38,6 +49,110 @@ module BinaryCodec
       st_object.from(json).to_hex
     end
 
+    # The bytes a payment channel claim is signed over: the 'CLM\0' prefix,
+    # the channel ID and the amount in drops. Same as xrpl.js
+    # encodeForSigningClaim.
+    #
+    # @param channel [String] the channel ID, 64 hex characters
+    # @param amount [String, Integer] the amount in drops
+    # @return [Array<Integer>] the signing data
+    def signing_claim_data(channel:, amount:)
+      int_to_bytes(HASH_PREFIX[:payment_channel_claim], 4) +
+        Hash256.from(channel).to_bytes +
+        Uint64.from(Integer(amount)).to_bytes
+    end
+
+    # The ID of a transaction: SHA512Half of 'TXN\0' and its serialisation.
+    # For a signed transaction that is its hash; for an unsigned one, such as
+    # the inner transaction of a Batch, it is the ID rippled gives it.
+    #
+    # @param transaction [Hash, String] the transaction, or its serialisation as hex
+    # @return [String] the ID, 64 uppercase hex characters
+    def transaction_id(transaction)
+      hex = transaction.is_a?(String) ? transaction : json_to_binary(transaction)
+      prefix = int_to_bytes(HASH_PREFIX[:transaction_id], 4).pack('C*')
+      Digest::SHA512.digest(prefix + [hex].pack('H*'))[0, 32].unpack1('H*').upcase
+    end
+
+    # The IDs of a Batch's inner transactions, in order.
+    #
+    # @param batch [Hash] the Batch
+    # @return [Array<String>] one ID per entry of RawTransactions
+    def inner_transaction_ids(batch)
+      Array(batch['RawTransactions']).map do |wrapper|
+        inner = wrapper.is_a?(::Hash) ? wrapper['RawTransaction'] : nil
+        inner = inner.to_h if defined?(XRPL::Transaction) && inner.is_a?(XRPL::Transaction)
+        raise ArgumentError, 'Every entry of RawTransactions needs a RawTransaction' unless inner.is_a?(::Hash)
+
+        transaction_id(inner)
+      end
+    end
+
+    # The bytes a BatchSigner signs over (rippled serializeBatch plus the
+    # signer suffix, rippled 3.4.1 STTx::checkBatchSingleSign and
+    # checkBatchMultiSign): 'BCH\0', the outer Account, the outer sequence
+    # value, Flags, the number of inner transactions and their IDs, then the
+    # BatchSigner's Account and, when multisigning, the signing account.
+    #
+    # Like encodeForSigningBatch in xrpl.js, this encodes what it is given: a
+    # Batch without a Sequence encodes the sequence value 0. Wallet#sign_batch
+    # refuses to sign one, because rippled requires the Sequence.
+    #
+    # @param batch [Hash] the Batch, with Account, Flags and its inner
+    #   transactions complete
+    # @param batch_account [String] the account of the BatchSigner entry
+    # @param signer_account [String, nil] the account of the signer in the
+    #   entry's Signers, when the entry is multisigned
+    # @return [Array<Integer>] the signing data
+    def signing_batch_data(batch, batch_account:, signer_account: nil)
+      unless batch['Account'] && batch.key?('Flags')
+        raise ArgumentError, 'A Batch needs Account and Flags before it can be signed'
+      end
+
+      ids = inner_transaction_ids(batch)
+      bytes = int_to_bytes(HASH_PREFIX[:batch], 4) +
+              account_bytes(batch['Account']) +
+              int_to_bytes(batch_sequence_value(batch), 4) +
+              int_to_bytes(Integer(batch['Flags']), 4) +
+              int_to_bytes(ids.size, 4)
+      ids.each { |id| bytes += hex_to_bytes(id) }
+      bytes += account_bytes(batch_account)
+      bytes += account_bytes(signer_account) if signer_account
+      bytes
+    end
+
+    # rippled's SeqProxy value: the Sequence, or the TicketSequence when the
+    # Sequence is 0 because a ticket is used.
+    #
+    # @param batch [Hash]
+    # @return [Integer]
+    def batch_sequence_value(batch)
+      sequence = uint32_value(batch['Sequence'])
+      return sequence if sequence.positive?
+
+      uint32_value(batch['TicketSequence'])
+    end
+
+    # A UInt32 field's value as the codec serialises it, so a check made on
+    # it agrees with the bytes that are signed. A String is a decimal
+    # number, as rippled reads it, not #to_i: "101junk" raises rather than
+    # becoming 101.
+    #
+    # Only numbers: a UInt32 also takes a permission name ("TrustSet" is
+    # 21), which is meant for PermissionValue and would be a wrong ticket or
+    # sequence here.
+    #
+    # @param value [Integer, String, nil]
+    # @return [Integer] 0 for nil
+    def uint32_value(value)
+      return 0 if value.nil?
+      if value.is_a?(String) && !value.match?(/\A\+?\d+\z/)
+        raise ArgumentError, "A sequence needs a number, got #{value.inspect}"
+      end
+
+      Uint32.from(value).value_of
+    end
+
     # Generates signing data for a transaction.
     # @param transaction [Hash] The transaction to serialize.
     # @param prefix [Integer] The prefix to add to the serialized data.
@@ -60,5 +175,11 @@ module BinaryCodec
 
       prefix_bytes + serialized_bytes
     end
+
+    private
+
+    def account_bytes(address)
+      AddressCodec::AddressCodec.new.decode_account_id(address).to_a
+    end
   end
 end