05 Transactions
5.1 Introduction to Transactions on Radix with the Transaction Manifest
Congratulations on getting through this course, Chapter 5 is the last heavy Scrypto concept that we will introduce in this course. Up until this point, you’ve learned the necessary foundations to write powerful blueprints with native Scrypto concepts and tools. Now, we will take it outside of the blueprints and components realm to build an understanding how transactions work on the Radix network.
Users on the Radix network have accounts which hold their assets, and users will want to do things with their assets by interacting with components and dApps. Unlike most networks where a user can only perform a single action, users on Radix can sign and submit a transaction to the network that describes a set of instructions they want to do with their assets and the components they interact with. These instructions are compiled into what’s called the transaction manifest. Said another way, a transaction manifest is a list of instructions that specifies the method calls and describes the asset movement between each method call.
Users on the Radix network have accounts which hold their assets, and users will want to do things with their assets by interacting with components and dApps. Unlike most networks where a user can only perform a single action, users on Radix can sign and submit a transaction to the network that describes a set of instructions they want to do with their assets and the components they interact with. These instructions are compiled into what’s called the transaction manifest. Said another way, a transaction manifest is a list of instructions that specifies the method calls and describes the asset movement between each method call.
//What is a Transaction Manifest
We write a Transaction Manifest as the set of instructions used to not only describe but also submit transactions to the Radix Engine for execution on the Network. Every transaction on the network is accompanied by a transaction manifest which defines in a special syntax designed to be easily human readable what must be done to commit a successful transaction to ledger. If any item on the manifest fails the whole transaction is rejected ensuring predictable results when performing transactions on Radix.
//Benefits of a Transaction Manifest
In other smart contract platforms, users can only directly perform one method call at a time. This user experience can be quite limiting, especially in the scope of DeFi. Take for example that we come across a scenario where the user sees price discrepancies of a particular token between two DEX’s and this user wishes to purchase the token that is cheaper on DEX 1 and sell the token in DEX 2 that is priced higher, thus performing an arbitrage trade. The user wants to do this sequence of steps all within the same transaction to maximise profits. On other platforms, the way to do this is having a separate smart contract to be deployed on the network that facilitates this type of transaction. This smart contract would then make the function call of purchasing the tokens from DEX 1 to sell the tokens in DEX 2 all within the same transaction. This would mean that there are two cases that could happen:
Case 1: The user is in luck and they find an already deployed contract that does exactly what they need to weave these calls together to perform the arbitrage. In this case they can straight away call the appropriate method on this other contract and it will in turn make the calls to the methods that they want.
Case 2: There isn’t a deployed smart contract that weaves the transaction in the way the user would like, so that leads to the user having to deploy their own smart contract that weaves these method calls together. Aside from the coding knowledge needed, knowledge of smart contracts and how they’re imported and stuff like that, the cost of deploying this smart contract to the blockchain just so the user can compose transactions together is impractical.
Case 2: There isn’t a deployed smart contract that weaves the transaction in the way the user would like, so that leads to the user having to deploy their own smart contract that weaves these method calls together. Aside from the coding knowledge needed, knowledge of smart contracts and how they’re imported and stuff like that, the cost of deploying this smart contract to the blockchain just so the user can compose transactions together is impractical.
Additionally, as a developer this provides a poor developer experience as writing a smart contract and paying for the fees to deploy the smart contract in order to compose method calls can become expensive and annoying. If there is a bug in the smart contract, then the developer would have to go through the burden of re-writing and re-deploying the smart contract.
Finally, this setup stifles composability, which is one of the most powerful features of dApps. The power of atomic composability cannot be underscored enough.
Finally, this setup stifles composability, which is one of the most powerful features of dApps. The power of atomic composability cannot be underscored enough.
//Atomic Composability Powered by the Transaction Manifest
Atomic composability is being able to interact with many different components in the same transaction - and having the steps revert if an error or failed assertion occurs at any step is a really important concept to make DeFi thrive. The previous arbitrage trade example is a simple and effective example of an atomic transaction, where all the sequence of those steps of that trade must be performed all at once. Additionally, with the transaction manifest, the user can specify an assertion that the transaction must profit in that transaction, otherwise, the transaction must fail leading to effectively guaranteed profit for the user to perform such transaction.