System Architecture

5.1Sharding — 100 Dynamically Rebalanced Shards

The network operates 100 parallel shards, each capable of processing up to 1,000 transactions at once, for a theoretical ceiling of 100,000 transactions per second. An on-chain learning system, referred to throughout this document as DALI (Decentralised Adaptive Learning Intelligence), rebalances which validators are assigned to which shard once an hour, using a reinforcement-learning technique called Q-learning. A coordination mechanism called Prime Shard Braiding handles transactions that span more than one shard, adding roughly 2 milliseconds of latency and reaching full cross-shard finality in about 8 seconds.

The intuition behind Q-learning is straightforward: the system tries different shard assignments, observes which ones produce better throughput and more even load, and gradually shifts toward the assignments that work best — without anyone needing to hand-tune the rules.

Q(s,a) ← Q(s,a) + α · [R(s,a) + γ · max Q(s′,a′) − Q(s,a)]
R(s,a) = TPS_shard / Latency_shard − Gini_load

Here, Q(s,a) is the system's running estimate of how good a given shard assignment action a is in a given network state s; α controls how quickly new observations update that estimate; γ controls how much weight is given to future consequences versus immediate ones; and the reward R(s,a) increases with throughput per unit of latency on a shard and decreases with Gini_load, a standard measure of how unevenly transaction load is spread across shards. In plain terms: the algorithm is rewarded for fast, evenly distributed shards and penalised for lopsided ones.

5.2Consensus Overview

Block production uses Proof of Entropy Minima (PoEM), described fully in Section 6. Three supporting mechanisms round out consensus: Cross-Shard Merged Mining (CSMM), which lets a single miner contribute proof-of-work toward multiple shards in parallel, cutting per-shard overhead by an estimated 30–40%; the Deterministic Finality Protocol, which reaches full cross-shard finality in roughly 8 seconds through Prime Shard Braiding; and a GHOST fork-choice rule, which serves as a backstop for the rare residual conflict, in practice resolving fewer than 0.01% of all blocks in well under a second.

5.3PIM-VM — A Virtual Machine That Adapts to Its Hardware

PIM-VM is the protocol's single execution engine — there is no separate Layer-2 system and no second virtual machine bolted on for constrained devices. It automatically selects between two execution modes depending on the hardware it is running on, while guaranteeing that both modes produce exactly the same effect on the ledger.

5.3.1Design Rationale

This design synthesises four threads of published research, summarised in Section 3: Minima's principle that a blockchain's execution engine should be small enough to fit in silicon [1]; the empirically established 256 KB RAM threshold separating pure-interpreter deployments from ahead-of-time-compiled ones [4]; DTVM's staged "lazy" compilation strategy, which recompiles frequently used contracts to optimised code in the background rather than up front [3]; and broader WebAssembly-for-edge-computing research establishing that portability and sandboxed security are worth more than raw execution speed for distributed financial infrastructure [6][7].

5.3.2The Two Modes, Side by Side

Every device tier, regardless of mode, achieves full ownership sovereignty — meaning even the cheapest microcontroller verifies its own coin ownership independently, without trusting a more powerful node's word for it. What differs across tiers is how much of the network's collective computation — full machine-learning inference, ring-signature generation for advanced privacy — each tier is capable of performing directly versus verifying through a published cryptographic commitment.

5.3.3The Shared Host API — Where Determinism Is Actually Enforced

The Shared Host API is the single interface through which both execution modes interact with every protocol primitive: creating and spending ledger objects, submitting energy proofs, querying market data, deriving privacy addresses. A contract running in Lite Mode and the same contract running in Full Mode, calling the same Host API function, produce byte-for-byte identical effects on the ledger. This is the precise mechanism that lets a constrained RISC-V node and a GPU validator participate as full equals: determinism is enforced at this interface boundary, not somewhere inside each execution engine separately, so there is no risk of the two modes silently drifting apart over time.

Among the functions exposed through this interface is one that queries a market-liquidity signal computed entirely from on-chain trading-pool data — available identically on a $3 device and a GPU validator, refreshed and cryptographically committed roughly every four minutes. This signal, described fully in Section 7, is one of the five inputs to the protocol's currency-issuance calibration formula.

5.3.4Hardware-Specific Optimisations

Four optimisations target RISC-V hardware specifically, since much of the protocol's intended rural and IoT deployment runs on this architecture: ahead-of-time compilation of lightweight contracts into native RISC-V machine code at node startup, removing interpreter overhead; use of RISC-V's vector extensions to run the compressed local inference model 4–8 times faster on supporting cores; proposed future custom instructions for accelerating the cryptographic hash operations used in Merkle proofs and zero-knowledge circuits; and integration with RISC-V's built-in power-saving modes, targeting under 5% CPU duty cycle on a 10–20 watt board.

