TL;DR:The sequencer is the heart of TeQoin L2. It receives transactions, orders them, executes them in the EVM, produces blocks every 5 seconds, and posts batches to Ethereum L1. While currently centralized for simplicity, the system is designed to be fraud-proof secure regardless of sequencer behavior.
🎯 What is the Sequencer?
The sequencer is the component that:- Receives transactions from users
- Orders transactions deterministically
- Executes transactions in the EVM
- Produces L2 blocks
- Posts transaction batches to L1
Role in the System
Think of the sequencer as:- The “block producer” for L2 (like miners/validators on L1)
- The “coordinator” that orders transactions
- The “publisher” that posts data to L1
🏗️ Sequencer Architecture
High-Level Components
- RPC Interface
- Transaction Pool
- Block Producer
- Batch Publisher
User-facing transaction submissionEndpoints:
- Primary: https://rpc.teqoin.io
- Backup: https://rpc-backup.teqoin.io
- WebSocket: wss://ws.teqoin.io
🔄 Transaction Flow Through Sequencer
Complete Lifecycle
1
Transaction Submission
User submits transaction via RPCSequencer receives:
2
Validation
Sequencer validates transaction
3
Mempool Addition
Add to transaction pool
4
Block Production (5 seconds)
Include in next blockUser sees confirmation in ~5 seconds
5
Batching (~10 minutes)
Collect blocks into batch
6
L1 Publication
Post batch to Ethereum
📊 Transaction Ordering
How Sequencer Orders Transactions
- FIFO (Current)
- Gas Price Priority
- Fair Ordering
First-In-First-Out orderingCharacteristics:
- ✅ Simple and predictable
- ✅ No MEV (Maximal Extractable Value)
- ✅ Fair to all users
- ❌ No priority for urgent transactions
⚙️ Block Production Details
Block Structure
Block Production Algorithm
📦 Batch Publishing
Batch Composition
What's in a Batch?
What's in a Batch?
Batch contents:Typical batch:
- 100-200 L2 blocks
- 5,000-20,000 transactions
- 500KB-2MB compressed data
Compression Strategy
Compression Strategy
How data is compressed:Compression ratio: ~15:1Size comparison:
- Uncompressed: 180 bytes/TX
- Compressed: ~12 bytes/TX
Publishing Schedule
Publishing Schedule
When batches are published:Typical frequency: Every 10 minutes
🔒 Sequencer Security
Centralized Sequencer Risks
- What Sequencer CAN Do
- What Sequencer CANNOT Do
- Forced Inclusion
Limited powers:✅ Order transactions
- Choose transaction ordering within blocks
- Potentially front-run or sandwich
- Mitigation: FIFO ordering policy
- Hold transactions in mempool temporarily
- Mitigation: Users can force via L1
- Control batch timing (within limits)
- Mitigation: Economic incentive to post regularly
🌐 Decentralization Roadmap
Path to Decentralized Sequencer
1
Phase 1: Single Sequencer (Current)
Current state:
- One centralized sequencer
- Operated by TeQoin team
- Fraud-proof secured
- Good enough for launch
- ✅ Simple and efficient
- ✅ Fast block times
- ✅ Low operational cost
- ❌ Single point of failure
- ❌ Potential censorship
2
Phase 2: Backup Sequencers
Add redundancy:
- Multiple sequencer nodes
- Automatic failover
- Load balancing
- ✅ Higher availability
- ✅ No downtime for maintenance
- ✅ Geographic distribution
3
Phase 3: Sequencer Set
Decentralized sequencer rotation:
- Multiple independent operators
- Round-robin or random selection
- Stake-based participation
4
Phase 4: Fully Decentralized
Open participation:
- Anyone can run sequencer
- Stake-based selection
- MEV-resistant ordering
- Decentralized governance
📊 Performance Metrics
Sequencer Performance
Block Time
5 secondsFixed block interval
Throughput
1000+ TPSTransactions per second
Latency
< 100msTransaction confirmation
Block Size
30M gasMaximum per block
Batch Interval
~10 minutesL1 posting frequency
Uptime
99.9%Sequencer availability
🛠️ For Node Operators
Running a Sequencer Node
Future requirements (Phase 3+):📚 Further Reading
Optimistic Rollup
How the overall system works
Fraud Proofs
How invalid sequencer behavior is prevented
Security Model
Complete security analysis
Technical Overview
Overall architecture
Understand the sequencer? Continue to Security Model - the final architecture page! →