Skip to main content

Whitepaper (Condensed)

Document type: Whitepaper (mid-length)
Doc ID: DCHUB-WP-PUBLIC-2025-12-21
Version: v1.3.1
Status: Final v1.3.1
Release date: December 21, 2025
Author: Nicolas Turcotte, Founder
www.dcorps.com · [email protected]
Last updated: 2026-01-25

This is the condensed whitepaper. For the official long version, see docs/whitepaper/WHITEPAPER_LONG.md.

Disclaimer

Nothing in this document is:

  • an offer to sell, or a solicitation of an offer to buy, any token, share, or security;
  • investment, legal, tax, or accounting advice; or
  • a promise of listing, price performance, or financial return for any asset.

This whitepaper describes a technical and economic design for the dCorps protocol as currently envisioned. Many details may change with engineering work, legal advice, market conditions, and community input. Any token sale, equity financing, or legal agreement will be governed by its own dedicated documentation and terms, not by this whitepaper.

Participants are responsible for obtaining their own professional advice and for complying with applicable laws in all relevant jurisdictions.

How to use this document

Reader shortcuts:

  • Founders and operators: sections 0, 4, 5, 6, 7.
  • Nonprofit leaders and donors: sections 0, 4.2, 5, 8.
  • Builders and integrators: sections 3, 4, 5, plus docs/spec/.
  • Rollup operators and security contributors: sections 6.4, 7, and docs/security/.
  • Institutions and legal professionals: sections 2, 7, 9, and docs/legal/.

Document stack and what is normative

This whitepaper explains intent, scope, boundaries, and design rationale. It is not the protocol specification.

For interoperability and correctness, the intended document stack is:

If there is a conflict between this whitepaper and a normative specification, the normative specification is intended to take precedence.

Table of contents

    1. Executive summary
    1. Problem and context
    1. Design principles and boundaries
    1. Architecture overview
    1. Entity models (corporations and nonprofits)
    1. Operations, accounting events, and reporting
    1. Token model and economic mechanics (high-level)
    1. Protocol governance and upgrade safety
    1. Security, privacy, and risk posture
    1. Legal position and public disclaimers
    1. What to read next

0. Executive summary

0.1 Overview

dCorps is a digitally native base layer for corporations and nonprofit organizations.

It provides a shared standard where organizations can be created, owned, governed, and operated on-chain. The dCorps Hub is the kernel: it defines canonical identity, ownership and authority, governance actions, wallet structure, commerce primitives, standardized accounting events, document anchoring, and an auditable history.

v1 in one sentence

In v1, an entity can register, set roles and authority/operational wallets, issue invoices or recurring plans, run stablecoin operations through tagged accounting events, and view reproducible cash-based operating and allocation summaries over any selected timeframe, with optional evidence anchoring.

Later phases are designed to support multiple approved stablecoins and, where technically and legally possible, CBDC-style instruments through the approved asset registry and optional jurisdiction adapter modules. This is expected to require issuer and jurisdiction cooperation and to be pursued through ecosystem adoption work coordinated by the foundation and ResCo (planned).

0.2 Kernel and adapters

dCorps keeps a strict boundary between a minimal kernel and optional modules:

  • Kernel (required): entity registry, roles and authority, governance actions, wallet structure, commerce primitives, accounting events, and document anchoring.
  • Adapters and modules (optional): jurisdiction recognition workflows, institutional reporting views, sector and impact frameworks, and attestations derived from kernel state.

Entities must be able to operate without adapters. Adapters may publish derived interpretations, but they must not redefine kernel semantics or rewrite history.

0.3 v1 scope (ships vs not in scope)

In scope for v1

  • Hub rollup (Arbitrum Orbit, Rollup mode), DCHUB gas + protocol governance + protocol-level fees, and basic on-chain governance.
  • Hub corporation and Hub nonprofit entity containers.
  • Authority and canonical operational wallets.
  • Commerce primitives (catalog items/services, invoices, recurring plans).
  • Tagged accounting events.
  • Explorer/indexer-derived cash-based operating views (corporations) and allocation views (nonprofits) over any selected timeframe.
  • Document anchoring and reference standards for explorers and indexers.

