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

add batch transactions docs

Browse Source
This commit is contained in:
Oliver Eggert
2025-06-17 14:07:12 -07:00
parent df89b5bd6e
commit c1acd9e417
4 changed files with 556 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

160
docs/concepts/transactions/batch-transactions.md Normal file
View File

@@ -0,0 +1,160 @@
---
seo:
description: Batch allows up to 8 transactions to be submitted as a single unit.
labels:
- Batch
- Transactions
status: not_enabled
---
# Batch Transactions
`Batch` lets you package multiple transactions together and execute them as a single unit. It eliminates the risk of partial completion and unexpected outcomes, giving you a more reliable and predictable experience for complex operations. Up to eight transactions can be submitted in a single batch.
Some potential uses for `Batch` include the following.
- All or nothing: You can mint an NFT and create an offer for it in one transaction. If the offer creation fails, the NFT mint is reverted as well.
- Trying out a few offers: Submit multiple offers with different amounts of slippage, but only one will succeed.
- Platform fees: Package platform fees within the transaction itself, simplifying the process.
- Swaps (multi-account): Trustless token/NFT swaps between multiple accounts.
- Withdrawing accounts (multi-account): Attempt a withdrawal from your checking account, and if that fails, withdraw from your savings account instead.
`Batch` transactions are comprised of the _outer transaction_, the wrapper `Batch` transaction itself, and the _inner transactions_, each of which is executed atomically. The precise way that the inner transactions are processed is determined by the batch _mode_.
## Batch Mode
There are four possible batch modes: `ALLORNOTHING`, `ONLYONE`, `UNTILFAILURE`, and `INDEPENDENT`.
### All or Nothing
In `ALLORNOTHING` mode, all inner transactions must succeed for any one of them to succeed.
### Only One
`ONLYONE` mode means that the first transaction to succeed is the only one to succeed. All other transactions either failed or were never tried.
### Until Failure
`UNTILFAILURE` applies all transactions until the first failure. All transactions after the first failure are not applied.
### Independent
All transactions are applied, even if one or more of the inner transactions fail.
## Raw Transactions
The `RawTransactions` object is a container for the list of transactions to be applied. You can include up to eight transactions in a sincle batch. The transactions can come from one account or multiple accounts.
Each inner transaction:
- Must set the `tfInnerBatchTxn` flag.
- Must not have a fee. It must use a fee value of _0_.
- Must not be signed (the global transaction is already signed by all relevant parties). They must instead have an empty string ("") in the `SigningPubKey` and `TxnSignature` fields.
A transaction is considered a failure if it receives any result that is not `tesSUCCESS`.
### Transaction Common Flag
`Batch` adds a global transaction flag.
| Flag Name | Value |
|-------------------|------------|
| `tfInnerBatchTxn` | 0x40000000 |
This flag is only used if a transaction is an inner transaction in a Batch transaction. This signifies that the transaction isn't signed. Any normal transaction that includes this flag is rejected.
### BatchSigners
This field is included if the account is signing with multi-sign (as opposed to a single signature). It operates equivalently to the `Signers` field used in standard transaction multi-sign. This field holds the signatures for the `Flags` field and the hashes of the transactions in `RawTransactions`. It is only needed if multiple accounts' transactions are included in the `Batch` transaction; otherwise, the normal transaction signature provides the same security guarantees.
This field must be provided if more than one account has inner transactions included in the Batch. In that case, this field must contain signatures from all accounts whose inner transactions are included, excluding the account signing the outer transaction (if applicable).
Each object in this array contains the following fields:
| Field Name | Required? | JSON Type | Internal Type |
|---------------|-----------|-----------|---------------|
| Account | yes | string | STAccount |
| SigningPubKey | no | string | STBlob |
| TxnSignature | no | string | STBlob |
| Signers | no | array | STArray |
Either the `SigningPubKey` and `TxnSignature` fields must be included, or the `Signers` field.
#### Account
This is an account that has at least one inner transaction.
#### SigningPubKey and TxnSignature
These fields are included if the account is signing with a single signature (as opposed to multi-sign). They sign the `Flags` field and the hashes of the transactions in `RawTransactions`.
#### Signers
This field is included if the account is signing with multi-sign (as opposed to a single signature). It operates equivalently to the `Signers` field used in standard transaction multi-sign. This field holds the signatures for the `Flags` field and the hashes of the transactions in `RawTransactions`.
## Transaction Fee
The fee for the outer transaction is twice the base fee (a total of 20 drops when there is no fee escalation), plus the sum of the transaction fees of all the inner transactions (which incorporates factors like higher fees for `multisign` or `AMMCreate`), plus an additional base fee amount for each additional signature in the transaction (for example, from `BatchSigners`). Expressed as an equation:
2 * (Base Fee) + SUM(Inner Transaction Fees) + An additional Base Fee for each additional signature
The fees for the individual inner transactions are paid in the outer transaction rather than the inner transactions themselves, to ensure that fee escalation is calculated on the total cost of the batch transaction and not just the overhead.
## Metadata
Inner transactions are committed separately to the ledger and therefore have separate metadata. This ensures better backward compatibility for legacy systems, so that they can support `Batch` transactions without needing changes to their systems.
For example, a ledger that only has one `Batch` transaction containing 2 inner transactions would look like this:
```
[
OuterTransaction,
InnerTransaction1,
InnerTransaction2
]
```
### Outer Transaction
Each outer transaction contains the metadata for its sequence and fee processing, not for the inner transaction processing. Any error code is only based on the outer transaction processing (for example, sequence and fee), and it returns a tesSUCCESS error even if inner transaction processing fails.
### Inner Transaction
Each inner transaction contains the metadata for its own processing. Only the inner transactions that are actually committed to the ledger are included. This makes it easier for legacy systems to process `Batch` transactions as if they were normal.
There is also a pointer back to the parent outer transaction (`ParentBatchID`).
## Transaction Common Fields
This standard doesn't add any new fields to the transaction common fields, but it does add another global transaction flag:
| Flag Name | Value |
|-----------------|------------|
| tfInnerBatchTxn | 0x40000000 |
This flag should be used only if a transaction is an inner transaction in a `Batch` transaction. This signifies that the transaction shouldn't be signed. Any normal transaction that includes this flag should be rejected.
## Security
Batch transactions come with additional security considerations.
### Trust Assumptions
Regardless of how many accounts' transactions are included in a `Batch` transaction, all accounts need to sign the collection of transactions.
#### Single Account
In the single account case, the single account must approve all of the transactions it is submitting. No other accounts are involved.
#### Multi Account
The multi-account case is a bit more complicated and is best illustrated with an example.
Alice and Bob are conducting a trustless swap via a multi-account `Batch`, with Alice providing 1000 XRP and Bob providing 1000 USD. Bob submits the `Batch` transaction, so Alice must provide her part of the swap to him.
If Alice provides a fully autofilled and signed transaction to Bob, Bob can submit Alice's transaction on the ledger without submitting his and receive the 1000 XRP without losing his 1000 USD. Therefore, the inner transactions must be unsigned.
If Alice just signs her part of the Batch transaction, Bob can modify his transaction to only provide 1 USD instead, thereby getting his 1000 XRP at a much cheaper rate. Therefore, the entire Batch transaction (and all its inner transactions) must be signed by all parties.
### Inner Transaction Safety
An inner batch transaction is a special case. It doesn't include a signature or a fee (since those are both included in the outer transaction). Therefore, they must be handled carefully to ensure that someone can't somehow directly submit an inner `Batch` transaction without it being included in an outer transaction.
Inner transactions cannot be broadcast (and won't be accepted if they happen to be broadcast, for example, from a malicious node). They must be generated from the `Batch` outer transaction instead. Inner transactions cannot be directly submitted via the submit RPC.

3
docs/references/protocol/transactions/common-fields.md
View File

@@ -73,11 +73,12 @@ Bits that are not defined as flags MUST be 0. (The [fix1543 amendment][] enforce
### Global Flags
The only flag that applies globally to all transactions is as follows:
The only flags that apply globally to all transactions are as follows:
| Flag Name | Hex Value | Decimal Value | Description |
|:----------------------|:-----------|:--------------|:--------------------------|
| `tfFullyCanonicalSig` | `0x80000000` | 2147483648 | **DEPRECATED** No effect. (If the [RequireFullyCanonicalSig amendment][] is not enabled, this flag enforces a [fully-canonical signature](../../../concepts/transactions/finality-of-results/transaction-malleability.md#alternate-secp256k1-signatures).) |
| `tfInnerBatchTxn` | `0x40000000` | 1073741824 | This flag is only used if a transaction is an inner transaction in a Batch transaction. This signifies that the transaction isn't signed. Any normal transaction that includes this flag is rejected. |
When using the [sign method][] (or [submit method][] in "sign-and-submit" mode), `rippled` adds a `Flags` field with `tfFullyCanonicalSig` enabled unless the `Flags` field is already present. The `tfFullyCanonicalSig` flag is not automatically enabled if `Flags` is explicitly specified. The flag is not automatically enabled when using the [sign_for method][] to add a signature to a multi-signed transaction.

392
docs/references/protocol/transactions/types/batch.md Normal file
View File

@@ -0,0 +1,392 @@
---
seo:
description: Create and submit a batch of up to 8 transactions.
labels:
- Batch
- Transactions
status: not_enabled
---
# Batch
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/Batch.cpp "Source")
The `Batch` transaction submits up to eight transactions in a single batch. Each transaction is executed atomically in one of four modes: All or Nothing, Only One, Until Failure, and Independent.
## Example Batch JSON
In this example, the user is creating an offer while trading on a DEX UI, and the second transaction is a platform fee. The inner transactions are not signed, and the `BatchSigners` field is not needed on the outer transaction, since there is only one account involved.
```json
{
"TransactionType": "Batch",
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Flags": "0x00010000",
"RawTransactions": [
{
"RawTransaction": {
"TransactionType": "OfferCreate",
"Flags": 1073741824,
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"TakerGets": "6000000",
"TakerPays": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"Sequence": 4,
"Fee": "0",
"SigningPubKey": ""
}
},
{
"RawTransaction": {
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Destination": "rDEXfrontEnd23E44wKL3S6dj9FaXv",
"Amount": "1000",
"Sequence": 5,
"Fee": "0",
"SigningPubKey": ""
}
}
],
"Sequence": 3,
"Fee": "40",
"SigningPubKey": "022D40673B44C82DEE1DDB8B9BB53DCCE4F97B27404DB850F068DD91D685E337EA",
"TxnSignature": "3045022100EC5D367FAE2B461679AD446FBBE7BA260506579AF4ED5EFC3EC25F4DD1885B38022018C2327DB281743B12553C7A6DC0E45B07D3FC6983F261D7BCB474D89A0EC5B8"
}
```
### Sample Ledger Confirmation
This example shows what the ledger looks like after the transaction is confirmed.
Note that the inner transactions are committed as normal transactions.
```json
[
{
"TransactionType": "Batch",
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Flags": "0x00010000",
"RawTransactions": [
{
"RawTransaction": {
"TransactionType": "OfferCreate",
"Flags": 1073741824,
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"TakerGets": "6000000",
"TakerPays": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"Sequence": 4,
"Fee": "0",
"SigningPubKey": ""
}
},
{
"RawTransaction": {
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Destination": "rDEXfrontEnd23E44wKL3S6dj9FaXv",
"Amount": "1000",
"Sequence": 5,
"Fee": "0",
"SigningPubKey": ""
}
}
],
"Sequence": 3,
"Fee": "40",
"SigningPubKey": "022D40673B44C82DEE1DDB8B9BB53DCCE4F97B27404DB850F068DD91D685E337EA",
"TxnSignature": "3045022100EC5D367FAE2B461679AD446FBBE7BA260506579AF4ED5EFC3EC25F4DD1885B38022018C2327DB281743B12553C7A6DC0E45B07D3FC6983F261D7BCB474D89A0EC5B8"
},
{
"TransactionType": "OfferCreate",
"Flags": 1073741824,
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"TakerGets": "6000000",
"TakerPays": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"Sequence": 4,
"Fee": "0",
"SigningPubKey": ""
},
{
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Destination": "rDEXfrontEnd23E44wKL3S6dj9FaXv",
"Amount": "1000",
"Sequence": 5,
"Fee": "0",
"SigningPubKey": ""
}
]
```
### Sample Ledger
This example shows what the ledger will look like after the transaction is confirmed. Note that the inner transactions are committed as normal transactions, and the RawTransactions field is not included in the validated version of the outer transaction.
```json
[
{
"TransactionType": "Batch",
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Flags": "1",
"TxnIDs": [
"7EB435C800D7DC10EAB2ADFDE02EE5667C0A63AA467F26F90FD4CBCD6903E15E",
"EAE6B33078075A7BA958434691B896CCA4F532D618438DE6DDC7E3FB7A4A0AAB"
],
"Sequence": 3,
"Fee": "40",
"SigningPubKey": "022D40673B44C82DEE1DDB8B9BB53DCCE4F97B27404DB850F068DD91D685E337EA",
"TxnSignature": "3045022100EC5D367FAE2B461679AD446FBBE7BA260506579AF4ED5EFC3EC25F4DD1885B38022018C2327DB281743B12553C7A6DC0E45B07D3FC6983F261D7BCB474D89A0EC5B8"
},
{
"TransactionType": "OfferCreate",
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"TakerGets": "6000000",
"TakerPays": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"BatchTxn": {
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"OuterSequence": 3,
"BatchIndex": 0
},
"Sequence": 0,
"Fee": "0",
"SigningPubKey": "",
"TxnSignature": ""
},
{
"TransactionType": "Payment",
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"Destination": "rDEXfrontEnd23E44wKL3S6dj9FaXv",
"Amount": "1000",
"BatchTxn": {
"Account": "rUserBSM7T3b6nHX3Jjua62wgX9unH8s9b",
"OuterSequence": 3,
"BatchIndex": 1
},
"Sequence": 0,
"Fee": "0",
"SigningPubKey": "",
"TxnSignature": ""
}
]
```
### Batch Fields
<!-- {% include '_snippets/tx-fields-intro.md' %} -->
| Field | JSON Type | [Internal Type][] | Description |
|:----------------|:--------------------|:------------------|:-------------------|
| TransactionType | string | UInt16 | |
| Account | string | STAccount | |
| Fee | string | STAmount | The fee is twice the base fee (a total of 20 drops when there is no fee escalation), plus the sum of the transaction fees of all the inner transactions (which incorporates factors like higher fees for multisign or AMMCreate). The fees for the individual inner transactions are paid here instead of in the inner transaction itself, to ensure that fee escalation is calculated on the total cost of the transaction instead of just the overhead. |
| Flags | number | UInt32 | The `Flags` field represents the batch mode of the transaction. Exactly one must be specified in a `Batch` transaction. See [Batch Flags](#batch-flags)|
| RawTransactions | array | STArray | RawTransactions contains the list of transactions that will be applied. See [Raw Transactions](#rawtransactions). |
| TxnIDs | array | Vector256 | `TxnIDs` contains a list of the transaction hashes/IDs for all the transactions contained in `RawTransactions`. This is the only part of the inner transactions that is saved as a part of the ledger within the `Batch` transaction, since the inner transactions themselves are their own transactions on-ledger. The hashes in TxnIDs must be in the same order as the raw transactions in `RawTransactions`. |
| BatchSigners | array | STArray | _Optional_. Only required if the `Batch` contains transactions for multiple accounts. See [BatchSigners](#batchsigners). |
### Batch Flags
Transactions of the Batch type support additional values in the `Flags` field as follows:
| Flag Name | Hex Value | Decimal Value | Description |
|:-------------------|:-------------| ------------: |:------------------------------|
| `ALLORNOTHING` | 0x00000001 | 1 | All or nothing. All transactions must succeed for any of them to succeed. |
| `ONLYONE` | 0x00000002 | 2 | The first transaction to succeed is the only one to succeed; all other transacitons either fail or are never tried. |
| `UNTILFAILURE` | 0x00000004 | 4 | All transactions are applied until the first failure; all transactions after the first failure are not applied. |
| `INDEPENDENT` | 0x00000008 | 8 | All transactions will be applied, regardless of failure. |
### RawTransactions
`RawTransactions` contains the list of transactions to be applied. There can be up to 8 transactions included. These transactions can come from one account or multiple accounts.
Each inner transaction:
- Must contain a BatchTxn field.
- Must not have a sequence number. It must use a sequence number value of 0.
- Must not have a fee. It must use a fee value of "0".
- Must not be signed (the global transaction is already signed by all relevant parties). They must instead have an empty string ("") in the SigningPubKey and TxnSignature fields.
A transaction is considered a failure if it receives any result that is not `tesSUCCESS`.
This field is not included in the validated transaction, nor is it used to compute the outer transaction signature(s), since all transactions are included separately as a part of the ledger.
### BatchSigners
This field operates similarly to multisign on the XRPL. It is only needed if multiple accounts' transactions are included in the Batch transaction; otherwise, the normal transaction signature provides the same security guarantees.
Every account that has at least one inner transaction, excluding the outer account (if applicable), must have a BatchSigners field.
| Field | JSON Type | [Internal Type][] | Description |
|:----------------|:--------------------|:------------------|:-------------------|
| Account | string | STAccount | This is an account that has at least one inner transaction. |
| SigningPubKey | string | STBlob | Included if the account is signing with a single signature. |
| Signature | string | STBlob | Included if the account is signing with a single signature. |
| Signers | array | STArray | This field is included if the account is signing with multi-sign (as opposed to a single signature). It operates equivalently to the Signers field used in standard transaction multi-sign. This field holds the signatures for the Flags and TxnIDs fields. |
## BatchTxn
The `BatchTxn` inner object must be included in any inner transaction of a `Batch` transaction. Its inclusion:
- Prevents hash collisions between identical transactions (since sequence numbers aren't included).
- Ensures that every transaction has a sequence number associated with it, so that created ledger objects that use it in their ID generation can still operate.
- Allows users to more easily organize their transactions in the correct order.
The fields contained in this object are as follows.
| Field | JSON Type | [Internal Type][] | Description |
|:---------------------|:-----------------|:------------------|:-----------------|
| `Account` | string | AccountID | Account that is submitting the outer `Batch` transaction. |
| `OuterSequence` | number | UInt32 | This is the sequence number of the outer `Batch` transaction. Its inclusion ensures that there are no hash collisions with other `Batch` transactions. |
| `Sequence` | number | UInt32 | _(Optional)_ This is the next available sequence number for the inner transaction's account. This only needs to be included in a multi-account Batch transaction. |
| `BatchIndex` | number | UInt8 | This is the (0-indexed) index of the inner transaction within the existing `Batch` transaction. The first inner transaction will have BatchIndex value 0, the second will be 1, and so on. Its inclusion ensures there are no hash collisions with other inner transactions within the same `Batch` transaction, and that the transactions are all placed in the right order. |
## Example Multiple Account Batch JSON
In this example, two users are atomically swapping their tokens, XRP for GKO. The inner transactions still are not signed, but the `BatchSigners` field is needed on the outer transaction, since there are two accounts' inner transactions in this `Batch` transaction.
```json
{
"TransactionType": "Batch",
"Account": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Flags": "0x00010000",
"RawTransactions": [
{
"RawTransaction": {
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Destination": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"Amount": "6000000",
"Sequence": 5,
"Fee": "0",
"SigningPubKey": ""
}
},
{
"RawTransaction": {
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"Destination": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Amount": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"Sequence": 20,
"Fee": "0",
"SigningPubKey": ""
}
}
],
"BatchSigners": [
{
"BatchSigner": {
"Account": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"SigningPubKey": "03C6AE25CD44323D52D28D7DE95598E6ABF953EECC9ABF767F13C21D421C034FAB",
"TxnSignature": "304502210083DF12FA60E2E743643889195DC42C10F62F0DE0A362330C32BBEC4D3881EECD022010579A01E052C4E587E70E5601D2F3846984DB9B16B9EBA05BAD7B51F912B899"
}
}
],
"Sequence": 4,
"Fee": "60",
"SigningPubKey": "03072BBE5F93D4906FC31A690A2C269F2B9A56D60DA9C2C6C0D88FB51B644C6F94",
"TxnSignature": "30440220702ABC11419AD4940969CC32EB4D1BFDBFCA651F064F30D6E1646D74FBFC493902204E5B451B447B0F69904127F04FE71634BD825A8970B9467871DA89EEC4B021F8"
}
```
#### Sample Ledger Response
```json
[
{
"TransactionType": "Batch",
"Account": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Flags": "0x00010000",
"RawTransactions": [
{
"RawTransaction": {
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Destination": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"Amount": "6000000",
"Sequence": 5,
"Fee": "0",
"SigningPubKey": ""
}
},
{
"RawTransaction": {
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"Destination": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Amount": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"Sequence": 20,
"Fee": "0",
"SigningPubKey": ""
}
}
],
"BatchSigners": [
{
"BatchSigner": {
"Account": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"SigningPubKey": "03C6AE25CD44323D52D28D7DE95598E6ABF953EECC9ABF767F13C21D421C034FAB",
"TxnSignature": "304502210083DF12FA60E2E743643889195DC42C10F62F0DE0A362330C32BBEC4D3881EECD022010579A01E052C4E587E70E5601D2F3846984DB9B16B9EBA05BAD7B51F912B899"
}
}
],
"Sequence": 4,
"Fee": "60",
"SigningPubKey": "03072BBE5F93D4906FC31A690A2C269F2B9A56D60DA9C2C6C0D88FB51B644C6F94",
"TxnSignature": "30440220702ABC11419AD4940969CC32EB4D1BFDBFCA651F064F30D6E1646D74FBFC493902204E5B451B447B0F69904127F04FE71634BD825A8970B9467871DA89EEC4B021F8"
},
{
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Destination": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"Amount": "6000000",
"Sequence": 5,
"Fee": "0",
"SigningPubKey": ""
},
{
"TransactionType": "Payment",
"Flags": 1073741824,
"Account": "rUser2fDds782Bd6eK15RDnGMtxf7m",
"Destination": "rUser1fcu9RJa5W1ncAuEgLJF2oJC6",
"Amount": {
"currency": "GKO",
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
"value": "2"
},
"Sequence": 20,
"Fee": "0",
"SigningPubKey": ""
}
]
```

2
sidebars.yaml
View File

@@ -76,6 +76,7 @@
- page: docs/concepts/transactions/index.md
expanded: false
items:
- page: docs/concepts/transactions/batch-transactions.md
- page: docs/concepts/transactions/fees.md
- page: docs/concepts/transactions/reliable-transaction-submission.md
- page: docs/concepts/transactions/secure-signing.md
@@ -383,6 +384,7 @@
- page: docs/references/protocol/transactions/types/ammdeposit.md
- page: docs/references/protocol/transactions/types/ammvote.md
- page: docs/references/protocol/transactions/types/ammwithdraw.md
- page: docs/references/protocol/transactions/types/batch.md
- page: docs/references/protocol/transactions/types/credentialaccept.md
- page: docs/references/protocol/transactions/types/credentialcreate.md
- page: docs/references/protocol/transactions/types/credentialdelete.md