DaoDex Whitepaper

DaoDex is an Internet Computer protocol for forming, funding, governing, and trading tokenized decentralized organizations. It combines a factory and capital‑raising backend with a dedicated governance canister, an ICRC‑compatible token ledger, a spot orderbook, a discussion forum, investor applications, and a certified SEO frontend.

The protocol is designed around a simple idea: capital formation should create an operating institution, not merely a tradable token. A successful public raise provisions an isolated governance system, treasury, token ledger, forum, and exchange market for that DAO. Investor allocations begin as governance stake, treasury actions pass through motions, and liquid trading becomes available only after tokens leave governance custody.

DaoDex uses canister isolation to reduce shared‑state risk. Each launched DAO receives its own governance, ledger, forum, and orderbook canisters. The platform backend coordinates formation and settlement, but linked application canisters are handed to the DAO's governance canister at provisioning. Persistent protocol state is stored in stable memory, and financial workflows use durable operation identifiers and in‑progress guards to limit duplicate execution across asynchronous calls.

Many token‑launch systems optimize for issuance and price formation while leaving governance, treasury custody, product ownership, and investor participation as separate or informal concerns. This creates structural weaknesses:

• fundraising can be disconnected from an organization's operating assets;
• founders may retain unilateral control after selling governance tokens;
• token holders may receive liquid assets without a meaningful governance role;
• treasury actions may lack transparent proposal and execution records;
• secondary liquidity may depend on opaque or centrally controlled mechanisms;
• every DAO may share the risk of one monolithic contract.

DaoDex treats a DAO launch as coordinated infrastructure deployment. A listing connects organizational metadata, capital commitments, governance stake, treasury custody, application‑canister control, public discussion, and secondary trading into one lifecycle.

The intended result is not risk‑free ownership. It is a more explicit and inspectable set of relationships: who can create a DAO, where capital is held, how voting power is computed, what actions motions can execute, when tokens become liquid, and which canister controls each component.

2.1 Institution before liquidity

A public raise does not issue freely tradable tokens immediately. When the DAO launches, investor and founder allocations are represented as governance neurons. Tokens become liquid only through the unstaking process.

2.2 Treasury custody over founder custody

Capital committed during a raise is held under protocol‑controlled DAO subaccounts and, after settlement, routed to the DAO governance treasury after protocol and ledger fees. The intended destination is an on‑chain governance institution, not a founder wallet.

2.3 Per‑DAO isolation

Every launched public DAO receives dedicated governance, forum, orderbook, and governance‑token ledger canisters. Private DAOs receive governance, forum, and ledger canisters and may request an orderbook later. A failure in one DAO's market or governance state therefore does not directly mutate another DAO's state.

2.4 Explicit control transfer

At submission, the platform backend must be one of the controllers of every linked application canister. It need not be the sole controller. During successful provisioning, the backend replaces the complete controller set of each linked application canister with the new governance canister. Governance becomes the sole controller.

If a public raise fails, a configured fallback principal is added only when the backend is still the app canister's sole controller. An existing multi‑controller set is not changed. This avoids overwriting a control arrangement that evolved during fundraising.

2.5 Durable, inspectable state

Core records are stored with ic-stable-structures. Memory identifiers are persistent schema contracts. Financial operations use stable journals or processed‑operation registries where replay could otherwise create duplicate transfers, minting, or settlement.

3.1 Platform backend

daospot_backend is the factory and public registry. It validates and stores submissions, reserves tickers and app‑canister claims, collects production publishing fees, accepts ICRC capital transfers, provisions child canisters, allocates launch tokens, settles raises, coordinates refunds, indexes DAO relationships, maintains user holdings, and orchestrates notifications and SEO publication.

3.2 Governance canister

Each DAO governance canister owns its governance state independently. It maintains neurons, motions, votes, recurring payments, execution history, staged application WASM, refund allocations, and processed settlements in stable memory.

The governance canister is also the operational owner of incorporated application canisters. The founder is represented as the CEO principal, but that role is caller authority rather than automatic IC controller authority.

3.3 Token ledger

Each DAO receives an ICRC‑1 governance‑token ledger. Governance is its minting account. Token precision is currently three decimals. The ledger supports investor allocations, staking, unstaking payouts, governance‑authorized minting, and base‑asset settlement on the orderbook.

3.4 Orderbook

The orderbook is a funded spot exchange for one base/quote pair. It supports buy and sell orders, price‑time‑priority matching, cancellations, trade history, market depth, and pending payout accounting. It does not implement leverage, margin, borrowing, or perpetual funding.

Prices are quote‑ledger smallest units per whole base token and are scaled using the base ledger's actual decimals. Quantities are base‑token smallest units. Both ledger decimal values are read and stored at setup.

3.5 Forum

Each DAO receives a forum for topics, comments, tags, and moderation. Governance motions are published best‑effort as linked discussion topics. Motion commitment does not fail merely because forum publication fails.

3.6 Certified discovery and SEO

