ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Set up rippled api links include

Browse Source
This commit is contained in:
mDuo13
2018-05-03 18:23:39 -07:00
parent b606735efd
commit 23f73a38a1
33 changed files with 169 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
content/_snippets/rippled-api-links.md Normal file
View File

@@ -0,0 +1,87 @@
<!-- TODO: update all the local links with their new locations -->
[Currency Amount]: reference-rippled-api-conventions.html#specifying-currency-amounts
[XRP, in drops]: reference-rippled-api-conventions.html#specifying-currency-amounts
[drops of XRP]: reference-rippled-api-conventions.html#specifying-currency-amounts
[Currency Code]: reference-rippled-api-conventions.html#currency-codes
[Address]: reference-rippled-api-conventions.html#addresses
[Hash]: reference-rippled-api-conventions.html#hashes
[Sequence Number]: reference-rippled-api-conventions.html#account-sequence
[Ledger Index]: reference-rippled-api-conventions.html#ledger-index
[universal error types]: reference-rippled-api-conventions.html#universal-errors
[Specifying Time]: reference-rippled-api-conventions.html#time
[base58]: https://en.wikipedia.org/wiki/Base58
[RFC-1751]: https://tools.ietf.org/html/rfc1751
[hexadecimal]: https://en.wikipedia.org/wiki/Hexadecimal
[admin command]: reference-rippled-intro.html#admin-connections
[standard format]: reference-rippled-intro.html#response-formatting
[seconds since the Ripple Epoch]: reference-rippled-api-conventions.html#time
[result code]: reference-transaction-results.html
[Specifying Ledgers]: reference-rippled-api-conventions.html#specifying-ledgers
[Marker]: reference-rippled-api-conventions.html#markers-and-pagination
[Interledger Protocol]: https://interledger.org/
[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-03
{% set api_methods = [
"account_channels",
"account_currencies",
"account_info",
"account_lines",
"account_objects",
"account_offers",
"account_tx",
"book_offers",
"can_delete",
"channel_authorize",
"channel_verify",
"connect",
"consensus_info",
"feature",
"fee",
"fetch_info",
"gateway_balances",
"get_counts",
"json",
"ledger",
"ledger_accept",
"ledger_cleaner",
"ledger_closed",
"ledger_current",
"ledger_data",
"ledger_entry",
"ledger_request",
"log_level",
"logrotate",
"noripple_check",
"path_find",
"peers",
"ping",
"print",
"random",
"ripple_path_find",
"server_info",
"server_state",
"sign",
"sign_for",
"stop",
"submit",
"submit_multisigned",
"subscribe",
"transaction_entry",
"tx",
"tx_history",
"unsubscribe",
"validation_create",
"validation_seed",
"validator_list_sites",
"validators",
"wallet_propose"
] %}
{% for method in api_methods %}
[{{method}} method]: {{method|lower}}.html
[{{method}} command]: {{method|lower}}.html
{% endfor %}

17
content/_snippets/tx-type-links.md
View File

@@ -21,20 +21,15 @@
"SetFee"
] %}
{% if currentpage.html == "reference-transaction-format.html" %}
{% set basepage = "" %}
{% else %}
{% set basepage = "reference-transaction-format.html" %}
{% endif %}
{% for tx in txtypes %}
[{{tx}}]: {{basepage}}#{{tx|lower}}
[{{tx}} transaction]: {{basepage}}#{{tx|lower}}
[{{tx}} transactions]: {{basepage}}#{{tx|lower}}
[{{tx}}]: {{tx|lower}}.html
[{{tx}} transaction]: {{tx|lower}}.html
[{{tx}} transactions]: {{tx|lower}}.html
{% endfor %}
{% for tx in pstxtypes %}
[{{tx}}]: {{basepage}}#{{tx|lower}}
[{{tx}} pseudo-transaction]: {{basepage}}#{{tx|lower}}
[{{tx}} pseudo-transactions]: {{basepage}}#{{tx|lower}}
[{{tx}}]: {{tx|lower}}.html
[{{tx}} pseudo-transaction]: {{tx|lower}}.html
[{{tx}} pseudo-transactions]: {{tx|lower}}.html
{% endfor %}

2
content/_snippets/wait-for-validation.md
View File

@@ -1,3 +1,3 @@
On the live network or the Ripple Test Net, you can wait 4-7 seconds for the ledger to close automatically.
If you're running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger.
If you're running `rippled` in stand-alone mode, use the [ledger_accept method][] to manually close the ledger.

2
content/concepts/complex-payment-types/checks.md
View File

