Transaction Complexity in ETH, SOL, APT, and RDX

By Michael @ CryptoEQ | CryptoEQ | 4 Apr 2024

You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $40/month you can upgrade to our FULL library of 60+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 


Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

  • Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
  • Early access to future CORE ratings: Being early is sometimes just as important as being right!
  • Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
  • CORE report Audio playback: Don’t want to read? No problem! Listen on the go.



A transaction, in essence, is when a user updates the state of the ledger by signing a set of instructions. Most transactions involve transferring of funds from one account to another. It’s important for these fund movements to be correct as if there is misapplied logic, then users could lose funds (or some users gain funds unexpectedly). Most transactions require a “gas” fee, which pays for the work performed by nodes to process the transaction.

Here’s a summary of how transactions work on our selected platforms.


Transactions on Ethereum can either be for the native asset ETH only; or they are calls to contracts, such as ERC20 contracts. In both cases, the user signing the transaction must pay gas fees from the account they wish to use, meaning that users must have some ETH in each account they wish to use.

For contract calls, a transaction can call only one smart contract. That smart contract then serves as the gateway to further downstream contract calls. Some transactions can involve more than ten different smart contracts calling further downstream contracts to update their own internal state, forming long chains of “delegate calls.” A major limitation of this approach is that if one of those downstream contract calls fails, all the smart contracts have to be able to cater to those failure modes, which can cause issues for users and cause additional complexity for developers.

Another barrier facing Ethereum’s UX is that the platform doesn’t understand natively what any token is other than ETH. To Ethereum, an ERC20 token is an arbitrary set of numbers that, if updated, must obey the logic defined by the smart contract. There is no on-chain requirement for ERC20 tokens to follow the same behaviors. It’s just a standard that a developer can manually choose to follow if they want. This reduces the trust in ERC20 tokens as users don’t actually have guarantees on what a token will do, e.g. if the accounting will be performed correctly, or worse, if signing a transaction with it means that other tokens could be drained from the user’s account.

Furthermore, this model means that when users interact with any smart contract, they need to “blind sign” their transactions. Blind signing a transaction means that wallets present a hash to the user - a string of what appear to be unintelligible letters and numbers that the user signs. The wallet can’t present what the transaction will do in human-readable terms because neither Ethereum nor its wallets know what a token is, as it is just an arbitrary number that obeys arbitrary code in a smart contract. 

Users can, therefore, be easily tricked into signing something they didn’t actually mean to, as a hash could be to approve the transfer of tokens inside a smart contract, or it could be to approve a smart contract to have approval to spend the user’s tokens, without their consent, commonly known as a “wallet drain.” 


Metamask’s non-user-friendly UI for signing a message.

From a safety angle, an oblivious user might unintentionally approve malicious activities. Moreover, from an adoption perspective, the daunting deluge of cryptographic information might repel prospective enthusiasts. While MetaMask has been a game-changer, its mode of transaction depiction might hinder more expansive adoption.

Third-party solutions like have entered the scene to counter these challenges. WalletGuard aims to render Ethereum's enigmatic transaction prompts into more digestible, human-friendly formats. This enhancement aids users in grasping the repercussions of their actions. Yet, these remedial tools, although laudable, are more of a band-aid to the existing infrastructure rather than a fundamental, systemic remedy, as the issue stems from how tokens are represented in the EVM. Depending on such external utilities introduces another layer of complexity for developers, often leading to increased integration labor and possible vulnerability spots.


Solana’s Phantom wallet aims to improve the user experience in earlier blockchain wallets. This design philosophy is evident in how it presents transaction details. Unlike MetaMask's often cryptic messages, Phantom lays out information in a more digestible manner, reducing the knowledge gap. However, it does not completely solve for the issues outlined above for Ethereum, such as wallet drains or blind signing, as can be seen in the example below. 

Phantom Wallet also features customizable gas fees, allowing users to make informed decisions that optimize their transactions based on the prevailing network conditions. 

Like Ethereum, a transaction can only call one smart contract at once. Complex transactions require a custom smart contract to be deployed to orchestrate a series of downstream calls for the transaction.


Due to Aptos’ new approach to accounts and “resources” on its blockchain, it is able to provide several improvements to transaction UX over Ethereum and Solana.

Notably, Aptos integrates transaction viability protection, which safeguards users against inadvertent transactions by placing constraints on each transaction's viability via a sequence number, expiration time, and chain identifier, shielding users from risks such as replaying a transaction that has already been committed, has expired, or has been committed on a different blockchain, such as a test network. 

Additionally, the mechanism of pre-signature transaction transparency allows wallets to interpret transaction results in a readable format before the user signs it. This is  pivotal in mitigating potential threats associated with signing harmful transactions. This feature achieves this by offering a detailed depiction of potential transaction outcomes before endorsement. To further fortify against fraudulent activities, this function can assimilate data on previous attack patterns and potentially harmful smart contracts.


Radix has developed an entirely novel approach to how transactions work on top of a public ledger, called the “Transaction Manifest”.

The Transaction Manifest is structured as a series of calls to each account or smart contract, specifying how native tokens should move between those accounts or smart contracts, and specifying what methods to call on smart contracts. 

This opens up a number of advantages, namely:

  • Transactions on Radix aren’t limited to just calling a single smart contract - it’s possible for a transaction on Radix to call many accounts and smart contracts atomically, all at once, and if any of those calls fails for some reason, the entire transaction is aborted without needing any special logic built by the smart contract developer to handle such an occurrence.
  • Safer transactions because the Radix Engine virtual machine natively understands what tokens are, and natively handles the safe and accurate accounting that must occur during a transaction, such as tokens shouldn’t be spent twice, or tokens shouldn’t go missing during a transaction, which is logic that developers on Ethereum and other platforms must implement themselves. Radix Engine handles this accounting via containers for tokens called vaults (while assets are at rest) and buckets (while assets are on the move), and these must resolve correctly before the end of a transaction if the transaction is to be accepted.
  • The Transaction Manifest also allows applications to be built that can compose multiple smart contracts atomically on the fly, without needing a special smart contract to be deployed just to orchestrate the transaction, opening up new use cases for applications built only in website front ends.



  • Furthermore, as the Transaction Manifest specifies how tokens move between accounts, all transactions on Radix are human-readable. They do not need to be blind signed, as the Radix platform natively understands how tokens behave, and transactions are expressed to the Radix platform in human-readable terms. 

This innovation ensures that users can comprehend the essence of their transactions irrespective of their familiarity with blockchain intricacies. A simple transaction like withdrawing 20 USD tokens from my account and depositing 16.32 GBP tokens in my account is presented in human-readable language, eliminating the ambiguities of blind signing on other platforms.

Last, Radix users can also set customizable “Guarantees”, such as if they are conducting a swap between two assets, the network will guarantee that at least a certain amount of tokens are deposited into their account, or if that guarantee isn’t met, the transaction is aborted.

How do you rate this article?


Michael @ CryptoEQ
Michael @ CryptoEQ

I am a Co-Founder and Lead Analyst at CryptoEQ. Gain the market insights you need to grow your cryptocurrency portfolio. Our team's supportive and interactive approach helps you refine your crypto investing and trading strategies.


Gain the market insights you need to grow your cryptocurrency portfolio. Our team's supportive and interactive approach helps you refine your crypto investing and trading strategies.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.