Vision events
A hypothetical event sequence toward a trusted Hub
dCorps is designed to become trusted infrastructure through observable adoption events: production entities, verifiable authority, reproducible views, and optional modules that map on-chain truth into external processes. The events below describe design intent and constraints, not a schedule or commitment.
Roadmap notice: Events below are illustrative turning points. They are not commitments and may change based on governance decisions, audits, partner readiness, and legal constraints.
-
Event 01
First Hub corporation in production
A small, stablecoin-native startup registers a Hub corporation and runs day-to-day operations through canonical wallets and tagged accounting events. Ownership, authority, and approvals are verifiable state—not only narrative policies, PDFs, and private spreadsheets.
Signals
- Units, roles, and executed resolutions are recorded as on-chain state.
- Canonical wallets and tagged events produce reproducible, cash-based time-window views.
-
Event 02
First Hub nonprofit in production
A small nonprofit registers a Hub nonprofit and runs donations, allocations, and board decisions on the Hub. Donors and partners can verify how funds move at least at category level, with optional evidence anchoring for material items.
Signals
- Donation and program wallets are canonical and publicly legible.
- Board governance and allocation views are reproducible from tagged flows.
-
Event 03
Counterparty trust without jurisdiction integration
For off-chain counterparties, auditors, and service providers, Hub-native entities adopt a governance binding document plus an authority evidence package that references on-chain roles and approvals. Material agreements are anchored by hash and tied to the approving resolution.
Signals
- Counterparties can verify entity identity, role bindings, and the relevant resolution record from public state.
- Anchored agreements can be corrected via supersession, preserving a legible, non-erasing timeline.
-
Event 04
Pilot Step 0 (temporary): delegated filing provider bridge
Pilot Step 0 is a temporary bridge between mainnet launch and direct jurisdiction integration. Providers perform off-chain filings under their own legal responsibilities and publish standardized on-chain attestations with evidence anchors.
Signals
- Reference interfaces label status clearly as “Filed via Provider (Pilot)” and never present this as recognition.
- Provider attestations include issuer identity, validity windows, evidence anchors, and dispute/supersession signals; providers can coexist and be switched without erasing history.
-
Event 05
Pilot Step 1 → Step 2: jurisdiction adapters
A jurisdiction (or an explicitly disclosed delegated operator under its supervision) pilots a disclosure, fee, and reporting module (Step 1). Where feasible, it graduates toward direct integration where recognition and registry actions are bound to module state under jurisdiction-controlled keys (Step 2).
Signals
- Step 1 defines eligibility, required disclosures (via anchored documents), reporting cadence, and fee collection in USDC.
- Where feasible, the same module pattern can extend to jurisdiction-scoped settlement rails (for example local stablecoins or CBDC integrations) via disclosed gateways and explicit eligibility outputs.
- Step 2 binds recognition status to jurisdiction-controlled keys; interfaces distinguish Step 0/1/2 states and never imply recognition from Hub state alone.
-
Event 06
Typed workflows and interoperable tooling
Core operating workflows (payroll, invoicing, grants, donation allocation, vendor payments) are implemented as typed modules or standardized message families that emit category tags as part of execution.
Signals
- Typed workflows emit deterministic tags; free-form tags remain possible but are clearly labeled.
- Schemas and conformance tests let many vendors serve the same entities—and let entities switch providers without losing history.
-
Event 07
Professional assurance becomes routine
Auditors and assurance providers use Hub exports plus evidence anchors as standard inputs. For material flows, evidence anchoring and optional counterparty receipts reduce dependence on bespoke data rooms.
Signals
- Assurance reports reference specific entity, role, and event state, not screenshots.
- Anchors and optional receipts/attestations raise integrity without making the protocol an adjudicator.
-
Event 08
Serious Web3 operators adopt the Hub
A major protocol or DAO adopts a Hub entity as its canonical corporate or nonprofit container. Authority, treasury policy, and reporting become a shared, verifiable record without changing the protocol’s own governance design.
Signals
- Roles and resolutions move from scattered documents into a standardized entity record.
- Partners can review consistent, comparable views across many operators without bespoke dashboards.
-
Event 09
Networks coordinate on shared rails
A coalition—such as a grant network, impact fund, or procurement program—requires members to operate via Hub entities and shared module standards. Cross-entity flows become legible across the whole network, not only inside each organization.
Signals
- Membership criteria reference entity types and module conformance rather than bespoke forms.
- Cross-entity flows stay traceable across members through canonical wallets and standardized tags.
-
Event 10
Public data and research layer
Journalists, NGOs, and academic groups use Hub views and exports as a common reference for studying governance, financial flows, and impact over time.
Signals
- Longitudinal studies use standardized, machine-readable entity data rather than ad hoc collections.
- Investigations can cite verifiable anchors and event references instead of screenshots.
-
Event 11
Global soft standard and infrastructure status
Funders, networks, and some institutions begin to accept Hub-compliant disclosures and dCorps-standard reports as routine evidence. Operating without an equivalent shared record remains possible, but it carries higher friction for due diligence and coordination.
Signals
- Programs accept standardized disclosures, module outputs, and reproducible views as routine evidence inputs.
- Operating without an equivalent shared record remains possible, but carries higher coordination and due diligence friction.
-
Event 12
DCHUB economics
As usage grows, DCHUB secures the Hub as shared infrastructure (gas, staking, governance) and coordinates upgrades and policy over time. Protocol fees and Treasury policy exist to fund security and public goods—not to promise any financial outcome.
Signals
- Gas fees (`DCHUB`) and staking secure the network; protocol fees and policy aim to fund security and public goods over time.
- Nothing in protocol economics is a promise of value accrual, liquidity, listings, or financial return.
-
Success criteria
What would count as “working”
We consider this working when independent parties can verify authority, approvals, and reproducible operating or allocation views using public chain data and anchored evidence—without bespoke data rooms.
Independent verification
- A third party can verify authority at a time, approval trails for material actions, and reproducible views from events.
Interoperable tooling
- Multiple indexers and apps can serve the same entities by following schemas and passing conformance tests.
Honest labeling
- Interfaces distinguish digital-only entities, Step 0 provider attestations, Step 1 reporting, and Step 2 recognition without implying legal outcomes.