# Known limitations This page gathers every known limitation of COLLAB 2.2 in one place: from the security model, the release notes and the reviews. Each one says, in plain words, what the limitation is and what to do about it. It is for members deciding how much to trust a DAO with, and for anyone who wants the honest list before relying on COLLAB. Some items are by design; others are planned to change. ## The release - **No external audit.** The contracts, the server kit and the website had AI-assisted reviews, done apart from the implementation work; an outside review of the 2.0.0 archive could not run the tests. None of them is an audit. *What to do:* keep in a DAO only what you can afford to lose; start with small amounts, short periods and conservative settings, and treat the first DAOs as a public test. See [Security at a glance](security-overview.md). - **The installer is untested on a live server.** It was tested on Ubuntu 24.04 in a sandbox, with real nginx on test ports, a self-signed certificate and a stand-in for certbot. The first run on a real server is the first with Let's Encrypt and systemd. *What to do (operators):* point the DNS of every name at the server first, then run it; see [Installing COLLAB on a server](INSTALL.md). ## Fees and gas - **A failed transaction still costs half its gas limit.** GenesisL1 charges every transaction at least half the gas limit it was sent with, even when it fails. For a large transaction with an explicit limit, that can be many L1. *What to do:* read the failure cost COLLAB shows before you sign, and keep logos and descriptions small. See [A failed transaction still pays](costs.md#a-failed-transaction-still-pays). - **Large logos and descriptions are expensive, and wallets cannot estimate them.** Writing a new 32-byte word costs about 23,000 gas; a creation with a 64 KB logo and a 16 KB description uses about 64 million gas. Nodes stop estimating at 25 million gas by default, so COLLAB sets such limits itself, and a node with a lower per-transaction cap refuses them. *What to do:* real 128 × 128 logos need only 5 to 30 KB; use another RPC endpoint if yours refuses. See [Large logos and descriptions](costs.md#large-logos-and-descriptions). - **Removing a large logo is not cheap either.** Clearing stored words costs gas, and refunds are capped: removing a 512 KB logo costs about 66 million gas, and replacing it with a small one costs about as much, since the old tail is cleared either way. *What to do:* plan the size from the start. ## Names and profiles - **A web address can be taken first.** Web addresses are first come, first served, and a creation waiting to be mined shows its address. Someone watching pending transactions can create a DAO with your address first; yours then fails and still pays half its gas limit, about 15.8 L1 for the largest creation, while taking the address costs about 0.27 L1. There is no reservation step in 2.2. *What to do:* COLLAB checks the address again just before your wallet opens; for a large logo or description, create the DAO without them and let a representative add them right after. A reservation by commit and reveal, and a two-step creation, are planned. - **Web addresses can look alike.** They use lowercase letters, digits and hyphens only, but `l` and `1`, `0` and `o`, or `rn` and `m` still look alike, and a name or web address says nothing about who runs a DAO. *What to do:* check a DAO's address against what its group publishes; see [Copycat DAOs](staying-safe.md#copycat-daos). A site's operator can hide squatted or spam DAOs from that site's listings; that changes nothing on chain or on other copies. - **The title and web address can never change.** *What to do:* choose them with care; a DAO that needs a new name needs a new DAO. - **A title may hold invisible or direction-changing characters.** The contract refuses the C0 control characters and DEL in titles, but not the C1 controls, direction controls or other invisible characters, and a title can never be corrected. The interface removes such characters from the names it shows and isolates every on-chain string from the text around it. *What to do:* rely on the web address, not the name. - **Only a logo's header and closing chunk are checked.** A logo may be malformed (browsers then show a broken image), animated, or not an image at all. The interface shows logos only as PNG images, never as SVG or HTML. - **Edits do not erase history.** An edit overwrites the logo or description in the profile, but the transactions that set earlier versions stay in the chain's history, so published content cannot be truly withdrawn. An edit by proposal puts the bytes there three times, a representative's edit once. *What to do:* publish only what you can leave public forever, and make large edits through a representative. Having proposals approve a content hash, uploaded once afterwards, is planned. ## Governance - **Governance is powerful by design.** A proposal that passes the critical rules can do anything, including moving the whole treasury with a raw transaction, and raw transactions cannot be switched off. The timelock is warning time, not a veto: members cannot stop a passed proposal. *What to do:* choose quorum, thresholds and timelocks that fit how much your members trust each other; see [Governance rules and presets](governance-rules.md). - **Low turnout can decide.** Quorum compares votes with all voting power, so with a low quorum a small group decides; abstentions count towards quorum, so without a minimum Yes a handful of Yes votes can pass a proposal the rest abstain on. *What to do:* keep a minimum Yes, as every preset does; see [Abstentions and the minimum Yes](proposals.md#abstentions-and-the-minimum-yes). - **A DAO can vote itself into a corner.** Within the bounds, a DAO can set very long voting periods, a very high quorum or a minimum Yes above the voting power its members actually use, and there is no admin to undo it. *What to do:* review rule changes as carefully as payments. - **Whoever executes chooses the moment.** Execution is open to anyone, who picks the moment within the execution window and the order of passed proposals that conflict. *What to do:* do not pass proposals that conflict. - **Trades are fixed at submission.** A proposal's swaps and liquidity changes can execute later at exactly their minimum amount, or fail if the market moved past it. *What to do:* set the minimum to what the DAO really accepts; where treasury spends are critical, such proposals need the critical rules. - **Leftover allowances.** An allowance left by one proposal could be used by a later proposal of a type that may call the same spender. COLLAB's own forms reset the allowances they grant in the same proposal. *What to do:* do the same in raw transactions. - **Rules added later are standard.** Treasury value is protected for COLLAB's default rules, its own contracts and the integrations a DAO lists. A rule a Governance rules proposal adds later, for another call that can move value or for a contract the DAO does not list, is standard unless it is marked critical. *What to do:* mark such rules **Makes the proposal critical**; see [When treasury spends are critical](treasury.md#when-treasury-spends-are-critical). - **Other ways to hand over a contract.** The policy recognises handing over or giving up a contract by `transferOwnership` and `renounceOwnership`. No default rule allows other ways, such as `setOwner` or granting roles. *What to do:* a DAO that adds a rule for one should mark it critical. - **Long locks are judged at submission.** Where treasury spends are critical, a lock box that opens more than ten years after the proposal's submission counts as permanent; the ten years count from submission, not execution. *What to do:* check unlock dates in proposals. ## Shares and freezes - **A series of freeze votes can hold a member's shares.** With freeze locks and transferable shares, a freeze vote blocks the member's transfers for the whole vote, even one the member wins, and through its execution window. Freeze votes can overlap, anyone can fund one, one proposal can name 32 accounts, and anyone can complete a partly funded freeze proposal's deposit to start its vote when they choose. A proposal keeps the settings it was submitted with. *What to do:* with transferable shares, keep a minimum deposit that makes such a series expensive (with the freeze bond, each failed vote costs its deposit), or leave freeze locks off. See [Freeze locks](members.md#freeze-locks). - **A lock placed before an exclusion halts a pool.** A share lock that a freeze vote placed before an account was excluded lasts until that proposal releases it. *What to do:* exclude pools and other infrastructure before trading starts. - **Frozen shares still count in open proposals.** For proposals already open when a member is frozen, the frozen shares stay in the quorum base, and a delegate the member chose earlier can still vote with them there. *What to do:* nothing; later proposals no longer count them. - **Shares that change hands in the holding window count for nobody.** Neither the seller nor the buyer gets weight for them on a proposal whose window covers the trade, and a shared delegate can lose them too. See [The holding period](proposals.md#the-holding-period). ## Integrations - **Outside administrators keep powers.** The GL1F collections and CIPNFT contracts a DAO uses have administrators of their own, who can change fees and terms and cancel listings; the original GL1F registry's owner can delete a model and replace the Model NFT contract. A DAO that lists a collection trusts its market with the approvals it gives. COLLAB cannot limit any of this. *What to do:* check the live holders of each key in the DAO's Settings; see [Outside admin keys](integrations.md#outside-admin-keys). - **Look-alike contracts pass the checks.** The checks cannot tell a real GL1F or CIPNFT contract from a look-alike, and they do not know the lenses, which hold nothing and could only block key rotation. *What to do:* list only contracts you trust. - **A contract that does not answer blocks key rotation.** So does one without post-quantum support when the new key has a post-quantum part. *What to do:* one Governance rules proposal can remove the contract and activate the next key. - **A contract listed again keeps an older key.** Until a vote registers the active key on it, it takes no purchases and the next key epoch cannot be activated. *What to do:* register the active key in the proposal that adds a contract, as COLLAB's form does. - **A market listing outlives its model's departure.** If a model comes back to its seller, an old GL1F listing applies again while the market is still approved. *What to do:* approve the market for one model at a time and cancel a listing before moving its model; revoking the approval also stops it. - **Removing a collection strands its listings.** After a collection is removed, cancelling a listing there takes a raw transaction. *What to do:* cancel listings, and for CIPNFT close listings and cancel offers, before removing an integration. ## Sealed data - **Key stewards can read everything** the DAO holds, at any time, and removing a steward does not take back what they saw. *What to do:* elect stewards you would trust with the data itself, and create a new DAO key when stewards change. - **Reveals and declassifications cannot be undone.** *What to do:* vote on them as final. - **Classic copies stay on chain.** Copies sealed to accounts without a post-quantum key use classic encryption only and stay on chain permanently. *What to do:* register post-quantum keys. - **Your encryption key comes from a wallet signature.** Anyone who can make your wallet sign the same COLLAB message gets your key, and wallets that do not sign deterministically cannot recreate it. *What to do:* sign it only on a COLLAB site you trust. - **A CIPNFT buyer can cancel after delivery.** On CIPNFT, a buyer can withdraw an offer after the data key was delivered and keep the data; the interface warns before every DAO sale. *What to do:* deliver only to buyers the DAO trusts. See [What can't be undone](sealed-data.md#what-cant-be-undone). ## DeSciFi and pages - **Unsupported tokens.** Tokens that take a fee on transfer or rebase do not work in DeSciFi pools, token launches or airdrops. - **Pools spammed with lock boxes.** A pool page reads the 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. - **The market lens's batch call trusts its targets.** One hostile token in a shared batch read can make it fail. COLLAB's pages read untrusted tokens only through the lens's capped views; other apps should do the same. - **Your view of the chain.** Pages show what your RPC endpoint reports; a simulation reflects the chain as it is now and is exact only once a proposal is ready to execute. COLLAB re-reads what matters through your wallet's network before sending. *What to do:* use an endpoint you trust; see [RPC endpoints](wallet.md#rpc-endpoints). ## The server kit - **What it does not protect against:** root on the server or whoever controls its DNS; a stolen admin token, until it is replaced; and an operator who publishes a wrong deployment record. *What to do (operators):* treat the token like a key, and check a record with the admin page's Check tab before publishing it. - **A compromised prerender job can deface pages.** It cannot change the contracts the site uses or add script code, but it can change the static pages, preview images and data files. - **Behind a reverse proxy**, the sign-in limit counts the proxy's addresses unless nginx's `real_ip` module is set up for it. See [Operator security checklist](server-security.md) and [Security](SECURITY.md#the-server-kit). ## Related - [Security at a glance](security-overview.md) - [Staying safe](staying-safe.md) - [Costs and gas](costs.md) - [Security](SECURITY.md) - [Release notes](RELEASE_NOTES.md)