I built a small Proof-of-Work cryptocurrency called Sparrow (SPW) as a long-running side project. CPU-mineable (RandomX), Bitcoin-style UTXO ledger, optional stealth addresses, no pre-mine, no VC, no governance token. Mainnet has been running since April 2026. This post is about the design choices and what I'd do differently.

Why bother building another chain?

Most of what gets called a "blockchain project" in 2025–2026 is one of three things:

1. A high-FDV token launch with a small fraction unlocked at TGE and a reserved investor allocation that vests over years.
2. A fork of an L1 with a different validator set and a token re-skin.
3. A meme.

That's fine — the market wants those. But there is essentially no one shipping the original idea any more: a fixed-supply, proof-of-work, individually-mineable, cryptocurrency-shaped cryptocurrency. Bitcoin became infrastructure for institutions. Monero is solid but mandatory privacy puts it in a regulatory category I don't want to inherit. Kaspa is interesting but goes after a different design space (high TPS, BlockDAG).

So I built Sparrow as a deliberately small project: the kind of chain a single developer can read end-to-end in an afternoon. Roughly:

spw_chain/
├── config.py        ~80 lines  — constants, emission schedule
├── core/            ~700 lines — Block, Transaction, Chain, Merkle
├── storage/         ~250 lines — sqlite-backed UTXO + chain index
├── wallet/          ~400 lines — keys, BIP39, BIP32, stealth
├── api/             ~300 lines — Flask REST endpoints
├── miner.py         ~120 lines — local PoW miner
├── miner_client.py  ~500 lines — remote miner (talks REST)
└── sparrow.py       ~260 lines — CLI entry point

Total: about 2,500 lines of Python you can audit yourself. That is, in itself, a feature in 2026.

Design decision 1: RandomX over SHA-256

Bitcoin uses SHA-256d — beautiful in 2009, but in 2026 it means ASIC farms, electricity contracts, and a barrier to entry that's already keeping out anyone who isn't running a hosted facility.

The alternative I picked was RandomX, the same algorithm Monero uses. The short version of why:

• CPU-optimized: it's designed to make CPUs the fastest hardware, not GPUs or ASICs.
• Memory-hard: ~2 GB of memory per VM in fast mode. ASIC economics don't work when you need that much DRAM.
• Battle-tested: it's been live in production on Monero for years.

Hooking it in was almost embarrassingly simple — RandomX has a clean Python binding:

import randomx, hashlib

def pow_hash(header_bytes: bytes, key: bytes) -> bytes:
    vm = randomx.RandomX(key)
    return vm.calculate_hash(header_bytes)

def block_hash(raw: bytes) -> str:
    # txid / Merkle still uses SHA-256d (cheap, well-understood)
    return hashlib.sha256(hashlib.sha256(raw).digest()).hexdigest()

The mining loop is the obvious one: increment the nonce, hash, compare against the target. The interesting part isn't the loop — it's that the loop is winnable on a laptop. I tested with a 2020 ThinkPad and it found blocks on testnet. That's the whole point.

The trade-off you're accepting: hashrate will be lower than a SHA-256 chain at the same valuation. That's fine for a network whose pitch is "individuals can participate," not "secure trillions of dollars."

Design decision 2: UTXO over accounts

Ethereum-style account models are easier to reason about for smart contracts. UTXO is easier to reason about for money. I went with UTXO because:

• It composes trivially with multi-input/multi-output transactions, change addresses, CoinJoin-style protocols, and stealth addresses.
• The validation logic is local — each input only depends on its referenced output.
• It plays well with how Bitcoin wallets, hardware wallets, BIP standards, etc. already work.

The internal representation is straightforward — outputs, inputs, transaction:

@dataclass
class TxOutput:
    amount:  int           # in feathers (10^-8 SPW)
    address: str           # Base58Check, version 0x1e

@dataclass
class TxInput:
    prev_txid: str
    vout:      int
    script_sig: str        # ECDSA signature over signing_data()
    pubkey:    str

@dataclass
class Transaction:
    inputs:  list[TxInput]
    outputs: list[TxOutput]
    # txid = SHA-256d(canonical_bytes)

The chain stores UTXOs in a SQLite table indexed by (txid, vout) plus a secondary index on address. That's enough for a balance lookup at REST API speed:

def get_balance(self, address: str) -> int:
    row = self.cursor.execute(
        "SELECT COALESCE(SUM(amount), 0) FROM utxos WHERE address = ?",
        (address,)
    ).fetchone()
    return row[0]

No fancy state tree, no Merkle Patricia, no per-account journaling. SQLite is the boring, reliable answer for a chain you intend to keep small.

Design decision 3: A bell-curve emission

