Transaction

What Is a Blockchain Transaction?

A transaction is the fundamental unit of action on a blockchain. It is a cryptographically signed data structure that instructs the network to perform a specific operation — transferring tokens, calling a smart contract function, deploying new contract code, or staking assets. Every change that happens on a blockchain originates from a transaction submitted by a user or a contract.

On Ethereum, transactions are the only way to change the state of the network. You cannot modify an account balance, update contract storage, or deploy code without submitting a transaction. Even seemingly simple operations like sending ETH from one address to another require a transaction. Understanding how transactions work is essential for anyone interacting with blockchain networks, whether you are a casual user, a DeFi participant, or a smart contract developer.

Anatomy of an Ethereum Transaction

An Ethereum transaction contains several critical fields:

to: The recipient address. This can be an externally owned account (EOA) for a simple ETH transfer, or a contract address for a smart contract interaction. If this field is empty, the transaction creates (deploys) a new smart contract.

value: The amount of ETH (in wei) to send to the recipient. For simple transfers, this is the full amount. For contract interactions, this is typically zero (the contract handles token logic separately), though some contracts accept ETH as payment.

gasLimit: The maximum amount of gas units the sender is willing to consume. Each EVM operation has a gas cost — 21,000 for a simple transfer, more for complex contract calls. If the transaction runs out of gas, it reverts but the sender still pays for the gas used.

maxFeePerGas (EIP-1559): The maximum total fee per gas unit the sender will pay (base fee + priority fee). This replaced the legacy gasPrice field.

maxPriorityFeePerGas (EIP-1559): The “tip” per gas unit that goes directly to the validator/Miner. Higher tips incentivize validators to include the transaction sooner.

nonce: A sequential counter for each account. Each transaction must have a nonce exactly one higher than the previous. This prevents replay attacks — you cannot resubmit the same transaction twice because the nonce would already be consumed.

data (or input): An arbitrary byte string carrying the payload. For contract deployments, this contains the compiled bytecode. For contract interactions, it encodes the function name and arguments (ABI-encoded). For simple ETH transfers, this is typically empty.

signature: The cryptographic proof that the sender authorized this transaction. It consists of v, r, and s values derived from the sender’s private key using the ECDSA (Elliptic Curve Digital Signature Algorithm) with the secp256k1 curve.

chainId: Identifies which network the transaction is intended for (1 for Ethereum mainnet, 5 for Goerli testnet, 137 for Polygon, etc.). This prevents cross-chain replay attacks — a transaction signed for Ethereum cannot be replayed on BSC even if you copy it.

EIP-2718: Typed Transaction Envelope

Before EIP-2718 (implemented in 2020), all Ethereum transactions used a single format. EIP-2718 introduced typed transactions, where each transaction type is identified by a one-byte prefix:

• Type 0 (0x00): Legacy transactions (the original format).
• Type 1 (0x01): Access list transactions (EIP-2930) — allow pre-specifying storage slots and addresses the transaction will access, reducing gas costs for those accesses.
• Type 2 (0x02): EIP-1559 transactions — the modern standard with maxFeePerGas and maxPriorityFeePerGas replacing the flat gasPrice.
• Type 3 (0x03): EIP-4844 blob-carrying transactions — used for rollups to post data to L1 at reduced cost through “blob” data that is not accessible from EVM execution but is committed to in the block header.

Each type has its own encoding format, but all share the common fields described above. Wallets and RPC nodes use the type byte to determine how to decode and process the transaction.

EIP-1559: Fee Market Reform

Before EIP-1559 (August 2021), Ethereum used a simple first-price auction model for transaction fees: users bid a gasPrice and the miner included transactions with the highest bids. This led to extreme fee volatility — during periods of high demand (like NFT drops or DeFi launches), users dramatically overpaid for gas because they had to guess what the market rate would be by the time their transaction was mined.

EIP-1559 introduced a base fee that is automatically set by the protocol based on network demand:

• When blocks are more than 50% full, the base fee increases for the next block (up to 12.5% per block).
• When blocks are less than 50% full, the base fee decreases (also up to 12.5% per block).

Users now specify a maxFeePerGas (the absolute maximum they are willing to pay) and a maxPriorityFeePerGas (the tip to incentivize inclusion). The actual fee per gas is: min(maxFeePerGas, baseFee + maxPriorityFeePerGas). If the base fee drops below what the user estimated, they pay less. This makes fee estimation more predictable and user-friendly.

The base fee is burned (sent to an address nobody controls), which introduces a deflationary mechanism. During periods of high network activity, significant ETH is removed from circulation. This was a deliberate design choice to make ETH a “ultrasound money” — potentially deflationary when network usage is high enough.

Transaction Lifecycle

1. Signing: The user’s wallet constructs the transaction object and signs it with their private key.
2. Submission: The signed transaction is sent to a node via RPC (eth_sendRawTransaction).
3. Propagation: The node broadcasts the transaction to its peers, who propagate it further across the network.
4. Mempool: The transaction sits in the mempool (a holding area for unconfirmed transactions) waiting for a validator to include it.
5. Inclusion: A validator selects the transaction (based on gas price and available block space) and includes it in a block.
6. Execution: The EVM executes the transaction, deducting gas and updating state.
7. Confirmation: The block containing the transaction is added to the chain, and subsequent blocks increase the confirmation count.

Transaction Types Beyond Value Transfer

Not all transactions move ETH. In fact, most transactions on Ethereum today are contract interactions:

• Token transfers: ERC-20, ERC-721, and ERC-1155 token transfers are contract calls, not native ETH transfers. The value field is zero; the token logic lives in the contract.
• DeFi operations: Swapping on Uniswap, supplying liquidity to Aave, claiming rewards, and voting in governance are all contract interactions.
• NFT mints and sales: Minting, listing, and buying NFTs involve contract calls with specific function signatures.
• Contract deployment: A transaction with an empty to field and compiled bytecode in the data field deploys a new contract.

Common Pitfalls

• Wrong nonce: If you submit a transaction with nonce 5 while your on-chain nonce is 4, the transaction will be rejected. This commonly happens when a previous transaction is still pending.
• Insufficient gas: Setting the gasLimit too low will cause the transaction to revert (and you still pay for the gas consumed before the revert).
• Stuck transactions: On legacy networks, submitting a replacement transaction with the same nonce but higher gas fee can “speed up” a stuck transaction.
• Data field misuse: Always check the data field when signing a transaction — it reveals exactly what contract function you are calling and with what parameters. Malicious frontends can sneak in unauthorized calls.
• Front-running: Because transactions are visible in the mempool before inclusion, MEV (Maximal Extractable Value) bots can see your trade and submit their own transaction ahead of yours to profit from the price impact.