The 13 proposal types

How types work

The composer at /dao/<web address>/propose groups the types the way people look for them. Each type has one or more builders: forms that compose the exact calls a proposal makes, its actions. A proposal can combine several actions of the same type, up to 32.

When a proposal is submitted, the DAO's policy contract checks every action against the type's rules and refuses anything outside them, so a mislabelled proposal never reaches a vote. The same check decides whether the proposal uses the standard or the critical rules. New DAOs start from the default rules of PolicyBuilder; a Governance rules proposal can change them, within limits described under Changing the call policy.

A DAO can mark more types critical, and where it makes Treasury spend critical, every action that can give up treasury value is critical in every type. Governance rules and presets lists everything that makes a proposal critical.

Signal

"A text-only decision. Nothing executes; the result is the record." A Signal carries no actions: the policy refuses one that has any. It always uses the standard rules, has no timelock, and once passed it is the DAO's recorded decision. Builder: Signal, "Use a signal to record a position, adopt a guideline or ask members a question."

Examples: adopt a data-sharing guideline for the next grant round; ask members whether the DAO should apply for an instrument grant.

Treasury spend

"Send L1, tokens or NFTs from the treasury, or fund a member airdrop." Standard in a new DAO.

It may send L1, ERC-20 tokens (tokens the DAO launched and LP tokens included), ERC-721 NFTs and ERC-1155 items; fund a member airdrop in L1 or tokens; and wrap L1 into wL1 and back. It may approve tokens only to the member airdrop contract, and revoke approvals, collection-wide ones on NFTs of no type included. GL1F Model NFTs move with Models proposals, and sealed data with Sealed data proposals.

Builders: Send L1 or tokens, Send an NFT, Member airdrop and Wrap or unwrap L1.

Examples: pay 500 L1 to a sequencing lab and 100 L1 to its data curator in one proposal, each payment its own action; fund an airdrop of 10,000 of the DAO's tokens to members in proportion to their shares.

A DAO can make Treasury spend critical. Then paying anything out needs the stricter vote, and COLLAB holds every other type to the same standard; see The treasury. Airdrops are on Issue and manage tokens.

Governance rules

"Change quorum, thresholds, periods, deposits, the holding period and what each proposal type may do." Always critical.

It may change deposits, periods, quorum, thresholds, the minimum Yes and the holding period; change the call policy (its rules, the contracts approvals may go to, and which types are critical); grant or revoke treasury module permissions; turn share transfers on or off; exclude infrastructure accounts from voting; and add or remove the DAO's GL1F collections and CIPNFT contracts. On a CIPNFT contract it adds, it may also accept the terms and register the DAO's keys, and it may activate a key epoch, so one proposal can unlist a contract that no longer answers and rotate the key.

Builders: Deposit and voting rules, Call policy, Module permissions, Share transferability, Holding period, Excluded accounts and Integrations.

Examples: raise the minimum deposit to 25 L1 and the standard quorum to 40%; add a GL1F collection the DAO built itself as an integration.

Governance rules and presets describes the rules builders, Members and shares transferability, the holding period and exclusions, The treasury module permissions, and Integrations the integrations.

Constitution

"Publish a new version of the constitution. Every version stays on-chain." Always critical. Builder: Amend the constitution, which edits the current text and publishes it as the next version.

Examples: add an article on authorship and data release; adopt a conflict-of-interest rule. The constitution and announcements explains versions and amendments.

Representatives and profile

The picker calls it Representatives & profile: "Appoint or replace representatives and edit the DAO's description, logo and links. Its name is permanent." Standard, but appointing a representative with the operator power makes the proposal critical.

It may set the list of representatives, remove one, replace the description, the logo or the links, and post an announcement. It cannot rename the DAO or change its web address: both are fixed at creation, and the composer says under the builders that the name is permanent.

Builders: Representatives, Remove a representative, Replace the description, Replace the logo, Edit links and Post an announcement.

Examples: appoint two representatives who may edit the description and post announcements until the end of the year; replace the logo with the new 128 × 128 PNG.

A logo or description changed by proposal enters the chain's history three times; a representative with the permission can make the same change directly, with one copy. See Name, web address, logo and description, Representatives and Announcements.

Membership

"Freeze or unfreeze a member, issue new shares, give out treasury shares or burn them." Always critical.

It may freeze or unfreeze accounts, issue new shares, give shares the treasury holds to members, and burn shares the treasury holds. Members' own shares cannot be burned. A proposal that freezes someone records its targets at submission; where the DAO turned them on, the freeze lock and the freeze bond apply.

