eth_call vs Sending an Ethereum Transaction
Compare eth_call with transaction submission, including state changes, simulation context, gas assumptions and the limits of a successful call.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A contract read and a submitted transaction can execute similar EVM code while producing very different outcomes. eth_call asks a node to execute against a chosen state without publishing the resulting state changes.
Execution is not publication
A call can evaluate code that would change storage, but its simulated changes are not committed to the blockchain. A transaction needs authorisation, inclusion and successful execution before durable state changes exist. Both operations depend on context such as sender, value, calldata and block state; omitting these can make a simulation answer a different question.
Worked example: a changing allowance
A simulated token operation succeeds at block A because sufficient allowance exists. Another transaction consumes or changes that allowance before the submitted transaction executes at block B. The real transaction can then revert. The earlier call remains a valid observation of A, not a guarantee about B or an authorisation to submit anything.
Use simulation as evidence
Capture the call inputs and block reference. Decode return data according to the relevant ABI and treat reverts as structured failures. Never display a call result as an included transaction or confirmed payment. If a workflow later submits a transaction, track its hash, receipt and confirmation policy separately from the simulation record.
A practical acceptance test
Simulate a successful call at block A, then change the fixture state so the submitted transaction reverts at B. Assert that the earlier simulation remains labelled as a simulation and the receipt supplies the executed outcome. No payment or included-transaction record should be created from the call result alone, even when its decoded return value looks successful.
Questions about the topic
Frequently asked questions
Does eth_call spend funds?
It does not publish a transaction or commit state changes.
Does successful simulation guarantee success later?
No. State and execution context can change before inclusion.
Standards & technical documentation
