Files
rippled/include/xrpl/protocol
Peng Wang 3ab800bf47 Merge branch 'ripple/se/wasmi-tests' into ripple/se/fees
Conflict resolution:

- features.macro: both sides added an amendment at the top of the list.
  Kept both, with fixCleanup3_4_0 above SmartEscrow.
- NetworkOPs.cpp: develop moved the ledgerClosed stream publisher out of
  pubLedger and into the new publishLedgerStreams helper, while this branch
  had added the Smart Escrow fee fields to the old inline version. Took the
  helper and moved the gas_limit / bytecode_size_limit / gas_price block into
  it, keeping the featureSmartEscrow guard.
2026-08-09 17:25:25 -04:00
..
2026-07-23 17:04:05 -04: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 xrpld 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.