Builders: Freeze a member, Unfreeze a member, Issue new shares, Distribute treasury shares and Burn treasury shares.

Examples: issue 50 shares to a lab that joins the consortium; freeze an account that broke the DAO's data-use agreement. Members and shares covers freezes, the lock, the bond and dilution.

Issue a token

"Create a new ERC-20 and split it between treasury, people, members and pools." Standard in a new DAO; where Treasury spend is critical, a launch is critical too, because it sets its own prices and allocations.

It may launch a token through the token launcher, sending L1 for pools paired with L1, wrap L1, and approve tokens only to the launcher. Builder: Launch a token, which splits the whole supply between the treasury, named recipients, an airdrop to members and one-sided or two-sided DeSciFi pools in one step.

Example: launch 1,000,000 research credits, half to the treasury, a fifth as an airdrop to members and the rest in a one-sided launch pool. Issue and manage tokens explains launches.

Manage a token

"Mint, pause or retire capabilities of a token this DAO issued." Standard in a new DAO.

On tokens the DAO owns, it may mint, pause and unpause, give up minting or pausing, change the logo, hand over or give up ownership, and burn tokens the treasury holds. Handing over or giving up a token another DAO launched and handed over is critical. Where Treasury spend is critical, so are minting to anyone but the treasury, burning the treasury's tokens, and giving up a token's minting or ownership; giving up pausing stays standard.

Builders: Mint, Pause transfers, Unpause transfers, Give up a capability, Change the logo, Transfer ownership, Give up ownership and Burn from the treasury.

Examples: mint 100,000 tokens to the treasury for the next grant round; hand a token's ownership to a partner DAO. See Issue and manage tokens.

DeSciFi liquidity

"Add or remove liquidity, swap treasury assets, lock LP and collect fees." Standard in a new DAO.

On DeSciFi pools and lock boxes it may add and remove liquidity with tokens or L1, swap treasury assets, create pools and one-sided launch pools, lock LP tokens, extend locks, withdraw unlocked LP, hand over a lock and collect fees. It may wrap and unwrap L1, and approve tokens only to the DeSciFi router, factory and lock factory. Where Treasury spend is critical, swaps, deposits into pools and launch pools are critical, and so are locks that open more than ten years after submission or never, and locks owned by or paying anyone but the treasury.

Builders: Add liquidity, Remove liquidity, Swap, Lock LP tokens, Collect LP fees, Extend a lock and Withdraw from a lock.

Examples: add 5,000 L1 and 250,000 of the DAO's tokens to their pool; lock the treasury's LP tokens until a date, with the fees still paid to the treasury. See Pools, liquidity and locks.

Sealed data (CIPNFT)

"Buy, mint, sell or reveal encrypted IP-NFTs and manage key stewards." Standard, but critical for calls that set the DAO's keys, expose data or cannot be undone.

On the DAO's CIPNFT contracts it may accept the terms, mint sealed assets, make and cancel offers, list assets, revoke deliveries, refund expired offers and rename; in the key vault it may close reveals and approve and cancel purchases. Under the critical rules it may register the DAO's encryption keys, complete offers and deliver assets directly rather than through the key vault, set view keys, re-seal the owner's data key, and burn or erase on CIPNFT; and in the key vault appoint stewards, activate a key epoch, and open reveals and declassifications.

Builders: Buy a CIPNFT, Mint sealed data from a file, Sell or unlist an asset, Reveal an asset to members, Make an asset public, Activate a DAO key, Move an asset to the active DAO key, Elect key stewards, Close a reveal, Cancel a purchase approval, Withdraw the DAO's offer and Accept CIPNFT terms.

Examples: buy a sealed dataset for up to 200 L1; reveal a cohort's data to members who hold at least 10 shares. Sealed data with CIPNFT explains stewards, keys, reveals and what cannot be undone.

Models (GL1F)

"Price inference, sell access plans and manage GL1F Model NFTs the DAO owns." Standard, but critical to burn and delete a model, change its licence or how its internals are shown.

On the DAO's GL1F collections it may turn inference on or off and make it free, tip-based or paid with a fee recipient; create and edit access plans, buy access, and give or revoke API keys; send Model NFTs; and list them on a collection's market, cancel listings and buy models, with approvals only to the DAO's GL1F markets. Where Treasury spend is critical, pricing, access plans, owner access keys, listings, sending a model away and paying with treasury L1 are critical too.

Builders: Price inference, Access plans, API keys, List for sale, Cancel a listing, Buy a model, Send a model, Burn and delete, Change the licence and Internals visibility.

