SolarCoins — Whitepaper
The World's First Solar-Native Blockchain
Abstract
SolarCoins is a proof-of-work blockchain designed from the ground up to run exclusively on solar-powered, ultra-low-power microcontroller miners. Unlike traditional PoW networks that consume nation-scale energy budgets, SolarCoins proves that a functional, secure blockchain can be sustained on milliwatts — powered entirely by small off-grid solar panels.
Every miner in the SolarCoins network reports real-time power telemetry — voltage, current, and energy consumption — directly from hardware sensors. This data is recorded on-chain, providing cryptographic proof of energy efficiency that no other blockchain can claim.
The result: a blockchain that mines more blocks per watt than any network in existence.
1. The Problem
| Network | Energy per Block | Annual Consumption | Source |
|---|---|---|---|
| Bitcoin | ~3,350 MWh | ~176 TWh (≈ Poland) | Cambridge CBECI |
| Ethereum (pre-merge) | ~45,000 kWh | ~78 TWh | Digiconomist |
| Solana | ~0.024 kWh | ~1.9 GWh | Solana Foundation |
| SolarCoins | ~0.0002 kWh | ~17 kWh (10 miners) | On-chain telemetry |
Bitcoin consumes more electricity than most countries to secure a network that processes 7 transactions per second. The environmental cost of proof-of-work has become the primary argument against blockchain technology.
SolarCoins asks a different question: What if the mining hardware is the power system?
2. The Thesis
A blockchain can be designed where every miner is:
1. A microcontroller consuming 1–3 watts
2. Powered by a small solar panel (1–5W)
3. Reporting real energy data to the chain
4. Proving, mathematically, that the network's total energy cost is a rounding error compared to existing PoW chains
SolarCoins doesn't try to compete with Bitcoin on hashrate or security budget. It proves that useful consensus can be achieved at milliwatt scale — opening blockchain to IoT, off-grid communities, and environmental applications where energy waste is unacceptable.
3. Mining Hardware
SolarCoins defines five official miner tiers. Four are based on the Espressif ESP32 dual-core Xtensa LX6 microcontroller; the newest tier (SOLAR/1-C6) runs on the ESP32-C6 single-core RISC-V chip with WiFi 6 and hardware crypto acceleration.
3.1 SOLAR/1-ESP32 — Headless
The entry-level miner. A bare ESP32 dev board running dual-core SHA-1 proof-of-work. USB-powered, no display, no battery — the smallest possible SOLAR/1 node.
| Spec | Value |
|---|---|
| MCU | ESP32-WROOM-32 (Xtensa LX6, 240 MHz, 2 cores) |
| Hashrate | ~85 kH/s per core, ~170 kH/s total |
| Power | 1.2W active mining |
| Price | $7.00 |
3.2 SOLAR/1-CYD — Display
A visual miner built on the Cheap Yellow Display (ESP32-2432S028) — a 2.8" IPS touchscreen showing live mining stats on-board. Same compute as SOLAR/1-ESP32 with a face.
| Spec | Value |
|---|---|
| Board | ESP32-2432S028 (CYD) |
| Display | 2.8" ILI9341 320×240 IPS, resistive touch |
| Power | 2.0W (display + mining) |
| Price | $20.00 |
3.3 SOLAR/1-18650 — Off-grid
The canonical "solar coin, mined from solar" miner. An ESP32 dev board with an on-board 18650 LiIon holder and TP4056-class USB-5V charging. Paired with a small USB solar panel + a 3D-printed case, the board mines autonomously — sun charges the cell during the day, cell mines through the night.
| Spec | Value |
|---|---|
| Board | Walfront / Wemos-Lolin clone (~$4 on Amazon) or genuine LilyGO T-Energy |
| MCU | ESP32-WROOM-32 / ESP32-WROVER-B (varies by lot) |
| Battery | 18650 LiIon, ~3400 mAh recycled cells fine |
| Charging | TP4056 over USB-5V, 0.5–1 A |
| Hashrate | ~30 kH/s (same ESP32 core as SOLAR/1-ESP32) |
| Power | 1.2W mining, ~10 µA in deep-sleep between cycles |
| Telemetry | VBAT read on GPIO14 (clone) or GPIO35 (genuine T-Energy) via 2× divider; chain payload carries vbat_mv + soc_pct + power_source per share |
| Price | $4–10 board + recycled 18650 + $5 USB panel |
3.4 SOLAR/1-C6 — RISC-V WiFi 6
The next-generation miner. Built on the Seeed Studio XIAO ESP32-C6 — a thumbnail-sized board with WiFi 6, BT 5 LE, 802.15.4 (Thread/Zigbee), and native USB-C. The RISC-V core has hardware accelerators for AES, SHA, HMAC, and ECDSA. First SOLAR/1 variant that is not Xtensa.
| Spec | Value |
|---|---|
| Board | Seeed Studio XIAO ESP32-C6 (~$6 from Seeed/Mouser) |
| MCU | ESP32-C6FH4 (RISC-V single core + LP core, 160 MHz) |
| Wireless | WiFi 6 (802.11ax), BT 5 LE, 802.15.4 — Thread/Zigbee unused |
| USB | USB-C with native USB Serial/JTAG (no CP210x/CH340 bridge) |
| Hashrate | ~23.7 kH/s (bench-measured against the live primary) |
| Power | ~0.8 W mining (single-core RISC-V at 160 MHz is more efficient than dual-core LX6 at 240 MHz) |
| Crypto accel | Hardware AES, SHA-1/256, HMAC, ECDSA, RNG |
| Telemetry | No on-board battery sense yet; pad for INA219 over I2C on GPIO22 (SDA) / GPIO23 (SCL) |
| Price | $5.50 (XIAO C6 only) + optional USB panel |
3.5 SOLAR/1 Cluster Board
A custom PCB holding 10 SOLAR/1-ESP32 miners with 3D-printed enclosure — for operators who want a single deployable unit packing nearly 2 MH/s.
| Spec | Value |
|---|---|
| Miners | 10× ESP32-WROOM-32 (each running SOLAR/1-ESP32 firmware) |
| Total Hashrate | ~1.7 MH/s |
| Power | ~12W |
| Monitoring | INA219 per-rail current sensing |
| Price | $45.00 (PCB) + $15.00 (case) |
4. Energy Telemetry — Proof, Not Claims
Every share submitted to the network includes real hardware measurements:
nonce, hashrate, software, rig_id, chip_id, wallet,
power_mw, nickname, rssi_dbm, free_heap, voltage_v,
chip_temp_c, uptime_s, cpu_freq_mhz4.1 Efficiency Comparison
| Metric | Bitcoin | Ethereum (PoS) | Solana | SolarCoins |
|---|---|---|---|---|
| Energy/block | ~3,350 MWh | ~1 kWh | ~0.024 kWh | 0.0002 kWh |
| Network power | ~20 GW | ~297 kW | ~217 kW | 12 W |
| Powered by | Coal/gas | Data centers | Data centers | Solar |
| Miner cost | $5,000+ ASIC | $0 (staking) | $0 (staking) | $7 ESP32 |
SolarCoins mines a block using less energy than it takes to charge a smartphone.
5. Tokenomics — Bitcoin-parity schedule
| Parameter | Value |
|---|---|
| Max Supply | 21,000,000 SOLAR/1 (matches BTC) |
| Initial Block Reward | 50 SOLAR/1 (BTC genesis-era reward) |
| Halving Interval | Every 210,000 blocks (~4 years, matches BTC) |
| Block Time Target | 600 seconds / 10 minutes (matches BTC) |
| Pre-mine | 0% — Fair launch |
| Token Creation Fee | 100 SOLAR/1 (one-time anti-spam burn, not a tx fee) |
| Transaction Fees | $0 — see §5.3, permanent design choice |
5.1 Halving Schedule
| Era | Block Range | Reward | Era Supply | Cumulative |
|---|---|---|---|---|
| 0 | 0 – 209,999 | 50 SOLAR/1 | 10,500,000 | 10,500,000 |
| 1 | 210K – 419K | 25 SOLAR/1 | 5,250,000 | 15,750,000 |
| 2 | 420K – 629K | 12.5 SOLAR/1 | 2,625,000 | 18,375,000 |
| 3 | 630K – 839K | 6.25 SOLAR/1 | 1,312,500 | 19,687,500 |
| … | … | … | … | → 21,000,000 (asymptote = cap) |
5.2 Bootstrap Supply
Before 2026-05-19 the chain ran under a different schedule (125 base, 2M-block halvings, 500M cap) for operator testing. ~30,600 SOLAR/1 was minted in this period, entirely to the operator's own test miners — no external participation. The BTC-parity schedule above is authoritative from block 245 onward.
Cumulative supply on the live ledger reads slightly higher than what the §5.1 schedule predicts for any given height. The delta is bootstrap supply, treated as a one-time pre-launch reserve. Verifier nodes allow for this offset when checking supply invariants.
5.3 Zero Transaction Fees
Bitcoin's model is block_reward = subsidy + tx_fees: as the subsidy halves toward zero, fees take over to pay miners. SOLAR/1 takes the opposite posture. The subsidy is the entire miner reward — forever. Every transaction is free: token transfers, contract triggers, wallet sends, all zero protocol fee.
Token creation (100 SOLAR/1) and contract deployment (10 SOLAR/1) are not fees. They are anti-spam burns paid once by the issuer or deployer, never by transactors.
As halvings deepen, miner revenue declines geometrically. By era 6 (~24 years) each block pays ≈ 0.78 SOLAR/1 split across all online miners. The chain is operator-subsidized in perpetuity. Hanger8200 accepts that miner participation will decline as halvings approach the dust floor, and explicitly chooses liquidity over scarcity-as-economic-floor. A free chain attracts use; a fee chain attracts speculators. SOLAR/1 chose the first lane.
Contributors proposing a fee market are reverting an intentional design choice. Rejected at PR review.
6. Token Factory
Anyone can create custom tokens on the SolarCoins chain:
# Create a token
curl -X POST https://api.solarcoins.net/token/create \
-d '{"symbol":"GWATT","name":"GreenWatt","max_supply":1000000}'
# Mint tokens
curl -X POST https://api.solarcoins.net/token/mint \
-d '{"symbol":"GWATT","amount":500,"recipient":"alice"}'
# Transfer tokens
curl -X POST https://api.solarcoins.net/token/transfer \
-d '{"symbol":"GWATT","amount":50,"username":"alice","recipient":"bob"}'"This token was mined, minted, and transferred using zero grid electricity. Every transaction is powered by the sun. The energy data is on-chain. Verify it yourself."
7. Market — Order Book + Matching Engine
SolarCoins ships with a native, on-chain order book + matching engine. Tokens minted on the SOLAR/1 network can be traded against SOLAR/1 — the native unit — without leaving the protocol. The matcher runs server-side with the same atomicity guarantees as the rest of the chain: every fill is one Postgres transaction.
7.1 Order Types
| Type | Behavior |
|---|---|
market | Walks the opposite side of the book, consuming maker liquidity until the requested quantity is filled or the book is exhausted. Coerced to IOC — never rests. |
limit | Rests on the book at a user-specified price. Crosses immediately if the opposite side already has equal-or-better price; remainder rests. |
7.2 Time-in-Force (TIF)
| TIF | Behavior |
|---|---|
GTC | Good-til-cancelled. Resting order persists until filled or explicitly cancelled by the user. |
IOC | Immediate-or-cancel. Fill what's possible right now; cancel any unfilled remainder atomically. |
FOK | Fill-or-kill. Must fill 100% in one shot, or the entire order rejects with no balance change. |
7.3 Matching Rules
- Price-time priority: Best price wins; ties broken by oldest
created_at. - Maker price prevails: When taker crosses, the fill price is the resting maker's price — price improvement flows to the taker.
- Self-trade prevention: A taker cannot fill against a maker order owned by the same
username. (Per-pubkey identity binding is intentionally not enforced — see §7.6.) - Atomic settlement: Balance locks, balance moves, fill records, and maker/taker order updates all live inside one Postgres transaction.
7.4 Settlement — On-Chain market_settle
Every SOLAR/1 leg of a fill is recorded on the chain as a market_settle transaction signed by the network's system key with the user's pubkey as from_pubkey (analogous to the existing admin_sweep pattern for ESP32-side keys the operator can't access live). Token-side balances (non-SOLAR/1 assets) live in the token_balances table.
7.5 Escrow
SOLAR/1 locked at order-submit transits through a deterministic escrow account (__market_escrow__) whose pubkey is derived from the system signing key. The escrow's private key is never used to sign — only the system key signs market_settle txs. Supply stays closed mid-trade: every lock has a matching refund (on cancel) or credit (on fill).
7.6 Known Limitations
- Wash-trade detection is post-hoc. Two distinct accounts owned by the same human can cross — by design, the protocol has no KYC binding. Each fill records both
maker_usernameandtaker_usernamefor off-line audit. - Single matching engine. All matching runs on the primary ledger node. A future P2P matching layer is out of scope for v1.
- No partial-cancel. Cancellation always cancels the full remaining quantity. Modify orders by cancel-and-replace.
8. Smart Contracts
SolarCoins ships five parameterized contract templates executed deterministically on the ledger node. There is no on-chain VM in v1 — each template is a Python function with strict parameter validation. This keeps the attack surface tiny and the gas cost zero. Lua / WASM is deferred to a future phase if third-party developer demand justifies the complexity.
8.1 Deployment
Anyone with a signed-in account can deploy. Cost: 10 SOLAR/1 burned + the funding amount the contract needs (escrow / timed_release / vesting all lock funds at deploy time; split_payment + allowlist_gate are 0-funding). The owner signs an Ed25519 transaction over the canonical CBOR payload; the deploy fee is burned, the funding moves into a per-contract escrow pubkey derived from app_meta.escrow_root (rotation-safe — see §6 audit fix history).
8.2 Templates
| Template | Required Parameters | Trigger |
|---|---|---|
escrow | buyer, seller, arbiter, amount, deadline_unix | Arbiter approves → seller paid, or rejects → buyer refunded. |
timed_release | recipient, amount, release_at_unix | Permissionless after the deadline — anyone can trigger payout. |
vesting | beneficiary, total_amount, start_unix, duration_seconds, release_count | Permissionless ticks. Server enforces tick schedule + count cap. |
split_payment | watch_pubkey, splits[{pubkey, percent}] | Auto: every incoming transfer to watch_pubkey is fanned out per the split table. |
allowlist_gate | token_symbol, allowed_pubkeys[] | Enforced by the token-transfer path. Transfers to non-allowed pubkeys reject. |
8.3 Permissionless Triggers, Server-Enforced Conditions
Following the convention from Ethereum + Solana, trigger endpoints (POST /contracts/{id}/timed-release, POST /contracts/{id}/vesting-tick) accept calls from any authenticated user. The chain enforces the condition (deadline passed, next tick due, etc.). This matches the design intent — a vesting contract should not require the beneficiary to remember to claim; any honest party can advance the schedule. The escrow template is the exception — only the named arbiter pubkey can call resolve.
8.4 Settlement Audit Trail
Each trigger emits a system-signed contract_trigger transaction on the chain that debits the per-contract escrow and credits the recipient(s). payload.extra records {contract_id, trigger, tick_index?, decision?} so an off-chain auditor can reconstruct the exact path from deploy to payout. The escrow's pubkey is derived from app_meta.escrow_root — stable across system-key rotation — and the per-contract escrow privkey is recomputed on demand from BLAKE2s("solar/1:contract-escrow:v2:" + escrow_root + contract_id, 32).
8.5 Known Limitations
- No top-up — funding is fixed at deploy. Future revision may add
POST /contracts/{id}/fund. - No cancel / refund (matches Ethereum convention by default). The owner can't escape a deployed contract unless the template itself provides a refund path (escrow's arbiter, timed-release's deadline).
- Escrow
deadline_unixis recorded on chain but auto-refund-after-deadline is not yet enforced — arbiter resolution is the only active path in v1. - No per-contract modifiers / hooks (no Solidity-style fallback functions). The five templates are fixed.
9. Use Cases
- Off-Grid Communities — Local digital economy with solar-powered nodes
- IoT Micro-Payments — Self-funding sensor networks
- Green Energy Certification — Auditable renewable energy records
- Education — $7 entry to learn blockchain, cryptography, and embedded systems
10. Conclusion
SolarCoins is not trying to replace Bitcoin. It's proving that proof-of-work doesn't have to be wasteful. By designing the mining hardware, power system, and blockchain as a single integrated system, SolarCoins achieves consensus at a fraction of the energy cost of any existing network.
A miner costs $7. The entire network runs on a single solar panel. And every watt is accounted for, on-chain, forever.
The greenest blockchain isn't the one that uses proof-of-stake. It's the one that mines on sunlight.
SolarCoins — solarcoins.net · May 2026