5.3.5How PIM-VM Compares to Other Blockchain Virtual Machines

5.4Networking

Network communication uses the QUIC protocol, chosen for its 8–10 millisecond latency over UDP and its suitability for 2G and 4G mobile connections common in the protocol's target regions. Bandwidth-saving techniques include adaptive Bloom filters (100–300 bytes) and zstd compression, cutting payload size by 50–70%, with peer discovery handled by the widely used libp2p library across networks of 1,000–10,000 nodes. Each node announces its virtual-machine mode capability as part of its network identity, which the DALI system uses as a routing input when dispatching contract calls. Privacy-mode transactions additionally use staged gossip propagation (Dandelion++) to obscure which node originated a given transaction from passive network observers.

5.5Storage

State is pruned using the Merkle Mountain Range structure described in Section 3.1, reducing storage growth to roughly 8.5–12.5 GB per year with compact proofs of just 4–8 KB. Standard transactions and privacy-mode transactions share this same proof structure; privacy-mode transactions are recorded on-chain as auditable "Private Tx" records in which the presence of the transaction is public but the sender, recipient, and amount are cryptographically obscured. Local node storage requirements range from 1–5 GB depending on tier.

5.6The Sovereign Edge Layer — Full Specification

The Sovereign Edge Layer (SEL) is the protocol's formal answer to the sovereignty gap described in Section 2.7: a fifth node tier, sitting below the mobile and IoT tier, that achieves complete ownership sovereignty on hardware too constrained to run a traditional hardware security module.

5.6.1What Qualifies as an SEL Node

An SEL node is any device meeting four minimum requirements: at least 256 KB of RAM, the empirically established floor for running a pure WebAssembly interpreter [4][9]; the ability to perform Transaction Proof-of-Work at a calibrated difficulty; a source of hardware-rooted identity, with an SRAM-based physically unclonable function as the minimum bar and stronger options (Ring Oscillator or Arbiter PUFs, ARM TrustZone, or a TPM if present) preferred; and basic network connectivity, which may be intermittent, LoRa-based, or 2G. This covers, among other devices, ESP32 boards ($3–5), nRF52840 boards ($4–8), Raspberry Pi Zero 2W units (~$15), any Android smartphone, and any RISC-V development board meeting the RAM threshold.

5.6.2How a Device Proves Its Identity Without a Security Chip

At enrollment, a device samples its own physically unclonable function response — for example, the random pattern its SRAM cells settle into when first powered on. Because this pattern can vary slightly with temperature or voltage, a well-studied correction technique called a "fuzzy extractor" converts the noisy raw response into a stable 256-bit value, using publicly published "helper data" that does not itself reveal the underlying secret. That stable value is then used to derive a quantum-resistant signing key. An attacker who obtains the helper data still cannot derive the key without physical access to that exact chip, because the underlying variation is a property of the silicon itself and cannot be modelled or simulated externally [34].

raw_response  = sample_puf()                      // e.g. SRAM power-up pattern
stable_seed   = fuzzy_extractor(raw_response)      // corrects for noise; helper data is public
signing_key   = derive_key(hash(stable_seed, "pim-sel-signing-key-v1"))

The hardware itself is classified at enrollment into one of three calibration tiers based on its measured capability:

5.6.3Energy Reporting Without a Hardware Security Module

Rather than measuring real-world power consumption directly — which would require dedicated metering hardware unavailable on cheap devices — an SEL node proves it performed a known amount of computational work with a known energy cost on its specific hardware class. This Computational Energy Attestation (CEA) is signed with the device's hardware-derived key and submitted every 12 hours, the same reporting cadence used by stronger node tiers.

In dense deployments — agricultural sensor networks, factory floors — nearby SEL nodes may optionally route their attestations through a stronger coordinator node, which aggregates them into a single certificate while preserving each device's individual signature for accountability. This aggregation is purely a network-efficiency optimisation: a device that submits its attestation directly retains exactly the same security and participation status as one that uses a coordinator.

5.6.4Local Decision-Making — Lite DALI

5.6.5The Sovereignty Guarantee, Stated Formally

Formal guarantee. An SEL node independently verifies every transaction that affects its own coins, using Merkle proofs checked against publicly available data. It does not trust any other node, at any tier, for the validity of its own coin ownership. For network-wide decisions it cannot compute on its own — full-scale inference, cross-shard coordination, advanced ring-signature generation — the SEL node verifies a published cryptographic commitment rather than simply accepting another node's raw output. This is the same sovereignty principle as Minima's embedded node design [1], extended here to a protocol with substantially more capability, through a formally specified and graduated participation model.