[Source]

The Amendments object type contains a list of Amendments that are currently active. Each ledger version contains at most one Amendments object.

Example JSON

{
    "Majorities": [
        {
            "Majority": {
                "Amendment": "1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146",
                "CloseTime": 535589001
            }
        }
    ],
    "Amendments": [
        "42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE",
        "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373",
        "6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC",
        "740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11"
    ],
    "Flags": 0,
    "LedgerEntryType": "Amendments",
    "index": "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4"
}

Fields

Each member of the Majorities field, if it is present, is an object with one field, Majority, whose contents are a nested object with the following fields:

In the amendment process, a consensus of validators adds a new amendment to the Majorities field using an [EnableAmendment][] pseudo-transaction with the tfGotMajority flag when 80% or more of validators support it. If support for a pending amendment goes below 80%, an [EnableAmendment][] pseudo-transaction with the tfLostMajority flag removes the amendment from the Majorities array. If an amendment remains in the Majorities field for at least 2 weeks, an [EnableAmendment][] pseudo-transaction with no flags removes it from Majorities and permanently adds it to the Amendments field.

Note: Technically, all transactions in a ledger are processed based on which amendments are enabled in the ledger version immediately before it. While applying transactions to a ledger version where an amendment becomes enabled, the rules don't change mid-ledger. After the ledger is closed, the next ledger uses the new rules as defined by any new amendments that apply.

Amendments ID Format

The Amendments object ID is the hash of the Amendments space key (0x0066) only. This means that the ID of the Amendments object in a ledger is always:

7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4

(Don't mix up the ID of the Amendments ledger object type with the Amendment ID of an individual amendment.)

[Source]

(Added by the [Checks amendment][].)

A Check object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an Escrow, the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.)

Example JSON

{
  "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
  "Destination": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
  "DestinationNode": "0000000000000000",
  "DestinationTag": 1,
  "Expiration": 570113521,
  "Flags": 0,
  "InvoiceID": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
  "LedgerEntryType": "Check",
  "OwnerNode": "0000000000000000",
  "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
  "PreviousTxnLgrSeq": 6,
  "SendMax": "100000000",
  "Sequence": 2,
  "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
}

Fields

A Check object has the following fields:

Check ID Format

The ID of a Check object is the [SHA-512Half][] of the following values, concatenated in order:

• The Check space key (0x0043)

• The AccountID of the sender of the [CheckCreate transaction][] that created the Check object

• The Sequence number of the [CheckCreate transaction][] that created the Check object. If the CheckCreate transaction used a Ticket, use the TicketSequence value instead.

Each ledger version in the XRP Ledger is made up of three parts:

• Ledger Header: Metadata about this ledger version itself.

• Transaction Set: All the transactions that were executed to create this ledger version.

• State Data: The complete record of objects representing accounts, settings, and balances as of this ledger version. (This is also called the "account state".)

State Data

Each ledger version's state data is a set of ledger objects, sometimes called ledger entries, which collectively represent all settings, balances, and relationships at a given point in time. To store or retrieve an object in the state data, the protocol uses that object's unique Ledger Object ID.

In the peer protocol, ledger objects have a canonical binary format. In xahaud APIs, ledger objects are represented as JSON objects.

A ledger object's data fields depend on the type of object; the Xahau Ledger supports the following types:

• Ledger Header

• Ledger Entry Common Fields

• Ledger Entry Types

[Source]

The DirectoryNode object type provides a list of links to other objects in the ledger's state tree. A single conceptual Directory　takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 IDs of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.

There are two kinds of Directories:

• Owner directories list other objects owned by an account, such as RippleState (trust line) or Offer objects.

• Offer directories list the offers available in the decentralized exchange. A single Offer directory contains all the offers that have the same exchange rate for the same token (currency code and issuer).

Example JSON

Offer Directory

