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

Ledger objects / Checks revisions per @jbheron @jhaaaa reviews

Browse Source
This commit is contained in:
mDuo13
2018-01-25 18:12:25 -08:00
parent 25d687a751
commit 5291eb46a0
16 changed files with 44 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/ledger-objects/accountroot.md
View File

@@ -63,7 +63,7 @@ AccountRoot objects can have the following flag values:
### AccountRoot ID Format
The ID of an AccountRoot object is the [SHA-512Half](#sha512half) of the following values put together:
The ID of an AccountRoot object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Account space key (`0x0061`)
* The AccountID of the account

6
content/ledger-objects/amendments.md
View File

@@ -31,10 +31,10 @@ Example `Amendments` object:
|-------------------|-----------|-------------------|-------------|
| `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. |
| `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 | Not used. |
| `LedgerEntryType` | String | UInt16 | The value `0x0066`, mapped to the string `Amendments`, indicates that this is object describes status of amendments to the XRP Ledger. |
| `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. |
Each member of the `Majorities` field, if it is present, is an object with a one field, `Majority`, whose contents are a nested object with the following fields:
Each member of the `Majorities` field, if it is present, is an object with one field, `Majority`, whose contents are a nested object with the following fields:
| Name | JSON Type | [Internal Type][] | Description |
|-------------------|-----------|-------------------|-------------|

10
content/ledger-objects/check.md
View File

@@ -3,7 +3,7 @@
_Requires the [Checks Amendment](reference-amendments.html#checks)._
A `Check` object describes a check, a potential pull payment, waiting to be cashed. (The potential payment has already been approved by its sender.) Example `Check` object:
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.) Example `Check` object:
```json
{
@@ -31,23 +31,23 @@ A `Check` object has the following fields:
| `LedgerEntryType` | String | UInt16 | The value `0x0043`, mapped to the string `Check`, indicates that this object is a Check object. |
| `Account` | String | Account | The sender of the Check. Cashing the Check debits this address's balance. |
| `Destination` | String | Account | The intended recipient of the Check. Only this address can cash the Check, using a [CheckCash transaction][]. |
| `Flags` | Number | UInt32 | No flags are defined for Checks, so this value is always `0`. |
| `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for Checks, so this value is always `0`. |
| `SendMax` | String or Object | Amount | The maximum amount of currency this Check can debit the sender. If the Check is successfully cashed, the destination is credited in the same currency for up to this amount. |
| `Sequence` | Number | UInt32 | The sequence number of the [CheckCreate transaction][] that created this check. |
| `OwnerNode` | String | UInt64 | A hint indicating which page of the sender's owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. |
| `DestinationNode` | String | UInt64 | _(Optional)_ A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. |
| `Expiration` | Number | UInt32 | (Optional) Indicates the time after which this Check is considered expired. See [Specifying Time](reference-rippled.html#specifying-time) for details. |
| `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash provided by the sender as a specific reason or identifier for this Check. |
| `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this Check, such as a hosted recipient at the sender's address. |
| `DestinationTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the destination for this Check, such as a hosted recipient at the destination address. |
| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. |
### Check ID Format
[[Source]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/Indexes.cpp#L193-L200 "Source")
The ID of a `Check` object is the [SHA-512Half](#sha512half) of the following values put together:
The ID of a `Check` object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Escrow space key (`0x0043`)
* The AccountID of the sender of the [CheckCreate transaction][] that created the `Check` object

6
content/ledger-objects/directorynode.md
View File

@@ -72,12 +72,12 @@ There are three different formulas for creating the ID of a DirectoryNode, depen
* The first page of an Offer Directory
* Later pages of either type
**The first page of an Owner Directory** has an ID that is the [SHA-512Half](#sha512half) of the following values put together:
**The first page of an Owner Directory** has an ID that is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Owner Directory space key (`0x004F`)
* The AccountID from the `Owner` field.
**The first page of an Offer Directory** has a special ID: the higher 192 bits define the order book, and the remaining 64 bits define the exchange rate of the offers in that directory. (The ID is big-endian, so the book is in the more significant bits, which come first, and the quality is in the less significant bits which come last.) This provides a way to iterate through an order book from best offers to worst. Specifically: the first 192 bits are the first 192 bits of the [SHA-512Half](#sha512half) of the following values put together:
**The first page of an Offer Directory** has a special ID: the higher 192 bits define the order book, and the remaining 64 bits define the exchange rate of the offers in that directory. (The ID is big-endian, so the book is in the more significant bits, which come first, and the quality is in the less significant bits which come last.) This provides a way to iterate through an order book from best offers to worst. Specifically: the first 192 bits are the first 192 bits of the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Book Directory space key (`0x0042`)
* The 160-bit currency code from the `TakerPaysCurrency`
@@ -87,7 +87,7 @@ There are three different formulas for creating the ID of a DirectoryNode, depen
The lower 64 bits of an Offer Directory's ID represent the TakerPays amount divided by TakerGets amount from the offer(s) in that directory as a 64-bit number in the XRP Ledger's internal amount format.
**If the DirectoryNode is not the first page in the Directory** (regardless of whether it is an Owner Directory or an Offer Directory), then it has an ID that is the [SHA-512Half](#sha512half) of the following values put together:
**If the DirectoryNode is not the first page in the Directory** (regardless of whether it is an Owner Directory or an Offer Directory), then it has an ID that is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The DirectoryNode space key (`0x0064`)
* The ID of the root DirectoryNode

3
content/ledger-objects/escrow.md
View File

@@ -43,6 +43,7 @@ An `Escrow` object has the following fields:
| `Condition` | String | VariableLength | _(Optional)_ A [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1), as hexadecimal. If present, the [EscrowFinish transaction][] must contain a fulfillment that satisfies this condition. |
| `CancelAfter` | Number | UInt32 | _(Optional)_ The held payment can be canceled if and only if this field is present _and_ the time it specifies has passed. Specifically, this is specified as [seconds since the Ripple Epoch](reference-rippled.html#specifying-time) and it "has passed" if it's earlier than the close time of the previous validated ledger. |
| `FinishAfter` | Number | UInt32 | _(Optional)_ The time, in [seconds since the Ripple Epoch](reference-rippled.html#specifying-time), after which this held payment can be finished. Any [EscrowFinish transaction][] before this time fails. (Specifically, this is compared with the close time of the previous validated ledger.) |
| `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for the Escrow type, so this value is always `0`. |
| `SourceTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the source for this held payment, such as a hosted recipient at the owner's address. |
| `DestinationTag` | Number | UInt32 | _(Optional)_ An arbitrary tag to further specify the destination for this held payment, such as a hosted recipient at the destination address. |
| `OwnerNode` | String | UInt64 | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
@@ -53,7 +54,7 @@ An `Escrow` object has the following fields:
### Escrow ID Format
The ID of an `Escrow` object is the [SHA-512Half](#sha512half) of the following values put together:
The ID of an `Escrow` object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Escrow space key (`0x0075`)
* The AccountID of the sender of the [EscrowCreate transaction][] that created the `Escrow` object

2
content/ledger-objects/ledgerhashes.md
View File

@@ -63,7 +63,7 @@ There are two formats for `LedgerHashes` object IDs, depending on whether the ob
The **"recent history"** `LedgerHashes` object has an ID that is the [SHA-512Half](#sha512half) of the `LedgerHashes` space key (`0x0073`). In other words, the "recent history" always has the ID `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`.
The **"previous history"** `LedgerHashes` objects have an ID that is the [SHA-512Half](#sha512half) of the following values put together:
The **"previous history"** `LedgerHashes` objects have an ID that is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
- The `LedgerHashes` space key (`0x0073`)
- The 32-bit [ledger index](#ledger-index) of a flag ledger in the object's `Hashes` array, divided by 65536.

2
content/ledger-objects/offer.md
View File

@@ -58,7 +58,7 @@ There are several options which can be either enabled or disabled when an [Offer
### Offer ID Format
The ID of an `Offer` object is the [SHA-512Half](#sha512half) of the following values put together:
The ID of an `Offer` object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The Offer space key (`0x006F`)
* The AccountID of the account placing the offer

2
content/ledger-objects/paychannel.md
View File

@@ -89,7 +89,7 @@ If any other address attempts to set an `Expiration` field, the transaction fail
### PayChannel ID Format
The ID of a `PayChannel` object is the [SHA-512Half](#sha512half) of the following values put together:
The ID of a `PayChannel` object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The PayChannel space key (`0x0078`)
* The AccountID of the source account

4
content/ledger-objects/ripplestate.md
View File

@@ -1,7 +1,7 @@
## RippleState
[[Source]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L70 "Source")
The `RippleState` object type connects two accounts in a single currency. Conceptually, a `RippleState` object represents two _trust lines_ between the accounts, one from each side. Each account can change the settings for its side of the `RippleState` object, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as trust line that does not exist, so `rippled` deletes `RippleState` objects when their properties are entirely default.
The `RippleState` object type connects two accounts in a single currency. Conceptually, a `RippleState` object represents two _trust lines_ between the accounts, one from each side. Each account can change the settings for its side of the `RippleState` object, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as a trust line that does not exist, so `rippled` deletes `RippleState` objects when their properties are entirely default.
Since no account is privileged in the XRP Ledger, a `RippleState` object sorts their account addresses numerically, to ensure a canonical form. Whichever address is numerically lower is deemed the "low account" and the other is the "high account".
@@ -94,7 +94,7 @@ Fortunately, `rippled` uses lazy evaluation to calculate the owner reserve. This
### RippleState ID Format
The ID of a RippleState object is the [SHA-512Half](#sha512half) of the following values put together:
The ID of a RippleState object is the [SHA-512Half](#sha512half) of the following values, concatenated in order:
* The RippleState space key (`0x0072`)
* The AccountID of the low account

11
content/ledger-objects/signerlist.md
View File

@@ -43,12 +43,13 @@ A SignerList object has the following fields:
| Name | JSON Type | Internal Type | Description |
|-----------------|-----------|---------------|-------------|
| `LedgerEntryType` | String | UInt16 | The value `0x0053`, mapped to the string `SignerList`, indicates that this object is a SignerList 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. |
| `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. |
| `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. |
| `Flags` | Number | UInt32 | A bit-map of boolean flags. No flags are defined for the SignerList type, so this value is always `0`. |
| `PreviousTxnID` | String | Hash256 | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger](#ledger-index) that contains the transaction that most recently modified this object. |
| `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. |
| `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.
@@ -69,7 +70,7 @@ A SignerList contributes to its owner's [reserve requirement](concept-reserves.h
### SignerList ID Format
The ID of a SignerList object is the SHA-512Half of the following values put together:
The ID of a SignerList object is the SHA-512Half of the following values, concatenated in order:
* The RippleState space key (`0x0053`)
* The AccountID of the owner of the SignerList

10
content/reference-transaction-format.md
View File

@@ -561,7 +561,7 @@ See also: [Partial Payments](concept-partial-payments.html)
These codes indicate an error in the local server processing the transaction; it is possible that another server with a different configuration or load level could process the transaction successfully. They have numerical values in the range -399 to -300. The exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `tel` codes are not applied to ledgers and have no effects. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** Transactions with `tel` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
| Code | Explanation |
|:----------------------|:-----------------------------------------------------|
@@ -583,7 +583,7 @@ These codes indicate an error in the local server processing the transaction; it
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 are not applied to ledgers with `tem` codes. 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](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.)
| Code | Explanation |
|:-----------------------------|:----------------------------------------------|
@@ -626,7 +626,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range -199 to -100. The exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `tef` codes are not applied to ledgers and have no effects. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** Transactions with `tef` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
| Code | Explanation |
|:-----------------------|:----------------------------------------------------|
@@ -653,7 +653,7 @@ These codes indicate that the transaction failed and was not included in a ledge
These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range -99 to -1. The exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `ter` codes are not applied to ledgers and have no effects. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** Transactions with `ter` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](#finality-of-results) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
| Code | Explanation |
|:-----------------|:----------------------------------------------------------|
@@ -671,7 +671,7 @@ These codes indicate that the transaction failed, but it could apply successfull
### tes Success
The code `tesSUCCESS` is the only code that indicates a transaction succeeded. This does not always mean it did what it was supposed to do. (For example, an [OfferCancel][] can "succeed" even if there is no offer for it to cancel.) The `tesSUCCESS` result uses the numerical value 0.
The code `tesSUCCESS` is the only code that indicates a transaction succeeded. This does not always mean it accomplished what you expected it to do. (For example, an [OfferCancel][] can "succeed" even if there is no offer for it to cancel.) The `tesSUCCESS` result uses the numerical value 0.
| Code | Explanation |
|:-----------|:----------------------------------------------------------------|

2
content/rippled-api-methods/account_objects.md
View File

@@ -64,7 +64,7 @@ The request includes the following parameters:
| `Field` | Type | Description |
|:---------------|:-------------------------------------------|:---------------|
| `account` | String | A unique identifier for the account, most commonly the account's address. |
| `type` | String | _(Optional)_ If included, filter results to include only this type of ledger object. The valid types are: `offer`, `signer_list`, `state` (trust line), `escrow`, and `payment_channel`. <!-- Author's note: Omitted types from this list that can't be owned by an account: https://github.com/ripple/rippled/blob/1dbc5a57e6b0e90a9da0d6e56f2f5a99e6ac1d8c/src/ripple/rpc/impl/RPCHelpers.cpp#L676-L686 --> <!-- Note 2: Can't filter by Checks yet. See https://github.com/ripple/rippled/issues/2350 for status. --> |
| `type` | String | _(Optional)_ If included, filter results to include only this type of ledger object. The valid types are: `check`, `escrow`, `offer`, `payment_channel`, `signer_list`, and `state` (trust line). <!-- Author's note: Omitted types from this list that can't be owned by an account, and ticket until Tickets are enabled: https://github.com/ripple/rippled/blob/1dbc5a57e6b0e90a9da0d6e56f2f5a99e6ac1d8c/src/ripple/rpc/impl/RPCHelpers.cpp#L676-L686 --> |
| `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 to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-ledgers)) |
| `limit` | Unsigned Integer | _(Optional)_ The maximum number of objects to include in the results. Must be within the inclusive range 10 to 400 on non-admin connections. Defaults to 200. |

2
content/transactions/checkcancel.md
View File

@@ -25,4 +25,4 @@ In addition to the [common fields](#common-fields), a CheckCancel transaction ha
### Error Cases
- If the object identified by the `CheckID` does not exist or is not a Check, the transaction fails with the result `tecNO_ENTRY`.
- If the Check is not expired and the sender if the CheckCancel transaction is not the source or destination of the Check, the transaction fails with the result `tecNO_PERMISSION`.
- If the Check is not expired and the sender of the CheckCancel transaction is not the source or destination of the Check, the transaction fails with the result `tecNO_PERMISSION`.

8
content/transactions/checkcash.md
View File

@@ -5,7 +5,7 @@ _Requires the [Checks Amendment](reference-amendments.html#checks)._
Attempts to redeem a Check object in the ledger to receive up to the amount authorized by the corresponding [CheckCreate transaction][]. Only the `Destination` address of a Check can cash it with a CheckCash transaction. Cashing a check this way is similar to executing a [Payment][] initiated by the destination.
Since the funds for a check are not guaranteed, redeeming a Check can fail because the sender does not have a high enough balance or because there is not enough liquidity to deliver the funds. If this happens, the
Since the funds for a check are not guaranteed, redeeming a Check can fail because the sender does not have a high enough balance or because there is not enough liquidity to deliver the funds. If this happens, the Check remains in the ledger and the destination can try to cash it again later, or for a different amount.
Example CheckCash:
@@ -24,8 +24,8 @@ In addition to the [common fields](#common-fields), a CheckCancel transaction ha
| Field | JSON Type | [Internal Type][] | Description |
|:------------|:----------|:------------------|:-------------------------------|
| `CheckID` | String | Hash256 | The ID of the [Check ledger object](reference-ledger-format.html#check) 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 the `SendMax` of the corresponding CheckCreate transaction. |
| `DeliverMin` | [Currency Amount][] | Amount | _(Optional)_ Redeem the Check for at least this amount and as much as possible. The currency must match the `SendMax` of the corresponding CheckCreate transaction. |
| `Amount` | [Currency Amount][] | Amount | _(Optional)_ Redeem the Check for exactly this amount, if possible. The currency must match 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 as much as possible. The currency must match 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.
@@ -35,5 +35,5 @@ The transaction ***must*** include either `Amount` or `DeliverMin`, but not both
- If the Check identified by the `CheckID` field does not exist, the transaction fails with the result `tecNO_ENTRY`.
- If the Check identified by the `CheckID` field has already expired, the transaction fails with the result `tecEXPIRED`.
- If the destination of the Check has the RequireDest flag enabled but the Check, as created, does not have a destination tag, the transaction fails with the result code `tecDST_TAG_NEEDED`.
- If the transaction specifies both `Amount` and `DeliverMin`, the transaction fails with the result `temMALFORMED`.
- If the transaction specifies both `Amount` and `DeliverMin`, or omits both, the transaction fails with the result `temMALFORMED`.
- If the `Amount` or `DeliverMin` does not match the currency (and issuer, if not XRP) of the Check, the transaction fails with the result `temBAD_CURRENCY`

4
content/transactions/checkcreate.md
View File

@@ -3,7 +3,7 @@
_Requires the [Checks Amendment](reference-amendments.html#checks)._
Create a Check object in the ledger, which is a deferred payment that can be cashed by its intended destination. The sender if this transaction is the sender of the Check.
Create a Check object in the ledger, which is a deferred payment that can be cashed by its intended destination. The sender of this transaction is the sender of the Check.
Example CheckCreate:
@@ -26,8 +26,8 @@ In addition to the [common fields](#common-fields), a CheckCancel transaction ha
|:-----------------|:--------------------|:------------------|:----------------|
| `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. |
| `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). |
| `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. |
### Error Cases

7
content/tutorial-checks.md
View File

@@ -1,5 +1,8 @@
# Checks Tutorial (draft)
***TODO: This whole page is just example requests and responses for now, not a finished page.***
<!--{# Just the requests and responses right now #}-->
<!--{# Accounts used in this example:
@@ -580,4 +583,6 @@ Loading: "/home/mduo13/.config/ripple/rippled.cfg"
}
```
## TODO: cash check (delivermin amount)
## cash check (delivermin)
***TODO: alternative version of cashing a check with delivermin instead of amount)