WarpCoin: A Fast, Fair, Mineable-by-Everyone Peer-to-Peer Digital Cash
A Standalone Layer-1 Proof-of-Work Blockchain
Ticker: WARP · Source: github.com/kevinsegal/warpcoin · License: MIT
Abstract
WarpCoin (ticker WARP) is a standalone Layer-1 proof-of-work blockchain implemented from scratch in the Go programming language using only the Go standard library, with zero third-party dependencies. It is designed as fast, fair, mineable-by-everyone peer-to-peer digital cash, optimized for everyday person-to-person payments while remaining versatile and fast.
Unlike many first-generation cryptocurrencies that track unspent transaction outputs (UTXOs), WarpCoin uses an account/nonce ledger model in which each address maintains a balance and a strictly increasing nonce. This design keeps transactions compact, makes replay protection explicit, and simplifies reasoning about account state. Consensus follows the well-understood proof-of-work model: blocks are secured by double SHA-256 hashing, difficulty retargets on a fixed schedule, and the chain with the most cumulative work wins. Because the work function is plain SHA-256d, mining is open to anyone using CPUs, GPUs, FPGAs, or ASICs.
This document describes the protocol, cryptography, monetary policy, networking, node roles, and tooling that make up WarpCoin, and it candidly enumerates the project's current limitations and roadmap. It is a technical document and is not investment advice.
1. Introduction & Motivation
The original promise of a peer-to-peer electronic cash system was a way to transfer value directly between participants without a trusted intermediary. WarpCoin returns to that core goal: simple, verifiable, fast digital cash that anyone can hold, send, and mine.
WarpCoin is built from the ground up in Go, relying exclusively on the Go standard library. This deliberate constraint — zero third-party dependencies — keeps the codebase auditable, reduces supply-chain risk, and ensures the entire system can be understood, built, and reasoned about from a single, self-contained source tree. The full implementation is open source under the MIT license.
The positioning is straightforward: WarpCoin aims to be fast, fair, and mineable by everyone. "Fair" refers to an open proof-of-work design with no special hardware requirement baked into the consensus algorithm. "Fast" refers to a short block-time target suited to everyday payments. "Mineable by everyone" reflects the choice of plain double SHA-256 as the proof-of-work function, which runs across a wide range of hardware.
2. Design Goals
WarpCoin's design is guided by a small set of explicit goals:
- Simplicity and auditability. Implemented in Go using only the standard library, with no external dependencies.
- Everyday payments. A short, 30-second block-time target oriented toward person-to-person transactions.
- Open mining. A proof-of-work function (double SHA-256 of the block header) that does not privilege any single class of hardware; CPUs, GPUs, FPGAs, and ASICs can all participate.
- Explicit, replay-resistant accounting. An account/nonce ledger that strictly orders each sender's transactions.
- Predictable, transparent monetary policy. A fixed initial reward, a halving schedule, a hard supply cap, and an on-chain, verifiable circulating-supply definition.
- Operational versatility. A single binary that can take on multiple network roles, packaged for desktop, container, and orchestrated deployments.
3. The Account-Based Ledger
WarpCoin uses an account/nonce ledger model similar to Ethereum's, rather than Bitcoin's UTXO model. The global state is a mapping from addresses to account records, where each account holds two fields:
| Field | Description |
|---|---|
| Balance | The amount of value held by the address, denominated in flux. |
| Nonce | A strictly increasing counter that orders the sender's transactions. |
The nonce serves two purposes. First, it imposes a strict ordering on the transactions originating from a given address, so that the network can determine the canonical sequence in which a sender's transactions take effect. Second, it provides replay protection: because each transaction commits to a specific nonce, a transaction cannot be validly re-applied once its nonce has been consumed.
This model keeps account state compact — a single balance and nonce per address — and makes balance lookups and validity checks direct, without the need to assemble and track sets of unspent outputs.
4. Transactions & Cryptography
4.1 Cryptographic Primitives
WarpCoin uses elliptic-curve cryptography based on ECDSA over the NIST P-256 curve (also known as secp256r1):
- Public keys are compressed to 33 bytes.
- Signatures are 64 bytes, encoded as the concatenation
r || s. - Hashing throughout the system is double SHA-256 (SHA-256 applied twice).
4.2 Addresses
Addresses are encoded using Base58Check with a version byte of 0x49, which causes all WarpCoin addresses to begin with the letter W. An address is derived as follows:
- Take the public key.
- Compute the double SHA-256 of the public key, and take the first 20 bytes as the payload.
- Prepend the version byte
0x49. - Append a 4-byte checksum, which is the first 4 bytes of the double SHA-256 of the versioned payload.
- Encode the result in Base58.
4.3 Transaction Structure
Each transaction contains the following fields:
| Field | Purpose |
|---|---|
| From | The sender's address. |
| To | The recipient's address. |
| Amount | The value transferred, in flux. |
| Fee | The fee paid to the miner who includes the transaction. |
| Nonce | The sender's transaction ordering/replay-protection counter. |
| Timestamp | The time the transaction was created. |
| PubKey | The sender's compressed 33-byte public key. |
| Signature | The 64-byte ECDSA signature over the signing hash. |
The signing hash is the double SHA-256 of the transaction's canonical serialization with the signature field omitted. Signing this hash with the sender's private key produces the 64-byte signature, and verifiers recompute the same hash to validate the signature against the included public key (which must also derive to the From address).
4.4 Coinbase Transactions
Each block contains a special coinbase transaction whose sender is the sentinel value WARP_COINBASE. The coinbase mints the block reward plus the total fees collected from the transactions included in the block, paying them to the miner. Fees themselves are ordinary transfers of existing value and do not create new issuance; only the block reward portion of the coinbase is newly issued.
5. Proof of Work & Difficulty Adjustment
5.1 Block Header
The block header is a fixed 88-byte big-endian structure:
| Field | Size (bytes) | Description |
|---|---|---|
| Version | 4 | Header version. |
| PrevHash | 32 | Hash of the previous block header. |
| MerkleRoot | 32 | Merkle root committing to all transactions. |
| Timestamp | 8 | Block timestamp. |
| Height | 8 | Block height. |
| Bits | 4 | Compact difficulty target (Bitcoin-style nBits). |
| Nonce | 8 | The proof-of-work nonce. |
The Merkle root commits to all transactions in the block using a Bitcoin-style Merkle tree, duplicating the last node when a tree level contains an odd number of nodes.
5.2 Proof-of-Work Function
The proof-of-work hash is the double SHA-256 of the serialized 88-byte header. A block is valid when that hash, interpreted as a big-endian 256-bit integer, is less than or equal to the target encoded by the compact bits field. The bits field uses the same compact "nBits" representation as Bitcoin.
Because the work function is plain SHA-256d — with no memory-hardness or specialized requirement built into consensus — it runs efficiently on CPUs, GPUs, FPGAs, and ASICs alike. This is a deliberate fairness choice: anyone can mine WarpCoin with whatever hardware they have.
5.3 Difficulty Adjustment
WarpCoin targets a 30-second block time. Difficulty retargets every 60 blocks (approximately 30 minutes). To resist timestamp manipulation, each retarget's adjustment is clamped to a factor of 4 in either direction, and difficulty is never allowed to drop below the genesis difficulty.
6. Network Protocol & Consensus
6.1 Gossip Transport
Nodes communicate over a custom TCP gossip protocol using JSON-encoded messages. When two peers connect, they perform a handshake that exchanges the protocol version, the current chain height, and the peer's listen address.
6.2 Peer Discovery
Peers discover one another through getpeers/peers gossip messages, allowing the network to share knowledge of live peers. New nodes bootstrap into the network via DNS seeders: a DNS seeder is a node that crawls the network and answers DNS A queries for a seed domain with the IP addresses of live peers.
6.3 Block & Transaction Propagation
Newly produced blocks and newly received transactions are propagated to connected peers, so that valid data flows across the network.
6.4 Synchronization
New or lagging nodes synchronize sequentially by block height, requesting and applying blocks in order until they reach the chain tip.
6.5 Fork Choice & Reorganizations
Consensus follows the most-cumulative-work rule: the valid chain with the greatest total accumulated proof-of-work is considered canonical. WarpCoin supports chain reorganizations, in which the node switches to a heavier competing chain by replaying state along the new branch.
Because security is provided by proof of work, transaction finality is probabilistic, as in Bitcoin: the more confirmations a transaction has, the less likely it is to be reversed by a reorganization.
7. Monetary Policy & Tokenomics
7.1 Units
The smallest indivisible unit of WarpCoin is the flux. One WARP equals 100,000,000 flux, giving WarpCoin 8 decimal places of precision.
| Unit | Value |
|---|---|
| 1 WARP | 100,000,000 flux |
| 1 flux | 0.00000001 WARP |
7.2 Emission Schedule
- The initial block reward is 50 WARP.
- The reward halves every 2,100,000 blocks, which is approximately every 2 years at a 30-second block time.
- The reward reaches zero after 64 halvings.
- The maximum supply is approximately 229,999,999.77 WARP.
Miners additionally collect the fees of the transactions they include in their blocks. These fees are transfers of existing value and are not new issuance — they redistribute value already in circulation to the miner.
7.3 Genesis Premine
WarpCoin's genesis block allocates 20,000,000 WARP on-chain, committed via the genesis Merkle root, to three founding holders:
| Reserve | Allocation (WARP) |
|---|---|
| Treasury Reserve | 10,000,000 |
| Development Fund | 5,000,000 |
| Ecosystem & Community | 5,000,000 |
| Total premine | 20,000,000 |
7.4 Circulating Supply
WarpCoin defines circulating supply as the total issued supply minus the balances still held by the three reserve addresses listed above. Because these reserve addresses are known and their balances are observable on-chain, circulating supply can be computed verifiably and rises as the reserves are distributed. A public supply API (described in Section 9) exposes circulating, total, and maximum supply figures.
7.5 Coinbase Maturity
Coinbase maturity is defined at 100 confirmations, meaning a freshly mined block reward is intended to mature over 100 subsequent blocks before being spendable. (See Section 12 for the current enforcement status of this rule.)
8. Mining
Mining WarpCoin consists of assembling a candidate block, computing its 88-byte header, and searching for a nonce such that the double SHA-256 of the header meets the target encoded in the bits field. The miner who finds a valid header receives the coinbase output: the block reward plus all fees from the included transactions.
Because the proof-of-work function is plain SHA-256d, mining is hardware-agnostic and open to CPUs, GPUs, FPGAs, and ASICs.
The WarpCoin node includes a CPU miner role. It also exposes a getwork/submitwork interface that lets external CPU or GPU miners attach to a node: a miner requests work via getwork, searches for a valid nonce off-node, and submits a found solution via submitwork. This decouples the hashing effort from the node process and allows external mining software to participate.
9. Node Roles & Infrastructure
WarpCoin ships as a single binary whose behavior is selected by configuration/role. The supported roles are:
| Role | Function |
|---|---|
| full | A validating node that verifies and relays blocks and transactions. |
| seed | A high peer-count bootstrap node that helps new nodes join the network. |
| miner | A CPU mining node; also serves getwork/submitwork so external CPU/GPU miners can attach. |
| verifier | A non-mining node exposing a /verify endpoint to pre-flight a transaction's signature, nonce, and balance without broadcasting it. |
| explorer | Serves a public block explorer and a supply API. |
| dnsseed | Provides DNS-based peer routing by answering DNS queries with live peer IPs. |
| market data service | Provides market data. |
9.1 Default Ports
| Service | Port | Protocol |
|---|---|---|
| P2P | 8338 | TCP |
| JSON-RPC | 8339 | TCP |
| Block explorer | 8340 | TCP |
| DNS seeder | 53 | UDP |
9.2 Block Explorer & Supply API
The explorer role serves a public block explorer together with a CoinGecko-style supply API exposing the following endpoints:
/api/supply/circulating/api/supply/total/api/supply/max
9.3 Tooling & Deployment
WarpCoin provides a single warpcoin CLI binary with subcommands including node, wallet, send, balance, status, miner, dnsseed, and explorer. For end users, a cross-platform Electron desktop application (Windows, macOS, and Linux) bundles the node.
For operators, the project provides a Docker image, a docker-compose configuration, systemd unit files, and Kubernetes manifests, covering single-machine, containerized, and orchestrated deployments.
10. Wallet & Transaction Lifecycle
A WarpCoin wallet manages an ECDSA P-256 key pair and derives the corresponding W... Base58Check address. The warpcoin CLI exposes wallet operations and supports querying balances and node status.
A typical transaction lifecycle proceeds as follows:
- Construction. The sender builds a transaction with the
From,To,Amount,Fee,Nonce,Timestamp, andPubKeyfields. The nonce is chosen as the sender's next sequential value. - Signing. The sender computes the signing hash (double SHA-256 of the canonical serialization without the signature) and produces a 64-byte ECDSA signature.
- Optional pre-flight. The sender may submit the transaction to a verifier node's
/verifyendpoint, which checks the signature, nonce, and balance without broadcasting it. - Broadcast. The transaction is submitted to a node and gossiped to peers.
- Inclusion. A miner includes the transaction in a candidate block and collects its fee upon mining the block.
- Confirmation. As subsequent blocks are mined on top, the transaction accrues confirmations and its finality becomes increasingly probable.
11. Wallet Platform & WarpScript Contracts
Beyond the base protocol, WarpCoin ships a wallet platform implemented in supported node code and exposed over the JSON-RPC API, with a reference web client, WarpWallet. It makes WARP usable as everyday money for people and businesses, and introduces no-code smart contracts.
Non-custodial by construction. Keys are generated and used on the client
(ECDSA P-256, Base58Check W… addresses, double SHA-256). Privileged service
actions are authorized by a signature over a canonical action string — digest = sha256d(utf8(action)), the same primitive as transaction signing — so the node
verifies authorization without holding any secret. The reference web client seals
keys at rest with AES-256-GCM behind a PBKDF2 (310k-iteration) passphrase.
Platform services.
- warp#tags — human-readable handles (
warp#nova) bound to an address by a signature, so users can be paid without sharing a long Base58 string. - Escrow — buyer/seller/arbiter agreements where every transition (fund/release/refund/dispute) is signature-authorized. On the account/nonce ledger this is a coordination-and-authorization layer; protocol-enforced custody arrives with WarpVM.
- Merchant gateway — businesses register a payout address, mint an API key, issue invoices, accept WARP at a hosted checkout, and receive HMAC-signed webhooks on payment.
- Inter-planetary settlement — the node estimates one-way/round-trip light time between Solar System bodies so wallets and contracts can settle on light-time-aware deadlines, respecting the speed of light as the binding constraint between worlds.
WarpScript contracts. A declarative, no-code contract model: a ContractSpec
of typed parameters and when/then clauses (triggers, conditions, actions),
authored in a visual studio. The compiler is deterministic and content-addressed
— the contract id is sha256d of a canonical JSON serialization, and the contract
address is Base58Check(0x49 || sha256d(spec)[0:20]), reusing the account address
scheme so it begins with W. The compiler is byte-compatible across
implementations: the Go node and the TypeScript web client derive the identical
id and address for the same spec (locked in by a cross-language golden test). The
emitted bytecode artifact targets the forthcoming WarpVM, which will execute
deployed contracts as consensus state using the same spec shape — so contracts
authored today carry forward unchanged.
See the Wallet Platform and WarpScript Contracts references for the complete endpoint and specification details.
12. Use Cases
WarpCoin is oriented toward versatile, fast, everyday peer-to-peer payments. Representative use cases include:
- Direct person-to-person transfers of digital cash without an intermediary.
- Open participation in mining for anyone with general-purpose or specialized hardware.
- Transaction pre-flighting via verifier nodes, useful for services that want to validate a transaction's signature, nonce, and balance before relying on it.
- Public chain transparency through the block explorer and the verifiable supply API.
- Self-hosted infrastructure using the desktop app for individuals or the container/orchestration tooling for operators.
- Pay-by-handle with warp#tags, escrowed deals between parties, and merchant acceptance of WARP via invoices and a hosted checkout (Section 11).
- No-code agreements — vesting, multisig treasuries, subscriptions, and light-time-aware inter-planetary transfers authored as WarpScript contracts.
13. Security Considerations
- Probabilistic finality. As a proof-of-work chain, WarpCoin offers probabilistic finality. Recipients of high-value transactions should wait for an appropriate number of confirmations, since reorganizations can reverse recent blocks.
- Open proof of work. The use of plain SHA-256d means security depends on honest hashing power exceeding that of any adversary. The most-cumulative-work fork-choice rule governs which chain is canonical.
- Difficulty manipulation resistance. Clamping each retarget to a factor of 4 and never dropping below genesis difficulty limits the impact of timestamp manipulation on difficulty.
- Replay protection. The per-account nonce strictly orders transactions and prevents replay of already-applied transactions.
- Signature and identity binding. Transactions are signed over a double SHA-256 hash of their canonical serialization (excluding the signature), and the included public key must correspond to the
Fromaddress, binding authorization to the spending account. - Unauthenticated interfaces. The RPC and API surfaces are unauthenticated and are intended to be bound privately or placed behind a proxy (see Section 14).
- Keystore protection. Keystores are currently stored as plaintext JSON with owner-only file permissions (see Section 14).
14. Limitations & Roadmap
WarpCoin is presented honestly, including its known limitations and the work planned to address them.
Current limitations:
- Coinbase maturity not yet enforced. Coinbase maturity is defined at 100 confirmations but is not yet enforced at spend time.
- Reorg state rebuilding. Chain reorganizations currently rebuild account state by replaying from genesis, rather than from a more recent snapshot.
- Plaintext keystores. Keystores are stored as plaintext JSON with owner-only permissions; they are not yet password-encrypted.
- Unauthenticated RPC/APIs. The RPC and API endpoints are unauthenticated and are meant to be bound privately or fronted by a proxy.
Planned future work:
- Enforcing coinbase maturity at spend time.
- Optimizing reorganizations with state snapshots instead of replaying from genesis.
- A native GPU miner.
- Transaction expiry and richer mempool eviction.
- Additional DNS seeds and NAT traversal.
- Encrypted (password-protected) keystores.
15. Conclusion
WarpCoin is a self-contained Layer-1 proof-of-work blockchain built in Go with no third-party dependencies, aiming to be fast, fair, and mineable by everyone. It combines a compact account/nonce ledger, ECDSA P-256 cryptography, double SHA-256 proof of work, a 30-second block target, and a transparent, capped monetary policy with a verifiable circulating-supply definition. A single binary provides full, seed, miner, verifier, explorer, DNS-seed, and market-data roles, and the project is packaged for desktop, container, and orchestrated deployment. The team is transparent about current limitations and has a clear roadmap toward enforcing coinbase maturity, optimizing reorganizations, hardening keystores and interfaces, and broadening mining and networking support.
Disclaimer
This document is a technical description of the WarpCoin software and protocol. It is provided for informational purposes only and does not constitute financial, investment, legal, or tax advice. It contains no price predictions and makes no representations about future value or performance. WarpCoin is open-source software distributed under the MIT license; readers should evaluate the source code and assume all associated technical and operational risks themselves.