@@ -81,7 +81,7 @@ Checks require `rippled` v0.90.0 or later. The Checks amendment gained support o
<!-- {***TODO:*** update this with the...other pseudo-transaction that will enable this amendment after two weeks with majority support? } -->
When not using the production XRP Ledger, you can check the status of the Checks amendment using the [`feature` command](reference-rippled.html#feature).
When not using the production XRP Ledger, you can check the status of the Checks amendment using the [feature method][].
## Further Reading

2
content/concepts/complex-payment-types/escrow.md
View File

@@ -48,7 +48,7 @@ When testing in [stand-alone mode](concept-stand-alone-mode.html), you can force
[features]
Escrow
You can check the status of the Escrow amendment using the [`feature` command](reference-rippled.html#feature).
You can check the status of the Escrow amendment using the [feature method][].
## EscrowFinish Transaction Cost

6
content/concepts/complex-payment-types/partial-payments.md
View File

@@ -57,9 +57,9 @@ You can find the `delivered_amount` field in the following places:
| API | Method | Field |
|-----|--------|-------|
| [JSON-RPC / WebSocket][] | [`account_tx` command](reference-rippled.html#account-tx) | `result.transactions` array members' `meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [`tx` command](reference-rippled.html#tx) | `result.meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [`transaction_entry` command](reference-rippled.html#transaction-entry) | `result.metadata.delivered_amount` |
| [JSON-RPC / WebSocket][] | [account_tx method][] | `result.transactions` array members' `meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [tx method][] | `result.meta.delivered_amount` |
| [JSON-RPC / WebSocket][] | [transaction_entry method][] | `result.metadata.delivered_amount` |
| [RippleAPI][] | [`getTransaction` method](reference-rippleapi.html#gettransaction) | `outcome.deliveredAmount` |
| [RippleAPI][] | [`getTransactions` method](reference-rippleapi.html#gettransactions) | array members' `outcome.deliveredAmount` |

2
content/concepts/consensus-network/amendments.md
View File

@@ -58,7 +58,7 @@ As with all aspects of the consensus process, amendment votes are only taken int
### Configuring Amendment Voting
You can temporarily configure an amendment using the [`feature` command](reference-rippled.html#feature). To make a persistent change to your server's support for an amendment, change your server's `rippled.cfg` file.
You can temporarily configure an amendment using the [feature method][]. To make a persistent change to your server's support for an amendment, change your server's `rippled.cfg` file.
Use the `[veto_amendments]` stanza to list amendments you do not want the server to vote for. Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:

8
content/concepts/issued-currencies/authorized-trust-lines.md
View File

@@ -24,7 +24,7 @@ To use the Authorized Trust Lines feature, an issuer must also enable `RequireAu
### Enabling RequireAuth
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an [AccountSet transaction][] to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
Request:
@@ -51,7 +51,7 @@ POST http://localhost:5005/
## Checking Whether an Account Has RequireAuth Enabled
To see whether an account has the RequireAuth setting enabled, use the [`account_info` command](reference-rippled.html#account-info) to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](reference-ledger-format.html#accountroot-flags).
To see whether an account has the RequireAuth setting enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](reference-ledger-format.html#accountroot-flags).
If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (0x00040000) is nonzero, then the account has RequireAuth enabled. If the result is zero, then the account has RequireAuth disabled.
@@ -61,7 +61,7 @@ If you are using the Authorized Trust Lines feature, others cannot hold balances
To authorize a trust line, submit a [TrustSet transaction][] from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](reference-transaction-format.html#trustset-flags) flag for the transaction.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
Request:
@@ -92,7 +92,7 @@ POST http://localhost:8088/
## Checking Whether Trust Lines Are Authorized
To see whether a trust line has been authorized, use the [`account_lines` command](reference-rippled.html#account-lines) to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
To see whether a trust line has been authorized, use the [account_lines method][] to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.

4
content/concepts/issued-currencies/freeze.md
View File

@@ -230,7 +230,7 @@ Example JavaScript (ECMAScript 6) code to enable No Freeze on an address:
### Using `rippled`
To see if a trust line has an Individual Freeze enabled, use the [`account_lines` method](reference-rippled.html#account-lines) with the following parameters:
To see if a trust line has an Individual Freeze enabled, use the [account_lines method][] with the following parameters:
| Field | Value | Description |
|----------|---------|-------------|
@@ -313,7 +313,7 @@ Example JavaScript (ECMAScript 6) code to check whether a trust line is frozen:
### Using `rippled`
To see if an address has enabled Global Freeze, No Freeze, or both, use the [`account_info` method](reference-rippled.html#account-lines) with the following parameters:
To see if an address has enabled Global Freeze, No Freeze, or both, use the [account_info method][] with the following parameters:
| Field | Value | Description |
|----------|---------|-------------|

4
content/concepts/issued-currencies/paths.md
View File

@@ -27,9 +27,9 @@ In both types of steps, each intermediate address gains and loses approximately
## Pathfinding
The `rippled` API has two methods that can be used for pathfinding. The [`ripple_path_find` command](reference-rippled.html#ripple-path-find) does a one-time lookup of possible path sets. The [`path_find` command](reference-rippled.html#path-find) (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.
The `rippled` API has two methods that can be used for pathfinding. The [ripple_path_find method][] does a one-time lookup of possible path sets. The [path_find method][] (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the [`sign` command](reference-rippled.html#sign) or [`submit` command (sign-and-submit mode)](reference-rippled.html#sign-and-submit-mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the [sign method][] or [`submit` command (sign-and-submit mode)](reference-rippled.html#sign-and-submit-mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
**Caution:** Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit. The actual cost to execute a payment along a path can change between submission and transaction execution.

2
content/concepts/issued-currencies/transfer-fees.md
View File

@@ -47,4 +47,4 @@ In `rippled`'s JSON-RPC and WebSocket APIs, the transfer fee is specified in the
A financial institution can submit an [AccountSet transaction](reference-transaction-format.html#accountset) from its [issuing address][] to change the `TransferRate` for its issuances.
You can check an account's `TransferRate` with the [`account_info` command](reference-rippled.html#account-info). If the `TransferRate` is omitted, then that indicates no fee.
You can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.

2
content/concepts/payment-system-basics/accounts/accounts.md
View File

@@ -23,7 +23,7 @@ There is not a dedicated "create account" transaction. The [Payment transaction]
The typical way to get an account in the XRP Ledger is as follows:
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair. (For example, you can use the [`wallet_propose` command](reference-rippled.html#wallet-propose) to do this.)
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair. (For example, you can use the [wallet_propose method][] to do this.)
2. Have someone who already has an account in the XRP Ledger send XRP to the address you generated.

2
content/concepts/payment-system-basics/accounts/concept-depositauth.md
View File

@@ -50,7 +50,7 @@ An account can enable deposit authorization by sending an [AccountSet transactio
## Checking Whether an Account Has DepositAuth Enabled
To see whether an account has Deposit Authorization enabled, use the [`account_info` command](reference-rippled.html#account-info) to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](reference-ledger-format.html#accountroot-flags).
To see whether an account has Deposit Authorization enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](reference-ledger-format.html#accountroot-flags).
If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (0x01000000) is nonzero, then the account has DepositAuth enabled. If the result is zero, then the account has DepositAuth disabled.

4
content/concepts/payment-system-basics/accounts/cryptographic-keys.md
View File

@@ -50,7 +50,7 @@ You can use this generated key pair in one of three ways: as a [master key pair]
**Key Type**
The field `key_type` indicates what [cryptographic signing algorithm](#signing-algorithms) was used to generate this key pair. You can specify the `key_type` when you make the request to generate a key pair using the [`wallet_propose` command](reference-rippled.html#wallet-propose).
The field `key_type` indicates what [cryptographic signing algorithm](#signing-algorithms) was used to generate this key pair. You can specify the `key_type` when you make the request to generate a key pair using the [wallet_propose method][].
## Master Key Pair
@@ -105,7 +105,7 @@ The XRP Ledger supports the following cryptographic signing algorithms:
| `secp256k1` | [ECDSA](https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/dss2/ecdsa2vs.pdf) using the elliptic curve [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) | This is the scheme used in Bitcoin. The XRP Ledger uses these key types by default. |
| `ed25519` | [EdDSA](https://tools.ietf.org/html/rfc8032) using the elliptic curve [Ed25519](https://ed25519.cr.yp.to/) | This is a newer algorithm which has better performance and other convenient properties. Since Ed25519 public keys are one byte shorter than secp256k1 keys, `rippled` prefixes Ed25519 public keys with the byte `0xED` so both types of public key are 33 bytes. |
When you generate a key pair with the [`wallet_propose` command](reference-rippled.html#wallet-propose), you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
When you generate a key pair with the [wallet_propose method][], you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](concept-accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.

8
content/concepts/payment-system-basics/transaction-cost.md
View File

@@ -109,18 +109,18 @@ _Fee levels_ represent the proportional difference between the minimum cost and
The `rippled` APIs have two ways to query the local load-based transaction cost: the `server_info` command (intended for humans) and the `server_state` command (intended for machines).
If the [FeeEscalation amendment](reference-amendments.html#feeescalation) is enabled, you can use the [`fee` command](reference-rippled.html#fee) to check the open ledger cost.
If the [FeeEscalation amendment](reference-amendments.html#feeescalation) is enabled, you can use the [fee method][] to check the open ledger cost.
### server_info
The [`server_info` command](reference-rippled.html#server-info) reports the unscaled minimum XRP cost, as of the previous ledger, as `validated_ledger.base_fee_xrp`, in the form of decimal XRP. The actual cost necessary to relay a transaction is scaled by multiplying that `base_fee_xrp` value by the `load_factor` parameter in the same response, which represents the server's current load level. In other words:
The [server_info method][] reports the unscaled minimum XRP cost, as of the previous ledger, as `validated_ledger.base_fee_xrp`, in the form of decimal XRP. The actual cost necessary to relay a transaction is scaled by multiplying that `base_fee_xrp` value by the `load_factor` parameter in the same response, which represents the server's current load level. In other words:
**Current Transaction Cost in XRP = `base_fee_xrp` × `load_factor`**
### server_state
The [`server_state` command](reference-rippled.html#server-state) returns a direct representation of `rippled`'s internal load calculations. In this case, the effective load rate is the ratio of the current `load_factor` to the `load_base`. The `validated_ledger.base_fee` parameter reports the minimum transaction cost in [drops of XRP](reference-rippled.html#specifying-currency-amounts). This design enables `rippled` to calculate the transaction cost using only integer math, while still allowing a reasonable amount of fine-tuning for server load. The actual calculation of the transaction cost is as follows:
The [server_state method][] returns a direct representation of `rippled`'s internal load calculations. In this case, the effective load rate is the ratio of the current `load_factor` to the `load_base`. The `validated_ledger.base_fee` parameter reports the minimum transaction cost in [drops of XRP](reference-rippled.html#specifying-currency-amounts). This design enables `rippled` to calculate the transaction cost using only integer math, while still allowing a reasonable amount of fine-tuning for server load. The actual calculation of the transaction cost is as follows:
**Current Transaction Cost in Drops = (`base_fee` × `load_factor`) ÷ `load_base`**
@@ -142,7 +142,7 @@ When you sign a transaction online, you can omit the `Fee` field. In this case,
* If the network's transaction cost goes up between signing and distributing the transaction, the transaction may not be confirmed.
* In the worst case, the transaction may be stuck in a state of being neither definitively confirmed or rejected, unless it included a `LastLedgerSequence` parameter or until you cancel it with a new transaction that uses the same `Sequence` number. See [reliable transaction submission](tutorial-reliable-transaction-submission.html) for best practices.
* You do not know in advance exactly what value you are signing for the `Fee` field.
* If you are using `rippled`, you can also use the `fee_mult_max` and `fee_div_max` parameters of the [`sign` command](reference-rippled.html#sign) to set a limit to the load scaling you are willing to sign.
* If you are using `rippled`, you can also use the `fee_mult_max` and `fee_div_max` parameters of the [sign method][] to set a limit to the load scaling you are willing to sign.
* You cannot look up the current transaction cost from an offline machine.
* You cannot automatically specify the transaction cost when [multi-signing](reference-transaction-format.html#multi-signing).

8
content/concepts/the-rippled-server/stand-alone-mode.md
View File

@@ -47,7 +47,7 @@ rippled --conf=/path/to/rippled.cfg
### 2. Wait until `rippled` is synced.
Use the [`server_info` command](reference-rippled.html#server-info) to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:
Use the [server_info method][] to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:
* `full`
* `proposing`
@@ -59,13 +59,13 @@ For more information, see [Possible Server States](reference-rippled.html#possib
If you only want the most recent ledger, you can skip this step.
If you want to load a specific historical ledger version, use the [`ledger_request` command](reference-rippled.html#ledger-request) to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger.
If you want to load a specific historical ledger version, use the [ledger_request method][] to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger.
If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version before it. (The previous ledger version sets up the initial state upon which you apply the changes described by the ledger version you replay.)
### 4. Shut down `rippled`.
Use the [`stop` command](reference-rippled.html#stop):
Use the [stop method][]:
```
rippled stop --conf=/path/to/rippled.cfg
@@ -96,7 +96,7 @@ rippled ledger_accept --conf=/path/to/rippled.cfg
## Advancing Ledgers in Stand-Alone Mode
In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [`ledger_accept` command](reference-rippled.html#ledger-accept):
In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [ledger_accept method][]:
```
rippled ledger_accept --conf=/path/to/rippled.cfg

2
content/news/known-amendments.md
View File

@@ -208,7 +208,7 @@ With this amendment, the new `STAmountCalcSwitchovers` code applies, which may c
|:-----------------------------------------------------------------|:----------|
| B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D | Enabled |
Adds tracking by destination account to [escrows](concept-escrow.html). Without this amendment, pending escrows are only tracked by sender. This amendment makes it possible to look up pending escrows by the destination address using the [`account_objects` command](reference-rippled.html#account-objects), excluding any pending escrows that were created before this amendment became enabled. This amendment also makes [EscrowCreate transactions][] appear in the destination's transaction history, as viewed with the [`account_tx` command](reference-rippled.html#account-tx).
Adds tracking by destination account to [escrows](concept-escrow.html). Without this amendment, pending escrows are only tracked by sender. This amendment makes it possible to look up pending escrows by the destination address using the [account_objects method][], excluding any pending escrows that were created before this amendment became enabled. This amendment also makes [EscrowCreate transactions][] appear in the destination's transaction history, as viewed with the [account_tx method][].
With this amendment, new escrows are added to the [owner directories](reference-ledger-format.html#directorynode) of both the sender and receiver. This amendment also adds a new `DestinationNode` field to [Escrow ledger objects](reference-ledger-format.html#escrow), indicating which page of the destination's owner directory contains the escrow.

2
content/references/rippled-api/ledger-data-formats/ledger-format-old-monolith.md
View File

@@ -34,7 +34,7 @@ All objects in a ledger' state tree have a unique ID. This field is returned as
## Header Format
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
Every ledger version has a unique header that describes the contents. You can look up a ledger's header information with the [`ledger` command](reference-rippled.html#ledger). The contents of the ledger header are as follows:
Every ledger version has a unique header that describes the contents. You can look up a ledger's header information with the [ledger method][]. The contents of the ledger header are as follows:
| Field | JSON Type | [Internal Type][] | Description |
|-----------------|-----------|-------------------|-------------|

6
content/references/rippled-api/transaction-formats/transaction-format-old-monolith.md
View File

@@ -188,7 +188,7 @@ To successfully submit a multi-signed transaction, you must do all of the follow
* For the provided signatures, the total `weight` associated with those signers must be equal or greater than the `quorum` for the SignerList.
* The [transaction cost](concept-transaction-cost.html) (specified in the `Fee` field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided.
* All fields of the transaction must be defined before collecting signatures. You cannot [auto-fill](#auto-fillable-fields) any fields.
* If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [`submit_multisigned` command](reference-rippled.html#submit-multisigned) handles this automatically.)
* If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [submit_multisigned method][] handles this automatically.)
For more information, see [How to Multi-Sign](tutorial-multisign.html).
@@ -447,7 +447,7 @@ Some of the fields that are mandatory for normal transactions do not make sense
## Immediate Response
The response from the [`submit` command](reference-rippled.html#submit) contains a provisional result from the `rippled` server indicating what happened during local processing of the transaction.
The response from the [submit method][] contains a provisional result from the `rippled` server indicating what happened during local processing of the transaction.
The response from `submit` contains the following fields:
@@ -469,7 +469,7 @@ If nothing went wrong when submitting and applying the transaction locally, the
## Looking up Transaction Results
To see the final result of a transaction, use the [`tx` command](reference-rippled.html#tx), [`account_tx` command](reference-rippled.html#account-tx), or other response from `rippled`. Look for `"validated": true` to indicate that this response uses a ledger version that has been validated by consensus.
To see the final result of a transaction, use the [tx method][], [account_tx method][], or other response from `rippled`. Look for `"validated": true` to indicate that this response uses a ledger version that has been validated by consensus.
| Field | Value | Description |
|:-----------------------|:--------|:------------------------------------------|

2
content/references/rippled-api/transaction-formats/transaction-types/offercreate.md
View File

@@ -58,7 +58,7 @@ An unfunded offer can stay on the ledger indefinitely, but it does not have any
Tracking the funding status of all offers can be computationally taxing. In particular, addresses that are actively trading may have a large number of offers open. A single balance can affect the funding status of many offers to buy different currencies. Because of this, `rippled` does not proactively find and remove offers.
A client application can locally track the funding status of offers. To do this, first retreive an order book using the [`book_offers` command](reference-rippled.html#book-offers) and check the `taker_gets_funded` field of offers. Then, [subscribe](reference-rippled.html#subscribe) to the `transactions` stream and watch the transaction metadata to see which offers are modified.
A client application can locally track the funding status of offers. To do this, first retreive an order book using the [book_offers method][] and check the `taker_gets_funded` field of offers. Then, [subscribe](reference-rippled.html#subscribe) to the `transactions` stream and watch the transaction metadata to see which offers are modified.
### Offers and Trust

18
content/tutorials/manage-account-settings/multisign.md
View File

@@ -20,7 +20,7 @@ To use multi-signing:
Multi-signing has been enabled by an [**Amendment**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27.
If you want to use multi-signing with `rippled` with a fresh ledger in [stand-alone mode](concept-stand-alone-mode.html), you must force the MultiSign feature to be enabled. You can check the status of the MultiSign amendment using the [`feature` command](reference-rippled.html#feature).
If you want to use multi-signing with `rippled` with a fresh ledger in [stand-alone mode](concept-stand-alone-mode.html), you must force the MultiSign feature to be enabled. You can check the status of the MultiSign amendment using the [feature method][].
To force the multi-signing feature to be enabled, add the following stanza to your `rippled.cfg`: <!--{# TODO: Link to rippled.cfg docs when those exist. #}-->
@@ -46,7 +46,7 @@ If you started `rippled` in [stand-alone mode](concept-stand-alone-mode.html) wi
### 2. Prepare member keys
You need several sets of XRP Ledger keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the [`wallet_propose` command](reference-rippled.html#wallet-propose). For example:
You need several sets of XRP Ledger keys (address and secret) to include as members of your SignerList. These can be funded addresses that exist in the ledger, or you can generate new addresses using the [wallet_propose method][]. For example:
$ rippled wallet_propose
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
@@ -154,7 +154,7 @@ Make sure that the [Transaction Result](reference-transaction-format.html#transa
On the live network, you can wait 4-7 seconds for the ledger to close automatically.
If you're running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger:
If you're running `rippled` in stand-alone mode, use the [ledger_accept method][] to manually close the ledger:
$ rippled ledger_accept
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
@@ -169,7 +169,7 @@ If you're running `rippled` in stand-alone mode, use the [`ledger_accept` comman
### 5. Confirm the new signer list
Use the [`account_objects` command](reference-rippled.html#account-objects) to confirm that the SignerList is associated with the address in the latest validated ledger.
Use the [account_objects method][] to confirm that the SignerList is associated with the address in the latest validated ledger.
Normally, an account can own many objects of different types (such as trust lines and offers). If you funded a new address for this tutorial, the SignerList is the only object in the response.
@@ -259,7 +259,7 @@ Here's an example transaction ready to be multi-signed:
### 2. Get one signature
Use the [`sign_for` command](reference-rippled.html#sign-for) with the secret key and address of one of the members of your SignerList to get a signature for that member.
Use the [sign_for method][] with the secret key and address of one of the members of your SignerList to get a signature for that member.
{% include '_snippets/secret-key-warning.md' %}
@@ -388,9 +388,9 @@ Depending on the SignerList you configured, you may need to repeat this step sev
### 4. Combine signatures and submit
If you collected the signatures in serial, the `tx_json` from the last `sign_for` response has all the signatures assembled, so you can use that as the argument to the [`submit_multisigned` command](reference-rippled.html#submit-multisigned).
If you collected the signatures in serial, the `tx_json` from the last `sign_for` response has all the signatures assembled, so you can use that as the argument to the [submit_multisigned method][].
If you collected the signatures in parallel, you must manually construct a `tx_json` object with all the signatures included. Take the `Signers` arrays from all the `sign_for` responses, and combine their contents into a single `Signers` array that has each signature. Add the combined `Signers` array to the original transaction JSON value, and use that as the argument to the [`submit_multisigned` command](reference-rippled.html#submit-multisigned).
If you collected the signatures in parallel, you must manually construct a `tx_json` object with all the signatures included. Take the `Signers` arrays from all the `sign_for` responses, and combine their contents into a single `Signers` array that has each signature. Add the combined `Signers` array to the original transaction JSON value, and use that as the argument to the [submit_multisigned method][].
$ rippled submit_multisigned '{
> "Account" : "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
@@ -469,7 +469,7 @@ Take note of the `hash` value from the response so you can check the results of
If you are using the live network, you can wait 4-7 seconds for the ledger to close automatically.
If you're running `rippled` in stand-alone mode, use the [`ledger_accept` command](reference-rippled.html#ledger-accept) to manually close the ledger:
If you're running `rippled` in stand-alone mode, use the [ledger_accept method][] to manually close the ledger:
$ rippled ledger_accept
Loading: "/home/mduo13/.config/ripple/rippled.cfg"
@@ -484,7 +484,7 @@ If you're running `rippled` in stand-alone mode, use the [`ledger_accept` comman
### 6. Confirm transaction results
Use the hash value from the response to the `submit_multisigned` command to look up the transaction using the [`tx` command](reference-rippled.html#tx). In particular, check that the `TransactionResult` is the string `tesSUCCESS`.
Use the hash value from the response to the `submit_multisigned` command to look up the transaction using the [tx method][]. In particular, check that the `TransactionResult` is the string `tesSUCCESS`.
On the live network, you must also confirm that the `validated` field is set to the boolean `true`. If the field is not `true`, you might need to wait longer for the consensus process to finish; or your transaction may be unable to be included in a ledger for some reason.

2
content/tutorials/manage-the-rippled-server/rippled-setup.md
View File

@@ -266,6 +266,6 @@ To enable clustering, change the following sections of your [config file](https:
192.168.0.1 51235
192.168.0.2 51235
* Generate a unique seed (using the [`validation_create` command](reference-rippled.html#validation-seed)) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
* Generate a unique seed (using the [validation_create method][]) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
* Add the public keys (for peer communication) of each of your other servers under the `[cluster_nodes]` section.

4
content/tutorials/use-complex-payment-types/use-checks/checks-cancel.md
View File

@@ -26,7 +26,7 @@ Figure out the values of the [CheckCancel transaction][] fields. The following f
|:------------------|:-----------------|:--------------------------------------|
| `TransactionType` | String | Use the string `CheckCancel` when canceling a Check. |
| `Account` | String (Address) | The address of the sender who is canceling the Check. (In other words, your address.) |
| `CheckID` | String | The ID of the Check object in the ledger to cancel. You can get this information by looking up the metadata of the CheckCreate transaction using the [`tx` method](reference-rippled.html#tx) or by looking for Checks using the [`account_objects` method](reference-rippled.html#account-objects). |
| `CheckID` | String | The ID of the Check object in the ledger to cancel. You can get this information by looking up the metadata of the CheckCreate transaction using the [tx method][] or by looking for Checks using the [account_objects method][]. |
If you are using [RippleAPI](reference-rippleapi.html), you can use the `prepareCheckCancel()` helper method.
@@ -147,7 +147,7 @@ The following examples demonstrate how to cancel a Check.
## {{cancel_n.next()}}. Confirm final result
Use the [`tx` method](reference-rippled.html#tx) with the CheckCancel transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
Use the [tx method][] with the CheckCancel transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
Look for a `DeletedNode` object in the transaction metadata with `"LedgerEntryType": "Check"` to indicate that the transaction removed a [Check ledger object](reference-ledger-format.html#check). The `LedgerIndex` of this object should match the ID of the Check.

4
content/tutorials/use-complex-payment-types/use-checks/checks-cash-exact.md
View File

@@ -18,7 +18,7 @@ Figure out the values of the [CheckCash transaction][] fields. To cash a check f
|:------------------|:--------------------------|:-----------------------------|
| `TransactionType` | String | The value `CheckCash` indicates this is a CheckCash transaction. |
| `Account` | String (Address) | The address of the sender who is cashing the Check. (In other words, your address.) |
| `CheckID` | String | The ID of the Check object in the ledger to cash. You can get this information by looking up the metadata of the CheckCreate transaction using the [`tx` method](reference-rippled.html#tx) or by looking for Checks using the [`account_objects` method](reference-rippled.html#account-objects). |
| `CheckID` | String | The ID of the Check object in the ledger to cash. You can get this information by looking up the metadata of the CheckCreate transaction using the [tx method][] or by looking for Checks using the [account_objects method][]. |
| `Amount` | String or Object (Amount) | The amount to redeem from the Check. For XRP, this must be a string specifying drops of XRP. For issued currencies, this is an object with `currency`, `issuer`, and `value` fields. The `currency` and `issuer` fields must match the corresponding fields in the Check object, and the `value` must be less than or equal to the amount in the Check object. (For currencies with transfer fees, you must cash the Check for less than its `SendMax` so the transfer fee can be paid by the `SendMax`.) If you cannot receive this much, cashing the Check fails, leaving the Check in the ledger so you can try again. For more information on specifying currency amounts, see [Specifying Currency Amounts][]. |
@@ -114,7 +114,7 @@ The following examples show how to prepare a transaction to cash a Check for a f
## {{cash_exact_n.next()}}. Confirm final result
Use the [`tx` method](reference-rippled.html#tx) with the CheckCash transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
Use the [tx method][] with the CheckCash transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
If the check was cashed for an exact `Amount` and succeeded, you can assume that the recipient was credited for exactly that amount (with possible rounding for very large or very small amounts of issued currencies).

4
content/tutorials/use-complex-payment-types/use-checks/checks-cash-flex.md
View File

@@ -21,7 +21,7 @@ Figure out the values of the [CheckCash transaction][] fields. To cash a check f
|:------------------|:--------------------------|:-----------------------------|
| `TransactionType` | String | The value `CheckCash` indicates this is a CheckCash transaction. |
| `Account` | String (Address) | The address of the sender who is cashing the Check. (In other words, your address.) |
| `CheckID` | String | The ID of the Check object in the ledger to cash. You can get this information by looking up the metadata of the CheckCreate transaction using the [`tx` method](reference-rippled.html#tx) or by looking for Checks using the [`account_objects` method](reference-rippled.html#account-objects). |
| `CheckID` | String | The ID of the Check object in the ledger to cash. You can get this information by looking up the metadata of the CheckCreate transaction using the [tx method][] or by looking for Checks using the [account_objects method][]. |
| `DeliverMin` | String or Object (Amount) | A minimum amount to receive from the Check. If you cannot receive at least this much, cashing the Check fails, leaving the Check in the ledger so you can try again. For XRP, this must be a string specifying drops of XRP. For issued currencies, this is an object with `currency`, `issuer`, and `value` fields. The `currency` and `issuer` fields must match the corresponding fields in the Check object, and the `value` must be less than or equal to the amount in the Check object. For more information on specifying currency amounts, see [Specifying Currency Amounts][]. |
### Example CheckCash Preparation for a flexible amount
@@ -115,7 +115,7 @@ The following examples show how to prepare a transaction to cash a Check for a f
## {{cash_flex_n.next()}}. Confirm final result
Use the [`tx` method](reference-rippled.html#tx) with the CheckCash transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
Use the [tx method][] with the CheckCash transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
### Example Request

2
content/tutorials/use-complex-payment-types/use-checks/checks-lookup-by-recipient.md
View File

@@ -6,7 +6,7 @@ This tutorial shows how to look up [Checks](concept-checks.html) by their recipi
To get a list of all incoming and outgoing Checks for an account, use the `account_objects` command with the recipient account's address and set the `type` field of the request to `checks`.
**Note:** The commandline interface to the `account_objects` command does not accept the `type` field. You can use the [`json` command](reference-rippled.html#json) to send the JSON-RPC format request on the commandline instead.
**Note:** The commandline interface to the `account_objects` command does not accept the `type` field. You can use the [json method][] to send the JSON-RPC format request on the commandline instead.
**Note:** RippleAPI does not have built-in support for the `account_objects` method. You can make a raw request in the WebSocket format using the `api.connection.request(websocket_request_json)` method.

2
content/tutorials/use-complex-payment-types/use-checks/checks-lookup-by-sender.md
View File

@@ -8,7 +8,7 @@ This tutorial shows how to look up [Checks](concept-checks.html) by their sender
To get a list of all incoming and outgoing Checks for an account, use the `account_objects` command with the sending account's address and set the `type` field of the request to `checks`.
**Note:** The commandline interface to the `account_objects` command does not accept the `type` field. You can use the [`json` command](reference-rippled.html#json) to send the JSON-RPC format request on the commandline instead.
**Note:** The commandline interface to the `account_objects` command does not accept the `type` field. You can use the [json method][] to send the JSON-RPC format request on the commandline instead.
**Caution:** RippleAPI does not have built-in support for the `account_objects` method. You can make a raw request in the WebSocket format using the `api.connection.request(websocket_request_json)` method. The response to this method is in the `rippled` API format. (For example, XRP is specified in integer "drops" rather than as a decimal.)

2
content/tutorials/use-complex-payment-types/use-checks/send-a-check.md
View File

@@ -174,7 +174,7 @@ The following example shows a prepared Check from BoxSend SG (rBXsgNkPcDN2runsvW
## {{send_n.next()}}. Confirm final result
Use the [`tx` method](reference-rippled.html#tx) with the CheckCreate transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
Use the [tx method][] with the CheckCreate transaction's identifying hash to check its status. Look for a `"TransactionResult": "tesSUCCESS"` field in the transaction's metadata, indicating that the transaction succeeded, and the field `"validated": true` in the result, indicating that this result is final.
Look for a `CreatedNode` object in the transaction metadata to indicate that the transaction created a [Check ledger object](reference-ledger-format.html#check). The `LedgerIndex` of this object is the ID of the Check. In the following example, the Check's ID is `49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0`.

16
content/tutorials/use-complex-payment-types/use-escrows/escrow.md
View File

@@ -84,7 +84,7 @@ Take note of the transaction's identifying `hash` value so you can check its fin
### 4. Confirm that the escrow was created
Use the [`tx` command](reference-rippled.html#tx) with the transaction's identifying hash to check its final status. Look for a `CreatedNode` in the transaction metadata to indicate that it created an [Escrow ledger object](reference-ledger-format.html#escrow).
Use the [tx method][] with the transaction's identifying hash to check its final status. Look for a `CreatedNode` in the transaction metadata to indicate that it created an [Escrow ledger object](reference-ledger-format.html#escrow).
Request:
@@ -114,7 +114,7 @@ Response:
Held payments with a `FinishAfter` time cannot be finished until a ledger has already closed with a [`close_time` header field](reference-ledger-format.html#header-format) that is later than the Escrow node's `FinishAfter` time.
You can check the close time of the most recently-validated ledger with the [`ledger` command](reference-rippled.html#ledger):
You can check the close time of the most recently-validated ledger with the [ledger method][]:
Request:
@@ -183,7 +183,7 @@ Take note of the transaction's identifying `hash` value so you can check its fin
### 8. Confirm final result
Use the [`tx` command](reference-rippled.html#tx) with the EscrowFinish transaction's identifying hash to check its final status. In particular, look in the transaction metadata for a `ModifiedNode` of type `AccountRoot` for the destination of the escrowed payment. The `FinalFields` of the object should show the increase in XRP in the `Balance` field.
Use the [tx method][] with the EscrowFinish transaction's identifying hash to check its final status. In particular, look in the transaction metadata for a `ModifiedNode` of type `AccountRoot` for the destination of the escrowed payment. The `FinalFields` of the object should show the increase in XRP in the `Balance` field.
Request:
@@ -306,7 +306,7 @@ Response:
### 5. Confirm that the escrow was created
Use the [`tx` command](reference-rippled.html#tx) with the transaction's identifying hash to check its final status. In particular, look for a `CreatedNode` in the transaction metadata to indicate that it created an [Escrow ledger object](reference-ledger-format.html#escrow).
Use the [tx method][] with the transaction's identifying hash to check its final status. In particular, look for a `CreatedNode` in the transaction metadata to indicate that it created an [Escrow ledger object](reference-ledger-format.html#escrow).
Request:
@@ -372,7 +372,7 @@ Take note of the transaction's identifying `hash` value so you can check its fin
### 8. Confirm final result
Use the [`tx` command](reference-rippled.html#tx) with the EscrowFinish transaction's identifying hash to check its final status. In particular, look in the transaction metadata for a `ModifiedNode` of type `AccountRoot` for the destination of the escrowed payment. The `FinalFields` of the object should show the increase in XRP in the `Balance` field.
Use the [tx method][] with the EscrowFinish transaction's identifying hash to check its final status. In particular, look in the transaction metadata for a `ModifiedNode` of type `AccountRoot` for the destination of the escrowed payment. The `FinalFields` of the object should show the increase in XRP in the `Balance` field.
Request:
@@ -390,7 +390,7 @@ Response:
### 1. Confirm the expired escrow
An escrow in the XRP Ledger is expired when its `CancelAfter` time is lower than the `close_time` of a validated ledger version. (If the escrow does not have a `CancelAfter` time, it never expires.) You can look up the close time of the latest validated ledger with the [`ledger` command](reference-rippled.html#ledger):
An escrow in the XRP Ledger is expired when its `CancelAfter` time is lower than the `close_time` of a validated ledger version. (If the escrow does not have a `CancelAfter` time, it never expires.) You can look up the close time of the latest validated ledger with the [ledger method][]:
Request:
@@ -417,7 +417,7 @@ _Websocket_
<!-- MULTICODE_BLOCK_END -->
You can look up the escrow and compare to the `CancelAfter` time using the [`account_objects` command](reference-rippled.html#account-objects):
You can look up the escrow and compare to the `CancelAfter` time using the [account_objects method][]:
Request:
@@ -481,7 +481,7 @@ Take note of the transaction's identifying `hash` value so you can check its fin
### 4. Confirm final result
Use the [`tx` command](reference-rippled.html#tx) with the EscrowCancel transaction's identifying hash to check its final status. Look in the transaction metadata for a `DeletedNode` with `LedgerEntryType` of `Escrow`. Also look for a `ModifiedNode` of type `AccountRoot` for the sender of the escrowed payment. The `FinalFields` of the object should show the increase in XRP in the `Balance` field for the returned XRP.
Use the [tx method][] with the EscrowCancel transaction's identifying hash to check its final status. Look in the transaction metadata for a `DeletedNode` with `LedgerEntryType` of `Escrow`. Also look for a `ModifiedNode` of type `AccountRoot` for the sender of the escrowed payment. The `FinalFields` of the object should show the increase in XRP in the `Balance` field for the returned XRP.
Request:

8
content/tutorials/use-complex-payment-types/use-payment-channels.md
View File

@@ -342,11 +342,11 @@ The payee should check the following:
- Confirm that the `amount` of the claim is equal or less than the `amount` of the channel. If the `amount` of the claim is higher, the claim cannot be redeemed unless the payer uses a [PaymentChannelFund transaction][] to increase the total amount of XRP available to the channel.
- Confirm that the `balance` of the channel matches the amount the payee expects to have already received from the channel. If these do not match up, the payee should double-check the channel's transaction history. Some possible explanations for a mismatch include:
- The payer used a [PaymentChannelClaim][] transaction to deliver XRP from the channel to the payee, but the payee did not notice and record the incoming transaction.
- The payee's records include transactions that are "in flight" or have not yet been included in the latest validated ledger version. The payee can use the [`tx` command](reference-rippled.html#tx) to look up the state of individual transactions to check this.
- The payee's records include transactions that are "in flight" or have not yet been included in the latest validated ledger version. The payee can use the [tx method][] to look up the state of individual transactions to check this.
- The `account_channels` request did not specify the correct ledger version. (Use `"ledger_index": "validated"` to get the latest validated ledger version)
- The payee previously redeemed XRP but forgot to record it.
- The payee attempted to redeem XRP and recorded the tentative result, but the transaction's final validated result was not the same and the payee neglected to record the final validated result.
- The `rippled` server the payee queried has lost sync with the rest of the network or is experiencing an unknown bug. Use the [`server_info` command](reference-rippled.html#server-info) to check the state of the server. (If you can reproduce this situation, please [report an issue](https://github.com/ripple/rippled/issues/).)
- The `rippled` server the payee queried has lost sync with the rest of the network or is experiencing an unknown bug. Use the [server_info method][] to check the state of the server. (If you can reproduce this situation, please [report an issue](https://github.com/ripple/rippled/issues/).)
After confirming both the signature and the current state of the payment channel, the payee has not yet received the XRP, but is certain that he or she _can_ redeem the XRP as long as the transaction to do so is processed before the channel expires.
@@ -456,7 +456,7 @@ Example of [submitting a transaction](reference-rippled.html#sign-and-submit-mod
}]
}
After the transaction is included in a validated ledger, either party can look up the currently-scheduled expiration of the channel using the [`account_channels` method](reference-rippled.html#account-channels). Be sure to specify `"ledger_index": "validated"` to get data from the latest validated ledger version.
After the transaction is included in a validated ledger, either party can look up the currently-scheduled expiration of the channel using the [account_channels method][]. Be sure to specify `"ledger_index": "validated"` to get data from the latest validated ledger version.
Example `account_channels` response:
@@ -511,7 +511,7 @@ Example of [submitting](reference-rippled.html#sign-and-submit-mode) a transacti
When the transaction has been included in a validated ledger, you can look at the metadata of the transaction to confirm that it deleted the channel and returned the XRP to the sender.
Example response from using the [`tx` command](reference-rippled.html#tx) to look up the transaction from this step:
Example response from using the [tx method][] to look up the transaction from this step:
{
"result": {

8
content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md
View File

@@ -340,7 +340,7 @@ Applications should persist the transaction's hash before submitting. The resul
#### Submit the transaction
`rippled` provides the [`submit` method](reference-rippled.html#submit), allowing us to submit the signed transaction. This uses the `tx_blob` parameter that was returned by the `sign` method.
`rippled` provides the [submit method][], allowing us to submit the signed transaction. This uses the `tx_blob` parameter that was returned by the `sign` method.
Request:
@@ -391,7 +391,7 @@ This a **preliminary** result. Final results are only available from validated
#### Verify the Transaction
The transaction hash, generated when the transaction was signed, is passed to the [`tx` method](reference-rippled.html#tx) to retrieve the result of a transaction.
The transaction hash, generated when the transaction was signed, is passed to the [tx method][] to retrieve the result of a transaction.
Request:
@@ -448,7 +448,7 @@ If the response does not include `"validated": true`, the result is provisional
#### Verify Missing Transaction
Applications must handle cases where a call to the [`tx` method](reference-rippled.html#tx) returns a `txnNotFound` error.
Applications must handle cases where a call to the [tx method][] returns a `txnNotFound` error.
```
{
@@ -468,7 +468,7 @@ Applications must handle cases where a call to the [`tx` method](reference-rippl
The `txnNotFound` result code occurs in cases where the transaction is not included in any ledger. However, it could also occur when a `rippled` instance does not have a complete ledger history, or if the transaction has not yet propagated to the `rippled` instance. Applications should make further queries to determine how to react.
The [`server_state` method](reference-rippled.html#server-state) (used earlier to determine the last validated ledger) indicates how complete the ledger history is, under `result.state.complete_ledgers`.
The [server_state method][] (used earlier to determine the last validated ledger) indicates how complete the ledger history is, under `result.state.complete_ledgers`.
```
{

14
content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md
View File

@@ -391,7 +391,7 @@ The DefaultRipple flag controls whether the balances in an accounting relationsh
Before asking customers to create accounting relationships to its issuing address, a gateway should enable the DefaultRipple flag on that address. Otherwise, the gateway must individually disable the NoRipple flag for each accounting relationship that other addresses have created.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an AccountSet transaction to enable the DefaultRipple flag:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the DefaultRipple flag:
Request:
@@ -463,7 +463,7 @@ The DisallowXRP setting (`disallowIncomingXRP` in RippleAPI) is designed to disc
An issuing gateway that does not trade XRP should enable the DisallowXRP flag on the gateway's issuing and operational addresses. A private exchange that trades in XRP should only enable the DisallowXRP flag on addresses that are not expected to receive XRP.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an AccountSet transaction to enable the DisallowXRP flag:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the DisallowXRP flag:
Request:
@@ -520,7 +520,7 @@ The `RequireDest` setting (`requireDestinationTag` in RippleAPI) is designed to
We recommend enabling the `RequireDest` flag on all gateway issuing and operational addresses.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an AccountSet transaction to enable the `RequireDest` flag:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the `RequireDest` flag:
Request:
@@ -578,7 +578,7 @@ The `RequireAuth` setting prevents all counterparties from holding balances issu
### Enabling RequireAuth
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an AccountSet transaction to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
Request:
@@ -609,7 +609,7 @@ If you are using the [Authorized Trust Lines](concept-authorized-trust-lines.htm
To authorize an accounting relationship, submit a TrustSet transaction from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](reference-transaction-format.html#trustset-flags) flag for the transaction.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
Request:
@@ -662,7 +662,7 @@ As an added precaution, we recommend comparing the balances of your issuing addr
The *TransferRate* setting (`transferRate` in RippleAPI) defines a fee to charge for transferring issuances from one XRP Ledger address to another. See [Transfer Fees](concept-transfer-fees.html) for more information.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an AccountSet transaction for the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW, setting the TransferRate to charge a fee of 0.5%.
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an AccountSet transaction for the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW, setting the TransferRate to charge a fee of 0.5%.
Request:
@@ -728,7 +728,7 @@ When you build an automated system to send payments into the XRP Ledger for your
One common pitfall is performing pathfinding before sending sending a payment to customers in the XRP Ledger. If you specify the issuers correctly, the [default paths](concept-paths.html#default-paths) can deliver the currency as intended.
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send a payment from the operational address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to the customer address raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n, sending and delivering funds issued by the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW.
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a payment from the operational address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to the customer address raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n, sending and delivering funds issued by the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW.
Request: