[Source]

Added by the [Escrow amendment][].

Finish with OfferSequence

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "EscrowFinish",
    "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "OfferSequence": 7,
    "Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100",
    "Fulfillment": "A0028000"
}

Finish with EscrowID

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "EscrowFinish",
    "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "EscrowID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
    "Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100",
    "Fulfillment": "A0028000"
}

Fields

Any account may submit an EscrowFinish transaction.

• If the held payment has a FinishAfter time, you cannot execute it before this time. Specifically, if the corresponding [EscrowCreate transaction][] specified a FinishAfter time that is after the close time of the most recently-closed ledger, the EscrowFinish transaction fails.

• If the held payment has a Condition, you cannot execute it unless you provide a matching Fulfillment for the condition.

• You cannot execute a held payment after it has expired. Specifically, if the corresponding [EscrowCreate transaction][] specified a CancelAfter time that is before the close time of the most recently-closed ledger, the EscrowFinish transaction fails.

Note: The minimum transaction cost to submit an EscrowFinish transaction increases if it contains a fulfillment. If the transaction has no fulfillment, the transaction cost is the standard 10 drops. If the transaction contains a fulfillment, the transaction cost is 330 [drops of XAH][] plus another 10 drops for every 16 bytes in size of the preimage.

In non-production networks, it may be possible to delete the destination account of a pending escrow. In this case, an attempt to finish the escrow fails with the result tecNO_TARGET, but the escrow object remains unless it has expired normally. If another payment re-creates the destination account, the escrow can be finished successfully. The destination account of an escrow can only be deleted if the escrow was created before the fix1523 amendment became enabled. No such escrows exist in the production Xahau, so this edge case is not possible on the production Xahau. This edge case is also not possible in test networks that enable both fix1523 and Escrow amendments at the same time, which is the default when you start a new genesis ledger.

[Source]

Added by the DeletableAccounts amendment

Example

{
    "TransactionType": "AccountDelete",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
    "DestinationTag": 13,
    "Fee": "2000000",
    "Sequence": 2470665,
    "Flags": 2147483648
}

Special Transaction Cost

As an additional deterrent against ledger spam, the AccountDelete transaction requires a much higher than usual transaction cost: instead of the standard minimum of 0.00001 XAH, AccountDelete must destroy at least the owner reserve amount, currently 2 XRP. This discourages excessive creation of new accounts because the reserve requirement cannot be fully recouped by deleting the account.

The transaction cost always applies when a transaction is included in a validated ledger, even if the transaction fails to delete the account. (See Error Cases.) To greatly reduce the chances of paying the high transaction cost if the account cannot be deleted, submit the transaction with fail_hard enabled.

Error Cases

Besides errors that can occur for all transactions, AccountDelete transactions can result in the following transaction result codes:

[]

(Added by the [Checks amendment][].)

Example

{
  "TransactionType": "CheckCreate",
  "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
  "Destination": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
  "SendMax": "100000000",
  "Expiration": 570113521,
  "InvoiceID": "6F1DFD1D0FE8A32E40E1F2C05CF1C15545BAB56B617F9C6C2D63A6B704BEF59B",
  "DestinationTag": 1,
  "Fee": "12"
}

Error Cases

• If the Destination account is blocking incoming Checks, the transaction fails with the result code tecNO_PERMISSION.

• If the Destination is the sender of the transaction, the transaction fails with the result code temREDUNDANT.

• If the Destination account does not exist in the ledger, the transaction fails with the result code tecNO_DST.

• If the Destination account has the RequireDest flag enabled but the transaction does not include a DestinationTag field, the transaction fails with the result code tecDST_TAG_NEEDED.

• If SendMax specifies a token which is frozen, the transaction fails with the result tecFROZEN.

• If the Expiration of the transaction is in the past, the transaction fails with the result tecEXPIRED.

• If the sender does not have enough XAH to meet the owner reserve after adding the Check, the transaction fails with the result tecINSUFFICIENT_RESERVE.

• If either the sender or the destination of the Check cannot own more objects in the ledger, the transaction fails with the result tecDIR_FULL.

[Source]

(Added by the [Checks amendment][].)

Example

{
    "Account": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
    "TransactionType": "CheckCash",
    "Amount": "100000000",
    "CheckID": "838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334",
    "Fee": "12"
}

The transaction must include either Amount or DeliverMin, but not both.

Error Cases

• If the sender of the CheckCash transaction is not the Destination of the check, the transaction fails with the result code tecNO_PERMISSION.

• 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, or omits both, the transaction fails with the result temMALFORMED.

• If the Amount or DeliverMin does not match the currency (and issuer, if not XAH) of the Check, the transaction fails with the result temBAD_CURRENCY.

[]

(Added by the [BalanceRewards amendment][].)

Opt-in + Claim

{
    "TransactionType": "ClaimReward",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "Issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"
}

Opt-out

{
    "TransactionType": "ClaimReward",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "Flags": 1
}

Fields

ClaimReward Flags

