Selendra: A Dual-VM Blockchain with Unified Account Architecture
Version 5.0
2025
Abstract
Cambodia represents a critical test case for blockchain adoption in emerging markets, where transaction costs exceeding daily wages, complex user experiences, and fragmented developer ecosystems have limited mainstream adoption. Bakong Blockchain pioneered successful blockchain implementation for payments and interbank money transfers, proving the technology can serve Cambodian needs. Selendra builds on these lessons to expand blockchain accessibility beyond payments, creating a general-purpose platform for smart contracts, decentralized applications, and financial inclusion.
The platform implements an EVM-first unified account architecture where users interact exclusively with familiar 0x... addresses through MetaMask, while developers access both EVM and WASM virtual machines without managing separate identity systems. Hybrid consensus delivers one-second blocks with Byzantine fault-tolerant finality, combining enterprise-grade security with sub-$0.001 transaction costs. This architecture enables daily transactions, SME loyalty programs, asset tokenization, and micro-commerce. Cambodia-first success provides a replicable blueprint for similar markets worldwide, bringing internet users into decentralized networks while maintaining permissionless innovation principles.
1. Introduction
1.1 The Cambodia-First Strategy
With over 50% internet penetration but significant blockchain adoption barriers, Cambodia represents the ideal test case for demonstrating how blockchain can serve emerging markets. Current solutions fail fundamental challenges: transaction costs exceeding daily wages, fragmented user experiences requiring multiple wallets, and complex development environments excluding local talent.
Selendra's Cambodia-first strategy solves these adoption challenges to create a replicable blueprint for similar markets worldwide, bringing internet users into decentralized networks while preserving developer accessibility.
1.2 Critical Adoption Barriers
Economic
Transaction fees of $0.50-$5.00 exceed daily wages, making blockchain impractical for SME operations and micro-commerce driving local economies.
Technical
Account fragmentation requires separate identities for different VMs, creating confusion and security risks while forcing developers to choose between Ethereum tooling and WebAssembly capabilities.
Experience
Complex wallet setup, multiple address formats, and gas estimation create onboarding friction preventing mainstream adoption.
1.3 Selendra's Solution
EVM-First Unified Accounts
Single 0x... addresses work across EVM and WASM VMs, providing MetaMask-native experiences while giving developers maximum flexibility through transparent address resolution.
Hybrid Consensus
One-second blocks with absolute finality deliver retail transaction speed while maintaining financial application security standards.
Economic Accessibility
Exponential inflation economics target sub-$0.001 transaction costs, enabling daily transactions, loyalty programs, and micro-commerce essential to emerging economies.
2. Consensus Architecture
2.1 Block Production
Block production utilizes AURA (Authority Round) consensus with deterministic slot assignment. Each one-second slot maps to exactly one validator through round-robin authority selection. This eliminates the probabilistic delays inherent in Proof-of-Work while maintaining predictable block production timing.
The weight-based execution model allocates 400ms for transaction processing within each 1,000ms block window, reserving 200ms for network propagation and 400ms for validation. This conservative ratio ensures validators on commodity hardware can process blocks without risking chain halts from computational delays.
Authority sets accommodate up to 100,000 validators through efficient slot scheduling. The session period of 900 blocks (15 minutes) balances validator set update frequency against the overhead of authority transitions. Era length of 96 sessions creates daily reward distribution cycles while allowing sufficient time for slashing dispute resolution.
2.2 Finality
Finality uses AlephBFT, a Byzantine fault-tolerant consensus protocol providing absolute transaction finality independent of block production. This two-layer architecture separates availability (block production) from agreement (finality), allowing the network to optimize each independently.
The finality committee consists of dynamically allocated validator seats split between reserved and non-reserved positions. Reserved seats ensure core validator stability while non-reserved seats enable permissionless participation through stake-based election. Committee composition changes each session through pallet-elections coordination.
AlephBFT operates through leader-based rounds where committee members vote on block finality. The protocol tolerates up to 33% Byzantine actors through cryptographic message signing and leader rotation. Emergency finalization mechanisms allow authorized keys to force finality during network disruption, preventing permanent chain halts from committee failures.
2.3 Validator Performance
Validator accountability operates through dual-layer tracking: block production monitoring and finality participation within AlephBFT rounds. Metrics aggregate per session with configurable thresholds.
The 90% lenient threshold allows temporary degradation without immediate slashing. Persistent underperformance triggers progressive penalties: warnings, committee exclusion, then slashing through governance approval.
Committee-management pallet coordinates performance data across staking, elections, and consensus pallets, maintaining consistent validator accountability across network functions.
3. Economic Model
3.1 Token Supply
The SEL token uses 18 decimal precision with a target supply cap of 320,000,000 SEL. Inflation follows an exponential decay curve approaching this cap asymptotically over the configured time horizon of approximately 4.9 years.
Per-era payout calculation:
era_payout = (era_duration / horizon) * (supply_cap - current_supply)
The exponential helper function implements Taylor series approximation:
exp_helper(x) = x - x²/2 + x³/6 - x⁴/24 + x⁵/120
This model front-loads rewards during network bootstrapping while ensuring issuance rate decreases as total supply approaches the cap. The deterministic formula eliminates governance overhead for monetary policy while maintaining predictable incentive schedules.
3.2 Staking Economics
Validator rewards split 75/25 between validators and nominators, incentivizing both direct validation and delegated staking. Each validator accepts exactly one nominator through strict delegation quotas, implementing true Delegated Proof-of-Stake where nominators delegate to single validators rather than spreading stakes.
Bonding duration of 14 eras (approximately 14 days) prevents rapid unstaking during market volatility while allowing reasonable liquidity for stakers. Slash deferral of 13 eras provides governance time to review slashing proposals before fund destruction, preventing false positive slashing from temporary network issues.
Existential deposit of 0.0000000005 SEL (500 picaSEL) maintains economic viability for small accounts while preventing state bloat from dust account accumulation. This threshold allows microtransaction accounts while keeping state growth manageable.
3.3 Transaction Fees
Fee calculation combines three components: weight-based execution cost, length-based storage cost, and dynamic multiplier adjustment.
Base fees:
- Weight factor: 0.0005 SEL per reference time unit
- Length fee: 0.00001 SEL per byte
- Operational multiplier: 5x priority boost
The dynamic fee multiplier targets 50% block capacity utilization, increasing fees during congestion and decreasing during low usage. Adjustment rate limits multiplier changes to 6.7% per 20 blocks, preventing volatility while maintaining responsiveness.
Operational transactions (governance, staking, system calls) receive 5x weight multiplier, ensuring critical network operations process during congestion. This tiered priority model maintains network functionality under load without requiring separate fee markets.
4. Virtual Machine Architecture
4.1 EVM Integration
Ethereum compatibility through Frontier provides complete Web3 API support with chain ID 1961. Gas model converts between Substrate weight units and EVM gas through calibrated ratio:
weight_per_gas = reference_time_per_second / gas_per_second gas_per_second = 40,000,000
Block gas limit of 36,000,000 leverages Substrate's 90% normal dispatch ratio, providing substantial capacity for complex smart contract operations while maintaining system stability. This ensures EVM transactions consume appropriate block weight without blocking operational extrinsics.
4.2 Dynamic Base Fee
EVM base fee adjusts dynamically based on block utilization, linking Ethereum gas pricing to Substrate's transaction fee multiplier. The adjustment formula:
base_fee = adjustment_factor * weight_factor * 25 / 98974
Minimum base fee of 0.1 Gwei prevents spam while maximum of 10,000 Gwei caps worst-case transaction costs. Step limit ratio of 0.0093% per block prevents sudden price spikes while maintaining responsiveness to demand changes.
4.3 WASM Contracts
WebAssembly contract support through pallet-contracts provides memory-safe smart contract execution with deterministic gas metering. Maximum code size of 256KB accommodates complex contracts while preventing state bloat.
Storage deposits charge 0.00004 SEL per byte, creating economic incentives for efficient contract storage. Deposit-per-item pricing scales with contract state complexity, ensuring storage costs reflect actual resource consumption.
Call stack depth of 16 frames prevents infinite recursion while allowing reasonable contract composition. Deletion queue depth of 128 contracts enables gradual state cleanup without blocking normal operations.
4.4 EVM-First Unified Account Architecture
Selendra implements an EVM-first user experience where all users interact exclusively with 0x... addresses, providing MetaMask-native compatibility while maintaining dual VM capabilities for developers. This eliminates the complexity of managing multiple address formats—a critical requirement for mainstream adoption in emerging markets.
Address Resolution System
The runtime transparently maps EVM addresses (H160) to Substrate AccountIds (32-byte) through two mechanisms:
1. Default Mapping
Automatically derives EVM address from Substrate accounts via Blake2 hashing, enabling immediate EVM functionality without explicit claiming
2. Explicit Claiming
Users prove control of existing EVM addresses through EIP-712 signature verification, binding specific Ethereum addresses to their Substrate identity
Both mechanisms charge 0.01 SEL mapping fee (immediately burned) to prevent state spam. Mappings are permanent and immutable once created, ensuring address consistency across all protocol layers.
Single-Address Identity
Users manage one 0x... address that works seamlessly across:
- EVM contracts (Solidity/Vyper)
- WASM contracts (ink!/AssemblyScript)
- Native transfers and staking
- Cross-VM DeFi protocols
The runtime automatically routes operations to the correct VM based on transaction type, eliminating bridge infrastructure typically required for cross-VM interactions.
Developer Integration
Ethereum developers use familiar tooling (Hardhat, Truffle, MetaMask) with standard JSON-RPC endpoints (chain ID 1961). Substrate developers access the same unified address system through Polkadot.js. Both ecosystems share unified liquidity pools and state, enabling seamless cross-VM composition without managing separate identity systems. Gaming developers deploy high-performance logic in ink! while using EVM contracts for NFT standards—all accessible through single user addresses.
5. Governance
5.1 Democratic Mechanisms
Public referendums with 7-day launch and voting periods enable token holder governance. Minimum 100 SEL deposit prevents spam while remaining accessible. Cooloff periods prevent repeated unpopular proposals. Maximum 100 concurrent proposals maintains manageable overhead.
5.2 Council System
Thirteen elected council members provide representative governance for urgent decisions using Phragmén proportional representation. Seven-day terms with 1,000 SEL candidacy bonds ensure serious candidates. Three-fifths majority required for privileged operations; unanimous technical committee approval for emergency changes.
5.3 Treasury
Transaction fees fund ecosystem development with 4-hour spend periods and maximum 20 concurrent approvals. Zero burn rate preserves all fees for productive use. Two-thirds council approval required for treasury spends.
6. Security Mechanisms
6.1 Safe Mode
Emergency pause mechanism enables network-wide operation suspension during detected attacks or consensus failures. Root authority can force entry into safe mode, halting all non-essential operations.
Whitelisted calls (sudo, system, timestamp) remain executable during safe mode, ensuring recovery operations and chain upgrades can proceed. Default safe mode period equals one session, providing operational window for coordinated response.
6.2 Transaction Pause
Granular call pausing allows disabling specific pallet functions without network-wide halts. Two-thirds council majority requirement ensures pause actions have broad support while enabling rapid response to discovered vulnerabilities.
Whitelist exemptions for sudo and system pallets prevent pause mechanisms from creating unrecoverable states. Maximum call name length of 256 bytes accommodates complex pallet::function identifiers while preventing abuse.
7. Network Parameters
Block Production
1-second blocks, 400ms execution window, 5MB maximum size, 2,400-block hash retention
Consensus
900-block sessions (15 min), 96-session eras (1 day), up to 100,000 validator capacity
Economic
320M SEL cap, 4.9-year inflation horizon, 75/25 validator/nominator split, 14-era bonding
Virtual Machines
EVM (chain ID 1961, 36M gas limit), WASM (256KB code limit), EVM-first unified accounts
8. Implementation
The runtime compiles to WebAssembly enabling forkless upgrades. Node implementation supports archive and pruned modes with RocksDB storage and optional SQL backend for EVM indexing. Frontier integration maintains Ethereum mappings enabling standard Web3 tooling without modification.
9. Real-World Use Cases for Cambodia's Digital Economy
9.1 Cross-Merchant Loyalty Programs
Cambodian SMEs operate fragmented loyalty ecosystems requiring multiple physical cards or applications. Selendra's EVM-first unified addresses enable cross-merchant networks where customers use a single MetaMask wallet across participating businesses. Sub-cent transaction costs make rewarding small purchases economically viable—coffee shops reward 0.01 SEL per transaction, street food vendors implement instant cashback, and tuk-tuk services offer points without prohibitive fees. Loyalty points become liquid digital assets tradable on secondary markets, creating value from accumulated rewards while providing businesses access to larger customer networks through shared ecosystems.
9.2 Asset Tokenization and Financial Inclusion
Traditional asset ownership in Southeast Asia lacks liquidity and accessibility. Selendra's low transaction costs democratize previously illiquid assets:
Agricultural Finance
Farmers tokenize future crop yields for pre-sale financing. Smart contracts automate payment release based on verified delivery, distributing risk across investors while providing immediate capital to producers.
Invoice Factoring
SMEs tokenize outstanding invoices for immediate liquidity. WASM contracts handle credit scoring while EVM contracts manage investor interactions—both accessible through unified addresses.
Remittance Networks
Migrant workers tokenize cash holdings, reducing remittance costs. Unified addresses simplify cross-border transfers while maintaining regulatory compliance through transparent blockchain transactions, providing families direct access to digital assets for education, healthcare, or business expenses.
10. Conclusion
Selendra demonstrates that blockchain can serve emerging market needs through transaction costs below $0.001, EVM-first unified accounts, and dual VM support. The hybrid consensus model achieves one-second block production with absolute finality, delivering the speed required for retail transactions while maintaining enterprise-grade security. This technical foundation enables daily blockchain usage patterns previously impossible in emerging markets.
The EVM-first unified account architecture eliminates user complexity while preserving developer flexibility. Users interact exclusively with familiar 0x... addresses through MetaMask, while the runtime transparently handles Substrate operations. Developers deploy Solidity or ink! contracts without managing separate identity systems—both access shared liquidity and state through unified addresses. This approach removes the technical barriers that have excluded billions of internet users from blockchain benefits.
Selendra brings internet users into decentralized networks through economic accessibility with sub-cent costs enabling daily transactions, technical simplicity with MetaMask-native 0x... addresses eliminating onboarding friction, developer freedom with EVM and WASM support without ecosystem lock-in, and local relevance through real-world use cases solving immediate market needs.
Selendra's focus on emerging markets creates inclusive digital economies serving both local requirements and global integration. The Cambodia-first approach with EVM-first architecture proves blockchain can empower millions excluded from digital economies, establishing Selendra as the bridge between internet and blockchain ecosystems. Success in Cambodia provides the playbook for similar markets worldwide, enabling rapid deployment to other regions facing comparable adoption barriers while maintaining principles of permissionless innovation and decentralization.
References
- Substrate Framework: https://substrate.io
- AlephBFT Consensus: https://arxiv.org/abs/1908.05156
- EIP-712 Typed Data: https://eips.ethereum.org/EIPS/eip-712
- Phragmén Election Method: https://arxiv.org/abs/2004.12990
- Frontier EVM Bridge: https://github.com/paritytech/frontier
Runtime Specification:
- spec_name: selendra
- spec_version: 20005
- Chain: Selendra Mainnet (Chain ID: 1961)
- SS58 Prefix: 42
Development Environment:
- JSON-RPC Endpoint: https://rpc.selendra.org
- WebSocket Endpoint: wss://rpc.selendra.org
- Chain ID: 1961 (0x7A9)
- Block Explorer: https://explorer.selendra.org
Tool Integration:
- MetaMask: Add custom network with chain ID 1961
- Hardhat: Update hardhat.config.js with selendra network configuration
- Polkadot.js: Use standard WebSocket connection to Selendra endpoints
- cargo-contract: Compatible with Selendra WASM contract deployment
