Trustless

Interaction between TON and Tycho is fully trustless. No relayers, multisigs, or trusted oracles are required.

A transaction is submitted to a smart contract on the receiving chain. The contract verifies cryptographic proofs and confirms that the transaction was actually executed in the source network.

This works in both directions:

• Tycho can verify events from TON

• TON can verify events from Tycho

The mechanism is possible because both systems share:

• a compatible data structure model (cells and TL-B)

• the same verification logic: reconstructing a proof chain from a transaction to a finalized block

• Merkle proofs combined with validator signatures verified by weight threshold

---

Data Required to Verify a Transaction

To verify a TON transaction inside Tycho, the contract needs two independent groups of data:

1. Validator set data

2. Transaction proof data

---

Validator Set Data

To understand what must be verified, we first need to understand how validator rotation works in TON.

TON has a masterchain. Every masterchain block is signed by the validators of the current validator set.

When the validator set changes, a key block is produced in the masterchain. This key block contains the new validator configuration, including:

• validator public keys

• validator weights

Importantly:

The key block itself is signed by the previous validator set.

This cryptographically anchors the new configuration to already finalized history.

---

Validator State Stored in App-Specific Chain

On the app-specific side, the contract maintains a chain of data derived from key blocks. It stores information about:

• the current validator epoch

• several previous epochs

This allows the contract to reconstruct which validator set was active for any master block whose signatures must be checked.

---

Data Imported From a Key Block

When a new key block appears, it is submitted to the app-specific chain as a verification package that updates the local validator state.

The package includes:

• a Merkle proof of the key block cell

• the file_hash (provided separately)

• validator signatures of the key block

The entire block is not required.

Only necessary fields are transmitted. All other parts are replaced with pruned cells.

Transferred fields:

• seq_no — master block sequence number

• gen_utime — generation time

• prev_key_block — reference to the previous key block

• validator configuration from config parameters 34 (and 32 when needed)

All remaining data is pruned.

---

Key Block Verification

The app-specific chain contract then performs:

1. Verifies that the block is indeed a key block

2. Extracts the block root_hash from the Merkle proof

3. Verifies validator signatures using:

   • root_hash

   • file_hash

   • submitted signatures

The signatures are checked against the validator set that was active when the key block was produced.

If verification succeeds, the contract extracts configuration parameters 32 and 34 from McBlockExtra and updates the validator state.

---

What App-Specific Chain Stores After Verification

Only the data necessary for future block verification is kept:

• epoch_id — validator set activation time

• the validity period of the validator set

• list of validators (public keys + weights) in contract-friendly format

• total weight threshold required to finalize a block

---

Transaction Proof Data

To verify a transaction, a proof package must link the transaction to a master block signed by validators and contain data necessary to locate the transaction inside the block.

check_transaction#ddab5b88
  proof_chain:^(MERKLE_PROOF ProofChainRoot)
  tx_proof:^TransactionProof
= InternalMsgBody;

---

Proof Chain

The proof chain cryptographically connects the transaction to a finalized masterchain block.

It contains:

• epoch_id of the master block (to select the correct validator set)

• file_hash of the master block

• the masterchain block itself

• validator signatures

• a shard block (if the transaction originated from a shardchain)

• intermediate shard blocks when necessary

proof_chain_root#_ {n:#}
  file_hash:uint256
  epoch_id:uint32
  mc_block:^Cell
  signatures:^(Hashmap 16 bits512)
  head:(ProofChainHead ~n)
= ProofChainRoot;

---

Shard Block Linking

If the masterchain references the shard block indirectly, a chain of shard blocks is provided:

proof_chain_head_empty#_ = ProofChainHead ~0;
proof_chain_head_1#_ sc_block1:^Cell = ProofChainHead ~1;
proof_chain_head_2#_ {n:#} sc_block1:^Cell tail:^(ProofChainTail ~n) = ProofChainHead ~2;

This allows the contract to deterministically reconstruct the path:

transaction → shard block → master block → validator signatures

---

Why This Is Trustless

The receiving contract independently verifies:

1. validator set correctness

2. block finality

3. transaction inclusion

No external party is trusted.

Security relies solely on:

• TON consensus

• validator signatures

• Merkle proofs

Therefore, Tycho does not assume that a transaction happened in TON — it cryptographically proves it.