Transactions
This page introduces transactions transitioning state upon execution.
Last updated
This page introduces transactions transitioning state upon execution.
Last updated
A transaction transitions state by consuming and creating resources on execution. This requires the transaction to be balanced (i.e., have a delta value of zero) & valid (i.e., all resource logics must be valid and resources must be resource machine compliant).
Balanced transactions are sent to a transaction mempool, where they can be picked up by a block producer that verifies and executes them in a determined order, thus updating the state. Unbalanced transactions, a.k.a. intents are sent to an intent mempool to be processed by solvers. Solvers compose unbalanced transactions to produce balanced transactions.
Applications provide so-called transaction functions as part of their interface producing balanced or unbalanced transactions, a.k.a. intents. The underlying transaction object contains standardized data fields, which are defined in the Anoma specs.