Understanding Different Types of Blockchain Transactions with Covalent

What are blockchain transactions?

Transactions are signed messages recorded on blockchains. Each block within a blockchain contains a bunch of transactions. If you want to make a transaction on a blockchain, for example, sending a payment to someone you know, you can’t just write down a transaction in a block - you need an entity called an account to do it for you. So, you give the account a message, which is signed to show that it's from you.

This message could either be a payment or a request to run some sort of program on the blockchain. Ethereum and other virtual machines are like computers that can run programs like this, while other blockchains like Bitcoin can only handle payments.

The Ethereum blockchain keeps track of all the accounts and their balances in something called the state. Sending a transaction is the only way to trigger the change of state of an account.

There are two main types of accounts involved in transactions:

1. Externally Owned Accounts (EOA). These are accounts controlled by human users through public and private keys. The public key is the identifier of the account. Transactions are signed by the private key to prove ownership of the EOA. An EOA can be thought of as an individual’s bank account that can be used to send funds using password verification.

2. Contract Accounts. These are accounts containing code and identified by a public key. The code is commonly referred to as a smart contract and is an automated program that runs when it receives a transaction from another EOA or contract account.

Any transaction ultimately originates from an EOA. Contract accounts do not execute on their own.

Different ways that transactions can occur

1. Between EOAs directly. This is usually a payment transaction between EOAs involving the transfer of a blockchain’s native token (e.g. ETH on Ethereum) without any smart contracts involved. These types of transactions are referred to as external transactions.

2. Between EOAs and Contract Accounts. These transactions are initiated by the EOA and invoke some smart contract function calls. For example, the transfer of an ERC20 token or an NFT first involves a call by the EOA to the approval function of the token contract and, if successful, a subsequent call to the transfer function.

3. Between Contract Accounts. These transactions are referred to as internal transactions. A smart contract calls a function on another smart contract, which can trigger the transfer of tokens or the execution of some other logic.

Here is an analogy:

Finally, there are transactions that can be transmitted across blockchain networks, such as between an L1 (Ethereum) and a L2 (Arbitrum) blockchain. In the context of our country analogy, these transactions are like cross-border payments involving various fees, exchange rates, and other factors that can impact the speed and cost of the transaction.

Examples

EOA to EOA:

Alice sends 0.15 ETH to Bob's Ethereum address.

When Alice goes to Etherscan to view her transaction, she can see the value of ETH sent from her address to Bob’s wallet and the timestamp, transaction hash, and fees she paid.

EOA and Smart Contract:

Alice approves a smart contract to spend 100 USDT on her behalf.

To initiate a transaction with a smart contract that involves the transfer of tokens, Alice must first approve the smart contract to spend a specific amount of tokens on her behalf. This is done by sending a message to the smart contract that specifies which function Alice wants it to call; in this case, it’s an “approve” function. The message also determines the number of tokens the smart contract can spend. This data is formatted as a hexadecimal string and is included in the "data" field of the transaction.

This is what Alice sees on Etherscan when the approval is successful.

Smart Contract to Smart Contract:

A decentralized exchange smart contract swaps some USDT for some FWB.

Alice makes a swap on Uniswap and sees this on Etherscan once the transaction is completed.

She doesn’t see that behind the scenes, 16 internal transactions took place between contracts to complete the swap. These are all triggered by a "multicall" method to execute her transaction.

What is transaction history useful for?

Transaction history is a critical analytics element of many blockchain-based applications across Web3. Here are a few common examples of where transaction history is used:

1. Decentralized exchanges (DEXs): DEXs are platforms for trading cryptocurrencies and other digital assets without intermediaries. Transaction history is a crucial component of DEXs, providing a transparent and reliable record of all trades on the platform. This enables users to track their trading history, review past transactions, and analyze market trends to inform future dealings.

2. Web3 wallets: Transaction history is a crucial component of Web3 wallets, as it enables users to track their asset balances, review past transactions, and monitor the status of pending transactions. This information is essential for managing digital assets effectively and securely.

3. DeFi tax tools: These tools use transaction history to identify and categorize transactions, calculate capital gains or losses, and generate tax reports to file taxes. Transaction history is a critical component of DeFi tax tools, providing the necessary information to ensure accurate and compliant tax reporting.

4. NFT marketplaces: In marketplaces where people are buying, selling, and trading NFTs, transaction history is an essential component as it enables users to review past transactions, track the ownership history and/or royalties of NFTs, and ensure the authenticity and provenance of NFTs they are interested in purchasing.

Challenges with accessing transaction data

One of the main challenges in getting transaction data from the blockchain is that the decentralized nature of the blockchain means that not every contract follows the same rules. Transactions can be either native or non-native, and non-native transactions involving smart contracts such as ERC-20 and ERC-721 emit log events containing additional information about the transaction. These log events may contain information about multiple wallets or contracts involved in the transaction, making it difficult to determine all the transactions in a particular wallet.

The hierarchical structure of a transaction, with its various involved parties, makes extracting all the relevant information challenging. There are five different places to look for the wallet address when trying to determine whether or not the wallet was involved in a transaction: the transaction sender, the transaction receiver, any log emitters, and log topics and data. In addition, log events may contain additional wallet addresses, further complicating the process of identifying all the wallets involved in a transaction.

To address these challenges, the Covalent’s transactions endpoints cover all five bases for any wallet address and include rich decoded transaction logs to extract as much relevant information as possible.

Summary

In summary, transactions on the blockchain occur between two entities: externally owned addresses (EOAs) and smart contracts. EOAs are user-controlled accounts identified by a unique public key on the blockchain, and smart contracts are self-executing programs stored on the blockchain. Transactions can occur between EOAs, between EOAs and smart contracts, or between smart contracts. The lack of standardization in decentralized finance and the hierarchical structure of transactions makes retrieving complete on-chain transaction data challenging. However, Covalent provides a way to do this. Overall, transaction history is a critical component of many blockchain-based applications providing transparency, accountability, and security for users interacting in Web3.