dCorps Hub
DevCo Testnet Foundation Audit Mainnet Adoption

Solo Corporation

What It Is

CORP-SOLO is the simplest dCorps company setup for one owner. It creates a public company profile, the main wallets to get paid and pay others, and an owner role that controls approvals. You stay in control while anyone can verify the structure and activity on-chain.

Template Code

Template code: CORP-SOLO. This label keeps the template consistent across apps, links, and public views.

Single Controller

One entity ID with a single primary owner wallet holding final authority.

Default Unit Model

Ownership is split into base units so percentages are simple and consistent across apps and explorers.

Standard Wallet Types

Standard wallet types separate revenue, spending, and reserves so money paths are easy to follow.

Tagged Flows

Payments carry tags that explain why money moved, so activity stays clear without manual notes.

Best Fit

CORP-SOLO fits solo operators who want a simple, transparent setup that works immediately. It suits freelancers, small studios, and early startups that want clear wallets and approvals without heavy process. Routine tasks can be delegated while the owner keeps final control.

Single Decision Maker

One owner makes final calls, while helpers can prepare tasks without taking control.

Stablecoin Native

Money in and out runs on stablecoins instead of bank rails, so the flow stays on-chain.

Early Stage Fit

Built for solo founders, consultants, and early operators who want structure without overhead.

Migration Path

A clear step up from spreadsheets to a shared on-chain view that clients can verify.

Not a Fit

This template is not for teams that require shared approvals, board votes, or formal investor controls. It is built for one owner with single-point authority, not multi-signer governance. Donation-led groups should use nonprofit templates designed for fundraising and disbursement.

Multi Signer Governance

Not suitable when multiple people must co-sign decisions, vote on changes, or approve spending.

Investor Restrictions

Does not cover complex investor terms, vesting rules, or transfer limits that venture structures require.

Nonprofit Model

Nonprofits require donation and allocation workflows; use the nonprofit templates instead for fundraising.

Ownership and Units

Keep percentages obvious by expressing shares in small, easy-to-read units. The default unit count keeps math simple, like splitting 100 percent into small pieces. If you want more precision later, you can add units without changing anyone's share.

Default Base Units

Starts with 10,000 base units, so 1 unit equals 0.01% ownership and is easy to read.

One Unit Vote

Voting follows unit ownership by default, with one unit equal to one vote unless governance changes it.

Precision Expansion

Add more base units later to increase precision while keeping every owner's percentage the same.

Authority and Governance

Bind roles on-chain so people can see who is allowed to act. Approvals and role changes leave a visible trail, which makes decisions easier to explain later. If keys change, the current authority is still clear because the role history remains public.

Owner Bound Roles

Admin, board, and treasurer roles map to the owner wallet by default in CORP-SOLO.

Authority Signatures

The authority wallet signs approvals and governance actions, creating clear accountability for decisions.

Key Rotation

Keys can be rotated through a governance action so access changes are public and traceable.

Protected Actions

Sensitive actions can require explicit approval, even in a single-owner setup, for safer control.

Employee Role Wallets

Delegate tasks without handing over full control by using role wallets. Teammates can prepare invoices, tag payments, or stage payouts while the owner approves the final step. This keeps work moving while responsibility remains clear.

Role Types

Role wallets can be set for operators, accountants, approvers, or payout executors depending on the team.

Scoped Permissions

Permissions can allow invoicing, tagging, or payout preparation while blocking execution until the owner approves.

Payee Separation

Payee wallets receive funds, while role wallets handle authority unless you explicitly bind both together.

Delegation and Approval Limits

Set approval limits to define what runs automatically and what must be reviewed. Small routine payments can clear quickly, while larger transfers wait for the owner's sign-off. Limits can vary by wallet or category so the rules match how the business operates.

Role Scope

Each role includes a clear scope that lists which actions it can prepare, approve, or execute.

Approval Thresholds

Thresholds set the amount or risk level that triggers an approval step before money moves.

Wallet and Category Limits

Limits can be tuned by wallet type or spend category so different activities follow different guardrails.

Wallet Structure