Transactions of the ClaimReward type support additional values in the Flags field, as follows:

Special Transaction Cost

The ClaimReward transaction has a standard transaction cost, which is the minimum transaction cost required for all transactions.

Error Cases

Besides errors that can occur for all transactions, ClaimReward transactions can result in the following transaction result codes:

Tip: You can use this transaction to preauthorize certain counterparties before you enable Deposit Authorization. This may be useful to ensure a smooth transition from not requiring deposit authorization to requiring it.

[]

Added by the [DepositPreauth amendment][].

Example

{
  "TransactionType" : "DepositPreauth",
  "Account" : "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
  "Authorize" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
  "Fee" : "10",
  "Flags" : 2147483648,
  "Sequence" : 2
}

Fields

You must provide either Authorize or Unauthorize, but not both.

Error Cases

• An account cannot preauthorize (or unauthorize) its own address. Attempting to do so fails with the result temCANNOT_PREAUTH_SELF.

• Attempting to preauthorize an account which is already preauthorized fails with the result tecDUPLICATE.

• Attempting to unauthorize an account which is not preauthorized fails with the result tecNO_ENTRY.

• Attempting to preauthorize an address that is not funded in the ledger fails with the result tecNO_TARGET.

• Adding authorization adds a DepositPreauth object to the ledger, which counts toward the owner reserve requirement. If the sender of the transaction does not have enough XAH to pay for the increased reserve, the transaction fails with the result tecINSUFFICIENT_RESERVE. If the sender of the account is already at the maximum number of owned objects, the transaction fails with the result tecDIR_FULL.

[]

Added by the [Escrow amendment][].

Cancel Using OfferSequence

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "EscrowCancel",
    "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "OfferSequence": 7,
}

Cancel Using EscrowID

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "EscrowCancel",
    "Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "EscrowID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
}

Fields

Any account may submit an EscrowCancel transaction.

• If the corresponding [EscrowCreate transaction][] did not specify a CancelAfter time, the EscrowCancel transaction fails.

• Otherwise the EscrowCancel transaction fails if the CancelAfter time is after the close time of the most recently-closed ledger.

Transaction Types

The type of a transaction (TransactionType field) is the most fundamental information about a transaction. This indicates what type of operation the transaction is supposed to do.

All transactions have certain fields in common:

• Common Fields

Each transaction type has additional fields relevant to the type of action it causes.

[Source]

(Added by the [Checks amendment][].)

Example

{
    "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
    "TransactionType": "CheckCancel",
    "CheckID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
    "Fee": "12"
}

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 of the CheckCancel transaction is not the source or destination of the Check, the transaction fails with the result tecNO_PERMISSION.

[Source]

(Added by the [Import amendment][].)

Example

{
  "TransactionType": "Import",
  "Sequence": 0,
  "Fee": "0",
  "Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
  "Blob" : "DEADBEEF"
}

Fields

Error Cases

• If the account is Non Activated then the Sequence must be 0 and the Fee must also be 0

• If the account is Activated then the Sequence and the Fee are calculated the standard method.

• If the Issuer field is present then the Fee must be calculated using the standard method.

Notes

It is recommended that if you use a SignersList or RegularKey to sign your transactions that you key your accounts FIRST before attempting to B2M XAH_._

• If the inner (xpop) transaction is AccountSet the mainet existing flags will be transfered to the new network.

• If the inner (xpop) transaction is SetRegularKey with the RegularKey field omitted or empty, and a signers list does not exist for the account then the lsfDisableMaster flag will be set on the account.

• If the inner (xpop) transaction is SetRegularKey then the lsfPasswordSpent flag will be set on the account.

• TicketSequence is not available on Import

Importing for the Issuer

For issuers, there are additional steps to follow before their asset holders can import transactions.

Firstly, issuers need to install a hook. There are two options for this: B2MNFToken or B2MPayment.

B2MNFToken

A NFTokenBurn transaction on mainnet will result in a URITokenMint transaction on the network.

c hook: https://example.com

B2MPayment

A Payment transaction on mainnet to the Issuer will result in a Payment transaction from the Issuer on the network.

c hook: https://example.com

Please note that the process of importing for the issuer involves specific transaction types and requires careful configuration. Always ensure that the hooks are correctly set up and that the transactions are valid for the intended operations.

[]

(Added by the [Hooks amendment][].)

Example

{
    "TransactionType": "Invoke",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "Blob": "697066733A2F2F4445414442454546",
    "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe"
}

Special Transaction Cost

The Invoke transaction has a standard transaction cost, plus an additional cost based on the size of the Blob and HookParameters fields.

Error Cases

Besides errors that can occur for all transactions, Invoke transactions can result in the following transaction result codes:

[]

Cancel with OfferSequence

{
    "TransactionType": "OfferCancel",
    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "Fee": "12",
    "Flags": 0,
    "LastLedgerSequence": 7108629,
    "OfferSequence": 6,
    "Sequence": 7
}

Cancel with OfferID

