Cell Hash

Cell Hash is the 256-bit (32-byte) identifier of a cell in TON. It’s computed as a hash of the cell’s contents plus the hashes of all its child cells. As a result the cell hash uniquely identifies the entire tree hanging beneath it.

How it’s computed

The algorithm is essentially SHA-256, but with a TON-specific input layout:

1. Take the cell’s body bits.
2. Append the 32-byte hashes of every child cell.
3. Append metadata: depth, flags, type (ordinary or exotic).
4. Run SHA-256 over the combined input.

Change any bit in any descendant cell and the root hash changes. That’s the standard Merkle-tree property, and it’s what makes a TON cell tree cryptographically verifiable.

Where it’s used

• Contract address. Part of a TON address is the cell hash of the contract’s initial state (code + data). So an address is known before deployment — it depends only on the code and initial data.
• Cell identity inside a block. Transactions and messages reference each other by hash.
• Proofs. A pruned cell carries the hash of the pruned branch, allowing a client to verify the root hash of the tree.

In practice

SDKs expose cell.hash() returning a Buffer or hex string. Contract code uses cell_hash(c) which returns a 256-bit int.

A subtle benefit

In TON, two cells with identical content (bits and sub-trees) have identical hashes. That means the network automatically deduplicates identical cells at the storage layer — two contracts with the same code share one physical copy of that code. It’s a real optimisation: thousands of users’ jetton-wallet contracts share a single code cell in network state.