Separate money by purpose so activity is easy to follow. One wallet receives customer payments, another handles operating spend, and a reserve wallet can hold savings. Authority wallets sign approvals, while payment wallets receive and send funds. This keeps control separate from cash so activity stays easy to verify.

Merchant Wallet

Wallet type MERCHANT is the public payment wallet where customer revenue lands.

Operating Treasury

Wallet type OPERATING_TREASURY handles routine business spending and outgoing payments for vendors and contractors.

Reserve Wallet

Wallet type RESERVES holds buffers or long-term funds when you decide to set some aside.

Authority Separation

Authority wallets approve actions, while payment wallets receive and send funds so control stays separated from cash.

Operating Assets

Reporting totals are shown in USDC so values stay stable and easy to compare. Treasury wallets can also hold DCHUB for gas or long-term exposure if you decide to keep it. Those holdings are tagged so summaries stay clear and do not mix with operating cash.

Reporting Unit

All reporting in v0.1 uses USDC totals so views stay stable across time and tools.

Treasury Holdings

Treasury and reserve wallets may hold DCHUB alongside stablecoins when you want network exposure.

Tagged Assets

DCHUB balances should carry asset_tag and BAL_DCHUB so explorers separate them from operating cash.

Gas Payments

Transaction fees are paid in DCHUB by the signing wallet each time it submits a transaction.

Commerce and Payment Modes

CORP-SOLO supports both direct payments and invoices, so customers can pay in the way that fits them. Recurring plans cover subscription billing with scheduled payments that run on-chain. Every invoice carries a status so you can see what is open, paid, or canceled at a glance.

Direct Payments

Customers can pay directly to the merchant wallet when the amount is known in advance.

Invoice Requests

Invoices are on-chain payment requests tied to the entity, with amount, due date, and payer reference.

Recurring Plans

Recurring plans schedule repeat billing so subscriptions or retainers can run without manual re-entry.

Status Updates

Each invoice status updates as it moves from open to paid or canceled, so follow-up is clear.

Catalog Items

Define what you sell once so invoices and payments stay organized as the business grows. Each item has a name, price, and ID that can be reused across invoices and tags. This creates a consistent view of sales without retyping details every time.

Item Reference

Create an item_id with a clear label and price so each product or service is easy to reuse.

Cost Baseline

Add an optional cost baseline so margins can be estimated later without retroactive guesswork.

Invoice Linking

Use item_id on invoices and tags to connect sales activity to totals and views.

Payroll and Contractor Flows

Tag payroll and contractor payouts so compensation is visible without mixing it with authority roles. Payee wallets receive funds, while approval roles control when payments go out. Apps can schedule or batch payouts to match payroll cycles.

Payee Wallets

Payee wallets receive salary or contractor payments directly, separate from any authority roles.

Tagged Payouts

Payouts carry payroll or contractor tags so compensation is easy to identify in summaries.

Optional Schedules

Apps or SDKs can schedule or batch payouts when you want recurring or grouped payments.

Tagging and Evidence

Tags are simple labels added to each payment so activity stays understandable over time. For important transactions, you can attach proof by anchoring a secure reference to an invoice, receipt, or agreement. This creates a clear trail without publishing private files.

Core Required

These tags are required on every flow so views stay consistent. Pair reference_type with reference_id.

category_code counterparty_type reference_id reference_type

Operating Context

Optional tags split activity by team, product, project, or channel for clearer tracking.

business_unit_tag department_tag cost_center_tag project_tag product_tag item_id channel_tag region_tag counterparty_tag

Equity Context

These tags apply only if equity workflows are added later, such as classes, pools, or vesting.

equity_class_tag vesting_schedule_tag option_pool_tag

Evidence Anchors

Anchors link to invoices, receipts, or agreements without publishing the document itself.

Materiality Threshold

Set a materiality threshold so larger items require evidence, with 1,000 USDC as the default.

Counterparty Directory and Privacy

Repeat clients or vendors can be labeled with private nicknames instead of real names. The real-world mapping stays off-chain under your control, which protects sensitive data. Public views show only the tag and wallet, not the underlying identity. You still get a consistent history of who pays and who gets paid without exposing identities.

