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 LlamaInstanceCreated logs on the five chains whose public explorers answer gives 43 instance creations (Optimism 15, Arbitrum 9, Base 7, Polygon 7, Ethereum 5, read 19 September 2026), and resolving each instance’s on-chain name gives roughly fourteen distinct organisations on the three chains named below. 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.

Two caveats belong with that count, and the page originally carried neither. The first is arithmetic: an earlier read of this page covered only Ethereum, Base and Arbitrum, and missed the fifteen instances on Optimism and seven on Polygon, which together are half the install base. The second matters more. Creating an instance is not using one: several of the addresses below hold their deployment events and nothing after them, so an adoption figure counted at the factory measures decisions to try the framework, not organisations that governed with it.

The framework outlived the company

The most interesting entry in that census is the last one, and it does not say what this page first read into it. The Towns Mainnet instance was created on 3 March 2025, six and a half months after the final commit to any Llama repository and around four months after llama.xyz stopped serving a page. A factory on an immutable chain does not know or care whether its maintainer still exists, so the deployment went through. But the instance has never been used: its address carries its deployment events and no action in the eighteen months since, read on 19 September 2026. The same holds for Moonwell’s instance on Base, which this page previously cited as substantial adoption.

What still executes belongs to the acquirer. River Protocol, now Towns, announced on 1 November 2024 that it had bought Llama and would integrate its contracts into River, a fact the page was missing; Llama’s co-founder described the same transaction from the other side. The busiest instance in the whole census is River’s own on Base, which was still queuing and executing actions on 11 September 2026, and the only meaningful fork of the contracts is the acquirer’s. So the framework did not outlive its company: it was absorbed by a customer, and what kept running is that customer’s own governance.

A live contract with an absent maintainer is still the failure class DAO tooling discontinuity calls the dangerous one, 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, on two paths the registry's own authorisation table keeps separate: an UPGRADE proposal passed by the $CAPER caper's own members, which reaches the registry through a method gated to the live logic component rather than to any key, and an operator backstop held by the protocol admin badge. Both land through the same propose-then-activate timelock, whose length is fixed when the registry is constructed and has no setter, so neither the badge nor a vote can shorten it; the Stokenet registry the site runs on was constructed with a delay of zero. What is absent is not the operator but the vendor: no maintainer's disappearance either freezes the tier 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. The instance census was re-read on 19 September 2026 across five chains, counting LlamaInstanceCreated at the factory and then each instance’s own logs; the acquisition is dated from River’s announcement of 1 November 2024.