A dual-VM chain with unified accounts.

Abstract

Cambodia is a test case for blockchain adoption in emerging markets, where transaction costs, complex user experiences and fragmented developer ecosystems have limited mainstream use. Bakong Blockchain showed the technology can serve Cambodian needs for payments and interbank transfers. Selendra builds on those lessons to extend blockchain beyond payments, into smart contracts, decentralized applications and financial inclusion.

The platform implements an EVM-first unified account architecture. Users interact with familiar 0x... addresses through MetaMask, while developers reach both the EVM and WASM virtual machines without managing separate identity systems. Hybrid consensus produces one-second blocks that finalize a median of one second later under Byzantine fault-tolerant agreement, and an EVM transfer costs about 0.0000021 SEL at the network's current base fee. That combination supports daily transactions, SME loyalty programs, asset tokenization and micro-commerce. Cambodia-first success is meant as a blueprint for similar markets, bringing internet users into decentralized networks while keeping permissionless innovation intact.

1. Introduction

1.1 The Cambodia-First Strategy

Cambodia has wide internet use and narrow blockchain use, which makes it a good place to test whether the second can follow the first. The obstacles are familiar: transaction costs that outrun the value being transferred, fragmented user experiences that require multiple wallets, and development environments that exclude local talent.

Selendra's Cambodia-first strategy works on these adoption barriers to produce a blueprint other markets can reuse, bringing internet users into decentralized networks without giving up developer accessibility.

1.2 Critical Adoption Barriers

Economic

Per-transaction fees on general-purpose chains are too high for SME operations and the micro-commerce that drives local economies.

Technical

Account fragmentation requires separate identities for different VMs, which creates confusion and security risk, and forces developers to choose between Ethereum tooling and WebAssembly capabilities.

Experience

Wallet setup, multiple address formats and gas estimation add onboarding friction.

1.3 Selendra's Solution

EVM-First Unified Accounts

A single 0x... address works across the EVM and WASM VMs, giving a MetaMask-native experience and transparent address resolution for developers.

Hybrid Consensus

One-second blocks, finalized a median of one second later. Once a block is finalized it does not revert.

Economic Accessibility

Exponential inflation economics and a low base fee keep per-transaction cost in fractions of a SEL, which is what makes daily transactions, loyalty programs and micro-commerce workable.

2. Consensus Architecture

2.1 Block Production

Block production uses AURA (Authority Round) consensus with deterministic slot assignment. Each one-second slot maps to exactly one validator through round-robin authority selection, and the runtime forbids more than one block per slot. This removes the probabilistic delays of Proof-of-Work while keeping block timing predictable.

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. The conservative ratio lets validators on commodity hardware process blocks without risking chain halts from computational delays.

The Aura authority vector is bounded at 100,000 entries, but the elected validator set is capped at 1,000 by the elections and committee-management pallets, so that is the real ceiling. Mainnet ran 4 validators as of 14 August 2026. The session period of 900 blocks (15 minutes) balances validator set update frequency against the overhead of authority transitions. An era of 96 sessions is exactly one day at one-second blocks, which sets the reward distribution cycle.

2.2 Finality

Finality uses AlephBFT, a Byzantine fault-tolerant protocol that runs independently of block production and carries its results as separate justifications. This two-layer architecture separates availability (block production) from agreement (finality), so each can be tuned on its own.

The finality committee is made of validator seats split three ways: reserved, non-reserved, and non-reserved finality seats. Reserved seats hold core validators in place. Non-reserved seats can be opened to permissionless stake-based election by governance, but the network currently runs a permissioned election with all committee seats reserved. Committee composition is recomputed each session through pallet-elections coordination.

AlephBFT operates through leader-based rounds in which committee members vote on block finality. The protocol tolerates up to a third of the committee acting Byzantine, enforced by a two-thirds-plus-one threshold on signed messages.

Emergency finalization lets an authorized key force finality during network disruption, which prevents a committee failure from halting the chain permanently. The key is set by Root or a three-fifths council majority and becomes usable two sessions later.

Finality runs roughly one block behind production. Across 498 consecutive mainnet blocks observed from the public RPC endpoint on 14 August 2026, a block was finalized a median of 1.00 s after it was first announced, with 90% finalized within 1.22 s and 95% within 1.37 s. Six blocks in that sample took longer than 2 s and the slowest took 6.4 s, so the tail is real and applications settling value should treat one to two seconds as typical rather than guaranteed. The measurement is client-side latency between the two subscriptions a node exposes, chain_subscribeNewHeads and chain_subscribeFinalizedHeads, so it includes network time to the observer and is an upper bound on what the committee itself takes.

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 AlephBFT scores submitted every 300 rounds.

