Skip to main content
T TON Adoption
← Glossary
NODE/03 · Term

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), different data (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.

Related terms