{
    "TransactionType": "OfferCancel",
    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "Fee": "12",
    "Flags": 0,
    "LastLedgerSequence": 7108629,
    "OfferID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
    "Sequence": 7
}

Fields

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.

The OfferCancel method returns tesSUCCESS even if it did not find an offer with the matching sequence number.

[]

Added by the [Escrow amendment][].

Example

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "EscrowCreate",
    "Amount" : {
       "currency" : "USD",
       "value" : "1",
       "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
    },
    "Destination": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
    "CancelAfter": 533257958,
    "FinishAfter": 533171558,
    "Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100",
    "DestinationTag": 23480,
    "SourceTag": 11747
}

Fields

Either CancelAfter or FinishAfter must be specified. If both are included, the FinishAfter time must be before the CancelAfter time.

With the [fix1571 amendment][] enabled, you must supply FinishAfter, Condition, or both. [New in: rippled 1.0.0][]

[]

Added by the [XahauGenesis amendment][] and the [Hooks amendment][]

Example

{
    "TransactionType": "GenesisMint",
    "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
    "GenesisMints": [
        {
            "GenesisMint": {
                "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
                "Amount": "1000000000"
            },
        }
    ]
}

Fields

GenesisMint Object

The GenesisMint transaction includes an array of objects called GenesisMints. Each object represents a destination account and the amount of XAH to be minted and distributed to that account.

Special Transaction Cost

The GenesisMint transaction has a standard transaction cost, which is the minimum transaction cost required for all transactions.

Error Cases

Besides errors that can occur for all transactions, the GenesisMint transaction can result in the following transaction result codes:

Added by the [PayChan amendment][].

The source address of a channel can:

• Send Amount from the channel to the destination with or without a signed Claim.

• Set the channel to expire as soon as the channel's SettleDelay has passed.

• Clear a pending Expiration time.

• Close a channel immediately, with or without processing a claim first. The source address cannot close the channel immediately if the channel has Amount remaining.

The destination address of a channel can:

• Receive Amount from the channel using a signed Claim.

• Close the channel immediately after processing a Claim, refunding any unclaimed Amount to the channel's source.

Any address sending this transaction can:

• Cause a channel to be closed if its Expiration or CancelAfter time is older than the previous ledger's close time. Any validly-formed PaymentChannelClaim transaction has this effect regardless of the contents of the transaction.

Example

{
  "Channel": "C1AE6DDDEEC05CF2978C0BAD6FE302948E9533691DC749DCDD3B9E5992CA6198",
  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
  },
  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
  },
  "Signature": "30440220718D264EF05CAED7C781FF6DE298DCAC68D002562C9BF3A07C1E721B420C0DAB02203A5A4779EF4D2CCC7BC3EF886676D803A9981B928D3B8ACA483B80ECA3CD7B9B",
  "PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A"
}

If the payment channel was created before the fixPayChanRecipientOwnerDir amendment became enabled (on 2020-05-01), it is possible that the destination of the payment channel has been deleted and does not currently exist in the ledger. If the destination has been deleted, the source account cannot send XAH from the channel to the destination; instead, the transaction fails with tecNO_DST. (And, of course, the deleted account cannot send any transactions at all.) Other uses of this transaction type are unaffected when the destination account has been deleted, including adjusting the channel expiration, closing a channel with no Amount, or removing a channel that has passed its expiration time.

PaymentChannelClaim Flags

Transactions of the PaymentChannelClaim type support additional values in the Flags field, as follows:

[Source]

You can protect your account by assigning a regular key pair to it and using it instead of the master key pair to sign transactions whenever possible. If your regular key pair is compromised, but your master key pair is not, you can use a SetRegularKey transaction to regain control of your account.

Example {{currentpage.name}} JSON

{
    "Flags": 0,
    "TransactionType": "SetRegularKey",
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "Fee": "12",
    "RegularKey": "rAR8rR8sUkBoCZFawhkWzY4Y5YoyuznwD"
}

See Also

For more information about regular and master key pairs, see Cryptographic Keys.

For a tutorial on assigning a regular key pair to an account, see Working with a Regular Key Pair.

For even greater security, you can use multi-signing, but multi-signing requires additional XAH for the [transaction cost][] and reserve.

[Source]

Added by the [PayChan amendment][].

Example

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "PaymentChannelCreate",
    "Amount" : {
       "currency" : "USD",
       "value" : "1",
       "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
    },
    "Destination": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
    "SettleDelay": 86400,
    "PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A",
    "CancelAfter": 533171558,
    "DestinationTag": 23480,
    "SourceTag": 11747
}

If the Destination account is blocking incoming payment channels, the transaction fails with result code tecNO_PERMISSION. (Requires the [DisallowIncoming amendment][] :not_enabled:)

[Source]

Example

{
    "TransactionType": "AccountSet",
    "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "Fee": "12",
    "Sequence": 5,
    "Domain": "6578616D706C652E636F6D",
    "SetFlag": 5,
    "MessageKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB"
}

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 for more details.