The 90% figure is a reward threshold. A validator that produces at least 90% of its expected blocks in a session earns the full session reward; below that, the reward scales linearly with blocks produced.

Underperforming validators can be removed from the committee for a configured number of eras, ten by default. Both ban triggers are currently set to values that disable automatic bans, and the runtime registers no offences pallet, so no automated slashing path exists today.

The committee-management pallet coordinates performance data across the staking, elections and consensus pallets, keeping one view of validator behaviour across network functions.

3. Economic Model

3.1 Token Supply

The SEL token uses 18 decimal precision with a target supply of 320,000,000 SEL. 320M SEL is an economic target, not a hard technical limit: it is an input to the era payout formula, held in mutable storage, and nothing in the runtime enforces it as a mint ceiling. Total issuance stood at 233.57M SEL on 14 August 2026.

Smart Inflation Design

• Rewards decrease as issuance approaches the 320M target
• Early stakers earn more rewards, later stakers earn less
• Similar to how early Bitcoin miners earned more rewards

The Basic Math Rewards per era follow one principle:

• More headroom below the target = Higher rewards
• Closer to 320M = Lower rewards
• Approaching 320M = Rewards approach zero

Supply Formula

era_payout = (1 - exp(-era_duration / 4.9 years)) × (320M - current_supply)

Over a single era the exponential term is small, so the payout is close to (era_duration / 4.9 years) × (320M - current_supply). The runtime evaluates the exponential with a fifth-order Taylor expansion.

Key Features:

• 4.9 years is a decay constant, not a completion date. Roughly two-thirds of the remaining gap to 320M closes in the first 4.9 years, and issuance approaches the target asymptotically without reaching it
• No sudden supply shocks, just a smooth decline in rewards
• Transparent formula anyone can verify against the chain
• Governance can adjust the cap and the horizon within bounded limits

At the August 2026 issuance level, one era pays about 48,400 SEL and the first year adds roughly 17.7M SEL.

Why This Matters for Emerging Markets:

• Predictable issuance for businesses planning around the token
• No surprise inflation
• A schedule that decays instead of stopping at a cliff

3.2 Staking Economics

Simple Staking Design for Everyone

Reward Distribution

• 75% of each era's inflation goes to the staking set - validators and their nominators, split first by validator commission and then by stake exposure
• 25% goes to the treasury as the era remainder
• Nominators are paid out of the validator share, not out of the treasury share

True Delegated Proof-of-Stake

• Each nominator backs exactly one validator, rather than spreading stake across many, unlike most other networks
• A validator can have up to 1,024 rewarded nominators
• Clear accountability, since you know exactly who you are supporting

Bonding and Security

• 14-day bonding period - tokens are locked for 14 eras, one era being one day
• Prevents rapid attacks and network instability
• 13-day slash deferral - a configured window between an offence and the penalty being applied. The runtime currently registers no offences pallet, so nothing reports a slashable offence and the window is unexercised

Why This Design for Cambodia:

• Simple to understand: you support one validator, not dozens
• One relationship to evaluate instead of a portfolio of them
• Predictable returns with clear rules

Minimum Account Balance

• 0.0000000005 SEL minimum (500 picoSEL) to keep an account active
• Prevents network bloat from abandoned accounts
• Low enough to leave micro-transactions viable

3.3 Transaction Fees

Low Fee Design for Daily Use

What a transaction actually costs

• An EVM transfer is 21,000 gas at the 0.1 Gwei base fee, about 0.0000021 SEL
• A native extrinsic costs roughly 0.000586 SEL per unit of base extrinsic weight, plus 0.00001 SEL per byte
• Any figure in dollars depends on the SEL price, which no runtime component supplies. Convert at a price you can cite

Smart Fee System

• Base fees: small amounts for computation and storage
• Dynamic adjustment: fees rise when the network is busy and fall when it is quiet
• Target: 50% network utilization, which keeps the network responsive without pricing it up
• Bounded movement: the fee multiplier cannot more than double over 20 blocks, about 20 seconds, set by a variability coefficient of 0.067

Priority for Important Operations

• Operational dispatches carry a virtual tip of 5x their fee
• Governance, staking and system operations therefore clear ahead of ordinary traffic
• The network stays functional during peak usage

Why This Matters for Cambodia:

• Daily transactions stay affordable: street food, tuk-tuk rides, small purchases
• Business-friendly: SMEs can accept blockchain payments without losing the margin to fees
• Predictable costs: the fee multiplier is bounded, so congestion cannot spike fees without limit
• Fair access: small transactions get the same priority as large ones

