A DAO's constitution is its contracts, but its working life runs on software somebody else operates: a voting front end, a forum, a member workspace, a payments app, a badge issuer, an analytics dashboard. Those tools are chosen once, wired into the way the organization actually works, and then almost never revisited. DAO tooling discontinuity is what happens when one of them stops existing.

The industry treats this as an operational annoyance. It is closer to a governance problem, for three reasons this page works through: the damage depends entirely on what the tool was holding, not on how important it felt; the signals people use to check whether a tool is still alive are unreliable in specific and predictable ways; and unlike a service provider, a SaaS dependency is usually adopted below the threshold that would ever put it to a vote, so when it fails there is no owner and no process.

A measured cohort

Between February and August 2026 this wiki kept a queue of DAO tooling products it intended to write up. Each was, at the time it was added, a going concern with a product site and users. On 5 August 2026 all seven were checked directly before any page was written. Six were gone, parked, or no longer in the category.

Tool	What it did	State on 5 Aug 2026
Llama	Treasury and governance framework	Gone. llama.xyz returns no DNS A record at all, and llamaxyz/llama is flagged archived with its last push on 16 August 2024.
Otterspace	Non-transferable membership badges	Gone. otterspace.xyz still resolves to Netlify addresses but the TLS handshake fails, and the otterspace-xyz contracts repository is a 404.
Utopia Labs	DAO payments and payroll	Holding page. utopialabs.com answers 200 with a 734-byte document: a title, a webfont link, and an empty root element.
CharmVerse	DAO workspace, proposals and roles	Product gone. charmverse.io now serves a domain-parking lander, app.charmverse.io has no DNS A record, and the repository is not archived, last pushed 18 October 2025.
Syndicate	Investment-club framework	Pivoted out of the category. syndicate.io now sells "the infrastructure to infinitely scale Ethereum" and lists an exchange-traded token. The investment-club product is not part of it.
Metropolis (ex-Orca Protocol)	Membership pods over a Safe	Unidentifiable. metropolis.space answers 200 with an empty JavaScript shell and the contracts repository path 404s.
Den	Multisig operations over Safe	Alive at onchainden.com. Note that den.xyz, the domain people assume, is parked for sale and is a different thing.

Treat that as one dated observation, not a survival rate: it is a convenience sample of seven, assembled because the tools looked notable, and notability is correlated with having raised money in a particular window. What it does establish is the shape of the risk. These are not obscure projects, the window is short, and none of the six announced anything to the DAOs still depending on them. The disappearance was discovered by dig, not by an email.

Classify by what the tool holds, not by what it does

The useful question is not how important a tool feels but what would be irretrievable if it vanished overnight. Three classes behave completely differently.

A dead interface is recoverable. When a tool is a view over state that lives on-chain, its death costs convenience and nothing else: the proposals, votes and balances are still there, and anyone can read the contract or build another front end. Tally's 2026 wind-down is the worked example, and the reason it was survivable is precisely that the Governor contracts it fronted never stopped working.

A dead hosted record is lossy, and the loss is the reasoning. Workspaces, forums, and payment apps hold the material that never had an on-chain shadow: the draft that became a proposal, the objection that changed it, who held which role in which month, what an invoice was for. When CharmVerse's application host stopped resolving, that class of material went with it. A DAO in this position keeps its money and its contracts and loses its memory, which is the half that made the money legible. The same boundary shows up even in healthy tools: Den adds no contracts to Safe, so the human-readable description a signer reads sits on Den's servers next to a payload that is immutable on-chain.

A live contract with a dead maintainer is the dangerous one. Deployed contracts do not shut down. An unmaintained module that still holds a role on a treasury Safe, a badge contract that still gates membership, a streaming contract that still holds a balance: all of these keep executing exactly as deployed, which is the problem. Nobody ships the fix, nobody answers the disclosure email, and the standing permission outlives the company that asked for it. A dead front end is an inconvenience. A live privileged contract with nobody behind it is an open item on the attack surface.

The signals that lie

Every check people reach for first is unreliable, and the failures are systematic rather than random.

• An HTTP 200 from the marketing domain proves nothing. Both charmverse.io and utopialabs.com answered 200 while the product behind them was gone: one serves a parking lander, the other a 734-byte shell. Domains outlive products because renewing a domain is cheap and shutting one down is a decision nobody gets around to making.
• Probe the application host, not the homepage. The strongest single signal in this cohort was a missing DNS A record on the app subdomain. Nobody pays to keep an application host resolving by accident.
• An archived repository is an honest signal; an unarchived one is not a signal at all. Llama's team set the archive flag, which is a courtesy. CharmVerse's repository is not archived and its app host does not resolve. The flag tells you something when it is set and nothing when it is absent.
• A traded token is not a living product. Syndicate's token has exchange listings and its company is clearly operating. The thing a DAO wanted from it no longer exists.
• Recent commits are weak evidence either way. CharmVerse's last push was ten months before its app went dark. Maintenance stops well before the lights do.

