AlphaCOLLAB runs on GenesisL1 mainnet and has had no external audit. Use small amounts.Security notes

COLLAB

Release notes

Part
Security and project
Version
COLLAB 2.2.0
Updated
Reading time
29 min
View as Markdown
Security and projectPages

Security and project

On this page

2.2.0 (2026-11-02, alpha)

COLLAB becomes a portal you install on your own server. One script sets up nginx, certificates and the redirects. An admin page then deploys the contracts from your wallet and publishes them to the site. DAOs get permanent web addresses and logos stored on chain, and DeSciFi becomes a market with a list of every token. A documentation section at /docs explains all of it, for members, operators and developers. This release is an alpha for GenesisL1 mainnet, tested in the real environment with real L1: it had AI-assisted internal reviews and no external audit.

Install on a server

  • server/install.sh (Debian and Ubuntu). Upload the archive to /var/www/html, extract it and run sudo ./collab-2.2.0/server/install.sh --email you@example.org (docs/INSTALL.md). It:
    • installs nginx, certbot and Python's packages;
    • creates the users collab and collab-prerender;
    • copies the release to /var/www/collab/releases/<version> and switches current atomically;
    • writes /etc/collab/collab.env once, with the admin token and secrets.
  • Domains. collab.genesisl1.com is the main host. dao.genesisl1.com, collab.descifi.org and dao.descifi.org answer 301 to the same path on it, and HTTP always redirects to HTTPS. --main and --alias choose other names.
  • Certificates. One Let's Encrypt certificate (webroot) covers every name whose DNS already points at the server. Names that don't are left out with a warning, and a later run adds them. Renewal reloads nginx.
  • Other sites stay as they are.
    • The installer refuses to run when another site claims one of the names, or when a port is held by another program.
    • It never edits the default site.
    • Every nginx change is followed by nginx -t, with a rollback if it fails.
  • Re-runs and upgrades. Re-running is safe. Running a newer release's installer upgrades the site, keeps the deployment and settings, and keeps the two previous releases. The same version installed again with other files replaces the installed copy without a gap, and the prerender writes its pages again.
  • Services. All run under systemd:
    • the admin service, hardened, on loopback behind nginx;
    • the prerender job: every 10 minutes and on request, as its own user, which can write only the pages and data it makes;
    • a root step that applies the CSP changes site settings need, with validation and rollback.
  • The collab helper: admin-token [--new], status, prerender [--request], logs.

The admin page

  • /admin signs in with the admin token:

    • an HttpOnly session cookie, valid for 12 hours, revoked on sign-out (even across restarts);
    • CSRF checks on every change;
    • a rate limit on sign-in attempts.

  • Deploy is 2.1's deploy page, moved here (/deploy redirects): every contract from your wallet, with each contract's code and wiring verified and resume after an interruption. Each creation stays far below the nodes' 25M gas estimate cap; the largest uses 4.6M.

  • Publish to this site writes config.js from the deployment record and starts a prerender, so the site switches from "not deployed yet" to the live protocol. Publishing can be undone. A record can also be pasted, uploaded or read from a factory address.

  • Check verifies any deployment against this release.

  • Site settings change what the site shows:

    • the alpha notice and an announcement;
    • featured and hidden DAOs, verified and hidden tokens;
    • search-engine texts, links and analytics;
    • RPC endpoints (each tested for chain 29) and the explorer.

    Each field is validated in the browser and on the server, with a preview.

  • Status shows the prerender (with Run now), certificates and their expiry, versions and disk.

The portal

  • Layout. A shell in the manner of gl1x.com, with genesisl1.com's look:
    • a sidebar with Discover, DeSciFi and Build, and a live network card (latest block, L1 price, deployment);
    • a top bar with a global search (DAOs by title, slug or address; tokens; proposals) and the currency, theme and wallet controls;
    • an ecosystem footer;
    • a drawer on phones.
  • Pages. A home hub, /daos, a new /votes with the open proposals of every DAO, and restyled settings, privacy, docs and 404 pages.
  • Alpha. A slim strip on every page, with text the operator can edit, and a badge by the wordmark. Its standard text: "COLLAB runs on GenesisL1 mainnet and has had no external audit. Use small amounts." The alpha is tested on mainnet, with real L1, not on a test network.
  • Cookie notice. A small card in a corner that never covers the page. The COLLAB mark is kept, with PNG icons added for phones and the web app manifest.
  • Undeployed mode. Before the contracts are published, every page loads and says COLLAB is not deployed here yet, with a link to /admin.
  • Search engines.
    • Static pages for every DAO (by slug) and every token.
    • A canonical address on the main host, Open Graph images, JSON-LD (WebSite with a search action, an Organization per DAO, breadcrumbs) and a sitemap with every DAO and token.
  • Speed.
    • Static shell markup, so nothing shifts as the page loads.
    • Module preloads.
    • Asset URLs versioned per release and cached for a year.
    • Files served precompressed.
  • Prices. The server fetches L1's price from CoinGecko at each prerender. Pages show US dollars from that snapshot, with its time. A visitor's browser contacts CoinGecko only after they pick another currency.

