05 Transactions

5.3 The Anatomy of a Transaction Manifest

Now that we have a general understanding how instructions are put together to create a transaction with the transaction manifest, let’s group related instructions together to better categorize what instructions the transaction manifest offers us. Broadly speaking, the transaction manifest instructions can be grouped to core, worktop, AuthZone, and alias instructions. We’ll be going through these categories throughout this section.

We’ll also note that this section won’t be providing snippet examples of each instructions nor will all the instructions be provided at this time. Transaction Manifest instructions can rapidly be added and/or changed and the best source of truth for references on manifest instructions are on the Transaction Manifest Specification page in the docs.

//Core Transaction Manifest Instructions

Many transaction manifest instructions deal with blueprint function or component method calls whether it be withdrawing resources from an account component, performing a swap on a DEX, or instantiating a component from a blueprint.

Instruction Description CALL_FUNCTION This instruction is normally used to instantiate components from blueprints. CALL_METHOD This instruction is normally used to call methods from account components to manage an account's resources, perform native component actions, or perform custom actions supported by the component.

//Worktop Instructions

The worktop is a place where resources are temporarily placed and allows us to manage resources in between component calls within a transaction. The transaction manifest is not only list instructions, but also describes the asset flows between instructions.

There are several instructions we can utilize to move these resources around which places them into buckets so that they may be passed as arguments to other component calls. We can move resources placed in the worktop with the following instructions:

Instruction Description TAKE_FROM_WORKTOP This instruction is used as a way to manage and take a supplied quantity of resource(s) from the worktop by placing it into a bucket. TAKE_ALL_FROM_WORKTOP This instruction is used to take all the supplied amount of a resource. TAKE_NON_FUNGIBLES_FROM_WORKTOP This instructions is used to take a specified array of non-fungibles from the worktop and place them into a bucket. RETURN_TO_WORKTOP This instruction is used to return a bucket of resource back into the worktop.

1CALL_METHOD2    Address("[your_account_address]")3    "withdraw"4    Address("[xrd_address]")5    Decimal("10") ;67TAKE_FROM_WORKTOP8    Address("[xrd_address]")9    Decimal("10")10    Bucket("xrd_bucket");11    12CALL_METHOD13    Address("token_sale_component_address")14    "buy_useful_token"15    Bucket("xrd_bucket");1617CALL_METHOD18    Address("[your_account_address]")19    "deposit_batch"20    Expression("ENTIRE_WORKTOP");

Worktop instructions are often used to manage resources between transaction manifest instructions. For example, if we were to use a DEX to swap one resource for another, the first instruction would be a method call to withdraw resources from the account. These resources are automatically placed into the worktop. We can then use a worktop instruction to take a specific amount or all of the amount we withdrew and place them into a bucket to perform a swap.

Worktop Assertion Instructions

We can account for resources on the worktop by using assertions to check the contents of the worktop. These assertions check and guarantee the worktop contains the resources and its amount from a component method call, else the entire transaction will fail.

1CALL_METHOD2    Address("[your_account_address]")3    "withdraw"4    Address("[xrd_address]")5    Decimal("10") ;67TAKE_FROM_WORKTOP8    Address("[xrd_address]")9    Decimal("10")10    Bucket("xrd_bucket");11    12CALL_METHOD13    Address("token_sale_component_address")14    "buy_useful_token"15    Bucket("xrd_bucket");16  17ASSERT_WORKTOP_CONTAINS18    Address("[useful_token_address]")19    Decimal("1");2021CALL_METHOD22    Address("[your_account_address]")23    "deposit_batch"24    Expression("ENTIRE_WORKTOP");

These instructions are useful to create guarantees around the amounts we expect to receive from a component method call such as guaranteeing the amount we expect to receive from a token swap.

//Proofs and AuthZone Instructions

The transaction manifest also have instructions to create proofs and manage proofs in the AuthZone same as we manage resources in the worktop. For example, we can create a proof of a badge we hold from our account to access a permissioned method call.

1CALL_METHOD2    Address("[your_account_address]")3    "withdraw"4    Address("[owner_badge_address]")5    Decimal("1") ;67TAKE_FROM_WORKTOP8    Address("[owner_badge_address]")9    Decimal("1")10    Bucket("owner_badge_bucket");11    12CREATE_PROOF_FROM_BUCKET_OF_AMOUNT13    Bucket("owner_badge_bucket")14    Decimal("1")15    Proof("owner_badge_proof")1617PUSH_TO_AUTH_ZONE18    Proof("owner_badge_proof");19    20CALL_METHOD21    Address("[token_sale_component_address]")22    "redeem_profits"2324CALL_METHOD25    Address("[your_account_address]")26    "deposit_batch"27    Expression("ENTIRE_WORKTOP");

Additionally, we can also use an AuthZone instruction to retrieve the proof and pass the proof into the method call to perform an application-level auth.

1CALL_METHOD2    Address("[your_account_address]")3    "create_proof"4    Address("[claim_badge_address]")5    Decimal("1") ;6    7POP_FROM_AUTH_ZONE8    Proof("claim_badge_proof");910CALL_METHOD11    Address("[xrd_distributer_component_address]")12    "claim_tokens"13    Proof("claim_badge_proof") ;1415CALL_METHOD16    Address("[your_account_address]")17    "deposit_batch"18    Expression("ENTIRE_WORKTOP");

//Alias Instructions

Alias instruction pertain to interacting with Radix Engine interfaces such as creating new accounts, resources, or instantiating Native Blueprints. This is because many of these instructions stem from natively built “smart contracts” within the engine and are simply function or method calls under the hood. For example, when we are using the CREATE_FUNGIBLE_RESOURCE instruction, under the hood it is a CALL_METHOD to a Radix Engine interface.

1CALL_METHOD2    Address("[your_account_address]")3    "create_proof"4    Address("[minter_badge]")5    Decimal("1") ;6    7MINT_FUNGIBLE8    Address("[useful_token_address]")9    Decimal("1");1011CALL_METHOD12    Address("[your_account_address]")13    "deposit_batch"14    Expression("ENTIRE_WORKTOP");

//Value Types

In Radix transaction manifest, all arguments are strongly typed. When passing values to instruction arguments, be mindful of what type is supported. You can find the list of supported types in the Transaction Manifest Specification docs.

//Writing Transaction Manifest

After going through the transaction manifest, you must be wondering why there isn’t a clear guide how transaction manifests are written. This is because at the current stage, some manifest instructions can become quite complex where there isn’t a clear pattern to recommend when writing them by hand. Additionally, the tooling to writing transaction manifest easily require additional knowledge that isn’t covered in this course.

In the meantime, it’s still worth understanding how transactions work with Radix with the transaction manifest. If you are keen to understanding how writing transaction manifest, there are some documentation which you can follow with your own path in the Writing Manifests page.

//Reference Material

5.2 Summary

5.3 Summary