Files
rippled/include/xrpl/protocol
Ed Hennis 25d246fc92 Merge remote-tracking branch 'XRPLF/develop' into ximinez/fix-getledger
* XRPLF/develop:
  ci: Rewrite clang-tidy workflow(s) in a reusable manner (7062)
  chore: Ignore identifier-naming update in git blame (7066)
  refactor: Enable clang-tidy `readability-identifier-naming` check (6571)
  refactor: Revert certain `Throw`s by `LogicError`s (7036)
  ci: Rename print-env -> print-build-env (7061)
  fix: Gate -mcmodel flags to x86_64 in sanitizer builds (7049)
  fix: Prevents overwriting a bool value in an invariant (6609)
  fix: Address code review comments regarding `boost::coroutine2` (6977)
  refactor: Apply various minor improvements and corrections (7045)
  fix: Store `Delegate` object in delegating and authorized account directories for proper deletion (6681)
  ci: Use print-env from XRPLF/actions (7052)
  fix: Make assorted RPC fixes (6529)
  chore: Enable clang-tidy v21 new checks (7031)
  feat: Create new transaction testing framework `TxTest` (6537)
  feat: Add cleanup amendment for 3.2.0 (7037)
  fix: Fix ubsan flagged issues (6151)
2026-05-05 00:08:59 -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.