DAOs: permanent addresses, logos and descriptions on chain

  • Slugs. Every DAO has a permanent, unique web address chosen at creation: /dao/<slug>, with 3 to 48 characters of a-z, 0-9 and -, starting with a letter. Links by address keep working and turn into the slug address.

  • The title is permanent; the settings and builders say so where a rename used to be.

  • Logo. A 128 × 128 PNG of up to 512 KB, kept in the DAO profile's own storage. Any image you pick is cropped and scaled to 128 × 128 in the browser. The page shows its size against the limit.

  • Description. Markdown of up to 256 KB, stored the same way, with a live byte counter and preview.

  • Edits overwrite in place. Editing the logo or the description overwrites the stored bytes, so the chain's state never grows with edits. Pages read the bytes in 16 KB pieces and check them against the hash the chain reports. A static copy on the server, verified the same way, makes the first paint fast.

  • Wizard.

    • A slug field that proposes one from the title and checks it live.
    • The logo pipeline and the description editor.
    • A fee review: transactions too large for a wallet to estimate (the nodes cap estimates at 25M gas) get an explicit gas limit from measured figures. The review also says what a failure would cost (see RV22-1 below).
    • Constitution templates for a research collective, a lab consortium, an institute or university, company research and a non-profit foundation, or a blank page.

  • Typical costs at the 50 gwei base fee, as gas used (measured):

    • a DAO without logo or description: 5.43M gas (about 0.27 L1);
    • a DAO with a 64 KB logo and a 16 KB description: 63.9M gas (about 3.2 L1);
    • a representative rewriting a 64 KB logo: 11.5M gas (about 0.58 L1).

    Real logos of 128 × 128 pixels are usually 5 to 30 KB. The largest possible creation (512 KB plus 256 KB) uses about 570M gas and fits a GenesisL1 block. A failed transaction still pays at least half its gas limit (RV22-1).

DeSciFi and the tokens pages

  • A market of its own. DeSciFi has its own buy and sell colours and a trading desk with a price chart, a Buy/Sell ticket, a price-impact meter and slippage. Unverified tokens carry plain warnings with the full address. Pools, the pool page, adding liquidity and locks are restyled.

  • /tokens lists every token with a DeSciFi pool:

    • price in L1 and in the display currency;
    • 24-hour change and a 7-day line;
    • pool liquidity and market cap;
    • holders;
    • the DAO that issued it, linked by slug.

    It sorts, searches, and filters by verified and DAO-issued; hidden tokens are left out. A holder count is exact only when the counted balances add up to the total supply; otherwise it reads "≥ N".

  • /tokens/<address> shows a token's chart, pools, facts and issuing DAO, with Buy and Sell into the swap ticket.

  • The data. The prerender writes /data/tokens.json (tools/seo/tokens.py) with an incremental cache and a time budget per run. Pages paint from it, then refresh from the chain.

Documentation

  • /docs is a documentation section of 58 pages in nine parts, for three kinds of reader:
    • DAO members: how COLLAB works, a tour of the site, wallets and settings, creating a DAO and its identity, proposals and the 13 proposal types, governance rules, the constitution, the treasury, members and representatives, tokens, DeSciFi swaps, pools and locks, sealed data, models and integrations, then staying safe, costs, known limitations, questions and a glossary;
    • operators: what to prepare, the installer, the admin page, deploying and publishing from it, site settings, the prerender job, domains and certificates, upgrades and backups, monitoring, troubleshooting, hosting without the server kit and a security checklist;
    • developers: the architecture, local development, the contracts and governance internals, reading COLLAB from the chain, the web app, data formats, the Admin API, testing, building a release, gas and the contract API.
  • Each page has its own address (/docs/<page>), a contents list that follows your reading, the other pages of its part, and previous and next links. Figures show the real interface; drawings show a DAO's contracts, a proposal's life, the holding period and a worked ballot; the contracts guide lists this site's own contract addresses, read from its config.js.
  • Search. The docs home searches every page's title, headings and summary, and the top bar's search has a Docs group.
  • For other tools. Every page has a Markdown copy at /docs/<page>.md, and /llms.txt lists them all. Pages carry Open Graph and structured data, and the sitemap lists them.
  • Old links to sections of the former single docs page, such as /docs#lifecycle, forward to their new page.
  • In the archive the same pages are Markdown files in docs/, readable on GitHub. tools/build_docs.py builds the site's pages from them and checks every link, anchor and figure; the release build stops on any problem.
  • Checked against the code. Each guide was read against the code in a separate AI-assisted review, by a reviewer who had not written it.