The check that actually works takes about a minute per tool and needs no API key: resolve the application host (dig +short app.example.com A), fetch it while watching the response size as well as the status code (a 734-byte page is not a product), and read pushed_at and archived from api.github.com/repos/<org>/<repo>. Run it against your own stack before you need the answer.

Why nobody owns the dependency

DAOs have built real process around money. A service provider is selected through a scored public process, funded by a proposal, and renewed by another one. Delegate payrolls and governance operating costs appear as budget lines that somebody argues about every season.

Tooling almost never gets there. It is adopted by a contributor with a company card, at a price too small to reach a proposal threshold, and it becomes load-bearing through use rather than through a decision. The result is an inversion: the dependencies with the most governance process attached are the ones the DAO could most easily replace, and the ones holding its actual working record have no proposal, no renewal date, no termination clause, and no named owner. When they fail, the failure surfaces as a support ticket that nobody can file.

This is also why discontinuity rarely appears in post-mortems. It produces no vote to point at and no on-chain event to timestamp, so it leaves the same kind of no-trace gap as the decisions that never became proposals.

What actually reduces the exposure

• Keep the binding state on-chain and treat every interface as replaceable. This is the whole reason Tally's wind-down was survivable and CharmVerse's was not. If losing a vendor would lose a decision, the decision was never really on-chain.
• Export the record on a schedule. Forum threads, proposal rationales, role histories. The export is worthless as a habit if it starts after the announcement, and there is usually no announcement.
• Revoke permissions from tools you have stopped using. Deprecation in a DAO tends to mean "we stopped opening it", which leaves the role, the module and the allowance exactly where they were. Auditing standing permissions against tools actually in use is the cheapest item on this list.
• Understand the trade in "no extra contracts". A tool that deploys nothing (Den over Safe) leaves no orphaned privileged code when it dies, but takes its off-chain record with it. A tool that deploys contracts (Hats, Zodiac) leaves durable state you can still read, and durable permissions you must remember to remove. Neither is the safe option in general; they fail in opposite directions.
• Check before you depend, and again on a cadence. The cohort above is what a queue looks like six months after it was assembled by people paying attention.

The wider pattern is visible across the tooling this wiki already covers: Aragon dissolved its association and refocused on a product, Coordinape sunset its app, Superfluid deprecated a major interface, and Boardroom has had to say out loud that it has no plan to deprecate. Discontinuity is the normal condition of this layer, not an exception in it.

How Caper approaches this

Verified against the Caper contract source, not aspirational.

A caper keeps the material that the hosted-record failure class destroys inside its own component state on the Radix ledger. Proposals, their options, the per-proposal ballots, and the proposal's title and description payload are all stored in key-value stores on the caper's state component (contracts/core/src/caper_dao.rs), and the reads are public methods on that component: read_proposal, read_proposal_meta, read_ballots and read_winner. There is no vendor database holding the reasoning beside a payload, because the description travels in the same state as the proposal and the ballots.

The contract is also split along this exact seam. The state tier is described in its own source as immortal, deployed once per caper and never migrated, and it deliberately holds no business logic; the curve math, the tally and the vote-weight formula live in a separate, swappable logic package that drives it. So replacing Caper's own logic does not move the record either. On the permissions side, every method that moves treasury assets is restricted to a single admin badge, and there is no module surface for a third-party tool to hold a standing role, which removes the orphaned-privileged-contract class rather than mitigating it.

The honest limit: this is about the record, not the interface. caper.network is a front end like any other and enjoys no special immunity. What the design buys is that a reader who loses the front end can still get the proposals, the ballots and the outcomes off the ledger. That is the same property that made Tally's wind-down survivable, applied to the half of the record that most DAOs keep somewhere else.

References

• llamaxyz/llama — archived repository, last push 16 August 2024.
• charmverse/app.charmverse.io — unarchived repository, last push 18 October 2025, product host no longer resolving.
• otterspace-xyz — GitHub organization; the contracts repository referenced by the product no longer exists.
• syndicate.io — current product positioning after the pivot away from investment-club infrastructure.
• Den documentation — the surviving tool in the cohort, and the clearest statement of where an off-chain description sits relative to an on-chain payload.
• Caper contract source: contracts/core/src/caper_dao.rs (state tier, proposal and ballot storage, public reads) and contracts/core/src/dao_treasury.rs (admin-gated treasury methods).