daospot_seo embeds the frontend, renders Handlebars metadata into DAO‑specific pages, and certifies responses with the IC HTTP certification tree. Only the configured backend can publish metadata. The backend prepares structured DAO source text, requests a concise description through DeepSeek using ic-rig, falls back to a generic description on failure, and publishes without rolling back a successful DAO submission.

The SEO canister also serves the shared Internet Identity derivation origin, alternative‑origin declaration, and application metadata used to display the DaoDex name and logo during authorization.

4.1 Submission

A founder may create a public fundraising DAO or a private DAO. Metadata includes the name, description, token symbol, FAQs, website, linked application canisters, and an optional fallback owner.

The backend validates fields, normalizes and reserves the ticker, rejects duplicate linked canisters, checks controller topology on‑chain, and reserves app‑canister claims across asynchronous validation. On mainnet, publication also collects a 20 ICP fee.

For linked app canisters, the backend must appear somewhere in the controller set. This permits founders to retain other controllers during fundraising without weakening the backend's ability to perform the final handoff.

4.2 Public primary raise

A public DAO begins in Fundraising. The founder configures a raise expiration between seven and forty‑five days, an optional target capital, an optional minimum contribution, and an optional per‑wallet maximum.

Investors approve the backend on the configured ICRC quote ledger and call invest_in_dao. The backend moves the net contribution into a deterministic DAO subaccount after accounting for the ledger fee. A per‑DAO financial‑operation guard prevents overlapping financial mutations, and a maximum investor count bounds state growth.

The primary raise has no changing quoted token price. Investors commit capital, and the fixed investor allocation is distributed pro rata at settlement:

investor allocation = investor net contribution / total net raised
                      × investor token pool

When the target is reached, provisioning starts from the triggering investment. If the window expires below target, the DAO enters PreLaunch; the founder may accept the amount raised or decline and refund investors. If no decision is made within the current prelaunch timeout, the primary raise is refunded and the DAO becomes Inactive.

4.3 Private DAO

A private DAO bypasses the public raise and provisions governance, forum, and ledger canisters directly. No spot orderbook is created automatically. The founder may later request one after governance and ledger setup.

4.4 Successful provisioning

The public setup path creates and installs four canisters:

1. governance‑token ledger;
2. spot orderbook;
3. forum;
4. governance.

After installation and treasury settlement succeed, linked application canisters are transferred to governance as sole controller. On mainnet, governance becomes self‑controlled. Local deployments retain the backend alongside governance for development maintenance.

Provisioning is ordered so application control is surrendered only after required child canisters and financial settlement succeed.

The governance token uses three decimal places. The configured total supply is ten billion whole tokens. The fixed public‑launch allocation is one billion whole tokens:

The remaining configured supply is not automatically placed into investor circulation by the primary launch. Future issuance depends on governance's ledger mint authority and proposal system.

Investor and founder allocations are initialized as governance neurons. Liquidity is minted to orderbook escrow and attached to three governance‑owned asks:

Prices are multiples of the primary clearing price. Each ask uses a distinct mint block, and the orderbook validates provenance and prevents a block from funding multiple orders.

6.1 Neurons and voting power

Staked tokens are held in per‑principal neurons. Voting power is sublinear and time‑gated:

active stake   = staked tokens − tokens queued for unstaking
eligible stake = min(active stake, current ladder value)
voting power   = floor(sqrt(eligible stake))

Square‑root voting reduces the marginal power of very large positions. The depth‑unlock ladder limits how much stake can contribute at each point in time. Steps are percentages of a reference stake and mature according to elapsed time from governance creation.

6.2 Staking and exit

Liquid holders may stake through an ICRC‑2 allowance. Governance transfers tokens into custody and creates or tops up the caller's neuron.

An unstake request immediately subtracts the queued amount from voting power. Only one queue may be active per neuron. After a three‑day cooldown, daily maintenance transfers matured tokens to the owner's default ledger account. This prevents voting with stake already committed to exit.

6.3 Delegation

Neuron holders may delegate voting power when delegation is enabled through governance parameters. It is disabled by default. The implementation tracks the delegate and reverse‑delegator relationships and includes effective delegated power when a vote is cast.

6.4 Motion lifecycle

Every new motion uses the DAO's canonical timelock, defaulting to twenty‑four hours. A motion containing multiple proposals adopts the strictest required quorum. Ledger‑oriented external calls are escalated to the arbitrary‑upgrade quorum and bond tier.

A caller may change a vote while the motion is active; the previous voting power is removed first.

6.5 Proposal actions

Implemented variants include:

• one‑time and recurring treasury spending;
• arbitrary external canister calls;
• governance‑controller additions and removals, without removing governance itself;
• governance parameter and CEO state changes;
• governance‑token minting;
• secondary capital raises.

BondIssuance exists in the public type system but is blocked at execution. reserved, not live It is reserved functionality, not a live financial product.

6.6 Default quorum

