Files
xahaud/include/xrpl/protocol
Nicholas Dudfield 985a194bdc feat(export): migrate to retriable ttEXPORT with proposal-based sigs
Replace the old ltEXPORTED_TXN + ttEXPORT_FINALIZE (validation-based
sigs, TxQ injection) approach with a retriable ttEXPORT that collects
validator signatures via TMProposeSet during consensus.

Added:
- terRETRY_EXPORT: keeps tx in retry set across ledger boundaries
- tecEXPORT_EXPIRED (200): LLS expiry frees sequence cleanly
- sfExportResult (OBJECT 98): signed export result in tx metadata
- ExportSigCollector: minimal thread-safe sig tracker
- Proposal sig attachment (RCLConsensus) + harvesting (PeerImp)
- exportSignatures field in TMProposeSet (ripple.proto)
- Metadata plumbing (TxMeta, ApplyViewImpl, ApplyStateTable)
- Hook xport() now emits ttEXPORT via normal emitted txn path

Removed:
- ttEXPORT_FINALIZE (type 90) pseudo-tx and Change::applyExportFinalize
- ltEXPORTED_TXN ledger entry and exportedDir/exportedTxn keylets
- ExportSignatureCollector (replaced by ExportSigCollector)
- TxQ export injection (quorum check + rawTxInsert)
- Validation-based export signing in RCLConsensus
- Application::getExportSignatureCollector

Verified on 5-node testnet: golden path (same-ledger finalization with
ExportResult in metadata), degraded path (tecEXPORT_EXPIRED on sub-quorum),
and hook xport() path (emitted ttEXPORT with shadow ticket creation).
2026-03-18 09:23:52 +07:00
..
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:26:21 +09:00
2026-02-20 07:11:14 +09:00
2026-02-20 07:11:13 +09:00
2026-02-25 16:20:43 +10:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:09:45 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 08:05:50 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:02:59 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-25 16:20:43 +10:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:26:21 +09:00
2026-02-20 08:02:59 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00

protocol

Classes and functions for handling data and values associated with the XRP Ledger protocol.

Serialized Objects

Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.

The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.

Optional Fields

Our serialized fields have some "type magic" to make optional fields easier to read:

  • The operation x[sfFoo] means "return the value of 'Foo' if it exists, or the default value if it doesn't."
  • The operation x[~sfFoo] means "return the value of 'Foo' if it exists, or nothing if it doesn't." This usage of the tilde/bitwise NOT operator is not standard outside of the rippled codebase.
    • As a consequence of this, x[~sfFoo] = y[~sfFoo] assigns the value of Foo from y to x, including omitting Foo from x if it doesn't exist in y.

Typically, for things that are guaranteed to exist, you use x[sfFoo] and avoid having to deal with a container that may or may not hold a value. For things not guaranteed to exist, you use x[~sfFoo] because you want such a container. It avoids having to look something up twice, once just to see if it exists and a second time to get/set its value. (Real example)

The source of this "type magic" is in SField.h.