Contracts

  • DAOProfile.
    • Title fixed at creation.
    • setLogo(bytes): a PNG whose signature, header fields and closing chunk are those of a 128 × 128 PNG, at most 524,288 bytes.
    • setDescription(bytes): well-formed UTF-8, at most 262,144 bytes.
    • Both stored in place, with logoInfo/logoChunk and descriptionInfo/descriptionChunk, and the events LogoChanged and DescriptionChanged.
    • Permission bit 1 (the title) is gone; ALL_PERMS is 62.
  • DAOFactory.
    • CreateParams takes slug, logo and description.
    • New views: daoBySlug, slugOf and slugAvailable; DAOCreated carries the slug.
    • VERSION is "COLLAB DAO v2.2.0".
  • DAOLens.
    • Summaries carry the slug and the logo's hash and length, and details the description's.
    • New getDAOBySlug and directory(offset, limit).
  • PolicyBuilder writes 115 default rules (no title rule).
  • Hardening found while building:
    • share names are capped at 80 bytes and symbols at 32 (H22-1);
    • MarketLens copies only what it decodes from token calls, so a page of hostile tokens can no longer exceed the 25M eth_call cap (H22-2).
  • Tests. forge test runs 331 tests in 92 suites. The 25 invariant tests of test/invariants/ are among them; FOUNDRY_PROFILE=ci runs them with deeper campaigns.

Reviews

