Sparrow (SPW)

§ Abstract

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):

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:

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:

Fees accumulate over all non-coinbase transactions in a block and are claimable by the miner in the coinbase output, subject to:

04 Proof of Work

4.1 Algorithm (RandomX)

Sparrow uses RandomX [8] as the block-header Proof-of-Work function. RandomX is a memory-hard, CPU-optimised algorithm designed for ASIC-resistance through randomly-generated programs executed on a virtual machine backed by a ~2 GiB dataset (or a ~256 MiB cache in light mode). It is the same algorithm used by Monero since 2019.

A block is valid if the RandomX hash of its header, interpreted as a 256-bit big-endian integer, is strictly less than the current target:

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, ~200 expected hashes) solves the genesis block in roughly 8 seconds — accessible to any participant during network bootstrap. Miners increment the 64-bit nonce until a valid hash is found; when the nonce space is exhausted the miner refreshes timestamp and/or modifies coinbase_data (which forces a new merkle_root) and continues the search (see §4.5).

4.2 RandomX Key Schedule & Mode Agreement

RandomX requires a key which seeds the dataset. Sparrow rotates this key every 2,048 blocks (≈1.4 days) forcing miners to periodically re-initialise their VM — raising the fixed cost of a specialised ASIC pipeline:

Light vs. fast mode. RandomX guarantees bit-exact output equality between light and fast modes for the same (key, input) pair. Consensus therefore does not mandate a specific mode: the reference node uses light mode (≈24 H/s per core, ~256 MiB RAM) for validation of submitted blocks; miners typically use fast mode for throughput. Either is acceptable as long as the implementation conforms to the official RandomX specification [8].

4.3 Block Header Byte Encoding

The input consumed by RandomX is the concatenation of the seven header fields, each rendered as its decimal ASCII or lowercase-hex ASCII text form, in the fixed order below, then UTF-8 encoded. There are no fixed-width binary fields, length prefixes, or separators — the inputs are string-juxtaposed directly. This is an intentional departure from Bitcoin's little-endian 80-byte header and is chosen for auditability: every intermediate value is human-readable.

4.4 Coinbase Construction

The first transaction of every block is a coinbase, mints the block reward, and claims any fees. Its canonical JSON form is:

• BIP34-equivalent height commitment. Sparrow does not embed height inside script_sig as Bitcoin does (BIP34); the block header already carries a first-class height field, so the commitment is explicit.
• Extra-nonce. The coinbase_data string is the extra-nonce field. Any mutation changes the coinbase txid, which changes merkle_root — giving the miner an unbounded additional search space beyond the 64-bit nonce. Convention: prefix with "SPW block <h>" and append a per-rebuild counter.
• No script. Coinbase script_sig and pubkey are empty strings; the coinbase is identified solely by the two sentinel input values.
• Fee claim. The sum of coinbase output.amount must satisfy Σ(cb_out) ≤ block_reward(height) + Σ(tx_fees). Under-claiming is permitted (funds are burned); over-claiming invalidates the block.

4.5 Search-Space Expansion

When the 64-bit nonce range is insufficient (or a miner simply wishes to parallelise), three orthogonal dimensions may be varied without changing consensus rules:

1. nonce — primary counter (cheapest to vary).
2. timestamp — re-read from the wall clock, subject to the validity bounds of §5.2.
3. coinbase_data — an extra-nonce mutation that forces recomputation of the coinbase txid and therefore merkle_root (more expensive; used only after nonce / timestamp exhaustion, or by pool implementations to split work across workers).

The reference miner (miner_client.py) refreshes timestamp every 2,000–5,000 nonces and rebuilds the candidate block when a new tip arrives on the network.

4.6 Block Submission Protocol

Sparrow does not implement Bitcoin's getblocktemplate RPC. A miner assembles its own candidate block from three read-only endpoints, then submits the completed block as a single JSON POST:

1. GET /block/latest — returns tip block; the miner reads hash (→ prev_hash), header.height (→ next height), and header.bits (→ target).
2. GET /chain/info — returns next_reward (SPW) for the coinbase amount.
3. GET /mempool — returns candidate fee-paying transactions to include (validated by the node before insertion; the miner may select any subset).
4. Build coinbase (§4.4), compute all txid's, build the Merkle root (§5.1), and search for a valid nonce.
5. POST /block/submit — body is the complete block as JSON:

Submission is idempotent on block.hash; duplicate submissions are accepted without re-validation. A rejected stale tip (prev_hash mismatch) is the miner's signal to rebuild.

4.7 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:

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:

5.1 Header Fields

