Skip to main content

Cell & Bag of Cells(BoC)


A cell represents a data structure on TON Blockchain. Cells are able to store up to 1023 bits and possess up to 4 references to other cells.

Bag of Cells

Bag of Cells (BoC) is a format for serializing cells into byte arrays, which is further described in the TL-B schema.

On TON, everything consists of cells, including contract code, stored data, blocks, achieving streamline and robust flexibility in the process.

Cell serialization

Let's analyze our first example of a Bag of Cells :

1[8_] -> {
7[FE] -> {

In this example we have a 1-bit size root cell that has 2 links: the first to a 24-bit cell and the second to a 7-bit cell which possesses 1 link to a 24-bit cell.

For this framework to work as intended, it’s necessary to turn the cells into a single sequence of bytes. To accomplish this, first, we leverage only unique cell types, below 3 out of 4 are presented as follows:


Now let's arrange them in such an order that the parent cells do not point backwards. The cell pointed to by the rest must be in the list after the ones that point to it. We get:

1[8_]      -> index 0 (root cell)
7[FE] -> index 1
24[0AAAAA] -> index 2

Now, let's calculate descriptions for each of the 3 cells touched on above. These descriptions are made up of 2 bytes that store flags composed of information about the length of the data and the number of data linkages.

The flags are omitted in the current parse and almost always possess a value of 0. The first byte contains 5 flag bits and 3 link count bits. The second byte is the length of the full 4-bit groups (but at least 1 if it isn’t empty). The result is:

1[8_]      -> 0201 -> 2 links, length 1 
7[FE] -> 0101 -> 1 link, length 1
24[0AAAAA] -> 0006 -> 0 links, length 6

For data with incomplete 4-bit groups, 1 bit is added to the end of the sequence. This means it denotes the end bit of the group and is used to determine the true size of incomplete groups. Let's add the bits below:

1[8_]      -> C0     -> 0b10000000->0b11000000
7[FE] -> FF -> 0b11111110->0b11111111
24[0AAAAA] -> 0AAAAA -> do not change (full groups)

Now let's add the link indexes:

0 1[8_]      -> 0201 -> refers to 2 cells with such indexes
1 7[FE] -> 02 -> refers to cells with index 2
2 24[0AAAAA] -> no links

And put it all together:

0201 C0     0201  
0101 AA 02
0006 0AAAAA

And concat it by joining the corresponding strings into a single array of bytes: 0201c002010101ff0200060aaaaa, size 14 bytes.

Show example
func (c *Cell) descriptors() []byte {
ceilBytes := c.bitsSz / 8
if c.bitsSz%8 ! = 0 {

// calc size
ln := ceilBytes + c.bitsSz/8

specBit := byte(0)
if c.special {
specBit = 8

return []byte{byte(len(c.refs)) + specBit + c.level*32, byte(ln)}


Packing a Bag of Cells

Let's pack the cell from the section directly above. We have already serialized it into a flat 14 byte array.

Therefore, we build the header according to its schema.

b5ee9c72                      -> id tl-b of the BoC structure
01 -> flags and size:(## 3), in our case the flags are all 0,
and the number of bytes needed to store the number of cells is 1.
we get - 0b0_0_0_00_001
01 -> number of bytes to store the size of the serialized cells
03 -> number of cells, 1 byte (defined by 3 bits size:(## 3), equal to 3.
01 -> number of root cells - 1
00 -> absent, always 0 (in current implementations)
0e -> size of serialized cells, 1 byte (size defined above), equal to 14
00 -> root cell index, size 1 (determined by 3 size:(## 3) bits from header),
always 0
0201c002010101ff0200060aaaaa -> serialized cells

Next, we concat everything above into an array of bytes into our final BoC: b5ee9c7201010301000e000201c002010101ff0200060aaaaa

Bag of Cells Implementation Examples: Serialization, Deserialization

Special cells

Generally, cells operating on TON are divided into two main types: ordinary cells and special cells. Most of the cells that the users work with are ordinary cells responsible for carrying information.

Nevertheless, to realize internal functionality of the network, special cells are sometimes needed and are used for a diverse range of purposes, depending on their subtype.

Special cell subtypes are determined by the first 8 bits that form their data structures. The main subtype variations include:

0x01: PrunnedBranch
0x02: Library
0x03: MerkleProof
0x04: MerkleUpdate

Merkle Proof

Merkle Proof cells are actually a hash tree that is used to cryptographically verify (via the merkle proof) that a portion of the cell tree data belongs to the full tree. This design often prevents the verifier from knowing the full contents of the tree, while only revealing its root hash.

Within itself, a cell carries the root hash of an object (for example, a block) and a hash tree of its branches as a child cell. The internal tree itself repeats the structure of the original object (by cryptographically proving its integrity), but at the same time, all branches that are not part of the data and don’t need verification and don’t lead to it are replaced by special PrunnedBranch cells, which instead of storing data, store the cell’s individualized hash.

Therefore, having calculated the root hash of the entire tree, the same hash should be derived from the root cell data of the merkle proof, which should match the hash known to us in advance (e.g., the hash of a block). This approach allows us to prove, for example, the existence of a transaction in a block, provided that the party knows the hash of the block in the first place.

Proof example for getAccountState

The getAccountState is a proof used to verify the integrity of the ShardStateUnsplit structure. But instead of the whole block, the getAccountState proof contains only the requested account: EQCVRJ-RqeZWcDqgTzzcxUIrChFYs0SyKGUvye9kGOuEWndQ.

All branches that are not related to or leading to the getAccountState are replaced with a PrunnedBranch, and those leading to it are Ordinary cells and contain the actual block data.

The symbol * denotes a special cell, the root which uses the 0x03 denotes a MerkleProof, while the 0x01 denotes a PrunedBranch.

Show example
280[03E42E9D59FE3B0900D185EA76AA5F64C6FA0F0C723FFD3CCA5F22B21354064C540219]* -> {
362[9023AFE2FFFFFF110000000000000000000000000001E9AA7F0000000163C1322C00001F522060E3C10194CD420_] -> {
75[8209C398C55C7BDDF32_] -> {
76[0104E1CC62AE3DEEF99_] -> {
76[0101A1AB8F37E15D045_] -> {
76[01010A762B5E3DB9BB3_] -> {
76[01007896888C1BF9AFF_] -> {
68[00F45169A7CA17BB3_] -> {
68[00E1E486CCD6F2D24_] -> {
68[00E17E05DDDEF5882_] -> {
68[00E0EEBE3D59F5624_] -> {
68[00E0B73C712EA7A3C_] -> {
68[00E026EB80E87B804_] -> {
68[00E023322BD069152_] -> {
68[00E0220B791895CE8_] -> {
68[00E0208438C7659B4_] -> {
68[00E0201CBDC2FA57E_] -> {
60[00C047CA5AA50C4_] -> {
52[00BD53FE01932_] -> {
52[00A0AC70E85E2_] -> {
44[00894655318_] -> {
44[0087FCFA2A6_] -> {
44[00805E35524_] -> {
53[E0A04027728E60] -> {
570[B991A9E656703AA04F3CDCC5422B0A1158B344B228652FC9EF6418EB845A001C09B2869397E6EAB3E5EC55401625FB84ED36424BB6EB0F344BC13953F74CC340000716D4326F30C_] -> {
868[0000000000000000FFFFFFFFFFFFFFFF8270E631571EF77CCBBA0EF6D39D6343100001F5220425F440194CD434074F1CF0713270443B84FEA5C35142771F8C6895A2B36117743862354F4EBE767D25641E7D9D005816619EB807E1C18C943B86598038ADD33B65980DCB14EF2_] -> {


Here a link to the original article by Oleg Baranov.