Coming from TON

This document briefly highlights how Tetra differs from TON blockchain and what matters for TON developers.

TetraChain is compatible with TON at the TVM level and uses the same asynchronous message model. From a user's perspective, using TetraChain feels the same as using the TON network.

Main differences

• TON is the gas token in TetraChain. To get TON in TetraChain, you need to transfer it from the TON blockchain.

• TetraChain uses a signature domain to protect against cross-network replay attacks. This changes what CHKSIGNU and CHKSIGNS opcodes actually verify.

• TetraChain modifies the block format and some network configuration parameters. This typically does not affect user experience, but it affects block parsing and indexers.

Assets

Since the gas token in TetraChain is TON, the basic way to get started is to move TON from the TON network into TetraChain.

The interaction model between TON and TetraChain is built around trustless event verification in a smart contract on the receiving side. The receiving contract verifies a proof chain and validator signatures, and then can safely accept the event from the source network. This works in both directions. See:

Trustless

In practice, this means:

1. To get TON in TetraChain, use the deposit flow from TON to TetraChain.

2. To move TON back to TON, use the withdrawal flow from TetraChain to TON.

3. For user interfaces and transfer tooling, you can reuse the existing implementations:

Moving Tokens TON ↔ Tetra

Developers

For developers, moving from TON to TetraChain most often looks like switching to another network with the same TVM and the same message primitives.

What to pay attention to:

• Signatures: Tetra adds network context to the data being verified by default. This is usually implemented at the VM level and does not require contract changes, but your offchain signer must produce signatures in the same global_id context as the Tetra network. If signatures are created without a signature domain, contract verification may start returning false. See:

Signature & Message Restrictions

• BLS: BLS_* opcodes available in TON are not implemented in Tetra. If you depend on BLS at the TVM level, you will need a different design. See:

TVM on Tetra

• Indexers and block parsing: a parser that expects the exact TON schemas from block.tlb will not be able to decode Tetra blocks correctly. For Tetra see difference:

Block Structure

• Tooling: many SDKs and tools you already use for TON work in TetraChain in the same way. For a detailed list, see

SDKs & Libraries