4. Virtual Machine Architecture

4.1 EVM Integration

Ethereum compatibility through Frontier provides Web3 API support with chain ID 1961. The gas model converts between Substrate weight units and EVM gas through a calibrated ratio:

weight_per_gas = reference_time_per_second / gas_per_second
gas_per_second = 40,000,000

That gives 25,000 weight units per gas. The block gas limit of 36,000,000 follows from Substrate's 90% normal dispatch ratio, which leaves room for complex contract operations without crowding out operational extrinsics.

4.2 Dynamic Base Fee

The EVM base fee is designed to adjust with block utilization, linking Ethereum gas pricing to Substrate's transaction fee multiplier. The adjustment formula:

base_fee = adjustment_factor * weight_factor * 25 / 98974

The runtime currently leaves the weight factor unset, which resolves to zero, so the computed ideal fee is zero and the value is clamped to the lower limit every block. The mechanism is in place but inert, and the chain sits pinned at the 0.1 Gwei floor.

The minimum base fee of 0.1 Gwei prevents spam and the maximum of 10,000 Gwei caps worst-case transaction costs. A step limit ratio of 0.0093% per block prevents sudden price spikes while keeping the fee responsive to demand.

4.3 WASM Contracts

WebAssembly contract support through pallet-contracts provides memory-safe execution with deterministic gas metering. Unstable host interfaces are disabled and the randomness source has been removed, both of which keep execution deterministic. A maximum code size of 256KB accommodates complex contracts while preventing state bloat.

Storage deposits charge 0.00004 SEL per byte, which prices efficient contract storage. Deposit-per-item pricing adds 0.00128 SEL per storage item, so costs track state complexity rather than raw size alone.

A call stack depth of 16 frames prevents infinite recursion while allowing reasonable contract composition.

4.4 EVM-First Unified Account Architecture

Selendra implements an EVM-first user experience in which all users interact with 0x... addresses, giving MetaMask-native compatibility while keeping dual VM capabilities available to developers. That removes the work of managing multiple address formats, which matters 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

Every Substrate account has an EVM address derived from it by Blake2 hashing, available immediately and at no cost, with no on-chain storage written.

2. Explicit Claiming

Users prove control of an existing EVM address through EIP-712 signature verification, binding that Ethereum address to their Substrate identity.

Claiming an address writes a mapping and charges a 0.01 SEL fee, which is burned to prevent state spam. The fee applies to both claim paths, including claiming the hash-derived default address, but not to the automatic derivation itself.

Mappings are immutable to the user. The pallet at repository HEAD adds a governance path that can remap an account to a new EVM address through a delayed request, which is visible on chain before it executes. The runtime live on mainnet predates that change.

Single-Address Identity

Users manage one 0x... address that works across:

• EVM contracts (Solidity/Vyper)
• WASM contracts (ink!/AssemblyScript)
• Native transfers and staking
• Cross-VM DeFi protocols

The runtime routes operations to the correct VM based on transaction type. Because both VMs share one address space, cross-VM interaction needs no bridge infrastructure.

Developer Integration

Ethereum developers use familiar tooling (Hardhat, Truffle, MetaMask) with standard JSON-RPC endpoints on chain ID 1961. Substrate developers reach the same unified address system through Polkadot.js. Both ecosystems share liquidity and state, so cross-VM composition does not require managing separate identities. A gaming developer can put performance-sensitive logic in ink! and use EVM contracts for NFT standards, all reachable from a single user address.

5. Governance

5.1 Democratic Mechanisms

Public referendums with 7-day launch and voting periods enable token holder governance. A minimum 100 SEL deposit prevents spam while staying accessible. A 7-day cooloff period blocks repeated unpopular proposals. A maximum of 100 concurrent proposals keeps the queue manageable.

5.2 Council System

Thirteen elected council members provide representative governance for urgent decisions, elected by Phragmén proportional representation. Seven-day terms with 1,000 SEL candidacy bonds set a bar for candidates. Privileged operations require a three-fifths council majority, and emergency changes require unanimous technical committee approval.

No council has been seated on mainnet as of 14 August 2026, so every council-gated origin currently resolves only through Root.

5.3 Treasury

80% of every transaction fee is burned and 20% goes to the block author; tips go entirely to the author. Fee revenue does not reach the treasury. The treasury is funded by the 25% era reward remainder, by slashes, and by forfeited council-election deposits.

