The Veld Protocol

1. Introduction

Veld is a proof-of-work cryptocurrency designed from first principles with two non-negotiable constraints:

1. Post-quantum by default. Every signature on the chain is ML-DSA-65 (Dilithium-3, NIST FIPS 204). No secp256k1, no hybrid layer, no "migrate later." A shelved quantum computer becoming operational next year does not invalidate a single UTXO.
2. Long-term participation is rewarded more than one-shot extraction. Solo mining, co-mining pool, vault-to-staker distributions, and a separate endorsement pool for validators together ensure no single actor extracts disproportionately more than their sustained contribution.

The project deliberately excludes features that have produced the most spectacular failures in other chains: bridges (cross-chain trust), smart-contract VMs (unbounded state transitions), and opaque pre-mines. Veld is a payment, staking, and validator chain. Nothing more.

2. Design Constraints

3. Block Reward Structure

Every normal block emits exactly 1.9025 VELD (1,000,000 / 525,600). The emission is split four ways at the consensus level — no fee markets, no hidden MEV.

Vault blocks: every 100th block routes 100% of the reward to the vault, bypassing the split. Over 100 blocks the vault receives 99 × 0.38 + 1 × 1.9025 ≈ 39.57 VELD, distributed every 144 blocks to stakers.

Mathematical integrity: at no point does the sum of coinbase outputs exceed the fixed block reward. Verified at consensus in include/core/blockchain.h (AddBlock) with overflow-safe aggregation.

4. Staking System

Staking is a commitment: you lock coins for a tier, and in return earn a share of vault distributions.

4.1 Stake lock mechanics

• Lock is an OP_RETURN payload: VELD_STAKE|LOCK|<address>|<amount>|<unlock_height>|<tier>
• The TX must be signed by <address> — a consent check enforced at consensus (not just at mempool) to prevent griefing.
• Each LOCK is backed by on-chain UTXOs: per-block balance + headroom check prevents phantom stakes.
• Per-address cap: 10,000 VELD. Per-output sanity: ≤ MAX_SUPPLY_UNITS. Intra-block sum-overflow guarded.

4.2 Tiers & multipliers

Hard cap on combined mining-tier × lockup-tier multiplier: 3.00×. Enforced at distribution time.

4.3 Distribution

Every 144 blocks (~2.4 hours), the veld-distribute daemon reads the vault UTXO set, enumerates active stakers weighted by stake × tier_multiplier × mining_tier_multiplier, and broadcasts a single distribution TX paying each staker their pro-rata share. 100% of vault accumulation flows to stakers. Validators are paid from a separate endorsement pool (below), not from the vault.

4.4 Cooldowns and unstake

• STAKE_COOLDOWN_BLOCKS after a stake: no unstake allowed for this period, regardless of individual lockup expiry.
• UNLOCK op-return requires the same signing-consent check as LOCK.
• Early unstake is rejected at consensus.

5. Validator & Endorsement System

5.1 Registration

• OP_RETURN: VELD_VALIDATOR|REGISTER|<pubkey_hex> (3,904 hex chars = full ML-DSA-65 public key).
• TX must be signed by the address derived from that pubkey (consent check).
• Registrant's address must have at least MIN_VALIDATOR_STAKE staked (mainnet target: 10,000 VELD).

5.2 Endorsement

• For each new block, each registered validator signs the message (height || block_hash) with their ML-DSA-65 key.
• Endorsement TX is broadcast via the mempool and included in the next block.
• Endorsement records are kept in the validator registry, keyed by block height.

5.3 Reward distribution

• Endorsement pool (10% coinbase slice) is flushed every 144 blocks.
• Payout is proportional to each validator's endorsement count over the last 144 blocks.
• Flush uses the same encryption path as other protocol keys (ChaCha20-Poly1305 + PBKDF2-SHA256).

5.4 Governance quorum

• General proposals: max(7, ceil(active_validators × 0.51)) — absolute floor of 7 to prevent small-cabal capture.
• Protocol upgrades: max(10, ceil(active_validators × 0.67)) — supermajority required.
• Voting window: 2016 blocks (~2 weeks). Timelock on protocol upgrades before activation.

5.5 Promo activations

A passed PROMO_ACTIVATION proposal can temporarily boost block rewards (max 2.0× multiplier, max 1,440 blocks, max 12% of current vault balance per activation, 30-day cooldown). All caps enforced at proposal-submit time and again at activation time.

6. Post-Quantum Cryptography

6.1 Algorithm choice

ML-DSA-65 (Dilithium-3), as standardized in NIST FIPS 204. Picked for:

• NIST-finalized status (not experimental).
• Lattice-based security assumption (module-LWE / module-SIS); independent of prime-order-group assumptions.
• Balanced performance/size tradeoff among the three ML-DSA security levels.

6.2 On-chain footprint

