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.
Operating Context
Optional tags split activity by team, product, project, or channel for clearer tracking.
Equity Context
These tags apply only if equity workflows are added later, such as classes, pools, or vesting.
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.
Register and Bind
Register the entity and bind the authority roles so the owner is clearly linked to approvals.
Set Wallets and Limits
Connect the standard wallets and set approval limits so spending follows your rules.
Delegate Roles
Add employee role wallets and payee wallets when you want others to prepare work.
Collect Revenue
Issue invoices or accept direct payments so revenue lands in the merchant wallet.
Tag and Anchor
Tag money in and out, and anchor evidence for material items that require proof.
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.
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 ManifestoNicolas 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 accessNewsletter
Stay in the loop
Concise updates on testnet readiness, releases, and governance milestones.