Examples: charge 0.5 L1 per on-chain inference of the DAO's peptide model, paid to the treasury; give every member a free API key for a paid model. See Models with GL1F.

DAO signature

"Approve a message hash so the DAO's ERC-1271 signature validates it." Always critical.

It may approve one 32-byte hash until an expiry time, or revoke the approval. Builders: Sign a message or hash and Revoke a signature.

Examples: approve the hash of an agreement so a partner's contract accepts it as signed by the DAO until the end of June; revoke that approval early. Approving a hash is like signing what it commits to; see The treasury.

Raw transaction

"Any calls, executed by the DAO like a multisig once the vote passes." Always critical, and it can neither be restricted nor switched off.

It may call any contract with any data and any amount of L1. Builders: Call a contract function, which builds the calldata from a function signature and your arguments; Raw calldata, for calldata produced elsewhere; and Import actions (JSON), for a list of {target, value, data} objects such as the raw actions of another proposal.

Examples: register the DAO with a partner's contract that COLLAB does not know; cancel a listing on the market of a GL1F collection the DAO has removed, which no other type reaches. The review decodes what it can and always shows the raw call data. See The treasury.

Rules across types

• A proposal has at most 32 actions. They execute in order, all or nothing.
• Raw transactions may call anything. For every other type:
  • a plain L1 payment, with no function call, is allowed only in Treasury spend;
  • L1 can be attached to a call only where the call needs it: funding an airdrop, wrapping L1, launching a token, adding L1 liquidity, swapping from L1, minting or making an offer on CIPNFT, and buying access, listing or buying on GL1F;
  • token approvals can only name the protocol contract the type works with, and for Models proposals the market of each GL1F collection the DAO uses, so a proposal cannot quietly let an outside address spend the treasury's tokens. Taking an approval back names no one, so any type whose rules reach a token can revoke its approvals, also after an integration was removed;
  • any action that calls the DAO's governor, treasury, policy or share token makes the proposal critical.
• Where Treasury spend is critical, every action that can give up treasury value is critical in every type.

Contracts that belong to a type

Some contracts belong to one type: the DAO's profile to Representatives and profile; its CIPNFT contracts and its key vault to Sealed data; the registry, Model NFT contract, market and runtime of each of its GL1F collections to Models; the tokens it launched to Manage a token; DeSciFi pools and lock boxes to DeSciFi liquidity. A GL1F collection or CIPNFT contract the DAO has not added, or has removed, belongs to no type. Plain transfers and approvals of launched tokens and of LP tokens still count as treasury business.

• Many rules name any contract rather than one address, such as a Treasury spend's token transfers or a Manage a token proposal's minting. Such a rule reaches contracts of the proposal's own type. Contracts that belong to no type are reached only by the general rules of Treasury spend, Issue a token and Manage a token, and by approvals, which always name an approved spender. So a DeSciFi liquidity proposal acts only on real DeSciFi pools and lock boxes, a Manage a token proposal cannot burn a sealed asset, and a Treasury spend cannot move a Model NFT.
• Reaching another type's contract needs a rule written for that contract, and the action is then as critical as that type makes it: critical if that type is critical, or if the call is critical there.
• Handing over or giving up ownership of a contract that belongs to no type, such as a token another DAO launched and handed over, is critical whatever the proposal's type.
• Manage a token rules recognise functions by their signature, so they take effect only where the DAO may call them: on tokens it owns or, under the critical rules, on its own shares.

Changing the call policy

The Call policy builder of a Governance rules proposal has three modes:

• Call rule. Set a rule for one contract and function with Allow, Deny or Clear the rule, optionally with May send L1 with the call and Makes the proposal critical. A rule for a specific contract always wins over the general rules of the same type and function, even when it forbids the call; clearing it lets the general rules apply again. The default rules for GL1F and CIPNFT name a part of an integration rather than an address, such as every GL1F market the DAO uses, so they apply to each integration the DAO adds; a rule for one contract wins over them, and they win over a rule for any contract.
• Approved spender. Allow approvals or Stop allowing for a contract that a type's approvals may name.
• Critical types. Tick the types that always use the critical rules.

The policy can never give Signal proposals actions, never make the five always-critical types standard, and never restrict Raw transactions: those stay available, under the critical rules. Current call policy shows the policy as it stands, rebuilt from the policy contract's events and checked against its state.

Related

• Proposals and voting: the composer, the review and execution.
• Governance rules and presets: standard and critical rules.
• The treasury: treasury spends, signatures, modules and raw transactions.
• Integrations: the GL1F collections and CIPNFT contracts a DAO uses.
• Known limitations: leftover allowances, rules added later and other edges.