Pseudonymous IDs

Use counterparty_tag to label repeat clients or vendors without exposing their legal names on-chain.

Off Chain Mapping

Keep the real-name mapping off chain so only your team can see it.

Repeat Counterparties

Track repeat counterparties across invoices and payments without publishing personal or business details.

Operating Flow

Move from setup to live activity in a simple sequence. Setup starts with the owner wallet, an entity name, and the first wallet bindings. You register the entity, connect wallets, take payments, and tag what happens so views stay consistent. Each step writes to the on-chain history, which keeps operations clear for you and anyone checking.

1

Register and Bind

Register the entity and bind the authority roles so the owner is clearly linked to approvals.

2

Set Wallets and Limits

Connect the standard wallets and set approval limits so spending follows your rules.

3

Delegate Roles

Add employee role wallets and payee wallets when you want others to prepare work.

4

Collect Revenue

Issue invoices or accept direct payments so revenue lands in the merchant wallet.

5

Tag and Anchor

Tag money in and out, and anchor evidence for material items that require proof.

6

Review and Close

Review live views, then close a period if you want a fixed snapshot for later comparison.

Live On-Chain Views

Explorers show live summaries from tagged transactions without waiting for manual exports. You can see balances, recent activity, and tag coverage as it happens. Others can check the same numbers you see, which keeps public visibility in sync.

Wallet Balances

Wallet balances update as transactions confirm on-chain, so the numbers stay current.

Time Window Views

Time window views summarize activity over a period without waiting for a manual close.

Coverage Ratios

Coverage ratios show which flows are fully tagged and which still require context.

Data Exports

Exports are optional for offline analysis or backups when you want files outside the chain.

Registry, Logs, and Proof

Use the registry and governance log to verify identity, status, official wallets, approvals, and role changes. If a document must be proven later, you can anchor a secure reference with a timestamp. Together these sources create a durable history that is difficult to rewrite.

Registry Entry

The registry lists identity, status, and official wallet bindings so anyone can verify the current setup.

Governance Log

The governance log shows approvals, votes, and role changes in time order for clear accountability.

Anchored Proof

Anchors timestamp receipts and contracts so their existence can be verified later without publishing the files.

Lifecycle and Status

Signals show whether a company is active, paused, or closed, so people know if payments should go through. Apps can show the status automatically as a simple safety cue. This reduces confusion and prevents money from going to inactive entities.

Status States

Status labels show whether the entity is active and safe to pay, using a consistent color set.

draft active suspended dissolved

Payment Endpoints

Payment endpoints resolve from the entity ID and wallet type, so users do not copy raw addresses.

Interface Warnings

Interfaces can warn when an entity is suspended or dissolved so payers avoid sending funds.

Upgrade Paths

As the business grows, you can move to a larger template without losing continuity. Upgrades add more roles, approvals, and governance layers while keeping the same entity ID and history. This lets you start simple now and expand when complexity appears.

Private Standard

Template code CORP-PRIVATE-STD adds multi-signer control and a second approval layer for growing teams.

Venture Template

Template code CORP-VENTURE adds investor terms, board workflows, and equity tagging for venture-backed structures.

Complex Private

Template code CORP-COMPLEX-PRIVATE supports complex holdings, committees, and protected matters for advanced governance.

Where to Operate and Verify

The official app handles day-to-day actions like registration, invoicing, and approvals. Public tools (registry, explorer, and official indexer) let anyone verify identity, status, and wallet bindings. This keeps what you do and what others see in sync across the network.

Official App

The official app is where you register, issue invoices, tag payments, and approve actions.

The Registry

The registry confirms identity, status, and official wallets so counterparties can verify who they are paying.

The Explorer

The explorer, powered by the official indexer, shows transactions, balances, and public history in one view.

Official Indexer

Reference data service that powers explorer summaries and reporting views for consistent public visibility.

dApps & SDKs

Third-party dApps and SDKs let you build custom flows or integrate payments into your own products.

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.

Newsletter

Stay in the loop

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

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.