Each part of 2.2 had its own review, AI-assisted and done apart from the implementation. Details are in docs/SECURITY.md.

  • The contract changes (RV22-1 to RV22-8): no High or Medium findings.

    • RV22-1 (Low). GenesisL1 charges every transaction at least half its gas limit, even when it fails (Ethermint's minimum gas multiplier). A creation that loses its slug to someone faster still pays half its limit. For the largest creation that is about 15.8 L1, while taking the slug costs about 0.27 L1.
      • The wizard and every large transaction now state that failure cost.
      • The wizard checks the slug again right before the wallet opens.
      • Execute re-reads the proposal's state just before sending.
      • A slug reservation that can't be front-run is future work.
    • The seven Info items are documented. The web's cleaning of invisible and bidi characters in permanent titles also gained the ranges the review found, and titles now render isolated (dir="auto").

  • The server kit (SV22-1 to SV22-6): three Medium and three Low findings. Each needed an attacker who had already taken over one of the kit's service accounts or a session cookie, and each would have broken the kit's separation between those accounts and root. All six are fixed, with a test each, and the fixes were verified twice.

  • The web and prerender changes (WB22-1 to WB22-5): no way for chain data to run as script.

    • WB22-1 (Medium). Three lopsided pools made of an attacker's own tokens could stop the prerender job from writing anything. The tokens step now uses integer math and caps absurd figures, and a failing tokens, network or price step is only a warning.
    • WB22-2 (Medium). A copycat DAO, with another DAO's title and logo under a different slug, could make a counterfeit token look vouched for. Now:
      • only tokens the operator verifies, or tokens of DAOs the operator features, count as vouched for;
      • every DAO is named by its slug wherever it vouches;
      • a DAO whose name matches another's, look-alike letters included, is flagged.
    • WB22-3 to WB22-5. A cache rule across upgrades, capped reads of /data files, and a few more invisible characters. All fixed and verified with the reviewer's original probes.

  • A rehearsal of the operator's whole path passed in a sandbox:

    • the archive in a /var/www/html folder;
    • the installer, and redirects for all four names;
    • /admin sign-in, a deploy of all 20 contracts from a test wallet, and publish;
    • a DAO created with a logo, and a token launched and traded;
    • site settings, and an upgrade.

    Its findings (a build-tool blocker, prerender warnings hidden from Status, the first prerender after publishing, hidden DAOs in one listing file, and phone sizes of the alpha strip and cookie notice) are fixed.

Interface changes

  • ABI:
    • DAOProfile: setTitle, PERM_TITLE, logo(), description(), logoMime(), TitleSet, LogoSet, DescriptionSet and InvalidMime are gone. New: setLogo(bytes), setDescription(bytes), logoInfo, logoChunk, descriptionInfo, descriptionChunk, LogoChanged, DescriptionChanged, InvalidPng, WrongLogoSize, ChunkTooLarge, LOGO_PIXELS, MAX_CHUNK_BYTES and MAX_ANNOUNCEMENT_BYTES.
    • DAOFactory: the new createDAO tuple, DAOCreated with the slug, daoBySlug, slugOf, slugAvailable, MIN_SLUG_BYTES/MAX_SLUG_BYTES, InvalidSlug and SlugTaken.
    • DAOLens: new summary and details tuples, getDAOBySlug and directory.
    • ShareToken: MAX_NAME_BYTES, MAX_SYMBOL_BYTES and InvalidMetadata.
    • The full API is in docs/CONTRACT_API.md; the ABIs are in abi/ and web/js/core/abi.js.
  • config.js:
    • gains deployed (false until a deployment is published) and site, the public part of the site settings;
    • tools/write_web_config.py remains the only writer, and the admin page's deploy writes the same bytes.
  • The deployment record is unchanged, apart from the version string.
  • New static data: /data/price.json, /data/tokens.json, /data/logos/<hash>.png and /data/texts/<hash>.txt. The formats are in web/DEVELOPING.md.
  • New addresses: /docs/<page> and its Markdown copy /docs/<page>.md, routed by the nginx templates, the Caddyfile, web/_headers and tools/serve_local.py.
  • robots.txt names the sitemap on the site's own address: the prerender job writes it on every run, and a static host writes it with tools/prerender.py --static-sitemap --site https://<host>.

Upgrading

Nothing was deployed on GenesisL1 mainnet, so 2.2.0 replaces 2.1.0 without a migration: install it on a server and deploy from /admin/deploy, or follow docs/DEPLOY.md.

An earlier build of 2.2.0, without the documentation section, was shared before this one. Its contracts are the same. To replace it, extract this archive into an empty folder and run its installer the same way: the installer finds the same version with other files and replaces the installed copy. Extracting over the older folder would keep files this archive no longer has.

Not done yet

  • No external audit. Start with small amounts and conservative settings.
  • The installer is untested on a live server. It was tested on Ubuntu 24.04 in a sandbox: real nginx on test ports, a self-signed certificate and a stand-in for certbot. A first run on a real server is the first with Let's Encrypt and systemd. Point the DNS of the names first, then run it.
  • Slugs can be front-run by someone watching pending transactions (RV22-1). A commit–reveal reservation, or a two-step creation that uploads the logo after the slug is taken, is planned.
  • Profile edits by proposal put the bytes into chain history three times (submission, event, execution). A representative's direct edit puts them there once. Approving an edit by its hash is planned.
  • Earlier limitations still apply: the GL1F and CIPNFT contracts keep administrators of their own, and the pool pages read a pool's lock boxes in one call.

2.1.0 (2026-10-24)

Each DAO now chooses the GL1F collections and CIPNFT contracts it works with, including ones it builds itself. Governance gets the hardening asked for by an outside review of 2.0.0, and the 2.1 changes went through an internal review of their own before release.

Integrations per DAO

  • Each DAO keeps its own lists of GL1F collections (a model registry, Model NFT, market and runtime that point at each other) and CIPNFT contracts, up to eight of each. On GenesisL1 the deployment's defaults are GL1F, GL1F Crypto and CIPNFT. The creation wizard ticks them all, and a DAO can drop any of them or add its own.
  • Add your own, remove any, by vote. Adding or removing a collection or contract is a critical Governance rules proposal of that DAO, so a DAO that builds its own model collection or sealed-data contract can work with it like with the defaults. Nobody else can change a DAO's lists: not the deployer, not another DAO.
  • Checked on chain. Adding a GL1F collection checks that its four contracts point at each other. It refuses addresses without code, duplicates, anything already listed, the DAO's own contracts and the protocol's contracts (the read-only lenses aside, which hold nothing).
  • Rules by role. Default rules name a role (CIPNFT contract, GL1F registry, Model NFT, market or runtime) instead of an address, so they cover every contract the DAO lists in that role. An explicit rule for one address beats the role rule, which beats the wildcard. The treasury stance follows the roles too: listing a model on any listed market, or paying model revenue elsewhere, is critical wherever treasury spends are.
  • One DAO key across CIPNFT contracts. The key vault serves every listed CIPNFT contract with one DAO key, and each vault call names its contract. Activating a key epoch checks the key registered on each listed contract. A proposal that adds a CIPNFT contract registers the active key there in the same proposal.
  • GL1F Crypto. A DAO owns, prices and sells GL1F Crypto models like GL1F ones. Changing a model's licence (only ever to a later or more open one) and how its internals are shown are critical actions. Paid subscriptions there can't be revoked, and a model can't be deleted until they end; the interface says so wherever a plan is priced.
  • In the interface:
    • the models page lists the models of every collection the DAO uses, labelled by collection;
    • sealed data works per contract;
    • a new Integrations builder adds a listed collection or contract, or your own with a live check of its cross-references, and removes one, with a reminder to cancel listings and offers there first;
    • DAO settings shows each integration with the live holder of each outside admin key and what that key can do to the DAO's assets;
    • a collection or contract the deployment does not list is called "Unlisted GL1F collection" or "Unlisted CIPNFT contract", never by its own name, and flagged wherever it appears. Before a transaction to it, the wallet's own network must confirm that the DAO's policy lists it.
  • Deployment. The deployment record and config.js carry gl1f and cipnft lists. script/integrations.json holds the chain-29 defaults; EXT_INTEGRATIONS names another file. The deploy page checks each collection's cross-references; its bundle format is collab-protocol/2.

Outside review of 2.0.0

An outside review read the published 2.0.0 archive, its source and its documentation. It could not run the Solidity suite and it was not an audit. All nine items were confirmed and are resolved (OR-1 to OR-9 in docs/SECURITY.md):

  • Outside admin powers are shown. "No admin keys" now names COLLAB's own contracts. The GL1F registry and market owners and CIPNFT's admin keep powers of their own; the documentation lists them, and each DAO's settings page shows who holds them (OR-1).
  • Freeze votes. A freeze vote locks its target's shares through the last second the freeze can be executed, and anyone can release the lock once the vote has failed. With the new freeze bond (FLAG_FREEZE_BOND, on in every preset), a freeze vote that is rejected or misses quorum forfeits its deposit, so a vote set up to fail costs its proposer. Freeze votes on one account can run side by side, each with its own lock, so a DAO with transferable shares should keep its minimum deposit meaningful; the interface warns (OR-2).
  • Ordered rules. At creation and on every change, the critical voting period must be at least the standard one, the critical veto threshold at most the standard one, and the critical minimum Yes at least the standard one, besides the existing quorum, threshold and timelock checks. The wizard and the rules builder refuse the same (OR-3).
  • Minimum Yes. Abstain counts towards quorum only, so a small Yes could pass when most voters abstain. Each rule set can now require Yes to reach a share of all voting power, up to 50% (minYesBps), and the interface states the smallest Yes that passes standard and critical votes (OR-4).
  • Exact simulation. An executable proposal is simulated through governor.execute itself. Earlier ones are simulated without the governor's execution context and labelled approximate (OR-5).
  • Plain statements about module permissions (a module may call its function with any arguments), the holding period (it compares two readings; two more tests) and encrypted data versus the rights in it (OR-6, OR-7, OR-9).
  • The directory's open-proposal cache expires after 60 seconds (OR-8).

Internal review of the 2.1 changes

Before release, a separate AI-assisted review of the 2.1 contract changes, done apart from the implementation work, tested every finding against the real GL1F, GL1F Crypto and CIPNFT bytecode. It found one medium, three low and eight informational issues, all resolved (RV-1 to RV-12 in docs/SECURITY.md), and no way for an outsider, a single member or a single steward to take treasury assets or sealed data.

  • Where treasury spends are critical, GL1F pricing, access plans, owner access keys and model settings are critical on every listed registry, whoever is paid (RV-1), and every approval on a listed Model NFT counts, token 0 included (RV-9).
  • A one-vote-per-account rule written first for OR-2 left a gap between votes, so it is gone; the freeze bond stays (RV-2). The freeze lock now also covers the last executable second (RV-7).
  • Approvals can always be revoked, even after a collection is removed (RV-3, completed by V21-1).
  • A purchase through the key vault completes only when the DAO's offer is sealed to its active key, and a classic-only key epoch is refused while a listed contract holds the DAO's post-quantum key (RV-4). So a purchase proposal creates the offer first and approves the purchase second, which is how the interface composes it.
  • One Governance rules proposal can unlist a CIPNFT contract that doesn't answer and rotate the key (RV-5).
  • The minimum Yes is capped at 50% (RV-10), reveals stop on an unlisted contract (RV-11), and no protocol contract can be listed as an integration (RV-12). RV-6 and RV-8 are documented.

Verification of the 2.1 fixes

Another separate AI-assisted check, done apart from the implementation work, verified each fix with a test of its own. It confirmed that the removal of the one-vote rule restores every 2.0 protection of the freeze lock, and found no way for an outsider, a single member or a single steward to take funds, tokens, shares or sealed data. It found one low and three informational issues (V21-1 to V21-4 in docs/SECURITY.md):

  • After a collection is removed, a treasury proposal can now revoke a market's collection-wide approval as well, so a stale listing can't sell (V21-1).
  • A listed contract that doesn't implement post-quantum keys, such as a DAO's own classic-only system, no longer blocks a classic key rotation (V21-2).
  • Completing a CIPNFT purchase or delivery directly, outside the key vault, is critical in every DAO, since it skips the stewards' checks (V21-3).
  • One freeze proposal can lock up to 32 accounts for one deposit; this is documented next to the freeze trade-off (V21-4).

Interface review of the 2.1 changes

A separate review of the 2.1 interface changes found two medium, one low and one informational issue, all fixed and checked again by the same reviewer (FE21-1 to FE21-4 in docs/SECURITY.md):

  • The review of a proposal now flags an approval of the DAO's Model NFTs to anything but the model's own market, and every call on an unlisted integration (FE21-1).
  • Adding a CIPNFT contract registers the active key epoch's key as the wallet's own network reports it, not as the page's RPC endpoint does. Minting stops unless the contract holds the DAO's active key, and the review warns about any key registration that doesn't match the active epoch (FE21-2).
  • Integration names in config.js follow one rule, without duplicates or look-alike characters (FE21-3); a settings note names pending additions exactly (FE21-4).
  • The reviewer's check of the fixes found two more low issues, both fixed. Names that look alike within the Latin script count as the same name, and the deploy page fails a look-alike of a default (FE21-5). The review of a key registration always asks you to compare the key's fingerprint with the stewards' (FE21-6).

Interface changes

  • DAOPolicy: integration roles and their rule keys (integrationRole, roleTarget, CIPNFT_TARGET to GL1F_RUNTIME_TARGET), gl1fCollections(), cipnfts(), addGl1fCollection, removeGl1fCollection, addCipnft and removeCipnft with their events, and InvalidIntegration(reason). Outside raw-transaction proposals, an action whose target is at or below 0x105 reverts InvalidTarget. homes() loses its CIPNFT and GL1F fields and initialize takes the lists.
  • CipherVault: the token functions take the CIPNFT contract first; purchaseOf(cipnft, tokenId) replaces purchases(tokenId) and policy() replaces cipnft(); errors UnlistedCipnft, OfferKeyNotActive and PqcKeyRequired; events carry the contract.
  • DAOFactory: defaultGl1f() and defaultCipnfts(); CreateParams ends with gl1f and cipnfts; protocol() loses its CIPNFT and GL1F fields. The factory reports COLLAB DAO v2.1.0.
  • DAOGovernor: VoteRules.minYesBps, MAX_MIN_YES_BPS (5000), FLAG_FREEZE_BOND (32), and the InvalidParams reasons "minYes", "critical votingPeriod < standard", "critical veto > standard" and "critical minYes < standard".
  • DAOLens: DAODetails replaces cipnftKey with gl1f, cipnfts and cipnftKeys.
  • PolicyBuilder writes 116 default rules, and its Targets lose the CIPNFT and GL1F fields.
  • Tests. forge test runs 289 tests in 84 suites, including the proof-of-concept tests of the internal review and of its verification (now asserting the fixed behaviour) and a check that every COLLAB contract fits the EIP-170 code size limit, which local test chains raise.

Upgrading

Nothing was deployed on GenesisL1 mainnet, so 2.1.0 replaces 2.0.0 without a migration. Deploy it as a new protocol (docs/DEPLOY.md or the /deploy page).

Not done yet

  • No external audit. Start with small amounts and conservative settings.
  • The contracts are not yet deployed on GenesisL1 mainnet.
  • The GL1F and CIPNFT contracts keep administrators of their own, which COLLAB can't limit, and a DAO that lists a collection trusts its market with the approvals it gives it.
  • The pool pages still read a pool's lock boxes in one call, so a pool spammed with thousands of lock boxes shows no lock information there.
  • Reloading the deploy page while a transaction is being sent once led, in testing, to one extra transaction: the deployment still completed and every check passed, but the extra transaction costs gas. Let each transaction confirm before reloading.

2.0.0 (2026-10-23)

A redesigned, wider and more secure COLLAB: the look of genesisl1.com's governance page, light and dark themes, clean URLs, user settings, a deploy page, and contracts rebuilt on audited libraries. Released under the MIT License, copyright Decentralized Science Labs LLC.

Website

  • Design aligned with genesisl1.com/gov.html. White windows with 1px hairlines and 14px corners, gov.html status pills and vote colours, GenesisL1 blue. Light and dark themes (System, Light or Dark), with the GenesisL1 zinc palette in dark.
  • Wide and responsive. Pages use up to 1600px. DAO pages have a section rail, the main column and a context aside on wide screens, a section bar on tablets and phones, and work down to 360px.
  • A scientific identity. Every DAO without a logo gets its own molecule glyph, and the landing page draws the DAOs as one network molecule, bonded by the members they share. Charts are numbered, captioned figures with reference lines (quorum, threshold, veto). Constitutions, proposal descriptions and the docs are set in Source Serif like a journal article.
  • Clean URLs, for example /dao/<address>/proposals/12, /dao/<address>/propose/treasury/send, /swap, /pools/<pair> and /docs#holding-period. Version 1 links redirect. Static hosts without rewrites are served through a 404 fallback.
  • Settings (/settings): theme; the RPC endpoint (presets, or a custom one that must answer for chain 29 with a recent block); the block explorer; and the display currency (L1, or one of 20 currencies with the price from CoinGecko).
  • Cookie notice in the style of genesisl1.com. COLLAB keeps only settings in the browser. Analytics are off unless a deployment configures them, and then load only after consent. A browser that sends Global Privacy Control counts as a decline.
  • Deploy page (/deploy). Deploys the whole protocol from a browser wallet in the order of script/Deploy.s.sol, verifies every contract's code and wiring, resumes after interruptions (checking saved progress against the release's code), and produces the deployments file and config.js for the site. It can also check an existing deployment.
  • Search engines and link previews. tools/prerender.py writes a static page for every DAO with its title, description, Open Graph image and structured data, static heads for /pools and /locks, the sitemap, and og/network.json, the member network the landing page draws without scanning the chain. Every page has a canonical link and Open Graph and Twitter tags. Server configurations for nginx, Caddy, Netlify and Cloudflare Pages carry the same security headers, and deploy/check_site.py checks a published site.
  • Your wallet's network as a second source. Before a transaction to a DAO's contracts or a payment to its treasury, COLLAB reads the DAO's addresses again through the wallet's own network and sends nothing if they differ. The keys data is sealed to and a proposal's committed actions are checked the same way. Every transaction carries the chain id, and the RPC endpoint's chain is re-checked every five minutes.
  • The review lists everything. The plain-language review of a token launch lists every recipient, largest first, with an allocation summary that must add up to the supply and a warning when one account receives a quarter of it or more; a rules change lists every rule.
  • Markdown is parsed by markdown-it 14.1.0 (MIT); COLLAB renders its tokens to the page itself, with raw HTML and images off.

