In this track: Execution traces and low-level calls
advanced · 4 MIN READ
msg.value in nested calls
Value belongs to a particular call context.
LET’S PICTURE IT
Passing a payment to one desk does not automatically pass the same payment to every later desk.
SEE IT FOR YOURSELF
A valid counter call, step by stepStep 1 / 4
This example begins with count zero and a request to call increment(). No real contract is deployed.
This example begins with count zero and a request to call increment(). No real contract is deployed.Execution follows the code’s input and permission rules. A website button is not the access-control mechanism.The function reads zero, calculates zero plus one, and writes one to persistent storage.The accepted state contains count one. Later reads can inspect it. Events are emitted only if the code implements them.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Read the current frame value
msg.value reports the Wei value associated with the current call. It is not automatically the original transaction value repeated through every nested CALL.
Specify nested transfer value
If A calls B normally with zero value, B sees msg.value zero even when the user sent ETH to A earlier in the transaction.
Distinguish delegate execution
DELEGATECALL preserves the delegating context’s msg.value without creating a new independent value transfer to the implementation address.
Avoid repeated accounting
Reusing one preserved msg.value across several delegated actions can create accounting errors if each action credits it as fresh ETH. Audit the complete batch context.
Follow the execution
User → A with 10 Wei
A → CALL B with 0 Wei
B sees msg.value = 0
A retains its own balance effects unless other code changes them.
A local conceptual trace with explicit assumptions; this is not a trace of a live transaction.
QUICK CHECK · NO PRESSURE
If A calls B with zero value, must B see the user’s earlier payment to A?