Transaction Manifests

Overview

Transaction manifests are Radix's instruction format for describing what a transaction should do. Where an EVM transaction encodes a function call as opaque hex calldata — the condition the wiki covers under blind signing — a manifest is an ordered list of named instructions over named values, and the same list a wallet displays is the list the Radix Engine executes.

A manifest reads like a recipe: withdraw XRD from an account, take some of it into a bucket, hand the bucket to a component, assert what came back, deposit the rest. It is not a script in the ordinary sense — there are no loops, no branches and no arithmetic. It is a straight-line list of effects, which is exactly what makes it possible to render, to analyse statically, and to check against what a user thought they were signing.

Composability

Manifests can chain any number of operations into a single atomic transaction. One manifest might withdraw collateral from a lending protocol, swap it on a DEX, provide liquidity, and deposit the LP tokens — all in one commit. If any instruction fails, the whole transaction reverts and nothing moved.

The Instruction Set

A manifest is a value of InstructionV2, an enum defined in the radix-transactions crate of radixdlt-scrypto. There are 38 of them, and the enum groups them into six sections with the comments left in the source:

The largest group is proof handling, which is a fair summary of what the format is for: most of the surface area is spent on saying precisely which authority a call is made under, rather than on saying what the call is. There is no instruction for arithmetic, comparison or control flow anywhere in the enum, and that absence is load-bearing — it is why a manifest's effects can be enumerated without running it.

Worktop, Buckets and Proofs

The instruction set only makes sense alongside the resource plumbing it manipulates. Resources on Radix are not ledger entries a contract may write to; they are objects that must physically be somewhere, which is the substance of asset-oriented programming. Inside a transaction that "somewhere" is one of three places, all covered in depth under Buckets, Proofs & Vaults:

• The worktop — the transaction's own holding area. Anything a component hands back lands here, and the transaction is not valid unless the worktop is empty when it ends. Resources cannot be lost by omission; they can only be deposited, burned or returned.
• Buckets — named portions taken off the worktop and passed into a call.
• Proofs — evidence of holding a badge or resource, without transferring it.

A manifest from the repository's own worktop example shows the shape (the ${...} forms are placeholders the test harness substitutes):

# Withdraw XRD from account
CALL_METHOD Address("account") "withdraw" Address("xrd") Decimal("5.0");
 
# Buy GUM with XRD
TAKE_FROM_WORKTOP Address("xrd") Decimal("2.0") Bucket("xrd");
CALL_METHOD Address("component") "buy_gumball" Bucket("xrd");
ASSERT_WORKTOP_CONTAINS Address("gumball") Decimal("3.0");
 
# Move all resources in worktop to account
CALL_METHOD Address("account") "deposit_batch" Expression("ENTIRE_WORKTOP");

The ASSERT_WORKTOP_CONTAINS line is the part worth noticing. It is not a comment or a client-side check — it is an instruction, it executes, and if the component returned fewer than three gumballs the whole transaction aborts. Slippage limits, minimum-received guarantees and "this had better be the token I asked for" are expressed in the manifest rather than trusted to the component, which is why they hold even when the component is hostile.

From Manifest to Notarized Transaction

The manifest is the innermost layer of a transaction, not the whole of one. Around it sit a header (the epoch window the transaction is valid in, the network it targets, a nonce, the notary's public key), the signatures of every account whose authority the instructions need, and finally the notary's own signature. The models live beside the instruction set in radix-transactions/src/model/v2 — transaction_manifest_v2.rs, transaction_intent_v2.rs, signed_transaction_intent_v2.rs and notarized_transaction_v2.rs, in that order of containment.

Manifests are written as .rtm files in a readable text form, then compiled to SBOR for transmission. The relationship is a round trip rather than a one-way build step: the crate ships a decompiler alongside the compiler, so a transaction pulled off the ledger can be rendered back into the same instruction list it was written as. This is what lets a wallet, an explorer and a reviewer all read a transaction that was assembled by a dApp's SDK, and it is the mechanical basis for the claim that Radix transactions are not blind-signed.

What the wallet shows a user is a further step on top: the transaction is previewed and the instruction list is classified — a transfer, a pool contribution, a stake — so the summary a user approves is derived from the instructions rather than supplied by the dApp requesting the signature.

What V2 Added

The Cuttlefish protocol update, enacted on mainnet on 18 December 2024, introduced the V2 transaction format. Comparing the two enums in the source, V2 is a strict superset: all 30 InstructionV1 variants survive unchanged and eight are added. Nothing was removed, which is why V1 transactions remain valid.

The eight fall into two groups. Five are new assertions — ASSERT_WORKTOP_RESOURCES_ONLY, ASSERT_WORKTOP_RESOURCES_INCLUDE, ASSERT_NEXT_CALL_RETURNS_ONLY, ASSERT_NEXT_CALL_RETURNS_INCLUDE and ASSERT_BUCKET_CONTENTS. The NEXT_CALL_RETURNS pair is the notable one: it constrains what the following instruction is permitted to hand back, so a manifest can bound the outcome of a call it does not control before making it, rather than inspecting the damage afterwards.

The other three — YIELD_TO_PARENT, YIELD_TO_CHILD and VERIFY_PARENT — are the machinery of subintents and pre-authorizations. A subintent is a manifest fragment signed by one party and composed into a larger transaction by another, with control passing back and forth through the yield instructions; VERIFY_PARENT lets a child assert something about the transaction it has been embedded in. Radix Docs covers the intent structure these instructions form, and the wiki's subintents page covers the pre-authorization flows built on it.

AI Agent Compatibility

Manifests matter disproportionately for AI agents, for the same reason they matter for wallets. An agent can construct a manifest, parse one it did not construct, and enumerate the effects of either without executing anything or trusting the party that supplied it — the instruction list is the transaction, and it is finite, named and branch-free.

The property that carries this is the absence of control flow. A format with loops or conditionals would make "what will this transaction do" a question answerable only by running it against live state; without them, the set of components called and the assertions that must hold can be read straight off the list. This is the same property the Hyperscale programme's purpose-built VM is designed to strengthen further, by making a transaction's full data footprint statically derivable from the manifest and the referenced blueprints' metadata — see hyperscale-rs.

External Links

• Radix Docs — Transaction Manifest
• Radix Docs — Manifest Instructions
• Radix Docs — Subintents
• InstructionV2 — the canonical 38-instruction set
• InstructionV1 — the 30-instruction set it supersedes
• Example .rtm manifests in radixdlt-scrypto
• Transaction Manifest Language Guide
• Transaction Lifecycle