{
    "ExchangeRate": "4F069BA8FF484000",
    "Flags": 0,
    "Indexes": [
        "AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD"
    ],
    "LedgerEntryType": "DirectoryNode",
    "RootIndex": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000",
    "TakerGetsCurrency": "0000000000000000000000000000000000000000",
    "TakerGetsIssuer": "0000000000000000000000000000000000000000",
    "TakerPaysCurrency": "0000000000000000000000004A50590000000000",
    "TakerPaysIssuer": "5BBC0F22F61D9224A110650CFE21CC0C4BE13098",
    "index": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000"
}

Owner Directory

{
    "Flags": 0,
    "Indexes": [
        "AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD",
        "E83BBB58949A8303DF07172B16FB8EFBA66B9191F3836EC27A4568ED5997BAC5"
    ],
    "ReferenceCount": "1",
    "LedgerEntryType": "DirectoryNode",
    "Owner": "rpR95n1iFkTqpoy1e878f4Z1pVHVtWKMNQ",
    "RootIndex": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94",
    "index": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"
}

Fields

Directory ID Formats

There are three different formulas for creating the ID of a DirectoryNode, depending on which of the following the DirectoryNode represents:

• The first page (also called the root) of an Owner Directory

• The first page of an Offer Directory

• Later pages of either type

The first page of an Owner Directory has an ID that is the [SHA-512Half][] of the following values, concatenated in order:

• The Owner Directory space key (0x004F)

• The AccountID from the Owner field.

The first page of an Offer Directory has a special ID: the higher 192 bits define the order book, and the remaining 64 bits define the exchange rate of the offers in that directory. (The ID is big-endian, so the book is in the more significant bits, which come first, and the quality is in the less significant bits which come last.)

This provides a way to iterate through an order book from best offers to worst. Specifically: the first 192 bits are the first 192 bits of the [SHA-512Half][] of the following values, concatenated in order:

• The Book Directory space key (0x0042)

• The 160-bit currency code from the TakerPaysCurrency

• The 160-bit currency code from the TakerGetsCurrency

• The AccountID from the TakerPaysIssuer

• The AccountID from the TakerGetsIssuer

The lower 64 bits of an Offer Directory's ID represent the TakerPays amount divided by TakerGets amount from the offer(s) in that directory as a 64-bit number in Xahau's internal amount format.

If the DirectoryNode is not the first page in the Directory (regardless of whether it is an Owner Directory or an Offer Directory), then it has an ID that is the [SHA-512Half][] of the following values, concatenated in order:

• The DirectoryNode space key (0x0064)

• The ID of the root DirectoryNode

• The page number of this object. (Since 0 is the root DirectoryNode, this value is an integer 1 or higher.)

(Added by the [Hooks amendment][].)

An EmittedTxn object describes a transaction that has been emitted by a hook. The object contains all the fields of the original transaction, along with additional details about the emission.

Example JSON

{
  "Account": "rMPwD1b8dJUaqZHaBgEvFx4ENhtpPVvDsv",
  "Amount": "999999",
  "Destination": "rfCarbonVNTuXckX6x2qTMFmFSnm6dEWGX",
  "DestinationTag": 0,
  "EmitDetails": {
    "EmitBurden": "1",
    "EmitCallback": "rMPwD1b8dJUaqZHaBgEvFx4ENhtpPVvDsv",
    "EmitGeneration": 1,
    "EmitHookHash": "A9B5411F4A4368008B4736EEE47A34B0EFCBE74016B9B94CC6208FBC0BF5C0C2",
    "EmitNonce": "6B2A27D6864903A479614581A79D18E8C8ADCE01E3440C6E993BE07298ADC2A4",
    "EmitParentTxnID": "9763EB6B74AEF0F55F642243AD51F48490594434439002A6142E545E47318D56"
  },
  "Fee": "31",
  "FirstLedgerSequence": 7186113,
  "Flags": 2147483648,
  "LastLedgerSequence": 7186117,
  "Sequence": 0,
  "SigningPubKey": "000000000000000000000000000000000000000000000000000000000000000000",
  "SourceTag": 0,
  "TransactionType": "Payment"
}