Quorum is measured against total voting power and expressed in basis points. Parameters can change through state‑change motions; batches use the highest applicable quorum.

6.7 Motion bonds

Motion submission requires an ICP bond unless an implemented exemption applies. Defaults scale with treasury value and have absolute minimums:

For a batch, the maximum requirement applies. The proposer pre‑funds a principal‑derived governance subaccount with the bond and ledger fee. Bonds are an anti‑spam and accountability mechanism, not a voter‑reward system.

7.1 Primary settlement

The public launch takes a two‑percent protocol fee from capital raised and routes the remaining amount, less ledger fees, to the governance treasury. Settlement uses the configured quote ledger, defaulting to ICP in the public path.

7.2 Treasury proposals

Governance may authorize one‑time or recurring transfers using the treasury token, governance token, or another ICRC ledger. Recurring schedules survive upgrades and are processed by daily maintenance.

7.3 Secondary raises

An active DAO may begin a follow‑on raise only through execution of a passed RaiseCapital proposal by its governance canister. The backend compares a deterministic algorithmic price with a manipulation‑resistant thirty‑day orderbook VWAP:

secondary share price = max(algorithmic step-up price, eligible 30-day VWAP)

If no qualifying VWAP can be determined, the algorithmic price applies. Eligibility excludes self‑trades, requires positive quantity, and requires sufficient activity and distinct counterparties.

The first seven days are reserved for existing investors and use the implemented early‑access allocation treatment. On‑target raises settle automatically. An undersubscribed raise waits for the founder to accept or decline. Declining refunds that raise's investors and returns the DAO to Active.

Secondary settlement applies the same two‑percent protocol fee and mints computed allocations through governance using a durable settlement identifier.

8.1 Authorization boundaries

• Anonymous callers are rejected from authenticated operations.
• Founder actions compare the caller with recorded founder metadata.
• Governance‑only backend actions validate the caller against the DAO registry.
• SEO publication accepts only the configured backend canister.
• App‑canister changes require existing management authority.

8.2 Concurrency and replay protection

IC updates may interleave whenever they await another canister. DaoDex uses transient reservations around ticker creation, app claims, DAO setup, and financial operations. Stable journals protect transfers, transfer‑from calls, settlement, and orderbook mint blocks from duplicate execution after retries or upgrades.

8.3 Stable‑memory compatibility

Persistent maps and cells use fixed memory IDs that must not be reordered or reused. New fields use optional/default‑compatible encodings where necessary, and legacy DAO representations remain decodable across schema evolution.

8.4 Controller topology

Successful setup makes governance the sole controller of linked application canisters (§2.4). Governance itself becomes self‑controlled on mainnet.

8.5 Residual risks

The implementation contains two platform revenue mechanisms:

Ledger transfer fees are execution costs rather than DaoDex revenue.

The protocol does not encode guaranteed yield, liquidity, or appreciation. Market prices arise from funded orders. Governance outcomes arise from eligible voting power, quorum, and execution rules. Treasury performance depends on each DAO's operations and decisions.

The frontend exposes discovery, fundraising, wallets, governance, forums, trading, and portfolio views. Internet Identity provides authentication, with a shared derivation origin allowing the frontend and dashboard to represent the same principal when configured correctly.

Certified SEO pages make DAO metadata available to crawlers without moving business logic to an off‑chain server. Unknown routes fall back to the rendered frontend index so client‑side routing remains functional.

Public APIs expose DAO records, motions, neurons, governance statistics, tokenomics, market data, depth, trades, and forum content.

The following are not complete protocol guarantees today.

Near‑term work should prioritize auditability: reconcile docs with exported Candid, add end‑to‑end upgrade and failure tests, expose controller and treasury proofs in the UI, formalize governance‑upgrade approval, and publish deployment‑specific risks.

DaoDex implements a vertically integrated DAO capital stack on the Internet Computer. Its distinguishing feature is the binding between capital formation and an operational governance system: a raise provisions isolated infrastructure, assigns governance stake, transfers application control, funds a treasury, opens public deliberation, and creates a path from governed stake to liquid spot trading.

Its strongest properties come from explicit on‑chain boundaries — dedicated canisters, stable state, funded orders, governance‑controlled treasuries, controller handoff, durable settlement, and transparent motion parameters. Its remaining risks are equally important: governance is not automatically legal ownership, identities do not eliminate Sybil behavior, external calls and upgrades remain powerful, and contract correctness needs independent validation.

DaoDex should therefore be understood as programmable institutional infrastructure: a system for making DAO formation and capital operations more structured, inspectable, and governable, while leaving each DAO responsible for the real‑world value, conduct, and legitimacy behind its token.

This whitepaper was prepared from the current Rust implementation, shared Candid types, checked‑in interfaces, API references, and architecture decisions. Where older planning text conflicts with executable behavior, the current implementation is treated as authoritative and the divergence is disclosed above. Deployment operators should verify the exact commit, generated Candid interfaces, controllers, environment variables, and installed module hashes for any live deployment.