Llama was an onchain governance and access-control framework for smart contracts, and — separately — the name of the firm that built it. The firm spent 2021–2022 as one of the better-known DAO service providers, writing and shepherding proposals for Aave in particular; its repository list still reads as a record of that work, from the Aave treasury dashboard's ETL through an escrow between Friends With Benefits and Gamma Strategies to the Gitcoin–Radicle Public Goods Alliance. In January 2023 it turned the pattern it had been implementing by hand into a product: a framework for organisations that need to delegate narrow, revocable authority over a treasury rather than put every action to a token vote.
The firm is gone. This page is not about that — the shutdown, and the general problem it belongs to, are covered on DAO tooling discontinuity, where Llama is one of a measured cohort. What is documented here is what the framework did, who actually ran one, and what happened to those deployments after there was nobody left to maintain them.
Roles, not token weight
Most onchain governance in this period was token-weighted: your influence is your balance, and every executable action passes through the same proposal queue. Llama started from the opposite premise. Membership of a Llama instance is a non-transferable NFT — a policy — and the policy encodes which roles the holder has. Permission is then a specific triple: a role, a target contract, and a function selector. A policyholder does not have "voting power"; they have the right to call this function on that contract, and nothing else.
Action execution rules are modular. Rather than one quorum for everything, an instance attaches a strategy per permission, and the framework ships five: relative-quantity quorum, relative-holder quorum, relative-unique-holder quorum, absolute quorum, and absolute peer review. The same instance can therefore require a full role-wide supermajority to move the treasury while letting a two-of-five peer review approve a parameter change, without either rule leaking into the other.
Funds are held in LlamaAccount contracts belonging to the instance, with a delegation-aware variant for governance tokens the treasury holds in other protocols — the same problem Safe-based treasuries solve with modules. The design goal, stated in the repository, is programmatic control of funds: an approved action is a call the contracts make, not an instruction a multisig is trusted to carry out. The nearest live comparisons today are Hats Protocol for the role-as-token idea and Zodiac for modular execution rules bolted onto an existing treasury.
How an instance is put together
Everything is deployed from a single LlamaFactory, which sits at 0xFf5d4E22…AbEB — the identical address on all seven supported chains, the signature of a deterministic deployment. Each instance the factory creates is a LlamaCore (the action queue and execution engine), a LlamaPolicy (the role NFTs and the permission set), and an executor that performs approved calls. The strategy and account logic contracts are shared singletons the instances point at, so a new organisation deploys a small amount of code rather than a full framework. A read-only LlamaLens helper exists purely to make instances legible to interfaces, and two governance scripts batch the common multi-step administrative changes.
The framework was reviewed four times before its last release: Spearbit in June 2023, Code4rena, a second Spearbit in August 2023, and a third for v1.1.0 in January 2024. All four reports, and the framework's own documentation directory, are still readable in the archived repository — which matters more than it sounds, because the hosted docs site went with the domain.
Who actually deployed one
Because every instance creation emits an event from a known factory address, the adoption question has an exact answer rather than a marketing one. Reading the factory's decoded logs on the three chains whose public explorers answered this run — Ethereum, Base and Arbitrum — gives 21 instance creations, and resolving each instance's on-chain name gives roughly fourteen distinct organisations. Several appear on more than one chain, which is one deployment decision rather than several.
- Ethereum (5). Llama's own instance and a "Demo", both dated 19 August 2023 — the framework's first day live; the DeFi Education Fund, whose Uniswap proposal work has its own repository in the same organisation; MYSO; Daylight; and Towns Mainnet.
- Base (7). Moonwell, Socket, River, Drakula, Daylight, plus the launch-day Llama and Demo instances again.
- Arbitrum (9). Perennial, RabbitHole, a LI.FI test instance, three separate Socket deployments, Daylight, and the launch-day pair.
That is a real but small install base, and it is worth reading honestly in both directions. Fourteen organisations is more than a failed product usually gets, and several — Moonwell, Socket, Perennial, the DeFi Education Fund — are substantial. It is also far below the scale at which a framework becomes infrastructure other people build on, which is the outcome the tooling market of that period was competing for.
The framework outlived the company
The most interesting entry in that census is the last one. The Towns Mainnet instance was created on 3 March 2025: roughly six and a half months after the final commit to any Llama repository, and around four months after llama.xyz stopped serving a page at all. Somebody deployed a production governance instance from a framework whose authors had already left, and it worked, because a factory on an immutable chain does not know or care whether its maintainer still exists.
This is the concrete case of the failure class DAO tooling discontinuity calls the dangerous one — a live contract with a dead maintainer — and it cuts both ways. On the good side, nothing was taken away: existing instances kept executing, the code is MIT-licensed and readable, the audit reports survived in the repository, and the on-chain record needs no vendor to be reconstructed. What did stop is everything that was not on-chain. There is no interface, no hosted documentation, no upgrade path, and no one to write a patch: the security review a prospective adopter would rely on is frozen at v1.1.0 in January 2024, and any vulnerability found after that date has no maintainer to report it to. An organisation adopting a framework in this state is choosing to become its own maintainer, whether or not it notices at the time.
How Caper approaches this
Caper's answer to the same exposure is structural rather than promissory, and it is visible in the contract split. Each caper's state tier — the treasury, the proposal record and the ballots — is deployed once and never migrated, so nothing about a caper's existing decisions depends on a maintainer being around. The logic tier that carries the pricing and execution plumbing can be replaced, but only by an UPGRADE proposal passed by the $CAPER caper's own members and routed through the protocol's registry — there is no admin key that upgrades it and no vendor whose disappearance either freezes it or lets it change. The trade Llama's instances face, between an immutable contract and a maintained one, is put to a vote rather than settled by whoever is still employed. See what a caper is for the shape of that split.
References
All figures on this page were read directly on 9 August 2026. The llamaxyz GitHub organisation — 52 public repositories, every one flagged archived, latest push anywhere 16 August 2024. llamaxyz/llama — the framework repository, archived, MIT, created 10 January 2023. LlamaFactory on Ethereum — the same address on all seven deployment chains; instance counts and dates come from its decoded LlamaInstanceCreated logs on Ethereum, Base and Arbitrum, and each instance's name from an eth_call to its LlamaCore. The domain's disappearance is dated from the Internet Archive's index for llama.xyz, which records HTTP 200 responses through 10 October 2024 and 404s from 30 November 2024 onward.