Fields

An EmittedTxn object has the following fields:

The EmittedTxn object also contains all the fields of the original transaction.

EmitDetails Fields

An EmitDetails object has the following fields:

[Source]

(Added by the [Hooks amendment][].)

A Hook object describes a smart contract, which can be triggered by a transaction to perform predefined operations. The operations are defined by the Hook creator and can interact with the ledger and transactions.

Example JSON

{
  "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
  "OwnerNode": "0000000000000000",
  "PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
  "PreviousTxnLgrSeq": 6,
  "Hooks": [
    {
      "HookHash": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
      "HookParameters": []
    }
  ],
  "LedgerEntryType": "Hook",
  "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
}

Fields

A Hook object has the following fields:

Hook Fields

The following fields are used in the hook object:

Hook ID Format

The ID of a Hook object is the [SHA-512Half][] of the following values, concatenated in order:

• The Hook space key (0x0048)

• The AccountID of the sender of the [SetHook transaction][] that created the Hook object

[Source]

The FeeSettings object type contains the current base transaction cost and reserve amounts as determined by fee voting. Each ledger version contains at most one FeeSettings object.

Example JSON

Example FeeSettings object:

{
   "BaseFee": "000000000000000A",
   "Flags": 0,
   "LedgerEntryType": "FeeSettings",
   "ReferenceFeeUnits": 10,
   "ReserveBase": 20000000,
   "ReserveIncrement": 5000000,
   "XahauActivationLgrSeq": 0,
   "NetworkID": 21337,
   "AccountCount": 0,
   "index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651"
}

Fields

The FeeSettings object has the following fields:

Warning: The JSON format for this ledger object type is unusual. The BaseFee, ReserveBase, and ReserveIncrement indicate drops of XAH but not in the usual format for [specifying XAH][Currency Amount].

If the [XAHFees amendment][] is enabled, the FeeSettings object has these fields instead:

FeeSettings ID Format

The FeeSettings object ID is the hash of the FeeSettings space key (0x0065) only. This means that the ID of the FeeSettings object in a ledger is always:

4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651

[Source]

(Added by the [Hooks amendment][].)

A HookDefinition object describes a hook, which is a piece of code that is executed in response to certain transactions. The hook can modify the transaction, emit new transactions, or perform other actions.

Example JSON

{
  "HookHash": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
  "HookOn": "0000000000000000000000000000000000000000000000000000000000000000",
  "HookNamespace": "0000000000000000000000000000000000000000000000000000000000000000",
  "HookParameters": {
    "HookParameter": {
      "HookParameterName": "DEADBEEF",
      "HookParameterValue": "DEADBEEF",
    }
  },
  "HookApiVersion": 1,
  "CreateCode": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
  "HookSetTxnID": "0000000000000000",
  "ReferenceCount": "6",
  "Fee": "100000000",
  "HookCallbackFee": "200000000",
  "LedgerEntryType": "HookDefinition",
  "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
}

Fields

A HookDefinition object has the following fields:

Hook Definition ID Format

The ID of a HookDefinition object is the [SHA-512Half][] of the following values, concatenated in order:

• The HookDefinition space key (0x0044)

• The HookHash of the hook

[Source]

(Added by the [Hooks amendment][].)

A HookState object describes the state of a hook, which is a piece of code running on Xahau that can interact with transactions. The HookState object stores the state of the hook, which can be modified by the hook's code.

Example JSON

{
  "OwnerNode": "0000000000000000",
  "HookStateKey": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
  "HookStateData": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
  "LedgerEntryType": "HookState",
  "index": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924"
}

Fields

A HookState object has the following fields:

HookState ID Format

[Source]

The ID of a HookState object is the [SHA-512Half][] of the following values, concatenated in order:

• The HookState space key (0x0076)

• The AccountID of the account that owns the hook

• The HookStateKey of the HookState object

