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.
The unique address of the transaction sender.
Hash value identifying another transaction. If provided, this transaction is only valid if the sending account's previously-sent transaction matches the provided hash.
The unique address of the account that can cash the Check.
Arbitrary tag that identifies the reason for the Check, or a hosted. recipient to pay.
Time after which the Check is no longer valid, in seconds since the Ripple. Epoch.
Integer amount of XRP, in drops, to be destroyed as a cost for distributing this transaction to the network. Some transaction types have different minimum requirements.
Set of bit-flags for this transaction.
Arbitrary 256-bit hash representing a specific reason or identifier for. this Check.
Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected.
Additional arbitrary information used to identify this transaction.
The network id of the transaction.
Maximum amount of source currency the Check is allowed to debit the sender, including transfer fees 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.
The sequence number of the account sending the transaction. A transaction is only valid if the Sequence number is exactly 1 greater than the previous transaction from the same account. The special case 0 means the transaction is using a Ticket instead.
Array of objects that represent a multi-signature which authorizes this transaction.
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.
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.
The sequence number of the ticket to use in place of a Sequence number. If this is provided, Sequence must be 0. Cannot be used with AccountTxnID.
The type of transaction. Valid types include:
TrustSet, and many others.
The signature that verifies this transaction as originating from the account it says it is from.
Generated using TypeDoc