How Blockchain Transactions Work — Complete Guide

In this tutorial, you'll learn about How Blockchain Transactions Work. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

What You'll Learn

Follow a Blockchain Transaction from the moment you click "Send" to when it's permanently recorded on the Blockchain.

Why It Matters

Understanding the Transaction lifecycle helps you debug failed transactions, optimize fees, and understand what's happening when you use Web3 apps.

Real-World Use

Sending ETH, swapping tokens on Uniswap, minting an NFT, or deploying a smart contract — all follow the same lifecycle.

The Transaction Lifecycle

1. Create → 2. Sign → 3. Broadcast → 4. Mempool → 5. Confirm

Step 1: Create

A Transaction contains:

{
  "from": "0xAlice",
  "to": "0xBob",
  "value": "1000000000000000000",  // 1 ETH in wei
  "gas": 21000,
  "gasPrice": "20000000000",       // 20 gwei
  "nonce": 5,                      // Alice's 6th tx
  "data": "0x"                     // Empty for simple transfer
}

Step 2: Sign

The sender signs the Transaction with their private key:

const { Web3 } = require("web3");
const web3 = new Web3();

const tx = {
  from: "0xAlice",
  to: "0xBob",
  value: web3.utils.toWei("1", "ether"),
  gas: 21000,
  gasPrice: web3.utils.toWei("20", "gwei"),
  nonce: 5,
};

// Signing produces a signature
const signedTx = await web3.eth.accounts.signTransaction(
  tx,
  "0x...private_key"
);

// Signature (r, s, v) proves Alice authorized this
console.log(signedTx.rawTransaction);

Step 3: Broadcast

The signed Transaction is sent to the network:

const txHash = await web3.eth.sendSignedTransaction(
  signedTx.rawTransaction
);

The Transaction propagates through the peer-to-peer network to reach all nodes.

Step 4: Mempool

Every node maintains a mempool — pending transactions waiting to be confirmed:

Mempool (pending transactions)
┌──────────────────────────┐
│ Tx A: Alice → Bob (20 gwei) │
│ Tx B: Carol → Dave (15 gwei)│
│ Tx C: Eve → Frank (50 gwei) │  ← Higher fee = priority
└──────────────────────────┘

Miners/validators select transactions from the mempool, prioritizing higher fees.

Step 5: Confirmation

A validator includes the Transaction in a block. After inclusion:

Block #19,500,001
├── Tx A: Alice → Bob (confirmed)
├── Tx B: Carol → Dave (confirmed)
├── Tx D: ... (confirmed)
└── Tx C: (in next block)

Confirmation Count

Failed Transactions

A Transaction can fail but still cost gas:

Transaction submitted
    ↓
Executes but reverts (e.g., out of balance)
    ↓
State changes are rolled back
    ↓
Gas is NOT refunded (validator still did work)

EIP-1559 (Type 2 Transactions)

Modern Ethereum uses EIP-1559:

Base fee (burned) + Priority fee (tip to validator)
    ↓
Base fee is algorithmically set per block
    ↓
Priority fee incentivizes validators to include your tx