Bitcoin's halving has interesting properties — predictable supply, decreasing inflation, long-term scarcity — but it also front-loads almost all coin issuance into the early years. By the time most people heard about Bitcoin in ~2017, ~80% of supply was already mined.

Sparrow uses a bell-curve schedule instead:

# Block reward by year (1 SPW = 10^8 feathers, blocks per year ≈ 525,600)
EMISSION_TABLE = [
    (1*BPY,  1.0),  # year 0–1: bootstrap
    (2*BPY,  1.0),  # year 1–2: bootstrap
    (3*BPY,  1.0),  # year 2–3: bootstrap
    (4*BPY,  1.0),  # year 3–4: bootstrap → ≈10% of supply
    (5*BPY,  3.0),
    (6*BPY,  5.0),  # ← peak years 5–7
    (7*BPY,  5.0),
    (8*BPY,  3.0),
    # ... gradual decline through year 20, then tail emissions
]

The intent: the first four years are intentionally low so the project has a long, fair on-ramp. Whoever shows up early doesn't get a windfall just for being early — they get rewarded for staying. The peak comes later, when you can reasonably hope the network has actually attracted some hashrate.

Total supply: 21,024,000 SPW. (Bitcoin's number, plus 24,000 — partly a nod, partly to avoid being mistaken for a Bitcoin clone.)

Design decision 4: Optional stealth addresses

Privacy is a spectrum. The two ends are:

• Bitcoin: every transaction publicly traceable. Convenient, regulator-friendly, weak privacy.
• Monero: every transaction private by default. Strong privacy, strong regulatory headwinds, listings problems.

I wanted the middle. Sparrow uses opt-in ECDH stealth addresses: you can publish a "view public key" + "spend public key" pair. Senders use ECDH with your view key to derive a one-time output key on the chain. Only you can recover the spend key for it; an outside observer sees a totally fresh address.

The recipient's wallet has two private keys:

spend_key  →  authorises spending UTXOs (keep secret, ever)
view_key   →  scans the chain for incoming stealth payments
              (can be shared with an auditor/accountant for read-only access)

The default user experience is unchanged — Bitcoin-style transparent addresses. Privacy is something you opt into per receive, not something the network forces on every transaction. That keeps the protocol out of the privacy-coin regulatory bucket while still giving people a real privacy tool when they want one.

Design decision 5: Boring, Bitcoin-shaped addresses

Sparrow addresses are Base58Check, version byte 0x1e, which produces addresses starting with D:

DAhg6h7yEsGJsH8aZqwS3FbBRG4vJVdAZf

Why not bech32? Because every wallet, hardware wallet, parser, and block explorer in the world already knows how to handle Base58Check. I didn't want users to copy an address into a tool that breaks because it doesn't know about a custom HRP.

The HD wallet path is BIP44 standard:

m / 44' / 1926' / account' / 0 / index
       ^------ pending SLIP-0044 registration

You can import your 12-word BIP39 mnemonic into the SPW wallet, derive the same chain of addresses you'd derive anywhere else, and your existing mental model just works.

What I'd do differently

A few things in retrospect:

• P2P first. Right now the reference node at spw.network is the canonical chain, which is fine for an early single-operator phase but obviously isn't decentralised yet. If I started over I'd ship libp2p-based gossip in week one rather than as roadmap item six.
• Write tests, not docs first. I wrote a lot of design notes. The test suite is decent but should have been the first artifact, not the last.
• Pick one language for the whole stack. Chain is Python, wallet is vanilla JS, the connect SDK is also JS. Having two languages was fine but the friction during refactors was real.

What's actually shipped vs not

Honest about state:

The chain works. The decentralisation story is incomplete. I'd rather say that out loud than pretend otherwise.

If you want to try it

It's CPU-mineable — that's the whole point. You can be on the network in one line:

# Linux / macOS
curl -fsSL https://spw.network/install-miner.sh | bash

# Windows (PowerShell)
iwr -useb https://spw.network/install-miner.ps1 | iex

The installer creates a virtualenv, drops in the miner client, generates a wallet (with backup), and writes a start.sh you can run whenever. Rewards land at your address as blocks land.

• Site: spw.network
• Whitepaper: spw.network/whitepaper.html
• Wallet (open-source): github.com/otisaipro/spw-wallet

A note on what this is and isn't

Sparrow is an experimental open-source PoW network. The network value depends on adoption that has not happened yet. There are no exchange listings. The code is open and the rules are fixed, but a small network can stay small.

Treat any SPW you mine or receive as exactly that — an experiment in whether a small, fair-launch, CPU-mineable cryptocurrency can still exist in 2026. If you've got a laptop and want to find out, the door's open.

If you've shipped something similar (or want to argue with a design choice above), I'd genuinely like to hear it — drop a comment.