Dev Phases

Initial release: 2025/12/21
Latest update: 2025/12/29

Legal warning: This page is for information only and does not constitute: (1) an offer to sell, or a solicitation of an offer to buy, any token, share, or security; (2) investment, legal, tax, or accounting advice; or (3) a promise of listing, price performance, or financial return for any asset. dCorps does not grant legal personhood by itself. Disclaimer.

Development phases

Phased readiness with clear exit criteria

Phases define readiness gates, not dates. Phase 0 is pre-mainnet readiness. Phases 1 to 5 begin at mainnet launch.

Source: Docs Center / Roadmap Phases Adoption Tracks

Roadmap notice: Phases define readiness gates, not dates. Scope can evolve with engineering, audits, legal constraints, and governance decisions.

  1. Phase 0A Current

    Baseline

    Objective: finalize public-facing pages, navigation, and doc alignment before protocol implementation work begins.

    Key deliverables

    • Website copy aligned to public docs and the Whitepaper Long.
    • Publish and update dates under page titles where required.
    • Roadmap page includes a high-level disclaimer.
    • Links to public docs and specs are verified.

    Exit criteria

    • Static site is ready to publish with verified doc links.
    • Website content and public docs remain aligned.
  2. Phase 0 Current

    Testnet

    Objective: publish verifiable artifacts and operate a public testnet so readiness can be assessed without private access.

    Key deliverables

    • Hub chain source code and build instructions.
    • Protocol specs and module standards.
    • Public testnet with chain ID, genesis file, and validator onboarding steps.
    • Reproducible tooling for nodes, indexers, and reporting views.
    • Public example entity package on testnet with tagged events, anchors, and derived reports.
    • Audit scope and reports for core modules and reference tooling.
    • Bug bounty program with disclosure workflow.
    • Governance and validator charters plus Treasury policy.

    Exit criteria

    • Third parties can reproduce entity views and reporting outputs from raw chain data.
    • At least one upgrade rehearsal is executed on testnet.
    • Security and governance artifacts are published and verifiable.
  3. Phase 1 Current

    Mainnet

    Objective: launch a stable Hub kernel that supports end‑to‑end operation for Hub corporations and Hub nonprofits.

    Key deliverables

    • Hub chain genesis, validator set, and runtime stability.
    • DCHUB gas, staking, and governance primitives.
    • Entity registry with IDs, types, metadata, and lifecycle status.
    • Hub corporation module v1 and Hub nonprofit module v1.
    • Canonical wallets and tagged accounting event schemas.
    • Document anchoring and evidence timelines.
    • Reference explorer and indexer for entity discovery and event timelines.

    Exit criteria

    • Core modules audited and deployed with reproducible builds.
    • Upgrade process and on-chain governance path tested in controlled upgrades.
    • Real entities can register, operate, and produce reproducible reports using only the Hub.
  4. Phase 2 Current

    Hardening

    Objective: harden operations, standards, and tooling so external builders can treat the Hub as infrastructure.

    Key deliverables

    • Conformance test suite for entity modules, schemas, and indexing compatibility.
    • Stable APIs and SDKs for core operations.
    • Monitoring, alerting, and incident processes for validators and core services.
    • Bug bounty expansion and formalized threat models for the kernel.
    • UX primitives such as fee grants that allow stablecoin service fees while execution uses DCHUB.

    Exit criteria

    • Independent builders can integrate against published schemas and pass conformance tests.
    • A first cohort of entities operates end to end on mainnet with real value flows.
  5. Phase 3 Current

    Ecosystem

    Objective: make the Hub easy to use for real organizations and easy to integrate for service providers and apps.

    Key deliverables

    • IBC stablecoin connectivity and standard treasury patterns.
    • App and module registry with metadata, versioning, and security posture disclosures.
    • Reference templates for common entity setups.
    • Indexer redundancy and data availability patterns.
    • Reference governance UI and reporting UI to reduce integration friction.

    Exit criteria

    • Multiple independent applications and service providers operate in production.
    • Stablecoin operations work reliably across inflows, approvals, payouts, and reporting.
  6. Phase 4 Current

    Adapters

    Objective: enable optional external integration without making external systems a kernel dependency.

    Key deliverables

    • Jurisdiction adapter framework with schemas, proofs, and reference workflows.
    • Where feasible, regulated settlement rails (for example CBDC-style instruments) integrated via disclosed gateways and module-based eligibility signals, coordinated through foundation/ResCo adoption work (planned).
    • Institutional reporting modules derived from standardized events and anchors.
    • Attestation modules and selective disclosure patterns.
    • Nonprofit overlays such as donation receipt workflows and sponsorship frameworks.

    Exit criteria

    • At least one high quality adapter demonstrates external recognition while leaving the kernel unchanged.
    • Entities can remain Hub-native or attach adapters without any mandatory graduation path.
  7. Phase 5 Current

    Maturity

    Objective: reach a state where the Hub can operate as long‑lived public infrastructure without a single required operator.

    Key deliverables

    • Decentralized validator set and governance participation.
    • Multiple independent indexers and reference implementations.
    • Predictable upgrade cadence and mature incident processes.
    • Sustainable foundation processes for standards, audits, and ecosystem support.

    Exit criteria

    • No single organization is required for the Hub to operate and evolve safely.
    • Entity creation and operation are routine with predictable costs and semantics.
  8. Optional future phase Current

    Advanced

    Scope: sub chains, specialized privacy execution, and public instrument models are explored only if real adoption proves they are needed and kernel invariants remain intact.