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: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: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
- 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.