The Sequencer Network is the operational backbone of the TON Adapter, consisting of distributed nodes that collect, validate, and reach consensus on cross-chain messages. These sequencers ensure that messages between TON and TAC EVM are processed securely and reliably through a multi-layered validation system.
Current Network Status: The sequencer network is currently distributed but not decentralized. Full decentralization is on the roadmap as the network matures.

​
Core Functions

Sequencers perform several critical functions that enable secure cross-chain communication:
  • Transaction Collection: Sequencers continuously monitor both TON and TAC EVM chains for relevant events. When users initiate cross-chain operations, sequencers detect these events and store them in local databases for processing.
  • Data Validation: Before participating in consensus, each sequencer validates transaction data locally. This includes verifying that asset transfers match message parameters and ensuring users have sufficient balances for requested operations.
  • Merkle Tree Formation: At regular intervals determined by network parameters, sequencers compile validated transactions into Merkle trees. These trees provide cryptographic proof of transaction inclusion and enable efficient consensus.
  • Consensus Participation: Sequencers work together in groups to reach agreement on transaction validity, with each group requiring 3/5 internal consensus before submitting to the broader network.

​
Sequencer Groups

The network organizes individual sequencers into groups to enhance security through redundancy and distributed validation.
Sequencer network group structure

Sequencer groups working together to validate cross-chain messages

​
Group Formation and Management

  • Approval Process: Sequencer groups are not permissionless - they require approval through DAO voting or multisig processes. This ensures that only trusted entities with proper infrastructure and incentives can participate in securing cross-chain messages.
  • Group Composition: Each group contains multiple sequencer nodes owned by a specific entity. This could be a trusted dApp, infrastructure provider, or other stakeholder with strong incentives to maintain network security.
  • Internal Operations: Within each group, sequencers operate independently but must coordinate to reach consensus. This internal redundancy protects against individual node failures while maintaining group-level reliability.

​
Economic Requirements

​
Consensus Mechanism

The sequencer network achieves consensus through a multi-layer validation process that ensures security while maintaining operational efficiency.

​
Network-Level Consensus

  • Cross-Group Validation: For a Merkle tree to be accepted by the network, multiple independent groups must submit identical trees. This requirement prevents any single group from manipulating the message flow or processing incorrect transactions.
  • Consensus Threshold: The network requires agreement from enough groups to ensure security. This threshold is configurable through DAO governance to balance security requirements with operational efficiency.
  • Tree Application: Only when sufficient groups submit matching trees does the CrossChainLayer smart contract accept the tree for transaction execution.

​
Transaction Processing Flow

Event Detection

Sequencers monitor both TON and TAC EVM chains for cross-chain events. When a user initiates a transaction, multiple sequencers detect it simultaneously and begin validation processes.

Local Validation

Each sequencer validates the transaction locally, checking asset transfers, user balances, and message parameters. Only valid transactions proceed to the next stage.

Database Storage

Validated transactions are stored in each sequencer’s local database, creating a distributed record of all cross-chain activity during the current epoch.

Merkle Tree Creation

At the end of each epoch, sequencers compile their validated transactions into Merkle trees and submit root hashes to their respective SequencerGroup contracts.

Group Consensus

Groups work to reach 3/5 internal agreement on their Merkle trees. Successfully agreed-upon trees are submitted to the network for cross-group validation.

Network Consensus

Multiple groups must submit identical trees for network acceptance. Once sufficient groups agree, the tree becomes eligible for execution.

Transaction Execution

Validated transactions are executed on the target chain using cryptographic proofs from the consensus-approved Merkle trees.

​
Economic Security Model

The sequencer network’s security relies on economic incentives that align participant behavior with network health.

​
Reward Structure

  • Stake-Based Selection: Executors are chosen for specific transactions based on their collateral amounts. Higher stake increases the probability of selection and larger potential rewards.
  • Proportional Distribution: At the end of each execution round, rewards are distributed proportionally to sequencer stakes, regardless of who actually performed the execution.
  • Performance Incentives: This system incentivizes sequencers to maintain higher collateral commitments while ensuring rewards are fairly distributed based on economic contribution.