Out of scope for v1

  • any requirement to attach a jurisdiction adapter, legal wrapper, or compliance process;
  • operating or providing any bank or fiat rail integrations (not supported at any layer), or custody of fiat;
  • any guarantee of listing, liquidity, or public-market infrastructure;
  • mandatory protocol-level KYC/KYB/AML (these live in applications, service providers, and optional modules);
  • default full privacy execution (privacy is an optional evolution).

1. Problem and context

1.1 Stablecoins are usable; entity infrastructure is not standardized

Stablecoins and wallets can already function as day-to-day operating accounts for global teams. However, authority, approvals, and reporting remain fragmented across private tools and jurisdiction-specific systems.

Common failure modes include:

  • unclear or unverifiable authority (who could approve what, when);
  • approvals and policies scattered across private tools and reporting artifacts, without a shared, queryable history;
  • operational reporting that requires manual reconciliation and cannot be reproduced from shared inputs; and
  • nonprofit allocation claims that are difficult for donors to verify without trusting custom reporting.

1.2 What “digitally native” means here

dCorps reuses proven organizational abstractions (ownership, units, boards, roles, approvals) but expresses them as deterministic on-chain state machines and events.

This does not replace legal responsibility. It provides a default operating posture for on-chain economic activity: counterparties can rely on verifiable authority and approvals as the default, even when no jurisdiction adapter is attached.

2. Design principles and boundaries

2.1 Minimal kernel, optional adapters

The Hub kernel has one job: be a neutral, robust, auditable organization kernel. Everything else is optional and replaceable.

dCorps avoids hard-coding jurisdiction-specific or sector-specific logic into the base protocol. Those differences live in optional protocol modules and matching off-chain processes.

2.2 Non-custodial and non-intermediation boundary

dCorps is not a custodial service. Funds live in entity-controlled wallets and are moved by on-chain authority rules and approvals.

dCorps does not promise compliance, listing, liquidity, or investment returns. It provides a programmable and auditable entity standard that others can build around.

2.3 Reporting honesty: provenance and coverage

The protocol is designed to surface what is known from on-chain facts, and to label what is derived, self-tagged, or supported by third-party attestations.

Reporting views should include coverage and integrity signals so readers can interpret transparency honestly.

3. Architecture overview

At a conceptual level:

External applications (UIs, markets, payroll, donation portals, dashboards)
        |
        v
Optional adapters and modules (jurisdiction recognition, sector frameworks, attestations)
        |
        v
dCorps Hub kernel (entity registry, roles, governance, wallets, commerce primitives, accounting events, anchoring)
        |
        v
DCHUB gas + rollup settlement (sequencer + Ethereum)

Applications provide user experience. The Hub provides canonical state and events. Optional modules publish derived interpretations under explicit rules and governance.

4. Entity models (corporations and nonprofits)

4.1 Hub corporation (private corporation container)

A Hub corporation is a complete on-chain entity container intended for long-lived operation on the Hub.

Core characteristics:

  • an internal unit-based cap table (10,000 base units by default);
  • role-based authority and approval governance;
  • authority wallets for approvals and canonical operational wallets for revenue and treasury activity;
  • tagged accounting events for inflows/outflows and reproducible reporting views.

Units are scoped to the entity. They are not global protocol tokens.

The base unit count is a declared denominator (10,000 by default). Corporations may expand it in multiples of 10,000 to increase precision without changing ownership percentages; v0.1 templates recommend a practical maximum of 1,000,000 base units for interoperability and UI performance.

4.2 Hub nonprofit (board-governed nonprofit container)

A Hub nonprofit is a complete on-chain entity container designed for donor-relevant transparency and board-governed controls.

Core characteristics:

  • board governance with explicit roles and voting rules;
  • donation and program wallet structure;
  • allocation rules and category-level transparency;
  • reproducible allocation views derived from tagged accounting events over any selected timeframe.

Donations may arrive directly to the donation wallet without invoices. Invoices or recurring plans are optional for grants, sponsorships, memberships, or pledged giving, with optional donation receipts anchored for confirmation.

Nonprofits are expected to meet a minimum transparency floor meaningful for donors, while allowing selective disclosure patterns as needed for beneficiary safety.

Nonprofits do not have equity and are not “owned” by units, but they can still participate in group structures (for example by holding units in a Hub corporation subsidiary).

4.3 Optional future extension: private execution zones

