eth_call executes a contract call against selected Ethereum state without creating a blockchain transaction. A transaction follows a separate path: it is the mechanism for initiating a network state update, requires broadcast, and must be included in a validated block. That distinction explains why a simulation result is useful evidence about a particular execution request but does not guarantee a later transaction’s success.
Understanding eth_call vs transaction means keeping three things together: the operation being evaluated, the state selected for evaluation, and what the returned result actually establishes. A successful preview should retain that context whenever it is described or compared with another result.
Execution without a committed state update
The Ethereum JSON-RPC documentation describes eth_call as executing a message call without creating a transaction on the blockchain. Execution still takes place; the method is not merely a label attached to an unevaluated request.
The distinction between execution and persistence is essential. Ethereum’s transaction documentation identifies transactions as the mechanism through which an account initiates a network state update. Combining those two premises supports a deduction: the simulated operation’s state changes are not committed to the Ethereum blockchain by eth_call.
Here, “read-only” describes the effect on persistent blockchain state. It should not be interpreted as saying that contract code cannot execute during the simulation. Even when discussing an operation intended to update stored data, the relevant question is whether that update becomes part of blockchain state.
For background on code and stored data, see our explanation of smart contract code, state, and calls. The focus here is what happens when execution is requested without committing the simulated update.
The selected block belongs with the result
An eth_call request accepts a block selector. The documented choices include an integer block number and tags such as latest, earliest, pending, safe, and finalized. The JSON-RPC documentation explains that the block parameter determines the block height for a state query.
Consequently, a useful description of a result includes the selected block context. “The call returned this value” leaves out part of the question that was asked. “The call returned this value using the stated block selector” preserves a necessary condition for interpreting the answer.
This is a deduction from the request structure, not a claim that every different selector must produce a different answer. Two evaluations can agree without making their state context irrelevant.
Also, selecting pending is not evidence that a transaction has been included in a validated block. A selector describes the requested state context; it does not turn a call into a transaction or establish transaction inclusion.
Which call details need to stay visible?
The selected state is only one part of the request. The documented call object also describes where execution is directed and what is supplied to it:
- from: an optional sender address in the call context.
- to: the address to which execution is directed.
- input: an optional field identifying the invoked method and its encoded parameters.
- value: an optional value supplied as part of the call context.
- gas: an optional execution parameter that some executions may need.
These fields should be read within the definition of eth_call. Although some parameter descriptions use transaction terminology, the method explicitly executes without creating a blockchain transaction. Supplying from therefore does not establish signing, authorization, or broadcast. Supplying value does not establish a committed transfer.
A practical reading habit follows: compare the recorded context before treating two call results as answers to the same question. Preserve the destination, input, supplied sender and value, and block selector. This does not assert that changing any one field always changes the result; it identifies the assumptions an explanation should retain. When gas is supplied, preserve it as part of the recorded call context.
A hypothetical counter: call versus transaction
Consider an invented classroom contract with a stored counter currently equal to 7. Stipulate that an operation named setEight, when executed successfully, sets that counter to 8 and returns 8. These are explicit teaching assumptions, not facts about a deployed contract.
The call branch
Suppose eth_call evaluates that operation successfully against the selected state and returns the stipulated value, 8. The returned value describes that execution. The simulated counter update remains uncommitted: the call has not changed the blockchain’s stored counter from 7 to 8.
This illustrates why the returned number and the persistent stored number must be kept separate. The fictional operation can return 8 during evaluation without that result being evidence of a committed counter update.
The transaction branch
Now consider a separate hypothetical transaction invoking the stipulated operation. Assume that it is broadcast, included in a validated block, and executed successfully. Under those assumptions, the transaction commits the counter update to 8.
The comparison is a deduction applying the documented call-versus-transaction distinction to the invented behavior. Successful execution and block inclusion are assumptions of the transaction branch. They are not consequences guaranteed by the earlier call result.
Why a successful simulation is not inclusion
The Ethereum transaction documentation explains that transactions intended to change EVM state need to be broadcast and must be included in a validated block. Those requirements concern the transaction’s network lifecycle. An eth_call result does not establish that those steps occurred.
The documented return from eth_call is the executed contract’s return data. That description does not promise that every request succeeds or supplies meaningful application data. When return data is available, its meaning still belongs to the operation and context being evaluated.
A further deduction follows from the limits already established: a successful call does not guarantee successful execution of a later transaction. The call evaluates specified context at selected state without creating a blockchain transaction; the later transaction requires separate inclusion. Those premises do not establish that its state and execution context will match the simulation.
This is an absence of a guarantee, not a prediction that a later transaction will fail. The JSON-RPC receipt description records a containing block separately from a success-or-failure status. A limited deduction follows from those separate fields: block inclusion alone does not establish successful contract execution.
A checklist for interpreting a call result
- Identify the evidence: does the record describe call execution or a separately submitted transaction?
- Keep the block selector: record the state context alongside the result.
- Preserve the call details: retain the destination, input, and any supplied sender or value. Also retain gas when supplied.
- Separate return data from persistence: a simulated result does not establish a committed update.
- Check the strength of the conclusion: call success, transaction inclusion, and successful transaction execution are distinct claims.
- State example assumptions: specify the fictional operation’s behavior and any assumed transaction success.
Use this checklist to assess explanations and recorded examples. Attribution to primary documentation supports the distinctions described here; it does not establish the safety or correctness of a particular contract.
Educational material prepared with AI assistance. The hypothetical example explains execution semantics and is not a recommendation to submit a transaction or sign a wallet request.