What are Transaction Manifests?

file icon

What are Transaction Manifests?

This page refers to features planned for the Babylon version of the Radix network, coming in Q2 2023, and may not apply to the current Olympia network version. For more information about the Radix roadmap, click here. To learn about other core capabilities of Babylon, return to Start Here! Upcoming Babylon Concepts and Technologies.

Transaction Manifests are the more powerful form of public ledger transaction used on the Radix network.

Typically today, transactions are simply a message passed to a single smart contract, and that smart contract is responsible for coordinating whatever should happen. Usually that message is hashed, making it unreadable for the user – but even if this weren’t the case, the transaction would tell you nothing at all about the result, only the input.

Leveraging the asset-oriented design of the Radix Engine, Transaction Manifests are inherently asset-oriented transactions. They are a listing of commands to the Radix network that have to do with the movement of assets between accounts and dApp components.

To take a simple example:

To send 10 tokens to Bob on Ethereum, you send a message to the relevant ERC-20 contract that basically says “please send 10 tokens to Bob”. You then trust that the smart contract has implemented its send function in a way that correctly verifies your signature and updates the balances of tokens. But you have no guarantees that it will do so.

To send 10 tokens to Bob on Radix, the Transaction Manifest describes things the way we would do it in the real-world. It basically says “withdraw 10 tokens from my account, then deposit those tokens into Bob’s Smart account”.  The Radix account (a Smart Account component) verifies you have permission to withdraw.

With the Transaction Manifest, the same concept goes when interacting with a dApp component. Let’s say you want to use a Swapper DEX dApp to swap 10 X tokens for the current market price of Y tokens – maybe 23.9 Y right now.

On Ethereum, you send a message to the Swapper DEX smart contract that says “please swap 10 X for some Y”. You then trust that the Swapper smart contract will correctly tell the X and Y token ERC-20 smart contracts to update the balances, hope that the ERC-20 contracts do so correctly, and hope that this results in something not too much less than 23.9 Y.

On Radix, the Transaction Manifest says “withdraw 10 X tokens from my account, pass those tokens to the Swapper component, then deposit the tokens that it returns back to my account. Oh, and if that return is less than 23 Y tokens, call the whole thing off.” 

On Radix, the Transaction Manifest actually describes what the user cares about. This means the Radix Wallet can show a clear, meaningful summary of exactly what’s going to happen. You also are protected from unexpected results. In the example above, it doesn’t matter if the Swapper is buggy or malicious, and it doesn’t matter if somebody front-runs your trade; the transaction will only happen if the result is you receiving at least 23 B tokens at the end. No surprises. No more “blind signing”, the cause of so many hacks and exploits (see further reading below on “Rekt Retweets” for example hacks and how they wouldn’t have happened on Radix).

Transaction Manifests also automatically enable atomic composability – without smart contract code.

The reason users want to “compose” multiple smart contracts together is to use assets across them in interesting ways. Perhaps a loan taken out in one component should be used to make a purchase from another. Typically this requires writing and deploying a special smart contract to coordinate actions across other smart contracts. With the Transaction Manifest, the asset returns from one component can be directly passed on to the next, and so on. If any part of the chain of asset movements fails, the entire transaction is canceled.

Not only does this make composed dApp interactions more transparent to users, it means that a web frontend can dynamically compose different dApps together on the fly just by constructing Transaction Manifests that describe what is desired.

To learn more about Transaction Manifests, see our technical docs.

Further reading: