mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Last link cleanup(??) and removing now-unused files
This commit is contained in:
mDuo13
@@ -52,7 +52,7 @@ A request can include the following parameters:
|
||||
| `account` | String | A unique identifier for the account, most commonly the account's [Address][]. |
|
||||
| `ledger` | Unsigned integer, or String | (Deprecated, Optional) A unique identifier for the ledger version to use, such as a ledger sequence number, a hash, or a shortcut such as "validated". |
|
||||
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string identifying the ledger version to use. |
|
||||
| `ledger_index` | _(Optional)_ [Ledger Index][] | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers](#specifying-ledgers)) |
|
||||
| `ledger_index` | _(Optional)_ [Ledger Index][] | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers][]) |
|
||||
| `limit` | Integer | (Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. Must be within the inclusive range 10 to 400. [New in: rippled 0.26.4][] |
|
||||
| `marker` | [Marker][] | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. [New in: rippled 0.26.4][] |
|
||||
|
||||
@@ -172,11 +172,11 @@ Each offer object contains the following fields:
|
||||
| `Field` | Type | Description |
|
||||
|:-------------|:-----------------|:-------------------------------------------|
|
||||
| `flags` | Unsigned integer | Options set for this offer entry as bit-flags. |
|
||||
| `seq` | Unsigned integer | Sequence number of the transaction that created this entry. (Transaction [sequence numbers](#account-sequence) are relative to accounts.) |
|
||||
| `seq` | Unsigned integer | Sequence number of the transaction that created this entry. (Transaction [sequence numbers](basic-data-types.html#account-sequence) are relative to accounts.) |
|
||||
| `taker_gets` | String or Object | The amount the account accepting the offer receives, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts][Currency Amount]) |
|
||||
| `taker_pays` | String or Object | The amount the account accepting the offer provides, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts][Currency Amount]) |
|
||||
| `quality` | String | The exchange rate of the offer, as the ratio of the original `taker_pays` divided by the original `taker_gets`. When executing offers, the offer with the most favorable (lowest) quality is consumed first; offers with the same quality are executed from oldest to newest. [New in: rippled 0.29.0][] |
|
||||
| `expiration` | Unsigned integer | (May be omitted) A time after which this offer is considered unfunded, as [the number of seconds since the Ripple Epoch](#specifying-time). See also: [Offer Expiration](offers.html#offer-expiration). [New in: rippled 0.30.1][] |
|
||||
| `expiration` | Unsigned integer | (May be omitted) A time after which this offer is considered unfunded, as the number of [seconds since the Ripple Epoch][]. See also: [Offer Expiration](offers.html#offer-expiration). [New in: rippled 0.30.1][] |
|
||||
|
||||
## Possible Errors
|
||||
|
||||
|
||||
@@ -161,7 +161,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `ledger_index` | Integer | (Omitted if ledger\_current\_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| `ledger_hash` | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| `marker` | [Marker][] | (May be omitted) Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. |
|
||||
| `offers` | Array | Array of offer objects, each of which has the fields of an [OfferCreate transaction](reference-transaction-format.html#offercreate) |
|
||||
| `offers` | Array | Array of offer objects, each of which has the fields of an [OfferCreate transaction][] |
|
||||
|
||||
In addition to the standard Offer fields, the following fields may be included in members of the `offers` array:
|
||||
|
||||
@@ -184,5 +184,7 @@ In addition to the standard Offer fields, the following fields may be included i
|
||||
* `badMarket` - The desired order book does not exist; for example, offers to exchange a currency for itself.
|
||||
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# path_find
|
||||
[[Source]<br>](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](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 the [ripple_path_find method][]. 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:
|
||||
|
||||
@@ -433,7 +433,7 @@ An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The initial response follows the [standard format](#response-formatting), with a successful result containing the following fields:
|
||||
The initial response follows the [standard format](response-formatting.html), with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:----------------------|:-----------------|:----------------------------------|
|
||||
@@ -455,7 +455,7 @@ Each element in the `alternatives` array is an object that represents a path fro
|
||||
|
||||
* Any of the [universal error types][].
|
||||
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
|
||||
* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See the [ripple_path_find method][] for a pathfinding method that _is_ compatible with JSON-RPC.)
|
||||
|
||||
### Asynchronous Follow-ups
|
||||
|
||||
@@ -530,7 +530,7 @@ If there was no outstanding pathfinding request, an error is returned instead.
|
||||
|
||||
* Any of the [universal error types][].
|
||||
* `invalidParams` - If any fields are specified incorrectly, or any required fields are missing.
|
||||
* `noEvents` - If you tried to use this method on a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
|
||||
* `noEvents` - If you tried to use this method on a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See the [ripple_path_find method][] for a pathfinding method that _is_ compatible with JSON-RPC.)
|
||||
* `noPathRequest` - You tried to close a pathfinding request when there is not an open one.
|
||||
|
||||
## path_find status
|
||||
@@ -575,7 +575,7 @@ If there was no outstanding pathfinding request, an error is returned instead.
|
||||
|
||||
* Any of the [universal error types][].
|
||||
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See [ripple\_path\_find](#ripple-path-find) for a pathfinding method that _is_ compatible with JSON-RPC.)
|
||||
* `noEvents` - You are using a protocol that does not support asynchronous callbacks, for example JSON-RPC. (See the [ripple_path_find method][] for a pathfinding method that _is_ compatible with JSON-RPC.)
|
||||
* `noPathRequest` - You tried to check the status of a pathfinding request when there is not an open one.
|
||||
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
The `sign` method takes a [transaction in JSON format](transaction-formats.html) and a secret key, and returns a signed binary representation of the transaction. The result is always different, even when you provide the same transaction JSON and secret key. To contribute one signature to a multi-signed transaction, use the [sign_for method][] instead.
|
||||
|
||||
**Caution:** Unless you run the `rippled` server yourself, you should do [local signing with RippleAPI](reference-rippleapi.html#sign) instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
|
||||
**Caution:** Unless you run the `rippled` server yourself, you should do [local signing with RippleAPI](rippleapi-reference.html#sign) instead of using this command. An untrustworthy server could change the transaction before signing it, or use your secret key to sign additional arbitrary transactions as if they came from you.
|
||||
|
||||
## Request Format
|
||||
An example of the request format:
|
||||
@@ -85,7 +85,7 @@ 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](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_mult_max` | Integer | (Optional, defaults to 10; recommended value 1000) Limits how high the [automatically-provided `Fee` field](transaction-common-fields.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
|
||||
@@ -98,7 +98,7 @@ The server automatically tries to fill in certain fields in `tx_json` (the [Tran
|
||||
* 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.
|
||||
* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you used the [ripple_path_find method][]. Only filled if `build_path` is provided.
|
||||
|
||||
## Response Format
|
||||
|
||||
|
||||
@@ -260,7 +260,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `tx_blob` | String | The complete transaction in hex string format |
|
||||
| `tx_json` | Object | The complete transaction in JSON format |
|
||||
|
||||
**Caution:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](reference-transaction-format.html#full-transaction-response-list) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
|
||||
**Caution:** Even if the WebSocket response has `"status":"success"`, indicating that the command was successfully received, that does _not_ indicate that the transaction executed successfully. Many situations can prevent a transaction from processing successfully, such as a lack of trust lines connecting the two accounts in a payment, or changes in the state of the ledger since the time the transaction was constructed. Even if nothing is wrong, it may take several seconds to close and validate the ledger version that includes the transaction. See the [full list of transaction responses](transaction-results.html) for details, and do not consider the transaction's results final until they appear in a validated ledger version.
|
||||
|
||||
**Caution:** If this command results in an error messages, the message can contain the secret key from the request. (This is not a problem if the request contained a signed tx_blob instead.) Make sure that these errors are not visible to others.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# submit_multisigned
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/release/src/ripple/rpc/handlers/SubmitMultiSigned.cpp "Source")
|
||||
|
||||
The `submit_multisigned` command applies a [multi-signed](multi-signing.html) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](#submit-only-mode).)
|
||||
The `submit_multisigned` command applies a [multi-signed](multi-signing.html) transaction and sends it to the network to be included in future ledgers. (You can also submit multi-signed transactions in binary form using the [`submit` command in submit-only mode](submit.html#submit-only-mode).)
|
||||
|
||||
This command requires the [MultiSign amendment](known-amendments.html#multisign) to be enabled. [New in: rippled 0.31.0][]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user