Each Radix transaction goes through a set of lifecycle phases: construct time, sign time, submit time and run time.
In this section, we discuss the runtime view of a transaction.
At the root of the runtime is a transaction context, which abstracts the low-level transaction details and is associated with a collection of buckets and bucket refs. These resource containers and references are produced by already executed instructions and can be consumed by the following instructions.
When a transaction finishes, the collection should be empty.
Some instructions, like
DepositAllBuckets, may call into another blueprint or component. In such cases, a call stack is dynamically allocated and deallocated.
All data and resources in call arguments moves from the caller to the callee. Call data is inspected by Radix Engine and invalid data would result in a runtime failure.
Each call frame is also associated with a collection of buckets and bucket refs. At the time of returning, this collection must be empty. After that, the call frame is deallocated.