How Caper approaches this Verified against the Caper contract source, not aspirational. A caper (/wiki/foundations/what-is-a-caper) keeps the materialrecord that the hosted-record failure class destroys tools lose inside its own component state on the Radix ledger. PIts proposals, their options, the per-proposal ballots, (/wiki/governance/proposals) , their options, the ballots (/wiki/governance/voting) cast and theeach proposal's title and description payload are all stored in key-value stores osit in the caper's stateown 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 n, and anyone can read them back off the ledger without caper.network. No vendor database holdings the reasoning beside athe payload, because the description travels in the same state as the proposal (/wiki/governance/proposals) and the ballots (/wiki/governance/voting) . The contract is also split along this exact seam. The state tier is described in its own source as immortal,. The record also sits apart from the rules. Each caper's state is 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. Swhile the rules that read and change it live in a separate part that can be upgraded, 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. No third-party tool holds a standing role over the treasury, which removes the orphaned-contract failure this page describes rather than guarding against it. This covers the record, not the interface… is a front end like any other and enjoys no special immunity. What the design buys is that a. A reader who loses ithe front end can still get the proposals, …nd the outcomes off the ledger. That, which is the same property that made Tally's win…wn survivable, applied to the halfpart of the record that most DAOs keep somewhere else.

References - llamaxyz/llama …- Den documentation (https://web.archive.org/web/20250424005445/https://docs.onchainden.com/overview/d…lative 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).

A measured cohort Between Feb…bytes of a different business —– a page titled “Atlas” selling…ex answers 200 with 114 bytes —– a bare window.onload that sends the browser to /lander —– so the lander is reachable on…money now has no DNS A record.

The signals that lie Every ch…erse.io now answers 114 bytes —– a window.onload hop to /lander —– so it reads dead on size whil…ck before you need the answer.

References - llamaxyz/llama …//github.com/llamaxyz/llama) —– archived repository, last pus…harmverse/app.charmverse.io) —– unarchived repository, last p…//github.com/otterspace-xyz) —– GitHub organization; the cont…e.io (https://syndicate.io/) —– current product positioning a…onchainden.com/overview/den) —– the surviving tool in the coh…admin-gated treasury methods).

A measured cohort Between Feb…e (re-checked 2 October 2026).The company had already moved …money now has no DNS A record.

A measured cohort Between Feb…Business by 31st March 2026”, while the apex coinshift.xyz now sellssix months past that date (re-checked 2 October 2026). The company had already moved twice: in 2025 to csUSDL, a yield vault over Paxos's USDL that stopped taking deposits after Paxos wound USDL down (https://www.paxos.com/newsroom/winding-down-usdl-lift-dollar) in October 2025, and by March 2026 (https://web.archive.org/web/20260312080356/https://coinshift.xyz/) to iUSPC, an “institutional credit yield” product that now fills the apex coinshift.xyz – out of the category, with th…eft standing behind the notice and the docs (https://docs.coinshift.xyz/) still describing both earlier products. Parcel, which sold “spend ma…money now has no DNS A record.

What actually reduces the expo…ring (checked 22 August 2026). Polkassembly (/wiki/dao-governance/tooling/voting/polkassembly) , Polkadot's main referendum front end for six years and paid by treasury referenda throughout, closed in 2026 after its wind-down request was rejected; the votes stayed on-chain and the discussion threads went into a read-only archive. Discontinuity is the normal c…layer, not an exception in it.

The signals that lie Every ch…FOUND at every path (checked 1, 9 and 920 September 2026, the last of them with the link still on the homepage). Nothing about the vendor is…ck before you need the answer.

Classify by what the tool hold…onted never stopped working. Aragon (/wiki/dao-governance/tooling/frameworks/aragon) 's own relaunch shows the same boundary inside one vendor. On 30 June 2025 the current Aragon app replaced every earlier version, and existing DAOs had nothing to do, because their proposals and settings live in OSx contracts. The developer layer fared differently: Aragon deprecated its legacy SDK and subgraph for OSx 1.3 and earlier and said it would not update either for version 1.4 or later, so an integration built on them cannot follow its DAO past 1.3 ( Aragon (https://blog.aragon.org/upcoming-changes-in-the-aragon-app/) ). A dead hosted record is lossy,…rity-and-governance-attacks) .

Topic What happens to a DAO wh…ao) Cohort checked 5 August 2026, plus two treasury tools on 14 September 2026 (method and results below)