• 32-byte secret seed — the canonical "private key" (same shape as a secp256k1 key for UX parity).
• 1,952-byte public key.
• Signatures up to 3,309 bytes (variable).
• scriptSig format: OP_PUSHDATA2 <sig_len> <sig || 0x01 SIGHASH_ALL> OP_PUSHDATA2 <1952> <pubkey> ≈ 5.3 KB per signed input.

6.3 Sighash

Bitcoin-style varint length prefixes for every count (inputs, outputs, subscript). Cryptographically bound to the prev-output scriptPubKey (not the scriptSig), preventing signature malleability on the signed hash.

6.4 Keyfile format

• ChaCha20-Poly1305 authenticated encryption.
• PBKDF2-SHA256, 600,000 iterations (2026 OWASP guidance).
• 32-byte salt + 12-byte nonce per file; GCM tag authenticates.
• One passphrase unlocks every protocol key on the operator's host (via systemd EnvironmentFile so the passphrase never transits a command line).

6.5 Browser signing

The wallet UI embeds an emcc-compiled WASM bundle (/dilithium.js, 39 KB single-file, base64-inlined). Browser-side generation, signing, and verification are identical to the native C++ path — proven by cross-platform round-trip TXs during the final audit.

7. Consensus & Network

7.1 Proof of work

• VeldHash: 1 GB memory-hard dataset, 4,096 instructions × 16 iterations, 8 FP registers, epoch-rotated seed, Blake2b-256 finalize.
• Retarget: every 20 blocks (bringup), 1,440 blocks (mainnet). Clamped to 4× per window to dampen oscillation.
• Target block time: 60 s.

7.2 Reorg & finality

• MAX_REORG_DEPTH = 100 blocks. Any attempted reorg deeper than this is rejected outright.
• Coinbase maturity: 100 blocks, enforced at consensus from height 1,500.
• Hardcoded checkpoints installed at stable heights before launch.

7.3 P2P layer

• Port 8333 public; 8334 RPC loopback-only.
• Peer-advertised start height sanity-bounded (≤ 10⁹) to prevent IBD-trap attacks.
• ADDR flood rate-limited: max 4 dials per ADDR message, 16 per 60 s per peer.
• Mempool re-sync request every 120 s per peer (in addition to on-VERACK pull and live INV gossip).
• Orphan pool capped at 2,000 entries / 100 MB with FIFO eviction.

8. Security Posture (audit-verified)

Two independent audits completed before the v1 launch:

1. Static code audit — 18 findings across cryptography, consensus, transaction validation, networking, and secrets handling.
2. Adversarial simulation — 37 attack vectors executed live against the 4-node cluster, including consensus attacks, transaction manipulation, staking griefing, vault drain attempts, validator forgery, RPC abuse, P2P flooding, and infrastructure probes.

Every CRITICAL and HIGH finding was resolved at the source-level. Representative fixes:

• ComputeSighash widened to varint length prefixes (was silently preimage-colliding modulo 256).
• sendrawtransaction now computes actual fees from referenced UTXOs (was bypassing fee-rate policy).
• ScriptSig parser rejects trailing bytes (closes third-party malleability).
• Input-value overflow guards in all aggregation paths.
• Stake-lock and validator-register ops require signature consent.
• setupwallet RPC removed (was a miner-key hijack vector).
• Rate limiter split into auth vs unauth buckets.
• Vault passphrase relocated from an opc-group-readable env file to a dedicated veld service group.

The full audit report is maintained in the project repository at docs/FINAL_AUDIT_REPORT.md.

9. Genesis & Launch

• Genesis block time: 2025-07-01 00:00:00 UTC.
• Genesis message: "Veld - Where value is earned."
• Mainnet launch target: August 30, 2026.
• Bringup phase (pre-launch): low stake thresholds (10 VELD min, 50 VELD validator) to allow rapid testing. These rise to mainnet values (1,000 VELD min stake, 10,000 VELD validator) at launch.

10. What Veld is not

By design, Veld does NOT include:

• Cross-chain bridges. Each bridge is a multi-audit attack surface; the value prop is native post-quantum, not cross-chain.
• Smart-contract VM. Adding a VM triples the attack surface and dilutes the simplicity that is the primary security argument.
• Pre-mine / founder allocation. Fixed supply, emitted only by PoW + vault distributions.
• Admin override. No pause switch, no upgrade multisig, no privileged RPC. Governance is the only protocol-parameter lever and requires on-chain validator quorum.

11. References

• NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
• PQClean reference implementation: github.com/PQClean/PQClean
• Blake2 (RFC 7693)
• ChaCha20-Poly1305 (RFC 8439)

This whitepaper reflects the post-audit state of the protocol. Every parameter is verifiable against the source at include/core/constants.h. If this document contradicts the source, the source is authoritative.