Build Zephyr Protocol v2 clean-break implementation

[the-code-learner]

Scope

Builds the executable Zephyr Protocol v2 clean break on top of the existing hardening, Consensus & Performance Lab and persistence work.

The branch follows two equal goals:

• scale up toward extremely high finalized-through-consensus TPS when hardware is abundant;
• scale down gracefully so verification, payments, relay and useful network participation can remain practical on commodity hardware and inside the Zephyr smartphone wallet.

Throughput may degrade when hardware is scarce; safety must not.

Authoritative design documents

• README.md — current v2 project overview and non-claim boundary.
• docs/protocol-v2.md — protocol architecture and clean-break contract.
• docs/protocol-v2-implementation-status.md — executable/experimental/non-production status by subsystem.
• docs/tokenomics-v2.md — oracle-free adaptive ZPH monetary design and activation gates.
• docs/compute-economics-v2.md — ZCR/ZCPI/ZCSI compute economics.
• docs/economic-state-v2.md — economic state, velocity and epoch aggregation.
• docs/economic-runtime-v2.md — finalized-block economic collection, scheduler and shadow consensus-finality pipeline.
• docs/protocol-v2-validator-trust.md — validator trust/rotation model.

Implemented v2 foundations

The branch now includes, with executable tests/gates:

• canonical bounded binary consensus encoding and genesis-derived network identity;
• separate account/node/validator identities and low-S P-256 signing;
• proof-oriented object/coin model and incremental Sparse-Merkle state;
• proof-carrying transactions and deterministic parallel execution;
• durable WAL/checkpoint backend and non-mutating state preview;
• v2 proposal/vote/QC/GlobalHeader finality and validator-root trust transitions;
• cross-shard finalized receipts, shard commitments and durable anti-replay state;
• Citizen/light proof API plus strict wallet-side cryptographic verification;
• deterministic metered reference contract runtime and deploy/call execution path;
• native custom-token creation plus fixed/capped/mintable policies, mint/burn and transferability enforcement;
• compute-market object state, escrow/collateral, settlement and objective replicated-majority slashing foundation;
• authenticated Reed-Solomon data-availability reconstruction foundation;
• libp2p/QUIC transport foundation with network-scoped protocols;
• dedicated v2 seven-validator conformance/partition gate and finalized batch benchmark.

Compute economics and tokenomics shadow mode

The branch includes executable instrumentation required to measure and simulate the monetary design before activation:

• normalized compute WorkVector rather than one fake universal FLOP scalar;
• versioned workload specifications bound to WorkloadHash and BenchmarkHash;
• registry conflict rejection;
• settlement receipts that can be parsed and deterministically reconstructed from finalized job state;
• VerifiedWork observations derived only from finalized/verification-satisfied compute settlements;
• ZCPI per-class medians, Q9 fixed-point pricing, EWMA, basket coverage and reliability;
• no offer price or provider self-reported theoretical capacity in ZCPI;
• ZCSI over standardized demand/supply, backlog, fulfillment, utilization and reliable ZCPI trend;
• separate ComputeSupplyReliable gate so unauthenticated capacity cannot make ZCSI reliable;
• exact cross-epoch compute flow accounting: opening backlog + new demand = fulfilled + expired + closing backlog;
• modes A/B/C for observe-only, compute-reward routing, and a narrow shadow inflation correction;
• ZAMP shadow controller centered near 2% annualized net ZPH supply growth, using only on-chain metrics;
• deterministic burn-offset accounting and bounded/rate-limited adaptive target;
• age-weighted money-velocity foundation using consensus-stamped coin creation height;
• canonical per-shard economic metrics and deterministic multi-shard aggregation;
• Merkle-authenticated chained MonetaryEpochState system object;
• finalized-block EpochCollector with atomic preview/apply semantics and cross-shard supply attribution;
• runtime-owned collector/engine clones so callers cannot mutate economic history outside node synchronization;
• successful QC commits advance finalized economic telemetry while rejected commits do not;
• preview/accept ShadowEpochEngine composing EpochAggregate -> ZCPI -> ZCSI -> ZAMP -> pending MonetaryEpochState without live minting;
• automatic configured epoch-boundary closure;
• automatic insertion of the pending monetary object into the first normal consensus candidate of the next epoch;
• QC/state-finality acceptance of the shadow monetary object through the normal shard/global state-root path;
• explicit tests that shadow issuance suggestions do not mutate live circulating supply;
• cmd/zephyr-econ-sim for replaying synthetic/devnet epoch metrics without mutating supply;
• deterministic fee-engine foundation for resource quotations and burn/validator/reserve split simulation while preserving the current compatibility policy until authenticated monetary accounting is activated.

License

The branch changes the project license to Apache License 2.0, adds the repository-level NOTICE attribution for Zephyr Chain / the-code-learner, and rewrites the README around the actual v2 status.

Deliberate non-claims

This draft does not claim that the following are production-ready or economically activated:

• live ZAMP minting or final monetary parameters;
• a finalized dynamic resource/gas schedule or active fee split;
• authenticated staking/protocol-reserve balances and governance bounds for live monetary transitions;
• production compute-capacity authentication/benchmark registry;
• compute feedback enabled in live monetary policy;
• production-governed workload registry;
• durable scheduler/controller recovery metadata across full node restarts;
• production-atomic global multi-shard backend commit coordination under storage I/O faults;
• production ZK/TEE verifier integrations or confidential-compute key exchange;
• production deterministic WASM engine/Rust SDK;
• mobile OS lifecycle/background integration and real-device resource budgets;
• production discovery/NAT/mobile relay/shard-aware gossip;
• reshard/split/merge activation or 4/16-shard public activation.

The rule is measure first -> simulate second -> activate last.

Gates

Both the existing v1 Consensus & Performance Lab and the dedicated V2 Lab remain mandatory. Performance changes do not enter the protocol if they regress safety/liveness. Shared GitHub runner benchmark numbers are development signals, not production-capacity claims.