Skip to main content
Cross-chain messaging is the foundation of TAC’s hybrid dApp functionality. It enables secure communication between TON users and EVM smart contracts through a structured system of message creation, validation, and execution. Understanding this messaging system helps developers build more effective applications and troubleshoot issues when they arise.
Current Network Status: The sequencer network is currently distributed but not decentralized. Full decentralization is on the roadmap as the network matures.

​
Message Lifecycle Overview

Every cross-chain operation in TAC follows a predictable lifecycle that ensures security and reliability while maintaining reasonable performance for application use cases.
Cross-chain messaging lifecycle diagram

Complete cross-chain message flow from TON user to EVM execution

Message Creation

User initiates an action in a hybrid dApp, triggering the creation of a structured cross-chain message containing operation details and asset information.

Sequencer Detection

Multiple sequencers detect the message simultaneously and begin independent validation processes to ensure message integrity.

Consensus Formation

Sequencer groups reach internal consensus, then coordinate across groups to form network-wide agreement on message validity.

Target Execution

Validated messages are executed on the target chain with cryptographic proof of consensus approval.

Result Delivery

Execution results and any return assets flow back through the same secure messaging system to the original user.

​
Message Structure

Cross-chain messages contain all the information needed for secure validation and execution across different blockchain architectures.

​
Core Message Components

Every message includes essential metadata and operation-specific data: 
{
  timestamp: 1640995200,              // TON blockchain timestamp
  target: "0x742d35Cc6473...",        // Target smart contract address
  methodName: "swapTokens(bytes,bytes)", // Method signature
  arguments: "0x1234...",             // Encoded method parameters
  caller: "EQAbc123...",              // Original TON caller address
  mintTokens: [...],                  // Tokens to mint on TAC EVM
  unlockTokens: [...]                 // Tokens to unlock from previous operations
}

​
TAC Header Information

The TON Adapter automatically augments messages with additional metadata that proxy contracts receive:
  • shardsKey: Unique identifier linking related transactions when multiple tokens are involved in a single operation.
  • timestamp: Block timestamp from the TON blockchain where the user’s original message was created.
  • operationId: Unique identifier generated by TAC infrastructure for tracking and validation purposes.
  • tvmCaller: The TON user’s wallet address that initiated the cross-chain operation.
  • extraData: Additional data provided by sequencers during execution, typically empty but available for special use cases.

​
Parameter Encoding

Application-specific parameters are encoded using standard Ethereum ABI encoding: 
// Example: DEX swap parameters
const abi = new ethers.AbiCoder();
const swapParams = abi.encode(
  ["tuple(address,address,uint256,uint256,address,uint256)"],
  [[tokenIn, tokenOut, amountIn, minAmountOut, recipient, deadline]]
);
This encoding ensures that EVM proxy contracts can decode parameters correctly while maintaining compatibility with standard Ethereum tooling.

​
Validation Process

The TON Adapter employs multiple layers of validation to ensure message integrity and prevent malicious activity.

​
Asset Verification

  • Transfer Validation: Sequencers verify that actual token transfers match the amounts specified in cross-chain messages. This prevents attempts to claim false transfer amounts or access unauthorized funds.
  • Balance Checking: User balances are validated against requested operations to ensure sufficient assets are available for the intended operation.
  • Metadata Consistency: Token information and operation parameters are cross-referenced to ensure consistency throughout the validation process.

​
Cryptographic Validation

  • Merkle Proofs
  • Consensus Signatures
  • Inclusion Proofs: Every executed message includes cryptographic proof of inclusion in a consensus-approved Merkle tree.
  • Tamper Resistance: Merkle proofs make it cryptographically impossible to modify messages after consensus without detection.
  • Independent Verification: Any party can verify message authenticity using the public Merkle proofs.

​
Epoch-Based Processing

TAC organizes message processing into time-based epochs that provide structure and predictability to cross-chain operations.

​
Epoch Structure

Deterministic Timing: Each epoch is calculated using a precise formula that ensures all sequencers work with the same time boundaries: 
EpochId = (currentTime - protocolDeployTime) / epochDuration
Processing Windows: Messages are collected and processed within specific timeframes: 
[protocolDeployTime + EpochId × epochDuration,
 protocolDeployTime + (EpochId + 1) × epochDuration]

