diff --git a/content/references/data-api.md b/content/references/data-api.md index d82b7d2e77..e21529266b 100644 --- a/content/references/data-api.md +++ b/content/references/data-api.md @@ -456,7 +456,7 @@ Optionally, you can provide the following query parameters: | `start` | String - [Timestamp][] | Filter results to this time and later. | | `end` | String - [Timestamp][] | Filter results to this time and earlier. | | `descending` | Boolean | If true, return results in reverse chronological order. Defaults to false. | -| `type` | String | Filter transactions to a specific [transaction type](reference-transaction-format.html). | +| `type` | String | Filter transactions to a specific transaction-types.html. | | `result` | String | Filter transactions for a specific [transaction result](reference-transaction-format.html#transaction-results). | | `binary` | Boolean | If true, return transactions in binary form. Defaults to false. | | `limit` | Integer | Maximum results per page. Defaults to 20. Cannot be more than 100. | @@ -3906,7 +3906,7 @@ Optionally, you can provide the following query parameters: | `end` | String - [Timestamp][] | End time of query range. Defaults to the current date. | | `min_sequence` | String | Minimum sequence number to query. | | `max_sequence` | String | Max sequence number to query. | -| `type` | String | Restrict results to a specified [transaction type](reference-transaction-format.html) | +| `type` | String | Restrict results to a specified transaction-types.html | | `result` | String | Restrict results to specified transaction result. | | `binary` | Boolean | Return results in binary format. | | `descending` | Boolean | If true, return results in reverse chronological order. Defaults to false. | @@ -5185,7 +5185,7 @@ A Payment Summary Object contains a reduced amount of information about a single ## Payment Objects [Payment Objects]: #payment-objects -In the Data API, a Payment Object represents an event where one account sent value to another account. This mostly lines up with XRP Ledger transactions of the `Payment` [transaction type](reference-transaction-format.html), except that the Data API does not consider a transaction to be a payment if the sending `Account` and the `Destination` account are the same, or if the transaction failed. +In the Data API, a Payment Object represents an event where one account sent value to another account. This mostly lines up with XRP Ledger transactions of the `Payment` transaction-types.html, except that the Data API does not consider a transaction to be a payment if the sending `Account` and the `Destination` account are the same, or if the transaction failed. Payment objects have the following fields: diff --git a/content/references/rippled-api/admin-rippled-methods/key-generation-methods/wallet_propose.md b/content/references/rippled-api/admin-rippled-methods/key-generation-methods/wallet_propose.md index 41764d003f..ecf4795784 100644 --- a/content/references/rippled-api/admin-rippled-methods/key-generation-methods/wallet_propose.md +++ b/content/references/rippled-api/admin-rippled-methods/key-generation-methods/wallet_propose.md @@ -1,7 +1,7 @@ # wallet_propose [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/WalletPropose.cpp "Source") -Use the `wallet_propose` method to generate a key pair and XRP Ledger address. This command only generates key and address values, and does not affect the XRP Ledger itself in any way. To become a funded address stored in the ledger, the address must [receive a Payment transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](reserves.html). +Use the `wallet_propose` method to generate a key pair and XRP Ledger address. This command only generates key and address values, and does not affect the XRP Ledger itself in any way. To become a funded address stored in the ledger, the address must [receive a Payment transaction](accounts.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](reserves.html). *The `wallet_propose` request is an [admin command](#connecting-to-rippled) that cannot be run by unprivileged users!* (This command is restricted to protect against people sniffing network traffic for account secrets, since admin commands are not usually transmitted over the outside network.) @@ -83,7 +83,7 @@ You must provide **at most one** of the following fields: `passphrase`, `seed`, #### Specifying a Seed -For most cases, you should use a seed value generated from a strong source of randomness. Anyone who knows the seed value for an address has full power to [send transactions signed by that address](reference-transaction-format.html#authorizing-transactions). Generally, running this command with no parameters is a good way to generate a random seed. +For most cases, you should use a seed value generated from a strong source of randomness. Anyone who knows the seed value for an address has full power to [send transactions signed by that address](transaction-basics.html#authorizing-transactions). Generally, running this command with no parameters is a good way to generate a random seed. Cases where you would specify a known seed include: @@ -182,7 +182,7 @@ In addition to using it as a regular key pair, you can also use it as a member o For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html) -For more information about multi-signing and signer lists, see [Multi-Signing](reference-transaction-format.html#multi-signing). +For more information about multi-signing and signer lists, see [Multi-Signing](multi-signing.html). ### Possible Errors diff --git a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_request.md b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_request.md index c90139193f..82cba2ae45 100644 --- a/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_request.md +++ b/content/references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/ledger_request.md @@ -164,9 +164,9 @@ When the server is in the progress of fetching a ledger, but has not yet finishe |:----------------------------|:-----------------|:----------------------------| | `hash` | String | (May be omitted) The [Hash][] of the requested ledger, if the server knows it. | | `have_header` | Boolean | Whether the server has the header section of the requested ledger. | -| `have_state` | Boolean | (May be omitted) Whether the server has the [account-state section](reference-ledger-format.html#tree-format) of the requested ledger. | +| `have_state` | Boolean | (May be omitted) Whether the server has the [account-state section](ledger-data-formats.html#tree-format) of the requested ledger. | | `have_transactions` | Boolean | (May be omitted) Whether the server has the transaction section of the requested ledger. | -| `needed_state_hashes` | Array of Strings | (May be omitted) Up to 16 hashes of objects in the [state tree](reference-ledger-format.html#tree-format) that the server still needs to retrieve. | +| `needed_state_hashes` | Array of Strings | (May be omitted) Up to 16 hashes of objects in the [state tree](ledger-data-formats.html#tree-format) that the server still needs to retrieve. | | `needed_transaction_hashes` | Array of Strings | (May be omitted) Up to 16 hashes of objects in the transaction tree that the server still needs to retrieve. | | `peers` | Number | How many peers the server is querying to find this ledger. | | `timeouts` | Number | Number of times fetching this ledger has timed out so far. | diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md index bd681cc009..a350472b8b 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/amendments.md @@ -41,7 +41,7 @@ Each member of the `Majorities` field, if it is present, is an object with one f | Name | JSON Type | [Internal Type][] | Description | |-------------------|-----------|-------------------|-------------| | `Amendment` | String | Hash256 | The Amendment ID of the pending amendment. | -| `CloseTime` | Number | UInt32 | The [`close_time` field](#header-format) of the ledger version where this amendment most recently gained a majority. | +| `CloseTime` | Number | UInt32 | The [`close_time` field](ledger-header.html) of the ledger version where this amendment most recently gained a majority. | In the [amendment process](amendments.html#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. diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md index 3c1cd82165..93eb1a572c 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/paychannel.md @@ -9,7 +9,7 @@ The [PaymentChannelCreate transaction][] type creates a `PayChannel` object. The 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 XRP to the owner, some address must send a new PaymentChannelClaim or PaymentChannelFund transaction accessing the channel. -For an example of using payment channels, see the [Payment Channels Tutorial](tutorial-paychan.html). +For an example of using payment channels, see the [Payment Channels Tutorial](use-payment-channels.html). ## Example {{currentpage.name}} JSON @@ -51,15 +51,15 @@ A `PayChannel` object has the following fields: | `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. | | `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. | | `Flags` | Number | UInt32 | A bit-map of boolean flags enabled for this payment channel. Currently, the protocol defines no flags for `PayChannel` objects. | -| `Expiration` | Number | UInt32 | _(Optional)_ The mutable expiration time for this payment channel, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). The channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](#header-format). See [Setting Channel Expiration](#setting-channel-expiration) for more details. | -| `CancelAfter` | Number | UInt32 | _(Optional)_ The immutable expiration time for this payment channel, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). This channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](#header-format). This is optionally set by the transaction that created the channel, and cannot be changed. | +| `Expiration` | Number | UInt32 | _(Optional)_ The mutable expiration time for this payment channel, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). The channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](ledger-header.html). See [Setting Channel Expiration](#setting-channel-expiration) for more details. | +| `CancelAfter` | Number | UInt32 | _(Optional)_ The immutable expiration time for this payment channel, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). This channel is expired if this value is present and smaller than the previous ledger's [`close_time` field](ledger-header.html). This is optionally set by the transaction that created the channel, and cannot be changed. | | `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this payment channel, such as a hosted recipient at the owner's address. | | `DestinationTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. | ## 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](#header-format) 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. +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](ledger-header.html) 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 diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md index 6e3b389a94..2d257b689b 100644 --- a/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md +++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_info.md @@ -173,7 +173,7 @@ The response follows the [standard format][], with the result containing the req | `Field` | Type | Description | |:-----------------------|:--------|:------------------------------------------| | `account_data` | Object | The [AccountRoot ledger object](reference-ledger-format.html#accountroot) with this account's information, as stored in the ledger. | -| `signer_lists` | Array | (Omitted unless the request specified `signer_lists` and at least one SignerList is associated with the account.) Array of [SignerList ledger objects](reference-ledger-format.html#signerlist) associated with this account for [Multi-Signing](reference-transaction-format.html#multi-signing). Since an account can own at most one SignerList, this array must have exactly one member if it is present. [New in: rippled 0.31.0][] | +| `signer_lists` | Array | (Omitted unless the request specified `signer_lists` and at least one SignerList is associated with the account.) Array of [SignerList ledger objects](reference-ledger-format.html#signerlist) associated with this account for [Multi-Signing](multi-signing.html). Since an account can own at most one SignerList, this array must have exactly one member if it is present. [New in: rippled 0.31.0][] | | `ledger_current_index` | Integer | (Omitted if `ledger_index` is provided instead) The sequence number of the most-current ledger, which was used when retrieving this information. The information does not contain any changes from ledgers newer than this one. | | `ledger_index` | Integer | (Omitted if `ledger_current_index` is provided instead) The sequence number of the ledger used when retrieving this information. The information does not contain any changes from ledgers newer than this one. | | `queue_data` | Object | (Omitted unless `queue` specified as `true` and querying the current open ledger.) Information about [queued transactions](transaction-cost.html#queued-transactions) sent by this account. This information describes the state of the local `rippled` server, which may be different from other servers in the consensus network. Some fields may be omitted because the values are calculated "lazily" by the queuing mechanism. | diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md index 64cf26f0cf..25cc8d21ad 100644 --- a/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md +++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_objects.md @@ -9,7 +9,7 @@ The types of objects that may appear in the `account_objects` response for an ac - [Offer objects](reference-ledger-format.html#offer) for orders that are currently live, unfunded, or expired but not yet removed. (See [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer) for more information.) - [RippleState objects](reference-ledger-format.html#ripplestate) for trust lines where this account's side is not in the default state. -- The account's [SignerList](reference-ledger-format.html#signerlist), if the account has [multi-signing](reference-transaction-format.html#multi-signing) enabled. +- The account's [SignerList](reference-ledger-format.html#signerlist), if the account has [multi-signing](multi-signing.html) enabled. - [Escrow objects](reference-ledger-format.html#escrow) for held payments that have not yet been executed or canceled. - [PayChannel objects](reference-ledger-format.html#paychannel) for open payment channels. - [Check objects](reference-ledger-format.html#check) for pending checks. diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md index 78ec55ffdb..95790a6659 100644 --- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md +++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md @@ -58,11 +58,11 @@ The full list of parameters recognized by this method is as follows: |:------------------------|:---------------------------|:----------------------| | `index` | String | _(Optional)_ Specify the unique identifier of a single ledger entry to retrieve. | | `account_root` | String - [Address][] | _(Optional)_ Specify an [AccountRoot object](reference-ledger-format.html#accountroot) to retrieve. | -| `directory` | Object or String | _(Optional)_ Specify a [DirectoryNode](reference-ledger-format.html#directorynode). (DirectoryNode objects each contain a list of IDs for things contained in them.) If a string, interpret as the [unique index](reference-ledger-format.html#tree-format) to the directory, in hex. If an object, requires either `dir_root` or `owner` as a sub-field, plus optionally a `sub_index` sub-field. | +| `directory` | Object or String | _(Optional)_ Specify a [DirectoryNode](reference-ledger-format.html#directorynode). (DirectoryNode objects each contain a list of IDs for things contained in them.) If a string, interpret as the [unique index](ledger-data-formats.html#tree-format) to the directory, in hex. If an object, requires either `dir_root` or `owner` as a sub-field, plus optionally a `sub_index` sub-field. | | `directory.sub_index` | Unsigned Integer | _(Optional)_ If provided, jumps to a later "page" of the [Directory](reference-ledger-format.html#directorynode). | | `directory.dir_root` | String | (Required if `directory` is specified as an object and `directory.owner` is not provided) Unique index identifying the directory to retrieve, as a hex string. | | `directory.owner` | String | (Required if `directory` is specified as an object and `directory.dir_root` is not provided) Unique address of the account associated with this directory | -| `offer` | Object or String | _(Optional)_ Specify an [Offer object](reference-ledger-format.html#offer) to retrieve. If a string, interpret as the [unique index](reference-ledger-format.html#tree-format) to the Offer. If an object, requires the sub-fields `account` and `seq` to uniquely identify the offer. | +| `offer` | Object or String | _(Optional)_ Specify an [Offer object](reference-ledger-format.html#offer) to retrieve. If a string, interpret as the [unique index](ledger-data-formats.html#tree-format) to the Offer. If an object, requires the sub-fields `account` and `seq` to uniquely identify the offer. | | `offer.account` | String - [Address][] | (Required if `offer` specified) The account that placed the offer. | | `offer.seq` | Unsigned Integer | (Required if `offer` specified) The sequence number of the transaction that created the Offer object. | | `ripple_state` | Object | _(Optional)_ Object specifying the RippleState (trust line) object to retrieve. The `accounts` and `currency` sub-fields are required to uniquely specify the RippleState entry to retrieve. | diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/sign_for.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/sign_for.md index 9ab7c8d4ec..50605ec094 100644 --- a/content/references/rippled-api/public-rippled-methods/transaction-methods/sign_for.md +++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/sign_for.md @@ -1,7 +1,7 @@ # sign_for [[Source]
](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SignFor.cpp "Source") -The `sign_for` command provides one signature for a [multi-signed transaction](reference-transaction-format.html#multi-signing). +The `sign_for` command provides one signature for a [multi-signed transaction](multi-signing.html). This command requires the [MultiSign amendment](known-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][] diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md index b55c8d7db8..5971456954 100644 --- a/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md +++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/submit.md @@ -16,7 +16,7 @@ A submit-only request includes the following parameters: | `Field` | Type | Description | |:------------|:--------|:-----------------------------------------------------| -| `tx_blob` | String | Hex representation of the signed transaction to submit. This can be a [multi-signed transaction](reference-transaction-format.html#multi-signing). | +| `tx_blob` | String | Hex representation of the signed transaction to submit. This can be a [multi-signed transaction](multi-signing.html). | | `fail_hard` | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers | ### Request Format @@ -60,7 +60,7 @@ submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534 ## Sign-and-Submit Mode -This mode signs a transaction and immediately submits it. This mode is intended to be used for testing. You cannot use this mode for [multi-signed transactions](reference-transaction-format.html#multi-signing). +This mode signs a transaction and immediately submits it. This mode is intended to be used for testing. You cannot use this mode for [multi-signed transactions](multi-signing.html). You can provide the secret key used to sign the transaction in the following ways: diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/submit_multisigned.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/submit_multisigned.md index ca800a58fc..475a7abb0b 100644 --- a/content/references/rippled-api/public-rippled-methods/transaction-methods/submit_multisigned.md +++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/submit_multisigned.md @@ -1,7 +1,7 @@ # submit_multisigned [[Source]
](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SubmitMultiSigned.cpp "Source") -The `submit_multisigned` command applies a [multi-signed](reference-transaction-format.html#multi-signing) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).) +The `submit_multisigned` command applies a [multi-signed](multi-signing.html) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).) This command requires the [MultiSign amendment](known-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][] diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md index 7912497df5..438005cd1d 100644 --- a/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md +++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/tx.md @@ -186,7 +186,7 @@ An example of a successful response: -The response follows the [standard format][], with a successful result containing the fields of the [Transaction object](reference-transaction-format.html) as well as the following additional fields: +The response follows the [standard format][], with a successful result containing the fields of the [Transaction object](transaction-formats.html) as well as the following additional fields: | `Field` | Type | Description | |:---------------|:-----------------|:-----------------------------------------| @@ -195,7 +195,7 @@ The response follows the [standard format][], with a successful result containin | `ledger_index` | Unsigned Integer | The sequence number of the ledger that includes this transaction. | | `meta` | Object | Various metadata about the transaction. | | `validated` | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. | -| (Various) | (Various) | Other fields from the [Transaction object](reference-transaction-format.html) | +| (Various) | (Various) | Other fields from the [Transaction object](transaction-formats.html) | ## Possible Errors diff --git a/content/references/rippled-api/transaction-formats/transaction-common-fields.md b/content/references/rippled-api/transaction-formats/transaction-common-fields.md index 84321eb5ed..202af0bda0 100644 --- a/content/references/rippled-api/transaction-formats/transaction-common-fields.md +++ b/content/references/rippled-api/transaction-formats/transaction-common-fields.md @@ -45,7 +45,7 @@ Some fields can be automatically filled in before a transaction is signed, eithe For a production system, we recommend _not_ leaving these fields to be filled by the server. For example, if transaction costs become high due to a temporary spike in network load, you may want to wait for the cost to decrease before sending some transactions, instead of paying the temporarily-high cost. -The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in. +The [`Paths` field](payment.html#paths) of the [Payment transaction][] type can also be automatically filled in. ## Flags Field diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md index ee76b3a1d1..81d7273606 100644 --- a/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md +++ b/content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md @@ -11,7 +11,7 @@ For the most part, transactions with `tec` codes take no action other than to de | `tecCLAIM` | 100 | Unspecified failure, with transaction cost destroyed. | | `tecCRYPTOCONDITION_ERROR` | 146 | This [EscrowCreate][] or [EscrowFinish][] transaction contained a malformed or mismatched crypto-condition. | | `tecDIR_FULL` | 121 | The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger. | -| `tecDST_TAG_NEEDED` | 143 | The [Payment](#payment) transaction omitted a destination tag, but the destination account has the `lsfRequireDestTag` flag enabled. [New in: rippled 0.28.0][] | +| `tecDST_TAG_NEEDED` | 143 | The [Payment transaction][] omitted a destination tag, but the destination account has the `lsfRequireDestTag` flag enabled. [New in: rippled 0.28.0][] | | `tecEXPIRED` | 148 | The transaction tried to create an object (such as an Offer or a Check) whose provided Expiration time has already passed. | | `tecFAILED_PROCESSING` | 105 | An unspecified error occurred when processing the transaction. | | `tecFROZEN` | 137 | The [OfferCreate transaction][] failed because one or both of the assets involved are subject to a [global freeze](freezes.html). | diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md index ac41bc4e8c..993108fa6e 100644 --- a/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md +++ b/content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md @@ -8,7 +8,7 @@ These codes indicate that the transaction failed and was not included in a ledge |:-----------------------|:----------------------------------------------------| | `tefALREADY` | The same exact transaction has already been applied. | | `tefBAD_ADD_AUTH` | **DEPRECATED.** | -| `tefBAD_AUTH` | The key used to sign this account is not authorized to modify this account. (It could be authorized if the account had the same key set as the [Regular Key](#setregularkey).) | +| `tefBAD_AUTH` | The key used to sign this account is not authorized to modify this account. (It could be authorized if the account had the same key set as the [Regular Key](cryptographic-keys.html).) | | `tefBAD_AUTH_MASTER` | The single signature provided to authorize this transaction does not match the master key, but no regular key is associated with this address. | | `tefBAD_LEDGER` | While processing the transaction, the ledger was discovered in an unexpected state. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. | | `tefBAD_QUORUM` | The transaction was [multi-signed](#multi-signing), but the total weights of all included signatures did not meet the quorum. | diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md index 2c36cb94c9..48b91ab09a 100644 --- a/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md +++ b/content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md @@ -7,32 +7,32 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | Code | Explanation | |:-----------------------------|:----------------------------------------------| | `temBAD_AMOUNT` | An amount specified by the transaction (for example the destination `Amount` or `SendMax` values of a [Payment](#payment)) was invalid, possibly because it was a negative number. | -| `temBAD_AUTH_MASTER` | The key used to sign this transaction does not match the master key for the account sending it, and the account does not have a [Regular Key](#setregularkey) set. | +| `temBAD_AUTH_MASTER` | The key used to sign this transaction does not match the master key for the account sending it, and the account does not have a [Regular Key](cryptographic-keys.html) set. | | `temBAD_CURRENCY` | The transaction improperly specified a currency field. See [Specifying Currency Amounts][Currency Amount] for the correct format. | | `temBAD_EXPIRATION` | The transaction improperly specified an expiration value, for example as part of an [OfferCreate transaction][]. Alternatively, the transaction did not specify a required expiration value, for example as part of an [EscrowCreate transaction][]. | | `temBAD_FEE` | The transaction improperly specified its `Fee` value, for example by listing a non-XRP currency or some negative amount of XRP. | | `temBAD_ISSUER` | The transaction improperly specified the `issuer` field of some currency included in the request. | | `temBAD_LIMIT` | The [TrustSet transaction][] improperly specified the `LimitAmount` value of a trustline. | | `temBAD_OFFER` | The [OfferCreate transaction][] specifies an invalid offer, such as offering to trade XRP for itself, or offering a negative amount. | -| `temBAD_PATH` | The [Payment](#payment) transaction specifies one or more [Paths](#paths) improperly, for example including an issuer for XRP, or specifying an account differently. | -| `temBAD_PATH_LOOP` | One of the [Paths](#paths) in the [Payment](#payment) transaction was flagged as a loop, so it cannot be processed in a bounded amount of time. | -| `temBAD_SEND_XRP_LIMIT` | The [Payment](#payment) transaction used the [tfLimitQuality](#limit-quality) flag in a direct XRP-to-XRP payment, even though XRP-to-XRP payments do not involve any conversions. | -| `temBAD_SEND_XRP_MAX` | The [Payment](#payment) transaction included a `SendMax` field in a direct XRP-to-XRP payment, even though sending XRP should never require SendMax. (XRP is only valid in SendMax if the destination `Amount` is not XRP.) | -| `temBAD_SEND_XRP_NO_DIRECT` | The [Payment](#payment) transaction used the [tfNoDirectRipple](#payment-flags) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments are always direct. | -| `temBAD_SEND_XRP_PARTIAL` | The [Payment](#payment) transaction used the [tfPartialPayment](#partial-payments) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments should always deliver the full amount. | -| `temBAD_SEND_XRP_PATHS` | The [Payment](#payment) transaction included `Paths` while sending XRP, even though XRP-to-XRP payments should always be direct. | +| `temBAD_PATH` | The [Payment transaction][] specifies one or more [Paths](paths.html) improperly, for example including an issuer for XRP, or specifying an account differently. | +| `temBAD_PATH_LOOP` | One of the [Paths](paths.html) in the [Payment transaction][] was flagged as a loop, so it cannot be processed in a bounded amount of time. | +| `temBAD_SEND_XRP_LIMIT` | The [Payment transaction][] used the [tfLimitQuality](payment.html#limit-quality) flag in a direct XRP-to-XRP payment, even though XRP-to-XRP payments do not involve any conversions. | +| `temBAD_SEND_XRP_MAX` | The [Payment transaction][] included a `SendMax` field in a direct XRP-to-XRP payment, even though sending XRP should never require SendMax. (XRP is only valid in SendMax if the destination `Amount` is not XRP.) | +| `temBAD_SEND_XRP_NO_DIRECT` | The [Payment transaction][] used the [tfNoDirectRipple](payment.html#payment-flags) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments are always direct. | +| `temBAD_SEND_XRP_PARTIAL` | The [Payment transaction][] used the [tfPartialPayment](#partial-payments) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments should always deliver the full amount. | +| `temBAD_SEND_XRP_PATHS` | The [Payment transaction][] included `Paths` while sending XRP, even though XRP-to-XRP payments should always be direct. | | `temBAD_SEQUENCE` | The transaction is references a sequence number that is higher than its own `Sequence` number, for example trying to cancel an offer that would have to be placed after the transaction that cancels it. | | `temBAD_SIGNATURE` | The signature to authorize this transaction is either missing, or formed in a way that is not a properly-formed signature. (See [tecNO_PERMISSION](#tec-codes) for the case where the signature is properly formed, but not authorized for this account.) | | `temBAD_SRC_ACCOUNT` | The `Account` on whose behalf this transaction is being sent (the "source account") is not a properly-formed [account](accounts.html) address. | | `temBAD_TRANSFER_RATE` | The [`TransferRate` field of an AccountSet transaction](#transferrate) is not properly formatted or out of the acceptable range. | | `temDST_IS_SRC` | The transaction improperly specified a destination address as the `Account` sending the transaction. This includes trust lines (where the destination address is the `issuer` field of `LimitAmount`) and payment channels (where the destination address is the `Destination` field). | -| `temDST_NEEDED` | The transaction improperly omitted a destination. This could be the `Destination` field of a [Payment](#payment) transaction, or the `issuer` sub-field of the `LimitAmount` field fo a `TrustSet` transaction. | +| `temDST_NEEDED` | The transaction improperly omitted a destination. This could be the `Destination` field of a [Payment transaction][], or the `issuer` sub-field of the `LimitAmount` field fo a `TrustSet` transaction. | | `temINVALID` | The transaction is otherwise invalid. For example, the transaction ID may not be the right format, the signature may not be formed properly, or something else went wrong in understanding the transaction. | -| `temINVALID_FLAG` | The transaction includes a [Flag](#flags) that does not exist, or includes a contradictory combination of flags. | +| `temINVALID_FLAG` | The transaction includes a [Flag](transaction-common-fields.html#flags-field) that does not exist, or includes a contradictory combination of flags. | | `temMALFORMED` | Unspecified problem with the format of the transaction. | | `temREDUNDANT` | The transaction would do nothing; for example, it is sending a payment directly to the sending account, or creating an offer to buy and sell the same currency from the same issuer. | | `temREDUNDANT_SEND_MAX` | [Removed in: rippled 0.28.0][] | -| `temRIPPLE_EMPTY` | The [Payment](#payment) transaction includes an empty `Paths` field, but paths are necessary to complete this payment. | +| `temRIPPLE_EMPTY` | The [Payment transaction][] includes an empty `Paths` field, but paths are necessary to complete this payment. | | `temBAD_WEIGHT` | The [SignerListSet transaction][] includes a `SignerWeight` that is invalid, for example a zero or negative value. | | `temBAD_SIGNER` | The [SignerListSet transaction][] includes a signer who is invalid. For example, there may be duplicate entries, or the owner of the SignerList may also be a member. | | `temBAD_QUORUM` | The [SignerListSet transaction][] has an invalid `SignerQuorum` value. Either the value is not greater than zero, or it is more than the sum of all signers in the list. | diff --git a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md index b813a07809..216517b776 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md @@ -63,7 +63,7 @@ The available AccountSet flags are: | asfAccountTxnID | 5 | (None) | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) | | asfDefaultRipple | 8 | lsfDefaultRipple | Enable [rippling](rippling.html) on this account's trust lines by default. [New in: rippled 0.27.3][] | | asfDepositAuth | 9 | lsfDepositAuth | Enable [Deposit Authorization](depositauth.html) on this account. _(Requires the [DepositAuth amendment](known-amendments.html#depositauth).)_ | -| asfDisableMaster | 4 | lsfDisableMaster | Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](#setregularkey) or a [Signer List](#signerlistset). | +| asfDisableMaster | 4 | lsfDisableMaster | Disallow use of the master key. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](cryptographic-keys.html) or a [Signer List](#signerlistset). | | asfDisallowXRP | 3 | lsfDisallowXRP | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) | | asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](freezes.html) all assets issued by this account. | | asfNoFreeze | 6 | lsfNoFreeze | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](freezes.html). This flag can never be disabled after being enabled. | @@ -72,7 +72,7 @@ The available AccountSet flags are: To enable the `asfDisableMaster` or `asfNoFreeze` flags, you must [authorize the transaction](#authorizing-transactions) by signing it with the master key. You cannot use a regular key or a multi-signature. [New in: rippled 0.28.0][] -The following [Transaction flags](#flags), specific to the AccountSet transaction type, serve the same purpose, but are discouraged: +The following [Transaction flags](transaction-common-fields.html#flags-field), specific to the AccountSet transaction type, serve the same purpose, but are discouraged: | Flag Name | Hex Value | Decimal Value | Replaced by AccountSet Flag | |:------------------|:-----------|:--------------|:----------------------------| diff --git a/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md b/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md index edbdc1e38a..1dab2440c0 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/offercreate.md @@ -38,7 +38,7 @@ For more information about how Offers work, see [Offers](offers.html). ## OfferCreate Flags -Transactions of the OfferCreate type support additional values in the [`Flags` field](#flags), as follows: +Transactions of the OfferCreate type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows: | Flag Name | Hex Value | Decimal Value | Description | |:--------------------|:-----------|:--------------|:--------------------------| diff --git a/content/references/rippled-api/transaction-formats/transaction-types/payment.md b/content/references/rippled-api/transaction-formats/transaction-types/payment.md index 32e6e7baca..cfaaa6f9d5 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/payment.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/payment.md @@ -68,7 +68,7 @@ For more information, see [Paths](paths.html). ## Payment Flags -Transactions of the Payment type support additional values in the [`Flags` field](#flags), as follows: +Transactions of the Payment type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows: | Flag Name | Hex Value | Decimal Value | Description | |:-----------------|:-----------|:--------------|:-----------------------------| diff --git a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md index 06a6f041c4..39806e0474 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/paymentchannelclaim.md @@ -50,7 +50,7 @@ The **destination address** of a channel can: ## PaymentChannelClaim Flags -Transactions of the PaymentChannelClaim type support additional values in the [`Flags` field](#flags), as follows: +Transactions of the PaymentChannelClaim type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows: | Flag Name | Hex Value | Decimal Value | Description | |:----------|:-----------|:--------------|:------------------------------------| diff --git a/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md b/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md index 93f50b65ca..8c8144d953 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/signerlistset.md @@ -49,7 +49,7 @@ You cannot create a SignerList such that the SignerQuorum could never be met. Th You can create, update, or remove a SignerList using the master key, regular key, or the current SignerList, if those methods of signing transactions are available. -You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the [`lsfDisableMaster` flag](accountroot.html#accountroot-flags) enabled) and the account does not have a [Regular Key](#setregularkey) configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [`tecNO_ALTERNATIVE_KEY`](#tec-codes). +You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (it has the [`lsfDisableMaster` flag](accountroot.html#accountroot-flags) enabled) and the account does not have a [Regular Key](cryptographic-keys.html) configured, then you cannot delete the SignerList from the account. Instead, the transaction fails with the error [`tecNO_ALTERNATIVE_KEY`](#tec-codes). {% include '_snippets/rippled-api-links.md' %} diff --git a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md index e94550c0e0..9f2bf46c4e 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md @@ -37,7 +37,7 @@ Create or modify a trust line linking two accounts. ## TrustSet Flags -Transactions of the TrustSet type support additional values in the [`Flags` field](#flags), as follows: +Transactions of the TrustSet type support additional values in the [`Flags` field](transaction-common-fields.html#flags-field), as follows: | Flag Name | Hex Value | Decimal Value | Description | |:----------------|:-----------|:--------------|:------------------------------|