Contracts

  • Audited libraries. OpenZeppelin Contracts Upgradeable 5.1.0 (Initializable, ERC20, Ownable, ReentrancyGuard), OpenZeppelin Math and SafeCast, and Solady 0.1.26 SSTORE2 for on-chain text. Two-step ownership, pausing, caps, votes and value transfers stay custom where the library versions would change behaviour.
  • Treasury value follows the treasury's rules. In a DAO where treasury spends are critical, every action that can give up treasury value is critical too, whatever the proposal type: L1 sent or wrapped, non-zero approvals (except of LP tokens) and operator approvals, swaps, pool deposits, launch pools and launches, listings and direct sales, transfers and mints to anyone but the treasury, handing over or giving up a token's ownership or its minting, redirected revenue, burns, and locks that are permanent or end more than ten years after the proposal. Exits, fee collection into the treasury and treasury-owned locks with an end date stay standard.
  • Invariant tests for every token and share rule and for the treasury stance (test/invariants/). They found V2-01 (a stale freeze-lock claim), which is fixed.
  • Readable text. Titles, names and symbols must be well-formed UTF-8 without control characters (V2-02).
  • Token and share review, and two rounds of verification. A review of token and share management, done apart from the implementation work, found three medium and two low issues in the contracts and one medium issue in the interface. Two verification rounds of the fixes found two more medium, three low and five informational issues. All are fixed with regression tests or documented as known limitations (R1–R3, L1, L2, W1, N1–N4, I1–I4, B1 and B2 in docs/SECURITY.md):
    • DeSciFi calls that pay anyone but the treasury are as critical as treasury spends, and so is every other way of giving up treasury value (above).
    • Equal-per-member airdrops need shares that were never transferable (ShareToken.everTransferable).
    • DeSciFi wildcards reach only real pools and lock boxes; handing over or giving up any other contract is always critical.
    • Excluded accounts such as pools cannot be frozen or locked.
    • The market lens names a token's launcher only when it is a COLLAB DAO, and reports each token's current administrator, so the interface shows which DAO issued a token and whether it still administers it.
    • Lock box and airdrop lists are paged and cannot be spammed into failing; empty lock boxes are refused, and airdrops the DAO created are marked as such.
    • The review names recipients only from known addresses, never by a contract's own symbol.
  • Interface changes. ShareToken.everTransferable(); errors AccountExcluded, FreezeTargetExcluded, EqualNeedsFixedMembers and InvalidAmount; MarketLens takes the DAO factory as a fifth constructor argument and adds factory(), owners(tokens), locksOfPage, locksPayingPage and campaignsOfPage; LockFactory adds ownerLockCount, ownerLockAt, feeLockCount and feeLockAt; MemberDistributor adds campaignCountOf and campaignIdOf; DAOPolicy exposes LOCK_HORIZON(). The factory reports COLLAB DAO v2.0.0.
  • Reproducible build. Contracts compiled from the release archive are byte-identical to the bytecode the deploy page sends, metadata included: foundry.toml uses only remappings.txt, and tools/build_release.py checks this on a clean extraction.
  • Tests. forge test runs 197 tests in 54 suites.