A measured cohort Between Feb…vered by dig, not by an email. Two treasury tools outside that sample, checked on 14 September 2026, show both ways a vendor can leave. Coinshift, a treasury-management app for crypto organisations built on Safe (/wiki/dao-governance/tooling/treasury/safe) , said so in writing: its app host beta.coinshift.xyz (https://beta.coinshift.xyz/) still carries the notice “We are sunsetting Coinshift Business by 31st March 2026”, while the apex coinshift.xyz now sells iUSPC, an “institutional credit yield” product – out of the category, with the old app left standing behind the notice. Parcel, which sold “spend management for on-chain teams” to Safe owners, contributors and accountants, left no notice on its own domain: the Wayback Machine holds its marketing site in December 2024 (https://web.archive.org/web/20241208005623/https://parcel.money/) , a Vercel DEPLOYMENT_DISABLED response in May 2025 (https://web.archive.org/web/20250503064905/https://parcel.money/) and a GoDaddy parking page by June 2026 (https://web.archive.org/web/20260615181249/https://parcel.money/) , and parcel.money now has no DNS A record.

A measured cohort Between Feb…Labs DAO payments and payroll Holding page.Gone, and the domain has since changed hands. On 5 August 2026 utopialabs.com answersed 200 with a 734-byte documentholding page: a title, a webfont link, and an empty root element. Re-checked 12 September 2026 it answers 200 with 7,677 bytes of a different business — a page titled “Atlas” selling an aircraft (“Introducing Atlas 1.2”, flight time, 270 km/h top speed, 0 m runway, “Visit our hangar”), served off Vercel, with no occurrence of “Utopia”, “DAO”, “payments” or “payroll” anywhere in the document. app.utopialabs.com still has no DNS A record. CharmVerse DAO workspace, pr…s Product gone. charmverse.io now serves a domain-parking lander…, last pushed 18 October 2025. Re-checked 12 September 2026: the apex answers 200 with 114 bytes — a bare window.onload that sends the browser to /lander — so the lander is reachable only by executing JavaScript, and a plain fetch never sees it. Syndicate Investment-club fr…vered by dig, not by an email.

The signals that lie Every ch…e product behind them was gone: one serves a parking lander, the other. Domains outlive products because renewing a domain is cheap and shutting one down is a decision nobody gets around to making. - Response size has a short shelf life as a signal, and it fails in both directions. On 5 August 2026 those two exhibits sorted cleanly by weight: a parking lander and a 734-byte shell. DomaBoth readings outlive products because renewing a domain is cheap and shutting one down is a decision nobody gets around to makinghad inverted by 12 September 2026. utopialabs.com now serves 7,677 bytes of a live aircraft business on a domain that changed hands, so it reads healthy on status and size while the DAO payments product is as gone as it ever was. charmverse.io now answers 114 bytes — a window.onload hop to /lander — so it reads dead on size while the lander behind it is unchanged. A byte count tells you who is paying for the domain this month, not whether the product exists. The rarer failure is the one to watch for: a new occupant makes a dead tool look alive on every cheap signal at once, and the Internet Archive has no capture of the Atlas page to contradict it. - Probe the application hos… app.example.com A), fetch it whileand read whatching the response size as well as the status code (a 734-byte page is not a product came back rather than only how much of it there was (a byte count can grow because a different company bought the domain), and read pushed_at and arch…ck before you need the answer.

The signals that lie Every ch…ed from it no longer exists. - Documentation dies before the product does. Gelato is trading and shipping, and both its marketing site and its application host answer 200 – while docs.gelato.cloud, the documentation link on Gelato's own homepage, returns a Vercel DEPLOYMENT_NOT_FOUND at every path (checked 1 and 9 September 2026). Nothing about the vendor is dead; its priceable terms are. Documentation is a hosted record with the same single point of failure as a workspace or a forum, and the archive is a poor substitute for a docs site that renders its tables after hydration – what that cost one figure is set out on who pays to execute a passed proposal (/wiki/dao-governance/concepts/analysis/proposal-execution-costs) . - Recent commits are weak evid…ck before you need the answer.

A measured cohort Between Feb…) Membership pods over a Safe UnidentifiablePivoted out of the category. metropolis.space answers 200 with an empty JavaScript shell and the contracts repository path 404s live site for deployment tooling and a Solidity podcast, not a pods product. The contracts repository does not 404: orcaprotocol/contracts 301s to 0xmetropolis/contracts (https://github.com/0xmetropolis/contracts) , last pushed March 2023, in an organisation that now ships token-launch tooling. Re-checked 26 August 2026, when the old marketing domain metropolis.xyz (https://metropolis.xyz/) was also found parked and listed for sale. Den Multisig operations ov…vered by dig, not by an email.

What actually reduces the expo… by people paying attention. - Test the app, not the URL. A single-page app serves its shell before it knows whether it can fetch anything, so a broken product keeps returning HTTP 200 with the right content type indefinitely. Boardroom (/wiki/dao-governance/tooling/analytics/boardroom) 's front end errors on every data route while every link to it stays green. Liveness has to be checked by loading the thing and looking, or by calling the service it depends on; a status code cannot see it. The wider pattern is visible a…/tooling/analytics/boardroom) , hasving had to say out loud that it has no plan to deprecate, now errors on every data route of its public app while its API keeps answering (checked 22 August 2026). Discontinuity is the normal …layer, not an exception in it.

A measured cohort Between Feb…the tools looked notable, and notability (/wiki/policy/notability) is correlated with having rais…vered by dig, not by an email.

Topic What happens to a DAO wh…cepts/analysis/how-daos-fail) · The machine-readable DAO (/wiki/dao-governance/concepts/analysis/machine-readable-dao) Cohort checked 5 August 2026 (method and results below)

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 (https://github.com/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 (https://github.com/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 (https://github.com/charmverse/app.charmverse.io) is not archived, last pushed 18 October 2025. Syndicate Investment-club framework Pivoted out of the category. syndicate.io (https://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 (/wiki/dao-governance/tooling/treasury/den) 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.

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 (/wiki/dao-governance/tooling/frameworks/llama) Treasury and governance framework Gone. llama.xyz returns no DNS A record at all, and llamaxyz/llama (https://github.com/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 (https://github.com/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 (https://github.com/charmverse/app.charmverse.io) is not archived, last pushed 18 October 2025. Syndicate Investment-club framework Pivoted out of the category. syndicate.io (https://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 (/wiki/dao-governance/tooling/treasury/den) 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.

Topic What happens to a DAO when a tool in its governance stack shuts down, is parked, or pivots away Also called Vendor discontinuity, front-end risk, tooling rot, orphaned infrastructure Applies to Any DAO (/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) whose decisions, records or permissions pass through third-party software Failure classes Dead interface (recoverable) · dead hosted record (lossy) · live contract with a dead maintainer (dangerous) Related The DAO tooling stack (/wiki/dao-governance/tooling/dao-tooling-overview) · DAO service providers (/wiki/dao-governance/concepts/analysis/dao-service-providers) · How DAOs fail (/wiki/dao-governance/concepts/analysis/how-daos-fail) Cohort checked 5 August 2026 (method and results below)

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 (/wiki/dao-governance/concepts/analysis/dao-service-providers) , 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 (https://github.com/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 (https://github.com/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 (https://github.com/charmverse/app.charmverse.io) is not archived, last pushed 18 October 2025. Syndicate Investment-club framework Pivoted out of the category. syndicate.io (https://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 (/wiki/dao-governance/tooling/treasury/den) 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 (/wiki/dao-governance/tooling/voting/tally) 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 (/wiki/dao-governance/frameworks/zodiac) that still holds a role on a treasury Safe (/wiki/dao-governance/tooling/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 (/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) .

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 (/wiki/dao-governance/concepts/analysis/dao-service-providers) is selected through a scored public process, funded by a proposal, and renewed by another one. Delegate payrolls and governance operating costs (/wiki/dao-governance/concepts/analysis/dao-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 (/wiki/dao-governance/concepts/voting/proposal-lifecycle) .

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 (/wiki/dao-governance/tooling/membership/hats-protocol) , Zodiac (/wiki/dao-governance/tooling/frameworks/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 (/wiki/dao-governance/tooling/frameworks/aragon) dissolved its association and refocused on a product, Coordinape (/wiki/dao-governance/tooling/treasury/coordinape) sunset its app, Superfluid (/wiki/dao-governance/tooling/treasury/superfluid) deprecated a major interface, and Boardroom (/wiki/dao-governance/tooling/analytics/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 (/wiki/foundations/what-is-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 (/wiki/governance/proposals) and the ballots (/wiki/governance/voting) . 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 (https://github.com/llamaxyz/llama) — archived repository, last push 16 August 2024. - charmverse/app.charmverse.io (https://github.com/charmverse/app.charmverse.io) — unarchived repository, last push 18 October 2025, product host no longer resolving. - otterspace-xyz (https://github.com/otterspace-xyz) — GitHub organization; the contracts repository referenced by the product no longer exists. - syndicate.io (https://syndicate.io/) — current product positioning after the pivot away from investment-club infrastructure. - Den documentation (https://docs.onchainden.com/overview/den) — 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).

Topic What happens to a DAO when a tool in its governance stack shuts down, is parked, or pivots away Also called Vendor discontinuity, front-end risk, tooling rot, orphaned infrastructure Applies to Any DAO (/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) whose decisions, records or permissions pass through third-party software Failure classes Dead interface (recoverable) · dead hosted record (lossy) · live contract with a dead maintainer (dangerous) Related The DAO tooling stack (/wiki/dao-governance/tooling/dao-tooling-overview) · DAO service providers (/wiki/dao-governance/concepts/analysis/dao-service-providers) · How DAOs fail (/wiki/dao-governance/concepts/analysis/how-daos-fail) Cohort checked 5 August 2026 (method and results below)

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 (/wiki/dao-governance/concepts/analysis/dao-service-providers) , 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 (https://github.com/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 (https://github.com/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 (https://github.com/charmverse/app.charmverse.io) is not archived, last pushed 18 October 2025. Syndicate Investment-club framework Pivoted out of the category. syndicate.io (https://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 (/wiki/dao-governance/tooling/treasury/den) 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 (/wiki/dao-governance/tooling/voting/tally) 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 (/wiki/dao-governance/tooling/frameworks/zodiac) that still holds a role on a treasury Safe (/wiki/dao-governance/tooling/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 (/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) .

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 (/wiki/dao-governance/concepts/analysis/dao-service-providers) is selected through a scored public process, funded by a proposal, and renewed by another one. Delegate payrolls and governance operating costs (/wiki/dao-governance/concepts/analysis/dao-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 (/wiki/dao-governance/concepts/voting/proposal-lifecycle) .

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 (/wiki/dao-governance/tooling/membership/hats-protocol) , Zodiac (/wiki/dao-governance/tooling/frameworks/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 (/wiki/dao-governance/tooling/frameworks/aragon) dissolved its association and refocused on a product, Coordinape (/wiki/dao-governance/tooling/treasury/coordinape) sunset its app, Superfluid (/wiki/dao-governance/tooling/treasury/superfluid) deprecated a major interface, and Boardroom (/wiki/dao-governance/tooling/analytics/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 (/wiki/foundations/what-is-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 (/wiki/governance/proposals) and the ballots (/wiki/governance/voting) . 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 (https://github.com/llamaxyz/llama) — archived repository, last push 16 August 2024. - charmverse/app.charmverse.io (https://github.com/charmverse/app.charmverse.io) — unarchived repository, last push 18 October 2025, product host no longer resolving. - otterspace-xyz (https://github.com/otterspace-xyz) — GitHub organization; the contracts repository referenced by the product no longer exists. - syndicate.io (https://syndicate.io/) — current product positioning after the pivot away from investment-club infrastructure. - Den documentation (https://docs.onchainden.com/overview/den) — 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).

Topic What happens to a DAO when a tool in its governance stack shuts down, is parked, or pivots away Also called Vendor discontinuity, front-end risk, tooling rot, orphaned infrastructure Applies to Any DAO (/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) whose decisions, records or permissions pass through third-party software Failure classes Dead interface (recoverable) · dead hosted record (lossy) · live contract with a dead maintainer (dangerous) Related The DAO tooling stack (/wiki/dao-governance/tooling/dao-tooling-overview) · DAO service providers (/wiki/dao-governance/concepts/analysis/dao-service-providers) · How DAOs fail (/wiki/dao-governance/concepts/analysis/how-daos-fail) Cohort checked 5 August 2026 (method and results below)

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 (/wiki/dao-governance/concepts/analysis/dao-service-providers) , 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 (https://github.com/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 (https://github.com/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 (https://github.com/charmverse/app.charmverse.io) is not archived, last pushed 18 October 2025. Syndicate Investment-club framework Pivoted out of the category. syndicate.io (https://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 (/wiki/dao-governance/tooling/treasury/den) 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 (/wiki/dao-governance/tooling/voting/tally) 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 (/wiki/dao-governance/frameworks/zodiac) that still holds a role on a treasury Safe (/wiki/dao-governance/tooling/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 (/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) .

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 (/wiki/dao-governance/concepts/analysis/dao-service-providers) is selected through a scored public process, funded by a proposal, and renewed by another one. Delegate payrolls and governance operating costs (/wiki/dao-governance/concepts/analysis/dao-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 (/wiki/dao-governance/concepts/voting/proposal-lifecycle) .

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 (/wiki/dao-governance/tooling/membership/hats-protocol) , Zodiac (/wiki/dao-governance/tooling/frameworks/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 (/wiki/dao-governance/tooling/frameworks/aragon) dissolved its association and refocused on a product, Coordinape (/wiki/dao-governance/tooling/treasury/coordinape) sunset its app, Superfluid (/wiki/dao-governance/tooling/treasury/superfluid) deprecated a major interface, and Boardroom (/wiki/dao-governance/tooling/analytics/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 (/wiki/foundations/what-is-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 (/wiki/governance/proposals) and the ballots (/wiki/governance/voting) . 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 (https://github.com/llamaxyz/llama) — archived repository, last push 16 August 2024. - charmverse/app.charmverse.io (https://github.com/charmverse/app.charmverse.io) — unarchived repository, last push 18 October 2025, product host no longer resolving. - otterspace-xyz (https://github.com/otterspace-xyz) — GitHub organization; the contracts repository referenced by the product no longer exists. - syndicate.io (https://syndicate.io/) — current product positioning after the pivot away from investment-club infrastructure. - Den documentation (https://docs.onchainden.com/overview/den) — 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).