Spend periods run every 4 hours with a maximum of 20 concurrent approvals, and the treasury's own burn rate is zero, so an unspent balance is retained rather than destroyed. Treasury spending is disabled at the runtime level: no origin can authorise a spend, and enabling it requires a runtime upgrade.

6. Security Mechanisms

6.1 Safe Mode

An emergency pause mechanism suspends network-wide operation during a detected attack or consensus failure. Root can force entry into safe mode, halting non-essential operations. Permissionless entry by deposit is disabled.

Calls to the sudo, system, timestamp and safe-mode pallets stay executable during safe mode, which is what allows recovery operations, chain upgrades and exit from safe mode itself. The default safe mode period is one session, 900 blocks or 15 minutes, which sets the window for a coordinated response.

6.2 Transaction Pause

Granular call pausing disables specific pallet functions without a network-wide halt. Pausing and unpausing both require Root or a two-thirds council majority, so the action needs broad support while still allowing a fast response to a discovered vulnerability.

Whitelist exemptions for the sudo, system and timestamp pallets keep the pause mechanism from creating an unrecoverable state. A maximum call name length of 256 bytes accommodates 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), elected validator set capped at 1,000

Economic

320M SEL target supply, 4.9-year inflation horizon, 75/25 staking/treasury 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, which enables forkless upgrades. The node supports archive and pruned modes with RocksDB storage and an optional SQL backend for EVM indexing. Frontier integration maintains the Ethereum mappings that let standard Web3 tooling work unmodified.

9. Real-World Use Cases for Cambodia's Digital Economy

9.1 Cross-Merchant Loyalty Programs

Cambodian SMEs run fragmented loyalty schemes that need a separate card or app for each merchant. Selendra's EVM-first unified addresses allow cross-merchant networks where a customer uses one MetaMask wallet across participating businesses. At fractions of a SEL per transaction, rewarding a small purchase is economically viable: a coffee shop can credit 0.01 SEL per visit, a street food vendor can run instant cashback, and a tuk-tuk service can issue points without the fee swallowing the reward. Loyalty points become liquid digital assets, tradable on secondary markets, which turns accumulated rewards into value and gives businesses access to a shared customer network.

9.2 Asset Tokenization and Financial Inclusion

Asset ownership in Southeast Asia often lacks liquidity and accessibility. Selendra's transaction costs make previously illiquid assets tradable:

Agricultural Finance

Farmers tokenize future crop yields for pre-sale financing. Smart contracts release payment on verified delivery, spreading risk across investors while giving producers capital up front.

Invoice Factoring

SMEs tokenize outstanding invoices for immediate liquidity. WASM contracts handle credit scoring while EVM contracts manage investor interactions, both reachable through the same unified address.

Remittance Networks

Migrant workers tokenize cash holdings to reduce remittance costs. Unified addresses simplify cross-border transfers, and on-chain transparency supports regulatory compliance, giving families direct access to digital assets for education, healthcare or business expenses.

10. Conclusion

Selendra shows blockchain can serve emerging market needs through low per-transaction cost, EVM-first unified accounts and dual VM support. The hybrid consensus model produces one-second blocks and finalizes them a median of one second later, and once finalized a block does not revert. That foundation supports daily blockchain usage patterns that were previously impractical in these markets.

The EVM-first unified account architecture removes user complexity without taking flexibility away from developers. Users interact with familiar 0x... addresses through MetaMask while the runtime handles Substrate operations underneath. Developers deploy Solidity or ink! contracts without managing separate identity systems, and both reach shared liquidity and state through the same addresses. This removes the technical barriers that have kept most internet users out of blockchain systems.

Selendra brings internet users into decentralized networks through economic accessibility, with fees measured in fractions of a SEL; technical simplicity, with MetaMask-native 0x... addresses; developer freedom, with EVM and WASM support and no ecosystem lock-in; and local relevance, through use cases that solve immediate market needs.

The Cambodia-first approach is meant to prove the model somewhere specific before generalising it. Success there produces a playbook for markets facing comparable adoption barriers, and lets deployment to those regions move quickly while keeping permissionless innovation and decentralization intact.

References

1. Substrate Framework: https://substrate.io
2. AlephBFT Consensus: https://arxiv.org/abs/1908.05156
3. EIP-712 Typed Data: https://eips.ethereum.org/EIPS/eip-712
4. Phragmén Election Method: https://arxiv.org/abs/2004.12990
5. Frontier EVM Bridge: https://github.com/paritytech/frontier

Runtime Specification:

• spec_name: selendra
• spec_version: 20004 (mainnet, as of 14 August 2026; the current value is published at https://explorer.selendra.org)
• 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