Interface review

A separate review of the redesigned interface and the site tooling found one high, two medium and two low issues, all fixed (FE2-H1 to FE2-L2 in docs/SECURITY.md): the launch review that cut off long recipient lists, a header injection and an open redirect in the servers' trailing-slash rule, quadratic Markdown-to-text conversion, a custom RPC endpoint choosing transaction targets and sealing keys, and unverified tokens preset by swap links.

Licence

Every source file carries the MIT licence header with Decentralized Science Labs LLC as copyright owner. Third-party components keep their own licences (THIRD_PARTY_NOTICES.md). The DeSciFi exchange is an original implementation, because Uniswap's code is GPL or BUSL licensed.

Upgrading

Release 1.0.0 was not deployed on GenesisL1. Deploy 2.0.0 as a new protocol (docs/DEPLOY.md or the /deploy page).

Not done yet

  • No external audit. Start with small amounts and conservative settings.
  • The contracts are not yet deployed on GenesisL1 mainnet.
  • A rule that a governance vote adds later, for a contract or call COLLAB does not know, stays standard unless the vote marks it critical. Mark such rules critical when they can move value.
  • The pool pages read a pool's lock boxes in one call, so a pool spammed with thousands of lock boxes shows no lock information there; the rest of the page keeps working.

1.0.0 (2026-10-22)

