# The treasury The treasury is the DAO's own contract and its address: it holds the DAO's assets, owns the tokens the DAO issues, and is the only account the DAO's other contracts obey. This page is for members who want to know what a treasury can hold, how it spends, when spending needs the stricter vote, how the DAO signs messages and runs calls like a multisig, how anyone can fund it, and how to read the **Treasury** section of a DAO's page. ## What the treasury holds A treasury can hold anything an Ethereum-style account can hold on GenesisL1: - **L1**, the coin of GenesisL1; - **ERC-20 tokens**: wL1, tokens the DAO issued, tokens it received, and the LP tokens of DeSciFi pools it provides liquidity to; - **ERC-721 and ERC-1155 NFTs**, including the Model NFTs of GL1F collections; - **CIPNFT sealed assets**: encrypted data whose key the DAO holds through its key stewards (see [Sealed data with CIPNFT](sealed-data.md)); - **its own shares**, which never vote and never count towards quorum. It also owns things that are not balances: the ERC-20 tokens the DAO launched (the treasury is their owner, so minting and pausing happen only by proposal) and the DeSciFi lock boxes it owns. Some assets move only through the proposal type built for them. CIPNFT assets cannot be sent like other NFTs: ownership moves only through offers, which re-encrypt the data key, so they use a **Sealed data (CIPNFT)** proposal. Model NFTs of the collections the DAO uses move by a **Models (GL1F)** proposal. An NFT of a GL1F collection or CIPNFT contract the DAO does not use as an integration carries the badge **Not an integration of this DAO**, and treasury rules apply to it. ## How the treasury spends Only a passed proposal moves what the treasury holds. The treasury's `executeBatch` accepts calls only from the DAO's governor, and the governor executes only: - the exact actions whose hash it stored when the proposal was submitted, - after the vote passed and the timelock ended, - within the execution window, - and only once. All actions of a proposal succeed together, or the whole execution reverts and nothing changes. Anyone may execute a passed proposal once it is ready; see [Proposals and voting](proposals.md#execution). The one narrow exception, module permissions, is described [below](#module-permissions). A **Treasury spend** proposal has four actions: | Action | What it does | |---|---| | **Send L1 or tokens** | Pays one or more recipients in L1 or any ERC-20 token the treasury holds. Each payment is its own action, so the proposal lists them one by one, up to 32. **Paste a list of recipients** takes one recipient per line: address, amount. | | **Send an NFT** | Transfers an ERC-721 or ERC-1155 token the treasury holds with `safeTransferFrom`. GL1F Model NFTs and sealed data move by their own proposal types. | | **Member airdrop** | Funds an airdrop that members claim, pro rata to their shares or, where membership has always been fixed, equally. See [Member airdrops](tokens.md#member-airdrops). | | **Wrap or unwrap L1** | Converts treasury L1 into wL1, the ERC-20 form pools and protocols use, or back. One wL1 is always one L1. | The composer's **What changes** panel shows the treasury's balance before and after. When the total is more than the treasury holds, it says so: execution fails unless the treasury receives the difference first. The DAO's own shares cannot be paid out this way; they move with a Membership proposal (**Distribute treasury shares**, see [Members and shares](members.md#issuing-and-burning-shares)). Other proposal types spend in their own ways: **DeSciFi liquidity** proposals swap and provide liquidity ([Pools, liquidity and locks](liquidity.md)), **Issue a token** seeds pools ([Issue and manage tokens](tokens.md)), **Models (GL1F)** and **Sealed data (CIPNFT)** proposals buy and sell, and a **Raw transaction** can do anything ([below](#the-dao-as-a-multisig)). The [13 proposal types](proposal-types.md) lists them all.  ## When treasury spends are critical Each DAO decides which proposal types use the critical voting rules; see [What makes a proposal critical](governance-rules.md#what-makes-a-proposal-critical). When **Treasury spend** is one of them (the Conservative preset makes it so), paying anything out needs the stricter vote, and COLLAB holds every other proposal type to the same standard: any action that can give up treasury value is critical too, whatever the proposal's type. That is an action that: - carries L1, wrapping it into wL1 included; - grants an allowance of anything but LP tokens, or approves an operator for the treasury's NFTs; on a Model NFT contract the DAO uses, every approval counts, token 0 included; - trades or sells at a price the proposal sets: swaps, adding liquidity, launch pools and token launches, listings on a GL1F market the DAO uses, opening a listing on a CIPNFT contract it uses, and deliveries and purchase completions made there directly rather than through the key vault's checked steps; - sets what a model's use costs or who may use it, on a GL1F registry the DAO uses, whoever is paid: inference pricing and revenue, access plans and permanent owner access keys; - sends tokens, NFTs, LP tokens, fees, a lock box, a token's ownership or newly minted tokens to anyone but the treasury, the burn address included; - locks LP tokens for good: a lock box, new or extended, that never opens or opens more than ten years after the proposal was submitted; - gives up what a token is worth or can do: burns tokens the treasury holds, or gives up a token's ownership or its minting. These stay standard: removing liquidity and collecting fees to the treasury; lock boxes that the treasury owns, that pay it and that open within ten years; approving LP tokens and setting an allowance back to zero; unwrapping wL1; closing a listing; profile edits; and pausing the DAO's own token, giving up its pausing or changing its logo. The call policy reads each recipient and each unlock date at its exact place in the call, and a call too short to hold one counts against the treasury. The ten years count from the proposal's submission, not from its execution. This protection covers the calls of COLLAB's default rules, on COLLAB's own contracts and on the GL1F collections and CIPNFT contracts the DAO lists as [integrations](integrations.md). A rule that a Governance rules proposal adds later, for another contract or function that can move value, is standard unless the rule itself is marked **Makes the proposal critical**. Mark such rules critical. To work with another GL1F collection or CIPNFT contract, add it as an integration instead, and its calls are covered too. In a DAO whose treasury spends are standard, none of this changes anything: a standard vote can already spend. ## The DAO as a multisig A **Raw transaction** proposal can call any contract with any data and any amount of L1. Think of it as a multisig whose signatures are the members' votes: once it passes and its timelock ends, anyone can execute it, and the calls run from the treasury's address. Use it for what the other types do not cover, such as working with a contract COLLAB does not know. - Raw transactions always use the critical rules, in every DAO, and they cannot be switched off. - A proposal holds at most 32 actions. They run in order, and if any call fails, none of them take effect; the proposal can then be executed again while its execution window lasts. - The composer builds actions three ways: **Call a contract function** (type the function signature and its arguments), **Raw calldata** (paste calldata produced elsewhere, such as a Safe, a dapp or a script) and **Import actions (JSON)** (a list of `{target, value, data}` objects, values in wei as strings). - The review decodes what it can and always shows the raw call. When it cannot decode a call, it says: "This call could not be decoded. Read the raw calldata before voting." - Handing over or giving up a contract outside COLLAB with `transferOwnership` or `renounceOwnership` uses the critical rules in every proposal type, whatever the call policy says. - A raw transaction that freezes a member is not a freeze proposal: it places no lock and carries no bond (see [Freeze locks](members.md#freeze-locks)). - A token allowance left behind by one proposal could be used by a later proposal of a type that may call the same spender. Proposals built with COLLAB's own forms reset the allowances they grant to zero in the same proposal; set them back to zero in raw transactions too. ## DAO signatures (ERC-1271) A contract has no private key, so it cannot sign a message the usual way. The ERC-1271 standard lets a contract approve signatures instead, and many protocols accept it for permits, orders and attestations. A **DAO signature** proposal approves one 32-byte hash until an expiry. Once it is executed, the treasury's `isValidSignature` accepts that hash as signed by the DAO until the expiry, whatever signature bytes are presented with it. DAO signature proposals always use the critical rules. - **Sign a message or hash** takes what to sign in one of three forms: **Raw hash**, **Message (EIP-191)**, the way a wallet's personal_sign hashes text, or **Typed data (EIP-712)**, the JSON a dapp would pass to `eth_signTypedData_v4`. Then **Signature valid until** sets the expiry. - The review shows what the hash commits to and warns about invisible or direction-changing characters, a typed-data domain without a chain ID or for another chain, and data that looks like a token permit, which would let a spender move the DAO's tokens without another vote. COLLAB cannot tell what a raw hash commits to: approve one only if members can recompute it from the original order, message or transaction. - The approval starts when the proposal executes, and an expiry that has passed by then makes the execution fail. The composer refuses an expiry before the earliest possible execution and warns when it falls before the latest one. - **Revoke a signature** withdraws an approval before it expires. From that execution on, `isValidSignature` rejects the hash; anything already done with the signature stays done. Approving a hash is like signing the message behind it. Check what it commits to before you vote. ## Module permissions Some jobs need a quick, narrow action without a full vote each time. Governance can give a helper contract, a module, permission to make the treasury call one function on one contract, without L1. - A permission names the contract and the function, never the arguments: the module may call it with any arguments, whenever it likes. A permission for a token's `transfer` lets the module send any amount of that token to anyone. - No module can ever call the treasury, the governor, or the DAO's policy, shares, profile or key vault. The treasury refuses such a permission, and refuses such a call. - Granting or revoking a permission is the **Module permissions** action of a **Governance rules** proposal (**Grant** or **Revoke**), which always uses the critical rules. COLLAB uses two modules of its own: - **The DAO key vault.** Every new DAO grants its key vault two calls on each CIPNFT contract it uses: completing a purchase that a proposal approved, once a key steward has checked the delivery, and delivering sold data to a buyer who escrowed the full listing price. Adding a CIPNFT contract later grants the same two. See [Sealed data with CIPNFT](sealed-data.md). - **The DAO profile.** Representatives with the operator permission use the calls governance granted to the profile; see [Representatives](representatives.md#what-representatives-can-do). A permission is powerful: grant only a call you would approve every single time, with any arguments. ## Funding the treasury Anyone can send L1 or tokens to a DAO's treasury. Use **Fund the treasury** in the DAO's header, or **Send** under **What you can do** in the Treasury section. The dialog **Fund the treasury** asks for the **Asset** (L1 or a token in your wallet) and the **Amount**, then sends it from your wallet. - It is a donation: not a proposal deposit, and only a passed proposal can move it again. - Before the transaction goes out, COLLAB reads the DAO's addresses again through your wallet's own network and sends nothing if they differ from what the page shows. - The treasury also accepts ERC-721 and ERC-1155 tokens sent to it with a safe transfer from your wallet. A holder can give a Model NFT to the DAO from its Models section; see [Donating a model](models.md#donating-a-model). - A plain L1 transfer leaves no event on chain, so it shows in the treasury's balance but not in **Recent flows**. ## Reading the Treasury section The Treasury section of a DAO is at `/dao//treasury`. Under its heading, **Propose a payment** opens a Treasury spend, and **On this page** links to **Holdings**, **Recent flows**, **Member airdrops**, **Module permissions**, **DAO signatures** and **Executed proposals**. When your wallet can claim a member airdrop, a bar at the top says "You can claim …" with the claim button. - **Total value.** What the treasury holds, valued in your display currency, with how many holdings could be valued and a figure of how the value is spread. L1 counts at face value. Tokens and liquidity count at DeSciFi pool mid prices in L1, each holding at most the L1 in the pool that prices it, so a thin pool cannot inflate the total. Assets without a price are named below the figure, under "Not included, for lack of a price". - **What you can do.** **Send tokens or NFTs to the treasury**, **Share with every member** (a member airdrop proposal) and **Put assets to work** (the Liquidity section), with the treasury's address and the rule that it moves assets "Only when a passed proposal is executed, after its timelock". - **Holdings.** Balances read live from the chain, grouped as **Coins and tokens**, **Liquidity**, **NFTs, sealed data and models**, and **Lock boxes of other owners that pay fees to the treasury**, with the columns **Asset**, **Holding**, **Price**, **Value** and **Share**. Each row offers the proposal that fits it, such as **Propose a payment**, **Propose collecting fees**, **Propose selling it** or **Propose sending it**. The list is found from transfers to the treasury since the DAO's creation, the GL1F collections and CIPNFT contracts the DAO uses, the tokens it issued, wL1 and the tokens you track. - **Recent flows.** Value in and out, with **When**, **Flow**, **Amount**, **Counterparty** and **Cause**: payments by proposal, donations in tokens, fee collections, airdrops, forfeited deposits and module calls. - **Member airdrops.** Every airdrop for the DAO's members, with claims; see [Member airdrops](tokens.md#member-airdrops). - **Module permissions** and **DAO signatures**, each with what is active now, read live from the contracts, and a link to propose a change or a revocation. - **What the treasury executed.** Passed proposals, module calls and signatures, newest first.  ## Related - [Proposals and voting](proposals.md) - [The 13 proposal types](proposal-types.md) - [Members and shares](members.md) - [Issue and manage tokens](tokens.md) - [Pools, liquidity and locks](liquidity.md) - [Integrations](integrations.md) - [Known limitations](limits.md)