Introduction

Why financial infrastructure needs to be rebuilt from the edge inward

In 2008, Satoshi Nakamoto proposed a system of electronic cash that needed no bank or intermediary to operate [27]. That idea has only been partially realised. Bitcoin, the system Nakamoto built, processes about 7 transactions per second and consumes close to 150 terawatt-hours of electricity annually — figures that put it out of reach for the populations who most need an alternative to traditional banking. The stablecoin market that grew up around this gap, now worth roughly $270 billion, solved the price-volatility problem but introduced a different one: more than 99% of that market is denominated in US dollars [22], meaning that emerging economies adopting these instruments are quietly importing American monetary policy rather than building their own.

Pim Protocol starts from a different premise: that financial infrastructure for underserved populations has to be scalable, secure against future threats, verifiably backed by something real, and — critically — cheap enough to run on the hardware those populations can actually afford. These four requirements are usually treated as a list of trade-offs. This protocol treats them as a single design problem.

1.1The Hardware Problem Nobody Solves at the Base Layer

Every blockchain has to choose a virtual machine — the software environment that executes its smart contracts. Powerful virtual machines, like the Ethereum Virtual Machine or a fully featured WebAssembly runtime, offer rich programmability but need megabytes of memory and meaningful processing power, which rules out the cheapest IoT devices. Minimal scripting engines run on almost anything but cannot support the kind of applications — identity systems, escrow, machine learning inference, automated trading — that a modern financial system needs. No blockchain has resolved this without bolting on a second, separate layer.

This gap is concrete, not theoretical, for the hardware this protocol targets: IoT sensors with under 256 KB of RAM cannot run a standard WebAssembly runtime; solar-powered rural nodes running on 10–20 watts need to keep their processors mostly idle to conserve power; drone flight controllers need execution that never pauses unpredictably for garbage collection; and embedded chips often cannot spare even five megabytes for a virtual machine.

There is a second, less obvious problem underneath this one: most blockchains solve hardware fragmentation by having weak devices simply trust stronger ones to do the heavy computation and report back the answer. That is a practical compromise, but it reintroduces exactly the kind of trust dependency that decentralised systems are meant to remove. A genuinely sovereign node — the term used throughout this document — is one that checks everything affecting its own assets itself, without taking anyone else's word for it. Pim Protocol's answer to this is the Sovereign Edge Layer, described in Section 5, which gives full sovereignty to devices as inexpensive as a $3–5 ESP32 microcontroller, without requiring a hardware security chip.

1.2The Privacy Problem for Ordinary People

Most high-throughput public blockchains record every transaction in the open by default. For the population this protocol is built for, that is not an abstract concern: it means family remittances, small business payments, and routine machine-to-machine transactions are all permanently visible to anyone who looks. The privacy technologies that exist to solve this — Monero's mandatory ring signatures, MimbleWimble's transaction aggregation, or zero-knowledge systems like those used by Zcash — each carry costs (computational weight, loss of programmability, or both) that make them unsuitable for a protocol that has to run on a $3 microcontroller as comfortably as it runs on a GPU server.

A further gap in how other protocols treat privacy is economic: privacy is almost always pure overhead, a cost the network absorbs with no offsetting benefit. Pim Protocol instead routes its privacy fees directly into shrinking the QOL currency supply and into a dedicated reserve, so that the more people use privacy, the more that activity reinforces monetary stability rather than just adding load to the network.

1.3What Pim Protocol Sets Out to Do

Pim Protocol aims to deliver Nakamoto's original idea more completely: a decentralised cash system that actually fits in a phone, a car, a drone, or a $3 sensor; that holds its value through a graduated, transparent process rather than a blunt on/off switch; that responds to genuine network demand instead of an arbitrary schedule; that resists both today's computers and tomorrow's quantum computers; that runs on a virtual machine small enough to fit in silicon; that gives true ownership sovereignty even on the cheapest hardware; and that offers privacy when privacy is wanted, without forcing it on everyone.

1.4Design Objectives

• Throughput: 15,100–100,000+ transactions per second via 100 dynamically managed shards.
• Energy efficiency: 0.00034 kWh per transaction, with a target of 85% renewable-powered nodes by 2030.
• Price stability: the QOL currency targets 1–2% daily volatility and 0.2–0.6% annual inflation, governed by a four-state graduated circuit breaker rather than a binary halt.
• Mobile and IoT participation: full transaction validation on devices with 1.5–3 GB of RAM.
• Edge sovereignty: full coin ownership verification on devices with as little as 256 KB of RAM — the class of hardware used in ESP32 and nRF52840 microcontrollers — without a hardware security module.
• Post-quantum security: all cryptographic signing and key exchange uses NIST-standardised post-quantum algorithms from the very first block, not as a future upgrade.
• Verifiable energy backing: nodes capable of stronger cryptography submit verifiable proof of their energy costs every 12 hours; constrained devices submit a lighter equivalent. The network requires at least 85% participation in this reporting before the currency's monetary policy can return to normal after a stress event.
• Native governance objects: all governance, staking, and asset records live natively on the ledger under a single object-based model — described fully in Section 5 — rather than as bolt-on smart contracts.
• Adaptive execution: one virtual machine, two execution modes, sharing a single interface so that a microcontroller and a server enforce identical rules.
• Optional privacy: an opt-in privacy mode available on every device tier, with fees that reinforce rather than drain the system.