In this track: Execution traces and low-level calls
advanced · 4 MIN READ
Init code versus runtime code
Deployment instructions and installed instructions have different jobs.
LET’S PICTURE IT
A shop’s setup checklist differs from its daily operating manual.
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.
Run setup once
Init code executes during creation and can establish initial state. It can include constructor logic and access to encoded constructor arguments.
Return the installed program
The bytes returned by successful init execution become the runtime code used for later ordinary calls. The init code itself is not necessarily retained as runtime.
Do not decode creation as a normal call
Constructor arguments do not begin behind an ordinary function selector. Recovering them requires the correct creation-code boundary and constructor schema.
Compare the correct artifact
Source verification, address prediction and runtime inspection use related but different byte artifacts. Label which artifact is being hashed or compared at every step.
Follow the execution
Creation input = init program + constructor arguments
Init execution → returned runtime
Later call → runtime executes
A local conceptual trace with explicit assumptions; this is not a trace of a live transaction.
QUICK CHECK · NO PRESSURE
What bytes become ordinary deployed code after successful creation?