Files
rippled/include/xrpl/protocol
Shawn Xie 9f4cf28aea Rename privacy flag and public key names (#6550)
Corresponding spec change:
https://github.com/XRPLF/XRPL-Standards/pull/501

### Field Renames (SFields)

| Before | After |
|--------|-------|
| `sfIssuerElGamalPublicKey` | `sfIssuerEncryptionKey` |
| `sfHolderElGamalPublicKey` | `sfHolderEncryptionKey` |
| `sfAuditorElGamalPublicKey` | `sfAuditorEncryptionKey` |

### Flag Renames

#### Transaction Flags (`tf`)

| Before | After |
|--------|-------|
| `tfMPTCanPrivacy` | `tfMPTCanConfidentialAmount` |

#### Ledger State Flags (`lsf`)

| Before | After |
|--------|-------|
| `lsfMPTCanPrivacy` | `lsfMPTCanConfidentialAmount` |

#### Ledger State Mutable Flags (`lsmf`)

| Before | After |
|--------|-------|
| `lsmfMPTCannotMutatePrivacy` |
`lsmfMPTCannotMutateCanConfidentialAmount` |

#### Transaction Mutable Flags (`tmf`)

| Before | After |
|--------|-------|
| `tmfMPTCannotMutatePrivacy` |
`tmfMPTCannotMutateCanConfidentialAmount` |
| `tmfMPTSetPrivacy` | `tmfMPTSetCanConfidentialAmount` |
| `tmfMPTClearPrivacy` | `tmfMPTClearCanConfidentialAmount` |
2026-03-17 10:53:17 -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 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.