Transactions
A transaction requests a change to network state, such as a transfer or a validator vote.
The lifecycle
Section titled “The lifecycle”- Prepare. Choose the account, network, operation, and required values.
- Review. Check the complete action and the fee shown by the wallet.
- Authorize. The appropriate account keys approve the transaction.
- Submit. A network service receives it for validation.
- Observe. Follow its recorded result and any finality information.
A successful network submission does not itself prove inclusion in a block. A local simulation demonstrates the interface without performing the authorization and network steps.
What to review
Section titled “What to review”| Field | What it identifies |
|---|---|
| Network | The environment receiving the action |
| Sender | The account authorizing it |
| Asset ID | The asset being moved |
| Recipient | The destination account |
| Amount | The asset quantity, with its correct precision |
| Fee | The charge shown for the selected operation |
| Reference or memo | Optional context attached to the action |
An account nonce orders transactions from the same account. Its exact encoding and acceptance rules belong to the network’s transaction contract. Do not guess a next nonce from an old activity screen.
Current baseline types
Section titled “Current baseline types”The current Rust transaction registry retains six version-3 types. These are the implemented compatibility baseline, before the later native-asset and migration operations.
| Group / type | Operation |
|---|---|
1 / 1 | Second-signature registration |
1 / 2 | Validator registration |
1 / 6 | Transfer to one or more recipients |
1 / 7 | Validator resignation |
2 / 0 | Burn |
2 / 2 | Vote |
- Transaction ID: SHA-256 of the serialized bytes, including signatures.
- Memo limit: 255 UTF-8 bytes.
Build clients with the registry and codec from the selected release. These baseline encodings differ from the later draft protocol, whose fixed operation set also covers native asset creation, atomic swaps, hash time-locked and time-locked transfers, account names (NAME_REGISTER, NAME_CLAIM), reward-sharing declarations (SHARE_DECLARE), key rotation, multisig accounts, and migration.
Read send and receive for the wallet flow, or integration principles for client behavior.