Security at a glance

What the contracts guarantee

Nobody owns a DAO.

• Each DAO is six minimal clones of fixed contracts, created and set up in one transaction by the COLLAB factory, so there is no moment when a half-built DAO could be taken over.
• None of COLLAB's own contracts, the six of each DAO and the shared ones, has an owner, an admin key, an upgrade path or a pause switch held by anyone outside the DAO. The factory has no admin either.
• A DAO's rules, call policy, profile, constitution, membership, key vault and the tokens it issued change only when its treasury calls them, that is, by passed proposals. Representatives act only within the permissions governance gave them.

Only passed proposals move the treasury. The treasury accepts calls only from the DAO's governor, and the governor runs only the exact actions whose hash it stored at submission, after the vote passed and the timelock ended, within the execution window, and only once. All actions of a proposal succeed or none do. The one exception is a module permission, which only a critical vote can grant and which reaches one function on one contract, never with L1 and never on the DAO's own core contracts. See The treasury.

Proposals do what they say.

• Each proposal type may call only what the DAO's call policy allows for it, and a mislabelled proposal is refused when it is submitted. Calls on the DAO's own governor, policy or shares, raw transactions and DAO signatures always use the critical rules, and the critical rules are never laxer than the standard ones.
• Where a DAO makes treasury spends critical, any action that can give up treasury value is critical too, whatever its type; see When treasury spends are critical.
• The interface reads a proposal's actions from the chain, checks them against the stored hash, describes every one in plain language beside the raw call, lists every recipient and every rule, and can simulate the execution.

Votes cannot be bought late. Voting power is read at the block before a proposal was submitted and, with a holding period, a second time earlier; the lower reading counts. Shares bought, borrowed or delegated after a proposal exists, or within the holding period before it, add nothing. Each proposal keeps the rules it was submitted under. See Proposals and voting.

Members are protected from each other, within limits. Freezing a member is always a critical vote; with freeze locks, a member facing a freeze vote cannot move shares away while it runs, and with the freeze bond, a failed freeze vote costs its backers their deposit. Excluded accounts, such as pools, hold no votes. See Members and shares.

What you read is what is on chain. Constitutions, announcements and proposal descriptions are stored on GenesisL1 and addressed by their hash; a DAO's logo and description live in its profile with their hash. The interface shows each only when the bytes match the hash. Names, titles and symbols are checked text, and one malformed string cannot break a page.

Names and addresses are permanent. A DAO's title and web address never change, and no two DAOs share a web address, so a link by web address leads to the same DAO on every copy of the site.

DeSciFi keeps fees apart. Swap fees stay out of the reserves, so they cannot be skimmed or used to move the price; pools can only be created for tokens that already exist; each LP holder collects only its own fees.

Sealed purchases complete only against the delivery a key steward checked, and one steward cannot overwrite another's current key copies.

What you still trust

• GenesisL1 itself: its validators, finality and EVM.
• Your DAO's members. A majority that meets the quorum and thresholds can do anything the DAO can do, including moving the whole treasury with a raw transaction. The timelock is warning time, not a veto. Choose the rules with that in mind; see Governance rules and presets.
• The outside contracts your DAO uses. The GL1F collections and CIPNFT contracts a DAO lists have administrators of their own, who can change fees and terms, cancel listings, and on the original GL1F delete a model. The DAO's Settings show who holds each key today; see Outside admin keys. wL1 is the chain's own contract, which COLLAB uses but does not control.
• Key stewards. They can read every sealed asset the DAO holds, at any time; see Sealed data with CIPNFT.
• Your RPC endpoint, for what pages display. An endpoint could show false data, but it cannot sign for you, and COLLAB does not take its word where it matters: before a transaction goes to a DAO or pays its treasury, the DAO's addresses are read again through your wallet's own network, and so are the keys data is sealed to. Use an endpoint you trust; see RPC endpoints.
• Your wallet, which shows what you actually sign.
• The website you load and its operator. The operator of a site publishes its code and the contract addresses its pages use, and chooses its default endpoints, which DAOs it features or hides and which tokens it verifies. The site loads no third-party code; it talks only to its RPC endpoints, to a price service for display (CoinGecko by default, never used for amounts you sign) and, only if the site turns on analytics and you accept, to Google. To be sure of the code, host the release yourself or compare the files you are served with the release's SHA256SUMS. Anyone can check that a site points at genuine contracts of its release on its /admin/check page, which only reads the chain and needs no sign-in; since the page comes from that site, run it from a copy you host yourself for full assurance.

How COLLAB was checked

Every review was AI-assisted and done apart from the implementation work. None was an external audit.

• Release 1.0. A review of the contracts found 12 issues (2 High, 8 Medium, 2 Low), each reproduced with a proof-of-concept test, and a 13th (Medium) turned up while the documentation was checked against the fixed code. All are fixed and tested. The interface had its own review.

• Release 2.0 rebuilt the contracts on audited libraries (OpenZeppelin Contracts 5.1 and Solady's SSTORE2), added invariant tests for every token and share rule, and had two more reviews of token and share management, a verification of their fixes and an interface review.

• Release 2.1 answered an outside review of the published 2.0.0 archive, which read the source and documentation but could not run the tests and was not an audit; its nine items are resolved. The 2.1 changes then had a review of their own (no High findings), a verification of its fixes and an interface review.

• Release 2.2. Two weaknesses found while building it were fixed first (H22-1, H22-2). Then each part had its own review, followed by a check of the fixes:

  • the contract changes: no High or Medium findings, and the reviewed contracts are the released ones (RV22-1 to RV22-8);
  • the server kit: three Medium and three Low findings, each needing an attacker who had already taken over a service account or a session cookie; all fixed with a test each (SV22-1 to SV22-6);
  • the website and static pages: no way for anything stored on chain to run as script in the site; two Medium, one Low and two Info findings, all fixed (WB22-1 to WB22-5).

  A rehearsal of the operator's whole path, from the archive through the installer, the admin page, the deploy and publishing to using the site and upgrading, passed in a sandbox.

Tests. The contracts have a Foundry suite of unit, fuzz, invariant and proof-of-concept tests: 331 tests in 92 suites in this release, all passing; its 25 invariant tests also run in deeper campaigns (FOUNDRY_PROFILE=ci). Every proposal type runs end to end against compiled copies of the live CIPNFT, GL1F and GL1F Crypto contracts. Browser end-to-end tests drive the website with a test wallet against a local chain.

No external audit

An external audit is the step that is still missing. Until one is published, keep in a DAO only what you can afford to lose, prefer conservative settings, and read Known limitations before you rely on COLLAB for anything valuable. To report a security issue, see Reporting problems.

Related

• Security
• Known limitations
• Staying safe
• Integrations
• Release notes