• The HookNamespace of the hook.

(Added by the [Import amendment][].)

The ImportVLSequence helps track and validate the order of operations during the import process. It is used to ensure that the correct sequence of events occurs and to handle any discrepancies or updates to the dUNL on the "burning" ledger.

Example JSON

{
  "LedgerEntryType": "ImportVLSequence",
  "Flags": 0,
  "ImportSequence": 2023102101,
  "PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy",
  "index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
}

Fields

A ImportVLSequence object has the following fields:

Import VL Sequence ID Format

The ID of a ImportVLSequence object is the [SHA-512Half][] of the following values, concatenated in order:

• The Import VL Sequence space key (0x0049)

• The Public Key of the Import Validator List

[Source]

(Added by the [Escrow amendment][].)

The Escrow object type represents a held payment of XAH or IOU waiting to be executed or canceled. An [EscrowCreate transaction][] creates an Escrow object in the ledger. A successful [EscrowFinish][] or [EscrowCancel][] transaction deletes the object.

If the Escrow object has a crypto-condition, the payment can only succeed if an EscrowFinish transaction provides the corresponding fulfillment that satisfies the condition. (The only supported crypto-condition type is PREIMAGE-SHA-256.) If the Escrow object has a FinishAfter time, the held payment can only execute after that time.

An Escrow object is associated with two addresses:

• The owner, who provides the XAH or IOU when creating the Escrow object. If the held payment is canceled, the XAH or IOU returns to the owner.

• The destination, where the XAH or IOU is paid when the held payment succeeds. The destination can be the same as the owner.

Example JSON

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "Amount": "10000",
    "CancelAfter": 545440232,
    "Condition": "A0258020A82A88B2DF843A54F58772E4A3861866ECDB4157645DD9AE528C1D3AEEDABAB6810120",
    "Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "DestinationTag": 23480,
    "FinishAfter": 545354132,
    "Flags": 0,
    "LedgerEntryType": "Escrow",
    "OwnerNode": "0000000000000000",
    "DestinationNode": "0000000000000000",
    "PreviousTxnID": "C44F2EB84196B9AD820313DBEBA6316A15C9A2D35787579ED172B87A30131DA7",
    "PreviousTxnLgrSeq": 28991004,
    "SourceTag": 11747,
    "index": "DC5F3851D8A1AB622F957761E5963BC5BD439D5C24AC6AD7AC4523F0640244AC"
}

Fields

An Escrow object has the following fields:

Escrow ID Format

The ID of an Escrow object is the [SHA-512Half][] of the following values, concatenated in order:

• The Escrow space key (0x0075)

• The AccountID of the sender of the [EscrowCreate transaction][] that created the Escrow object

• The Sequence number of the [EscrowCreate transaction][] that created the Escrow object If the EscrowCreate transaction used a Ticket, use the TicketSequence value instead.

The RippleState object type connects two accounts in a single currency. Conceptually, a RippleState object represents two trust lines between the accounts, one from each side. Each account can change the settings for its side of the RippleState object, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as a trust line that does not exist, so rippled deletes RippleState objects when their properties are entirely default.

High vs. Low Account

There can only be one RippleState object per currency for any given pair of accounts. Since no account is privileged in Xahau, a RippleState object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when decoded is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.

The "issuer" for the balance in a trust line depends on whether the balance is positive or negative. If a RippleState object shows a positive balance, the high account is the issuer. If the balance is negative, the low account is the issuer. Often, the issuer has its limit set to 0 and the other account has a positive limit, but this is not reliable because limits can change without affecting an existing balance.

Example JSON

Fields

A RippleState object has the following fields:

RippleState Flags

There are several options which can be either enabled or disabled for a trust line. These options can be changed with a [TrustSet transaction][]. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with lsf.

RippleState objects can have the following flag values:

Contributing to the Owner Reserve

