Skip to content

Implementation plan (builder-ready)

This page converts the wiki’s phased planning into an execution-oriented plan for teams implementing ReddID + Namespaces.

Phased delivery (one sensible sequencing)

Phase 0 — Finalize specs & invariants (Weeks 1–4)

  • Lock canonical encoding / message formats
  • Confirm auction states, renewal rules, anti-sniping behavior
  • Confirm schema versioning + migration plan
  • Document threat model (spam/sybil, squatting, auction manipulation)

Phase 1 — Core protocol + storage (Weeks 5–16)

  • Namespace auction manager + validation
  • Namespace configuration manager (hashing, update rules, propagation)
  • Core DB tables + indexes
  • On-chain recording of critical events (creation, bids, settlement, renewals)
  • P2P relay extensions for auction/config messages

Phase 2 — Wallet UI/UX (Weeks 12–20)

  • Auction browser (namespaces + user IDs)
  • Bid placement UI (deposit visibility, extensions, warnings)
  • Namespace configuration UI (owner-only flows, safe defaults)
  • Status visibility (active auctions, expiration timers)

Phase 3 — Testing, audits, beta (Weeks 16–24)

  • Unit tests for rule enforcement
  • Fuzz tests for message parsing / validation
  • Security review for economic attacks
  • Beta program (testnet) + monitoring dashboards

Phase 4 — Launch & operations (Weeks 25–28)

  • Mainnet deployment
  • Operational runbooks (incident response, chain splits, rollback plan)
  • Post-launch cadence: metrics + parameter tuning (transparent governance)

Deliverables per phase (what “done” looks like)

  • Spec: deterministic rules for validation across nodes
  • Protocol: message propagation + mempool/persistence behavior
  • Storage: schema + migrations
  • UI: flows non-technical users can execute safely
  • Ops: monitoring, triage playbooks, known-failure modes

Canonical sources

Last reviewed: 2026-02-13