The header is not stored on the wire as a fixed-width binary blob. For PoW hashing (§4.3) the seven fields are rendered to ASCII text and concatenated; for transport they are carried inside the JSON block envelope (§4.6). All 32-byte hash values — prev_hash, merkle_root, and the resulting block.hash — use lowercase hexadecimal with no 0x prefix, and the resulting integer is compared against target as big-endian.

5.2 Timestamp Validity

To allow miners with imperfect clocks while still preventing gross manipulation of the difficulty retarget, Sparrow enforces:

• Future bound. A block is rejected if timestamp > wall_clock + 7200 s (2 hours) at the receiving node — the same tolerance as Bitcoin [1].
• Past bound. A block is rejected if timestamp ≤ median(timestamp[h-11 … h-1]), the median-time-past (MTP) of the previous 11 blocks. This monotonicity rule prevents re-ordering attacks on the retarget window.
• Genesis and blocks below height 11 are exempt from the MTP rule (median is computed over whatever prior blocks exist).

5.3 Merkle Tree

The Merkle tree is built by repeatedly hashing pairs of txid's with SHA-256d until a single 32-byte root remains. Leaves and internal nodes are represented as 64-char lowercase hex strings, concatenated as ASCII (not raw bytes), then double- SHA-256'd. An odd number of leaves is handled by duplicating the last element — the same construction as Bitcoin [1], differing only in that pairs are joined as text rather than as raw 32-byte values.

5.4 Validation Rules

• Correct prev_hash linkage to the canonical chain tip.
• Valid Proof of Work against the current bits target (RandomX with the height-derived epoch key, §4.2).
• Timestamp satisfies §5.2 bounds.
• First transaction is coinbase; coinbase output ≤ reward + fees (§4.4).
• 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 same curve used for key generation and signing). 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.

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

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:

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 S (for Sparrow).

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.

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. The timestamp of the block proves the document existed at that moment.
• SPW-native NFTs — inscribe a content hash + metadata URI. The inscription record (txid:vout) becomes the immutable token ID.
• Domain names — register name.spw by inscribing a JSON record, then prove ownership via the spending key of the accompanying UTXO.
• On-chain messages — short memos between parties, provably authored by a signing key.

Inscriptions are queryable at GET /inscriptions and GET /inscription/<txid>/<vout>. The node automatically attempts UTF-8 decoding and returns both data_hex and data_text in the response.

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", "TICKET-001").
• Mark output(s) carrying the new supply with color_id = "__issue__" and the desired color_qty.
• On block confirmation the node replaces __issue__ with the actual txid, which becomes the permanent color identifier.

Transfer:

• Reference the issuance txid in output.color_id and set color_qty for each colored output.
• Consensus rule: Σ color_qty(outputs) ≤ Σ color_qty(inputs) for every distinct color_id. Excess is burned; creation without issuance is rejected.
• The SPW amount of a colored output may be 0 (token-only) or positive (SPW + token in the same UTXO).

Representative use cases:

• Equity tokens — issue 10,000 units representing shares; transfer fractional ownership with standard SPW transactions.
• Event tickets — mint N tickets; scan the holder's colored UTXO at the door.
• Game items / loyalty points — in-game currencies or reward tokens redeemable on-chain.
• Stablecoins — a trusted issuer mints SPW-native tokens backed by off-chain reserves.

12.3 Disk Impact

Both extensions add minimal on-chain overhead. An OP_RETURN inscription adds at most ~120 bytes to the transaction record and one row to the inscriptions index. A colored-coin output adds two integer columns to the UTXO row (≈16 bytes). At 10% adoption (roughly 1 in 10 transactions carrying an extension) across a 20 tx/block rate, the combined additional storage over ten years amounts to less than 3% of base-chain data — well within the projections in §8.

13 Roadmap

14 Conclusion

Sparrow is a lean, auditable, and privacy-aware Proof-of-Work currency. Its design deliberately inherits Bitcoin's battle-tested primitives (SHA-256d, SECP256k1, UTXO, Base58Check, 2016-block retarget) while introducing meaningful improvements: 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 for anchoring arbitrary data (NFTs, domain names, notarisation) and Colored Coins for issuing and transferring token assets — 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. ethereum.org/whitepaper
• [3] T. E. Jedusor (pseud.), "Mimblewimble," 2016. scalingbitcoin.org
• [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," Contemporary Mathematics, 2008.
• [7] NIST FIPS 180-4, "Secure Hash Standard (SHS)," 2015.
• [8] tevador et al., "RandomX: Proof-of-work algorithm based on random code execution," 2019. github.com/tevador/RandomX