- The Ethereum whitepaper had just been published. Bitcoin was starting to show real limitations for anything beyond simple value transfer. We were building Crowdstart — a commerce platform for crowdfunding campaigns — and thinking hard about what programmable money would mean for creators and backers.
This is a retrospective on those early architectural explorations that eventually became Lux.
The Problem With Single-Chain Architectures
The Bitcoin model — every transaction on one global ledger — was revolutionary but limiting:
- Throughput: All transactions compete for the same block space
- Finality: Probabilistic finality means waiting for confirmations
- Programmability: Limited scripting, no native smart contracts
- Specialization: One chain trying to serve every use case
Ethereum's whitepaper solved the programmability problem elegantly. But it was still fundamentally a single-chain design. We believed the future would be purpose-built chains that interoperate.
What We Were Building Toward
The architecture we eventually built into Lux:
Specialized chains, shared consensus
- Different chains optimized for different workloads
- High-throughput for payments and commerce
- Smart contract execution for complex logic
- Asset issuance and transfer
- Governance and validator management
Sub-second finality
- PoW and PoS have inherent latency tied to probabilistic finality
- Wave consensus family achieves deterministic finality in under a second
- This matters enormously for commerce — you need to know a payment is final
EVM compatibility
- The developer ecosystem around smart contract tooling is too valuable to ignore
- Thousands of audited contracts, battle-tested libraries, experienced developers
- We wanted full compatibility while running different consensus under the hood
The EVM Question
The Ethereum Virtual Machine represents a remarkable standard. The tooling ecosystem — wallets, development frameworks, the Solidity compiler, auditing firms — all built around one VM specification.
When building Lux's C-Chain (the smart contract chain), we wanted this compatibility. Our implementation runs the EVM specification on Lux's high-performance consensus layer:
- Same EVM: All Solidity contracts work unchanged
- Same RPC: Existing tools just work
- Different consensus: Wave family for sub-second finality
- Multi-chain: C-Chain interoperates with X-Chain (assets) and P-Chain (validators)
// The Lux VM interface — pluggable execution behind consensus
type VM interface {
Initialize(ctx *lux.Context, ...) error
BuildBlock() (luxman.Block, error)
ParseBlock([]byte) (luxman.Block, error)
// ... Lux-specific methods
}Lux Consensus
The Wave consensus family is probabilistic-but-fast. Each node repeatedly samples a small random subset of peers. When sufficient agreement is detected, the network reaches consensus in milliseconds.
This enables:
- 1-2 second finality for payment confirmation
- 4,500+ TPS on the C-Chain
- Chain architecture for infinite scalability
- Deterministic finality — once accepted, it's final
Commerce and Crypto
From a commerce perspective, what matters:
For creators: Campaign funding that clears in seconds, not hours. Smart contracts that automatically disburse funds when milestones are reached.
For platforms: Composable financial primitives. On-chain reputation. Cross-chain payment rails.
For developers: Full EVM compatibility means existing Solidity knowledge transfers directly.
Fast Forward to 2020
We published the Lux mainnet in 2020. The multi-chain architecture we'd sketched in 2013-2014 was built out: C-Chain for EVM contracts, X-Chain for native Lux asset exchange, P-Chain for validator coordination. Post-quantum cryptography via lattice-based signatures baked in from the start.
The AI/compute layer came later — but the same architectural instincts apply. Specialized chains for specialized workloads. High throughput, deterministic finality, interoperability.
This post is part of our retrospective series exploring the technical foundations of Hanzo and Lux.
Read more
The Full Arc: Commerce, Blockchain, AI, and Why It's All the Same Problem
Looking back from 2026: the through-line from a commerce platform in 2008 to frontier AI models today is a single consistent thesis about infrastructure, openness, and who gets to build.
Building a Blockchain Faucet That Doesn't Get Drained
How we built the Lux testnet faucet to resist abuse while remaining accessible to developers.
Netrunner: Testing Blockchains at Scale
How we built Netrunner to simulate blockchain networks and catch bugs before they hit production.