WarpCoin WARP
← All documentation

WarpCoin Security

This document describes WarpCoin's security model, the protections implemented in the code, and the residual risks and roadmap. It reflects the hardening pass covering consensus integrity, peer-to-peer and RPC denial-of-service, key storage, and the desktop app.

Consensus integrity

  • No inflation via integer overflow. Every value-bearing operation is bounded by MaxMoney (the maximum possible supply) and uses checked addition. A transaction is rejected if its amount or fee exceeds MaxMoney, if amount + fee overflows, or if crediting a recipient/miner balance or summing block fees would overflow. This prevents wrap-around bugs that could mint coins.
  • Duplicate-transaction / Merkle-forgery protection. Blocks containing a repeated transaction id are rejected, which also closes the CVE-2012-2459 Merkle-tree vulnerability (an attacker cannot duplicate transactions to forge a colliding Merkle root).
  • Signature malleability removed. ECDSA signatures are normalized to low-S on signing and high-S signatures are rejected on verification, along with out-of-range r/s. This makes a transaction's id stable against malleation.
  • Coinbase and reward rules. Exactly one coinbase, first in the block; its amount may not exceed the block subsidy plus collected fees, and is bounded by MaxMoney.
  • Timestamp rules. A block's timestamp may not precede its parent's and may not be more than two hours in the future, limiting difficulty manipulation.
  • Self-send and structural checks. Sender ≠ recipient, positive amount, valid addresses, public key must hash to the sender address, and transaction field lengths are capped.

Peer-to-peer hardening

  • Framed messages with a hard size cap. P2P messages are length-prefixed and capped at 16 MiB, so a peer cannot force unbounded memory allocation by streaming a huge JSON value.
  • Read/write deadlines. Handshake and idle read deadlines, plus write deadlines, prevent slow-peer resource exhaustion. The idle timeout is longer than the discovery-broadcast interval, so healthy idle peers are not dropped.
  • Validation before trust. All gossiped blocks and transactions are fully validated (proof of work, signatures, consensus rules) before acceptance, so a malicious peer can waste only bounded resources, not corrupt state.

RPC, explorer, and market services

  • Hardened HTTP servers. All HTTP services use read-header/read/write/idle timeouts and a header-size cap (resisting Slowloris), and POST endpoints bound the request body (1 MiB for transactions, 16 MiB for submitted blocks, a few KiB for market orders).
  • Optional RPC authentication. The node RPC supports a bearer token via --rpc-token or the WARP_RPC_TOKEN environment variable. When set, every endpoint except /healthz requires Authorization: Bearer <token> (compared in constant time). Bind RPC to localhost by default; require a token (and/or a reverse proxy and firewall) whenever it is exposed beyond the host.
  • Read-only public services. The block explorer and supply API are read-only. The market service is a reference order book and does not custody funds or settle on-chain.

Wallet-platform services (tags, escrow, merchant, contracts)

  • Bounded request bodies. All service endpoints decode through a shared helper that caps the request body (1 MiB), preventing memory exhaustion.
  • Signature-authorized state changes. Claiming a warp#tag and every escrow transition (fund/release/refund/dispute) require a wallet signature over a canonical action string from an address permitted to make that change; the public key must hash to the claimed address (internal/authsig, using the hardened wallet.Verify).
  • Constant-time API keys. Merchant API keys are matched with a constant-time comparison to avoid timing side-channels.
  • SSRF-guarded webhooks. Merchant webhooks are signed with HMAC-SHA256 and sent through a dialer that refuses to connect to loopback, private, link-local, or other non-public addresses — checked against the resolved IP at connect time, which also defeats DNS rebinding. Webhook URLs must be http(s).
  • Payments re-validated on-chain. Invoice payments are ordinary signed transactions; the gateway checks the recipient and amount and then submits them through the node, which re-verifies signature, nonce, and balance.

Key storage

  • Encrypted keystores. Wallets can be encrypted with a passphrase using PBKDF2-SHA256 (600,000 iterations) to derive a key that seals the private key with AES-256-GCM (authenticated encryption). The address and public key remain in the clear; the private key never touches disk unencrypted.
  • Passphrase sources. The CLI takes the passphrase from --passphrase-file, the WARP_WALLET_PASSPHRASE environment variable, or an interactive prompt with terminal echo disabled. Plaintext keystores remain supported for automation via --plaintext, with a clear warning.
  • Desktop app. The desktop app encrypts the keystore at rest automatically: it generates a random passphrase protected by the OS keychain (Electron safeStorage — Keychain on macOS, DPAPI on Windows, the secret service on Linux) and passes it to the bundled binary. If OS-level protection is unavailable it falls back to a plaintext keystore and logs a warning.

Desktop app hardening

  • The renderer runs with contextIsolation on, nodeIntegration off, sandbox on, and a strict Content-Security-Policy. It has no direct filesystem or network access — every action goes through a vetted preload IPC bridge.
  • The bundled node binds RPC to localhost and is authenticated with a random per-run bearer token.

Residual risks & roadmap

  • Transport privacy. The P2P protocol is plaintext (like Bitcoin's). All data is cryptographically validated, so a network attacker cannot corrupt state, but they can observe traffic. Optional transport encryption (Noise/BIP324-style) is on the roadmap.
  • Post-quantum signatures. Signatures use ECDSA (P-256), which is not quantum-resistant; hashing/PoW (SHA-256d) is. A crypto-agility layer and hybrid post-quantum signatures are planned. See the whitepaper.
  • Coinbase maturity. The maturity depth is defined but not yet enforced at spend time.
  • Reorg cost. Adopting a heavier fork rebuilds account state by replaying from genesis; this is correct but to be optimized with state snapshots.
  • DoS depth. Per-peer rate limiting and a ban score are not yet implemented.

Reporting

Found a vulnerability? Please open a private report to the maintainers rather than a public issue, and allow time to remediate before disclosure.