If an account modifies a trust line to put it in a non-default state, then that trust line counts towards the account's owner reserve. In a RippleState object, the lsfLowReserve and lsfHighReserve flags indicate which account(s) are responsible for the owner reserve. The rippled server automatically sets these flags when it modifies a trust line.

The values that count towards a trust line's non-default state are as follows:

The lsfLowAuth and lsfHighAuth flags do not count against the default state, because they cannot be disabled.

The default state of the two No Ripple flags depends on the state of the lsfDefaultRipple flag in their corresponding AccountRoot objects. If Default Ripple is disabled (the default), then the default state of the lsfNoRipple flag is enabled for all of an account's trust lines. If an account enables Default Ripple, then the lsfNoRipple flag is disabled (rippling is enabled) for an account's trust lines by default.

Note: Prior to the introduction of the Default Ripple flag in rippled version 0.27.3 (March 10, 2015), the default state for all trust lines was with both No Ripple flags disabled (rippling enabled).

Fortunately, rippled uses lazy evaluation to calculate the owner reserve. This means that even if an account changes the default state of all its trust lines by changing the Default Ripple flag, that account's reserve stays the same initially. If an account modifies a trust line, rippled re-evaluates whether that individual trust line is in its default state and should contribute to the owner reserve.

RippleState ID Format

The ID of a RippleState object is the [SHA-512Half][] of the following values, concatenated in order:

• The RippleState space key (0x0072)

• The AccountID of the low account

• The AccountID of the high account

• The 160-bit currency code of the trust line(s)

(Added by the [NegativeUNL amendment][].)

The NegativeUNL object type contains the current status of the Negative UNL, a list of trusted validators currently believed to be offline.

Each ledger version contains at most one NegativeUNL object. If no validators are currently disabled or scheduled to be disabled, there is no NegativeUNL object in the ledger.

Example JSON

A NegativeUNL object has the following fields:

DisabledValidator Objects

Each DisabledValidator object represents one disabled validator. In JSON, a DisabledValidator object has one field, DisabledValidator, which in turn contains another object with the following fields:

NegativeUNL ID Format

The NegativeUNL object ID is the hash of the NegativeUNL space key (0x004E) only. This means that the ID of the NegativeUNL object in a ledger is always:

The Offer ledger entry describes an Offer to exchange currencies in Xahau's decentralized exchange. (In finance, this is more traditionally known as an order.) An [OfferCreate transaction][] only creates an Offer entry in the ledger when the Offer cannot be fully executed immediately by consuming other Offers already in the ledger.

An Offer can become unfunded through other activities in the network while remaining in the ledger. When processing transactions, the network automatically prunes any unfunded Offers that those transactions come across. (Otherwise, unfunded Offers remain because only transactions can change the ledger state.)

Example JSON

Fields

An Offer object has the following fields:

Offer Flags

There are several options that can be either enabled or disabled when an [OfferCreate transaction][] creates an offer object. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with lsf.

Offer objects can have the following flag values:

Offer ID Format

The ID of an Offer object is the [SHA-512Half][] of the following values, concatenated in order:

• The Offer space key (0x006F)

• The AccountID of the account placing the Offer

• The Sequence number of the [OfferCreate transaction][] that created the Offer.

  If the OfferCreate transaction used a Ticket, use the TicketSequence value instead.

A DepositPreauth object tracks a preauthorization from one account to another. [DepositPreauth transactions][] create these objects.

This has no effect on the processing of transactions unless the account that provided the preauthorization requires Deposit Authorization. In that case, the account that was preauthorized can send payments and other transactions directly to the account that provided the preauthorization. Preauthorizations are one-directional and have no effect on payments going the opposite direction.

Example JSON

Fields

A DepositPreauth object has the following fields:

DepositPreauth ID Format

The ID of a DepositPreauth object is the [SHA-512Half][] of the following values, concatenated in order:

• The DepositPreauth space key (0x0070)

• The AccountID of the owner of this object (the sender of the [DepositPreauth transaction][] that created this object; in other words, the one that granted the preauthorization)

