transactology.dev

The Science of Transactions

NETWORK: MAINNET BLOCK: 19,847,231 STATUS: SYNCED
INPUT VERIFY SIGN MERGE BROADCAST CONFIRM FINALIZE
// DOCUMENTATION

Transaction Anatomy

Every blockchain transaction follows a deterministic lifecycle: construction, signing, propagation, validation, and finalization. Understanding each phase is critical for building reliable decentralized systems.

// transaction.construct() LIVE
const tx = {
  nonce: await provider.getTransactionCount(sender),
  to: recipient,
  value: parseEther("1.0"),
  gasLimit: 21000n,
  maxFeePerGas: parseGwei("20"),
  maxPriorityFeePerGas: parseGwei("2"),
  chainId: 1
};

const signed = await wallet.signTransaction(tx);
const receipt = await provider.sendTransaction(signed);
CONSTRUCT SIGN PROPAGATE VALIDATE INCLUDE FINALIZE

Nonce Management

The nonce is a sequential counter that prevents replay attacks and ensures transaction ordering. Each account maintains its own nonce, incremented with every confirmed transaction. Incorrect nonce values cause transactions to be rejected or queued indefinitely in the mempool.

// Get pending nonce (includes mempool)
const nonce = await provider
  .getTransactionCount(addr, "pending");

// Manual nonce tracking for batches
let localNonce = nonce;
for (const op of operations) {
  await send({ ...op, nonce: localNonce++ });
}

Gas Economics

Post-EIP-1559, gas pricing uses a base fee (burned) plus priority fee (tip to validators). The base fee adjusts algorithmically based on block utilization, targeting 50% capacity. Effective gas strategies monitor base fee trends and set appropriate max fees to avoid overpaying.

// Dynamic gas estimation
const feeData = await provider.getFeeData();
const baseFee = feeData.lastBaseFeePerGas;

const tx = {
  maxFeePerGas: baseFee * 2n,
  maxPriorityFeePerGas: parseGwei("1.5"),
  // effective = min(maxFee, base + priority)
};
// TRANSACTION WALKTHROUGH

Transaction Lifecycle

01

Construction

The sender assembles the transaction object: recipient address, value, gas parameters, calldata for contract interactions, and the current nonce. The transaction type (legacy, EIP-2930, or EIP-1559) determines the field structure.

02

Signing

The transaction is RLP-encoded and hashed (keccak256). The sender's private key produces an ECDSA signature (v, r, s values). This cryptographic proof authorizes the transaction without revealing the private key.

03

Propagation

The signed transaction is broadcast to connected peers via the gossip protocol. Nodes validate basic fields and forward to their peers. Within seconds, the transaction reaches most network nodes and enters their mempools.

04

Validation & Inclusion

Block proposers select transactions from the mempool, prioritizing by effective tip. The EVM executes the transaction, modifying state. If execution succeeds, the transaction is included in the proposed block.

05

Finalization

After inclusion, the block propagates through the network. Under proof-of-stake, finality is achieved when two-thirds of validators attest to the block's epoch. Once finalized, the transaction is irreversible.

TX_CONFIRMED

transactology.dev

Decoding the science of every on-chain interaction.

0 Daily Transactions
0 Sec to Finality
0 % Uptime