​
Penalty Mechanisms

The network includes robust penalty systems to discourage malicious behavior and maintain security standards.
  • Penalty Applications: Other sequencer groups can submit penalty applications to the Penalty smart contract when they detect incorrect behavior or invalid proofs.
  • Collateral Locking: If enough groups agree on a penalty application, partial collateral locking occurs while the penalty is investigated and resolved.
  • Network Voting: Penalty resolution happens through network-wide voting, ensuring that punishments are applied fairly and only when warranted.

​
Epoch-Based Processing

The sequencer network operates on an epoch-based system that provides structure and predictability to cross-chain message processing.

​
Epoch Structure

  • Time-Based Windows: Each epoch represents a specific time period during which transactions are collected and processed together. The epoch duration is configurable through DAO governance.
  • Deterministic Timing: Epoch boundaries are calculated using the formula: 
EpochId = (currentTime - protocolDeployTime) / epochDuration
  • Processing Boundaries: Transactions are processed within specific timeframes:
[protocolDeployTime + EpochId × epochDuration,
 protocolDeployTime + (EpochId + 1) × epochDuration]

​
Benefits of Epoch Processing

  • Ordered Processing: The epoch system ensures that all sequencers work with the same set of transactions, preventing timing-based attacks and inconsistencies.
  • Batch Efficiency: Processing transactions in batches is more efficient than handling them individually and provides better opportunities for validation and consensus.
  • Predictable Timing: Users and applications can understand approximately when their transactions will be processed based on epoch timing.

​
Governance and Elections

The sequencer network operates under distributed governance that manages participation and network parameters.

​
Election Cycles

  • Regular Elections: The system includes regular election cycles every N hours, where N is configurable through DAO voting. This ensures that sequencer participation remains current and responsive to network needs.
  • Performance Monitoring: During election cycles, sequencer performance is evaluated based on reliability, accuracy, and participation in consensus.
  • Dynamic Participation: The election system allows for adding new groups and removing underperforming ones based on community governance decisions.

​
Parameter Management

Epoch Duration: The length of processing windows can be adjusted to balance security with performance requirements. Consensus Thresholds: The number of groups required for network consensus can be modified based on security needs and participation levels. Timing Windows: Various timeout and processing windows can be tuned for optimal network performance.

​
Executor Mechanism

TAC employs a separation of responsibilities between cross-chain message sequencing and execution, with designated executors handling the final transaction processing.

​
Executor Selection and Assignment

​
Executor Responsibilities

Primary execution duties: - Submit finalized message batches with Merkle proofs to CrossChainLayer contract - Verify cryptographic proofs of consensus approval - Trigger asset minting/unlocking operations before contract calls - Execute target smart contract methods with validated parameters

​
Security Through Cryptography

No Collateral Required:
  • Executor security guaranteed through cryptographic proofs rather than economic staking
  • Merkle proofs ensure only consensus-approved messages can be executed
  • CrossChainLayer contract validates all proofs before allowing execution
  • Eliminates need for executor collateral or centralized approval processes

​
Future Evolution

The modular design of the sequencer network allows for future improvements and adaptations as the network grows and requirements evolve.

​
Planned Enhancements

  • FROST Consensus Upgrade: Migration to FROST-Ed25519 threshold signatures with DKG
  • Enhanced Oracle Integration: Expanded oracle services during execution
  • Scalability Improvements: Support for more groups, shorter epochs, efficient consensus
  • Additional Blockchain Support: Potential expansion beyond TON and TAC EVM

​
What’s Next?

Understanding the sequencer network helps you appreciate how TAC maintains security and reliability for cross-chain operations.

Cross-Chain Messaging

Learn how sequencers process and validate messages

Asset Bridging

Understand how sequencers handle token operations