• The AccountID of the preauthorized account (the Authorized field of the [DepositPreauth transaction][] that created this object; in other words, the one that received the preauthorization)

(Added by the [PayChan amendment][].)

The PayChannel object type represents a payment channel. Payment channels enable small, rapid off-ledger payments of XAH or IOU that can be later reconciled with the consensus ledger. A payment channel holds a balance of XAH or IOU that can only be paid out to a specific destination address until the channel is closed. Any unspent XAH or IOU is returned to the channel's owner (the source address that created and funded it) when the channel closes.

The [PaymentChannelCreate transaction][] type creates a PayChannel object. The [PaymentChannelFund][] and [PaymentChannelClaim transaction][] types modify existing PayChannel objects.

When a payment channel expires, at first it remains on the ledger, because only new transactions can modify ledger contents. Transaction processing automatically closes a payment channel when any transaction accesses it after the expiration. To close an expired channel and return the unspent XAH or IOU to the owner, some addresses must send a new PaymentChannelClaim or PaymentChannelFund transaction accessing the channel.

For an example of using payment channels, see the Payment Channels Tutorial.

Example JSON

Fields

A PayChannel object has the following fields:

Setting Channel Expiration

The Expiration field of a payment channel is the mutable expiration time, in contrast to the immutable expiration time represented by the CancelAfter field. The expiration of a channel is always considered relative to the close_time field of the previous ledger. The Expiration field is omitted when a PayChannel object is created. There are several ways the Expiration field of a PayChannel object can be updated, which can be summarized as follows: a channel's source address can set the Expiration of the channel freely as long as the channel always remains open at least SettleDelay seconds after the first attempt to close it.

Source Address

The source address can set the Expiration directly with the PaymentChannelFund transaction type. The new value must not be earlier than whichever of the following values is earliest:

• The current Expiration value (if one is set)

• The previous ledger's close time plus the SettleDelay of the channel

In other words, the source address can always make the Expiration later if an expiration is already set. The source can make an Expiration value earlier or set an Expiration if one isn't currently set, as long as the new value is at least SettleDelay seconds in the future. If the source address attempts to set an invalid Expiration date, the transaction fails with the temBAD_EXPIRATION error code.

The source address can also set the Expiration with the tfClose flag of the PaymentChannelClaim transaction type. If the flag is enabled, the ledger automatically sets the Expiration to whichever of the following values is earlier:

• The current Expiration value (if one is set)

• The previous ledger's close time plus the SettleDelay of the channel

The source address can remove the Expiration with the tfRenew flag of the PaymentChannelClaim transaction type.

Destination Address

The destination address cannot set the Expiration field. However, the destination address can use the PaymentChannelClaim's tfClose flag to close a channel immediately.

Other Addresses

If any other address attempts to set an Expiration field, the transaction fails with the tecNO_PERMISSION error code. However, if the channel is already expired, the transaction causes the channel to close and results in tesSUCCESS instead.

PayChannel ID Format

The ID of a PayChannel object is the [SHA-512Half][] of the following values, concatenated in order:

• The PayChannel space key (0x0078)

• The AccountID of the source account

• The AccountID of the destination account

• The Sequence number of the [PaymentChannelCreate transaction][] that created the channel If the PaymentChannelCreate transaction used a Ticket, use the TicketSequence value instead.

An AccountRoot ledger entry type describes a single account, its settings, and XAH balance.

Example JSON

Fields

An AccountRoot object has the following fields:

AccountRoot Flags

There are several options which can be either enabled or disabled for an account. These options can be changed with an [AccountSet transaction][]. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with lsf.

fAccountRoot objects can have the following flag values:

AccountRoot ID Format

The ID of an AccountRoot object is the [SHA-512Half][] of the following values, concatenated in order:

• The Account space key (0x0061)

• The AccountID of the account

(Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the LedgerHashes ledger object type.)

