Native EltooLightning Network
The world's first Eltoo 2.0 implementation with Dual-Track UTXO architecture. No external registry. No penalty mechanisms. Just pure UTXO-native state channels with enshrined transaction types.
Dual-Track UTXO Architecture
Eltoo 2.0 introduces a revolutionary Dual-Track UTXO model where channel state is directly encoded in the UTXO set through enshrined transaction types.
Fund UTXO
Static AnchorThe immutable anchor holding channel funds and security parameters. Created at genesis, referenced by UPDATE transactions, and only spent during SETTLE or SPLICE.
channel_id - Immutable channel identifieragg_vk - Aggregated verification key (32 bytes)min_csv - Minimum CSV delay for settlementState UTXO
Dynamic PointerThe dynamic state pointer tracking current channel state. Destroyed and recreated with every UPDATE, carrying the latest balance commitments.
state_number - Monotonically increasing counterbalances_root - Commitment to current balancesptlcs_root - Commitment to active PTLCsTruth-in-UTXO Consensus
The on-chain UTXO set IS the sole source of truth. No external registry database needed. Fund + State UTXOs together encode complete channel state with consensus-level enforcement.
UTXO-Based Registry-Free Model
Eltoo 2.0 eliminates the need for any external state database. The UTXO set itself is the authoritative source of channel state.
Script-Based (Lightning)
- โRequires complex script execution for validation
- โState stored in external databases with consistency risks
- โSoft fork needed for new script types
UTXO-Based (Eltoo 2.0)
- โNative enum pattern matching - O(1) validation
- โState IS the UTXO set - atomic consistency guaranteed
- โEnshrined transaction types with compile-time safety
Why UTXO-Based Architecture Matters
Native UTXO Integration
Channel state uses the same UTXO set as regular transactions
Natural Reorg Safety
UTXO rollback handles blockchain reorgs automatically
Atomic Splicing
Channel resizing is just a standard UTXO transaction
How Eltoo 2.0 Works
Four enshrined transaction types with pattern-matched validation. Transaction type is inferred from input/output enum patterns, not declared.
FUND
Creates the channel with Fund UTXO (static anchor) and State UTXO at state_number=0.
Out: Fund + State(0)
UPDATE
Spends old State UTXO, references Fund UTXO (read-only via ChannelFundRef), creates new State with incremented state_number.
Out: State(N+1)
SETTLE
Spends both Fund and State UTXOs, distributes balances according to final state commitments after CSV delay.
Out: Standard (distributed)
SPLICE
Atomic channel resizing with FORK/MERGE modes for Channel Factories.
Channel Lifecycle
Splice Transactions & Channel Factories
SPLICE transactions with State UTXO enable atomic channel resizing and native Channel Factory support - creating subchannels from a parent channel in a single transaction.
SPLICE-RECONFIGURE
Resize channel capacity by adding or removing funds while preserving channel identity.
SPLICE-FORK
Split a parent channel into multiple independent subchannels. Each subchannel operates autonomously.
SPLICE-MERGE
Consolidate subchannels back into the parent channel with atomic balance conservation.
Channel Factory Architecture
N participants need only 1 FUND + 1 FORK tx instead of N(N-1)/2 individual channels.
Subchannels update independently - no coordination needed for routine payments.
Eltoo 2.0 vs Lightning Network
Eltoo 2.0 fundamentally reimagines payment channels through enshrined transaction types and UTXO-native state management.
| Feature | Traditional Lightning Network | Eltoo 2.0 |
|---|---|---|
| Fraud Handling | Penalty-based punishment (total fund loss risk) | Strict monotonic overwriting (safe, no penalties) |
| State Model | Revocable commitments + external database | UTXO-native Dual-Track (Fund + State) |
| Channel Factories | Complex custom scripts required | Native SPLICE-FORK/MERGE support |
| Multi-Party Scaling | N(N-1)/2 channels needed | 1 FUND + 1 FORK for N users |
| Validation | Script execution overhead | O(1) pattern matching dispatch |
No Penalties, No Risk
Safe state overwriting with strict monotonicity. Offline periods are completely safe - no punishment mechanisms or watchtower dependencies.
Enshrined Simplicity
First-class enum variants replace 10+ fields. Core logic is <500 lines with compile-time type safety and exhaustiveness checking.
Native Multi-Asset
Direct balance commitments with asset_id field. Tokens, stablecoins, and NFTs handled naturally at consensus level via Ingot integration.
Optional Watchtowers
UTXO-based state means watchtowers are optional for audits, not required for safety. Query channel_id directly from UTXO set.
Type-Safe Architecture
Rust enum system provides compile-time guarantees. Pattern matching ensures all cases handled, preventing runtime validation bugs.
Channel Factory Native
SPLICE-FORK creates subchannels, SPLICE-MERGE consolidates them. Atomic REBALANCE moves liquidity in a single transaction.
Development Roadmap
Eltoo 2.0 Devnet
Full Eltoo 2.0 with Dual-Track UTXO model deployed on Tondi devnet. Enshrined transaction types, SPLICE-FORK/MERGE, and complete SDK with WASM bindings available.
Security Audits
Comprehensive third-party security audits of consensus rules, STPC mempool strategy, and cryptographic implementations.
Mainnet Launch
Production deployment on Tondi mainnet after successful audit completion and extensive testnet validation.
Experience the Future of Payment Channels
Eltoo 2.0 represents the most advanced Layer 2 architecture ever designed. Read the complete technical specification.