Sparrow (SPW)
"Small but complete, wild and resilient."
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.
§ Abstract
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.
01 Introduction
1.1 Motivation
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.
1.2 Design Goals
- Simplicity. Every component — from the block header to the wallet — is readable by a competent programmer in a single sitting.
- Fair launch. No pre-mine, no founder reward, no investor allocation. The emission schedule intentionally starts slow so early participants have no overwhelming advantage.
- Long-term security. A tail emission ensures miners are compensated indefinitely, avoiding the fee-only security model that may threaten fixed-supply coins.
- Privacy by design. Stealth addresses are a first-class feature of the protocol, not a layer-two add-on.
- Auditability. The full reference implementation is open source. Every consensus rule is traceable to fewer than 2,000 lines of Python.
02 Protocol Overview
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:
03 Transactions
3.1 UTXO Model
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):
txid = SHA256d(JSON_canonical(inputs ∥ outputs ∥ timestamp ∥ tx_pubkey))
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.
3.2 Signing
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:
# Signing data (Python)
raw = json.dumps({
'inputs': [{'prev_txid': i.prev_txid, 'prev_vout': i.prev_vout} for i in inputs],
'outputs': [{'amount': o.amount, 'address': o.address} for o in outputs],
'timestamp': timestamp,
'tx_pubkey': tx_pubkey,
}, sort_keys=True).encode()
digest = SHA256d(raw) # 32 bytes, passed to ECDSA sign
3.3 Fees
The fee for a transaction is the difference between the total value of its inputs and the total value of its outputs:
fee = Σ(inputs) − Σ(outputs) ≥ MIN_FEE (10,000 feathers)
Fees accumulate over all non-coinbase transactions in a block and are claimable by the miner in the coinbase output, subject to:
coinbase_output ≤ block_reward(height) + Σ(fees)
04 Proof of Work
4.1 Algorithm
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:
RandomX(key, block_header) < target(bits)
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.
# Key schedule (from core/spw_rx.py)
RX_KEY_INTERVAL = 2048
rx_key(height) = f'SPW-v1-epoch-{height // RX_KEY_INTERVAL}'.encode()
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.
4.2 Difficulty Adjustment
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:
# Difficulty adjustment (simplified)
ideal = DIFF_ADJ_INTERVAL * TARGET_BLOCK_TIME # 120,960 s
actual = timestamp[height] - timestamp[height - DIFF_ADJ_INTERVAL]
ratio = clamp(actual / ideal, 0.25, 4.0)
new_target = current_target * ratio
new_bits = target_to_bits(new_target)
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.
05 Blocks & Chain
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:
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:
- Correct
prev_hash linkage to the canonical chain tip.
- Valid Proof of Work against the current
bits target.
- First transaction is coinbase; coinbase output ≤ reward + fees.
- Correct Merkle root over all transactions.
- All non-coinbase transactions individually valid (UTXO existence, signatures, fee ≥ MIN_FEE).
06 Privacy
6.1 Stealth Addresses
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:
- Spend key pair (S, s): used to spend outputs. The spend public key S is shared publicly.
- View key pair (V, v): used to scan the chain. The view public key V is shared publicly; the view private key v is used only for scanning.
6.2 ECDH Protocol
All arithmetic is performed on the SECP256k1 curve. The protocol proceeds as follows:
Stealth Payment Flow
Sender knows
V, S (recipient's public keys)
Pick random r, compute R = r·G (tx pubkey)
Compute shared secret: shared = r·V
One-time pubkey: P = H(shared)·G + S
Broadcast: output at addr(P), with R in tx metadata
Recipient scans chain
with v (view private key)
Recompute shared: shared = v·R = r·V (ECDH)
Expected pubkey: P' = H(shared)·G + S
If addr(P') = addr(P) → output belongs to me
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.
07 Emission Schedule
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:
- Reduce the advantage of genesis-era miners relative to later adopters.
- Provide a strong economic incentive for miners precisely when the network most needs security — during its growth phase.
- Sustain a long tail emission that funds mining after most SPW is issued, avoiding the cliff-edge security risk of a purely fixed supply.
7.1 Block Reward Schedule
Block reward (SPW/block) by year — 525,600 blocks/year at 60 s target
7.2 Tail Emission & Hard Cap
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:
Hard cap: 21,024,000 SPW (≈ 2.1 × 1015 feathers)
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.
08 Economics
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:
8.1 Mining Incentives
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.
8.2 Fee Market
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.
8.3 Fair Launch
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.
09 Address Format
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:
# Address derivation
private_key = random_32_bytes()
public_key = SECP256k1.multiply(private_key, G) # 33-byte compressed
hash160 = RIPEMD160(SHA256(public_key)) # 20 bytes
versioned = bytes([0x1e]) + hash160 # 21 bytes
checksum = SHA256(SHA256(versioned))[:4] # 4 bytes
address = Base58Encode(versioned + checksum) # starts with "D"
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.
10 Network API
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.
11 Security Analysis
11.1 Consensus Security
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.
11.2 Transaction Security
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.
11.3 Double-Spend Protection
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.
11.4 Privacy Threat Model
Stealth addresses protect recipient anonymity on-chain. They do not protect against:
- Network-level surveillance (IP address correlation at broadcast time).
- Exchange/custodian KYC linking.
- Amount analysis (output values are transparent).
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.
12 Extended Protocol
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.
12.1 OP_RETURN Inscriptions
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:
- Set
output.amount = 0, output.address = "", and output.data = <hex string, ≤ 160 chars>.
- Maximum one OP_RETURN output per transaction.
- Data is hex-encoded; the node will additionally try UTF-8 decode for human-readable display.
- The standard fee applies to the rest of the transaction; the zero-value output does not affect fee calculation.
Representative use cases:
- Document notarisation — hash a contract, deed, or audit report; inscribe the hash on-chain.
- SPW-native NFTs — inscribe a content hash + metadata URI.
- Domain names — register
name.spw by inscribing a JSON record.
- On-chain messages — short memos between parties, provably authored by a signing key.
// Inscription transaction output (JSON)
{
"amount": 0,
"address": "",
"data": "7b226e616d65223a22666f6f2e737077227d" // UTF-8: {"name":"foo.spw"}
}
12.2 Colored Coins
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:
- Set
tx.color_issue = "<SYMBOL>" (e.g. "GOLD").
- Mark output(s) with
color_id = "__issue__" and the desired color_qty.
- On block confirmation the node replaces
__issue__ with the actual txid.
Transfer:
- Reference the issuance txid in
output.color_id and set color_qty.
- Consensus rule: Σ color_qty(outputs) ≤ Σ color_qty(inputs). Excess is burned.
// Issuance transaction (simplified)
{
"color_issue": "GOLD",
"outputs": [
{ "amount": 99990000, "address": "Dxxx..." },
{ "amount": 0, "address": "Dxxx...", "color_id": "__issue__", "color_qty": 10000 }
]
}
12.3 Disk Impact
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.
14 Conclusion
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.
§ References
- [1] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008. bitcoin.org/bitcoin.pdf
- [2] V. Buterin, "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform," 2014.
- [3] T. E. Jedusor (pseud.), "Mimblewimble," 2016.
- [4] S. Noether et al., "Ring Confidential Transactions," Monero Research Lab Bulletin MRL-0005, 2015.
- [5] P. Todd, "Stealth Addresses," Bitcoin development mailing list, 2014.
- [6] D. J. Bernstein & T. Lange, "Analysis and Optimization of Elliptic-Curve Single-Scalar Multiplication," 2008.
- [7] NIST FIPS 180-4, "Secure Hash Standard (SHS)," 2015.
