mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 03:35:51 +00:00
Merge pull request #483 from mDuo13/txserialization
Transaction Serialization (binary format) docs
This commit is contained in:
Rome Reginelli
315
content/references/rippled-api/api-conventions/serialization.md
Normal file
315
content/references/rippled-api/api-conventions/serialization.md
Normal file
@@ -0,0 +1,315 @@
|
||||
# Serialization Format
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp#L696-L718 "Source")
|
||||
|
||||
This page describes the XRP Ledger's canonical binary format for transactions and other data. This binary format is necessary to create and verify digital signatures of those transactions' contents, and is also used in other places. The [rippled APIs](rippled-api.html) typically use JSON to communicate with client applications. However, JSON is unsuitable as a format for serializing transactions for being digitally signed, because JSON can represent the same data in many different but equivalent ways.
|
||||
|
||||
The process of serializing a transaction from JSON or any other representation into their canonical binary format can be summarized with these steps:
|
||||
|
||||
1. Make sure all required fields are provided, including any required but ["auto-fillable" fields](transaction-common-fields.html#auto-fillable-fields).
|
||||
|
||||
The [Transaction Formats Reference](transaction-formats.html) defines the required and optional fields for XRP Ledger transactions.
|
||||
|
||||
**Note:** The `SigningPubKey` must also be provided at this step. When signing, you can derive this key from the secret key that is provided for signing.
|
||||
|
||||
2. Convert each field's data into its ["internal" binary format](#internal-format).
|
||||
|
||||
3. Sort the fields in [canonical order](#canonical-field-order).
|
||||
|
||||
4. Prefix each field with a [Field ID](#field-ids).
|
||||
|
||||
5. Concatenate the fields (including prefixes) in their sorted order.
|
||||
|
||||
The result is a single binary blob that can be signed using well-known signature algorithms such as ECDSA (with the secp256k1 elliptic curve) and Ed25519. For purposes of the XRP Ledger, you must also [hash][Hash] the data with the appropriate prefix (`0x53545800` if single-signing, or `0x534D5400` if multi-signing). After signing, you must re-serialize the transaction with the `TxnSignature` field included. <!--{# TODO: link docs on how to compute a transaction signature. #}-->
|
||||
|
||||
**Note:** The XRP Ledger uses the same serialization format to represent other types of data, such as [ledger objects](ledger-object-types.html) and processed transactions. However, only certain fields are appropriate for including in a transaction that gets signed. (For example, the `TxnSignature` field, containing the signature itself, should not be present in the binary blob that you sign.) Thus, some fields are designated as "Signing" fields, which are included in objects when those objects are signed, and "non-signing" fields, which are not.
|
||||
|
||||
### Examples
|
||||
|
||||
Both signed and unsigned transactions can be represented in both JSON and binary formats. The following samples show the same signed transaction in its JSON and binary formats:
|
||||
|
||||
**JSON:**
|
||||
|
||||
```json
|
||||
{% include '_code-samples/tx-serialization/test-cases/tx1.json' %}
|
||||
```
|
||||
|
||||
**Binary (represented as hexadecimal):**
|
||||
|
||||
```text
|
||||
{% include '_code-samples/tx-serialization/test-cases/tx1-binary.txt' %}
|
||||
```
|
||||
|
||||
## Sample Code
|
||||
|
||||
The serialization processes described here are implemented in multiple places and programming languages:
|
||||
|
||||
- In C++ [in the `rippled` code base](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp).
|
||||
- In JavaScript in the [`ripple-binary-codec`](https://github.com/ripple/ripple-binary-codec/) package.
|
||||
- In Python 3 in [this repository's code samples section]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/tx-serialization/serialize.py).
|
||||
|
||||
These implementations are all provided with permissive open-source licenses, so you can import, use, or adapt the code for your needs in addition to using it alongside these documents for learning purposes.
|
||||
|
||||
|
||||
|
||||
## Internal Format
|
||||
|
||||
Each field has an "internal" binary format used in the `rippled` source code to represent that field when signing (and in most other cases). The internal formats for all fields are defined in the source code of [`SField.cpp`](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/SField.cpp). (This file also includes fields other than transaction fields.) The [Transaction Format Reference](transaction-formats.html) also lists the internal formats for all transaction fields.
|
||||
|
||||
For example, the `Flags` [common transaction field](transaction-common-fields.html) becomes a UInt32 (32-bit unsigned integer).
|
||||
|
||||
### Definitions File
|
||||
|
||||
The following JSON file defines the important constants you need for serializing XRP Ledger data to its binary format and deserializing it from binary:
|
||||
|
||||
**<https://github.com/ripple/ripple-binary-codec/blob/master/src/enums/definitions.json>**
|
||||
|
||||
The following table defines the top-level fields from the definitions file:
|
||||
|
||||
| Field | Contents |
|
||||
|:----------------------|:-----------------------------------------------------|
|
||||
| `TYPES` | Map of data types to their ["type code"](#type-codes) for constructing field IDs and sorting fields in canonical order. Codes below 1 should not appear in actual data; codes above 10000 represent special "high-level" object types such as "Transaction" that cannot be serialized inside other objects. See the [Type List](#type-list) for details of how to serialize each type. |
|
||||
| `LEDGER_ENTRY_TYPES` | Map of [ledger objects](ledger-object-types.html) to their data type. These appear in ledger state data, and in the "affected nodes" section of processed transactions' [metadata](transaction-metadata.html). |
|
||||
| `FIELDS` | A sorted array of tuples representing all fields that may appear in transactions, ledger objects, or other data. The first member of each tuple is the string name of the field and the second member is an object with that field's properties. (See the "Field properties" table below for definitions of those fields.) |
|
||||
| `TRANSACTION_RESULTS` | Map of [transaction result codes](transaction-results.html) to their numeric values. Result types not included in ledgers have negative values; `tesSUCCESS` has numeric value 0; [`tec`-class codes](tec-codes.html) represent failures that are included in ledgers. |
|
||||
| `TRANSACTION_TYPES` | Map of all [transaction types](transaction-types.html) to their numeric values. |
|
||||
|
||||
For purposes of serializing transactions for signing and submitting, the `FIELDS`, `TYPES`, and `TRANSACTION_TYPES` fields are necessary.
|
||||
|
||||
The field definition objects in the `FIELDS` array have the following fields:
|
||||
|
||||
| Field | Type | Contents |
|
||||
|:-----------------|:--------|:------------------------------------------------|
|
||||
| `nth` | Number | The [field code](#field-codes) of this field, for use in constructing its [Field ID](#field-ids) and ordering it with other fields of the same data type. |
|
||||
| `isVLEncoded` | Boolean | If `true`, this field is [length-prefixed](#length-prefixing). |
|
||||
| `isSerialized` | Boolean | If `true`, this field should be encoded into serialized binary data. When this field is `false`, the field is typically reconstructed on demand rather than stored. |
|
||||
| `isSigningField` | Boolean | If `true` this field should be serialized when preparing a transaction for signing. If `false`, this field should be omitted from the data to be signed. (It may not be part of transactions at all.) |
|
||||
| `type` | String | The internal data type of this field. This maps to a key in the `TYPES` map, which gives the [type code](#type-codes) for this field. |
|
||||
|
||||
### Field IDs
|
||||
|
||||
[[Source - Encoding]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L117-L148 "Source")
|
||||
[[Source - Decoding]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L484-L509 "Source")
|
||||
|
||||
When you combine a field's type code and field code, you get the field's unique identifier, which is prefixed before the field in the final serialized blob. The size of the Field ID is one to three bytes depending on the type code and field codes it combines. See the following table:
|
||||
|
||||
| | Type Code < 16 | Type Code >= 16 |
|
||||
|:-----------------|:------------------------------------------------------------------------------|:--|
|
||||
| **Field Code < 16** |  |  |
|
||||
| **Field Code >= 16** |  |  |
|
||||
|
||||
When decoding, you can tell how many bytes the field ID is by which bits **of the first byte** are zeroes. This corresponds to the cases in the above table:
|
||||
|
||||
| | High 4 bits are nonzero | High 4 bits are zero |
|
||||
|:-----------------|:------------------------------------------------------------------------------|:--|
|
||||
| **Low 4 bits are nonzero** | 1 byte: high 4 bits define type; low 4 bits define field. | 2 bytes: low 4 bits of the first byte define field; next byte defines type |
|
||||
| **Low 4 bits are zero** | 2 bytes: high 4 bits of the first byte define type; low 4 bits of first byte are 0; next byte defines field | 3 bytes: first byte is 0x00, second byte defines type; third byte defines field |
|
||||
|
||||
**Caution:** Even though the Field ID consists of the two elements that are used to sort fields, you should not sort by the serialized Field ID itself, because the byte structure of the Field ID changes the sort order.
|
||||
|
||||
### Length Prefixing
|
||||
|
||||
Some types of variable-length fields are prefixed with a length indicator. `Blob` fields (containing arbitrary binary data) are one such type. For a list of which types are length-prefixed, see the [Type List](#type-list) table.
|
||||
|
||||
**Note:** Some types of fields that vary in length are not length-prefixed. Those types have other ways of indicating the end of their contents.
|
||||
|
||||
The length prefix consists of one to three bytes indicating the length of the field immediately after the type prefix and before the contents.
|
||||
|
||||
- If the field contains 0 to 192 bytes of data, the first byte defines the length of the contents, then that many bytes of data follow immediately after the length byte.
|
||||
|
||||
- If the field contains 193 to 12480 bytes of data, the first two bytes indicate the length of the field with the following formula:
|
||||
|
||||
193 + ((byte1 - 193) * 256) + byte2
|
||||
|
||||
- If the field contains 12481 to 918744 bytes of data, the first three bytes indicate the length of the field with the following formula:
|
||||
|
||||
12481 + ((byte1 - 241) * 65536) + (byte2 * 256) + byte3
|
||||
|
||||
- A length-prefixed field cannot contain more than 918744 bytes of data.
|
||||
|
||||
When decoding, you can tell from the value of the first length byte whether there are 0, 1, or 2 additional length bytes:
|
||||
|
||||
- If the first length byte has a value of 192 or less, then that's the only length byte and it contains the exact length of the field contents in bytes.
|
||||
- If the first length byte has a value of 193 to 240, then there are two length bytes.
|
||||
- If the first length byte has a value of 241 to 254, then there are three length bytes.
|
||||
|
||||
|
||||
## Canonical Field Order
|
||||
|
||||
All fields in a transaction are sorted in a specific order based first on the field's type (specifically, a numeric "type code" assigned to each type), then on the field itself (a "field code"). (Think of it as sorting by family name, then given name, where the family name is the field's type and the given name is the field itself.)
|
||||
|
||||
### Type Codes
|
||||
|
||||
Each field type has an arbitrary type code, with lower codes sorting first. These codes are defined in [`SField.h`](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/SField.h#L57-L74).
|
||||
|
||||
For example, [UInt32 has type code 2](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/SField.h#L59), so all UInt32 fields come before all [Amount fields, which have type code 6](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/SField.h#L63).
|
||||
|
||||
The [definitions file](#definitions-file) lists the type codes for each type in the `TYPES` map.
|
||||
|
||||
### Field Codes
|
||||
|
||||
Each field has a field code, which is used to sort fields that have the same type as one another, with lower codes sorting first. These fields are defined in [`SField.cpp`](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L72-L266).
|
||||
|
||||
For example, the `Account` field of a [Payment transaction][] [has sort code 1](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L219), so it comes before the `Destination` field which [has sort code 3](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L221).
|
||||
|
||||
Field codes are reused for fields of different field types, but fields of the same type never have the same field code. When you combine the type code with the field code, you get the field's unique [Field ID](#field-ids).
|
||||
|
||||
|
||||
|
||||
## Type List
|
||||
|
||||
Transaction instructions may contain fields of any of the following types:
|
||||
|
||||
| Type Name | Type Code | Bit Length | [Length-prefixed]? | Description |
|
||||
|:--------------|:----------|:-----------|:-------------------|----------------|
|
||||
| [AccountID][] | 8 | 160 | Yes | The unique identifier for an [account](accounts.html). |
|
||||
| [Amount][] | 6 | 64 or 384 | No | An amount of XRP or issued currency. The length of the field is 64 bits for XRP or 384 bits (64+160+160) for issued currencies. |
|
||||
| [Blob][] | 7 | Variable | Yes | Arbitrary binary data. One important such field is `TxnSignature`, the signature that authorizes a transaction. |
|
||||
| [Hash128][] | 4 | 128 | No | A 128-bit arbitrary binary value. The only such field is `EmailHash`, which is intended to store the MD-5 hash of an account owner's email for purposes of fetching a [Gravatar](https://www.gravatar.com/). |
|
||||
| [Hash160][] | 17 | 160 | No | A 160-bit arbitrary binary value. This may define a currency code or issuer. |
|
||||
| [Hash256][] | 5 | 256 | No | A 256-bit arbitrary binary value. This usually represents the "SHA-512Half" hash of a transaction, ledger version, or ledger data object. |
|
||||
| [PathSet][] | 18 | Variable | No | A set of possible [payment paths](paths.html) for a [cross-currency payment](cross-currency-payments.html). |
|
||||
| [STArray][] | 15 | Variable | No | An array containing a variable number of members, which can be different types depending on the field. Two cases of this include [memos](transaction-common-fields.html#memos-field) and lists of signers used in [multi-signing](multi-signing.html). |
|
||||
| [STObject][] | 14 | Variable | No | An object containing one or more nested fields. |
|
||||
| [UInt8][] | 16 | 8 | No | An 8-bit unsigned integer. |
|
||||
| [UInt16][] | 1 | 16 | No | A 16-bit unsigned integer. The `TransactionType` is a special case of this type, with specific strings mapping to integer values. |
|
||||
| [UInt32][] | 2 | 32 | No | A 32-bit unsigned integer. The `Flags` and `Sequence` fields on all transactions are examples of this type. |
|
||||
|
||||
[Length-prefixed]: #length-prefixing
|
||||
|
||||
In addition to all of the above field types, the following types may appear in other contexts, such as [ledger objects](ledger-object-types.html) and [transaction metadata](transaction-metadata.html):
|
||||
|
||||
| Type Name | Type Code | [Length-prefixed]? | Description |
|
||||
|:------------|:----------|:-------------------|:------------------------------|
|
||||
| Transaction | 10001 | No | A "high-level" type containing an entire [transaction](transaction-formats.html). |
|
||||
| LedgerEntry | 10002 | No | A "high-level" type containing an entire [ledger object](ledger-object-types.html). |
|
||||
| Validation | 10003 | No | A "high-level" type used in peer-to-peer communications to represent a validation vote in the [consensus process](consensus.html). |
|
||||
| Metadata | 10004 | No | A "high-level" type containing [metadata for one transaction](transaction-metadata.html). |
|
||||
| [UInt64][] | 3 | No | A 64-bit unsigned integer. This type does not appear in transaction instructions, but several ledger objects use fields of this type. |
|
||||
| Vector256 | 19 | Yes | This type does not appear in transaction instructions, but the [Amendments ledger object](amendments-object.html)'s `Amendments` field uses this to represent which [amendments](amendments.html) are currently enabled. |
|
||||
|
||||
|
||||
### AccountID Fields
|
||||
[AccountID]: #accountid-fields
|
||||
|
||||
Fields of this type contain the 160-bit identifier for an XRP Ledger [account](accounts.html). In JSON, these fields are represented as base58 XRP Ledger "addresses", with additional checksum data so that typos are unlikely to result in valid addresses. (This encoding, sometimes called "Base58Check", prevents accidentally sending money to the wrong address.) The binary format for these fields does not contain any checksum data nor does it include the `0x00` "type prefix" used in [address base58 encoding](accounts.html#address-encoding). (However, since the binary format is used mostly for signed transactions, a typo or other error in transcribing a signed transaction would invalidate the signature, preventing it from sending money.)
|
||||
|
||||
AccountIDs that appear as stand-alone fields (such as `Account` and `Destination`) are [length-prefixed](#length-prefixing) despite being a fixed 160 bits in length. As a result, the length indicator for these fields is always the byte `0x14`. AccountIDs that appear as children of special fields ([Amount `issuer`][Amount] and [PathSet `account`][PathSet]) are _not_ length-prefixed.
|
||||
|
||||
|
||||
### Amount Fields
|
||||
[Amount]: #amount-fields
|
||||
|
||||
The "Amount" type is a special field type that represents an amount of currency, either XRP or an issued currency. This type consists of two sub-types:
|
||||
|
||||
- **XRP**
|
||||
|
||||
XRP is serialized as a 64-bit unsigned integer (big-endian order), except that the most significant bit is always 0 to indicate that it's XRP, and the second-most-significant bit is `1` to indicate that it is positive. Since the maximum amount of XRP (10<sup>17</sup> drops) only requires 57 bits, you can calculate XRP serialized format by taking standard 64-bit unsigned integer and performing a bitwise-OR with `0x4000000000000000`.
|
||||
|
||||
- **Issued Currencies**
|
||||
|
||||
Issued currencies consist of three segments in order:
|
||||
|
||||
1. 64 bits indicating the amount in the [internal currency format](currency-formats.html#issued-currency-math). The first bit is `1` to indicate that this is not XRP.
|
||||
2. 160 bits indicating the [currency code](currency-formats.html#currency-codes). The standard API converts 3-character codes such as "USD" into 160-bit codes using the [standard currency code format](currency-formats.html#standard-currency-codes), but custom 160-bit codes are also possible.
|
||||
3. 160 bits indicating the issuer's Account ID. (See also: [Account Address Encoding](accounts.html#address-encoding))
|
||||
|
||||
You can tell which of the two sub-types it is based on the first bit: `0` for XRP; `1` for issued currency.
|
||||
|
||||
The following diagram shows the serialization formats for both XRP amounts and issued currency amounts:
|
||||
|
||||
|
||||
|
||||
|
||||
### Array Fields
|
||||
[STArray]: #array-fields
|
||||
|
||||
Some transaction fields, such as `SignerEntries` (in [SignerListSet transactions][]) and [`Memos`](transaction-common-fields.html#memos-field), are arrays of objects (called the "STArray" type).
|
||||
|
||||
Arrays contain several [object fields](#object-fields) in their native binary format in a specific order. In JSON, each array member is a JSON "wrapper" object with a single field, which is the name of the member object field. The value of that field is the ("inner") object itself.
|
||||
|
||||
In the binary format, each member of the array has a Field ID prefix (based on the single key of the wrapper object) and contents (comprising the inner object, [serialized as an object](#object-fields)). To mark the end of an array, append an item with a "Field ID" of `0xf1` (the type code for array with field code of 1) and no contents.
|
||||
|
||||
The following example shows the serialization format for an array (the `SignerEntries` field):
|
||||
|
||||
|
||||
|
||||
|
||||
### Blob Fields
|
||||
[Blob]: #blob-fields
|
||||
|
||||
The Blob type is a [length-prefixed](#length-prefixing) field with arbitrary data. Two common fields that use this type are `SigningPubKey` and `TxnSignature`, which contain (respectively) the public key and signature that authorize a transaction to be executed.
|
||||
|
||||
Blob fields have no further structure to their contents, so they consist of exactly the amount of bytes indicated in the variable-length encoding, after the Field ID and length prefixes.
|
||||
|
||||
|
||||
### Hash Fields
|
||||
[Hash128]: #hash-fields
|
||||
[Hash160]: #hash-fields
|
||||
[Hash256]: #hash-fields
|
||||
|
||||
The XRP Ledger has several "hash" types: Hash128, Hash160, and Hash256. These fields contain arbitrary binary data of the given number of bits, which may or may not represent the result of a hash operation.
|
||||
|
||||
All such fields are serialized as the specific number of bits, with no length indicator, in big-endian byte order.
|
||||
|
||||
|
||||
### Object Fields
|
||||
[STObject]: #object-fields
|
||||
|
||||
Some fields, such as `SignerEntry` (in [SignerListSet transactions][]), and `Memo` (in `Memos` arrays) are objects (called the "STObject" type). The serialization of objects is very similar to that of arrays, with one difference: **object members must be placed in canonical order** within the object field, where array fields have an explicit order already.
|
||||
|
||||
The [canonical field order](#canonical-field-order) of object fields is the same as the canonical field order for all top-level fields, but the members of the object must be sorted within the object. After the last member, there is an "Object end" Field ID of `0xe1` with no contents.
|
||||
|
||||
The following example shows the serialization format for an object (a single `Memo` object in the `Memos` array).
|
||||
|
||||
|
||||
|
||||
|
||||
### PathSet Fields
|
||||
[PathSet]: #pathset-fields
|
||||
|
||||
The `Paths` field of a cross-currency [Payment transaction][] is a "PathSet", represented in JSON as an array of arrays. For more information on what paths are used for, see [Paths](paths.html).
|
||||
|
||||
A PathSet is serialized as **1 to 6** individual paths in sequence[[Source]](https://github.com/ripple/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L35-L36 "Source"). Each complete path is followed by a byte that indicates what comes next:
|
||||
|
||||
- `0xff` indicates another path follows
|
||||
- `0x00` indicates the end of the PathSet
|
||||
|
||||
Each path consists of **1 to 8** path steps in order[[Source]](https://github.com/ripple/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L38-L39 "Source"). Each step starts with a **type** byte, followed by one or more fields describing the path step. The type indicates which fields are present in that path step through bitwise flags. (For example, the value `0x30` indicates changing both currency and issuer.) If more than one field is present, the fields are always placed in a specific order.
|
||||
|
||||
The following table describes the possible fields and the bitwise flags to set in the type byte to indicate them:
|
||||
|
||||
| Type Flag | Field Present | Field Type | Bit Size | Order |
|
||||
|:----------|:--------------|:------------------|:---------|:------|
|
||||
| `0x01` | `account` | [AccountID][] | 160 bits | 1st |
|
||||
| `0x10` | `currency` | [Currency Code][] | 160 bits | 2nd |
|
||||
| `0x20` | `issuer` | [AccountID][] | 160 bits | 3rd |
|
||||
|
||||
[Currency Code]: currency-formats.html#standard-currency-codes
|
||||
|
||||
Some combinations are invalid; see [Path Specifications](paths.html#path-specifications) for details.
|
||||
|
||||
The AccountIDs in the `account` and `issuer` fields are presented _without_ a length prefix. When the `currency` is XRP, the currency code is represented as 160 bits of zeroes.
|
||||
|
||||
Each step is followed directly by the next step of the path. As described above, last step of a path is followed by either `0xff` (if another path follows) or `0x00` (if this ends the last path).
|
||||
|
||||
The following example shows the serialization format for a PathSet:
|
||||
|
||||
|
||||
|
||||
|
||||
### UInt Fields
|
||||
[UInt8]: #uint-fields
|
||||
[UInt16]: #uint-fields
|
||||
[UInt32]: #uint-fields
|
||||
[UInt64]: #uint-fields
|
||||
|
||||
The XRP Ledger has several unsigned integer types: UInt8, UInt16, UInt32, and UInt64. All of these are standard big-endian binary unsigned integers with the specified number of bits.
|
||||
|
||||
When representing these fields in JSON objects, most are represented as JSON numbers by default. One exception is UInt64, which is represented as a string because some JSON decoders may try to represent these integers as 64-bit "double precision" floating point numbers, which cannot represent all distinct UInt64 values with full precision.
|
||||
|
||||
Another special case is the `TransactionType` field. In JSON, this field is conventionally represented as a string with the name of the transaction type, but in binary, this field is a UInt16. The `TRANSACTION_TYPES` object in the [definitions file](#definitions-file) maps these strings to specific numeric values.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -14,8 +14,8 @@ Every transaction has the same set of common fields, plus additional fields base
|
||||
| [Memos][] | Array of Objects | Array | _(Optional)_ Additional arbitrary information used to identify this transaction. |
|
||||
| [Signers][] | Array | Array | _(Optional)_ Array of objects that represent a [multi-signature](multi-signing.html) which authorizes this transaction. |
|
||||
| SourceTag | Unsigned Integer | UInt32 | _(Optional)_ Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
|
||||
| SigningPubKey | String | PubKey | _(Automatically added when signing)_ Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
|
||||
| TxnSignature | String | VariableLength | _(Automatically added when signing)_ The signature that verifies this transaction as originating from the account it says it is from. |
|
||||
| SigningPubKey | String | Blob | _(Automatically added when signing)_ Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
|
||||
| TxnSignature | String | Blob | _(Automatically added when signing)_ The signature that verifies this transaction as originating from the account it says it is from. |
|
||||
|
||||
[auto-fillable]: #auto-fillable-fields
|
||||
[AccountTxnID]: #accounttxnid
|
||||
@@ -89,9 +89,9 @@ The `Memos` field includes arbitrary messaging data with the transaction. It is
|
||||
|
||||
| Field | Type | [Internal Type][] | Description |
|
||||
|:-----------|:-------|:------------------|:-----------------------------------|
|
||||
| MemoData | String | VariableLength | Arbitrary hex value, conventionally containing the content of the memo. |
|
||||
| MemoFormat | String | VariableLength | Hex value representing characters allowed in URLs. Conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml). |
|
||||
| MemoType | String | VariableLength | Hex value representing characters allowed in URLs. Conventionally, a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
|
||||
| MemoData | String | Blob | Arbitrary hex value, conventionally containing the content of the memo. |
|
||||
| MemoFormat | String | Blob | Hex value representing characters allowed in URLs. Conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml). |
|
||||
| MemoType | String | Blob | Hex value representing characters allowed in URLs. Conventionally, a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
|
||||
|
||||
The MemoType and MemoFormat fields should only consist of the following characters: `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%`
|
||||
|
||||
@@ -125,7 +125,7 @@ The `Signers` field contains a [multi-signature](multi-signing.html), which has
|
||||
|:--------------|:-------|:------------------|:--------------------------------|
|
||||
| Account | String | AccountID | The address associated with this signature, as it appears in the SignerList. |
|
||||
| TxnSignature | String | Blob | A signature for this transaction, verifiable using the `SigningPubKey`. |
|
||||
| SigningPubKey | String | PubKey | The public key used to create this signature. |
|
||||
| SigningPubKey | String | Blob | The public key used to create this signature. |
|
||||
|
||||
The `SigningPubKey` must be a key that is associated with the `Account` address. If the referenced `Account` is a funded account in the ledger, then the SigningPubKey can be that account's current Regular Key if one is set. It could also be that account's Master Key, unless the [lsfDisableMaster](accountroot.html#accountroot-flags) flag is enabled. If the referenced `Account` address is not a funded account in the ledger, then the `SigningPubKey` must be the master key associated with that address.
|
||||
|
||||
|
||||
@@ -22,17 +22,23 @@ An AccountSet transaction modifies the properties of an [account in the XRP Ledg
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-------------------------------|:-----------------|:------------------|:-----|
|
||||
| [ClearFlag](#accountset-flags) | Unsigned Integer | UInt32 | _(Optional)_ Unique identifier of a flag to disable for this account. |
|
||||
| [Domain](#domain) | String | VariableLength | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
|
||||
| EmailHash | String | Hash128 | _(Optional)_ Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
|
||||
| MessageKey | String | PubKey | _(Optional)_ Public key for sending encrypted messages to this account. |
|
||||
| [SetFlag](#accountset-flags) | Unsigned Integer | UInt32 | _(Optional)_ Integer flag to enable for this account. |
|
||||
| [TransferRate](accountset.html#transferrate) | Unsigned Integer | UInt32 | _(Optional)_ The fee to charge when users transfer this account's issued currencies, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
|
||||
| [TickSize](ticksize.html) | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Requires the [TickSize amendment](known-amendments.html#ticksize).)_ |
|
||||
| WalletLocator | String | Hash256 | _(Optional)_ Not used. |
|
||||
| WalletSize | Unsigned Integer | UInt32 | _(Optional)_ Not used. |
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-----------------|:-----------------|:------------------|:-------------------|
|
||||
| [ClearFlag][] | Number | UInt32 | _(Optional)_ Unique identifier of a flag to disable for this account. |
|
||||
| [Domain][] | String | Blob | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
|
||||
| EmailHash | String | Hash128 | _(Optional)_ Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
|
||||
| MessageKey | String | Blob | _(Optional)_ Public key for sending encrypted messages to this account. |
|
||||
| [SetFlag][] | Number | UInt32 | _(Optional)_ Integer flag to enable for this account. |
|
||||
| [TransferRate][] | Unsigned Integer | UInt32 | _(Optional)_ The fee to charge when users transfer this account's issued currencies, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
|
||||
| [TickSize][] | Unsigned Integer | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Requires the [TickSize amendment](known-amendments.html#ticksize).)_ |
|
||||
| WalletLocator | String | Hash256 | _(Optional)_ Not used. |
|
||||
| WalletSize | Number | UInt32 | _(Optional)_ Not used. |
|
||||
|
||||
[ClearFlag]: #accountset-flags
|
||||
[Domain]: #domain
|
||||
[SetFlag]: #accountset-flags
|
||||
[TickSize]: ticksize.html
|
||||
[TransferRate]: accountset.html#transferrate
|
||||
|
||||
If none of these options are provided, then the AccountSet transaction has no effect (beyond destroying the transaction cost). See [Cancel or Skip a Transaction](cancel-or-skip-a-transaction.html) for more details.
|
||||
|
||||
|
||||
@@ -22,11 +22,11 @@ Since the funds for a check are not guaranteed, redeeming a Check can fail becau
|
||||
{% include '_snippets/tx-fields-intro.md' %}
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:------------|:----------|:------------------|:-------------------------------|
|
||||
| `CheckID` | String | Hash256 | The ID of the [Check ledger object](check.html) to cash, as a 64-character hexadecimal string. |
|
||||
| `Amount` | [Currency Amount][] | Amount | _(Optional)_ Redeem the Check for exactly this amount, if possible. The currency must match that of the `SendMax` of the corresponding CheckCreate transaction. You must provide either this field or `DeliverMin`. |
|
||||
| `DeliverMin` | [Currency Amount][] | Amount | _(Optional)_ Redeem the Check for at least this amount and for as much as possible. The currency must match that of the `SendMax` of the corresponding CheckCreate transaction. You must provide either this field or `Amount`. |
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-------------|:--------------------|:------------------|:--------------------|
|
||||
| `CheckID` | String | Hash256 | The ID of the [Check ledger object](check.html) to cash, as a 64-character hexadecimal string. |
|
||||
| `Amount` | [Currency Amount][] | Amount | _(Optional)_ Redeem the Check for exactly this amount, if possible. The currency must match that of the `SendMax` of the corresponding CheckCreate transaction. You must provide either this field or `DeliverMin`. |
|
||||
| `DeliverMin` | [Currency Amount][] | Amount | _(Optional)_ Redeem the Check for at least this amount and for as much as possible. The currency must match that of the `SendMax` of the corresponding CheckCreate transaction. You must provide either this field or `Amount`. |
|
||||
|
||||
The transaction ***must*** include either `Amount` or `DeliverMin`, but not both.
|
||||
|
||||
|
||||
@@ -27,8 +27,8 @@ Create a Check object in the ledger, which is a deferred payment that can be cas
|
||||
|:-----------------|:--------------------|:------------------|:----------------|
|
||||
| `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][]. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the Check, or a hosted recipient to pay. |
|
||||
| `Expiration` | Number | UInt32 | _(Optional)_ Time after which the Check is no longer valid, in [seconds since the Ripple Epoch][]. |
|
||||
| `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this Check. |
|
||||
|
||||
## Error Cases
|
||||
|
||||
@@ -21,10 +21,10 @@ Return escrowed XRP to the sender.
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:----------------|:-----------------|:------------------|:--------------------------|
|
||||
| `Owner` | String | AccountID | Address of the source account that funded the escrow payment.
|
||||
| `OfferSequence` | Unsigned Integer | UInt32 | Transaction sequence of [EscrowCreate transaction][] that created the escrow to cancel.
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:----------------|:----------|:------------------|:---------------------------|
|
||||
| `Owner` | String | AccountID | Address of the source account that funded the escrow payment. |
|
||||
| `OfferSequence` | Number | UInt32 | Transaction sequence of [EscrowCreate transaction][] that created the escrow to cancel. |
|
||||
|
||||
Any account may submit an EscrowCancel transaction.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Sequester XRP until the escrow process either finishes or is canceled.
|
||||
| `Destination` | String | AccountID | Address to receive escrowed XRP. |
|
||||
| `CancelAfter` | Number | UInt32 | _(Optional)_ The time, in [seconds since the Ripple Epoch][], when this escrow expires. This value is immutable; the funds can only be returned the sender after this time. |
|
||||
| `FinishAfter` | Number | UInt32 | _(Optional)_ The time, in [seconds since the Ripple Epoch][], when the escrowed XRP can be released to the recipient. This value is immutable; the funds cannot move until this time is reached. |
|
||||
| `Condition` | String | VariableLength | _(Optional)_ Hex value representing a [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1). The funds can only be delivered to the recipient if this condition is fulfilled. |
|
||||
| `Condition` | String | Blob | _(Optional)_ Hex value representing a [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1). The funds can only be delivered to the recipient if this condition is fulfilled. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag to further specify the destination for this escrowed payment, such as a hosted recipient at the destination address. |
|
||||
|
||||
Either `CancelAfter` or `FinishAfter` must be specified. If both are included, the `FinishAfter` time must be before the `CancelAfter` time.
|
||||
|
||||
@@ -23,12 +23,12 @@ Deliver XRP from a held payment to the recipient.
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:----------------|:-----------------|:------------------|:--------------------------|
|
||||
| `Owner` | String | AccountID | Address of the source account that funded the held payment.
|
||||
| `OfferSequence` | Unsigned Integer | UInt32 | Transaction sequence of [EscrowCreate transaction][] that created the held payment to finish.
|
||||
| `Condition` | String | VariableLength | _(Optional)_ Hex value matching the previously-supplied [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1) of the held payment. |
|
||||
| `Fulfillment` | String | VariableLength | _(Optional)_ Hex value of the [PREIMAGE-SHA-256 crypto-condition fulfillment](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1.4) matching the held payment's `Condition`. |
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:----------------|:-----------------|:------------------|:--------------------|
|
||||
| `Owner` | String | AccountID | Address of the source account that funded the held payment. |
|
||||
| `OfferSequence` | Unsigned Integer | UInt32 | Transaction sequence of [EscrowCreate transaction][] that created the held payment to finish. |
|
||||
| `Condition` | String | Blob | _(Optional)_ Hex value matching the previously-supplied [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1) of the held payment. |
|
||||
| `Fulfillment` | String | Blob | _(Optional)_ Hex value of the [PREIMAGE-SHA-256 crypto-condition fulfillment](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1.4) matching the held payment's `Condition`. |
|
||||
|
||||
Any account may submit an EscrowFinish transaction.
|
||||
|
||||
|
||||
@@ -22,9 +22,9 @@ An OfferCancel transaction removes an Offer object from the XRP Ledger.
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:--------------|:-----------------|:------------------|:----------------------|
|
||||
| OfferSequence | Unsigned Integer | UInt32 | The sequence number of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:--------------|:----------|:------------------|:-----------------------------|
|
||||
| OfferSequence | Number | UInt32 | The sequence number of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
|
||||
|
||||
*Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate transaction][] with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
|
||||
|
||||
|
||||
@@ -29,12 +29,14 @@ For more information about how Offers work, see [Offers](offers.html).
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:--------------------------|:--------------------|:------------------|:-------|
|
||||
| [Expiration](offers.html#offer-expiration) | Unsigned Integer | UInt32 | _(Optional)_ Time after which the offer is no longer active, in [seconds since the Ripple Epoch][]. |
|
||||
| OfferSequence | Unsigned Integer | UInt32 | _(Optional)_ An offer to delete first, specified in the same way as [OfferCancel][]. |
|
||||
| TakerGets | [Currency Amount][] | Amount | The amount and type of currency being provided by the offer creator. |
|
||||
| TakerPays | [Currency Amount][] | Amount | The amount and type of currency being requested by the offer creator. |
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:---------------|:--------------------|:------------------|:------------------|
|
||||
| [Expiration][] | Number | UInt32 | _(Optional)_ Time after which the offer is no longer active, in [seconds since the Ripple Epoch][]. |
|
||||
| OfferSequence | Number | UInt32 | _(Optional)_ An offer to delete first, specified in the same way as [OfferCancel][]. |
|
||||
| TakerGets | [Currency Amount][] | Amount | The amount and type of currency being provided by the offer creator. |
|
||||
| TakerPays | [Currency Amount][] | Amount | The amount and type of currency being requested by the offer creator. |
|
||||
|
||||
[Expiration]: offers.html#offer-expiration
|
||||
|
||||
## OfferCreate Flags
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ Payments are also the only way to [create accounts](#creating-accounts).
|
||||
|:---------------|:---------------------|:------------------|:-----------------|
|
||||
| Amount | [Currency Amount][] | Amount | The amount of currency to deliver. For non-XRP amounts, the nested field names MUST be lower-case. If the [**tfPartialPayment** flag](#payment-flags) is set, deliver _up to_ this amount instead. |
|
||||
| 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. |
|
||||
| DestinationTag | Number | 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](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.html). 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. |
|
||||
|
||||
@@ -44,8 +44,8 @@ The **destination address** of a channel can:
|
||||
| `Channel` | String | Hash256 | The unique ID of the channel, as a 64-character hexadecimal string. |
|
||||
| `Balance` | String | Amount | _(Optional)_ Total amount of [XRP, in drops][Currency Amount], delivered by this channel after processing this claim. Required to deliver XRP. Must be more than the total amount delivered by the channel so far, but not greater than the `Amount` of the signed claim. Must be provided except when closing the channel. |
|
||||
| `Amount` | String | Amount | _(Optional)_ The amount of [XRP, in drops][Currency Amount], authorized by the `Signature`. This must match the amount in the signed message. This is the cumulative amount of XRP that can be dispensed by the channel, including XRP previously redeemed. |
|
||||
| `Signature` | String | VariableLength | _(Optional)_ The signature of this claim, as hexadecimal. The signed message contains the channel ID and the amount of the claim. Required unless the sender of the transaction is the source address of the channel. |
|
||||
| `PublicKey` | String | PubKey | _(Optional)_ The public key used for the signature, as hexadecimal. This must match the `PublicKey` stored in the ledger for the channel. Required unless the sender of the transaction is the source address of the channel and the `Signature` field is omitted. (The transaction includes the PubKey so that `rippled` can check the validity of the signature before trying to apply the transaction to the ledger.) |
|
||||
| `Signature` | String | Blob | _(Optional)_ The signature of this claim, as hexadecimal. The signed message contains the channel ID and the amount of the claim. Required unless the sender of the transaction is the source address of the channel. |
|
||||
| `PublicKey` | String | Blob | _(Optional)_ The public key used for the signature, as hexadecimal. This must match the `PublicKey` stored in the ledger for the channel. Required unless the sender of the transaction is the source address of the channel and the `Signature` field is omitted. (The transaction includes the PubKey so that `rippled` can check the validity of the signature before trying to apply the transaction to the ledger.) |
|
||||
|
||||
|
||||
## PaymentChannelClaim Flags
|
||||
|
||||
@@ -30,7 +30,7 @@ Create a unidirectional channel and fund it with XRP. The address sending this t
|
||||
| `Amount` | String | Amount | Amount of [XRP, in drops][Currency Amount], to deduct from the sender's balance and set aside in this channel. While the channel is open, the XRP can only go to the `Destination` address. When the channel closes, any unclaimed XRP is returned to the source address's balance. |
|
||||
| `Destination` | String | AccountID | Address to receive XRP claims against this channel. This is also known as the "destination address" for the channel. Cannot be the same as the sender (`Account`). |
|
||||
| `SettleDelay` | Number | UInt32 | Amount of time the source address must wait before closing the channel if it has unclaimed XRP. |
|
||||
| `PublicKey` | String | PubKey | The public key of the key pair the source will use to sign claims against this channel, in hexadecimal. This can be any secp256k1 or Ed25519 public key. <!-- STYLE_OVERRIDE: will --> |
|
||||
| `PublicKey` | String | Blob | The public key of the key pair the source will use to sign claims against this channel, in hexadecimal. This can be any secp256k1 or Ed25519 public key. <!-- STYLE_OVERRIDE: will --> |
|
||||
| `CancelAfter` | Number | UInt32 | _(Optional)_ The time, in [seconds since the Ripple Epoch][], when this channel expires. Any transaction that would modify the channel after this time closes the channel without otherwise affecting it. This value is immutable; the channel can be closed earlier than this time but cannot remain open after this time. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. |
|
||||
|
||||
|
||||
@@ -25,14 +25,14 @@ Create or modify a trust line linking two accounts.
|
||||
{% include '_snippets/tx-fields-intro.md' %}
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-------------------------|:-----------------|:------------------|:-----------|
|
||||
| `LimitAmount` | Object | Amount | Object defining the trust line to create or modify, in the format of a [Currency Amount][]. |
|
||||
| `LimitAmount`.`currency` | String | (Amount.currency) | The currency to this trust line applies to, as a three-letter [ISO 4217 Currency Code](http://www.xe.com/iso4217.php) or a 160-bit hex value according to [currency format](currency-formats.html). "XRP" is invalid. |
|
||||
| `LimitAmount`.`value` | String | (Amount.value) | Quoted decimal representation of the limit to set on this trust line. |
|
||||
| `LimitAmount`.`issuer` | String | (Amount.issuer) | The address of the account to extend trust to. |
|
||||
| `QualityIn` | Unsigned Integer | UInt32 | _(Optional)_ Value incoming balances on this trust line at the ratio of this number per 1,000,000,000 units. A value of `0` is shorthand for treating balances at face value. |
|
||||
| `QualityOut` | Unsigned Integer | UInt32 | _(Optional)_ Value outgoing balances on this trust line at the ratio of this number per 1,000,000,000 units. A value of `0` is shorthand for treating balances at face value. |
|
||||
| Field | JSON Type | [Internal Type][] | Description |
|
||||
|:-------------------------|:----------|:------------------|:------------------|
|
||||
| `LimitAmount` | Object | Amount | Object defining the trust line to create or modify, in the format of a [Currency Amount][]. |
|
||||
| `LimitAmount`.`currency` | String | (Amount.currency) | The currency to this trust line applies to, as a three-letter [ISO 4217 Currency Code](http://www.xe.com/iso4217.php) or a 160-bit hex value according to [currency format](currency-formats.html). "XRP" is invalid. |
|
||||
| `LimitAmount`.`value` | String | (Amount.value) | Quoted decimal representation of the limit to set on this trust line. |
|
||||
| `LimitAmount`.`issuer` | String | (Amount.issuer) | The address of the account to extend trust to. |
|
||||
| `QualityIn` | Number | UInt32 | _(Optional)_ Value incoming balances on this trust line at the ratio of this number per 1,000,000,000 units. A value of `0` is shorthand for treating balances at face value. |
|
||||
| `QualityOut` | Number | UInt32 | _(Optional)_ Value outgoing balances on this trust line at the ratio of this number per 1,000,000,000 units. A value of `0` is shorthand for treating balances at face value. |
|
||||
|
||||
|
||||
## TrustSet Flags
|
||||
|
||||
Reference in New Issue
Block a user