First release of COLLAB: serverless DAOs for scientific communities on GenesisL1.

Contracts

  • DAOs without owners. A factory creates DAOs from six owner-less clones: treasury, governor, shares, policy, profile and key vault. There are no admin keys and no upgrades.
  • Governance like GenesisL1. Proposals have a deposit period and vote Yes, Abstain, No or No-with-veto, with quorum, pass and veto thresholds. Delegation lets a delegator's own vote override its delegate's. Every proposal has a timelock, an execution window and deposit penalties.
  • Critical rules. Thirteen proposal types are checked by an on-chain call policy; critical types and calls use stricter rules.
  • Holding period. DAOs with tradable shares get a holding period, so freshly bought shares cannot decide a vote. Votes are counted independently of their order.
  • Membership.
    • Members can be frozen and unfrozen by vote, with per-proposal transfer locks.
    • Infrastructure accounts can be excluded from membership.
  • Treasury. Holds L1, ERC-20 tokens, ERC-721 and ERC-1155 NFTs, CIPNFT assets and GL1F Model NFTs, and signs for the DAO (ERC-1271). Raw-transaction proposals make the DAO a multisig, and any party can broadcast them once passed.
  • Representatives and constitution.
    • Representatives with limited, expiring powers edit the profile: title, description, on-chain logo, links and announcements.
    • The constitution is versioned on-chain.
  • Tokens and DeSciFi.
    • Token issuance in one proposal, to the treasury, named recipients, member airdrops, and one- or two-sided pools.
    • Token administration by vote.
    • DeSciFi: constant-product pools, launch pools, LP locks with a fixed fee recipient (the treasury, a collector or the burn address), and a router.
  • Sealed data on CIPNFT. Elected key stewards hold the DAO's CIPNFT key. The DAO can buy, mint, sell, reveal to members and declassify assets. Purchases are bound to the delivery a steward verified.
  • GL1F models. The DAO can own models, set inference prices and access plans, and sell access.
  • Security review. An internal security review found 12 issues (2 high, 8 medium, 2 low) plus 9 informational notes; a 13th issue was found while documenting the fixes. All are resolved. See docs/SECURITY.md for the table and the tests that cover each.
  • Tests. forge test runs 104 tests in 26 suites: unit, fuzz, invariant and the review's proof-of-concept tests.

Website

  • Static and dependency-light. Plain HTML, CSS and JavaScript ES modules, with no build step, no Node.js and no third-party requests. A strict Content-Security-Policy applies everywhere.
  • Pages.
    • DAO directory and creation wizard.
    • DAO pages: overview, proposals, treasury, members, constitution, tokens, liquidity, sealed data, models and settings.
    • A proposal composer with a plain-language review, an on-chain policy check and an execution simulation.
    • The DeSciFi exchange, the documentation, and per-DAO titles and share previews.
  • Browser end-to-end tests drive every area with a test wallet against a local chain:
    • tools/e2e/run.py runs them;
    • tools/e2e/sweep.py checks the visual and layout behaviour in light, dark and phone widths.

Not done yet

  • No external audit. Start with small amounts and conservative settings.
  • The contracts are not yet deployed on GenesisL1 mainnet. docs/DEPLOY.md describes the deployment.