Cross-Chain Messaging
How messages flow securely between TON and TAC EVM through the TON Adapter’s validation and consensus system
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.
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:
TAC Header Information
The TON Adapter automatically augments messages with additional metadata that proxy contracts receive:
TAC Header Fields
TAC Header Fields
-
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:
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
- 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.
- 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.
- Multi-Group Agreement: Messages require agreement from multiple independent sequencer groups before execution.
- Economic Security: Sequencer groups stake significant collateral, creating financial incentives for honest validation.
- Threshold Requirements: The network requires sufficient group participation to ensure security while maintaining operational efficiency.
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:
Processing Windows: Messages are collected and processed within specific timeframes:
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
Automatic Rollback
Automatic Rollback
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 Transaction Collection
Failed Transaction Collection
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.
Status Reporting
Status Reporting
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
- 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.
- 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.
- Set Expectations: Inform users that cross-chain operations take longer than single-chain transactions.
- Provide Status Updates: Use the operation tracking tools to keep users informed about message progress.
- Handle Failures Gracefully: Implement proper error handling that explains what happened and what users should expect.
- Test Failure Scenarios: Ensure your application handles various failure modes appropriately.
- Validate Rollbacks: Confirm that failed operations properly return assets to users.
- Monitor Performance: Track message processing times and success rates in your applications.
What’s Next?
Understanding cross-chain messaging and fee structures provides the foundation for exploring specific operational aspects of TAC’s hybrid dApp system.