Ethereum Basics: Transactions and Messages

Ethereum is more than just a cryptocurrency—it’s a decentralized platform that enables smart contracts and decentralized applications (dApps). At the heart of its functionality lie two fundamental concepts: transactions and messages. While they may appear similar in structure, their roles, origins, and impacts on the network are fundamentally different.

Understanding these concepts is essential for developers, investors, and users alike. This guide dives deep into what transactions and messages are, how they differ, and why they matter in the Ethereum ecosystem.

What Is a Transaction?

A transaction in Ethereum is a signed data packet created by an external actor—typically a user with a private key. It represents an intent to perform an action on the blockchain, such as transferring ETH or interacting with a smart contract.

Once broadcasted to the network, transactions are validated by miners (or validators in Proof-of-Stake) and, if valid, included in a block. Once confirmed, they become a permanent part of the blockchain ledger.

There are two main types of Ethereum transactions:

1. Value Transfer Transactions – Sending ETH from one account to another.
2. Contract Creation or Execution Transactions – Deploying a new smart contract or triggering functions within an existing one.

Key Components of an Ethereum Transaction

According to the Ethereum Yellow Paper, every transaction includes the following fields:

• Nonce: A sequential counter that prevents replay attacks. Each transaction from an account must have a unique nonce.
• Gas Price: The amount of Ether (in wei) the sender is willing to pay per unit of gas.
• Gas Limit: The maximum amount of gas the sender allows for the transaction execution.
• To: The recipient’s address. If empty, this indicates a contract creation transaction.
• Value: The amount of Ether (in wei) being sent.
• Data: Optional field used to pass input data—critical when calling functions in smart contracts.
• v, r, s: Cryptographic signatures that authenticate the sender and ensure transaction integrity.

👉 Discover how Ethereum transactions power real-world dApps today.

When creating a contract, additional components like initialization code (init) may be included in the data field. This code runs once during deployment and defines the initial state of the contract.

What Is a Message?

Unlike transactions, messages are not stored on the blockchain. They are virtual, transient objects generated internally by smart contracts during execution.

Think of a message as a function call within Ethereum’s execution environment—the Ethereum Virtual Machine (EVM). When one contract needs to interact with another—such as querying data or transferring funds—it sends a message.

Messages resemble transactions in structure but differ in origin and permanence:

• Origin: Created by contracts, not external actors.
• Storage: Never recorded on-chain; exist only during runtime.
• Purpose: Facilitate inter-contract communication and logic execution.

Structure of a Message

A message typically contains:

• Sender (from): The address initiating the message (usually a contract).
• Recipient (to): The target account or contract.
• Value: Optional Ether transfer in wei.
• Data: Input parameters for function calls.
• STARTGAS: The maximum gas available for the message execution.
• GASPRICE: Inherited from the originating transaction.

Because messages aren’t signed by private keys and don’t originate externally, they cannot independently affect the blockchain state. Their execution depends entirely on an initial transaction.

Understanding Message Calls

The term message call refers to the actual act of sending a message from one account to another. If the destination has associated EVM code (i.e., it’s a smart contract), the EVM executes the code using the message as input.

Key characteristics of message calls:

• They can return data to the caller.
• They are limited by gas—exceeding it results in reversal.
• They do not require mining since they occur within a transaction’s execution scope.
• They are read-only if initiated via .call() or similar methods without state changes.

Message calls enable complex interactions between contracts—such as decentralized finance (DeFi) protocols calling price oracles, or NFT marketplaces verifying ownership before sales.

Key Differences: Transaction vs Message vs Message Call

(Note: Table removed per instructions)

Instead, here's a structured comparison:

Origin

• Transaction: Initiated by an externally owned account (EOA), requiring a digital signature.
• Message: Generated by a smart contract during execution.
• Message Call: The process of delivering a message from one account to another.

Persistence

• Only transactions are permanently recorded on the blockchain.
• Messages and message calls exist only during execution and leave no direct trace—though their effects (like balance changes) are recorded.

Cost & Execution

• Transactions consume gas paid by the sender.
• Messages inherit gas from the parent transaction; if gas runs out, all changes revert.

Use Cases

• Use transactions to initiate actions: send ETH, deploy contracts, trigger state changes.
• Use messages for internal logic: contract-to-contract data exchange.
• Use message calls to simulate behavior or read data without committing changes.

Does Calling a Contract Function Create a Transaction or Message?

This depends entirely on how and who initiates the call.

Let’s examine four common scenarios:

1. Direct call via .call() from EOA
   → Results in a message call, but no transaction is created because no state change occurs.
2. Using sendTransaction to call function
   → Creates a full transaction, as it alters blockchain state and requires gas payment.
3. Contract calling another contract via .call()
   → Generates an internal message, not a transaction. Entirely virtual and temporary.
4. Contract using sendTransaction internally
   → Not possible. Only externally owned accounts can sign transactions. Contracts cannot generate standalone transactions—they can only send messages.

✅ Bottom line: Only externally signed actions create transactions. All internal interactions between contracts are messages or message calls.

👉 See how developers use message calls to build secure DeFi protocols.

Why These Distinctions Matter

Understanding the difference between transactions and messages is crucial for:

• Smart Contract Security: Preventing reentrancy attacks (e.g., exploited in The DAO hack) requires knowing when messages execute and how gas limits affect them.
• Gas Optimization: Unnecessary message calls increase gas costs—efficient design minimizes them.
• Debugging dApps: Knowing whether an action triggers a transaction or message helps trace execution flow.
• Frontend Development: Web3 apps must distinguish between call (read-only) and sendTransaction (state-changing) methods.

For example, MetaMask prompts users only for sendTransaction actions because they require signatures and cost gas—while call operations happen instantly and freely.

Frequently Asked Questions (FAQ)

Q1: Can a message become a transaction?

No. Messages are internal and ephemeral—they result from contract logic and cannot evolve into transactions. Only externally signed data can be a transaction.

Q2: Are messages visible on Etherscan?

Not directly. While messages themselves aren’t stored, their effects (e.g., token transfers) appear in transaction traces. Tools like Tenderly or Etherscan’s “Internal Transactions” tab can help inspect them.

Q3: Do messages cost gas?

Yes—but indirectly. Messages consume gas from the original transaction’s allocated limit. If gas runs out during a message call, execution halts and reverts.

Q4: What happens if a message fails?

The EVM stops processing and rolls back any state changes made during that call—unless handled with low-level functions like .call(), which return false instead of reverting.

Q5: Is every transaction processed immediately?

No. Transactions enter the mempool first and wait for miners/validators to include them in a block. High network congestion may delay processing—especially for low-gas-price transactions.

Q6: Can contracts initiate transactions?

No. Contracts can only respond to incoming transactions by sending messages. Autonomous behavior requires external triggers—often via keepers or oracles.

👉 Learn how OKX Web3 tools help track transactions and messages seamlessly.

Core Keywords

This article integrates the following SEO-focused keywords naturally throughout:

• Ethereum transactions
• Ethereum messages
• Message call
• Smart contract interaction
• EVM execution
• Blockchain communication
• Gas limit
• Nonce

These terms align with common search intents related to Ethereum development, dApp debugging, and blockchain mechanics.

By mastering transactions and messages, you gain deeper insight into how Ethereum truly works under the hood—empowering better development, investment, and usage decisions in the Web3 space.