Files
xahaud/include/xrpl/protocol
Bronek Kozicki 16e154a655 Add support for DomainID in MPTokenIssuance transactions (#5509)
This change adds support for `DomainID` to existing transactions `MPTokenIssuanceCreate` and `MPTokenIssuanceSet`.

In #5224 `DomainID` was added as an access control mechanism for `SingleAssetVault`. The actual implementation of this feature lies in `MPToken` and `MPTokenIssuance`, hence it makes sense to enable the use of `DomainID` also in `MPTokenIssuanceCreate` and `MPTokenIssuanceSet`, following same rules as in Vault:

* `MPTokenIssuanceCreate` and `MPTokenIssuanceSet` can only set `DomainID` if flag `MPTRequireAuth` is set.
* `MPTokenIssuanceCreate` requires that `DomainID` be a non-zero, uint256 number.
* `MPTokenIssuanceSet` allows `DomainID` to be zero (or empty) in which case it will remove `DomainID` from the `MPTokenIssuance` object.

The change is amendment-gated by `SingleAssetVault`. This is a non-breaking change because `SingleAssetVault` amendment is `Supported::no`, i.e. at this moment considered a work in progress, which cannot be enabled on the network.
2026-05-11 10:52:29 +09:00
..
2026-05-07 16:58:25 +09:00
2026-02-20 07:11:12 +09:00
2026-05-11 10:23:00 +09:00
2026-05-11 10:23:00 +09:00
2026-02-20 07:11:13 +09:00
2026-05-11 10:23:00 +09:00
2026-05-07 16:58:25 +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:50 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-05-07 16:58:25 +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-04-28 18:23:31 +10:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-05-11 10:23:00 +09:00
2026-05-11 10:23:00 +09:00
2026-05-11 10:23:00 +09:00
2026-05-07 16:58:25 +09:00
2026-02-20 07:11:13 +09:00
2026-05-07 16:58:25 +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.