Domain

The Domain field is represented as the hex string of the lowercase ASCII of the domain. For example, the domain example.com would be represented as "6578616D706C652E636F6D".

To remove the Domain field from an account, send an AccountSet with the Domain set to an empty string.

You can put any domain in your account's Domain field. To prove that an account and domain belong to the same person or business, you need a "two-way link":

• Accounts you own should have a domain you own in the Domain field.

• At that domain, host an xah-ledger.toml file listing accounts you own, and optionally other information about how you use Xahau.

AccountSet Flags

There are several options which can be either enabled or disabled for an account. Account options are represented by different types of flags depending on the situation:

• The AccountSet transaction type has several "AccountSet Flags" (prefixed asf) that can enable an option when passed as the SetFlag parameter, or disable an option when passed as the ClearFlag parameter. Newer options have only this style of flag. You can enable up to one asf flag per transaction, and disable up to one asf flag per transaction.

• The AccountSet transaction type has several transaction flags (prefixed tf) that can be used to enable or disable specific account options when passed in the Flags parameter. You can enable and disable a combination of settings in one transaction using multiple tf flags, but not all settings have tf flags.

• The AccountRoot ledger object type has several ledger-state-flags (prefixed lsf) which represent the state of particular account options within a particular ledger. These settings apply until a transaction changes them.

To enable or disable Account Flags, use the SetFlag and ClearFlag parameters of an AccountSet transaction. AccountSet flags have names that begin with asf.

All flags are disabled by default.

The available AccountSet flags are:

To enable the asfDisableMaster or asfNoFreeze flags, you must authorize the transaction by signing it with the master key pair. You cannot use a regular key pair or a multi-signature. You can disable asfDisableMaster (that is, re-enable the master key pair) using a regular key pair or multi-signature.

The following Transaction flags (tf flags), specific to the AccountSet transaction type, serve the same purpose. Due to limited space, some settings do not have associated tf flags, and new tf flags are not being added to the AccountSet transaction type. You can use a combination of tf and asf flags to enable multiple settings with a single transaction.

Caution: The numeric values of tf and asf flags in transactions do not match up with the values they set in the accounts "at rest" in the ledger. To read the flags of an account in the ledger, see AccountRoot flags.

Blocking Incoming Transactions

Incoming transactions with unclear purposes may be an inconvenience for financial institutions, who would have to recognize when a customer made a mistake, and then potentially refund accounts or adjust balances depending on the mistake. The asfRequireDest and asfDisallowXRP flags are intended to protect users from accidentally sending funds in a way that is unclear about the reason the funds were sent.

For example, a destination tag is typically used to identify which hosted balance should be credited when a financial institution receives a payment. If the destination tag is omitted, it may be unclear which account should be credited, creating a need for refunds, among other problems. By using the asfRequireDest tag, you can ensure that every incoming payment has a destination tag, which makes it harder for others to send you an ambiguous payment by accident.

You can protect against unwanted incoming payments for non-XAH currencies by not creating trust lines in those currencies. Since XAH does not require trust, the asfDisallowXRP flag is used to discourage users from sending XAH to an account. However, this flag is not enforced in Xahau protocol because it could potentially cause accounts to become unusable if they run out of XAH. Instead, client applications should disallow or discourage XAH payments to accounts with the asfDisallowXRP flag enabled.

If you want to block all incoming payments, you can enable Deposit Authorization. This prevents any transaction from sending money to you, even XAH, unless your account is below the reserve requirement.

If the [DisallowIncoming amendment][] :not_enabled: is enabled, you also have the option to block all incoming Checks, NFTokenOffers, Payment Channels, and trust lines. It is generally harmless to be on the receiving end of these objects, but they can block you from deleting your account and it can be confusing to have objects you didn't expect mixed in with the list of objects you created. To block incoming objects, use one or more of these account flags:

• asfDisallowIncomingCheck - for Check objects

• asfDisallowIncomingNFTOffer - for NFTokenOffer objects

• asfDisallowIncomingPayChan - for PayChannel objects

• asfDisallowIncomingTrustline - for RippleState (trust line) objects

When a transaction would create one of these ledger entries, if the destination account has the corresponding flag enabled, the transaction fails with the result code tecNO_PERMISSION. Unlike Deposit Authorization, these settings do not prevent you from receiving payments in general. Also, enabling this setting doesn't stop you from creating these types of objects yourself (unless the destination of your transaction is also using the setting, of course).

TransferRate

The TransferRate field specifies a fee to charge whenever counterparties transfer the currency you issue.

In the HTTP and WebSocket APIs, the transfer fee is represented as an integer, the amount that must be sent for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value 1200000000. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify 0 as a shortcut for 1000000000, meaning no fee.

See Transfer Fees for more information.

[Source]

Example

{
    "TransactionType": "OfferCreate",
    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "Fee": "12",
    "Flags": 0,
    "LastLedgerSequence": 7108682,
    "Sequence": 8,
    "TakerGets": "6000000",
    "TakerPays": {
      "currency": "GKO",
      "issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
      "value": "2"
    }
}