Some organizations may eventually require specialized execution environments for extreme scale or specialized privacy. These can be implemented as application-level execution zones or off-chain workflows that anchor evidence back to the Hub under explicit standards.

v1 does not require any private execution zones for entities to operate.

5. Operations, accounting events, and views

5.1 Canonical wallets and tagged accounting events

Entities operate through canonical wallet types (for example merchant, donation, program, treasury). Flows through these wallets can be recorded with tagged accounting events.

Authority wallets sign governance actions and approvals, while operational wallets receive and send USDC. The kernel also supports on-chain catalog items/services, invoices (payment requests), and recurring plans tied to canonical payment wallets.

Tags are explicit. The Hub does not attempt to infer them. Typed workflows can produce deterministic tags, while external applications may also submit tags under the entity’s authority.

5.2 Cash-based operating views (corporations)

dCorps supports cash-based operating views: time-window summaries derived from tagged inflow/outflow events, excluding accrual accounting treatments.

Cash-based views are designed for operational clarity and comparability. They are not GAAP/IFRS financial statements.

Important boundary: these views are derived by explorers/indexers (and optional dApps) from on-chain events. The kernel does not require a reporting cadence and does not store periodic statements as native state.

5.3 Nonprofit allocation views

Nonprofit allocation views are reproducible cash-based time-window views derived from tagged accounting events and the nonprofit’s allocation rules.

The design goal is meaningful transparency for donors without forcing disclosure of sensitive details.

5.4 Evidence anchoring and integrity signals

For material items, entities may anchor evidence (invoices, receipts, agreements) by hash and link accounting events to evidence references.

Views should surface integrity signals, such as uncategorized flows, provenance labels (typed workflow vs entity-tagged), and optional attestation signals.

6. Token model and economic mechanics (high-level)

6.1 Separation of DCHUB, Hub units, and optional dShares

dCorps separates protocol participation and entity-level ownership:

  • DCHUB: Hub gas, protocol governance, and protocol-level fees; does not represent ownership in user entities.
  • Hub units: internal ownership and voting rights within a Hub corporation; scoped to that entity.
  • dShares (optional future extension): equity-style tokens issued by entities under applicable legal regimes, potentially via Hub modules or approved external rails.
  • Nonprofit governance: board and allocation rules, not equity; no token represents ownership of a nonprofit.

6.2 DCHUB and USDC roles

  • DCHUB prices execution (gas) and supports protocol governance and protocol-level fees.\n+- USDC is the baseline unit of account for examples and the primary operating currency for many entities and protocol service fees (canonical bridged USDC at launch).

This describes protocol mechanics, not promises about price, liquidity, or market outcomes.

6.3 Supply and distribution (reference)

For the fixed hard-cap supply stance, indicative allocations, vesting, and emissions vocabulary, see:

7. Protocol governance and upgrade safety

The governance design intent is conservative:

  • keep the Hub minimal and neutral;
  • make hostile or careless upgrades slower and more visible;
  • treat certain changes as higher-risk “Protected Changes” with higher thresholds and safety mechanisms.

Governance process and proposal classes are described in docs/policy/POL-GOV.md. The Whitepaper Long defines the baseline Protected Change thresholds and safety expectations.

8. Security, privacy, and risk posture

dCorps treats security as a first-order constraint:

  • defense-in-depth across protocol, infrastructure, and process;
  • audits and a bug bounty program for critical components;
  • clear incident response procedures and communications expectations.

Privacy is not assumed by default. Confidentiality exists only when an entity uses privacy-preserving execution or disclosure tools. Interfaces should clearly label what is raw on-chain data, what is aggregate, and what is a claim supported by attestations.

Entities declare a disclosure mode at creation (Mode A, B, or C), and the mode is public metadata that tells interfaces how to render data. Every entity also has a lifecycle status (draft, active, suspended, or dissolved) recorded in the registry, so counterparties can see standing at a glance.

For security posture and operational docs, see docs/security/. For a plain-language risk overview, see docs/legal/RISK_DISCLOSURE.md.

dCorps is a protocol and documentation set. It is not legal advice and it does not create legal personhood.

Legal status, filings, reporting obligations, and enforcement remain off-chain and jurisdiction-dependent. Optional jurisdiction adapter modules may support recognition workflows, but legal effect comes from local law and contracts that reference those workflows.

See: