TL;DR

• Goal: Bring Hyperlane’s permissionless messaging to the TON blockchain.
• Scope: Every core FunC contract, all off-chain Rust modules, full test coverage, and technical docs.
• Result: TON developers can now send messages or tokens across chains through Hyperlane, without relying on centralized bridges or additional trust assumptions.

What is Hyperlane?

Hyperlane is a permissionless interoperability protocol that allows any blockchain to communicate with any other. At its core, Hyperlane uses:

• Mailboxes: smart contracts that send and receive cross-chain messages.
• Interchain Security Modules (ISMs): customizable modules that verify messages on-chain (Merkle roots, validator sets, routing rules, etc.)
• Relayers: off-chain agents that transport messages between chains.
  
  

Hyperlane is designed to be modular, secure, and extensible, with upgradeable contracts and a flexible trust model.

Day One of TON

• Before: Zero TON code in the Hyperlane monorepo — no contracts, no integration, no off-chain logic.
  
  
• After RSquad joined: The full TON integration, including contracts, off-chain modules, and Hyperlane configuration, is now merged and active in testnet.

What RSquad Delivered

On-chain (FunC / TVM):

• Mailbox: emits and receives cross-chain messages.
• Message-ID Multisig ISM: validator-based verification.
• Merkle Tree Hook: Merkle root proof verification.
• Protocol Fee Hook: collects/forwards message delivery fees.
• Interchain Gas Paymaster: prepays gas for remote execution in TON.
• Validator Announce: broadcasts active validator set.
• Warp-Route Suite:
  
  • Token Router
  • Jetton
  • Jetton Native
  • Jetton Collateral

Off-chain Rust integration in the Hyperlane repository, including extended validator logic for TON:

• TON signer and transaction assembler.
• Extended relayer logic for TON.
• run-locally test suite for messages and token bridging.

Challenges and How We Solved Them

One of the key differences was that TON doesn’t support synchronous smart contract calls, unlike EVM-based chains. As a result, we had to redesign the entire interaction between Mailbox and ISM around asynchronous internal messaging, carefully preserving message integrity and protocol guarantees.

Another challenge was TON’s gas payment model, where contracts must carry and manage their own gas. This is in contrast to Ethereum’s approach, where the caller typically pays for execution. We adjusted the contract interaction patterns to fit TON’s model, ensuring smooth message delivery without relying on external gas logic inside the Interchain Gas Paymaster.

Data serialization was also non-trivial. While Hyperlane relies on strict 32-byte identifiers and EVM-friendly memory layouts, TON uses a cell-based binary tree structure. To ensure compatibility, we implemented serialization and deserialization logic both on-chain (in FunC) and off-chain (in Rust), enabling seamless message encoding between Hyperlane and TON formats.

Finally, replay protection required a completely different approach. In TON, external messages are not used in this integration; only internal messages are used. In addition, storage in TON is costly, and the cost of dictionary insertions increases with size, which makes Ethereum-style «message ID registries» impractical. As a result, we redesigned the replay protection mechanism from the ground up, optimizing for TON’s storage model while maintaining Hyperlane’s security guarantees.

Some Thoughts

Integrating TON with interoperability-focused protocols like those in the EVM ecosystem is a non-trivial challenge due to fundamental architectural differences, yet solutions must be found — and Hyperlane offers one of the most promising approaches, combining permissionless messaging, modular components, and cross-chain compatibility in a way that respects TON’s unique design and opens up powerful opportunities for both developers and users.