diff --git a/content/_snippets/checkcash-prereqs.md b/content/_snippets/checkcash-prereqs.md index e1c774aeb4..21478fde78 100644 --- a/content/_snippets/checkcash-prereqs.md +++ b/content/_snippets/checkcash-prereqs.md @@ -4,7 +4,7 @@ The prerequisites for cashing a check are the same whether you are cashing it fo - For example, the ID of one Check in these examples is `838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334`, although you must use a different ID to go through these steps yourself. - The **address** and **secret key** of the Check's stated recipient. The address must match the `Destination` address in the Check object. - If the Check is for an issued currency, you (the recipient) must have a trust line to the issuer. Your limit on that trust line must be enough higher than the balance to add the amount you would receive. - - For more information on trust lines and limits, see [Issued Currencies](concept-money.html#issued-currencies) and [Trust Limits](reference-transaction-format.html#trust-limits). + - For more information on trust lines and limits, see [Issued Currencies](money.html#issued-currencies) and [Trust Limits](reference-transaction-format.html#trust-limits). - A secure way to sign transactions, such as [RippleAPI][] or your own [`rippled` server](tutorial-rippled-setup.html). - A client library that can connect to a `rippled` server, such as [RippleAPI][] or any HTTP or WebSocket library. - For more information, see [Connecting to `rippled`](reference-rippled.html#connecting-to-rippled). diff --git a/content/_snippets/data_types/address.md b/content/_snippets/data_types/address.md index e03c50440b..179f472e97 100644 --- a/content/_snippets/data_types/address.md +++ b/content/_snippets/data_types/address.md @@ -7,5 +7,5 @@ Accounts in the XRP Ledger are identified by a base58 XRP Ledger Address. The ad * Includes a 4-byte checksum so that the probability of generating a valid address from random characters is approximately 1 in 2^32 {% if currentpage.md != "concept-accounts.md" %} -For more information, see [Accounts](concept-accounts.html). +For more information, see [Accounts](accounts.html). {% endif %} diff --git a/content/_snippets/tutorial-submit-step.md b/content/_snippets/tutorial-submit-step.md index 3f408d3aa4..79bb346936 100644 --- a/content/_snippets/tutorial-submit-step.md +++ b/content/_snippets/tutorial-submit-step.md @@ -1,3 +1,3 @@ -Take the signed transaction blob from the previous step and submit it to a `rippled` server. You can do this safely even if you do not operate the `rippled` server. The response contains a provisional result, which should be `tesSUCCESS`, but this result is [usually not final](reference-transaction-format.html#finality-of-results). A provisional response of `terQUEUED` is also OK, since [queued transactions](concept-transaction-cost.html#queued-transactions) are generally included in the next open ledger version (usually about 10 seconds after submission). +Take the signed transaction blob from the previous step and submit it to a `rippled` server. You can do this safely even if you do not operate the `rippled` server. The response contains a provisional result, which should be `tesSUCCESS`, but this result is [usually not final](reference-transaction-format.html#finality-of-results). A provisional response of `terQUEUED` is also OK, since [queued transactions](transaction-cost.html#queued-transactions) are generally included in the next open ledger version (usually about 10 seconds after submission). **Tip:** If the preliminary result is `tefMAX_LEDGER`, the transaction has failed permanently because its `LastLedgerSequence` parameter is lower than the current ledger. This happens when you take longer than the expected number of ledger versions between preparing and submitting the transaction. If this occurs, [start over from step 1]({{step_1_link}}) with a higher `LastLedgerSequence` value. diff --git a/content/concepts/complex-payment-types/checks.md b/content/concepts/complex-payment-types/checks.md index e87518f277..a235617d8b 100644 --- a/content/concepts/complex-payment-types/checks.md +++ b/content/concepts/complex-payment-types/checks.md @@ -4,7 +4,7 @@ The Checks feature in the XRP Ledger allows users to create deferred payments th XRP Ledger Checks have expiration times after which they may no longer be cashed. If the receiver doesn't successfully cash the Check before it expires, the Check object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and receiver can cancel the Check before it expires or is cashed. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it. -Checks are similar to [Escrow](concept-escrow.html) and [Payment Channels](tutorial-paychan.html), but there are some important differences between those features and Checks: +Checks are similar to [Escrow](escrow.html) and [Payment Channels](tutorial-paychan.html), but there are some important differences between those features and Checks: * You can send issued currency with Checks. With Payment Channels and Escrow, you can only send XRP. @@ -29,7 +29,7 @@ Checks potentially enable many other use cases. Ripple encourages the community **Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](tutorial-gateway-guide.html#gateway-compliance), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to disclose the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, issued currencies) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. -**Solution:** Institutions can enable [Deposit Authorization](concept-depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](reference-transaction-format.html#accountset-flags). This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled. +**Solution:** Institutions can enable [Deposit Authorization](depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](reference-transaction-format.html#accountset-flags). This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled. ## Usage @@ -48,7 +48,7 @@ Checks typically have the lifecycle described below. **Step 3:** To cash the check, the receiver submits a [CheckCash][] transaction. The receiver has two options for cashing the check: -* `Amount` — The receiver can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](concept-transfer-fees.html) and the receiver can only accept the exact amount on an invoice or other contract. +* `Amount` — The receiver can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](transfer-fees.html) and the receiver can only accept the exact amount on an invoice or other contract. * `DeliverMin` — The receiver can use this option to specify the minimum amount they are willing to receive from the Check. If the receiver uses this option, `rippled` attempts to deliver as much as possible and will deliver at least this amount. The transaction fails if the amount that can be credited to the receiver is not at least this amount. @@ -76,7 +76,7 @@ All Checks start the same way, so **Steps 1 and 2** are the same. ## Availability of Checks -Checks require `rippled` v0.90.0 or later. The Checks amendment gained support of a majority of validators on the production XRP Ledger on 2018-03-22 in this [EnableAmendment pseudo-transaction](https://ripple.com/build/transactions/#enableamendment): [`EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04`](https://xrpcharts.ripple.com/#/transactions/EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04). For more information about how amendments are enabled and voted on, see [Amendment Process](concept-amendments.html#amendment-process). +Checks require `rippled` v0.90.0 or later. The Checks amendment gained support of a majority of validators on the production XRP Ledger on 2018-03-22 in this [EnableAmendment pseudo-transaction](https://ripple.com/build/transactions/#enableamendment): [`EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04`](https://xrpcharts.ripple.com/#/transactions/EC0D90F114D4F3C599FEABCAF47DCF0CAC29A272D1EF6C9BEF7F420819540F04). For more information about how amendments are enabled and voted on, see [Amendment Process](amendments.html#amendment-process). @@ -103,8 +103,8 @@ For more information about Checks in the XRP Ledger, see: For more information about related features, see: -* [Deposit Authorization](concept-depositauth.html) -* [Escrow](concept-escrow.html) +* [Deposit Authorization](depositauth.html) +* [Escrow](escrow.html) * [Payment Channels Tutorial](tutorial-paychan.html) diff --git a/content/concepts/complex-payment-types/escrow.md b/content/concepts/complex-payment-types/escrow.md index dbde3de39e..ba91f30589 100644 --- a/content/concepts/complex-payment-types/escrow.md +++ b/content/concepts/complex-payment-types/escrow.md @@ -31,7 +31,7 @@ All escrows start the same way, so **Steps 1 and 2** are the same as in the succ Escrow is designed as a feature to enable the XRP Ledger to be used in the [Interledger Protocol][] and with other smart contracts. The current version has a modest scope to avoid complexity. - Escrow only works with XRP, not issued currencies. -- Escrow requires sending at least two transactions: one to create the escrow, and one to finish or cancel it. Thus, it may not be financially sensible to escrow payments for very small amounts, because the participants must destroy the [transaction cost](concept-transaction-cost.html) of the two transactions. +- Escrow requires sending at least two transactions: one to create the escrow, and one to finish or cancel it. Thus, it may not be financially sensible to escrow payments for very small amounts, because the participants must destroy the [transaction cost](transaction-cost.html) of the two transactions. - When using Crypto-Conditions, the [cost of the transaction to finish the escrow](#escrowfinish-transaction-cost) is higher than usual. - All escrows must have a "finish-after" time, an expiration time, or both. Neither time can be in the past when the transaction to create the escrow executes. - Timed releases and expirations are limited to the resolution of XRP Ledger closes. This means that, in practice, times may be rounded to approximately 5 second intervals, depending on exactly when the ledgers close. @@ -43,7 +43,7 @@ Escrow provides strong guarantees that are best suited for high-value, low-quant Conditional payments have been enabled by the ["Escrow" Amendment](reference-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016. -When testing in [stand-alone mode](concept-stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`: +When testing in [stand-alone mode](stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`: [features] Escrow @@ -52,15 +52,15 @@ You can check the status of the Escrow amendment using the [feature method][]. ## EscrowFinish Transaction Cost -When using [crypto-conditions][], the EscrowFinish transaction must pay a [higher transaction cost](concept-transaction-cost.html#special-transaction-costs) because of the higher processing load involved in verifying the crypto-condition fulfillment. +When using [crypto-conditions][], the EscrowFinish transaction must pay a [higher transaction cost](transaction-cost.html#special-transaction-costs) because of the higher processing load involved in verifying the crypto-condition fulfillment. -If the escrow is purely time-locked with no crypto-condition, the EscrowFinish costs only the standard [transaction cost](concept-transaction-cost.html) for a reference transaction. +If the escrow is purely time-locked with no crypto-condition, the EscrowFinish costs only the standard [transaction cost](transaction-cost.html) for a reference transaction. The additional transaction cost required is proportional to the size of the fulfillment. Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](reference-rippled.html#specifying-currency-amounts) plus 10 drops per 16 bytes in the size of the fulfillment**. If the transaction is [multi-signed](reference-transaction-format.html#multi-signing), the cost of multi-signing is added to the cost of the fulfillment. **Note:** The above formula is based on the assumption that the reference cost of a transaction is 10 drops of XRP. -If [Fee Voting](concept-fee-voting.html) changes the `reference_fee` value, the formula scales based on the new reference cost. The generalized formula for an EscrowFinish transaction with a fulfillment is as follows: +If [Fee Voting](fee-voting.html) changes the `reference_fee` value, the formula scales based on the new reference cost. The generalized formula for an EscrowFinish transaction with a fulfillment is as follows: ``` reference_fee * (signer_count + 33 + (fulfillment_bytes / 16)) diff --git a/content/concepts/complex-payment-types/partial-payments.md b/content/concepts/complex-payment-types/partial-payments.md index e561dd7e28..9c6b7d71af 100644 --- a/content/concepts/complex-payment-types/partial-payments.md +++ b/content/concepts/complex-payment-types/partial-payments.md @@ -1,8 +1,8 @@ # Partial Payments -In the default case, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the exact amount to deliver, after charging for exchange rates and [transfer fees](concept-transfer-fees.html). The "Partial Payment" flag ([**tfPartialPayment**](reference-transaction-format.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](tutorial-gateway-guide.html#bouncing-payments) without incurring additional costs to oneself. +In the default case, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the exact amount to deliver, after charging for exchange rates and [transfer fees](transfer-fees.html). The "Partial Payment" flag ([**tfPartialPayment**](reference-transaction-format.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](tutorial-gateway-guide.html#bouncing-payments) without incurring additional costs to oneself. -The amount of XRP used for the [transaction cost](concept-transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction. +The amount of XRP used for the [transaction cost](transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction. Partial payments can be used to exploit naive integrations with the XRP Ledger to steal money from exchanges and gateways. The [Partial Payments Exploit](#partial-payments-exploit) section of this document describes how this exploit works and how you can avoid it. @@ -16,9 +16,9 @@ In other words: Amount + (fees) = (sent amount) ≤ SendMax -In this formula, "fees" refers to [transfer fees](concept-transfer-fees.html) and currency exchange rates. The "sent amount" and the delivered amount (`Amount`) may be denominated in different currencies and converted by consuming Offers in the XRP Ledger's decentralized exchange. +In this formula, "fees" refers to [transfer fees](transfer-fees.html) and currency exchange rates. The "sent amount" and the delivered amount (`Amount`) may be denominated in different currencies and converted by consuming Offers in the XRP Ledger's decentralized exchange. -**Note:** The `Fee` field of the transaction refers to the XRP [transaction cost](concept-transaction-cost.html), which is destroyed to relay the transaction to the network. The exact transaction cost specified is always debited from the sender and is completely separate from the fee calculations for any type of payment. +**Note:** The `Fee` field of the transaction refers to the XRP [transaction cost](transaction-cost.html), which is destroyed to relay the transaction to the network. The exact transaction cost specified is always debited from the sender and is completely separate from the fee calculations for any type of payment. ### With Partial Payments diff --git a/content/concepts/consensus-network/amendments.md b/content/concepts/consensus-network/amendments.md index ae4bd3029a..9bc1c02a4d 100644 --- a/content/concepts/consensus-network/amendments.md +++ b/content/concepts/consensus-network/amendments.md @@ -16,7 +16,7 @@ Amendments solve this problem, so that new features can be enabled only when eno Users and businesses who rely on the XRP Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or [the consensus process][] do not need Amendments. -[the consensus process]: concept-consensus.html +[the consensus process]: consensus.html ## About Amendments @@ -30,7 +30,7 @@ By convention, Ripple's developers use the SHA-512Half hash of the amendment nam ## Amendment Process -Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. ([Fee Voting](concept-fee-voting.html) also occurs around flag ledgers.) +Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. ([Fee Voting](fee-voting.html) also occurs around flag ledgers.) The flag ledger itself has no special contents. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an [`EnableAmendment` pseudo-transaction](reference-transaction-format.html#enableamendment) into the following ledger. The flags of an EnableAmendment pseudo-transaction show what the server thinks happened: @@ -221,7 +221,7 @@ To look up which `rippled` version supports these features, see [Known Amendment If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s configuration file to forcibly enable a feature. This is intended for development purposes only. -Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](concept-stand-alone-mode.html). +Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](stand-alone-mode.html). To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example: diff --git a/content/concepts/consensus-network/fee-voting.md b/content/concepts/consensus-network/fee-voting.md index 1cc2919a80..7e76042721 100644 --- a/content/concepts/consensus-network/fee-voting.md +++ b/content/concepts/consensus-network/fee-voting.md @@ -1,6 +1,6 @@ # Fee Voting -Validators can vote for changes to basic [transaction cost](concept-transaction-cost.html) as well as [reserve requirements](concept-reserves.html). If the preferences in a validator's configuration are different than the network's current settings, the validator expresses its preferences to the network periodically. If a quorum of validators agrees on a change, they can apply a change that takes effect thereafter. Validators may do this for various reasons, especially to adjust to long-term changes in the value of XRP. +Validators can vote for changes to basic [transaction cost](transaction-cost.html) as well as [reserve requirements](reserves.html). If the preferences in a validator's configuration are different than the network's current settings, the validator expresses its preferences to the network periodically. If a quorum of validators agrees on a change, they can apply a change that takes effect thereafter. Validators may do this for various reasons, especially to adjust to long-term changes in the value of XRP. Operators of [`rippled` validators](tutorial-rippled-setup.html#running-a-validator) can set their preferences for the transaction cost and reserve requirements in the `[voting]` stanza of the `rippled.cfg` file. diff --git a/content/concepts/decentralized-exchange/offers.md b/content/concepts/decentralized-exchange/offers.md index 28b45441bb..b4111c7ac7 100644 --- a/content/concepts/decentralized-exchange/offers.md +++ b/content/concepts/decentralized-exchange/offers.md @@ -19,7 +19,7 @@ It is possible for an offer to become temporarily or permanently _unfunded_: * If the creator no longer has any of the `TakerGets` currency. * The offer becomes funded again when the creator obtains more of that currency. -* If the currency required to fund the offer is held in a [frozen trust line](concept-freeze.html). +* If the currency required to fund the offer is held in a [frozen trust line](freeze.html). * The offer becomes funded again when the trust line is no longer frozen. * If the creator does not have enough XRP for the reserve amount of a new trust line required by the offer. (See [Offers and Trust](#offers-and-trust).) * The offer becomes funded again when the creator obtains more XRP, or the reserve requirements decrease. @@ -44,7 +44,7 @@ A client application can locally track the funding status of offers. To do this, The limit values of trust lines (See [TrustSet](#trustset)) do not affect offers. In other words, you can use an offer to acquire more than the maximum amount you trust an issuer to redeem. -However, holding non-XRP balances still requires a trust line to the address issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](concept-reserves.html), any offers that would require a new trust line also require the address to have enough XRP to meet the reserve for that trust line. +However, holding non-XRP balances still requires a trust line to the address issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](reserves.html), any offers that would require a new trust line also require the address to have enough XRP to meet the reserve for that trust line. A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits. @@ -64,7 +64,7 @@ You can determine the final disposition of an offer with an `Expiration` as soon **Note:** Since only new transactions can modify the ledger, an expired offer can stay on the ledger after it becomes inactive. The offer is treated as unfunded and has no effect, but it can continue to appear in results (for example, from the [ledger_entry](reference-rippled.html#ledger-entry) command). Later on, the expired offer can get finally deleted as a result of another transaction (such as another OfferCreate) if the server finds it while processing. -If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment](reference-amendments.html#checks) is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. In either case, the transaction has no effect except to destroy the XRP paid as a [transaction cost](concept-transaction-cost.html). +If an OfferCreate transaction has an `Expiration` time that has already passed when the transaction first gets included in a ledger, the transaction does not execute the offer. The result code of such a transaction depends on whether the [Checks amendment](reference-amendments.html#checks) is enabled. With the Checks amendment enabled, the transaction has the `tecEXPIRED` result code. Otherwise, the transaction has the `tesSUCCESS` transaction code. In either case, the transaction has no effect except to destroy the XRP paid as a [transaction cost](transaction-cost.html). diff --git a/content/concepts/introduction/consensus.md b/content/concepts/introduction/consensus.md index ebcac2babc..fcfbef7cf0 100644 --- a/content/concepts/introduction/consensus.md +++ b/content/concepts/introduction/consensus.md @@ -12,10 +12,10 @@ When building applications on the XRP Ledger, it is important to understand this The peer-to-peer XRP Ledger network provides a worldwide, shared ledger, which gives applications authoritative information about the state of its contents. This state information includes: -- settings for each [account](concept-accounts.html) +- settings for each [account](accounts.html) - balances between accounts (trust lines) - offers in the distributed exchange -- network settings, such as [transaction costs](concept-transaction-cost.html) and [reserve](concept-reserves.html) amounts +- network settings, such as [transaction costs](transaction-cost.html) and [reserve](reserves.html) amounts - a time stamp For a full, technical description of which data is included in a ledger version, see the [Ledger Format Reference](reference-ledger-format.html). @@ -102,7 +102,7 @@ Nodes of the network recognize a ledger instance as validated when a supermajori In cases where a node is in the minority, having computed a ledger that differs from its peers, the node disregards the ledger it computed 9. It recomputes the correct ledger, or retrieves the correct ledger as needed. -If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the nodes repeat the consensus process. As time passes since consensus began, it becomes increasingly likely that a majority of the nodes have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](concept-transaction-cost.html) and the time to wait for consensus in response to these conditions. +If the network fails to achieve supermajority agreement on validations, this implies that transaction volume was too high or network latency too great for the consensus process to produce consistent proposals. In this case, the nodes repeat the consensus process. As time passes since consensus began, it becomes increasingly likely that a majority of the nodes have received the same set of candidate transactions, as each consensus round reduces disagreement. The XRP Ledger dynamically adjusts [transaction costs](transaction-cost.html) and the time to wait for consensus in response to these conditions. [![Figure 9: Network Recognizes a New Validated Ledger Version](img/consensus-validated-ledger.png)](img/consensus-validated-ledger.png) diff --git a/content/concepts/introduction/xrp-ledger-overview.md b/content/concepts/introduction/xrp-ledger-overview.md index 509f2aaf98..e685bfb819 100644 --- a/content/concepts/introduction/xrp-ledger-overview.md +++ b/content/concepts/introduction/xrp-ledger-overview.md @@ -26,7 +26,7 @@ This combines qualities of physical and centralized digital money. Prior to the - **Physical coins and paper money**, which individuals can use to do business without going through a central party. As physical objects, they cannot be used online, and doing business long-distance is slow and inconvenient. - **Centralized digital currencies**, which need an administrator to confirm transactions. The administrator also has the power to censor or roll back transactions, or disallow some individuals from using the digital currency. If the operator of a digital currency decides someone has violated its terms of service, it can freeze or even confiscate that person's money. However, as digital balances, these currencies can be used online and are convenient across long distances. -**Note:** Users of the XRP Ledger _can_ freeze non-XRP currencies issued in the XRP Ledger. For more information, see the [Freeze documentation](concept-freeze.html). +**Note:** Users of the XRP Ledger _can_ freeze non-XRP currencies issued in the XRP Ledger. For more information, see the [Freeze documentation](freeze.html). The XRP Ledger's system of trusted validators uses a small amount of human interaction to achieve better distribution of authority than other decentralized systems. Fully-automated systems for reaching consensus from an unknown set of participants are vulnerable to concentrations of voting power. For example, Bitcoin mining is disproportionately concentrated in places with cheap electricity. As Ripple curates a list of distinct validators operated by different entities in different jurisdictions, the XRP Ledger can become more resistant to censorship and outside pressures than proof-of-work mining. For more information on Ripple's plan to decentralize the recommended set of validators, see the [Decentralization Strategy Update](https://ripple.com/dev-blog/decentralization-strategy-update/). @@ -38,7 +38,7 @@ The XRP Ledger's biggest difference from most cryptocurrencies is that it uses a Furthermore, each new "ledger version" in the XRP Ledger (the equivalent of a "block") contains the full current state of all balances, so a server can synchronize with the network in minutes instead of spending hours downloading and re-processing the full transaction history. -For more information on how the XRP Ledger's consensus algorithm works, see [The XRP Ledger Consensus Process](concept-consensus.html). For background on why the XRP Ledger uses this consensus algorithm, see [Reaching Consensus In the XRP Ledger](concept-reaching-consensus.html). +For more information on how the XRP Ledger's consensus algorithm works, see [The XRP Ledger Consensus Process](consensus.html). For background on why the XRP Ledger uses this consensus algorithm, see [Reaching Consensus In the XRP Ledger](reaching-consensus.html). ## Finite XRP Supply @@ -48,9 +48,9 @@ Alongside war and political turmoil, hyperinflation is one of the leading causes The supply of XRP available to the general public _does_ change due to a few factors: -- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with certain minimums based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](concept-transaction-cost.html). +- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with certain minimums based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](transaction-cost.html). - Each account in the XRP Ledger must hold a small amount of XRP in reserve. This is an anti-spam measure to disincentivize making the ledger data occupy too much space. XRP Ledger validators can vote to change the amount of XRP required as a reserve, to compensate for changes in XRP's real-world value. (The last time this happened was in December 2013, when [the reserve requirement decreased from 50 XRP to 20 XRP](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/).) If the reserve requirement decreases, XRP that was previously locked up by the reserve becomes available again. -- Ripple (the company) holds a large reserve of XRP in escrow. At the start of each month, 1 billion XRP is released from escrow for Ripple to use. (Ripple uses XRP to incentivize growth in the XRP Ledger ecosystem and sells XRP to institutional investors.) At the end of each month, any remaining XRP the company does not sell or give away is stored into escrow for a 54-month period. For more information on Ripple's escrow policy, see [Ripple Escrows 55 Billion XRP for Supply Predictability](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). For more information on the technical capabilities of the Escrow feature, see [Escrow](concept-escrow.html). +- Ripple (the company) holds a large reserve of XRP in escrow. At the start of each month, 1 billion XRP is released from escrow for Ripple to use. (Ripple uses XRP to incentivize growth in the XRP Ledger ecosystem and sells XRP to institutional investors.) At the end of each month, any remaining XRP the company does not sell or give away is stored into escrow for a 54-month period. For more information on Ripple's escrow policy, see [Ripple Escrows 55 Billion XRP for Supply Predictability](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). For more information on the technical capabilities of the Escrow feature, see [Escrow](escrow.html). ## Responsible Software Governance @@ -71,7 +71,7 @@ As an entity that is obligated to hold large amounts of XRP for the long term, R Cryptography is one of the hardest parts of any distributed system, and a mistake can lead to money stolen by malicious actors anywhere in the world. The XRP Ledger uses industry-standard schemes for signing and verifying transactions, algorithms that have successfully protected hundreds of billions of US dollars' worth of value for many years. The XRP Ledger also layers multi-signing functionality so you can use multi-factor authorization or split keys across multiple people as a backup, and provides new algorithms with a path to migrate the keys you use if a breakthrough in cryptography makes the old algorithms obsolete. -For more information, see [Cryptographic Keys](concept-cryptographic-keys.html) and [Multi-signing](reference-transaction-format.html#multi-signing). +For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-signing](reference-transaction-format.html#multi-signing). ## Modern Features for Smart Contracts @@ -82,11 +82,11 @@ Besides simple value transfer with XRP payments, the XRP Ledger has several adva A sample of advanced features in the XRP Ledger: - [Payment Channels](tutorial-paychan.html) allow asynchronous balance changes as fast as you can create and validate signatures. -- [Escrow](concept-escrow.html) locks up XRP until a declared time passes or cryptographic condition is met. -- [DepositAuth](concept-depositauth.html) lets users decide who can send them money and who can't. +- [Escrow](escrow.html) locks up XRP until a declared time passes or cryptographic condition is met. +- [DepositAuth](depositauth.html) lets users decide who can send them money and who can't. - A [Decentralized Exchange](#on-ledger-decentralized-exchange) lets users trade obligations and XRP on-ledger. - [Invariant Checking](https://ripple.com/dev-blog/protecting-ledger-invariant-checking/) provides an independent layer of protections against bugs in transaction execution. -- [Amendments](concept-amendments.html) provide smooth upgrades to the existing feature set, so the technology can continue to evolve without fracturing the ecosystem or causing uncertainty around times of transition. +- [Amendments](amendments.html) provide smooth upgrades to the existing feature set, so the technology can continue to evolve without fracturing the ecosystem or causing uncertainty around times of transition. ## On-Ledger Decentralized Exchange @@ -94,4 +94,4 @@ A sample of advanced features in the XRP Ledger: One of the biggest features that sets the XRP Ledger apart from other cryptocurrency networks is that it also contains a full currency exchange that runs on the XRP Ledger. Within this system, businesses (typically called "gateways") can freely issue any currency they want to customers, and those customers can freely trade issued currencies for XRP or other issued currencies issued by any gateway. The XRP Ledger can execute atomic cross-currency transactions this way, using orders in the exchange to provide liquidity. -For more information on how the decentralized exchange works, see [Money in the XRP Ledger](concept-money.html) and [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer). For more information on the gateway business model, see the [Gateway Guide](tutorial-gateway-guide.html). +For more information on how the decentralized exchange works, see [Money in the XRP Ledger](money.html) and [Lifecycle of an Offer](reference-transaction-format.html#lifecycle-of-an-offer). For more information on the gateway business model, see the [Gateway Guide](tutorial-gateway-guide.html). diff --git a/content/concepts/introduction/xrp.md b/content/concepts/introduction/xrp.md index 1313da61b8..c0494e774c 100644 --- a/content/concepts/introduction/xrp.md +++ b/content/concepts/introduction/xrp.md @@ -1,15 +1,15 @@ # XRP -**XRP** is the native cryptocurrency of the XRP Ledger. All [accounts](concept-accounts.html) in the XRP Ledger can send XRP among one another and must hold a minimum amount of XRP as a [reserve](concept-reserves.html). XRP can be sent directly from any XRP Ledger address to any other, without needing a gateway or liquidity provider. This helps make XRP a convenient bridge currency. +**XRP** is the native cryptocurrency of the XRP Ledger. All [accounts](accounts.html) in the XRP Ledger can send XRP among one another and must hold a minimum amount of XRP as a [reserve](reserves.html). XRP can be sent directly from any XRP Ledger address to any other, without needing a gateway or liquidity provider. This helps make XRP a convenient bridge currency. -Some advanced features of the XRP Ledger, such as [Escrow](concept-escrow.html) and [Payment Channels](tutorial-paychan.html), only work with XRP. Order book [autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/) uses XRP to deepen liquidity in the decentralized exchange by merging order books of two issued currencies with XRP order books to create synthetic combined order books. (For example, autobridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.) +Some advanced features of the XRP Ledger, such as [Escrow](escrow.html) and [Payment Channels](tutorial-paychan.html), only work with XRP. Order book [autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/) uses XRP to deepen liquidity in the decentralized exchange by merging order books of two issued currencies with XRP order books to create synthetic combined order books. (For example, autobridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.) -XRP also serves as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to pay the costs of maintaining the XRP Ledger. The [transaction cost](concept-transaction-cost.html) and [reserve](concept-reserves.html) are neutral fees denominated in XRP and not paid to any party. In the ledger's data format, XRP is stored in [AccountRoot objects](reference-ledger-format.html#accountroot). +XRP also serves as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to pay the costs of maintaining the XRP Ledger. The [transaction cost](transaction-cost.html) and [reserve](reserves.html) are neutral fees denominated in XRP and not paid to any party. In the ledger's data format, XRP is stored in [AccountRoot objects](reference-ledger-format.html#accountroot). For more information on XRP's use cases, benefits, and news, see the [XRP Portal](https://ripple.com/xrp-portal/). ## XRP Properties -The very first ledger contained 100 billion XRP, and no new XRP can be created. XRP can be destroyed by [transaction costs](concept-transaction-cost.html) or lost by sending it to addresses for which no one holds a key, so XRP is slightly [deflationary](https://en.wikipedia.org/wiki/Deflation) by nature. No need to worry about running out, though: at the current rate of destruction, it would take at least 70,000 years to destroy all XRP, and XRP [prices and fees can be adjusted](concept-fee-voting.html) as the total supply of XRP changes. +The very first ledger contained 100 billion XRP, and no new XRP can be created. XRP can be destroyed by [transaction costs](transaction-cost.html) or lost by sending it to addresses for which no one holds a key, so XRP is slightly [deflationary](https://en.wikipedia.org/wiki/Deflation) by nature. No need to worry about running out, though: at the current rate of destruction, it would take at least 70,000 years to destroy all XRP, and XRP [prices and fees can be adjusted](fee-voting.html) as the total supply of XRP changes. In technical contexts, XRP is measured precisely to the nearest 0.000001 XRP, called a "drop" of XRP. The [`rippled` APIs](reference-rippled.html) require all XRP amounts to be specified in drops of XRP. For example, 1 XRP is represented as `1000000` drops. For more detailed information, see the [currency format reference](reference-currency.html). diff --git a/content/concepts/issued-currencies/authorized-trust-lines.md b/content/concepts/issued-currencies/authorized-trust-lines.md index 447b0b772a..ef0b14567f 100644 --- a/content/concepts/issued-currencies/authorized-trust-lines.md +++ b/content/concepts/issued-currencies/authorized-trust-lines.md @@ -16,7 +16,7 @@ The transaction to authorize a trust line must be signed by the issuing address, The `RequireAuth` setting (`requireAuthorization` in [RippleAPI](reference-rippleapi.html)) prevents all counterparties from holding balances issued by an address unless the issuing address has specifically approved a trust line with that counterparty for the currency in question. -As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](concept-issuing-and-operational-addresses.html), and then never approve any trust lines to those addresses. This prevents operational addresses and standby addresses from issuing currency in the XRP Ledger even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issued currency balances created by the issuing address, as they are intended to do. +As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](issuing-and-operational-addresses.html), and then never approve any trust lines to those addresses. This prevents operational addresses and standby addresses from issuing currency in the XRP Ledger even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issued currency balances created by the issuing address, as they are intended to do. To use the Authorized Trust Lines feature, an issuer must also enable `RequireAuth` on its issuing address. After doing so, the issuing address must [submit a `TrustSet` transaction to approve each trust line](#authorizing-trust-lines) from a customer. diff --git a/content/concepts/issued-currencies/freeze.md b/content/concepts/issued-currencies/freeze.md index a76d6b93b3..8a05bebf9d 100644 --- a/content/concepts/issued-currencies/freeze.md +++ b/content/concepts/issued-currencies/freeze.md @@ -24,7 +24,7 @@ The **Individual Freeze** feature is a setting on a trust line. When an issuing A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution operates that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.) -An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](concept-issuing-and-operational-addresses.html), from sending that financial institution's issuances to the individual address. This type of individual freeze has no effect on offers. +An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's issuances to the individual address. This type of individual freeze has no effect on offers. The Individual Freeze applies to a single currency only. To freeze multiple currencies with a particular counterparty, the address must enable Individual Freeze on the trust lines for each currency individually. @@ -35,13 +35,13 @@ An address cannot enable the Individual Freeze setting if it has enabled the [No The **Global Freeze** feature is a setting on an address. When an issuing address enables the Global Freeze feature, the following rules apply: -* All counterparties of the frozen issuing address can no longer decrease the balances in their trust lines to the frozen address, except in direct payments to the issuer. (This also affects any [operational addresses](concept-issuing-and-operational-addresses.html).) +* All counterparties of the frozen issuing address can no longer decrease the balances in their trust lines to the frozen address, except in direct payments to the issuer. (This also affects any [operational addresses](issuing-and-operational-addresses.html).) * Counterparties of the frozen issuing address can still send and receive payments directly to and from the issuing address. * All offers to sell currencies issued by the frozen address are [considered unfunded](reference-transaction-format.html#lifecycle-of-an-offer). -It can be useful to enable Global Freeze on a financial institution's [issuing address](concept-issuing-and-operational-addresses.html) if the secret key to an operational address is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, a financial institution should also suspend activities in its connectors to outside systems. +It can be useful to enable Global Freeze on a financial institution's [issuing address](issuing-and-operational-addresses.html) if the secret key to an operational address is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, a financial institution should also suspend activities in its connectors to outside systems. -It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](concept-issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies. +It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies. Global Freeze applies to _all_ currencies issued and held by the address. You cannot enable Global Freeze for only one currency. If you want to have the ability to freeze some currencies and not others, you should use different addresses for each currency. diff --git a/content/concepts/issued-currencies/issued-currencies.md b/content/concepts/issued-currencies/issued-currencies.md index c5bb7992ed..5b77c918f0 100644 --- a/content/concepts/issued-currencies/issued-currencies.md +++ b/content/concepts/issued-currencies/issued-currencies.md @@ -2,7 +2,7 @@ All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "issuances" or "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. -Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [NoRipple flag](concept-noripple.html) on trust lines to prevent those trust lines from rippling. +Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [NoRipple flag](noripple.html) on trust lines to prevent those trust lines from rippling. Issued currencies can be traded with XRP or each other in the XRP Ledger's decentralized exchange. @@ -18,9 +18,9 @@ Ripple strongly recommends researching the relevant regulations before engaging All issued currencies in the XRP Ledger exist in trust lines, represented in the ledger's data as [RippleState objects](reference-ledger-format.html#ripplestate). To create an issued currency, the issuing address sends a [Payment transaction][] to an address which has a trust line to the issuer with a nonzero limit for that currency. (You can also create issued currency by rippling "through" such a trust line.) You can erase issued currency by sending it back to the issuer. -The issuer of a currency can define a percentage [transfer fee](concept-transfer-fees.html) to deduct when two parties transact in its issued currencies. +The issuer of a currency can define a percentage [transfer fee](transfer-fees.html) to deduct when two parties transact in its issued currencies. -Addresses can also [freeze](concept-freeze.html) issued currencies, which may be useful for businesses to comply with financial regulations in their jurisdiction. If you do not need this feature and do not want to freeze currencies, you can give up your address's ability to freeze individual trust lines and to undo a global freeze. XRP cannot be frozen. +Addresses can also [freeze](freeze.html) issued currencies, which may be useful for businesses to comply with financial regulations in their jurisdiction. If you do not need this feature and do not want to freeze currencies, you can give up your address's ability to freeze individual trust lines and to undo a global freeze. XRP cannot be frozen. Issued currencies are designed to be able to represent any kind of currency or asset, including those with very small or very large nominal values. For detailed technical information on the types of currency codes and the numeric limits of issued currency representation, see the [currency format reference](reference-currency.html). diff --git a/content/concepts/issued-currencies/paths.md b/content/concepts/issued-currencies/paths.md index d0ceccb2ed..de6b3177e1 100644 --- a/content/concepts/issued-currencies/paths.md +++ b/content/concepts/issued-currencies/paths.md @@ -13,11 +13,11 @@ A path is made of steps that connect the sender to the receiver of the payment. * Rippling through another address with the same currency * Exchanging currency at an order book -Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the NoRipple Flag](concept-noripple.html) for more examples of rippling. +Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the NoRipple Flag](noripple.html) for more examples of rippling. In the case of a currency exchange step, the path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) -In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](concept-transfer-fees.html), trust line quality, or rounding. +In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.html), trust line quality, or rounding. [![Diagram of three example paths](img/paths-examples.png)](img/paths-examples.png) diff --git a/content/concepts/issued-currencies/transfer-fees.md b/content/concepts/issued-currencies/transfer-fees.md index 2d2412bc89..0804d695bb 100644 --- a/content/concepts/issued-currencies/transfer-fees.md +++ b/content/concepts/issued-currencies/transfer-fees.md @@ -2,8 +2,8 @@ The `TransferRate` setting in the XRP Ledger allows [financial institutions that issue currency in the XRP Ledger](tutorial-gateway-guide.html) to charge users a _transfer fee_ for sending the currencies issued by that financial institution. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee, which becomes the property of the issuing address, and is no longer tracked in the XRP Ledger. The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user. -[operational address]: concept-issuing-and-operational-addresses.html -[issuing address]: concept-issuing-and-operational-addresses.html +[operational address]: issuing-and-operational-addresses.html +[issuing address]: issuing-and-operational-addresses.html XRP never has a transfer fee, because it never has an issuer. @@ -31,7 +31,7 @@ In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to de The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The TransferRate setting applies to all currencies issued by the same account. If you want to have different transfer fee percentages for different currencies, use different [issuing addresses][issuing address] for each currency. -**Note:** The [fix1201 amendment](concept-amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to operate at their stated rate. +**Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to operate at their stated rate. ## RippleAPI diff --git a/content/concepts/payment-system-basics/accounts/accounts.md b/content/concepts/payment-system-basics/accounts/accounts.md index 713cdaa7ad..394df0cc34 100644 --- a/content/concepts/payment-system-basics/accounts/accounts.md +++ b/content/concepts/payment-system-basics/accounts/accounts.md @@ -3,7 +3,7 @@ An "Account" in the XRP Ledger represents a holder of XRP and a sender of [transactions](reference-transaction-format.html). The core elements of an account are: - An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` -- An **XRP balance**. Some of this XRP is set aside for the [Reserve](concept-reserves.html). +- An **XRP balance**. Some of this XRP is set aside for the [Reserve](reserves.html). - A **sequence number**, starting at 1 and increasing with each transaction sent from this account. No transaction can be included in a ledger unless the transaction's sequence number matches its sender's next sequence number. - A **history of transactions** that affected this account and its balances. - One or more ways to [authorize transactions](reference-transaction-format.html#authorizing-transactions), possibly including: @@ -17,7 +17,7 @@ In the ledger's data tree, an account's core data is stored in the [AccountRoot] ### Creating Accounts -There is not a dedicated "create account" transaction. The [Payment transaction][] automatically creates a new account if the payment sends XRP equal to or greater than the [account reserve](concept-reserves.html) to a mathematically-valid address that does not already have an account. This is called _funding_ an account, and creates an [AccountRoot object](reference-ledger-format.html#accountroot) in the ledger. No other transaction can create an account. +There is not a dedicated "create account" transaction. The [Payment transaction][] automatically creates a new account if the payment sends XRP equal to or greater than the [account reserve](reserves.html) to a mathematically-valid address that does not already have an account. This is called _funding_ an account, and creates an [AccountRoot object](reference-ledger-format.html#accountroot) in the ledger. No other transaction can create an account. **Caution:** Funding an account **does not** give you any special privileges over that account. Whoever has the secret key corresponding to the account's address has full control over the account and all XRP it contains. For some addresses, it's possible that no one has the secret key, in which case the account is a [black hole](#special-addresses) and the XRP is lost forever. @@ -29,7 +29,7 @@ The typical way to get an account in the XRP Ledger is as follows: - For example, you can purchase XRP in a private exchange, then withdraw XRP from the exchange to the address you specified. - **Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](concept-reserves.html) (currently 20 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price. + **Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.html) (currently 20 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price. ## Addresses @@ -66,7 +66,7 @@ Unlike Bitcoin and many other crypto-currencies, each new version of the XRP Led In the XRP Ledger, transaction history is tracked by a "thread" of transactions linked by a transaction's identifying hash and the ledger index. The `AccountRoot` ledger object has the identifying hash and ledger of the transaction that most recently modified it; the metadata of that transaction includes the previous state of the `AccountRoot` node, so it is possible to iterate through the history of a single account this way. This transaction history includes any transactions that modify the `AccountRoot` node directly, including: -- Transactions sent by the account, because they modify the account's `Sequence` number. These transactions also modify the account's XRP balance because of the [transaction cost](concept-transaction-cost.html). +- Transactions sent by the account, because they modify the account's `Sequence` number. These transactions also modify the account's XRP balance because of the [transaction cost](transaction-cost.html). - Transactions that modified the account's XRP balance, including incoming [Payment transactions][] and other types of transactions such as [PaymentChannelClaim][] and [EscrowFinish][]. The _conceptual_ transaction history of an account also includes transactions that modified the account's owned objects and non-XRP balances. These objects are separate ledger objects, each with their own thread of transactions that affected them. If you have an account's full ledger history, you can follow it forward to find the ledger objects created or modified by it. A "complete" transaction history includes the history of objects owned by a transaction, such as: diff --git a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md index 05925026dd..2acc357428 100644 --- a/content/concepts/payment-system-basics/accounts/cryptographic-keys.md +++ b/content/concepts/payment-system-basics/accounts/cryptographic-keys.md @@ -38,11 +38,11 @@ The `public_key` and `public_key_hex` are the public key in various formats, wit **account_id** -The `account_id` is [derived from the public key](concept-accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account. +The `account_id` is [derived from the public key](accounts.html#address-encoding) and designates the *potential* for an account to be created in the XRP Ledger. It is important to know that while an `account_id` exists, no actual account exists in the XRP Ledger until the `account_id` receives its first XRP payment. In addition, the `account_id` can't send any transactions until after it's received a transaction that funds and creates the account. The `account_id` (without a funded account) can, however, be used as a [regular key](#regular-key-pair) or a [member of a signer list](reference-transaction-format.html#multi-signing) to authorize transactions for another account that does exist. -To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](concept-reserves.html). +To create a funded account stored in the ledger, the `account_id` must [receive a `Payment` transaction](reference-transaction-format.html#creating-accounts) that provides enough XRP to meet the [reserve requirement](reserves.html). For more information about the `wallet_propose` response, see [`wallet_propose`](reference-rippled.html#wallet-propose). @@ -59,11 +59,11 @@ The master key pair is composed of a private key and a public key. In addition t * [Disable the master public key](reference-transaction-format.html#accountset-flags). -* Permanently give up the ability to [freeze](concept-freeze.html#no-freeze). +* Permanently give up the ability to [freeze](freeze.html#no-freeze). -* Send a cost-0 [key reset transaction](concept-transaction-cost.html#key-reset-transaction). +* Send a cost-0 [key reset transaction](transaction-cost.html#key-reset-transaction). -The master key pair for an account is generated in the same [`wallet_propose`](reference-rippled.html#wallet-propose) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](concept-accounts.html#address-encoding) to the `account_id`, which is derived from the `public_key_hex`. +The master key pair for an account is generated in the same [`wallet_propose`](reference-rippled.html#wallet-propose) response as the `account_id` of the account the master key pair is authorized to sign transactions for. Because the master key pair is generated in the same response, it is [intrinsically related](accounts.html#address-encoding) to the `account_id`, which is derived from the `public_key_hex`. This is as opposed to a regular key pair, which is also generated using the `wallet_propose` method, but which must be explicitly assigned as a regular key pair to an account. Because a regular key pair is explicitly assigned, it is not intrinsically related to the `account_id` of the account it is authorized to sign transactions for. For more information, see [Regular Key Pair](#regular-key-pair). @@ -107,7 +107,7 @@ The XRP Ledger supports the following cryptographic signing algorithms: 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. +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](accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs. **Note:** Currently, you cannot sign [payment channel claims](tutorial-paychan.html) with Ed25519 keys. This is a bug. diff --git a/content/concepts/payment-system-basics/accounts/depositauth.md b/content/concepts/payment-system-basics/accounts/depositauth.md index 7e3c4ef02f..f565422ba1 100644 --- a/content/concepts/payment-system-basics/accounts/depositauth.md +++ b/content/concepts/payment-system-basics/accounts/depositauth.md @@ -2,7 +2,7 @@ _(Requires the [DepositAuth amendment](reference-amendments.html#depositauth).)_ -Deposit Authorization is an optional feature of an [account](concept-accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies. +Deposit Authorization is an optional feature of an [account](accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies. By default, new accounts have DepositAuth disabled. @@ -12,14 +12,14 @@ Financial services regulations and licenses may require that a business or entit The Deposit Authorization flag introduces an option for those using the XRP Ledger to comply with such regulations without changing the fundamental nature of the decentralized ledger. With Deposit Authorization enabled, an account can only receive funds it explicitly approves by sending a transaction. The owner of an account using Deposit Authorization can perform the due diligence necessary to identify the sender of any funds _before_ sending the transaction that causes the account to receive the money. -Deposit Authorization is intended to be used with [Checks](reference-amendments.html#checks), [Escrow](concept-escrow.html), and [Payment Channels](reference-amendments.html#paychan). In this "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds. Deposit Authorization cannot be used with [Payment transactions][]. +Deposit Authorization is intended to be used with [Checks](reference-amendments.html#checks), [Escrow](escrow.html), and [Payment Channels](reference-amendments.html#paychan). In this "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds. Deposit Authorization cannot be used with [Payment transactions][]. ## Recommended Usage To get the full effect of Deposit Authorization, Ripple recommends also doing the following: -- Always maintain an XRP balance higher than the minimum [reserve requirement](concept-reserves.html). -- Keep the DefaultRipple flag in its default (disabled) state. Do not enable [rippling](concept-noripple.html) on any trust lines. When sending TrustSet transactions, always use the [`tfSetNoRipple` flag](reference-transaction-format.html#trustset-flags). +- Always maintain an XRP balance higher than the minimum [reserve requirement](reserves.html). +- Keep the DefaultRipple flag in its default (disabled) state. Do not enable [rippling](noripple.html) on any trust lines. When sending TrustSet transactions, always use the [`tfSetNoRipple` flag](reference-transaction-format.html#trustset-flags). - Do not place [Offers](reference-transaction-format.html#offercreate). It is impossible to know in advance which matching offers will be consumed to execute such a trade. ## Precise Semantics @@ -27,13 +27,13 @@ To get the full effect of Deposit Authorization, Ripple recommends also doing th An account with Deposit Authorization enabled: - **Cannot** be the destination of [Payment transactions][], with **one exception**: - - If the account's XRP balance is equal to or below the minimum account [reserve requirement](concept-reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case. + - If the account's XRP balance is equal to or below the minimum account [reserve requirement](reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case. - Can receive XRP from [PaymentChannelClaim transactions][] **only if** the sender of the PaymentChannelClaim transaction is the destination of the payment channel. - Can receive XRP from [EscrowFinish transactions][] **only if** the sender of the EscrowFinish transaction is the destination of the escrow. - **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Requires the [Checks amendment](reference-amendments.html#checks).)_ - **Can** receive XRP or issued currencies by sending [OfferCreate transactions][]. - If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions. -- If the account has created any trust lines without the [NoRipple flag](concept-noripple.html) enabled, or has enabled the DefaultRipple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. +- If the account has created any trust lines without the [NoRipple flag](noripple.html) enabled, or has enabled the DefaultRipple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions. - In general, an account in the XRP Ledger **cannot** receive any non-XRP currencies in the XRP Ledger as long as all of the following are true. (This rule is not specific to the DepositAuth flag.) - The account has not created any trust lines with a nonzero limit. - The account has not issued currency on trust lines created by others @@ -56,9 +56,9 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value ( ## See Also -- The [Authorized Trust Lines](concept-authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account. +- The [Authorized Trust Lines](authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account. - The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.) - The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](tutorial-gateway-guide.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags. -- [Partial Payments](concept-partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](concept-transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent. +- [Partial Payments](partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent. {% include '_snippets/tx-type-links.md' %} diff --git a/content/concepts/payment-system-basics/accounts/reserves.md b/content/concepts/payment-system-basics/accounts/reserves.md index f674b5101b..993d7ac9eb 100644 --- a/content/concepts/payment-system-basics/accounts/reserves.md +++ b/content/concepts/payment-system-basics/accounts/reserves.md @@ -25,7 +25,7 @@ Many objects in the ledger are owned by a particular address, and count toward t - [Held Payments (Escrow)](reference-ledger-format.html#escrow) are owned by the address that placed them. - [Payment Channels](tutorial-paychan.html) are owned by the address that created them. - [Owner directories](reference-ledger-format.html#directorynode) list all the ledger objects that contribute to an address's owner reserve. However, the owner directory itself does not count towards the reserve. -- [Checks](concept-checks.html) are owned by the address that created them (the sender, not the destination). +- [Checks](checks.html) are owned by the address that created them (the sender, not the destination). #### Owner Reserve Edge Cases @@ -35,7 +35,7 @@ The XRP Ledger considers an [OfferCreate transaction][] to be an explicit statem ## Going Below the Reserve Requirement -During transaction processing, the [transaction cost](concept-transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement. +During transaction processing, the [transaction cost](transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement. When an address holds less XRP than its current reserve requirement, it cannot send new transactions that would transfer XRP to others, or increase its own reserve. Even so, the address continues to exist in the ledger and can send other transactions as long as it has enough XRP to pay the transaction cost. The address can become able to send all types of transactions again if it receives enough XRP to meet its reserve requirement again, or if the [reserve requirement decreases](#changing-the-reserve-requirements) to less than the address's XRP holdings. @@ -43,6 +43,6 @@ When an address holds less XRP than its current reserve requirement, it cannot s ## Changing the Reserve Requirements -The XRP Ledger has a mechanism to adjust the reserve requirements for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](concept-fee-voting.html) for more information. +The XRP Ledger has a mechanism to adjust the reserve requirements for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information. {% include '_snippets/tx-type-links.md' %} diff --git a/content/concepts/payment-system-basics/fees.md b/content/concepts/payment-system-basics/fees.md index 3fd6c68516..8c2aaf87a8 100644 --- a/content/concepts/payment-system-basics/fees.md +++ b/content/concepts/payment-system-basics/fees.md @@ -9,13 +9,13 @@ However, the rules of the XRP Ledger include several types of fees, including ne ### Neutral Fees -The _**transaction cost**_ (sometimes called the transaction fee) is a miniscule amount of XRP destroyed to send a transaction. This cost scales with the load of the network, which protects the peer-to-peer network from spam. See [Transaction Cost](concept-transaction-cost.html) for more information. +The _**transaction cost**_ (sometimes called the transaction fee) is a miniscule amount of XRP destroyed to send a transaction. This cost scales with the load of the network, which protects the peer-to-peer network from spam. See [Transaction Cost](transaction-cost.html) for more information. -The _**reserve requirement**_ is a minimum amount of XRP that an account must hold. It increases with the number of objects the account owns in the ledger. This disincentivizes users from increasing the size of the ledger carelessly or maliciously. See [Reserves](concept-reserves.html) for more information. +The _**reserve requirement**_ is a minimum amount of XRP that an account must hold. It increases with the number of objects the account owns in the ledger. This disincentivizes users from increasing the size of the ledger carelessly or maliciously. See [Reserves](reserves.html) for more information. ### Optional Fees -_**Transfer fees**_ are optional percentage fees that issuers can charge to transfer the currencies they issue to other addresses within the XRP Ledger. See [Transfer Fees](concept-transfer-fees.html) for more information. +_**Transfer fees**_ are optional percentage fees that issuers can charge to transfer the currencies they issue to other addresses within the XRP Ledger. See [Transfer Fees](transfer-fees.html) for more information. _**Trust line quality**_ is a setting that allows an account to value balances on a trust line at higher or lower than face value. This can lead to situations that are like charging a fee. Trust line quality does not apply to XRP, which is not tied to a trust line. diff --git a/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md b/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md index 764ae387cf..e5f1f94055 100644 --- a/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md +++ b/content/concepts/payment-system-basics/transaction-basics/transaction-cost.md @@ -91,7 +91,7 @@ If none of the above occur, transactions can stay in the queue for a theoretical ## Reference Transaction Cost -The "Reference Transaction" is the cheapest (non-free) transaction, in terms of the necessary [transaction cost](concept-transaction-cost.html) before load scaling. Most transactions have the same cost as the reference transaction. Some transactions, such as [multi-signed transactions](reference-transaction-format.html#multi-signing), require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction. +The "Reference Transaction" is the cheapest (non-free) transaction, in terms of the necessary [transaction cost](transaction-cost.html) before load scaling. Most transactions have the same cost as the reference transaction. Some transactions, such as [multi-signed transactions](reference-transaction-format.html#multi-signing), require a multiple of this cost instead. When the open ledger cost escalates, the requirement is proportional to the basic cost of the transaction. ### Fee Levels @@ -101,7 +101,7 @@ _Fee levels_ represent the proportional difference between the minimum cost and |-------------|-----------------------|----------------------------|----------------------|---------------------------| | Reference transaction (most transactions) | 10 | 256 | 20 | 512 | | [Multi-signed transaction](reference-transaction-format.html#multi-signing) with 4 signatures | 50 | 256 | 100 | 512 | -| [Key reset transaction](concept-transaction-cost.html#key-reset-transaction) | 0 | (Effectively infinite) | N/A | (Effectively infinite) | +| [Key reset transaction](transaction-cost.html#key-reset-transaction) | 0 | (Effectively infinite) | N/A | (Effectively infinite) | | [EscrowFinish transaction](reference-transaction-format.html#escrowfinish) with 32-byte preimage. | 350 | 256 | 700 | 512 | @@ -130,7 +130,7 @@ The [server_state method][] returns a direct representation of `rippled`'s inter Every signed transaction must include the transaction cost in the [`Fee` field](reference-transaction-format.html#common-fields). Like all fields of a signed transaction, this field cannot be changed without invalidating the signature. -As a rule, the XRP Ledger executes transactions _exactly_ as they are signed. (To do anything else would be difficult to coordinate across a decentralized consensus network, at the least.) As a consequence of this, every transaction destroys the exact amount of XRP specified by the `Fee` field, even if the specified amount is much more than the current minimum transaction cost for any part of the network. The transaction cost can even destroy XRP that would otherwise be set aside for an account's [reserve requirement](concept-reserves.html). +As a rule, the XRP Ledger executes transactions _exactly_ as they are signed. (To do anything else would be difficult to coordinate across a decentralized consensus network, at the least.) As a consequence of this, every transaction destroys the exact amount of XRP specified by the `Fee` field, even if the specified amount is much more than the current minimum transaction cost for any part of the network. The transaction cost can even destroy XRP that would otherwise be set aside for an account's [reserve requirement](reserves.html). Before signing a transaction, we recommend [looking up the current load-based transaction cost](#querying-the-transaction-cost). If the transaction cost is high due to load scaling, you may want to wait for it to decrease. If you do not plan on submitting the transaction immediately, we recommend specifying a slightly higher transaction cost to account for future load-based fluctuations in the transaction cost. @@ -176,6 +176,6 @@ When the [FeeEscalation amendment](reference-amendments.html#feeescalation) is e ## Changing the Transaction Cost -The XRP Ledger has a mechanism for changing the minimum transaction cost to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](concept-fee-voting.html) for more information. +The XRP Ledger has a mechanism for changing the minimum transaction cost to account for long-term changes in the value of XRP. Any changes have to be approved by the consensus process. See [Fee Voting](fee-voting.html) for more information. {% include '_snippets/rippled_versions.md' %} diff --git a/content/concepts/payment-system-basics/transaction-basics/understanding-signatures-draft.md b/content/concepts/payment-system-basics/transaction-basics/understanding-signatures-draft.md index 2146f566bf..d8ee700472 100644 --- a/content/concepts/payment-system-basics/transaction-basics/understanding-signatures-draft.md +++ b/content/concepts/payment-system-basics/transaction-basics/understanding-signatures-draft.md @@ -4,7 +4,7 @@ ***TODO: Question: Added this concept section based on fantastic source material from Rome -- thought we should publish it. Useful? May be good to associate it with a flow diagram - like the one for address encoding: https://ripple.com/build/accounts/#address-encoding. Address both single and multi-sign flows.*** -In the XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. A digital signature is created based on a [key pair](concept-cryptographic-keys.html) associated with the transaction's sending account. +In the XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. A digital signature is created based on a [key pair](cryptographic-keys.html) associated with the transaction's sending account. Here's an overview of some of the more common signature-related fields used in the XRP Ledger. @@ -20,7 +20,7 @@ To verify whether a single-signed transaction is valid, a `rippled` server check 1. This key hashes to an address that's authorized by the transaction's sender. - The default is that only the address of an account is authorized to send all transactions for that account. That address is [derived from](concept-accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](concept-cryptographic-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing). ***TODO: address from Ryan: "And of course" - Nit: this seems a little informal. Maybe just drop it and go into the next sentence? JHA take a closer look at what this sentence is trying to say.*** + The default is that only the address of an account is authorized to send all transactions for that account. That address is [derived from](accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](cryptographic-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing). ***TODO: address from Ryan: "And of course" - Nit: this seems a little informal. Maybe just drop it and go into the next sentence? JHA take a closer look at what this sentence is trying to say.*** 2. This key matches the signature on the transaction. @@ -63,7 +63,7 @@ Verifying a [multi-signed transaction](reference-transaction-format.html#multi-s The public key of one signer. Verifying a [multi-signed transaction](reference-transaction-format.html#multi-signing) involves making sure each such key is authorized to sign for the `AccountID` of the signer. -Multi-signature `AccountIDs` are a little special. If one is an address that doesn't exist in the ledger, then the `SigningPubKey` must hash to the `AccountID` value using the standard rules for [deriving an AccountID](concept-accounts.html#address-encoding) from a public key. If the address does exist in the ledger, then either: +Multi-signature `AccountIDs` are a little special. If one is an address that doesn't exist in the ledger, then the `SigningPubKey` must hash to the `AccountID` value using the standard rules for [deriving an AccountID](accounts.html#address-encoding) from a public key. If the address does exist in the ledger, then either: 1. The `SigningPubKey` must hash to the `AccountID` and the address must not have the master key disabled. diff --git a/content/concepts/the-rippled-server/stand-alone-mode.md b/content/concepts/the-rippled-server/stand-alone-mode.md index 36c7ee3624..1a136fc7f7 100644 --- a/content/concepts/the-rippled-server/stand-alone-mode.md +++ b/content/concepts/the-rippled-server/stand-alone-mode.md @@ -1,6 +1,6 @@ # Stand-Alone Mode -You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](concept-amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network. +You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network. When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from: diff --git a/content/news/known-amendments.md b/content/news/known-amendments.md index f2db62c6b7..bec0d76e79 100644 --- a/content/news/known-amendments.md +++ b/content/news/known-amendments.md @@ -84,9 +84,9 @@ Adds a new account flag, `DepositAuth`, which lets an account strictly reject an When an account enables this flag, Payment transactions fail if the account is the destination, regardless of whether the Payment would have delivered XRP or an issued currency. EscrowFinish and PaymentChannelClaim transactions fail if the account is the destination unless the destination account itself sends those transactions. If the [Checks][] amendment is enabled, the account can receive XRP or issued currencies by sending CheckCash transactions. -As an exception, accounts with `DepositAuth` enabled can receive Payment transactions for small amounts of XRP (equal or less than the minimum [account reserve](concept-reserves.html)) if their current XRP balance is below the account reserve. +As an exception, accounts with `DepositAuth` enabled can receive Payment transactions for small amounts of XRP (equal or less than the minimum [account reserve](reserves.html)) if their current XRP balance is below the account reserve. -Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where they mistakenly enforced the DisallowXRP flag, which is meant to be a non-binding advisory flag. (By not enforcing DisallowXRP in the ledger itself an account can still receive the necessary XRP to meet its [account reserve](concept-reserves.html) and pay [transaction costs](concept-transaction-cost.html).) +Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where they mistakenly enforced the DisallowXRP flag, which is meant to be a non-binding advisory flag. (By not enforcing DisallowXRP in the ledger itself an account can still receive the necessary XRP to meet its [account reserve](reserves.html) and pay [transaction costs](transaction-cost.html).) **Caution:** This amendment is [in development](https://github.com/ripple/rippled/pull/2239) and is expected for `rippled` v0.90.0. @@ -104,9 +104,9 @@ Introduces two new transaction error codes, `tecINVARIANT_FAILED` and `tefINVARI Examples of invariant checks: -- The total amount of XRP destroyed by a transaction must match the [transaction cost](concept-transaction-cost.html) exactly. +- The total amount of XRP destroyed by a transaction must match the [transaction cost](transaction-cost.html) exactly. - XRP cannot be created. -- [`AccountRoot` objects in the ledger](reference-ledger-format.html#accountroot) cannot be deleted. (See also: [Permanence of Accounts](concept-accounts.html#permanence-of-accounts).) +- [`AccountRoot` objects in the ledger](reference-ledger-format.html#accountroot) cannot be deleted. (See also: [Permanence of Accounts](accounts.html#permanence-of-accounts).) - [An object in the ledger](reference-ledger-format.html#ledger-object-types) cannot change its type. (The `LedgerEntryType` field is immutable.) - There cannot be a trust line for XRP. @@ -130,7 +130,7 @@ Provides "suspended payments" for XRP for escrow within the XRP Ledger, includin |:-----------------------------------------------------------------|:----------| | 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE | Enabled | -Changes the way the [transaction cost](concept-transaction-cost.html) applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost. +Changes the way the [transaction cost](transaction-cost.html) applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost. This amendment introduces a fixed-size transaction queue for transactions that were not able to be included in the previous consensus round. If the `rippled` servers in the consensus network are under heavy load, they queue the transactions with the lowest transaction cost for later ledgers. Each consensus round prioritizes transactions from the queue with the largest transaction cost (`Fee` value), and includes as many transactions as the consensus network can process. If the transaction queue is full, transactions drop from the queue entirely, starting with the ones that have the lowest transaction cost. @@ -150,7 +150,7 @@ A transaction remains in the queue until one of the following happens: |:-----------------------------------------------------------------|:----------| | B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD | Enabled | -Correctly implements a limit on [transfer fees](concept-transfer-fees.html) to a 100% fee, represented by a maximum `TransferRate` value of `2000000000`. (A 100% fee in this case means you must send 2 units of the issued currency for every 1 unit you want to deliver.) Without the amendment, the effective limit is a `TransferRate` value of 232-1, for approximately a 329% fee. +Correctly implements a limit on [transfer fees](transfer-fees.html) to a 100% fee, represented by a maximum `TransferRate` value of `2000000000`. (A 100% fee in this case means you must send 2 units of the issued currency for every 1 unit you want to deliver.) Without the amendment, the effective limit is a `TransferRate` value of 232-1, for approximately a 329% fee. With this amendment enabled, an [AccountSet][] transaction that attempts to set `TransferRate` higher than `2000000000` fails with the result code `temBAD_TRANSFER_RATE`. Any existing `TransferRate` which was set to a higher value under the previous rules continues to apply at the higher rate. @@ -172,9 +172,9 @@ Fixes a minor bug in transaction processing that causes some payments to fail wh |:-----------------------------------------------------------------|:----------| | 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC | Enabled | -Fixes a minor bug in transaction processing that causes failures when trying to prepare certain [payment paths](concept-paths.html) for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail. +Fixes a minor bug in transaction processing that causes failures when trying to prepare certain [payment paths](paths.html) for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail. -The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose [steps](concept-paths.html#path-specifications) include conflicting fields and paths that loop through the same object more than once. +The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose [steps](paths.html#path-specifications) include conflicting fields and paths that loop through the same object more than once. ## fix1512 @@ -184,7 +184,7 @@ The fix1373 amendment corrects the issue so that the paths are properly prepared |:-----------------------------------------------------------------|:----------| | 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 | Enabled | -Fixes a bug in transaction processing that causes some invalid [PaymentChannelClaim][] transactions to fail with the wrong error code. Without this amendment, the transactions have a `tec`-class result code despite not being included in a ledger and therefore not paying the [transaction cost](concept-transaction-cost.html). +Fixes a bug in transaction processing that causes some invalid [PaymentChannelClaim][] transactions to fail with the wrong error code. Without this amendment, the transactions have a `tec`-class result code despite not being included in a ledger and therefore not paying the [transaction cost](transaction-cost.html). With this amendment, the transactions fail with a more appropriate result code, `temBAD_AMOUNT`, instead. @@ -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 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][]. +Adds tracking by destination account to [escrows](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. @@ -292,7 +292,7 @@ An address with a SignerList can disable the master key even if a regular key is |:-----------------------------------------------------------------|:----------| | 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 | In development | -Fixes an inconsistency in the way [transfer fees](concept-transfer-fees.html) are calculated between [OfferCreate](reference-transaction-format.html#offercreate) and [Payment](reference-transaction-format.html#payment) transaction types. Without this amendment, the holder of the issuances pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. +Fixes an inconsistency in the way [transfer fees](transfer-fees.html) are calculated between [OfferCreate](reference-transaction-format.html#offercreate) and [Payment](reference-transaction-format.html#payment) transaction types. Without this amendment, the holder of the issuances pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected. This Amendment requires the [Flow Amendment](#flow) to be enabled. @@ -378,7 +378,7 @@ Introduces a `TickSize` field to accounts, which can be set with the [AccountSet |:-----------------------------------------------------------------|:----------| | 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC | Enabled | -Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Trust Lines](concept-authorized-trust-lines.html). +Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Trust Lines](authorized-trust-lines.html). With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](reference-transaction-format.html#trustset-flags) can create a new [`RippleState` ledger object](reference-ledger-format.html#ripplestate) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](reference-ledger-format.html#ripplestate-flags) enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](reference-ledger-format.html#accountroot-flags) by sending an [AccountSet transaction](reference-transaction-format.html#accountset) with the [asfRequireAuth flag enabled](reference-transaction-format.html#accountset-flags). diff --git a/content/references/data-api.md b/content/references/data-api.md index d6f75830ed..d82b7d2e77 100644 --- a/content/references/data-api.md +++ b/content/references/data-api.md @@ -2233,7 +2233,7 @@ Response: ## Get Transaction Costs [[Source]
](https://github.com/ripple/rippled-historical-database/blob/develop/api/routes/network/getFees.js "Source") -Returns [transaction cost](concept-transaction-cost.html) stats per ledger, hour, or day. The data shows the average, minimum, maximum, and total transaction costs paid for the given interval or ledger. _(New in [v2.2.0][])_ +Returns [transaction cost](transaction-cost.html) stats per ledger, hour, or day. The data shows the average, minimum, maximum, and total transaction costs paid for the given interval or ledger. _(New in [v2.2.0][])_ #### Request Format @@ -3282,7 +3282,7 @@ Each field in the top level JSON object is a [Currency Code][]. The content of e | Field | Value | Description | |----------|---------|-------------| | `name` | String | A human-readable proper name for the gateway. | -| `account` | String - [Address][] | The [issuing address](concept-issuing-and-operational-addresses.html) of this currency. | +| `account` | String - [Address][] | The [issuing address](issuing-and-operational-addresses.html) of this currency. | | `featured` | Boolean | Whether this gateway is considered a "featured" issuer of the currency. Ripple decides which gateways to feature based on responsible business practices, volume, and other measures. | | `label` | String | (May be omitted) Only provided when the [Currency Code][] is a 40-character hexadecimal value. This is an alternate human-readable name for the currency issued by this gateway. | `assets` | Array of Strings | Graphics filenames available for this gateway, if any. (Mostly, these are logos used by XRP Charts.) | @@ -3384,8 +3384,8 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the |-------------|--------|-------------| | `name` | String | Human-readable name of the gateway. | | `start_date` | String - [Timestamp][] | The approximate date of the first time exchanges for this gateway's currencies appeared in the ledger. | -| `accounts` | Array | A list of [issuing addresses](concept-issuing-and-operational-addresses.html) used by this gateway. (Gateways may use different issuing accounts for different currencies.) | -| `hotwallets` | Array of [Address][]es | This gateway's [operational addresses](concept-issuing-and-operational-addresses.html). | +| `accounts` | Array | A list of [issuing addresses](issuing-and-operational-addresses.html) used by this gateway. (Gateways may use different issuing accounts for different currencies.) | +| `hotwallets` | Array of [Address][]es | This gateway's [operational addresses](issuing-and-operational-addresses.html). | | `domain` | String | The domain name where this gateway does business. Typically the gateway hosts a [`ripple.txt`](https://wiki.ripple.com/Ripple.txt) there. | | `normalized` | String | A normalized version of the `name` field suitable for including in URLs. | | `assets` | Array of Strings | Graphics filenames available for this gateway, if any. (Mostly, these are logos used by XRP Charts.) | @@ -3394,7 +3394,7 @@ Each object in the `accounts` field array has the following fields: | Field | Value | Description | |------------|--------|-------------| -| `address` | String | The [issuing address](concept-issuing-and-operational-addresses.html) used by this gateway. | +| `address` | String | The [issuing address](issuing-and-operational-addresses.html) used by this gateway. | | `currencies` | Object | Each field in this object is a [Currency Code][] corresponding to a currency issued from this address. Each value is an object with a `featured` boolean indicating whether that currency is featured. Ripple decides which currencies and gateways to feature based on responsible business practices, volume, and other measures. | #### Example 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 8ffefaa99f..99b7a2cbab 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](concept-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](reference-transaction-format.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.) @@ -180,7 +180,7 @@ You can also use this method to generate a key pair to use as a regular key pair In addition to using it as a regular key pair, you can also use it as a member of a multi-signing list (SignerList). -For more information about master and regular key pairs, see [Cryptographic Keys](concept-cryptographic-keys.html) +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). diff --git a/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/feature.md b/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/feature.md index 22e5a2dd76..7cfcd96235 100644 --- a/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/feature.md +++ b/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/feature.md @@ -1,9 +1,9 @@ # feature [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/Feature1.cpp "Source") -The `feature` command returns information about [amendments](concept-amendments.html) this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the [amendment process](concept-amendments.html#amendment-process). [New in: rippled 0.31.0][] +The `feature` command returns information about [amendments](amendments.html) this server knows about, including whether they are enabled and whether the server is voting in favor of those amendments in the [amendment process](amendments.html#amendment-process). [New in: rippled 0.31.0][] -You can use the `feature` command to temporarily configure the server to vote against or in favor of an amendment. This change does not persist if you restart the server. To make lasting changes in amendment voting, use the `rippled.cfg` file. See [Configuring Amendment Voting](concept-amendments.html#configuring-amendment-voting) for more information. +You can use the `feature` command to temporarily configure the server to vote against or in favor of an amendment. This change does not persist if you restart the server. To make lasting changes in amendment voting, use the `rippled.cfg` file. See [Configuring Amendment Voting](amendments.html#configuring-amendment-voting) for more information. _The `feature` method is an [admin command](#connecting-to-rippled) that cannot be run by unprivileged users._ @@ -177,7 +177,7 @@ The response follows the [standard format](#response-formatting), with a success |:------------|:--------|:-----------------------------------------------------| | `enabled` | Boolean | Whether this amendment is currently enabled in the latest ledger. | | `name` | String | (May be omitted) The human-readable name for this amendment, if known. | -| `supported` | Boolean | Whether the server knows how to apply this amendment. If this field is set to `false` (the server does not know how to apply this amendment) and `enabled` is set to `true` (this amendment is enabled in the latest ledger), this amendment may cause your server to be [amendment blocked](concept-amendments.html#amendment-blocked). | +| `supported` | Boolean | Whether the server knows how to apply this amendment. If this field is set to `false` (the server does not know how to apply this amendment) and `enabled` is set to `true` (this amendment is enabled in the latest ledger), this amendment may cause your server to be [amendment blocked](amendments.html#amendment-blocked). | | `vetoed` | Boolean | Whether the server has been instructed to vote against this amendment. | **Caution:** The `name` for an amendment does not strictly indicate what that amendment does. The name is not guaranteed to be unique or consistent across servers. diff --git a/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md b/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md index 2f03fa4887..de05f8e8a1 100644 --- a/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md +++ b/content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md @@ -382,7 +382,7 @@ Each field of the `cluster` object is the public key of that `rippled` server's | `Field` | Type | Description | |:--------|:-------|:----------------------------------------------------------| | `tag` | String | The display name for this cluster member as defined in the config file. | -| `fee` | Number | (May be omitted) The load multiplier this cluster member is applying to the [transaction cost](concept-transaction-cost.html) | +| `fee` | Number | (May be omitted) The load multiplier this cluster member is applying to the [transaction cost](transaction-cost.html) | | `age` | Number | The number of seconds since the last cluster report from this cluster member. | Each member of the `peers` array is a peer object with the following fields: diff --git a/content/references/rippled-api/api-conventions/basic-data-types.md b/content/references/rippled-api/api-conventions/basic-data-types.md index 1f9281d58e..0710de1d4a 100644 --- a/content/references/rippled-api/api-conventions/basic-data-types.md +++ b/content/references/rippled-api/api-conventions/basic-data-types.md @@ -2,7 +2,7 @@ Different types of objects are uniquely identified in different ways: -[Accounts](concept-accounts.html) are identified by their [Address][], for example `"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`. Addresses always start with "r". Many `rippled` methods also accept a hexadecimal representation. +[Accounts](accounts.html) are identified by their [Address][], for example `"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`. Addresses always start with "r". Many `rippled` methods also accept a hexadecimal representation. [Transactions](reference-transaction-format.html) are identified by a [Hash][] of the transaction's binary format. You can also identify a transaction by its sending account and [Sequence Number][]. diff --git a/content/references/rippled-api/api-conventions/currency-formatting.md b/content/references/rippled-api/api-conventions/currency-formatting.md index 3b981264ee..d3d1272da1 100644 --- a/content/references/rippled-api/api-conventions/currency-formatting.md +++ b/content/references/rippled-api/api-conventions/currency-formatting.md @@ -1,6 +1,6 @@ # Currency Formats -The XRP Ledger has [two kinds of money](concept-money.html): XRP, and issued currencies. In the XRP Ledger, both types have high precision, although their formats are different. +The XRP Ledger has [two kinds of money](money.html): XRP, and issued currencies. In the XRP Ledger, both types have high precision, although their formats are different. ## String Formatting @@ -38,7 +38,7 @@ When transmitting non-XRP amounts across the network or recording them in ledger ## Currency Codes -All non-XRP currencies in the XRP Ledger have a 160-bit currency code. The [`rippled` APIs](reference-rippled.html) map 3-character ASCII strings (case-sensitive) to 160-bit currency codes using a standard mapping. The currency code `XRP` is disallowed for issued currencies. Currencies with the same code can [ripple](concept-noripple.html) across connected trustlines. Currency codes have no other behavior built into the XRP Ledger. +All non-XRP currencies in the XRP Ledger have a 160-bit currency code. The [`rippled` APIs](reference-rippled.html) map 3-character ASCII strings (case-sensitive) to 160-bit currency codes using a standard mapping. The currency code `XRP` is disallowed for issued currencies. Currencies with the same code can [ripple](noripple.html) across connected trustlines. Currency codes have no other behavior built into the XRP Ledger. ### Standard Currency Codes @@ -57,4 +57,4 @@ The standard currency mapping allocates the bits as follows: You can also issue currency of other types by using a 160-bit (40-character) hexadecimal string such as `015841551A748AD2C1F76FF6ECB0CCCD00000000` as the currency code. To prevent this from being treated as a different currency code type, the first 8 bits MUST NOT be `0x00`. -**Deprecated:** Some previous versions of [ripple-lib](https://github.com/ripple/ripple-lib) supported an "interest-bearing" or "demurraging" currency code type. These currencies have the first 8 bits `0x01`. Demurraging / interest-bearing currencies are no longer supported, but you may encounter them in ledger data. For more information, see [Demurrage](concept-demurrage.html). +**Deprecated:** Some previous versions of [ripple-lib](https://github.com/ripple/ripple-lib) supported an "interest-bearing" or "demurraging" currency code type. These currencies have the first 8 bits `0x01`. Demurraging / interest-bearing currencies are no longer supported, but you may encounter them in ledger data. For more information, see [Demurrage](demurrage.html). diff --git a/content/references/rippled-api/api-conventions/modifying-the-ledger.md b/content/references/rippled-api/api-conventions/modifying-the-ledger.md index 23de23dcd8..da342b5a01 100644 --- a/content/references/rippled-api/api-conventions/modifying-the-ledger.md +++ b/content/references/rippled-api/api-conventions/modifying-the-ledger.md @@ -1,6 +1,6 @@ # Modifying the Ledger -All changes to the XRP Ledger happen as the result of transactions. The only API methods that can change the contents of the XRP Ledger are the commands that submit transactions. Even then, changes only apply permanently if the transactions are approved by the [consensus process](concept-consensus.html). Most other public methods represent different ways to view the data represented in the XRP Ledger, or request information about the state of the server. +All changes to the XRP Ledger happen as the result of transactions. The only API methods that can change the contents of the XRP Ledger are the commands that submit transactions. Even then, changes only apply permanently if the transactions are approved by the [consensus process](consensus.html). Most other public methods represent different ways to view the data represented in the XRP Ledger, or request information about the state of the server. Transaction submission commands: diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md index 754381671c..b32264f924 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/accountroot.md @@ -56,8 +56,8 @@ AccountRoot objects can have the following flag values: | Flag Name | Hex Value | Decimal Value | Description | Corresponding [AccountSet Flag](accountset.html#accountset-flags) | |-----------|-----------|---------------|-------------|-------------------------------| -| lsfDefaultRipple | 0x00800000 | 8388608 | Enable [rippling](concept-noripple.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. | asfDefaultRipple | -| lsfDepositAuth | 0x01000000 | 16777216 | This account can only receive funds from transactions it sends. (It has [DepositAuth](concept-depositauth.html) enabled.) | asfDepositAuth | +| lsfDefaultRipple | 0x00800000 | 8388608 | Enable [rippling](noripple.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. | asfDefaultRipple | +| lsfDepositAuth | 0x01000000 | 16777216 | This account can only receive funds from transactions it sends. (It has [DepositAuth](depositauth.html) enabled.) | asfDepositAuth | | lsfDisableMaster | 0x00100000 | 1048576 | Disallows use of the master key to sign transactions for this account. | asfDisableMaster | | lsfDisallowXRP | 0x00080000 | 524288 | Client applications should not send XRP to this account. Not enforced by `rippled`. | asfDisallowXRP | | lsfGlobalFreeze | 0x00400000 | 4194304 |　All assets issued by this address are frozen. | asfGlobalFreeze | 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 978358d523..bd681cc009 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 @@ -1,7 +1,7 @@ # Amendments [[Source]
](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/LedgerFormats.cpp#L110-L113 "Source") -The `Amendments` object type contains a list of [Amendments](concept-amendments.html) that are currently active. Each ledger version contains **at most one** `Amendments` object. +The `Amendments` object type contains a list of [Amendments](amendments.html) that are currently active. Each ledger version contains **at most one** `Amendments` object. ## Example {{currentpage.name}} JSON @@ -31,7 +31,7 @@ The `Amendments` object type contains a list of [Amendments](concept-amendments. | Name | JSON Type | [Internal Type][] | Description | |-------------------|-----------|-------------------|-------------| -| `Amendments` | Array | STI_VECTOR256 | _(Optional)_ Array of 256-bit [amendment IDs](concept-amendments.html#about-amendments) for all currently-enabled amendments. If omitted, there are no enabled amendments. | +| `Amendments` | Array | STI_VECTOR256 | _(Optional)_ Array of 256-bit [amendment IDs](amendments.html#about-amendments) for all currently-enabled amendments. If omitted, there are no enabled amendments. | | `Majorities` | Array | STI_ARRAY | _(Optional)_ Array of objects describing the status of amendments that have majority support but are not yet enabled. If omitted, there are no pending amendments with majority support. | | `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for the Amendments object type, so this value is always `0`. | | `LedgerEntryType` | String | UInt16 | The value `0x0066`, mapped to the string `Amendments`, indicates that this object describes the status of amendments to the XRP Ledger. | @@ -43,7 +43,7 @@ Each member of the `Majorities` field, if it is present, is an object with one f | `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. | -In the [amendment process](concept-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. +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. **Note:** Technically, all transactions in a ledger are processed based on which amendments are enabled in the ledger version immediately before it. While applying transactions to a ledger version where an amendment becomes enabled, the rules don't change mid-ledger. After the ledger is closed, the next ledger uses the new rules as defined by any new amendments that applied. diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md index 639a5de0be..7cf88952de 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/check.md @@ -3,7 +3,7 @@ _Requires the [Checks Amendment](reference-amendments.html#checks)._ -A `Check` object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an [Escrow](concept-escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.) +A `Check` object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an [Escrow](escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.) ## Example {{currentpage.name}} JSON diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.md index 1c4d219847..4221e77bb9 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/feesettings.md @@ -1,7 +1,7 @@ # FeeSettings [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120 "Source") -The `FeeSettings` object type contains the current base [transaction cost](concept-transaction-cost.html) and [reserve amounts](concept-reserves.html) as determined by [fee voting](concept-fee-voting.html). Each ledger version contains **at most one** `FeeSettings` object. +The `FeeSettings` object type contains the current base [transaction cost](transaction-cost.html) and [reserve amounts](reserves.html) as determined by [fee voting](fee-voting.html). Each ledger version contains **at most one** `FeeSettings` object. ## Example {{currentpage.name}} JSON @@ -26,10 +26,10 @@ The `FeeSettings` object has the following fields: | Name | JSON Type | [Internal Type][] | Description | |:--------------------|:----------|:------------------|:-----------------------| | `LedgerEntryType` | String | UInt16 | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. | -| `BaseFee` | String | UInt64 | The [transaction cost](concept-transaction-cost.html) of the "reference transaction" in drops of XRP as hexadecimal. | +| `BaseFee` | String | UInt64 | The [transaction cost](transaction-cost.html) of the "reference transaction" in drops of XRP as hexadecimal. | | `ReferenceFeeUnits` | Number | UInt32 | The `BaseFee` translated into "fee units". | -| `ReserveBase` | Number | UInt32 | The [base reserve](concept-reserves.html#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. | -| `ReserveIncrement` | Number | UInt32 | The incremental [owner reserve](concept-reserves.html#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. | +| `ReserveBase` | Number | UInt32 | The [base reserve](reserves.html#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. | +| `ReserveIncrement` | Number | UInt32 | The incremental [owner reserve](reserves.html#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. | | `Flags` | Number | UInt32 | A bit-map of boolean flags for this object. No flags are defined for this type. | **Warning:** The JSON format for this ledger object type is unusual. The `BaseFee`, `ReserveBase`, and `ReserveIncrement` indicate drops of XRP but ***not*** in the usual format for [specifying XRP](reference-rippled.html#specifying-currency-amounts). diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md index 277834e339..8d6f0de3e1 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/ripplestate.md @@ -42,7 +42,7 @@ A `RippleState` object has the following fields: |-----------------|-----------|---------------|-------------| | `LedgerEntryType` | String | UInt16 | The value `0x0072`, mapped to the string `RippleState`, indicates that this object is a RippleState object. | | `Flags` | Number | UInt32 | A bit-map of boolean options enabled for this object. | -| `Balance` | Object | Amount | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the low account has issued currency to the high account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](concept-accounts.html#special-addresses). | +| `Balance` | Object | Amount | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the low account has issued currency to the high account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](accounts.html#special-addresses). | | `LowLimit` | Object | Amount | The limit that the low account has set on the trust line. The `issuer` is the address of the low account that set this limit. | | `HighLimit` | Object | Amount | The limit that the high account has set on the trust line. The `issuer` is the address of the high account that set this limit. | | `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. | @@ -66,14 +66,14 @@ RippleState objects can have the following flag values: | lsfHighReserve | 0x00020000 |131072 | This RippleState object [contributes to the high account's owner reserve](#contributing-to-the-owner-reserve). | (None) | | lsfLowAuth | 0x00040000 | 262144 | The low account has authorized the high account to hold the low account's issuances. | tfSetAuth | | lsfHighAuth | 0x00080000 | 524288 | The high account has authorized the low account to hold the high account's issuances. | tfSetAuth | -| lsfLowNoRipple | 0x00100000 | 1048576 | The low account [has disabled rippling](concept-noripple.html) from this trust line to other trust lines with the same account's NoRipple flag set. | tfSetNoRipple | -| lsfHighNoRipple | 0x00200000 | 2097152 | The high account [has disabled rippling](concept-noripple.html) from this trust line to other trust lines with the same account's NoRipple flag set. | tfSetNoRipple | +| lsfLowNoRipple | 0x00100000 | 1048576 | The low account [has disabled rippling](noripple.html) from this trust line to other trust lines with the same account's NoRipple flag set. | tfSetNoRipple | +| lsfHighNoRipple | 0x00200000 | 2097152 | The high account [has disabled rippling](noripple.html) from this trust line to other trust lines with the same account's NoRipple flag set. | tfSetNoRipple | | lsfLowFreeze | 0x00400000 | 4194304 | The low account has frozen the trust line, preventing the high account from transferring the asset. | tfSetFreeze | | lsfHighFreeze | 0x00800000 | 8388608 | The high account has frozen the trust line, preventing the low account from transferring the asset. | tfSetFreeze | ## Contributing to the Owner Reserve -If an account modifies a trust line to put it in a non-default state, then that trust line counts towards the account's [owner reserve](concept-reserves.html#owner-reserves). In a RippleState object, the `lsfLowReserve` and `lsfHighReserve` flags indicate which account(s) are responsible for the owner reserve. The `rippled` server automatically sets these flags when it modifies a trust line. +If an account modifies a trust line to put it in a non-default state, then that trust line counts towards the account's [owner reserve](reserves.html#owner-reserves). In a RippleState object, the `lsfLowReserve` and `lsfHighReserve` flags indicate which account(s) are responsible for the owner reserve. The `rippled` server automatically sets these flags when it modifies a trust line. The values that count towards a trust line's non-default state are as follows: diff --git a/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md b/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md index 7dc7414975..9f19543801 100644 --- a/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md +++ b/content/references/rippled-api/ledger-data-formats/ledger-object-types/signerlist.md @@ -50,7 +50,7 @@ A `SignerList` object has the following fields: | `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. | | `OwnerNode` | String | UInt64 | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. | | `SignerEntries` | Array | Array | An array of SignerEntry objects representing the parties who are part of this signer list. | -| `SignerListID` | Number | UInt32 | An ID for this signer list. Currently always set to `0`. If a future [amendment](concept-amendments.html) allows multiple signer lists for an account, this may change. | +| `SignerListID` | Number | UInt32 | An ID for this signer list. Currently always set to `0`. If a future [amendment](amendments.html) allows multiple signer lists for an account, this may change. | | `SignerQuorum` | Number | UInt32 | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. | The `SignerEntries` may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys. @@ -68,7 +68,7 @@ When processing a multi-signed transaction, the server dereferences the `Account ## SignerLists and Reserves -A SignerList contributes to its owner's [reserve requirement](concept-reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) object in the ledger. +A SignerList contributes to its owner's [reserve requirement](reserves.html). The SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](#ripplestate)) or [Offer](#offer) object in the ledger. ## SignerList ID Format diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md index 5ccff43de9..47ecce75e4 100644 --- a/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md +++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_currencies.md @@ -138,7 +138,7 @@ The response follows the [standard format](#response-formatting), with a success | `send_currencies` | Array of Strings | Array of [Currency Code][]s for currencies that this account can send. | | `validated` | Boolean | If `true`, this data comes from a validated ledger. | -**Note:** The currencies that an account can send or receive are defined based on a check of its trust lines. If an account has a trust line for a currency and enough room to increase its balance, it can receive that currency. If the trust line's balance can go down, the account can send that currency. This method _doesn't_ check whether the trust line is [frozen](concept-freeze.html) or authorized. +**Note:** The currencies that an account can send or receive are defined based on a check of its trust lines. If an account has a trust line for a currency and enough room to increase its balance, it can receive that currency. If the trust line's balance can go down, the account can send that currency. This method _doesn't_ check whether the trust line is [frozen](freeze.html) or authorized. ## Possible Errors 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 ded398d53a..38643ba222 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 @@ -176,7 +176,7 @@ The response follows the [standard format](#response-formatting), with the resul | `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][] | | `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](concept-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. | +| `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. | | `validated` | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. [New in: rippled 0.26.0][] | The `queue_data` parameter, if present, contains the following fields: @@ -195,7 +195,7 @@ Each object in the `transactions` array, if present, may contain any or all of t | `Field` | Type | Description | |:------------------|:--------|:-----------------------------------------------| | `auth_change` | Boolean | Whether this transaction changes this address's [ways of authorizing transactions](reference-transaction-format.html#authorizing-transactions). | -| `fee` | String | The [Transaction Cost](concept-transaction-cost.html) of this transaction, in [drops of XRP](#specifying-currency-amounts). | +| `fee` | String | The [Transaction Cost](transaction-cost.html) of this transaction, in [drops of XRP](#specifying-currency-amounts). | | `fee_level` | String | The transaction cost of this transaction, relative to the minimum cost for this type of transaction, in [fee levels][]. | | `max_spend_drops` | String | The maximum amount of XRP, [in drops](#specifying-currency-amounts), this transaction could send or destroy. | | `seq` | Integer | The [Sequence Number][] of this transaction. | diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md b/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md index 68708c834e..3a923ff0b0 100644 --- a/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md +++ b/content/references/rippled-api/public-rippled-methods/account-methods/account_lines.md @@ -170,12 +170,12 @@ Each trust line object has some combination of the following fields: | `limit_peer` | String | The maximum amount of currency that the counterparty account is willing to owe the perspective account | | `quality_in` | Unsigned Integer | Rate at which the account values incoming balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. | | `quality_out` | Unsigned Integer | Rate at which the account values outgoing balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. | -| `no_ripple` | Boolean | (May be omitted) `true` if this account has enabled the [NoRipple flag](concept-noripple.html) for this line. If omitted, that is the same as `false`. | -| `no_ripple_peer` | Boolean | (May be omitted) `true` if the peer account has enabled the [NoRipple flag](concept-noripple.html). If omitted, that is the same as `false`. | -| `authorized` | Boolean | (May be omitted) `true` if this account has [authorized this trust line](concept-authorized-trust-lines.html). If omitted, that is the same as `false`. | -| `peer_authorized`| Boolean | (May be omitted) `true` if the peer account has [authorized this trust line](concept-authorized-trust-lines.html). If omitted, that is the same as `false`. | -| `freeze` | Boolean | (May be omitted) `true` if this account has [frozen](concept-freeze.html) this trust line. If omitted, that is the same as `false`. | -| `freeze_peer` | Boolean | (May be omitted) `true` if the peer account has [frozen](concept-freeze.html) this trust line. If omitted, that is the same as `false`. | +| `no_ripple` | Boolean | (May be omitted) `true` if this account has enabled the [NoRipple flag](noripple.html) for this line. If omitted, that is the same as `false`. | +| `no_ripple_peer` | Boolean | (May be omitted) `true` if the peer account has enabled the [NoRipple flag](noripple.html). If omitted, that is the same as `false`. | +| `authorized` | Boolean | (May be omitted) `true` if this account has [authorized this trust line](authorized-trust-lines.html). If omitted, that is the same as `false`. | +| `peer_authorized`| Boolean | (May be omitted) `true` if the peer account has [authorized this trust line](authorized-trust-lines.html). If omitted, that is the same as `false`. | +| `freeze` | Boolean | (May be omitted) `true` if this account has [frozen](freeze.html) this trust line. If omitted, that is the same as `false`. | +| `freeze_peer` | Boolean | (May be omitted) `true` if the peer account has [frozen](freeze.html) this trust line. If omitted, that is the same as `false`. | ## Possible Errors diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md b/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md index 4f9149d267..7217e69c5f 100644 --- a/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md +++ b/content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md @@ -1,7 +1,7 @@ # gateway_balances [[Source]
](https://github.com/ripple/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/GatewayBalances.cpp "Source") -The `gateway_balances` command calculates the total balances issued by a given account, optionally excluding amounts held by [operational addresses](concept-issuing-and-operational-addresses.html). [New in: rippled 0.28.2][] +The `gateway_balances` command calculates the total balances issued by a given account, optionally excluding amounts held by [operational addresses](issuing-and-operational-addresses.html). [New in: rippled 0.28.2][] ## Request Format An example of the request format: @@ -46,9 +46,9 @@ The request includes the following parameters: | `Field` | Type | Description | |:---------------|:---------------------------|:-------------------------------| -| `account` | String | The [Address][] to check. This should be the [issuing address](concept-issuing-and-operational-addresses.html) | +| `account` | String | The [Address][] to check. This should be the [issuing address](issuing-and-operational-addresses.html) | | `strict` | Boolean | _(Optional)_ If true, only accept an address or public key for the account parameter. Defaults to false. | -| `hotwallet` | String or Array | An [operational address](concept-issuing-and-operational-addresses.html) to exclude from the balances issued, or an array of such addresses. | +| `hotwallet` | String or Array | An [operational address](issuing-and-operational-addresses.html) to exclude from the balances issued, or an array of such addresses. | | `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-ledgers)) | | `ledger_index` | String or Unsigned Integer | _(Optional)_ The sequence number of the ledger version to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) | @@ -204,7 +204,7 @@ The response follows the [standard format](#response-formatting), with a success | `account` | String | Unique [Address][] identifying the account that issued the balances. | | `obligations` | Object | (Omitted if empty) Total amounts issued to addresses not excluded, as a map of currencies to the total value issued. | | `balances` | Object | (Omitted if empty) Amounts issued to the `hotwallet` addresses from the request. The keys are addresses and the values are arrays of currency amounts they hold. | -| `assets` | Object | (Omitted if empty) Total amounts held that are issued by others. In the recommended configuration, the [issuing address](concept-issuing-and-operational-addresses.html) should have none. | +| `assets` | Object | (Omitted if empty) Total amounts held that are issued by others. In the recommended configuration, the [issuing address](issuing-and-operational-addresses.html) should have none. | | `ledger_hash` | String | (May be omitted) The identifying hash of the ledger that was used to generate this response. | | `ledger_index` | Number | (May be omitted) The sequence number of the ledger version that was used to generate this response. | | `ledger_current_index` | Number | (May be omitted) The sequence number of the current in-progress ledger version that was used to generate this response. | diff --git a/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md b/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md index 047fac9a89..791e39db24 100644 --- a/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md +++ b/content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md @@ -1,7 +1,7 @@ # noripple_check [[Source]
](https://github.com/ripple/rippled/blob/9111ad1a9dc37d49d085aa317712625e635197c0/src/ripple/rpc/handlers/NoRippleCheck.cpp "Source") -The `noripple_check` command provides a quick way to check the status of [the DefaultRipple field for an account and the NoRipple flag of its trust lines](concept-noripple.html), compared with the recommended settings. +The `noripple_check` command provides a quick way to check the status of [the DefaultRipple field for an account and the NoRipple flag of its trust lines](noripple.html), compared with the recommended settings. ## Request Format An example of the request format: diff --git a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md index b8fafc58f0..eb364a02aa 100644 --- a/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md +++ b/content/references/rippled-api/public-rippled-methods/ledger-methods/ledger.md @@ -66,7 +66,7 @@ The request can contain the following parameters: | `expand` | Boolean | _(Optional)_ Provide full JSON-formatted information for transaction/account information instead of only hashes. Defaults to `false`. Ignored unless you request transactions, accounts, or both. | | `owner_funds` | Boolean | _(Optional)_ If `true`, include `owner_funds` field in the metadata of OfferCreate transactions in the response. Defaults to `false`. Ignored unless transactions are included and `expand` is true. | | `binary` | Boolean | _(Optional)_ If `true`, and `transactions` and `expand` are both also `true`, return transaction information in binary format (hexadecimal string) instead of JSON format. [New in: rippled 0.28.0][] | -| `queue` | Boolean | _(Optional)_ If `true`, and the command is requesting the `current` ledger, includes an array of [queued transactions](concept-transaction-cost.html#queued-transactions) in the results. +| `queue` | Boolean | _(Optional)_ If `true`, and the command is requesting the `current` ledger, includes an array of [queued transactions](transaction-cost.html#queued-transactions) in the results. The `ledger` field is deprecated and may be removed without further notice. @@ -178,7 +178,7 @@ Each member of the `queue_data` array represents one transaction in the queue. S | `preflight_result` | String | The tentative result from preliminary transaction checking. This is always `tesSUCCESS`. | | `last_result` | String | _(May be omitted)_ If this transaction was left in the queue after getting a [retriable (`ter`) result](reference-transaction-format.html#result-categories), this is the exact `ter` result code it got. | | `auth_change` | Boolean | _(May be omitted)_ Whether this transaction changes this address's [ways of authorizing transactions](reference-transaction-format.html#authorizing-transactions). | -| `fee` | String | _(May be omitted)_ The [Transaction Cost](concept-transaction-cost.html) of this transaction, in [drops of XRP](#specifying-currency-amounts). | +| `fee` | String | _(May be omitted)_ The [Transaction Cost](transaction-cost.html) of this transaction, in [drops of XRP](#specifying-currency-amounts). | | `fee_level` | String | _(May be omitted)_ The transaction cost of this transaction, relative to the minimum cost for this type of transaction, in [fee levels][]. | | `max_spend_drops` | String | _(May be omitted)_ The maximum amount of XRP, [in drops](#specifying-currency-amounts), this transaction could potentially send or destroy. | @@ -186,7 +186,7 @@ If the request specified `"owner_funds": true` and expanded transactions, the re | `Field` | Value | Description | |:--------------|:-------|:----------------------------------------------------| -| `owner_funds` | String | Numeric amount of the `TakerGets` currency that the `Account` sending this OfferCreate transaction has after the execution of all transactions in this ledger. This does not check whether the currency amount is [frozen](concept-freeze.html). | +| `owner_funds` | String | Numeric amount of the `TakerGets` currency that the `Account` sending this OfferCreate transaction has after the execution of all transactions in this ledger. This does not check whether the currency amount is [frozen](freeze.html). | ## Possible Errors @@ -197,6 +197,6 @@ If the request specified `"owner_funds": true` and expanded transactions, the re -[fee levels]: concept-transaction-cost.html#fee-levels +[fee levels]: transaction-cost.html#fee-levels {% include '_snippets/rippled_versions.md' %} {% include '_snippets/rippled-api-links.md' %} diff --git a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md index 031faaa5fa..5451d9c726 100644 --- a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md +++ b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/path_find.md @@ -1,7 +1,7 @@ # path_find [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/PathFind.cpp "Source") -*WebSocket API only!* The `path_find` method searches for a [path](concept-paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account. +*WebSocket API only!* The `path_find` method searches for a [path](paths.html) along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account. There are three different modes, or sub-commands, of the path_find command. Specify which one you want with the `subcommand` parameter: @@ -53,7 +53,7 @@ The request includes the following parameters: | `destination_account` | String | Unique address of the account to find a path to. (In other words, the account that would receive a payment.) | | `destination_amount` | String or Object | [Currency amount](#specifying-currency-amounts) that the destination account would receive in a transaction. **Special case:** [New in: rippled 0.30.0][] You can specify `"-1"` (for XRP) or provide -1 as the contents of the `value` field (for non-XRP currencies). This requests a path to deliver as much as possible, while spending no more than the amount specified in `send_max` (if provided). | | `send_max` | String or Object | _(Optional)_ [Currency amount](#specifying-currency-amounts) that would be spent in the transaction. Not compatible with `source_currencies`. [New in: rippled 0.30.0][] | -| `paths` | Array | _(Optional)_ Array of arrays of objects, representing [payment paths](concept-paths.html) to check. You can use this to keep updated on changes to particular paths you already know about, or to check the overall cost to make a payment along a certain path. | +| `paths` | Array | _(Optional)_ Array of arrays of objects, representing [payment paths](paths.html) to check. You can use this to keep updated on changes to particular paths you already know about, or to check the overall cost to make a payment along a certain path. | The server also recognizes the following fields, but the results of using them are not guaranteed: `source_currencies`, `bridges`. These fields should be considered reserved for future use. @@ -437,7 +437,7 @@ The initial response follows the [standard format](#response-formatting), with a | `Field` | Type | Description | |:----------------------|:-----------------|:----------------------------------| -| `alternatives` | Array | Array of objects with suggested [paths](concept-paths.html) to take, as described below. If empty, then no paths were found connecting the source and destination accounts. | +| `alternatives` | Array | Array of objects with suggested [paths](paths.html) to take, as described below. If empty, then no paths were found connecting the source and destination accounts. | | `destination_account` | String | Unique address of the account that would receive a transaction | | `destination_amount` | String or Object | [Currency amount](#specifying-currency-amounts) that the destination would receive in a transaction | | `id` | (Various) | (WebSocket only) The ID provided in the WebSocket request is included again at this level. | @@ -448,7 +448,7 @@ Each element in the `alternatives` array is an object that represents a path fro | `Field` | Type | Description | |:-----------------|:-----------------|:---------------------------------------| -| `paths_computed` | Array | Array of arrays of objects defining [payment paths](concept-paths.html) | +| `paths_computed` | Array | Array of arrays of objects defining [payment paths](paths.html) | | `source_amount` | String or Object | [Currency amount](#specifying-currency-amounts) that the source would have to send along this path for the destination to receive the desired amount | ### Possible Errors @@ -459,7 +459,7 @@ Each element in the `alternatives` array is an object that represents a path fro ### Asynchronous Follow-ups -In addition to the initial response, the server sends more messages in a similar format to update on the status of [payment paths](concept-paths.html) over time. These messages include the `id` of the original WebSocket request so you can tell which request prompted them, and the field `"type": "path_find"` at the top level to indicate that they are additional responses. The other fields are defined in the same way as the initial response. +In addition to the initial response, the server sends more messages in a similar format to update on the status of [payment paths](paths.html) over time. These messages include the `id` of the original WebSocket request so you can tell which request prompted them, and the field `"type": "path_find"` at the top level to indicate that they are additional responses. The other fields are defined in the same way as the initial response. If the follow-up includes `"full_reply": true`, then this is the best path that rippled can find as of the current ledger. diff --git a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md index b70ee8e912..f4244d1bb7 100644 --- a/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md +++ b/content/references/rippled-api/public-rippled-methods/path-and-order-book-methods/ripple_path_find.md @@ -1,7 +1,7 @@ # ripple_path_find [[Source]
](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/RipplePathFind.cpp "Source") -The `ripple_path_find` method is a simplified version of [`path_find`](#path-find) that provides a single response with a [payment path](concept-paths.html) you can use right away. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making multiple calls to stay updated, you should use [`path_find`](#path-find) instead where possible. +The `ripple_path_find` method is a simplified version of [`path_find`](#path-find) that provides a single response with a [payment path](paths.html) you can use right away. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making multiple calls to stay updated, you should use [`path_find`](#path-find) instead where possible. Although the `rippled` server tries to find the cheapest path or combination of paths for making a payment, it is not guaranteed that the paths returned by this method are, in fact, the best paths. @@ -323,7 +323,7 @@ Each element in the `alternatives` array is an object that represents a path fro | `Field` | Type | Description | |:-----------------|:-----------------|:---------------------------------------| -| `paths_computed` | Array | Array of arrays of objects defining [payment paths](concept-paths.html) | +| `paths_computed` | Array | Array of arrays of objects defining [payment paths](paths.html) | | `source_amount` | String or Object | [Currency amount](#specifying-currency-amounts) that the source would have to send along this path for the destination to receive the desired amount | The following fields are deprecated, and may be omitted: `paths_canonical`, and `paths_expanded`. If they appear, you should disregard them. diff --git a/content/references/rippled-api/public-rippled-methods/server-info-methods/fee.md b/content/references/rippled-api/public-rippled-methods/server-info-methods/fee.md index b832be4848..5165a95c57 100644 --- a/content/references/rippled-api/public-rippled-methods/server-info-methods/fee.md +++ b/content/references/rippled-api/public-rippled-methods/server-info-methods/fee.md @@ -1,7 +1,7 @@ # fee [[Source]
](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/Fee1.cpp "Source") -The `fee` command reports the current state of the open-ledger requirements for the [transaction cost](concept-transaction-cost.html). This requires the [FeeEscalation amendment](reference-amendments.html#feeescalation) to be enabled. [New in: rippled 0.31.0][] +The `fee` command reports the current state of the open-ledger requirements for the [transaction cost](transaction-cost.html). This requires the [FeeEscalation amendment](reference-amendments.html#feeescalation) to be enabled. [New in: rippled 0.31.0][] This is a public command available to unprivileged users. [Updated in: rippled 0.32.0][New in: rippled 0.32.0] @@ -140,10 +140,10 @@ The response follows the [standard format](#response-formatting), with a success | `current_ledger_size` | String (Integer) | Number of transactions provisionally included in the in-progress ledger. | | `current_queue_size` | String (Integer) | Number of transactions currently queued for the next ledger. | | `drops` | Object | Various information about the transaction cost (the `Fee` field of a transaction), in [drops of xrp](#specifying-currency-amounts). | -| `drops.base_fee` | String (Integer) | The transaction cost required for a [reference transaction](concept-transaction-cost.html#reference-transaction-cost) to be included in a ledger under minimum load, represented in drops of XRP. | +| `drops.base_fee` | String (Integer) | The transaction cost required for a [reference transaction](transaction-cost.html#reference-transaction-cost) to be included in a ledger under minimum load, represented in drops of XRP. | | `drops.median_fee` | String (Integer) | An approximation of the median transaction cost among transactions included in the previous validated ledger, represented in drops of XRP. | -| `drops.minimum_fee` | String (Integer) | The minimum transaction cost for a [reference transaction](concept-transaction-cost.html#reference-transaction-cost) to be queued for a later ledger, represented in drops of XRP. If greater than `base_fee`, the transaction queue is full. | -| `drops.open_ledger_fee` | String (Integer) | The minimum transaction cost that a [reference transaction](concept-transaction-cost.html#reference-transaction-cost) must pay to be included in the current open ledger, represented in drops of XRP. | +| `drops.minimum_fee` | String (Integer) | The minimum transaction cost for a [reference transaction](transaction-cost.html#reference-transaction-cost) to be queued for a later ledger, represented in drops of XRP. If greater than `base_fee`, the transaction queue is full. | +| `drops.open_ledger_fee` | String (Integer) | The minimum transaction cost that a [reference transaction](transaction-cost.html#reference-transaction-cost) must pay to be included in the current open ledger, represented in drops of XRP. | | `expected_ledger_size` | String (Integer) | The approximate number of transactions expected to be included in the current ledger. This is based on the number of transactions in the previous ledger. | | `ledger_current_index` | Number | The [Ledger Index][] of the current open ledger these stats describe. [New in: rippled 0.50.0][] | | `levels` | Object | Various information about the transaction cost, in [fee levels][]. The ratio in fee levels applies to any transaction relative to the minimum cost of that particular transaction. | @@ -151,7 +151,7 @@ The response follows the [standard format](#response-formatting), with a success | `levels.minimum_level` | String (Integer) | The minimum transaction cost required to be queued for a future ledger, represented in [fee levels][]. | | `levels.open_ledger_level` | String (Integer) | The minimum transaction cost required to be included in the current open ledger, represented in [fee levels][]. | | `levels.reference_level` | String (Integer) | The equivalent of the minimum transaction cost, represented in [fee levels][]. | -| `max_queue_size` | String (Integer) | The maximum number of transactions that the [transaction queue](concept-transaction-cost.html#queued-transactions) can currently hold. | +| `max_queue_size` | String (Integer) | The maximum number of transactions that the [transaction queue](transaction-cost.html#queued-transactions) can currently hold. | ## Possible Errors @@ -159,6 +159,6 @@ The response follows the [standard format](#response-formatting), with a success -[fee levels]: concept-transaction-cost.html#fee-levels +[fee levels]: transaction-cost.html#fee-levels {% include '_snippets/rippled_versions.md' %} {% include '_snippets/rippled-api-links.md' %} diff --git a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md index 09e075b1ea..5d29101dde 100644 --- a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md +++ b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_info.md @@ -280,7 +280,7 @@ The `info` object may have some arrangement of the following fields: | `Field` | Type | Description | |:------------------------------------|:--------------------------|:-----------| -| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](concept-amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] | +| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] | | `build_version` | String | The version number of the running `rippled` version. | | `closed_ledger` | Object | (May be omitted) Information on the most recently closed ledger that has not been validated by consensus. If the most recently validated ledger is available, the response omits this field and includes `validated_ledger` instead. The member fields are the same as the `validated_ledger` field. | | `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local rippled has in its database. This may be a disjoint sequence, for example `24900901-24900984,24901116-24901158`. | @@ -290,13 +290,13 @@ The `info` object may have some arrangement of the following fields: | `load` | Object | _(Admin only)_ Detailed information about the current load state of the server | | `load.job_types` | Array | _(Admin only)_ Information about the rate of different types of jobs the server is doing and how much time it spends on each. | | `load.threads` | Number | _(Admin only)_ The number of threads in the server's main job pool. | -| `load_factor` | Number | The load-scaled open ledger transaction cost the server is currently enforcing, as a multiplier on the base transaction cost. For example, at `1000` load factor and a reference transaction cost of 10 drops of XRP, the load-scaled transaction cost is 10,000 drops (0.01 XRP). The load factor is determined by the highest of the [individual server's load factor](concept-transaction-cost.html#local-load-cost), the cluster's load factor, the [open ledger cost](concept-transaction-cost.html#open-ledger-cost) and the overall network's load factor. [Updated in: rippled 0.33.0][New in: rippled 0.33.0] | +| `load_factor` | Number | The load-scaled open ledger transaction cost the server is currently enforcing, as a multiplier on the base transaction cost. For example, at `1000` load factor and a reference transaction cost of 10 drops of XRP, the load-scaled transaction cost is 10,000 drops (0.01 XRP). The load factor is determined by the highest of the [individual server's load factor](transaction-cost.html#local-load-cost), the cluster's load factor, the [open ledger cost](transaction-cost.html#open-ledger-cost) and the overall network's load factor. [Updated in: rippled 0.33.0][New in: rippled 0.33.0] | | `load_factor_local` | Number | (May be omitted) Current multiplier to the [transaction cost][] based on load to this server. | | `load_factor_net` | Number | (May be omitted) Current multiplier to the [transaction cost][] being used by the rest of the network (estimated from other servers' reported load values). | | `load_factor_cluster` | Number | (May be omitted) Current multiplier to the [transaction cost][] based on load to servers in [this cluster](tutorial-rippled-setup.html#clustering). | | `load_factor_fee_escalation` | Number | (May be omitted) The current multiplier to the [transaction cost][] that a transaction must pay to get into the open ledger. [New in: rippled 0.32.0][] | | `load_factor_fee_queue` | Number | (May be omitted) The current multiplier to the [transaction cost][] that a transaction must pay to get into the queue, if the queue is full. [New in: rippled 0.32.0][] | -| `load_factor_server` | Number | (May be omitted) The load factor the server is enforcing, not including the [open ledger cost](concept-transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] | +| `load_factor_server` | Number | (May be omitted) The load factor the server is enforcing, not including the [open ledger cost](transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] | | `peers` | Number | How many other `rippled` servers this one is currently connected to. | | `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This key is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) | | `pubkey_validator` | String | _(Admin only)_ Public key used by this node to sign ledger validations. | @@ -317,7 +317,7 @@ The `info` object may have some arrangement of the following fields: **Note:** If the `closed_ledger` field is present and has a small `seq` value (less than 8 digits), that indicates `rippled` does not currently have a copy of the validated ledger from the peer-to-peer network. This could mean your server is still syncing. Typically, it takes about 5 minutes to sync with the network, depending on your connection speed and hardware specs. -[transaction cost]: concept-transaction-cost.html +[transaction cost]: transaction-cost.html ## Possible Errors diff --git a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md index 54dbbc040b..eedfe41aa9 100644 --- a/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md +++ b/content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md @@ -250,7 +250,7 @@ The `state` object may have some arrangement of the following fields: | `Field` | Type | Description | |:---------------------------------|:-----------------|:-----------------------| -| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](concept-amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] | +| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] | | `build_version` | String | The version number of the running `rippled` version. | | `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. It is possible to be a disjoint sequence, e.g. "2500-5000,32570-7695432". | | `closed_ledger` | Object | (May be omitted) Information on the most recently closed ledger that has not been validated by consensus. If the most recently validated ledger is available, the response omits this field and includes `validated_ledger` instead. The member fields are the same as the `validated_ledger` field. | @@ -258,12 +258,12 @@ The `state` object may have some arrangement of the following fields: | `load` | Object | _(Admin only)_ Detailed information about the current load state of the server | | `load.job_types` | Array | _(Admin only)_ Information about the rate of different types of jobs the server is doing and how much time it spends on each. | | `load.threads` | Number | _(Admin only)_ The number of threads in the server's main job pool. | -| `load_base` | Integer | This is the baseline amount of server load used in [transaction cost](concept-transaction-cost.html) calculations. If the `load_factor` is equal to the `load_base` then only the base transaction cost is enforced. If the `load_factor` is higher than the `load_base`, then transaction costs are multiplied by the ratio between them. For example, if the `load_factor` is double the `load_base`, then transaction costs are doubled. | -| `load_factor` | Number | The load factor the server is currently enforcing. The ratio between this value and the `load_base` determines the multiplier for transaction costs. The load factor is determined by the highest of the individual server's load factor, cluster's load factor, the [open ledger cost](concept-transaction-cost.html#open-ledger-cost), and the overall network's load factor. [Updated in: rippled 0.33.0][New in: rippled 0.33.0] | +| `load_base` | Integer | This is the baseline amount of server load used in [transaction cost](transaction-cost.html) calculations. If the `load_factor` is equal to the `load_base` then only the base transaction cost is enforced. If the `load_factor` is higher than the `load_base`, then transaction costs are multiplied by the ratio between them. For example, if the `load_factor` is double the `load_base`, then transaction costs are doubled. | +| `load_factor` | Number | The load factor the server is currently enforcing. The ratio between this value and the `load_base` determines the multiplier for transaction costs. The load factor is determined by the highest of the individual server's load factor, cluster's load factor, the [open ledger cost](transaction-cost.html#open-ledger-cost), and the overall network's load factor. [Updated in: rippled 0.33.0][New in: rippled 0.33.0] | | `load_factor_fee_escalation` | Integer | (May be omitted) The current multiplier to the [transaction cost][] to get into the open ledger, in [fee levels][]. [New in: rippled 0.32.0][] | | `load_factor_fee_queue` | Integer | (May be omitted) The current multiplier to the [transaction cost][] to get into the queue, if the queue is full, in [fee levels][]. [New in: rippled 0.32.0][] | | `load_factor_fee_reference` | Integer | (May be omitted) The [transaction cost][] with no load scaling, in [fee levels][]. [New in: rippled 0.32.0][] | -| `load_factor_server` | Number | (May be omitted) The load factor the server is enforcing, not including the [open ledger cost](concept-transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] | +| `load_factor_server` | Number | (May be omitted) The load factor the server is enforcing, not including the [open ledger cost](transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] | | `peers` | Number | How many other `rippled` servers this one is currently connected to. | | `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This key pair is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) | | `pubkey_validator` | String | _(Admin only)_ Public key of the keypair used by this server to sign proposed ledgers for validation. | @@ -288,8 +288,8 @@ The `state` object may have some arrangement of the following fields: * Any of the [universal error types][]. -[fee levels]: concept-transaction-cost.html#fee-levels -[transaction cost]: concept-transaction-cost.html +[fee levels]: transaction-cost.html#fee-levels +[transaction cost]: transaction-cost.html {% include '_snippets/rippled_versions.md' %} {% include '_snippets/rippled-api-links.md' %} {% include '_snippets/tx-type-links.md' %} diff --git a/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md b/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md index 6bad21ca97..d77374a609 100644 --- a/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md +++ b/content/references/rippled-api/public-rippled-methods/subscription-methods/subscribe.md @@ -154,7 +154,7 @@ The fields from a ledger stream message are as follows: | `Field` | Type | Description | |:--------------------|:-----------------|:------------------------------------| | `type` | String | `ledgerClosed` indicates this is from the ledger stream | -| `fee_base` | Unsigned Integer | Cost of the 'reference transaction' in drops of XRP. (See [Transaction Cost](concept-transaction-cost.html) If the ledger includes a [SetFee pseudo-transaction](reference-transaction-format.html#setfee) the new transaction cost applies to all transactions after this ledger. | +| `fee_base` | Unsigned Integer | Cost of the 'reference transaction' in drops of XRP. (See [Transaction Cost](transaction-cost.html) If the ledger includes a [SetFee pseudo-transaction](reference-transaction-format.html#setfee) the new transaction cost applies to all transactions after this ledger. | | `fee_ref` | Unsigned Integer | Cost of the 'reference transaction' in 'fee units'. | | `ledger_hash` | String | Unique hash of the ledger that was closed, as hex | | `ledger_index` | Unsigned Integer | Sequence number of the ledger that was closed | @@ -200,15 +200,15 @@ The fields from a validations stream message are as follows: | `Field` | Type | Description | |:------------------------|:-----------------|:--------------------------------| | `type` | String | The value `validationReceived` indicates this is from the validations stream. | -| `amendments` | Array of Strings | (May be omitted) The [amendments](concept-amendments.html) this server wants to be added to the protocol. [New in: rippled 0.32.0][] | -| `base_fee` | Integer | (May be omitted) The unscaled transaction cost (`reference_fee` value) this server wants to set by [Fee Voting](concept-fee-voting.html). [New in: rippled 0.32.0][] | +| `amendments` | Array of Strings | (May be omitted) The [amendments](amendments.html) this server wants to be added to the protocol. [New in: rippled 0.32.0][] | +| `base_fee` | Integer | (May be omitted) The unscaled transaction cost (`reference_fee` value) this server wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] | | `flags` | Number | Bit-mask of flags added to this validation message. The flag 0x80000000 indicates that the validation signature is fully-canonical. The flag 0x00000001 indicates that this is a full validation; otherwise it's a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] | | `full` | Boolean | If `true`, this is a full validation. Otherwise, this is a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] | | `ledger_hash` | String | The identifying hash of the proposed ledger is being validated. | | `ledger_index` | String - Integer | The [Ledger Index][] of the proposed ledger. [New in: rippled 0.31.0][] | | `load_fee` | Integer | (May be omitted) The local load-scaled transaction cost this validator is currently enforcing, in fee units. [New in: rippled 0.32.0][] | -| `reserve_base` | Integer | (May be omitted) The minimum reserve requirement (`account_reserve` value) this validator wants to set by [Fee Voting](concept-fee-voting.html). [New in: rippled 0.32.0][] | -| `reserve_inc` | Integer | (May be omitted) The increment in the reserve requirement (`owner_reserve` value) this validator wants to set by [Fee Voting](concept-fee-voting.html). [New in: rippled 0.32.0][] | +| `reserve_base` | Integer | (May be omitted) The minimum reserve requirement (`account_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] | +| `reserve_inc` | Integer | (May be omitted) The increment in the reserve requirement (`owner_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] | | `signature` | String | The signature that the validator used to sign its vote for this ledger. | | `signing_time` | Number | When this validation vote was signed, in seconds since the [Ripple Epoch](#specifying-time). [New in: rippled 0.32.0][] | | `validation_public_key` | String | The [base58][] encoded public key from the key-pair that the validator used to sign the message. This identifies the validator sending the message and can also be used to verify the `signature`. | @@ -529,7 +529,7 @@ The format of an order book stream message is the same as that of [transaction s | `Field` | Value | Description | |:--------------------------|:-------|:----------------------------------------| -| `transaction.owner_funds` | String | Numeric amount of the `TakerGets` currency that the `Account` sending this OfferCreate transaction has after executing this transaction. This does not check whether the currency amount is [frozen](concept-freeze.html). | +| `transaction.owner_funds` | String | Numeric amount of the `TakerGets` currency that the `Account` sending this OfferCreate transaction has after executing this transaction. This does not check whether the currency amount is [frozen](freeze.html). | {% include '_snippets/rippled_versions.md' %} diff --git a/content/references/rippled-api/public-rippled-methods/transaction-methods/sign.md b/content/references/rippled-api/public-rippled-methods/transaction-methods/sign.md index 00b885f161..78682e359d 100644 --- a/content/references/rippled-api/public-rippled-methods/transaction-methods/sign.md +++ b/content/references/rippled-api/public-rippled-methods/transaction-methods/sign.md @@ -85,8 +85,8 @@ The request includes the following parameters: | `key_type` | String | _(Optional)_ Type of cryptographic key provided in this request. Valid types are `secp256k1` or `ed25519`. Defaults to `secp256k1`. Cannot be used with `secret`. **Caution:** Ed25519 support is experimental. | | `offline` | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not try to automatically fill in or validate values. | | `build_path` | Boolean | _(Optional)_ If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. **Caution:** The server looks for the presence or absence of this field, not its value. This behavior may change. | -| `fee_mult_max` | Integer | (Optional, defaults to 10; recommended value 1000) Limits how high the [automatically-provided `Fee` field](reference-transaction-format.html#auto-fillable-fields) can be. Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](concept-transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](concept-transaction-cost.html)). | -| `fee_div_max` | Integer | (Optional, defaults to 1) Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](concept-transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](concept-transaction-cost.html)). [New in: rippled 0.30.1][] | +| `fee_mult_max` | Integer | (Optional, defaults to 10; recommended value 1000) Limits how high the [automatically-provided `Fee` field](reference-transaction-format.html#auto-fillable-fields) can be. Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](transaction-cost.html)). | +| `fee_div_max` | Integer | (Optional, defaults to 1) Signing fails with the error `rpcHIGH_FEE` if the current [load multiplier on the transaction cost](transaction-cost.html#local-load-cost) is greater than (`fee_mult_max` ÷ `fee_div_max`). Ignored if you specify the `Fee` field of the transaction ([transaction cost](transaction-cost.html)). [New in: rippled 0.30.1][] | ### Auto-Fillable Fields @@ -95,7 +95,7 @@ The server automatically tries to fill in certain fields in `tx_json` (the [Tran * `Sequence` - The server automatically uses the next Sequence number from the sender's account information. * **Caution:** The next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must manually provide the correct sequence numbers for each transaction after the first. * `Fee` - If you omit the `Fee` parameter, the server tries to fill in an appropriate transaction cost automatically. On the production XRP Ledger, this fails with `rpcHIGH_FEE` unless you provide an appropriate `fee_mult_max` value. - * The `fee_mult_max` and `fee_div_max` parameters limit how high the automatically-provided transaction cost can be, in terms of the load-scaling multiplier that gets applied to the [reference transaction cost](concept-transaction-cost.html#reference-transaction-cost). The default settings return an error if the automatically-provided value would use greater than a 10× multiplier. However, the production XRP Ledger [typically has a 1000× load multiplier](concept-transaction-cost.html#current-transaction-cost). + * The `fee_mult_max` and `fee_div_max` parameters limit how high the automatically-provided transaction cost can be, in terms of the load-scaling multiplier that gets applied to the [reference transaction cost](transaction-cost.html#reference-transaction-cost). The default settings return an error if the automatically-provided value would use greater than a 10× multiplier. However, the production XRP Ledger [typically has a 1000× load multiplier](transaction-cost.html#current-transaction-cost). * The commandline syntax does not support `fee_mult_max` and `fee_div_max`. For the production XRP Ledger, you must provide a `Fee` value. * **Caution:** A malicious server can specify an excessively high transaction cost, ignoring the values of `fee_mult_max` and `fee_div_max`. * `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided. 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 8fb26de656..9467a5901e 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 @@ -81,7 +81,7 @@ The request includes the following parameters: | `offline` | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not try to automatically fill in or validate values. | | `build_path` | Boolean | _(Optional)_ If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. You must omit this field if the transaction is a direct XRP-to-XRP transfer. **Caution:** The server looks for the presence or absence of this field, not its value. This behavior may change. | | `fee_mult_max` | Integer | (Optional, defaults to 10, recommended value 1000) If the `Fee` parameter is omitted, this field limits the automatically-provided `Fee` value so that it is less than or equal to the long-term base transaction cost times this value. | -| `fee_div_max` | Integer | (Optional, defaults to 1) Used with `fee_mult_max` to create a fractional multiplier for the limit. Specifically, the server multiplies its base [transaction cost](concept-transaction-cost.html) by `fee_mult_max`, then divides by this value (rounding down to an integer) to get a limit. If the automatically-provided `Fee` value would be over the limit, the submit command fails. [New in: rippled 0.30.1][] | +| `fee_div_max` | Integer | (Optional, defaults to 1) Used with `fee_mult_max` to create a fractional multiplier for the limit. Specifically, the server multiplies its base [transaction cost](transaction-cost.html) by `fee_mult_max`, then divides by this value (rounding down to an integer) to get a limit. If the automatically-provided `Fee` value would be over the limit, the submit command fails. [New in: rippled 0.30.1][] | See the [sign command](#sign) for detailed information on how the server automatically fills in certain fields. @@ -272,7 +272,7 @@ The response follows the [standard format](#response-formatting), with a success ## Possible Errors * Any of the [universal error types][]. -* `amendmentBlocked` - The transaction cannot be submitted to the network because the `rippled` server is [amendment blocked](concept-amendments.html#amendment-blocked). +* `amendmentBlocked` - The transaction cannot be submitted to the network because the `rippled` server is [amendment blocked](amendments.html#amendment-blocked). * `highFee` - The `fee_mult_max` parameter was specified, but the server's current fee multiplier exceeds the specified one. (Sign-and-Submit mode only) * `internalJson` - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. * `internalSubmit` - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed. diff --git a/content/references/rippled-api/rippled-old-monolith.md b/content/references/rippled-api/rippled-old-monolith.md index ec83bb922c..8a711be8a8 100755 --- a/content/references/rippled-api/rippled-old-monolith.md +++ b/content/references/rippled-api/rippled-old-monolith.md @@ -144,7 +144,7 @@ All field names are case-sensitive. In responses, fields that are taken directly Different types of objects are uniquely identified in different ways: -[Accounts](concept-accounts.html) are identified by their [Address][], for example `"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`. Addresses always start with "r". Many `rippled` methods also accept a hexadecimal representation. +[Accounts](accounts.html) are identified by their [Address][], for example `"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`. Addresses always start with "r". Many `rippled` methods also accept a hexadecimal representation. [Transactions](reference-transaction-format.html) are identified by a [Hash][] of the transaction's binary format. You can also identify a transaction by its sending account and [Sequence Number][]. @@ -294,7 +294,7 @@ The format of the `marker` field is intentionally undefined. Each server can def ## Modifying the Ledger -All changes to the XRP Ledger happen as the result of transactions. The only API methods that can change the contents of the XRP Ledger are the commands that submit transactions. Even then, changes only apply permanently if the transactions are approved by the [consensus process](concept-consensus.html). Most other public methods represent different ways to view the data represented in the XRP Ledger, or request information about the state of the server. +All changes to the XRP Ledger happen as the result of transactions. The only API methods that can change the contents of the XRP Ledger are the commands that submit transactions. Even then, changes only apply permanently if the transactions are approved by the [consensus process](consensus.html). Most other public methods represent different ways to view the data represented in the XRP Ledger, or request information about the state of the server. Transaction submission commands: @@ -325,7 +325,7 @@ You can use the `rippled` application (as a separate instance) as a JSON-RPC cli # Account Information -For more information, see [Accounts](concept-accounts.html). +For more information, see [Accounts](accounts.html). {% include 'rippled-api-methods/wallet_propose.md' %} diff --git a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md index 3ca1524078..34d8ea7a7b 100644 --- a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md +++ b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/enableamendment.md @@ -1,12 +1,12 @@ # EnableAmendment -Tracks the progress of the [amendment process](concept-amendments.html#amendment-process) for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled. +Tracks the progress of the [amendment process](amendments.html#amendment-process) for changes in transaction processing. This can indicate that a proposed amendment gained or lost majority approval, or that an amendment has been enabled. **Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers. | Field | JSON Type | [Internal Type][] | Description | |:---------------|:----------|:------------------|:----------------------------| -| Amendment | String | Hash256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](concept-amendments.html) for a list of known amendments. | +| Amendment | String | Hash256 | A unique identifier for the amendment. This is not intended to be a human-readable name. See [Amendments](amendments.html) for a list of known amendments. | | LedgerSequence | Number | UInt32 | The index of the ledger version where this amendment appears. This distinguishes the pseudo-transaction from other occurrences of the same change. | ## EnableAmendment Flags diff --git a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md index a46cb94a3d..b3d7927790 100644 --- a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md +++ b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/pseudo-transaction-types.md @@ -6,7 +6,7 @@ Some of the fields that are mandatory for normal transactions do not make sense | Field | Default Value | |:--------------|:---------------------------------------------------------| -| Account | [ACCOUNT_ZERO](concept-accounts.html#special-addresses) | +| Account | [ACCOUNT_ZERO](accounts.html#special-addresses) | | Sequence | 0 | | Fee | 0 | | SigningPubKey | "" | diff --git a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md index 70c63a4678..89f582ce8f 100644 --- a/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md +++ b/content/references/rippled-api/transaction-formats/pseudo-transaction-types/setfee.md @@ -1,6 +1,6 @@ # SetFee -A change in [transaction cost](concept-transaction-cost.html) or [account reserve](concept-reserves.html) requirements as a result of [Fee Voting](concept-fee-voting.html). +A change in [transaction cost](transaction-cost.html) or [account reserve](reserves.html) requirements as a result of [Fee Voting](fee-voting.html). **Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers. @@ -23,7 +23,7 @@ A change in [transaction cost](concept-transaction-cost.html) or [account reserv | Field | JSON Type | [Internal Type][] | Description | |:------------------|:-----------------|:------------------|:------------------| -| BaseFee | String | UInt64 | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](concept-transaction-cost.html) before scaling for load.) | +| BaseFee | String | UInt64 | The charge, in drops of XRP, for the reference transaction, as hex. (This is the [transaction cost](transaction-cost.html) before scaling for load.) | | ReferenceFeeUnits | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction | | ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops | | ReserveIncrement | Unsigned Integer | UInt32 | The incremental reserve, in drops | 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 b63f775abc..5bfe676ccb 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 @@ -1,8 +1,8 @@ # tec Codes -These codes indicate that the transaction failed, but it was applied to a ledger to apply the [transaction cost](concept-transaction-cost.html). They have numerical values in the range 100 to 199. Ripple recommends using the text code, not the numeric value. +These codes indicate that the transaction failed, but it was applied to a ledger to apply the [transaction cost](transaction-cost.html). They have numerical values in the range 100 to 199. Ripple recommends using the text code, not the numeric value. -For the most part, transactions with `tec` codes take no action other than to destroy the XRP paid as a [transaction cost](concept-transaction-cost.html), but there are some exceptions. As an exception, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](#lifecycle-of-an-offer). Always look at the [transaction metadata](#understanding-transaction-metadata) to see precisely what a transaction did. +For the most part, transactions with `tec` codes take no action other than to destroy the XRP paid as a [transaction cost](transaction-cost.html), but there are some exceptions. As an exception, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](#lifecycle-of-an-offer). Always look at the [transaction metadata](#understanding-transaction-metadata) to see precisely what a transaction did. **Caution:** A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html). @@ -14,10 +14,10 @@ For the most part, transactions with `tec` codes take no action other than to de | `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][] | | `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](concept-freeze.html). | -| `tecINSUF_RESERVE_LINE` | 122 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](concept-reserves.html)) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See `tecNO_LINE_INSUF_RESERVE` for the other case.) | -| `tecINSUF_RESERVE_OFFER` | 123 | The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: [Reserves](concept-reserves.html)) | -| `tecINSUFFICIENT_RESERVE` | 141 | The transaction would increase the [reserve requirement](concept-reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves) for more information. | +| `tecFROZEN` | 137 | The [OfferCreate transaction][] failed because one or both of the assets involved are subject to a [global freeze](freeze.html). | +| `tecINSUF_RESERVE_LINE` | 122 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See `tecNO_LINE_INSUF_RESERVE` for the other case.) | +| `tecINSUF_RESERVE_OFFER` | 123 | The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: [Reserves](reserves.html)) | +| `tecINSUFFICIENT_RESERVE` | 141 | The transaction would increase the [reserve requirement](reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves) for more information. | | `tecINTERNAL` | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | | `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Requires the [EnforceInvariants amendment](reference-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | | `tecNEED_MASTER_KEY` | 142 | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](#accountset-flags). [New in: rippled 0.28.0][] | @@ -28,7 +28,7 @@ For the most part, transactions with `tec` codes take no action other than to de | `tecNO_ENTRY` | 140 | Reserved for future use. | | `tecNO_ISSUER` | 133 | The account specified in the `issuer` field of a currency amount does not exist. | | `tecNO_LINE` | 135 | The `TakerPays` field of the [OfferCreate transaction][] specifies an asset whose issuer has `lsfRequireAuth` enabled, and the account making the offer does not have a trust line for that asset. (Normally, making an offer implicitly creates a trust line if necessary, but in this case it does not bother because you cannot hold the asset without authorization.) If the trust line exists, but is not authorized, `tecNO_AUTH` occurs instead. | -| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](concept-reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) | +| `tecNO_LINE_INSUF_RESERVE` | 126 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty does not have a trust line to this account for the same currency. (See `tecINSUF_RESERVE_LINE` for the other case.) | | `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. | | `tecNO_PERMISSION` | 139 | The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its `FinishAfter` time, someone tried to use [PaymentChannelFund][] on a channel the sender does not own, or a [Payment][] tried to deliver funds to an account with the "DepositAuth" flag enabled. | | `tecNO_REGULAR_KEY` | 131 | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](#authorizing-transactions). If [multi-signing](#multi-signing) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. | @@ -37,9 +37,9 @@ For the most part, transactions with `tec` codes take no action other than to de | `tecOWNERS` | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | | `tecPATH_DRY` | 128 | The transaction failed because the provided paths did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by trust lines. | | `tecPATH_PARTIAL` | 101 | The transaction failed because the provided paths did not have enough liquidity to send the full amount. | -| `tecUNFUNDED` | 129 | The transaction failed because the account does not hold enough XRP to pay the amount in the transaction _and_ satisfy the additional reserve necessary to execute this transaction. (See: [Reserves](concept-reserves.html)) | +| `tecUNFUNDED` | 129 | The transaction failed because the account does not hold enough XRP to pay the amount in the transaction _and_ satisfy the additional reserve necessary to execute this transaction. (See: [Reserves](reserves.html)) | | `tecUNFUNDED_ADD` | 102 | **DEPRECATED.** | -| `tecUNFUNDED_PAYMENT` | 104 | The transaction failed because the sending account is trying to send more XRP than it holds, not counting the reserve. (See: [Reserves](concept-reserves.html)) | +| `tecUNFUNDED_PAYMENT` | 104 | The transaction failed because the sending account is trying to send more XRP than it holds, not counting the reserve. (See: [Reserves](reserves.html)) | | `tecUNFUNDED_OFFER` | 103 | The [OfferCreate transaction][] failed because the account creating the offer does not have any of the `TakerGets` currency. | 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 33752c7aaf..3dbd3fee4c 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 @@ -17,7 +17,7 @@ These codes indicate that the transaction failed and was not included in a ledge | `tefEXCEPTION` | While processing the transaction, the server entered an unexpected state. This may be caused by unexpected inputs, for example if the binary data for the transaction is grossly malformed. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. | | `tefFAILURE` | Unspecified failure in applying the transaction. | | `tefINTERNAL` | When trying to apply the transaction, the server entered an unexpected state. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues) to get it fixed. | -| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](concept-transaction-cost.html). Requires the [EnforceInvariants amendment](reference-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | +| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](transaction-cost.html). Requires the [EnforceInvariants amendment](reference-amendments.html#enforceinvariants). If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). | | `tefMASTER_DISABLED` | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. | | `tefMAX_LEDGER` | The transaction included a [`LastLedgerSequence`](#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. | | `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trustline as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. | diff --git a/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md index 0bff1a5240..de27f68285 100644 --- a/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md +++ b/content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md @@ -9,14 +9,14 @@ These codes indicate an error in the local server processing the transaction; it | `telBAD_DOMAIN` | The transaction specified a domain value (for example, the `Domain` field of an [AccountSet transaction][]) that cannot be used, probably because it is too long to store in the ledger. | | `telBAD_PATH_COUNT` | The transaction contains too many paths for the local server to process. | | `telBAD_PUBLIC_KEY` | The transaction specified a public key value (for example, as the `MessageKey` field of an [AccountSet transaction][]) that cannot be used, probably because it is too long. | -| `telCAN_NOT_QUEUE` | The transaction did not meet the [open ledger cost](concept-transaction-cost.html), but this server did not queue this transaction because it did not meet the [queuing restrictions](concept-transaction-cost.html#queuing-restrictions). For example, a transaction returns this code when the sender already has 10 other transactions in the queue. You can try again later or sign and submit a replacement transaction with a higher transaction cost in the `Fee` field. | -| `telCAN_NOT_QUEUE_BALANCE` | The transaction did not meet the [open ledger cost](concept-transaction-cost.html) and also was not added to the transaction queue because the sum of potential XRP costs of already-queued transactions is greater than the expected balance of the account. You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_BLOCKS` | The transaction did not meet the [open ledger cost](concept-transaction-cost.html) and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_BLOCKED` | The transaction did not meet the [open ledger cost](concept-transaction-cost.html) and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_FEE` | The transaction did not meet the [open ledger cost](concept-transaction-cost.html) and also was not added to the transaction queue. This code occurs when a transaction with the same sender and sequence number already exists in the queue and the new one does not pay a large enough transaction cost to replace the existing transaction. To replace a transaction in the queue, the new transaction must have a `Fee` value that is at least 25% more, as measured in [fee levels](concept-transaction-cost.html#fee-levels). You can increase the `Fee` and try again, send this with a higher `Sequence` number so it doesn't replace an existing transaction, or try sending to another server. [New in: rippled 0.70.2][] | -| `telCAN_NOT_QUEUE_FULL` | The transaction did not meet the [open ledger cost](concept-transaction-cost.html) and the server did not queue this transaction because this server's transaction queue is full. You could increase the `Fee` and try again, try again later, or try submitting to a different server. The new transaction must have a higher transaction cost, as measured in [fee levels](concept-transaction-cost.html#fee-levels), than the transaction in the queue with the smallest transaction cost. [New in: rippled 0.70.2][] | +| `telCAN_NOT_QUEUE` | The transaction did not meet the [open ledger cost](transaction-cost.html), but this server did not queue this transaction because it did not meet the [queuing restrictions](transaction-cost.html#queuing-restrictions). For example, a transaction returns this code when the sender already has 10 other transactions in the queue. You can try again later or sign and submit a replacement transaction with a higher transaction cost in the `Fee` field. | +| `telCAN_NOT_QUEUE_BALANCE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because the sum of potential XRP costs of already-queued transactions is greater than the expected balance of the account. You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | +| `telCAN_NOT_QUEUE_BLOCKS` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This transaction could not replace an existing transaction in the queue because it would block already-queued transactions from the same sender by changing authorization methods. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | +| `telCAN_NOT_QUEUE_BLOCKED` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue because a transaction queued ahead of it from the same sender blocks it. (This includes all [SetRegularKey][] and [SignerListSet][] transactions, as well as [AccountSet][] transactions that change the RequireAuth/OptionalAuth, DisableMaster, or AccountTxnID flags.) You can try again later, or try submitting to a different server. [New in: rippled 0.70.2][] | +| `telCAN_NOT_QUEUE_FEE` | The transaction did not meet the [open ledger cost](transaction-cost.html) and also was not added to the transaction queue. This code occurs when a transaction with the same sender and sequence number already exists in the queue and the new one does not pay a large enough transaction cost to replace the existing transaction. To replace a transaction in the queue, the new transaction must have a `Fee` value that is at least 25% more, as measured in [fee levels](transaction-cost.html#fee-levels). You can increase the `Fee` and try again, send this with a higher `Sequence` number so it doesn't replace an existing transaction, or try sending to another server. [New in: rippled 0.70.2][] | +| `telCAN_NOT_QUEUE_FULL` | The transaction did not meet the [open ledger cost](transaction-cost.html) and the server did not queue this transaction because this server's transaction queue is full. You could increase the `Fee` and try again, try again later, or try submitting to a different server. The new transaction must have a higher transaction cost, as measured in [fee levels](transaction-cost.html#fee-levels), than the transaction in the queue with the smallest transaction cost. [New in: rippled 0.70.2][] | | `telFAILED_PROCESSING` | An unspecified error occurred when processing the transaction. | -| `telINSUF_FEE_P` | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](concept-transaction-cost.html) requirement, which is derived from its load level. | +| `telINSUF_FEE_P` | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](transaction-cost.html) requirement, which is derived from its load level. | | `telLOCAL_ERROR` | Unspecified local error. | | `telNO_DST`_`PARTIAL` | The transaction is an XRP payment that would fund a new account, but the [tfPartialPayment flag](#partial-payments) was enabled. This is disallowed. | 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 a5e6da10ee..2c36cb94c9 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 @@ -2,7 +2,7 @@ These codes indicate that the transaction was malformed, and cannot succeed according to the XRP Ledger protocol. They have numerical values in the range -299 to -200. The exact code for any given error is subject to change, so don't rely on it. -**Tip:** Transactions with `tem` codes are not applied to ledgers, and cannot cause any changes to XRP Ledger state. A `tem` result is final unless the rules for a valid transaction change. (For example, using functionality from an [Amendment](concept-amendments.html) before that amendment is enabled results in `temDISABLED`; such a transaction could succeed later if it becomes valid when the amendment is enabled.) +**Tip:** Transactions with `tem` codes are not applied to ledgers, and cannot cause any changes to XRP Ledger state. A `tem` result is final unless the rules for a valid transaction change. (For example, using functionality from an [Amendment](amendments.html) before that amendment is enabled results in `temDISABLED`; such a transaction could succeed later if it becomes valid when the amendment is enabled.) | Code | Explanation | |:-----------------------------|:----------------------------------------------| @@ -23,7 +23,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | `temBAD_SEND_XRP_PATHS` | The [Payment](#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](concept-accounts.html) address. | +| `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. | @@ -38,7 +38,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco | `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. | | `temUNCERTAIN` | Used internally only. This code should never be returned. | | `temUNKNOWN` | Used internally only. This code should never be returned. | -| `temDISABLED` | The transaction requires logic that is disabled. Typically this means you are trying to use an [amendment](concept-amendments.html) that is not enabled for the current ledger. | +| `temDISABLED` | The transaction requires logic that is disabled. Typically this means you are trying to use an [amendment](amendments.html) that is not enabled for the current ledger. | {% include '_snippets/rippled-api-links.md' %} diff --git a/content/references/rippled-api/transaction-formats/transaction-results/ter-codes.md b/content/references/rippled-api/transaction-formats/transaction-results/ter-codes.md index 728f9f7f3a..c54eb3acd8 100644 --- a/content/references/rippled-api/transaction-formats/transaction-results/ter-codes.md +++ b/content/references/rippled-api/transaction-formats/transaction-results/ter-codes.md @@ -16,7 +16,7 @@ These codes indicate that the transaction failed, but it could apply successfull | `terOWNERS` | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](#accountset-flags) flag if it has any trust lines or available offers. | | `terPRE_SEQ` | The `Sequence` number of the current transaction is higher than the current sequence number of the account sending the transaction. | | `terRETRY` | Unspecified retriable error. | -| `terQUEUED` | The transaction met the load-scaled [transaction cost](concept-transaction-cost.html) but did not meet the open ledger requirement, so the transaction has been queued for a future ledger. | +| `terQUEUED` | The transaction met the load-scaled [transaction cost](transaction-cost.html) but did not meet the open ledger requirement, so the transaction has been queued for a future ledger. | {% include '_snippets/rippled-api-links.md' %} diff --git a/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md b/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md index f1747134e3..30c1990f78 100644 --- a/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md +++ b/content/references/rippled-api/transaction-formats/transaction-results/transaction-results.md @@ -11,7 +11,7 @@ The `rippled` server summarizes transaction results with result codes, which app | Failure | [tef](tef-codes.html) | The transaction cannot be applied to the server's current (in-progress) ledger or any later one. It may have already been applied, or the condition of the ledger makes it impossible to apply in the future. | | Retry | [ter](ter-codes.html) | The transaction could not be applied, but it might be possible to apply later. | | Success | [tes](tes-success.html) | (Not an error) The transaction succeeded. This result only final in a validated ledger. | -| Claimed cost only | [tec](tec-codes.html) | The transaction did not achieve its intended purpose, but the [transaction cost](concept-transaction-cost.html) was destroyed. This result is only final in a validated ledger. | +| Claimed cost only | [tec](tec-codes.html) | The transaction did not achieve its intended purpose, but the [transaction cost](transaction-cost.html) was destroyed. This result is only final in a validated ledger. | **Warning:** Transactions' provisional result codes may differ than their final result. Transactions that provisionally succeeded may eventually fail and transactions that provisionally failed may eventually succeed. Transactions that provisionally failed may also eventually fail with a different code. See [finality of results](finality-of-results.html) for how to know when a transaction's result is final. 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 c8357130de..b23113c496 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/accountset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/accountset.md @@ -61,12 +61,12 @@ The available AccountSet flags are: | Flag Name | Decimal Value | Corresponding Ledger Flag | Description | |:-----------------|:--------------|:--------------------------|:--------------| | asfAccountTxnID | 5 | (None) | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) | -| asfDefaultRipple | 8 | lsfDefaultRipple | Enable [rippling](concept-noripple.html) on this account's trust lines by default. [New in: rippled 0.27.3][] | -| asfDepositAuth | 9 | lsfDepositAuth | Enable [Deposit Authorization](concept-depositauth.html) on this account. _(Requires the [DepositAuth amendment](reference-amendments.html#depositauth).)_ | +| asfDefaultRipple | 8 | lsfDefaultRipple | Enable [rippling](noripple.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](reference-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). | | asfDisallowXRP | 3 | lsfDisallowXRP | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) | -| asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](concept-freeze.html) all assets issued by this account. | -| asfNoFreeze | 6 | lsfNoFreeze | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](concept-freeze.html). This flag can never be disabled after being enabled. | +| asfGlobalFreeze | 7 | lsfGlobalFreeze | [Freeze](freeze.html) all assets issued by this account. | +| asfNoFreeze | 6 | lsfNoFreeze | Permanently give up the ability to [freeze individual trust lines or disable Global Freeze](freeze.html). This flag can never be disabled after being enabled. | | asfRequireAuth | 2 | lsfRequireAuth | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. | | asfRequireDest | 1 | lsfRequireDestTag | Require a destination tag to send transactions to this account. | @@ -96,7 +96,7 @@ You can protect against unwanted incoming payments for non-XRP currencies by not ## TransferRate -The TransferRate field specifies a fee to charge whenever counterparties transfer the currency you issue. See [Transfer Fees](concept-transfer-fees.html) for more information. +The TransferRate field specifies a fee to charge whenever counterparties transfer the currency you issue. See [Transfer Fees](transfer-fees.html) for more information. In `rippled`'s WebSocket and JSON-RPC APIs, the TransferRate is represented as an integer, the amount that must be sent for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value `1200000000`. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify 0 as a shortcut for 1000000000, meaning no fee. diff --git a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md index 58681b9253..93dd78bc9e 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md @@ -28,8 +28,8 @@ In addition to the [common fields](#common-fields), a CheckCreate transaction ha | Field | JSON Type | [Internal Type][] | Description | |:-----------------|:--------------------|:------------------|:----------------| -| `Destination` | String | Account | The unique address of the [account](concept-accounts.html) that can cash the Check. | -| `SendMax` | [Currency Amount][] | Amount | Maximum amount of source currency the Check is allowed to debit the sender, including [transfer fees](concept-transfer-fees.html) on non-XRP currencies. The Check can only credit the destination with the same currency (from the same issuer, for non-XRP currencies). For non-XRP amounts, the nested field names MUST be lower-case. | +| `Destination` | String | Account | The unique address of the [account](accounts.html) that can cash the Check. | +| `SendMax` | [Currency Amount][] | Amount | Maximum amount of source currency the Check is allowed to debit the sender, including [transfer fees](transfer-fees.html) on non-XRP currencies. The Check can only credit the destination with the same currency (from the same issuer, for non-XRP currencies). For non-XRP amounts, the nested field names MUST be lower-case. | | `DestinationTag` | Unsigned Integer | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the Check, or a hosted recipient to pay. | | `Expiration` | Unsigned Integer | UInt32 | _(Optional)_ Time after which the Check is no longer valid, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time). | | `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this Check. | @@ -37,11 +37,11 @@ In addition to the [common fields](#common-fields), a CheckCreate transaction ha ## Error Cases - If the `Destination` is the sender of the transaction, the transaction fails with the result code `temREDUNDANT`. -- If the `Destination` [account](concept-accounts.html) does not exist in the ledger, the transaction fails with the result code `tecNO_DST`. +- If the `Destination` [account](accounts.html) does not exist in the ledger, the transaction fails with the result code `tecNO_DST`. - If the `Destination` account has the RequireDest flag enabled but the transaction does not include a `DestinationTag` field, the transaction fails with the result code `tecDST_TAG_NEEDED`. -- If `SendMax` specifies an issued currency which is [frozen](concept-freeze.html), the transaction fails with the result `tecFROZEN`. +- If `SendMax` specifies an issued currency which is [frozen](freeze.html), the transaction fails with the result `tecFROZEN`. - If the `Expiration` of the transaction is in the past, the transaction fails with the result `tecEXPIRED`. -- If the sender does not have enough XRP to meet the [owner reserve](concept-reserves.html#owner-reserves) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`. +- If the sender does not have enough XRP to meet the [owner reserve](reserves.html#owner-reserves) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`. - If either the sender or the destination of the Check cannot own more objects in the ledger, the transaction fails with the result `tecDIR_FULL`. diff --git a/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md b/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md index b8adb203d5..f253c8ba94 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/escrowfinish.md @@ -36,7 +36,7 @@ Any account may submit an EscrowFinish transaction. - If the held payment has a `Condition`, you cannot execute it unless you provide a matching `Fulfillment` for the condition. - You cannot execute a held payment after it has expired. Specifically, if the corresponding [EscrowCreate transaction][] specified a `CancelAfter` time that is before the close time of the most recently-closed ledger, the EscrowFinish transaction fails. -**Note:** The minimum [transaction cost](concept-transaction-cost.html) to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 [drops of XRP](reference-rippled.html#specifying-currency-amounts) plus another 10 drops for every 16 bytes in size of the preimage. +**Note:** The minimum [transaction cost](transaction-cost.html) to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 [drops of XRP](reference-rippled.html#specifying-currency-amounts) plus another 10 drops for every 16 bytes in size of the preimage. {% include '_snippets/rippled-api-links.md' %} 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 a55dced3cc..32e6e7baca 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/payment.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/payment.md @@ -33,13 +33,13 @@ Payments are also the only way to [create accounts](#creating-accounts). | Destination | String | Account | The unique address of the account receiving the payment. | | DestinationTag | Unsigned Integer | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the payment to the destination, or a hosted recipient to pay. | | InvoiceID | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this payment. | -| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](concept-paths.html) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. | -| SendMax | [Currency Amount][] | Amount | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](concept-transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](#transaction-cost). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. | +| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](paths.html) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. | +| SendMax | [Currency Amount][] | Amount | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](#transaction-cost). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. | | DeliverMin | [Currency Amount][] | Amount | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](#partial-payments). For non-XRP amounts, the nested field names are lower-case. | ## Special issuer Values for SendMax and Amount -Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates a financial institution's [issuing address](concept-issuing-and-operational-addresses.html). However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment. +Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates a financial institution's [issuing address](issuing-and-operational-addresses.html). However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment. * There is only ever one balance for the same currency between two addresses. This means that, sometimes, the `issuer` field of an amount actually refers to a counterparty that is redeeming issuances, instead of the address that created the issuances. * When the `issuer` field of the destination `Amount` field matches the `Destination` address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all addresses to which the destination has extended trust lines, as well as issuances created by the destination which are held on other trust lines. @@ -49,7 +49,7 @@ Most of the time, the `issuer` field of a non-XRP [Currency Amount][] indicates The Payment transaction type can create new accounts in the XRP Ledger by sending enough XRP to an unfunded address. Other transactions to unfunded addresses always fail. -For more information, see [Accounts](concept-accounts.html#creating-accounts). +For more information, see [Accounts](accounts.html#creating-accounts). ## Paths @@ -64,7 +64,7 @@ If the `Paths` field is provided, the server decides at transaction processing t The `Paths` field must not be an empty array, nor an array whose members are all empty arrays. -For more information, see [Paths](concept-paths.html). +For more information, see [Paths](paths.html). ## Payment Flags @@ -84,7 +84,7 @@ A partial payment is any [Payment transaction][] with the **tfPartialPayment** f The [`delivered_amount`](#delivered-amount) field of a payment's metadata indicates the amount of currency actually received by the destination account. -For more information, see the full article on [Partial Payments](concept-partial-payments.html). +For more information, see the full article on [Partial Payments](partial-payments.html). ## Limit Quality 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 d77eba7526..131dea3426 100644 --- a/content/references/rippled-api/transaction-formats/transaction-types/trustset.md +++ b/content/references/rippled-api/transaction-formats/transaction-types/trustset.md @@ -42,11 +42,11 @@ Since a computer program cannot force a someone to keep a promise and not defaul There are two cases where you can hold a balance on a trust line that is *greater* than your limit: when you acquire more of that currency through [trading](#offercreate), or when you decrease the limit on your trust line. -Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](concept-reserves.html). This applies to the account extending trust, not to the account receiving it. +Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](reserves.html). This applies to the account extending trust, not to the account receiving it. A trust line with settings in the default state is equivalent to no trust line. -The default state of all flags is off, except for the [NoRipple flag](concept-noripple.html), whose default state depends on the DefaultRipple flag. +The default state of all flags is off, except for the [NoRipple flag](noripple.html), whose default state depends on the DefaultRipple flag. The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XRP reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. An issuer can pre-authorize a trust line with the `tfSetfAuth` flag only, even if the limit and balance of the trust line are 0. @@ -57,10 +57,10 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel | Flag Name | Hex Value | Decimal Value | Description | |:----------------|:-----------|:--------------|:------------------------------| | tfSetfAuth | 0x00010000 | 65536 | Authorize the other party to hold issuances from this account. (No effect unless using the [*asfRequireAuth* AccountSet flag](#accountset-flags).) Cannot be unset. | -| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](concept-noripple.html) for details.) | -| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [NoRipple](concept-noripple.html) for details.) | -| tfSetFreeze | 0x00100000 | 1048576 | [Freeze](concept-freeze.html) the trustline. | -| tfClearFreeze | 0x00200000 | 2097152 | [Unfreeze](concept-freeze.html) the trustline. | +| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](noripple.html) for details.) | +| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [NoRipple](noripple.html) for details.) | +| tfSetFreeze | 0x00100000 | 1048576 | [Freeze](freeze.html) the trustline. | +| tfClearFreeze | 0x00200000 | 2097152 | [Unfreeze](freeze.html) the trustline. | {% include '_snippets/rippled-api-links.md' %} diff --git a/content/tutorials/manage-account-settings/assign-a-regular-key-pair.md b/content/tutorials/manage-account-settings/assign-a-regular-key-pair.md index 632463368c..8cf04b67ec 100644 --- a/content/tutorials/manage-account-settings/assign-a-regular-key-pair.md +++ b/content/tutorials/manage-account-settings/assign-a-regular-key-pair.md @@ -2,7 +2,7 @@ The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions. If the private key of a regular key pair is compromised, you can remove or replace it without changing the rest of your account and re-establishing its relationships to other accounts. You can also rotate a regular key pair proactively. (Neither of those things is possible for the master key pair of an account, which is intrinsically linked to the account's address.) -For more information about master and regular key pairs, see [Cryptographic Keys](concept-cryptographic-keys.html). +For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html). This tutorial walks through the steps required to assign a regular key pair to your account: @@ -665,7 +665,7 @@ Now that you're familiar with the benefits of assigning a regular key pair to an - [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html) - [How to Multi-Sign](tutorial-multisign.html) -- [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html) +- [Issuing and Operational Addresses](issuing-and-operational-addresses.html) - [Listing XRP as an Exchange](tutorial-listing-xrp.html) diff --git a/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md b/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md index 762561ca1e..807ee590a5 100644 --- a/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md +++ b/content/tutorials/manage-account-settings/change-or-remove-a-regular-key-pair.md @@ -2,7 +2,7 @@ The XRP Ledger allows an account to authorize a secondary key pair, called a _regular key pair_, to sign future transactions. If your account's regular key pair is compromised, or if you just want to periodically change the regular key pair as a security measure, use a [SetRegularKey transaction][] to remove or change the regular key pair for your account. -For more information about master and regular key pairs, see [Cryptographic Keys](concept-cryptographic-keys.html). +For more information about master and regular key pairs, see [Cryptographic Keys](cryptographic-keys.html). ## Changing a Regular Key Pair @@ -352,7 +352,7 @@ An example of a successful response: -In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](concept-transaction-cost.html#key-reset-transaction) without paying the [transaction cost](reference-transaction-format.html#transaction-cost). With the enablement of the FeeEscalation amendment, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero. +In some cases, you can even use the `SetRegularKey` transaction to send a [key reset transaction](transaction-cost.html#key-reset-transaction) without paying the [transaction cost](reference-transaction-format.html#transaction-cost). With the enablement of the FeeEscalation amendment, `rippled` prioritizes key reset transactions above other transactions even though the nominal transaction cost of a key reset transaction is zero. {% include '_snippets/rippled-api-links.md' %} diff --git a/content/tutorials/manage-account-settings/set-up-multi-signing.md b/content/tutorials/manage-account-settings/set-up-multi-signing.md index 7978eb5359..e8056587c8 100644 --- a/content/tutorials/manage-account-settings/set-up-multi-signing.md +++ b/content/tutorials/manage-account-settings/set-up-multi-signing.md @@ -11,14 +11,14 @@ This tutorial demonstrates how to enable multi-signing for an address. - You must have access to a tool that can generate key pairs in the XRP Ledger format. If you are using a `rippled` server for this, you must have admin access because the [wallet_propose method][] is admin-only. -- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27. +- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27. ## 1. Prepare a funded address -You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](concept-reserves.html) and [transaction cost](concept-transaction-cost.html), increasing with the number of signers and signatures you use. +You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html) and [transaction cost](transaction-cost.html), increasing with the number of signers and signatures you use. -If you started `rippled` in [stand-alone mode](concept-stand-alone-mode.html) with a new genesis ledger, you must: +If you started `rippled` in [stand-alone mode](stand-alone-mode.html) with a new genesis ledger, you must: 1. Generate keys for a new address, or reuse keys you already have. 2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 [drops of XRP](reference-rippled.html#specifying-currency-amounts).) @@ -129,7 +129,7 @@ In this example, the SignerList has 3 members, with the weights and quorum set u Make sure that the [Transaction Result](reference-transaction-format.html#transaction-results) is [**tesSUCCESS**](reference-transaction-format.html#tes-success). Otherwise, the transaction failed. If you have a problem in stand-alone mode or a non-production network, check that [multi-sign is enabled](#availability-of-multi-signing). -**Note:** The more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](concept-reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](reference-transaction-format.html#tec-codes). See also: [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves). +**Note:** The more members in the SignerList, the more XRP your address must have for purposes of the [owner reserve](reserves.html#owner-reserves). If your address does not have enough XRP, the transaction fails with [tecINSUFFICIENT_RESERVE](reference-transaction-format.html#tec-codes). See also: [SignerLists and Reserves](reference-ledger-format.html#signerlists-and-reserves). ## 4. Close the ledger diff --git a/content/tutorials/manage-issued-currencies/set-up-issuing-and-operational-addresses.md b/content/tutorials/manage-issued-currencies/set-up-issuing-and-operational-addresses.md index 69331b023c..1239dc04c5 100644 --- a/content/tutorials/manage-issued-currencies/set-up-issuing-and-operational-addresses.md +++ b/content/tutorials/manage-issued-currencies/set-up-issuing-and-operational-addresses.md @@ -10,7 +10,7 @@ All non-XRP currency balances (issuances) in the XRP Ledger are tied to accounti When the issuing address sends payments, it creates balances in the accounting relationships in the XRP Ledger. Within the XRP Ledger, users can exchange balances across different accounting relationships, so we use the term _issuances_ to describe any non-XRP balance. Issuances have negative value from the perspective of the issuing address, since they represent obligations. The same issuances have positive value from the perspective of the issuing address's counterparties. When the issuing address receives a payment, this reduces its obligations, erasing the issuances that were sent. -The issuing address sends issuances to a standby address, or directly to an operational address. The standby addresses send those issuances to operational addresses. Operational addresses send payments to other counterparties, such as liquidity providers, partners, and other customers. Because all issuances are tied to accounting relationships with the issuing address, payments and exchanges of issuances "ripple through" the issuing address. The payment debits the sender's balance in its accounting relationship with the issuing address and credits the recipient's balance in the recipient's accounting relationship with the issuing address. The XRP Ledger also supports more complicated [paths](concept-paths.html) that connect multiple issuers through order books and [liquidity providers who allow their funds to ripple](concept-noripple.html). +The issuing address sends issuances to a standby address, or directly to an operational address. The standby addresses send those issuances to operational addresses. Operational addresses send payments to other counterparties, such as liquidity providers, partners, and other customers. Because all issuances are tied to accounting relationships with the issuing address, payments and exchanges of issuances "ripple through" the issuing address. The payment debits the sender's balance in its accounting relationship with the issuing address and credits the recipient's balance in the recipient's accounting relationship with the issuing address. The XRP Ledger also supports more complicated [paths](paths.html) that connect multiple issuers through order books and [liquidity providers who allow their funds to ripple](noripple.html). ## Issuing Address @@ -24,7 +24,7 @@ If a malicious actor learns the secret key behind a institution's issuing addres ### Multiple Issuing Addresses -A financial institution can issue more than one currency in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all currencies issued from an address, including the percentage for [transfer fees](concept-transfer-fees.html) and the [global freeze](concept-freeze.html) status. If the financial institution wants the flexibility to manage settings differently for each currency, the institution must use a different issuing address for each currency. +A financial institution can issue more than one currency in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all currencies issued from an address, including the percentage for [transfer fees](transfer-fees.html) and the [global freeze](freeze.html) status. If the financial institution wants the flexibility to manage settings differently for each currency, the institution must use a different issuing address for each currency. ## Operational Addresses diff --git a/content/tutorials/manage-the-rippled-server/advance-the-ledger-in-stand-alone-mode.md b/content/tutorials/manage-the-rippled-server/advance-the-ledger-in-stand-alone-mode.md index 0cfc82186d..e2e6304364 100644 --- a/content/tutorials/manage-the-rippled-server/advance-the-ledger-in-stand-alone-mode.md +++ b/content/tutorials/manage-the-rippled-server/advance-the-ledger-in-stand-alone-mode.md @@ -6,6 +6,6 @@ In stand-alone mode, `rippled` does not communicate to other members of the peer rippled ledger_accept --conf=/path/to/rippled.cfg ``` -In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](concept-consensus.html).) +In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](consensus.html).) Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed. **Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](reference-transaction-format.html#common-fields). diff --git a/content/tutorials/manage-the-rippled-server/start-a-new-genesis-ledger-in-stand-alone-mode.md b/content/tutorials/manage-the-rippled-server/start-a-new-genesis-ledger-in-stand-alone-mode.md index d3c5814436..f3deeb40b6 100644 --- a/content/tutorials/manage-the-rippled-server/start-a-new-genesis-ledger-in-stand-alone-mode.md +++ b/content/tutorials/manage-the-rippled-server/start-a-new-genesis-ledger-in-stand-alone-mode.md @@ -8,7 +8,7 @@ In stand-alone mode, you can have `rippled` create a new genesis ledger. This pr rippled -a --start --conf=/path/to/rippled.cfg ``` -In a genesis ledger, the [genesis address](concept-accounts.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows: +In a genesis ledger, the [genesis address](accounts.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows: **Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` @@ -16,6 +16,6 @@ In a genesis ledger, the [genesis address](concept-accounts.html#special-address ## Settings in New Genesis Ledgers -In a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html)) +In a new genesis ledger, the hard-coded default [Reserve](reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](fee-voting.html)) -By default, a new genesis ledger has no [amendments](concept-amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](reference-transaction-format.html#enableamendment) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the configuration file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](#advancing-ledgers-in-stand-alone-mode).) [New in: rippled 0.50.0][] +By default, a new genesis ledger has no [amendments](amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](reference-transaction-format.html#enableamendment) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the configuration file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](#advancing-ledgers-in-stand-alone-mode).) [New in: rippled 0.50.0][] diff --git a/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md b/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md index 63b9762950..28f75aa175 100644 --- a/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md +++ b/content/tutorials/use-complex-payment-types/use-checks/cancel-a-check.md @@ -1,10 +1,10 @@ # Cancel a Check -_Requires the [Checks Amendment](reference-amendments.html#checks)._ +_Requires the [Checks Amendment](known-amendments.html#checks)._ -This tutorial shows how to cancel a [Check](concept-checks.html), which removes the [Check object from the ledger](reference-ledger-format.html#check) without sending money. +This tutorial shows how to cancel a [Check](checks.html), which removes the [Check object from the ledger](check.html) without sending money. -You may want to cancel an incoming Check if you do not want it. You might cancel an outgoing Check if you made a mistake when sending it or if circumstances have changed. If a Check expires, it's also necessary to cancel it to remove it from the ledger so the sender gets their [owner reserve](concept-reserves.html#owner-reserves) back. +You may want to cancel an incoming Check if you do not want it. You might cancel an outgoing Check if you made a mistake when sending it or if circumstances have changed. If a Check expires, it's also necessary to cancel it to remove it from the ledger so the sender gets their [owner reserve](reserves.html#owner-reserves) back. {% set cancel_n = cycler(* range(1,99)) %} diff --git a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md b/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md index 11ec42f72b..85924c3ae4 100644 --- a/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md +++ b/content/tutorials/use-complex-payment-types/use-checks/cash-a-check-for-a-flexible-amount.md @@ -154,15 +154,15 @@ If cashing the Check failed with a `tec`-class code, look up the code in the [Fu | `tecNO_ENTRY` | The Check ID doesn't exist. | Confirm that the `CheckID` from the CheckCash transaction is correct. Confirm that the Check has not already been canceled or successfully cashed. | | `tecNO_LINE` | The recipient doesn't have a trust line for the Check's currency. | If you want to hold this currency from this issuer, create a trust line for the specified currency and issuer with a reasonable limit using a [TrustSet transaction][], then try to cash the check again. | | `tecNO_PERMISSION` | The sender of the CheckCash transaction isn't the `Destination` of the Check. | Double-check the `Destination` of the Check. | -| `tecNO_AUTH` | The issuer of the currency from the check is using [Authorized Trust Lines](concept-authorized-trust-lines.html) but the recipient's trust line to the issuer is not approved. | Ask the issuer to authorize this trust line, then try again to cash the Check after they do. | -| `tecPATH_PARTIAL` | The Check could not deliver enough issued currency, either due to trust line limits or because the sender does not have enough balance of the currency to send (after including the issuer's [transfer fee](concept-transfer-fees.html), if there is one). | If the problem is the trust line limit, send a [TrustSet transaction][] to increase your limit (if desired) or lower your balance by spending some of the currency, then try to cash the Check again. If the problem is the sender's balance, wait for the sender to have more of the Check's currency, or try again to cash the Check for a lesser amount. | +| `tecNO_AUTH` | The issuer of the currency from the check is using [Authorized Trust Lines](authorized-trust-lines.html) but the recipient's trust line to the issuer is not approved. | Ask the issuer to authorize this trust line, then try again to cash the Check after they do. | +| `tecPATH_PARTIAL` | The Check could not deliver enough issued currency, either due to trust line limits or because the sender does not have enough balance of the currency to send (after including the issuer's [transfer fee](transfer-fees.html), if there is one). | If the problem is the trust line limit, send a [TrustSet transaction][] to increase your limit (if desired) or lower your balance by spending some of the currency, then try to cash the Check again. If the problem is the sender's balance, wait for the sender to have more of the Check's currency, or try again to cash the Check for a lesser amount. | | `tecUNFUNDED_PAYMENT` | The Check could not deliver enough XRP. | Wait for the sender to have more XRP, or try again to cash the Check for a lesser amount. | ## {{cash_flex_n.next()}}. Confirm delivered amount If the Check was cashed for a flexible `DeliverMin` amount and succeeded, you can assume that the Check was cashed for at least the `DeliverMin` amount. To get the exact amount delivered, check the transaction metadata. The metadata's `AffectedNodes` array contains one or two objects that reflect the change in balances from cashing the Check, depending on the type of currency. -- For XRP, the `AccountRoot` object of the Check's sender has its XRP `Balance` field debited. The `AccountRoot` object of the Check's recipient (the one who sent the CheckCash transaction) has its XRP `Balance` credited for at least the `DeliverMin` of the CheckCash transaction minus the [transaction cost](concept-transaction-cost.html) of sending the transaction. +- For XRP, the `AccountRoot` object of the Check's sender has its XRP `Balance` field debited. The `AccountRoot` object of the Check's recipient (the one who sent the CheckCash transaction) has its XRP `Balance` credited for at least the `DeliverMin` of the CheckCash transaction minus the [transaction cost](transaction-cost.html) of sending the transaction. For example, the following `ModifiedNode` shows that the account rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis, the Check's recipient and the sender of this CheckCash transaction, had its XRP balance change from `9999999970` drops to `10099999960` drops, meaning the recipient was credited a _net_ of 99.99999 XRP as a result of processing the transaction. @@ -201,7 +201,7 @@ If the Check was cashed for a flexible `DeliverMin` amount and succeeded, you ca - - If the issued currency has a [transfer fee](concept-transfer-fees.html), the Check's sender may be debited more than the recipient is credited. (The difference is the transfer fee, which is returned to the issuer as a decreased net obligation.) + - If the issued currency has a [transfer fee](transfer-fees.html), the Check's sender may be debited more than the recipient is credited. (The difference is the transfer fee, which is returned to the issuer as a decreased net obligation.) [Specifying Currency Amounts]: reference-rippled.html#specifying-currency-amounts diff --git a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md b/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md index 64c7504eff..d2a7e480dc 100644 --- a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md +++ b/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-recipient.md @@ -2,7 +2,7 @@ _Requires the [Checks Amendment](reference-amendments.html#checks)._ -This tutorial shows how to look up [Checks](concept-checks.html) by their recipient. You may also want to [look up Checks by sender](tutorial-checks-lookup-by-sender.html). +This tutorial shows how to look up [Checks](checks.html) by their recipient. You may also want to [look up Checks by sender](tutorial-checks-lookup-by-sender.html). ## 1. Look up all Checks for the address diff --git a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md b/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md index ed2e7a3100..b67f15f835 100644 --- a/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md +++ b/content/tutorials/use-complex-payment-types/use-checks/look-up-checks-by-sender.md @@ -2,7 +2,7 @@ _Requires the [Checks Amendment](reference-amendments.html#checks)._ -This tutorial shows how to look up [Checks](concept-checks.html) by their sender. You may also want to [look up Checks by recipient](tutorial-checks-lookup-by-recipient.html). +This tutorial shows how to look up [Checks](checks.html) by their sender. You may also want to [look up Checks by recipient](tutorial-checks-lookup-by-recipient.html). ## 1. Look up all Checks for the address diff --git a/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md b/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md index e17ff08d08..14191b4691 100644 --- a/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md +++ b/content/tutorials/use-complex-payment-types/use-checks/send-a-check.md @@ -4,7 +4,7 @@ _Requires the [Checks Amendment](reference-amendments.html#checks)._ Sending a Check is like writing permission for an intended recipient to pull a payment from you. The outcome of this process is a [Check object in the ledger](reference-ledger-format.html#check) which the recipient can cash later. -In many cases, you want to send a [Payment][] instead of a Check, since that delivers the money directly to the recipient in one step. However, if your intended recipient uses [DepositAuth](concept-depositauth.html), you cannot send them Payments directly, so a Check is a good alternative. +In many cases, you want to send a [Payment][] instead of a Check, since that delivers the money directly to the recipient in one step. However, if your intended recipient uses [DepositAuth](depositauth.html), you cannot send them Payments directly, so a Check is a good alternative. This tutorial uses the example of a fictitious company, BoxSend SG (whose XRP Ledger address is rBXsgNkPcDN2runsvWmwxk3Lh97zdgo9za) paying a fictitious cryptocurrency consulting company named Grand Payments (with XRP Ledger address rGPnRH1EBpHeTF2QG8DCAgM7z5pb75LAis) for some consulting work. Grand Payments prefers be paid in XRP, but to simplify their taxes and regulation, only accepts payments they've explicitly approved. @@ -32,7 +32,7 @@ Decide how much money the Check is for and who can cash it. Figure out the value | `TransactionType` | String | Use the string `CheckCreate` here. | | `Account` | String (Address) | The address of the sender who is creating the Check. (In other words, your address.) | | `Destination` | String (Address) | The address of the intended recipient who can cash the Check. | -| `SendMax` | String or Object (Amount) | The maximum amount the sender can be debited when this Check gets cashed. For XRP, use a string representing drops of XRP. For issued currencies, use an object with `currency`, `issuer`, and `value` fields. See [Specifying Currency Amounts][] for details. If you want the recipient to be able to cash the Check for an exact amount of a non-XRP currency with a [transfer fee](concept-transfer-fees.html), remember to include an extra percentage to pay for the transfer fee. (For example, for the recipient to cash a Check for 100 CAD from an issuer with a 2% transfer fee, you must set the `SendMax` to 102 CAD from that issuer.) | +| `SendMax` | String or Object (Amount) | The maximum amount the sender can be debited when this Check gets cashed. For XRP, use a string representing drops of XRP. For issued currencies, use an object with `currency`, `issuer`, and `value` fields. See [Specifying Currency Amounts][] for details. If you want the recipient to be able to cash the Check for an exact amount of a non-XRP currency with a [transfer fee](transfer-fees.html), remember to include an extra percentage to pay for the transfer fee. (For example, for the recipient to cash a Check for 100 CAD from an issuer with a 2% transfer fee, you must set the `SendMax` to 102 CAD from that issuer.) | If you are using [RippleAPI](reference-rippleapi.html), you can use the `prepareCheckCreate()` helper method. diff --git a/content/tutorials/use-complex-payment-types/use-payment-channels.md b/content/tutorials/use-complex-payment-types/use-payment-channels.md index 6f85b3b67c..c761ad002b 100644 --- a/content/tutorials/use-complex-payment-types/use-payment-channels.md +++ b/content/tutorials/use-complex-payment-types/use-payment-channels.md @@ -51,7 +51,7 @@ This is a [PaymentChannelCreate transaction][]. As part of this process, the pay The following example shows creation of a payment channel by [submitting](reference-rippled.html#sign-and-submit-mode) to a local `rippled` server with the JSON-RPC API. The payment channel allocates 100 XRP from the [example payer](#example-values) (rN7n7...) to the [example payee](#example-values) (rf1Bi...) with a settlement delay of 1 day. The public key is the example payer's master public key, in hexadecimal. -**Note:** A payment channel counts as one object toward the payer's [owner reserve](concept-reserves.html#owner-reserves). The owner must keep at least enough XRP to satisfy the reserve after subtracting the XRP allocated to the payment channel. +**Note:** A payment channel counts as one object toward the payer's [owner reserve](reserves.html#owner-reserves). The owner must keep at least enough XRP to satisfy the reserve after subtracting the XRP allocated to the payment channel. Request: @@ -160,7 +160,7 @@ In the response from the JSON-RPC, the payer should look for the following: ## 2. The payee checks specifics of the payment channel. -You can look up payment channels with the [`account_channels` API method](reference-rippled.html#account-channels), using the payer of the channel, as in the following example (using the JSON-RPC API): +You can look up payment channels with the [account_channels method][], using the payer of the channel, as in the following example (using the JSON-RPC API): Request: @@ -215,7 +215,7 @@ The amounts of these claims depends on the specific goods or services the payer Each claim must be for a cumulative amount. In other words, to buy two items at 10 XRP each, the first claim should have an amount of 10 XRP and the second claim should have an amount of 20 XRP. The claim can never be more than the total amount of XRP allocated to the channel. (A [PaymentChannelFund][] transaction can increase the total amount of XRP allocated to the channel.) -You can create claims with the [`channel_authorize` API method](reference-rippled.html#channel-authorize). The following example authorizes 1 XRP from the channel: +You can create claims with the [channel_authorize method][]. The following example authorizes 1 XRP from the channel: Request: @@ -257,7 +257,7 @@ The payee also needs to know the Public Key associated with the channel, which i ## 5. The payee verifies the claims. -You can verify claims using the [`channel_verify` API method](reference-rippled.html#channel-verify). The payee should confirm that the amount of the claim is equal to or greater than the total price of goods and services provided. (Since the amount is cumulative, this is the total price of all goods and services bought so far.) +You can verify claims using the [channel_verify method][]. The payee should confirm that the amount of the claim is equal to or greater than the total price of goods and services provided. (Since the amount is cumulative, this is the total price of all goods and services bought so far.) Example of using `channel_verify` with the JSON-RPC API: @@ -477,7 +477,7 @@ In this example, the `expiration` value 547073182 in [seconds since the Ripple E After the settlement delay has passed or the channel has reached its planned expiration time, the channel is expired. Any further transaction that would affect the channel can only close it, returning unclaimed XRP to the payer. -The channel can remain on the ledger in an expired state indefinitely. This is because the ledger cannot change except as the results of a transaction, so _someone_ must send a transaction to cause the expired channel to close. As long as the channel remains on the ledger, it counts as an object owned by the payer for purposes of the [owner reserve](concept-reserves.html#owner-reserves). +The channel can remain on the ledger in an expired state indefinitely. This is because the ledger cannot change except as the results of a transaction, so _someone_ must send a transaction to cause the expired channel to close. As long as the channel remains on the ledger, it counts as an object owned by the payer for purposes of the [owner reserve](reserves.html#owner-reserves). Ripple recommends that the payer sends a second [PaymentChannelClaim transaction][] with the `tfClose` flag for this purpose. However, other accounts, even those not involved in the payment channel, can cause an expired channel to close. diff --git a/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md b/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md index d235948254..1feaa34d5f 100644 --- a/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md +++ b/content/tutorials/use-simple-xrp-payments/reliable-transaction-submission.md @@ -19,7 +19,7 @@ These types of errors can potentially lead to serious problems. For example, an The XRP Ledger protocol provides a ledger shared across all servers in the network. Through a [process of consensus and validation](https://ripple.com/build/ripple-ledger-consensus-process/), the network agrees on the order in which transactions are applied to (or omitted from) the ledger. -Well-formed transactions submitted to trusted XRP Ledger servers are usually validated or rejected in a matter of seconds. There are cases, however, in which a well-formed transaction is neither validated nor rejected this quickly. One specific case can occur if the global [transaction cost](concept-transaction-cost.html) increases after an application sends a transaction. If the transaction cost increases above what has been specified in the transaction, the transaction is not included in the next validated ledger. If at some later date the global transaction cost decreases, the transaction could be included in a later ledger. If the transaction does not specify an expiration, there is no limit to how much later this can occur. +Well-formed transactions submitted to trusted XRP Ledger servers are usually validated or rejected in a matter of seconds. There are cases, however, in which a well-formed transaction is neither validated nor rejected this quickly. One specific case can occur if the global [transaction cost](transaction-cost.html) increases after an application sends a transaction. If the transaction cost increases above what has been specified in the transaction, the transaction is not included in the next validated ledger. If at some later date the global transaction cost decreases, the transaction could be included in a later ledger. If the transaction does not specify an expiration, there is no limit to how much later this can occur. If a power or network outage occurs, applications face more challenges finding the status of submitted transactions. Applications must take care both to properly submit a transaction and later to properly get authoritative results. @@ -135,7 +135,7 @@ For each persisted transaction without validated result: The difference between the two transaction failure cases (labeled (1) and (2) in the pseudo-code) is whether the transaction was included in a validated ledger. In both cases, you should decide carefully how to process the failure. -- In failure case (1), the transaction was included in a ledger and destroyed the [XRP transaction cost](concept-transaction-cost.html), but did nothing else. This could be caused by a lack of liquidity, improperly specified [paths](concept-paths.html), or other circumstances. For many such failures, immediately retrying with a similar transaction is likely to have the same result. You may get different results if you wait for circumstances to change. +- In failure case (1), the transaction was included in a ledger and destroyed the [XRP transaction cost](transaction-cost.html), but did nothing else. This could be caused by a lack of liquidity, improperly specified [paths](paths.html), or other circumstances. For many such failures, immediately retrying with a similar transaction is likely to have the same result. You may get different results if you wait for circumstances to change. - In failure case (2), the transaction was not included in a validated ledger, so it did nothing at all, not even destroy the transaction cost. This could be the result of the transaction cost being too low for the current load on the XRP Ledger, the `LastLedgerSequence` being too soon, or it could be due to other conditions such as an unstable network connection. In contrast to failure case (1), it is more likely that a new transaction is likely to succeed if you change only the `LastLedgerSequence` and possibly the `Fee` and submit again. - It is also possible that the transaction could not succeed due to the state of the ledger, for example because the sending address disabled the key pair used to sign the transaction. If the transaction's provisional result was a [`tef`-class code](reference-transaction-format.html#tef-codes), the transaction is less likely to succeed without further modification. @@ -511,7 +511,7 @@ Finally the server may show one or more gaps in the transaction history. The `co ## Additional Resources - [Transaction Format](reference-transaction-format.html) -- [Transaction Cost](concept-transaction-cost.html) +- [Transaction Cost](transaction-cost.html) - [`LastLedgerSequence` field](reference-transaction-format.html#lastledgersequence) -- [Overview of XRP Ledger Consensus Process](concept-consensus.html) -- [Reaching Consensus in the XRP Ledger](concept-reaching-consensus.html) +- [Overview of XRP Ledger Consensus Process](consensus.html) +- [Reaching Consensus in the XRP Ledger](reaching-consensus.html) diff --git a/content/tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md b/content/tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md index 5c19068ef6..9da9c2d470 100644 --- a/content/tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md +++ b/content/tutorials/use-simple-xrp-payments/send-a-multisigned-transaction.md @@ -6,14 +6,14 @@ The following procedure demonstrates how to create, sign, and submit a multi-sig - You must have already [set up multi-signing](set-up-multi-signing.html) for your address. -- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](concept-amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27. +- Multi-signing must be available. Multi-signing has been enabled by an [**Amendment**](amendments.html) to the XRP Ledger Consensus Protocol since 2016-06-27. ### 1. Create the transaction Create a JSON object that represents the transaction you want to submit. You have to specify _everything_ about this transaction, including `Fee` and `Sequence`. Also include the field `SigningPubKey` as an empty string, to indicate that the transaction is multi-signed. -Keep in mind that the `Fee` for multi-signed transactions is significantly higher than for regularly-signed transactions. It should be at least (N+1) times the normal [transaction cost](concept-transaction-cost.html), where N is the number of signatures you plan to provide. Since it sometimes takes a while to collect signatures from multiple sources, you may want to specify more than the current minimum, in case the [transaction cost](concept-transaction-cost.html) increases in that time. +Keep in mind that the `Fee` for multi-signed transactions is significantly higher than for regularly-signed transactions. It should be at least (N+1) times the normal [transaction cost](transaction-cost.html), where N is the number of signatures you plan to provide. Since it sometimes takes a while to collect signatures from multiple sources, you may want to specify more than the current minimum, in case the [transaction cost](transaction-cost.html) increases in that time. Here's an example transaction ready to be multi-signed: diff --git a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md index b3e56a13ff..8aab2e44aa 100644 --- a/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md +++ b/content/tutorials/xrp-ledger-businesses/become-an-xrp-ledger-gateway.md @@ -36,7 +36,7 @@ A "trust line" is link between two addresses in the XRP Ledger. A trust line rep **XRP** is the native cryptocurrency of the XRP Ledger. Like issuances, XRP can be freely sent and exchanged among XRP Ledger addresses. Unlike issuances, XRP is not tied to an accounting relationship. XRP can be sent directly from any XRP Ledger address to any other, without going through a gateway or liquidity provider. This helps make XRP a convenient bridge currency. For more information on XRP, see the [XRP Portal](https://ripple.com/xrp-portal/). -XRP also serves other purposes in the XRP Ledger, in particular as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to pay the costs of maintaining the XRP Ledger. The [transaction cost](concept-transaction-cost.html) and [reserve](concept-reserves.html) are neutral fees denoted in XRP and not paid to any party. +XRP also serves other purposes in the XRP Ledger, in particular as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to pay the costs of maintaining the XRP Ledger. The [transaction cost](transaction-cost.html) and [reserve](reserves.html) are neutral fees denoted in XRP and not paid to any party. Issuing gateways do not need to accumulate or exchange XRP. They must only hold a small balance of XRP to send transactions through the network. The XRP equivalent of $10 USD should be enough for at least one year of transaction costs for a busy gateway. @@ -57,7 +57,7 @@ Contact [partners@ripple.com](mailto:partners@ripple.com) for help establishing The value of a gateway's issuances in the XRP Ledger comes directly from the trust that customers can redeem them with the gateway when needed. We recommend the following precautions to reduce the risk of business interruptions: -* Use separate [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html) to limit your risk profile on the network. +* Use separate [Issuing and Operational Addresses](issuing-and-operational-addresses.html) to limit your risk profile on the network. * Follow anti-money-laundering regulations for your jurisdiction, such as the [Bank Secrecy Act](http://en.wikipedia.org/wiki/Bank_Secrecy_Act). This usually includes requirements to collect ["Know-Your-Customer" (KYC) information](http://en.wikipedia.org/wiki/Know_your_customer). * Read and stay up-to-date with [Gateway Bulletins](#gateway-bulletins), which provide news and suggestions for XRP Ledger gateways. * Publicize all your policies and fees. @@ -67,7 +67,7 @@ The value of a gateway's issuances in the XRP Ledger comes directly from the tru {% include '_snippets/issuing-and-operational-addresses-intro.md' %} -For more information, see [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html) +For more information, see [Issuing and Operational Addresses](issuing-and-operational-addresses.html) ## Fees and Revenue Sources @@ -242,7 +242,7 @@ There are several prerequisites that ACME must meet for this to happen: - ACME may create a XRP Ledger collateral account in ACME's system of record. - ACME can store the funds allocated to the XRP Ledger in a separate bank account. - If ACME is a cryptocurrency exchange, ACME can create a separate wallet to hold the funds allocated to the XRP Ledger, as publicly-verifiable proof to customers that the gateway is solvent. -- ACME must control an address in the XRP Ledger. Ripple's best practices recommend using a separate issuing address and operational address. See [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html) for details. +- ACME must control an address in the XRP Ledger. Ripple's best practices recommend using a separate issuing address and operational address. See [Issuing and Operational Addresses](issuing-and-operational-addresses.html) for details. - ACME must enable the [DefaultRipple Flag](#defaultripple) on its issuing address for customers to send and receive its issuances. - Alice must create an accounting relationship (trust line) from her XRP Ledger address to ACME's issuing address. She can do this from any XRP Ledger client application as long as she knows ACME's issuing address. - ACME should publicize its issuing address on its website where customers can find it. It can also use [ripple.txt](#rippletxt) to publish the issuing address to automated systems. @@ -316,14 +316,14 @@ A gateway can freeze accounting relationships in the XRP Ledger to meet regulato * Gateways can freeze all accounting relationships to their issuing address, in case of a major security compromise or for migrating to a new issuing address. * Furthermore, gateways can permanently opt out of their ability to freeze accounting relationships. This allows a gateway to assure its customers that it will continue to provide "physical-money-like" services. -For more information, see the [Freeze article](concept-freeze.html). +For more information, see the [Freeze article](freeze.html). ## Authorized Trust Lines The XRP Ledger's Authorized Trust Lines feature (formerly called "Authorized Accounts") enables a gateway to limit who can hold that gateway's issuances, so that unknown XRP Ledger addresses cannot hold the currency the gateway issues. Ripple feels this is *not necessary* in most cases, since gateways have full control over the process of redeeming Ripple balances for value in the outside world. (You can collect customer information and impose limits on withdrawals at that stage without worrying about what happens within the XRP Ledger.) -For more information, see [Authorized Trust Lines](concept-authorized-trust-lines.html). +For more information, see [Authorized Trust Lines](authorized-trust-lines.html). ## Source and Destination Tags @@ -387,7 +387,7 @@ The examples in this document show API methods that include a secret key. This i ## DefaultRipple -The DefaultRipple flag controls whether the balances in an accounting relationship [allowed to ripple](concept-noripple.html) by default. Rippling is what allows customers to trade issuances, so a gateway must allow rippling on all the accounting relationships to its issuing address. +The DefaultRipple flag controls whether the balances in an accounting relationship [allowed to ripple](noripple.html) by default. Rippling is what allows customers to trade issuances, so a gateway must allow rippling on all the accounting relationships to its issuing address. 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. @@ -574,7 +574,7 @@ Response: ## RequireAuth -The `RequireAuth` setting prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty. For more information, see [Authorized Trust Lines](concept-authorized-trust-lines.html). +The `RequireAuth` setting prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty. For more information, see [Authorized Trust Lines](authorized-trust-lines.html). ### Enabling RequireAuth @@ -605,7 +605,7 @@ POST http://localhost:5005/ ### Authorizing Trust Lines -If you are using the [Authorized Trust Lines](concept-authorized-trust-lines.html) feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the XRP Ledger. +If you are using the [Authorized Trust Lines](authorized-trust-lines.html) feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the XRP Ledger. 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. @@ -660,7 +660,7 @@ As an added precaution, we recommend comparing the balances of your issuing addr ## TransferRate -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 *TransferRate* setting (`transferRate` in RippleAPI) defines a fee to charge for transferring issuances from one XRP Ledger address to another. See [Transfer Fees](transfer-fees.html) for more information. 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%. @@ -726,7 +726,7 @@ For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver When you build an automated system to send payments into the XRP Ledger for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should. -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. +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](paths.html#default-paths) can deliver the currency as intended. 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. @@ -796,7 +796,7 @@ Response: In particular, note the following features of the [Payment Transaction](reference-transaction-format.html#payment): -- No `Paths` field. The payment only succeeds if it can use a [default path](concept-paths.html#default-paths), which is preferable. Using less direct paths can become much more expensive. +- No `Paths` field. The payment only succeeds if it can use a [default path](paths.html#default-paths), which is preferable. Using less direct paths can become much more expensive. - The `issuer` of both the `SendMax` and the `Amount` is the issuing address. This ensures that the transaction sends and delivers issuances from the issuing address, and not from some other gateway. - The `value` of the `SendMax` amount is slightly higher than the destination `Amount`, to compensate for the [transfer fee](#transferrate). In this case, the transfer fee is 0.5%, so the `SendMax` amount is exactly 1.005 times the destination `Amount`. diff --git a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md index 2dcf4b8d6b..067824b6b9 100644 --- a/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md +++ b/content/tutorials/xrp-ledger-businesses/list-xrp-as-an-exchange.md @@ -50,17 +50,17 @@ Before integrating, exchanges should be aware of the [partial payments](referenc When the [tfPartialPayment flag](reference-transaction-format.html#payment-flags) is enabled, the `Amount` field **_is not guaranteed to be the amount received_**. The `delivered_amount` field of a payment's metadata indicates the amount of currency actually received by the destination account. When receiving a payment, use `delivered_amount` instead of the Amount field to determine how much your account received instead. -**Warning:** Be aware that malicious actors could exploit this. For more information, see [Partial Payments](concept-partial-payments.html). +**Warning:** Be aware that malicious actors could exploit this. For more information, see [Partial Payments](partial-payments.html). ### Accounts -XRP is held in _accounts_ (also referred to as _wallets_ or _addresses_ ) on the XRP Ledger. Accounts on the XRP Ledger are different than accounts on other blockchain ledgers, such as Bitcoin, where accounts incur little to no overhead. In the XRP Ledger, accounts can [never be deleted](concept-accounts.html#permanence-of-accounts), and each account must hold a separate [reserve of XRP](concept-reserves.html) that cannot be sent to others. For these reasons, Ripple recommends that institutions not create excessive or needless accounts. +XRP is held in _accounts_ (also referred to as _wallets_ or _addresses_ ) on the XRP Ledger. Accounts on the XRP Ledger are different than accounts on other blockchain ledgers, such as Bitcoin, where accounts incur little to no overhead. In the XRP Ledger, accounts can [never be deleted](accounts.html#permanence-of-accounts), and each account must hold a separate [reserve of XRP](reserves.html) that cannot be sent to others. For these reasons, Ripple recommends that institutions not create excessive or needless accounts. To follow Ripple's recommended best practices, Alpha Exchange should create at least two new accounts on the XRP Ledger. To minimize the risks associated with a compromised secret key, Ripple recommends creating [_cold_, _hot_, and _warm_ accounts](https://ripple.com/build/issuing-operational-addresses/) (these are sometimes referred to, respectively, as cold, hot, and warm wallets). The hot/warm/cold model is intended to balance security and convenience. Exchanges listing XRP should create the following accounts: -* A [_cold wallet_](concept-issuing-and-operational-addresses.html#issuing-address) to securely hold the majority of XRP and customers' funds. For exchanges, this is also the address to which its users send [deposits](#deposit-xrp-into-exchange). To provide optimal security, this account's secret key should be offline. +* A [_cold wallet_](issuing-and-operational-addresses.html#issuing-address) to securely hold the majority of XRP and customers' funds. For exchanges, this is also the address to which its users send [deposits](#deposit-xrp-into-exchange). To provide optimal security, this account's secret key should be offline. If a malicious actor compromises an exchange's cold wallet, the possible consequences are: @@ -76,24 +76,24 @@ To follow Ripple's recommended best practices, Alpha Exchange should create at l * If a malicious actor sets the asfRequireAuth flag for the account, that cannot be unset, although this only relates to issuing currency and should not affect an exchange that is not also a gateway. Any other settings a malicious actor sets or unsets with a master key can be reverted. -* One or more [_hot wallets_](concept-issuing-and-operational-addresses.html#operational-addresses) to conduct the day-to-day business of managing customers' XRP withdrawals and deposits. For example, with a hot wallet, exchanges can securely support these types of automated XRP transfers. Hot wallets need to be online to service instant withdrawal requests. +* One or more [_hot wallets_](issuing-and-operational-addresses.html#operational-addresses) to conduct the day-to-day business of managing customers' XRP withdrawals and deposits. For example, with a hot wallet, exchanges can securely support these types of automated XRP transfers. Hot wallets need to be online to service instant withdrawal requests. - For more information about the possible consequences of a compromised hot wallet, see [Operational Account Compromise](concept-issuing-and-operational-addresses.html#operational-address-compromise). + For more information about the possible consequences of a compromised hot wallet, see [Operational Account Compromise](issuing-and-operational-addresses.html#operational-address-compromise). * Optionally, one or more warm wallets to provide an additional layer of security between the cold and hot wallets. Unlike a hot wallet, the secret key of a warm wallet does not need to be online. Additionally, you can distribute the secret keys for the warm wallet to several different people and implement [multisigning](tutorial-multisign.html) to increase security. - For more information about the possible consequences of a compromised warm wallet, see [Standby Account Compromise](concept-issuing-and-operational-addresses.html#standby-address-compromise). + For more information about the possible consequences of a compromised warm wallet, see [Standby Account Compromise](issuing-and-operational-addresses.html#standby-address-compromise). See also: * ["Suggested Business Practices" in the _Gateway Guide_](tutorial-gateway-guide.html#suggested-business-practices) -* [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html) +* [Issuing and Operational Addresses](issuing-and-operational-addresses.html) * [Creating Accounts](reference-transaction-format.html#creating-accounts) -* [Reserves](concept-reserves.html) +* [Reserves](reserves.html) ### Balance Sheets @@ -193,7 +193,7 @@ For more information, see [Specifying Currency Amounts](reference-rippled.html#s With exchanges like _Alpha Exchange_, XRP can be "on-ledger" or "off-ledger": -* **On-Ledger XRP**: XRP that can be queried through the public XRP Ledger by specifying the public [address](concept-accounts.html#addresses) of the XRP holder. The counterparty to these balances is the XRP Ledger. For more information, see [Currencies](reference-rippled.html#currencies). +* **On-Ledger XRP**: XRP that can be queried through the public XRP Ledger by specifying the public [address](accounts.html#addresses) of the XRP holder. The counterparty to these balances is the XRP Ledger. For more information, see [Currencies](reference-rippled.html#currencies). * **Off-Ledger XRP**: XRP that is held by the accounting system of an exchange and can be queried through the exchange interface. Off-ledger XRP balances are credit-based. The counterparty is the exchange holding the XRP. @@ -412,7 +412,7 @@ Customers who hold XRP in their own XRP Ledger accounts can also use the distrib ### Rebalance XRP Holdings -Exchanges can adjust the balances between their hot and cold wallets at any time. Each balance adjustment consumes a [transaction cost](concept-transaction-cost.html), but does not otherwise affect the aggregate balance of all the accounts. The aggregate, on-ledger balance should always exceed the total balance available for trade on the exchange. (The excess should be enough to cover the XRP Ledger's transaction costs.) +Exchanges can adjust the balances between their hot and cold wallets at any time. Each balance adjustment consumes a [transaction cost](transaction-cost.html), but does not otherwise affect the aggregate balance of all the accounts. The aggregate, on-ledger balance should always exceed the total balance available for trade on the exchange. (The excess should be enough to cover the XRP Ledger's transaction costs.) The following table demonstrates a balance adjustment of 80,000 XRP (via a [_payment_](reference-transaction-format.html#payment) on the XRP Ledger) between Alpha Exchange's cold wallet and its hot wallet, where the cold wallet was debited and the hot wallet was credited. If the payment were reversed (debiting the hot wallet and crediting the cold wallet), the hot wallet balance would decrease. Balance adjustments like these allow an exchange to limit the risks associated with holding XRP in online hot wallets.