SPW is a proof-of-work cryptocurrency you can mine with a CPU, send for fractions of a cent, and hold in full self-custody. No staking. No governance tokens. No bloat.
A sparrow is small — yet it navigates the world with instinct and precision. It survives winters that fell larger creatures. It builds with what it has.
SPW is built on the same philosophy. No bloated VM, no governance tokens, no venture capital. Just a clean proof-of-work blockchain with honest rules and a supply cap of 21,000,000 SPW.
1 SPW = 100,000,000 feathers. Bell-curve emission: starts at 1 SPW/block, peaks in years 5–7, then long gradual decay. Supply cap: 21,024,000 SPW.
Every design decision favours simplicity, honesty, and longevity.
RandomX Proof-of-Work with automatic difficulty adjustment every 2,016 blocks. CPU-optimized and ASIC-resistant — anyone can mine competitively. No shortcuts, no stake.
Bitcoin-style unspent transaction outputs. Clean, auditable, and resistant to double-spend. No global state, no hidden complexity.
Minimum fee of 0.0001 SPW per transaction. Miners collect fees as incentive. Cheap to use, sustainable to run.
ECDH-based one-time addresses. Recipient identity hidden on-chain. Dual spend/view key wallet keeps your finances private.
Simple JSON API for balances, UTXOs, transactions, blocks, and broadcasting. No SDK required — any HTTP client works.
Keys generated and transactions signed entirely in your browser. Your private key never leaves your device. No extension needed.
Everything you need to know about the protocol.
The SPW web wallet runs entirely in your browser. Keys are generated locally using secp256k1 — the same curve as Bitcoin. Nothing is ever sent to a server.
Where we've been, where we're going.
PoW chain, UTXO model, Merkle tree, difficulty adjustment, block halving logic.
Minimum-fee enforcement, fee collection by miners, CLI send with fee support.
Full JSON REST API. Browser wallet with in-browser key generation and signing.
Official website live. Mainnet running.
ECDH-based one-time addresses. Recipient identity hidden on-chain. Dual spend/view key wallet.
Peer discovery, block propagation, transaction relay. Multiple independent nodes.
Live address lookup — balance, UTXOs, and transaction history.
Stratum-compatible pool support so miners can work together.
Atomic swap support for peer-to-peer trading without a trusted intermediary.
Explore the network, access the API, and connect with the community.
Look up any SPW address to see its balance and full transaction history.
This page is under active development and will be live on or before Q3 2026.
We're rebuilding the mining stack — RandomX tuning, the block submission protocol, and getblocktemplate-style endpoints. Documentation and the downloadable miner client will be republished here once the v0.3 mining protocol is finalised.
Questions or early-access requests: support@spw.network
A Proof-of-Work cryptocurrency with RandomX mining, a bell-curve emission schedule, and built-in stealth address privacy — designed to be simple, auditable, and permanently censorship-resistant.
Sparrow (SPW) is a decentralized, peer-to-peer digital currency built on a Proof-of-Work consensus mechanism using RandomX — the same memory-hard, CPU-optimized algorithm as Monero — providing ASIC resistance and broad mining accessibility. It introduces a bell-curve token emission model with a hard cap of 21,024,000 SPW, providing a low-inflation bootstrap phase, a peak-growth period in years five through seven, and a long graceful decay thereafter. Transactions are secured by SECP256k1 elliptic-curve digital signatures. Optional sender-side stealth addresses based on Elliptic-Curve Diffie-Hellman (ECDH) allow recipients to receive funds without publishing a reusable public address. The minimum transaction unit is one feather (10−8 SPW), and the chain targets a 60-second block interval with automatic difficulty adjustment every 2,016 blocks.
Since the publication of Bitcoin's whitepaper in 2008 [1], the cryptocurrency ecosystem has grown enormously. Yet the fundamental promise — a permissionless, censorship-resistant medium of exchange not subject to any single authority — has often been diluted by complex governance structures, opaque pre-mines, or privacy features grafted on as an afterthought.
Sparrow is a return to first principles. It is intentionally small in scope, easy to audit, and built to survive. Like the bird after which it is named, it occupies a modest niche but does so with extraordinary resilience.
Sparrow follows the UTXO-based model pioneered by Bitcoin. Nodes maintain a chain of blocks, each containing a set of transactions. New blocks are produced by miners who perform computational work and are rewarded with freshly minted SPW. The following parameters govern the protocol:
| Parameter | Value |
|---|---|
| Coin name | Sparrow (SPW) |
| Base unit | 1 feather = 10⁻⁸ SPW |
| Hard cap | 21,024,000 SPW |
| Target block time | 60 seconds |
| Difficulty retarget | Every 2,016 blocks (~1.4 days) |
| Proof of Work | RandomX (same algorithm as Monero) |
| Signature scheme | ECDSA over SECP256k1 |
| Address prefix | D… (Base58Check, version 0x1e) |
| Privacy | ECDH stealth addresses (optional) |
| Minimum fee | 0.0001 SPW (10,000 feathers) |
| Default fee | 0.001 SPW (100,000 feathers) |
| Genesis timestamp | 2026-04-19 (Unix 1745078400) |
| API port | 8333 |
| Genesis message | Sparrow SPW 0.2.1 - RandomX PoW - Small but complete, wild and resilient. 2026-04-19 |
Sparrow adopts the Unspent Transaction Output (UTXO) model. The balance of an address is the sum of all unspent outputs locked to it. Spending requires providing a valid cryptographic signature in the transaction input.
Each transaction is identified by its txid, which is the double-SHA-256 hash of its canonical JSON serialisation (inputs, outputs, timestamp, tx_pubkey — sorted keys):
A coinbase transaction has exactly one input with prev_txid = "000…000" (64 zeros) and prev_vout = −1. It creates new SPW according to the emission schedule and may also collect transaction fees from the block.
Each non-coinbase input must carry a DER-encoded ECDSA signature and the corresponding compressed public key. The signing digest commits to all inputs (by reference only), all outputs, the transaction timestamp, and the tx_pubkey field used for stealth:
The fee for a transaction is the difference between the total value of its inputs and the total value of its outputs:
Fees accumulate over all non-coinbase transactions in a block and are claimable by the miner in the coinbase output, subject to:
Sparrow uses RandomX for block hashing — the same memory-hard, CPU-optimized algorithm used by Monero [2]. RandomX executes a randomly generated program inside a virtual machine whose working set requires approximately 256 MB of fast memory, making it prohibitively expensive to implement in custom silicon. A block is valid if its RandomX hash, interpreted as a 256-bit big-endian integer, is below the current target:
The key is derived from the block height and rotates every 2,048 blocks (~1.4 days), forcing miners to reinitialise their virtual machine periodically. This key schedule is enforced at the consensus layer and raises the amortised cost of building specialised hardware pipelines.
The bits field encodes the target in compact form (identical to Bitcoin's nBits). The genesis block uses bits = 0x200147ae, calibrated so that a single CPU core running RandomX in light mode (~24 H/s) solves the genesis block in approximately 8 seconds — accessible to any participant during network bootstrap.
Miners increment a 64-bit nonce until a valid hash is found. Unlike SHA-256d, RandomX cannot be efficiently accelerated by ASICs or FPGAs; the dominant hardware is the standard CPU, placing all participants on equal footing.
Difficulty is adjusted every 2,016 blocks (approximately 1.4 days at the 60-second target). The algorithm compares the actual time elapsed for the last 2,016 blocks against the ideal time (2,016 × 60 s = 120,960 s) and scales the target proportionally, clamped to a 4× change per interval — preventing runaway adjustments:
The 2,016-block retarget interval was chosen to match Bitcoin's proven design. At 60 s block times it fires roughly 14× more often than Bitcoin's 10-minute equivalent, keeping the network responsive to rapid hash-rate changes.
Each block consists of a header and an ordered list of transactions. The header commits to the entire transaction set through a Merkle root and chains to the previous block via its hash:
| Header Field | Description |
|---|---|
| version | Protocol version (currently 1) |
| height | Block index (genesis = 0) |
| prev_hash | RandomX hash of the previous block header |
| merkle_root | Merkle root of all txid's in this block |
| timestamp | Unix time in seconds (wall clock of miner) |
| bits | Compact target encoding |
| nonce | 64-bit miner-chosen value |
The Merkle tree is built by repeatedly hashing pairs of txid's (SHA-256d) until a single 32-byte root remains. An odd number of leaves is handled by duplicating the last element — identical to Bitcoin's construction [1].
Block validation enforces:
prev_hash linkage to the canonical chain tip.bits target.A major privacy weakness in transparent blockchains is address reuse: every payment to a public address is permanently linkable on-chain. Stealth addresses, as pioneered by Peter Todd and later refined in Monero [4], allow a sender to derive a one-time address from the recipient's published public keys. The output then appears on-chain at that one-time address, which cannot be linked to the recipient's wallet without the recipient's private view key.
In Sparrow, stealth address support is optional and sender-initiated. A wallet may publish a dual-key stealth address consisting of:
All arithmetic is performed on the SECP256k1 curve. The protocol proceeds as follows:
The hash function H maps the shared EC point to a scalar: H(point) = SHA-256(x-coordinate). Spending requires the recipient to know their spend private key s, computing the one-time private key as p = h + s (mod N) where h = H(shared) as an integer.
Privacy guarantee: An external observer sees only the one-time address addr(P) on-chain. Without the recipient's view private key v, they cannot determine which wallet controls the output, nor link multiple payments to the same recipient.
Sparrow departs from Bitcoin's simple halving schedule in favour of a bell-curve emission: block rewards start intentionally low during the bootstrap phase, rise to a peak in years 5–7, then decay gradually over two decades. This design serves three goals:
| Period | Block Reward | Blocks | SPW Minted | Cumulative % |
|---|---|---|---|---|
| Year 0–4 (bootstrap) | 1.0 SPW | ~2,102,400 | ~2,102,400 | ~10% |
| Year 4–5 | 3.0 SPW | ~525,600 | ~1,576,800 | ~17% |
| Year 5–7 (peak) | 5.0 SPW | ~1,051,200 | ~5,256,000 | ~42% |
| Year 7–8 | 3.0 SPW | ~525,600 | ~1,576,800 | ~49% |
| Year 8–9 | 1.8 SPW | ~525,600 | ~946,080 | ~54% |
| Year 9–10 | 1.2 SPW | ~525,600 | ~630,720 | ~57% |
| Year 10–12 | 2.5 SPW | ~1,051,200 | ~2,628,000 | ~69% |
| Year 12–14 | 2.0 SPW | ~1,051,200 | ~2,102,400 | ~79% |
| Year 14–16 | 1.5 SPW | ~1,051,200 | ~1,576,800 | ~87% |
| Year 16–18 | 1.0 SPW | ~1,051,200 | ~1,051,200 | ~92% |
| Year 18–20 | 0.5 SPW | ~1,051,200 | ~525,600 | ~95% |
| Year 20+ (tail) | Halving every 2 yr | ∞ | → 0 | → 100% |
After year 20, the reward halves every two years starting from 0.5 SPW, converging to zero asymptotically (with a floor of 1 feather to keep the schedule well-defined). The geometric series of tail halvings contributes approximately the remaining ~5% toward the hard cap:
Unlike Bitcoin's eventual fee-only security model, Sparrow's perpetual tail emission guarantees miners always receive some block subsidy, preserving the economic incentive to honest-mine even if transaction volume is low.
The economic security of any PoW chain rests on the assumption that the cost of mounting a 51% attack exceeds the expected gain. Sparrow's economic model addresses this through several mechanisms:
Block rewards follow the bell-curve schedule detailed in §7. The peak reward (5 SPW/block in years 5–7) coincides with the expected period of maximum adoption, when the cost of acquiring SPW — and thus the economic value of an attack — is likely to be highest. By concentrating emission during this window, Sparrow maximises miner revenue precisely when network security matters most.
A mandatory minimum fee of 10,000 feathers (0.0001 SPW) per transaction prevents spam and provides a floor for miner revenue independent of the block subsidy. As the chain matures and block rewards decline, the fee market is expected to organically compensate miners. The default wallet fee is 100,000 feathers (0.001 SPW), providing headroom for future fee bidding in congested blocks.
There is no pre-mine, no team allocation, and no venture-capital distribution. The genesis block contains a single coinbase transaction paying the node operator who mines it — just as Bitcoin's genesis block paid Satoshi Nakamoto. The first four years of low rewards (1 SPW/block) ensure that any early miner does not accumulate a disproportionate fraction of total supply before the ecosystem is established.
Sparrow addresses follow the Base58Check encoding used by Bitcoin, with a version byte of 0x1e — chosen so that encoded addresses begin with the capital letter D.
Derivation from a private key:
Wallet files are stored as JSON containing the WIF-like private key, the compressed public key, and the derived address. Stealth wallets additionally store separate view and spend key pairs.
The Sparrow node exposes a REST API on port 8333 (proxied at https://spw.network/api/). All endpoints return JSON. The API is stateless and read-only except for transaction broadcast and the embedded wallet endpoint.
| Endpoint | Description |
|---|---|
GET /chain/info | Height, difficulty, best hash, mempool count, next reward |
GET /block/latest | Full latest block (header + transactions) |
GET /block/<height> | Block by height |
GET /block/hash/<hash> | Block by header hash |
GET /tx/<txid> | Transaction by txid |
GET /balance/<address> | Confirmed balance (SPW + feathers) |
GET /utxos/<address> | Unspent outputs for address |
GET /mempool | Pending unconfirmed transactions |
POST /tx/broadcast | Submit a signed transaction |
GET /explorer/<address> | Balance + full transaction history |
GET /scan/<view_pub>/<spend_pub> | Scan UTXO set for stealth outputs |
GET /miner/stats | Live hash rate, blocks found, CPU limit |
GET /wallet | Embedded browser wallet application |
GET /inscriptions | List OP_RETURN inscriptions (paginated) |
GET /inscription/<txid>/<vout> | Single inscription by output reference |
GET /color/<color_id> | Colored-coin token info (symbol, supply) |
GET /color/utxos/<address> | Colored UTXOs grouped by token for address |
As in any longest-chain PoW system, an attacker controlling more than 50% of the network hash rate could rewrite recent history. The economic cost of such an attack scales with the total hardware and electricity investment of the honest miners, providing a quantifiable security bound. The bell-curve emission is designed so that this cost is maximised during the network's most vulnerable growth period.
Signatures use ECDSA over SECP256k1 with 256-bit security. Forgery requires solving the elliptic curve discrete logarithm problem (ECDLP), which is computationally infeasible with current and near-future classical hardware. The signing digest includes tx_pubkey, preventing signature replay across stealth and non-stealth transactions.
Each UTXO is marked spent atomically when the containing block is committed to the database. Chain reorganisations are handled by the longest-chain rule: any fork shorter than the canonical chain is discarded. Merchants should wait for sufficient confirmations — recommended: 6 blocks (~6 minutes) for moderate-value transactions, proportionally more for high-value transfers.
Stealth addresses protect recipient anonymity on-chain. They do not protect against:
Future protocol versions may introduce Pedersen commitments or range proofs (as in Mimblewimble [3] or Monero's RingCT [4]) to hide amounts. These are out of scope for v0.2.
Version 0.2 ships two opt-in protocol extensions that add expressive power to the base layer without changing consensus for plain SPW transfers. Both are implemented and active on mainnet.
Any transaction may embed up to 80 bytes of arbitrary data in a single zero-value output. The output is provably unspendable (amount = 0, no address) and is stored in a dedicated inscriptions index rather than the UTXO set, so it imposes no lasting burden on the live coin state.
Encoding rules:
output.amount = 0, output.address = "", and output.data = <hex string, ≤ 160 chars>.Representative use cases:
name.spw by inscribing a JSON record.Colored Coins allow any UTXO to carry an additional integer quantity of a user-defined token alongside its SPW amount. The token type is identified by the txid of its issuance transaction (color_id). Token units obey a strict conservation rule enforced at the consensus layer.
Issuance:
tx.color_issue = "<SYMBOL>" (e.g. "GOLD").color_id = "__issue__" and the desired color_qty.__issue__ with the actual txid.Transfer:
output.color_id and set color_qty.Both extensions add minimal on-chain overhead. An OP_RETURN inscription adds at most ~120 bytes to the transaction record. A colored-coin output adds two integer columns to the UTXO row (≈16 bytes). At 10% adoption across a 20 tx/block rate, the combined additional storage over ten years amounts to less than 3% of base-chain data.
| Phase | Target | Milestone |
|---|---|---|
| Phase 0 Genesis | Q2 2026 | Mainnet launch · Genesis block mined · REST API live · Browser wallet deployed · spw.network online |
| Phase 1 Foundation | Q3–Q4 2026 | P2P gossip protocol · Multi-node testnet · CLI full-node binary · SPW Explorer public launch |
| Phase 2 Growth | 2027 | Mobile wallet (iOS & Android) · Hardware wallet integration · First exchange listing · Mining pool protocol |
| Phase 3 Privacy+ | 2028 | Confidential transactions · Tor/I2P network transport · Atomic swap support (BTC ↔ SPW) |
| Phase 4 Maturity | 2029+ | Layer-2 payment channels · Mining pool protocol · Formal specification & independent audit |
Sparrow is a lean, auditable, and privacy-aware Proof-of-Work currency. Its design inherits Bitcoin's proven primitives (UTXO model, SECP256k1, Base58Check, 2,016-block retarget) while introducing meaningful improvements: RandomX mining for ASIC resistance and broad CPU accessibility, a bell-curve emission that rewards later miners fairly, built-in ECDH stealth addresses that protect recipient privacy without requiring a trusted setup, and a tail emission that keeps the chain economically secure indefinitely.
Version 0.2 extends the base protocol with two opt-in layers — OP_RETURN inscriptions and Colored Coins — all enforced at the consensus layer with no trusted third parties.
The codebase is intentionally small. Simplicity is not a limitation — it is the feature. A system that can be fully understood by a single developer in a weekend is a system that can be trusted, audited, forked, and improved by the community it serves.
Like the sparrow: small but complete, wild and resilient.
Questions, contributions, and partnership inquiries: support@spw.network
Source code and live chain data: spw.network/api/
Products and services powered by Sparrow. Real utility, native payments, no middlemen.
/api/balance/{addr}./api/explorer/{addr} until the expected UTXO appears with ≥1 confirmation.