Fields

OfferCreate Flags

Transactions of the OfferCreate type support additional values in the Flags field, as follows:

Error Cases

[Source]

(Added by the [Remit amendment][].)

Example

{
    "TransactionType": "Remit",
    "Account": "rGvbdrdCxG2tk9ZU2673XmsjRdHCDQEpt7",
    "Amounts": [
        {
            "AmountEntry": {
                "Amount": "1000000"
            }
        }, {
            "AmountEntry": {
                "Amount": {
                    "currency": "USD",
                    "issuer": "rExKpRKXNz25UAjbckCRtQsJFcSfjL9Er3",
                    "value": "1"
                }
            }
        }
    ],
    "Destination": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
    "URITokenIDs": [
        "714F206C865D334721B2F3388BEAF33AA91BC1D78C71941D10A2A653C873EDD3"
    ],
    "MintURIToken": {
        "Digest": "6F11A4DF4EE794E2800BB361173D454BFBECB3D7506C4F4CB0EC5AE98BE43747",
        "Flags": 1,
        "URI": "697066733A2F2F"
    }
}

AmountEntry Fields

MintURIToken Fields

MintURIToken Flags

The MintURIToken STObject supports the values in the Flags field, as follows:

Special Transaction Cost

The Remit transaction has a standard transaction cost, which is the minimum fee required for any transaction in Xahau.

In addition to the minimum fee required the Remit transaction will also deduct the fees for the following:

Error Cases

Besides errors that can occur for all transactions, Remit transactions can result in the following transaction result codes:

[Source]

Added by the [PayChan amendment][].

Example

{
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "TransactionType": "PaymentChannelFund",
    "Channel": "C1AE6DDDEEC05CF2978C0BAD6FE302948E9533691DC749DCDD3B9E5992CA6198",
    "Amount" : {
         "currency" : "USD",
         "value" : "1",
         "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
      },
    "Expiration": 543171558
}

Error Cases

Besides errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following transaction result codes:

(Added by the [TicketBatch amendment][].)

Example

{
    "TransactionType": "TicketCreate",
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "Fee": "10",
    "Sequence": 381,
    "TicketCount": 10
}

If the transaction cannot create all of the requested Tickets (either due to the 250-Ticket limit or the owner reserve), it fails and creates no Tickets. To look up how many Tickets an account currently owns, use the [account_info method][] and check the account_data.TicketCount field.

Tip: This transaction increases the sending account's [sequence number][Sequence Number] by 1 plus the number of tickets created (TicketCount). This is the only transaction that increases an account's sequence number by more than 1.

Error Cases

Besides errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following transaction result codes:

Example

{
  "TransactionType" : "Payment",
  "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
  "Amount" : {
     "currency" : "USD",
     "value" : "1",
     "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
  },
  "Fee": "12",
  "Flags": 2147483648,
  "Sequence": 2,
}

Types of Payments

The Payment transaction type is a general-purpose tool that can represent several different types of abstract actions. You can identify the transaction type based on the transaction's fields, as described in the table below:

Special issuer Values for SendMax and Amount

Most of the time, the issuer field of a non-XAH [Currency Amount][] indicates the issuer of a token. However, when describing payments, there are special rules for the issuer field in the Amount and SendMax fields of a payment.

• There is only ever one balance between two addresses for the same currency code. This means that, sometimes, the issuer field of an amount actually refers to a counterparty, instead of the address that issued the token.

• When the issuer field of the destination Amount field matches the Destination address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all addresses to which the destination has trust lines with a positive limit, as well as tokens with the same currency code issued by the destination.

• When the issuer field of the SendMax field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new tokens on trust lines that other accounts have extended to the source account, and sending tokens the source account holds from other issuers.

Creating Accounts

The Payment transaction type can create new accounts in Xahau by sending enough XAH to an unfunded address. Other transactions to unfunded addresses always fail.

For more information, see Accounts.

Paths

If present, the Paths field must contain a path set - an array of path arrays. Each individual path represents one way value can flow from the sender to receiver through various intermediary accounts and order books. A single transaction can potentially use multiple paths, for example if the transaction exchanges currency using several different order books to achieve the best rate.

You must omit the Paths field for direct payments, including:

• An XAH-to-XAH transfer.

• A direct transfer on a trust line that connects the sender and receiver.

If the Paths field is provided, the server decides at transaction processing time which paths to use, from the provided set plus a default path (the most direct way possible to connect the specified accounts). This decision is deterministic and attempts to minimize costs, but it is not guaranteed to be perfect.

The Paths field must not be an empty array, nor an array whose members are all empty arrays.

For more information, see Paths.

Payment Flags

Transactions of the Payment type support additional values in the Flags field, as follows:

Partial Payments

A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for returning payments without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the Amount field of a successful transaction always describes the exact amount delivered.