The LedgerHashes object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a transaction or pseudo-transaction.) The LedgerHashes objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.

There are two kinds of LedgerHashes object. Both types have the same fields. Each ledger version contains:

• Exactly one "recent history" LedgerHashes object

• A number of "previous history" LedgerHashes objects based on the current ledger index (that is, the length of the ledger history). Specifically, Xahau adds a new "previous history" object every 65536 ledger versions.

Note: As an exception, a new genesis ledger has no LedgerHashes objects at all, because it has no ledger history.

Example LedgerHashes object (trimmed for length):

A LedgerHashes object has the following fields:

Recent History LedgerHashes

There is exactly one LedgerHashes object of the "recent history" sub-type in every ledger after the genesis ledger. This object contains the identifying hashes of the most recent 256 ledger versions (or fewer, if the ledger history has less than 256 ledgers total) in the Hashes array. Whenever a new ledger is closed, part of the process of closing it involves updating the "recent history" object with the hash of the previous ledger version this ledger version is derived from (also known as this ledger version's parent ledger). When there are more than 256 hashes, the oldest one is removed.

Using the "recent history" LedgerHashes object of a given ledger, you can get the hash of any ledger index within the 256 ledger versions before the given ledger version.

Previous History LedgerHashes

The "previous history" LedgerHashes entries collectively contain the hash of every 256th ledger version (also called "flag ledgers") in the full history of the ledger. When the child of a flag ledger closes, the flag ledger's hash is added to the Hashes array of the newest "previous history" LedgerHashes object. Every 65536 ledgers, rippled creates a new LedgerHashes object, so that each "previous history" object has the hashes of 256 flag ledgers.

Note: The oldest "previous history" LedgerHashes object contains only 255 entries because the genesis ledger has a ledger index of 1, not 0.

LedgerHashes ID Formats

There are two formats for LedgerHashes object IDs, depending on whether the object is a "recent history" sub-type or a "previous history" sub-type.

The "recent history" LedgerHashes object has an ID that is the [SHA-512Half][] of the LedgerHashes space key (0x0073). In other words, the "recent history" always has the ID B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B.

The "previous history" LedgerHashes objects have an ID that is the [SHA-512Half][] of the following values, concatenated in order:

• The LedgerHashes space key (0x0073)

• The 32-bit [Ledger Index][] of a flag ledger in the object's Hashes array, divided by 65536.

  Tip: Dividing by 65536 keeps the most significant 16 bits, which are the same for all the flag ledgers listed in a "previous history" object, and only those ledgers. You can use this fact to look up the LedgerHashes object that contains the hash of any flag ledger.

(Added by the [MultiSign amendment][].)

The SignerList object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a signer list using a [SignerListSet transaction][].

Example JSON

Fields

A SignerList object has the following fields:

The SignerEntries may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys.

Signer Entry Object

Each member of the SignerEntries field is an object that describes that signer in the list. A Signer Entry has the following fields:

When processing a multi-signed transaction, the server looks up the Account values with respect to the ledger at the time of transaction execution. If the address does not correspond to a funded AccountRoot object, then only the master private key associated with that address can be used to produce a valid signature. If the account does exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.

{{currentpage.name}} Flags

(Added by the [MultiSignReserve amendment][].)

SignerList objects can have the following flag value:

Signer Lists and Reserves

A signer list contributes to its owner's reserve requirement.

The [MultiSignReserve amendment][] (enabled 2019-04-17) made it so each signer list counts as one object, regardless of how many members it has. As a result, the owner reserve associated with a new signer list is 2 XAH.

A signer list created before the [MultiSignReserve amendment][] itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with the signer list is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer object in the ledger. To update a signer list to use the new, reduced reserve, update the signer list by sending a [SignerListSet transaction][].

SignerList ID Format

The ID of a signer list object is the SHA-512Half of the following values, concatenated in order:

• The RippleState space key (0x0053)

• The AccountID of the owner of the signer list

• The SignerListID (currently always 0)