StateInit
Serialised initial state of a TON smart contract: code (cell) + data (cell) + optional fields. The hash of StateInit becomes the contract's TON address inside its workchain.
Aliases: state init, state_init, init-state
StateInit is the TON data structure describing a smart contract’s “initial state” at deploy time. The TL-B definition:
StateInit = { split_depth?, special?, code:Cell?, data:Cell?, library:HashmapE 256 SimpleLib }
In practice 99% of contracts use just two fields: code (a cell containing TVM bytecode) and data (a cell with initial storage).
Why it matters
- Contract address = workchain : SHA256(StateInit). A TON contract’s address is deterministic: knowing code + data ahead of deploy lets you know the address. No “deploy first, then learn the address” like in Ethereum (before CREATE2).
- Deploy = the first message to that address, with StateInit in the message body. The contract “winks into existence” when the first message brings the body + StateInit.
- Wallets v3/v4/v5 are all concrete StateInit templates: same
code(per version), differentdata(owner’s public key, seqno).
Practical consequence
If you know the owner’s public key and the wallet version, you mathematically know the address of their wallet — no network calls. This is the basic operation in the @ton/ton SDK:
const wallet = WalletContractV4.create({ publicKey, workchain: 0 });
console.log(wallet.address.toString()); // address of a not-yet-deployed wallet
For forensics and audits
StateInit is the canonical anchor of contract identity. Swap the code = swap the address. It’s impossible to “silently swap bytecode” at an existing address — that’s a different contract by definition. Upgradeable contracts on TON work via the SETCODE instruction, and any upgrade is visible on-chain in the transaction, not by address change.