A partial payment is any [Payment transaction][] with the tfPartialPayment flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its DeliverMin field (or any positive amount at all if DeliverMin is not specified) without sending more than the SendMax value.

The delivered_amount field of a payment's metadata indicates the amount of currency actually received by the destination account.

For more information, see the full article on Partial Payments.

Limit Quality

Xahau defines the "quality" of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the "quality" of that exchange is 0.5.

The tfLimitQuality flag allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination Amount divided by the SendMax amount (the numeric amounts only, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.

By itself, the tfLimitQuality flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall average quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the transaction result is tecPATH_DRY.

Consider the following example. If I am trying to send you 100 Chinese Yuan (Amount = 100 CNY) for 20 United States dollars (SendMax = 20 USD) or less, then the limit quality is 5. Imagine one trader is offering ¥95 for $15 (a ratio of about 6.3 CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of 2.5 CNY per USD). If I were to take both offers to send you 100 CNY, then it would cost me 17 USD, for an average quality of about 5.9.

Without the tfLimitQuality flag set, this transaction would succeed, because the $17 it costs me is within my specified SendMax. However, with the tfLimitQuality flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of 2.5, which is worse than the limit quality of 5.

The tfLimitQuality flag is most useful when combined with partial payments. When both tfPartialPayment and tfLimitQuality are set on a transaction, then the transaction delivers as much of the destination Amount as it can, without using any conversions that are worse than the limit quality.

In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both tfPartialPayment and tfLimitQuality enabled. If we keep my SendMax of 20 USD and a destination Amount of 100 CNY, then the limit quality is still 5. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about 6.3, but it rejects the ¥5/$2 offer because that offer's quality of 2.5 is worse than the quality limit of 5. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.

(Added by the [URIToken amendment][].)

The URITokenBurn transaction is used to burn a URIToken in Xahau. Burning a URIToken permanently removes it from circulation.

Example

{
    "TransactionType": "URITokenBurn",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA",
}

Special Transaction Cost

The URITokenBurn transaction does not have any special transaction cost requirements.

Error Cases

Besides errors that can occur for all transactions, URITokenBurn transactions can result in the following transaction result codes:

[Source]

(Added by the [Hooks amendment][].)

Example

{
    "TransactionType": "SetHook",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "Flags": 0,
    "Hooks": [
        {
            "Hook": {
                "HookHash": "610F33B8EBF7EC795F822A454FB852156AEFE50BE0CB8326338A81CD74801864",
                "CreateCode": "697066733A2F2F4445414442454546697066733A2F2F44454144424545467878",
                "HookGrants": [],
                "HookNamespace": "0000000000000000000000000000000000000000000000000000000000000000",
                "HookParameters": [],
                "HookOn": "0000000000000000000000000000000000000000000000000000000000000000",
                "HookApiVersion": 0,
                "Flags": 0
            }
        }
    ]
}

Special Transaction Cost

The SetHook transaction has a standard transaction cost, which is the minimum transaction cost required for all transactions.

Error Cases

Besides errors that can occur for all transactions, SetHook transactions can result in the following transaction result codes:

SetHook Operations

There are six possible operations: No Operation, Create, Update, Delete, Install and Namespace Delete

Each operation is specified by the inclusion or omission of certain HookSet Object fields. This might seem confusing at first but by working through a few examples the reader should find it intuitive; Essentially HookSet operations are a type of diff between a specific Hook's defaults, existing and newly specified fields.

Achieving each type of operation is explained in a subsection below.

No Operation

Occurs when:

• The HookSet Object is empty

Behaviour:

• No change of any kind is made.

Example:

JSON

{ 
    Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc",
    TransactionType: "SetHook",
    Fee: "2000000",
    Hooks:
    [        
        {                        
            Hook: {}
        }
    ]
}

Create Operation

Occurs when:

All of the following conditions are met:

• The Corresponding Hook does not exist orFLAG_OVERRIDE is specified.

• CreateCode field is specified and is not blank and contains the valid web assembly bytecode for a valid Hook.

• No instance of the same web assembly bytecode already exists on the XRPL. (If it does and all other requirements are met then interpret as an Install Operation — see below.)

Behaviour:

• A reference counted HookDefinition object is created on the XRPL containing the fields in the HookSet Object, with all specified fields (Namespace, Parameters, HookOn) becoming defaults (but not Grants.)

• A Hooks array is created on the executing account, if it doesn't already exist. (This is the structure that contains the Corresponding Hooks.)

• A Hook object is created at the Corresponding Hook position if one does not already exist.

• The Hook object points at the HookDefinition.

• The Hook object contains no fields except HookHash which points at the created HookDefinition.

• If hsfNSDELETE flag is specified then any HookState entires in the destination namespace are deleted if they currently exist.

Example:

JSON

{ 
    Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc",
    TransactionType: "SetHook",
    Fee: "2000000",
    Hooks:
    [        
        {                        
            Hook: {                
                CreateCode: fs.readFileSync('accept.wasm').toString('hex').toUpperCase(),
                HookOn: '0000000000000000',
                HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(),
                HookApiVersion: 0
            }
        }
    ]
}

Install Operation

Occurs when:

All of the following conditions are met:

• The Corresponding Hook does not exist orFLAG_OVERRIDE is specified.

• HookHash field is specified and is not blank and contains the hash of a Hook that already exists as a HookDefinition on the ledger or CreateCode field is specified and is not blank and contains the valid web assembly bytecode for a valid hook that already exists on the ledger as a HookDefinition.

Behaviour:

• The reference count of the HookDefinition object is incremented.

• A Hooks array is created on the executing account, if it doesn't already exist. (This is the structure that contains the Corresponding Hooks.)

• A Hook object is created at the Corresponding Hook position if one does not already exist.

• The Hook object points at the HookDefinition.

• The Hook object contains all the fields in the HookSet Object, except and unless:

• A field or key-pair within a field is identical to the Hook Defaults set on the HookDefinition, in which case it is omitted due to defaults.

• If hsfNSDELETE flag is specified then any HookState entires in the destination namespace are deleted if they currently exist.

Example:

JSON

{ 
    Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc",
    TransactionType: "SetHook",
    Fee: "2000000",
    Hooks:
    [        
        {                        
            Hook: {                
                HookHash: "A5663784D04ED1B4408C6B97193464D27C9C3334AAF8BBB4FA5EB8E557FC4A2C",
                HookOn: '0000000000000000',
                HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(),
            }
        }
    ]
}

Update Operation

Occurs when:

All of the following conditions are met:

• The Corresponding Hook exists.

• HookHash is absent.

• CreateCode is absent.

• One or more of HookNamespace, HookParameters or HookGrants is present.

General Behaviour:

• The Corresponding Hook is updated in such a way that the desired changes are reflected in the Corresponding Hook.

Specific Behaviour:

If HookNamespace is specified and differs from the Corresponding Hook's Namespace:

• the Corresponding Hook's HookNamespace is updated, and

• if the hsfNSDELETE flag is specified all HookState entires in the old namespace are deleted.

If HookParameters is specified, then for each entry:

• If HookParameterName exists but HookParameterValue is absent and the Corresponding Hook's Parameters (either specifically or via defaults) contains this HookParameterName then the parameter is marked as deleted on the Corresponding Hook.

• If HookParameterName exists and HookParameterValue exists then the Corresponding Hook's Parameters are modified to include the new or updated parameter.

If HookGrants is specified then:

• The Corresponding Hook's HookGrants array is replaced with the array.

Example:

JSON

{ 
    Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc",
    TransactionType: "SetHook",
    Fee: "2000000",
    Hooks:
    [        
        {                        
            Hook: {
                HookNamespace: addr.codec.sha256('new_accept').toString('hex').toUpperCase(),
            }
        }
    ]
}

Delete Operation

Occurs when:

All of the following conditions are met:

• The Corresponding Hook exists.

• hsfOVERRIDE is specified.

• optionally hsfNSDELETE is also specified.

• HookHash is absent.

• CreateCode is present but empty.

Behaviour:

• The reference count of the HookDefinition object is decremented.

• If the reference count is now zero the HookDefintion is removed from the ledger.

• The Hook object in the Corresponding Hook position is deleted, leaving an empty position.

• If hsfNSDELETE is specified the namespace and all HookState entries are also deleted.

Example:

JSON

{ 
    Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc",
    TransactionType: "SetHook",
    Fee: "2000000",
    Hooks:
    [        
        {                        
            Hook: {
                CreateCode: "",
                Flags: 1,
            }
        }
    ]
}

Namespace Reset

Occurs when:

All of the following conditions are met:

• flags is present and hsfNSDELETE is set. hsfOVERRIDE can optionally also be specified if the Hook at this position is to be deleted.

• HookNamespace is specified.

• CreateCode is absent.

• HookHash is absent.

• HookGrants, HookParameters, HookOn and HookApiVersion are absent.

Behaviour:

• If the Corresponding Hook exists, it remains, nothing happens to it.

• A subset of HookState objects and the HookState directory for the specified namespace are removed from the ledger, up to the defined limit (512). Further transactions are needed to continue the deletion process until all relevant records are removed. See tesPARTIAL.

Example:

JSON

{ 
    Account: "r4GDFMLGJUKMjNhhycgt2d5LXCdXzCYPoc",
    TransactionType: "SetHook",
    Fee: "2000000",
    Hooks:
    [        
        {                        
            Hook: {
              	HookNamespace: addr.codec.sha256('accept').toString('hex').toUpperCase(),
                Flags: 3,
            }
        }
    ]
}

Hook Fields

The following fields are used in the hook object:

Flags

The Flags field in the hook object specifies additional flags for the hook. The following flags are supported:

Hook Grants

The HookGrants field is an array of objects that specify the grants associated with the hook. Each grant object has the following fields:

Hook Parameters

The HookParameters field is an array of objects that specify the parameters of the hook. Each parameter object has the following fields:

Hook Executions

When Hooks execute they leave behind information about the status of that execution. This appears in the Originating Transaction metadata as an sfHookExecutions block. This block contains the following fields:

[Source]

(Added by the [URIToken amendment][].)

Example

{
    "TransactionType": "URITokenCancelSellOffer",
    "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
    "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA",
}

Fields

Error Cases

Besides errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following transaction result codes:

[Source]

Example

{
    "Flags": 0,
    "TransactionType": "SignerListSet",
    "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    "Fee": "12",
    "SignerQuorum": 3,
    "SignerEntries": [
        {
            "SignerEntry": {
                "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
                "SignerWeight": 2
            }
        },
        {
            "SignerEntry": {
                "Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
                "SignerWeight": 1
            }
        },
        {
            "SignerEntry": {
                "Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
                "SignerWeight": 1
            }
        }
    ]
}

A successful SignerListSet transaction replaces the account's SignerList object in the ledger, or adds one if it did not exist before. An account may not have more than one signer list. To delete a signer list, you must set SignerQuorum to 0 and omit the SignerEntries field. Otherwise, the transaction fails with the error temMALFORMED. A transaction to delete a signer list is considered successful even if there was no signer list to delete.

You cannot create a signer list such that the SignerQuorum could never be met. The SignerQuorum must be greater than 0 but less than or equal to the sum of the SignerWeight values in the list. Otherwise, the transaction fails with the error temMALFORMED.

You can create, update, or remove a signer list using the master key, regular key, or the current signer list, if those methods of signing transactions are available.

You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (the account has the lsfDisableMaster flag enabled) and the account does not have a Regular Key configured, then you cannot delete the signer list from the account. Instead, the transaction fails with the error tecNO_ALTERNATIVE_KEY.

Creating or replacing a signer list enables the lsfOneOwnerCount flag on the SignerList object. Lists that were created before the [MultiSignReserve amendment][] became enabled do not have this flag and have a higher owner reserve. You can decrease the owner reserve for these lists by replacing the list with the same list. For more information, see SignerList Flags.

[Source]

(Added by the [URIToken amendment][].)

Example

{
    "TransactionType": "URITokenBuy",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA",
    "Amount": {
      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
      "currency": "USD",
      "value": "100",
    },
}

Special Transaction Cost

The URITokenBuy transaction has a standard transaction cost, which is the minimum fee required for any transaction in Xahau.

Error Cases

Besides errors that can occur for all transactions, URITokenBuy transactions can result in the following transaction result codes:

[Source]

Example

{
    "TransactionType": "TrustSet",
    "Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
    "Fee": "12",
    "Flags": 262144,
    "LastLedgerSequence": 8007750,
    "LimitAmount": {
      "currency": "USD",
      "issuer": "rsP3mgGb2tcYUrxiLFiHJiQXhsziegtwBc",
      "value": "100"
    },
    "Sequence": 12
}

If the account specified in LimitAmount.issuer is blocking incoming trust lines, the transaction fails with the result code tecNO_PERMISSION. (Requires the [DisallowIncoming amendment][] :not_enabled:)

TrustSet Flags

Transactions of the TrustSet type support additional values in the Flags field, as follows:

If a transaction tries to enable No Ripple but cannot, it fails with the result code tecNO_PERMISSION. Before the [fix1578 amendment][] became enabled, such a transaction would result in tesSUCCESS (making any other changes it could) instead.

The Auth flag of a trust line does not determine whether the trust line counts towards its owner's XAH reserve requirement. However, an enabled Auth flag prevents the trust line from being in its default state. An authorized trust line can never be deleted. An issuer can pre-authorize a trust line with the tfSetfAuth flag only, even if the limit and balance of the trust line are 0.

[Source]

(Added by the [URIToken amendment][].)

Example

{
    "TransactionType": "URITokenCreateSellOffer",
    "Account": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
    "URITokenID": "C1AE6DDDEEC05CF2978C0BAD6FE27362498DGS691DC749DCDD3B95992978C0BA",
    "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
    "Amount": {
      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
      "currency": "USD",
      "value": "100",
    },
}

Fields

Error Cases

Besides errors that can occur for all transactions, URITokenCreateSellOffer transactions can result in the following transaction result codes:

[Source]

(Added by the [URIToken amendment][].)

Example

{
    "TransactionType": "URITokenMint",
    "Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
    "Flags": 1,
    "URI": "697066733A2F2F4445414442454546",
    "Digest": "697066733A2F2F4445414442454546697066733A2F2F44454144424545467878",
    "Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
    "Amount": {
      "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
      "currency": "USD",
      "value": "100",
    },
}

URITokenMint Flags

Transactions of the URITokenMint type support additional values in the Flags field, as follows:

Error Cases

Special Transaction Cost

The URIToken Mint transaction has a standard transaction cost, which is the minimum transaction cost required for all transactions.

Error Cases

Besides errors that can occur for all transactions, URIToken Mint transactions can result in the following transaction result codes: