Operations are the bread and butter of Bantu: they’re the individual commands that mutate the ledger. Transactions, which accounts sign and submit for inclusion in the ledger, are really just bundles of operations. Transactions can, by definition, include anywhere from 1 to 100 operations.
Network capacity, which is determined by validator vote, is measured in terms of operations/ledger. Currently, it’s set to 1,000.
There are thirteen possible operation types, each of which is detailed along with parameters, errors, and links to SDK docs in the List of Operations.
Operations are executed on behalf of the source account specified in the transaction, unless there is an override defined for the operation.
Each operation falls under a specific threshold category: low, medium, or high. Thresholds define the level of privilege an operation needs in order to succeed.
Everything Else (
SetOptions (only when changing signers and the thresholds for each category).
When a transaction is submitted to a node, the node checks the validity of each operation in the transaction before attempting to include it in a candidate transaction set. These initial operation validity checks are intended to be fast and simple: more intensive checks come later, after fees have been consumed. For an operation to pass this first validity check, it has to meet the following conditions:
The signatures on the transaction must be valid for the operation. That means:
The signatures are from valid signers for the source account of the operation.
The combined weight of all signatures for the source account of the operation meets the threshold for the operation.
The operation itself must be well-formed. Typically this means checking the parameters for the operation to see if they're in a valid format.
For example, only positive values can be set for the amount of a payment operation.
The operation must be valid in the current protocol version of the network. Deprecated operations, such as inflation, are invalid by design.
For more details on this process, see the lifecycle of a transaction.
For each operation, there is a matching result type. In the case of success, this result allows users to gather information about the effects of the operation. In the case of failure, it allows users to learn more about the error.