​
Benefits of Epoch Processing

  • Ordered Processing: All sequencers process the same set of messages in each epoch, preventing timing-based attacks and ensuring consistency.
  • Batch Efficiency: Processing messages in batches is more efficient than individual handling and provides better consensus guarantees.
  • Predictable Latency: Users and applications can estimate processing times based on epoch duration and current network status.

​
Message Types and Flows

Different types of cross-chain operations follow distinct patterns that affect how messages are structured and processed.

​
One-Way Messages (TON → TAC)

  • Simple Operations: Basic token transfers, contract calls that don’t require return values, or operations where results remain on the EVM side.
  • Message Flow: TON user → TON Adapter → Sequencer validation → EVM execution → Completion notification.
  • Use Cases: Token deposits, simple contract interactions, or operations where users only need confirmation of completion.

​
Round-Trip Messages (TON → TAC → TON)

  • Complex Operations: Operations that generate results or assets that need to be returned to the original TON user.
  • Extended Flow: Includes an additional return path where EVM proxy contracts create new messages to send results back through the TON Adapter.
  • Use Cases: Token swaps, liquidity operations, or any interaction where users expect to receive different assets or data back.

​
Rollback Operations

When operations fail on the target chain, TAC automatically initiates rollback procedures to protect user assets.
  • Automatic Triggers: Failed executions on either chain automatically trigger rollback message creation to return assets safely.
  • Asset Protection: Rollback messages ensure that locked or transferred assets are returned to users when operations cannot complete successfully.
  • Special Processing: Rollback messages receive priority processing to minimize the time users wait for asset recovery.

​
Error Handling and Recovery

TAC’s messaging system includes comprehensive error handling mechanisms that protect user assets and provide clear feedback about operation status.

​
Failure Detection

Execution Monitoring: The system continuously monitors message execution on target chains and detects various types of failures. Timeout Handling: Messages that don’t complete within expected timeframes trigger automatic timeout procedures. Validation Failures: Messages that fail validation at any stage are rejected before execution to prevent resource waste.

​
Recovery Mechanisms

When transactions fail after asset transfers have occurred, the system automatically creates rollback messages to return assets to their original owners. This process uses the same consensus mechanisms as regular messages, ensuring that rollbacks are secure and verifiable.
Failed transactions are collected into special Merkle trees and processed through the consensus system to ensure proper resolution. This systematic approach prevents failed transactions from being lost or forgotten while maintaining the same security standards.
Comprehensive status reporting allows applications to detect failures quickly and provide users with clear information about what happened and what to expect. Status information includes failure reasons when available, helping users understand issues and potential resolution steps.

​
Message Security Guarantees

The cross-chain messaging system provides strong security guarantees through multiple redundant mechanisms.

​
Economic Security

  • Stake Requirements: Sequencers must stake significant collateral to participate in message validation, creating strong financial incentives for honest behavior.
  • Slashing Mechanisms: Provably incorrect behavior results in automatic collateral slashing, making attacks economically unattractive.
  • Reward Alignment: Performance-based rewards encourage reliable operation and continued network participation.

​
Technical Security

  • Consensus Thresholds: High consensus requirements (3/5 within groups, multiple groups for network consensus) make coordination attacks extremely difficult.
  • Cryptographic Verification: Merkle proofs and digital signatures provide mathematical guarantees of message integrity and authenticity.
  • Redundant Validation: Multiple independent parties validate each message, preventing single points of failure or manipulation.

​
Performance Characteristics

Understanding the performance characteristics of cross-chain messaging helps developers set appropriate expectations and design better user experiences.

Latency

  • Typical Processing Time: Most messages complete within minutes rather than hours, depending on epoch duration and network conditions.
  • Factors Affecting Speed: Epoch timing, consensus participation levels, and target chain congestion all influence processing speed.

Throughput

  • Batch Processing: The epoch-based system can handle hundreds of messages per processing window.
  • Scalability: Throughput scales with shorter epochs and increased sequencer participation.

​
Best Practices for Developers

  • Message Design
  • User Experience
  • Testing
  • Keep Parameters Simple: Complex nested structures increase encoding size and processing time. Use flat structures when possible.
  • Validate Inputs: Perform client-side validation before creating cross-chain messages to prevent obvious failures.
  • Handle Timeouts: Design applications to handle messages that take longer than expected to process.

​
What’s Next?

Understanding cross-chain messaging and fee structures provides the foundation for exploring specific operational aspects of TAC’s hybrid dApp system.

Asset Bridging

Learn how tokens and assets move securely between chains

Transaction Lifecycle

Dive deeper into the complete transaction processing flow
⌘I