Future adoption roadmap
Optional overlays, not required dependencies
dCorps is designed so entities can operate as Hub-native corporations or nonprofits without any jurisdiction, institutional, or sector overlay attached. These tracks summarize longer-horizon work that can expand adoption by mapping on-chain truth into external processes through optional modules.
Roadmap notice: Items below describe design intention and potential workstreams. They are not commitments and may change based on governance decisions, audits, partner readiness, and legal constraints.
-
Track A
Smart Jurisdiction integration
Objective: allow entities to reference Hub identity, governance, and evidence in external legal workflows without changing kernel semantics or rewriting history.
Design intention
- Jurisdiction adapter modules are optional overlays; a Hub entity is complete with or without them.
- A phased adoption path can start with a delegated filing provider bridge (pilot attestations + evidence anchors) before direct integration exists.
- A disclosure, fee, and reporting module can publish machine-readable status outputs and collect USDC service fees when entities opt in.
- Where feasible, modules can also publish eligibility signals for jurisdiction-scoped settlement rails (for example local stablecoins or CBDC integrations) via disclosed gateways or delegated operators.
- Where applicable, “recognition active/withdrawn” is controlled by jurisdiction keys (or an explicitly disclosed delegated operator), with legal effect arising off-chain.
- Making these integrations real is expected to require partner engagement and policy work, coordinated through the foundation and ResCo (planned), without implying outcomes or guarantees.
Boundaries
- Step 0 “Filed via Provider (Pilot)” must never be presented as legal recognition.
- Multiple providers and modules can exist; entities must be able to switch without erasing history.
- dCorps does not guarantee recognition or compliance; the Hub records facts and evidence timelines.
-
Track B
Institutions & regulators
Objective: make oversight and institutional workflows legible via standardized views over on-chain events, while keeping the Hub neutral and interface-independent.
Design intention
- Expose a standardized view of entity identity, lifecycle state, roles, and governance history.
- Produce reproducible reporting views from tagged inflow/outflow events, with coverage and provenance signals.
- Allow optional modules (jurisdictions, sector frameworks, attestations) to publish disclosed status outputs for those who choose to rely on them.
- Support integrations into external systems (illustrative: accounting, payroll, donor portals, procurement) without making any single interface “consensus”.
Boundaries
- The protocol is not a regulator and must not be presented as a government endorsement or approval.
- Disclosure posture matters: sensitive details can remain off-chain, referenced via anchors when needed.
- Institutions interpret Hub truth through their own policies and risk controls; dCorps does not enforce off-chain obligations.
-
Track C
Compliance & reporting automation
Objective: make obligations auditable and automatable where entities opt in, without turning the Hub into a compliance oracle.
Design intention
- Use governance events (proposals, approvals, executed resolutions) as an auditable decision record.
- Use tagged accounting events plus evidence anchoring to build time-window views and dispute-ready timelines.
- Use source labeling to distinguish typed-workflow tags from free-form entity tagging.
- Allow optional modules to require defined view export formats and emit status signals (active, withdrawn, disputed) without rewriting Hub history.
Boundaries
- Compliance depends on law, contracts, and off-chain process; dCorps does not make an entity “compliant” by itself.
- Transfer restrictions enforce on-chain approvals and evidence trails; they do not guarantee legal classification outcomes.
- Reporting views are derived from on-chain events for a selected timeframe; they are not promises of completeness outside disclosed inputs.
-
Track D
Reputation & assurance overlays
Objective: help stakeholders interpret behavior over time using defined inputs and disclosed issuers, without introducing a kernel-level scoring system.
Design intention
- Derive signals from inspectable inputs: governance events, tagged flows, evidence coverage, and module outputs.
- Show provenance: who issued the signal, what dataset was used, and what limitations apply.
- Support attestations (none, self, third-party) as explicit overlays rather than implied trust.
- Avoid opaque single-score representations when underlying reasons matter.
Boundaries
- The Hub does not maintain a global reputation bulletin board; overlays are opt-in and issuer-scoped.
- Signals prompt questions and due diligence; they do not replace verification.
- Interfaces can disagree on presentation; the on-chain record remains the source of truth.
-
Track E
Sector frameworks
Objective: enable sector-specific standards on top of shared primitives (identity, governance, wallets, accounting events) without fragmenting the kernel.
Design intention
- Allow sector and impact frameworks to publish derived interpretations and eligibility outputs from Hub state.
- Keep frameworks composable and opt-in: multiple sector modules can exist for different standards bodies and communities.
- Support defined metric logic (illustrative: allocation constraints, impact reporting, evidence requirements) with clear versioning and disclosure.
- Sector examples (illustrative): real estate programs, grant frameworks, or industry-specific reporting schemas built as modules and apps.
Boundaries
- Sector frameworks must not redefine kernel semantics; they publish overlays and derived outputs.
- “Official” status, where applicable, is a governance decision; multiple independent standards can still coexist.
- Examples above are illustrative and not commitments to specific sectors.