Protocol Architecture

System Layers

The architecture describes how the Hub chain executes transactions and records canonical entity state. The Hub runs on dCorps Chain—an Arbitrum Orbit rollup (Rollup mode) that settles to Ethereum. Layers run from rollup execution and settlement to kernel contracts, optional adapters, and downstream interfaces.

Rollup execution

Arbitrum Orbit rollup executes transactions; DCHUB powers gas, governance, and protocol-level fees.

Kernel modules

Core modules store identity, roles, decisions, wallets, and the event history.

Optional adapters

Optional adapters add jurisdiction, sector, or compliance context without changing kernel state.

Interfaces + indexers

Indexers and apps read the chain; they render non-authoritative views.

Kernel Core Modules

Every entity relies on a minimal set of core modules that define the canonical record. They stay minimal so governance can evolve without changing the standard.

Entity registry

Identity, entity type, and lifecycle status so entities can be referenced and verified.

Roles and authority

Role bindings and permissions define who can propose, approve, or spend.

Governance actions

Proposals, votes, and resolutions recorded as the official decision history.

Wallets and events

Official wallets and tagged inflow/outflow events track treasury activity.

Document anchors

Document hashes anchor evidence so later proofs can be verified.

Disclosure and Lifecycle Signals

The architecture records disclosure mode and lifecycle status in the canonical registry so interfaces can show what is public, what is aggregated, and whether an entity is active.

Disclosure modes

Mode A · Everything public

Maximum verifiability from raw chain data.

Mode B · Public structure, aggregate reporting

Aggregates and proofs replace sensitive line items.

Mode C · Private execution, public anchors

Private zones or sub-chains anchor summaries to the Hub.

Confidentiality requires privacy tools; the mode is a visibility signal.

Lifecycle status

draft

Created, not yet active for counterparties.

active

Operating and discoverable in the registry.

suspended

Paused by governance or policy triggers.

dissolved

Closed and no longer active.

Lifecycle changes are recorded on-chain as governance events.

Optional Modules and Adapters

Add optional context through modules and adapters that interpret kernel state without redefining it. Attach or remove them as needs change. They can add jurisdiction, sector, or assurance context.

Jurisdiction workflows

Optional workflows to align entities with local recognition requirements.

Sector frameworks

Sector-specific governance overlays or reporting structures built on the kernel.

Attestations

External attestations or audits that reference kernel records without rewriting them.

Reporting overlays

Disclosure templates and outputs generated from standardized event records.

Canonical vs Derived

On-chain state is time-ordered and tamper-evident. Derived views are off-chain and non-authoritative; anyone can reconstruct them from the chain.

Canonical (on-chain)

Module state, parameters, and event history secured by consensus.

Derived (off-chain)

Indexer views, dashboards, and exports recreated from canonical data.

Recording Mechanics

Write events deterministically in stablecoin-native form (USDC). Events are time-ordered and can include evidence anchors. No fiat rails or custody are required.

Registration

Create entities and update lifecycle status in a verifiable sequence.

Governance

Submit proposals and record approvals that update canonical state.

Treasury events

Record tagged USDC inflows, outflows, and transfers from official wallets.

Anchors

Anchor documents and evidence with hashes that can be verified later.

Manifesto

"My goal is simple: make it possible for anyone, anywhere, to form an entity that can operate with credibility, continuity, and real financial rails, built for stablecoin-native operations."

Read the Manifesto

Nicolas Turcotte

Founder and Lead Engineer

Contribute now

Testnet is for builders, operators, and stewards who want to validate the Hub in public.

Protocol engineers

Working on kernel definitions, message scope, and invariants.

Indexer and data engineers

Defining event schemas and reproducible view inputs.

Early operators

Testing sequencer, batch posting, and operational scope under testnet rules.

Infrastructure-aligned investors

Tracking scope, risks, and progress (no return claims implied).

Legal counsel

Reviewing boundary posture, non-custodial scope, and document stack order.

Governance stewards

Shaping kernel/adapters separation and upgrade posture.

Testnet

Testnet access

If you're building or validating the Hub, request testnet access to evaluate it.

Request testnet access

Newsletter

Stay in the loop

Concise updates on testnet readiness, releases, and governance milestones.