2. Transaction Manifest

As flash loans are executed within a single transaction, you are required to tailor a transaction. Tailoring and building a transaction can be done in multiple ways, either manually, semi-automatically and fully automatically. To actually understand what happens under the hood, we will first walk through the manual way of tailoring a transaction. To build a transaction manually we need to take a closer look at what is called the "transaction manifest".

Transaction manifest

"A transaction manifest is the Radix way of building transactions. It makes it possible to compose multiple actions to be executed atomically by describing a sequence of component calls and movements of resources between components. In short, full atomic composability becomes possible directly in transactions" - see link for more detail.

Below the most basic transaction is demonstrated as transaction manifest. This is what happens:

1. A "lock fee" method is called on an account address that locks some XRD as fee. "lock_fee" will immediately add the associated amount of XRD to the fee reserve. This XRD can be used to pay for ongoing processing during the transaction’s execution, and can be spent even if the transaction ultimately fails in its execution. See article.

2. A "withdraw" method is called on an account address that takes some amount of a resource from the account. If you want to use XRD to fund a certain action, this method is required to get the XRD into the transaction.

3. A "take_from_worktop_by_amount" is called on some amount of a resource, takes it from the worktop, and puts it in a bucket. This operation is a bit less intuitive, please read this post for more information. In essence you can think of the "worktop" as a distribution centre, or a layer on top of a transaction, that orchestrates resources from one instance to the other. Unused resources will be stored in the worktop during a transaction, and have to be withdrawn to be exchanged.

4. A "deposit" method is called that takes some bucket and deposits it into a account address. This is final operation that finalises the transaction. Note: no resources are allowed to be left in the worktop for a transaction to be completed. Therefore it is of importance that all hanging resources are deposited at the end of a transaction.

# lock fees to pay for the transaction
CALL_METHOD
  Address("[your_account_address]")
  "lock_fee"
  Decimal("[amount]");

# withdraw 10 XRD from account, which goes to the worktop
CALL_METHOD
  Address("[your_account_address]")
  "withdraw"
  ResourceAddress("[xrd_address]")
  Decimal("[amount]");

# take 10 XRD from the worktop and put it in a bucket
TAKE_FROM_WORKTOP_BY_AMOUNT
  Decimal("10")
  Address("[xrd_address]")
  Bucket("xrd");

# deposit the bucket of XRD into the recipient's account
CALL_METHOD
  Address("[your_account_address]")
  "deposit"
  Bucket("xrd");

The above transaction is considered a simple "one component" transaction. Although the skeleton of the flash loan transaction will be similar, a flash loan will interact with more components during the same transaction, and is therefore considered a complex transaction. The next section will describe what flash loan transaction manifest will look like.