Llama

Llama was an onchain governance and access-control framework for smart contracts, and – separately – the name of the firm that built it. In 2021–2022 the firm worked as a DAO service provider, 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.

River Protocol acquired the firm in November 2024. Its end, and the general problem it belongs to, are covered on DAO tooling discontinuity, where Llama is one of a measured cohort. This page covers what the framework did, who deployed one, and what happened to those deployments once nobody maintained 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; the hosted docs site went with the domain.

Who deployed one

Every instance creation emits an event from one factory address, so adoption can be counted exactly. 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.

Creating an instance is not using one: several of the addresses above hold their deployment events and nothing after them, so a count at the factory measures decisions to try the framework, not organisations that governed with it. For how the framework compares with others in the tooling market, see Aragon alternatives.

What happened to the deployments

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; the factory accepts deployments with no maintainer behind it. 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.

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; 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. The framework passed to a customer, and what still runs is that customer’s own governance.

A live contract with an absent maintainer is the failure class DAO tooling discontinuity calls the dangerous one. 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. Everything off-chain stopped. 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 the framework now becomes its own maintainer.

How Caper approaches this

A caper's treasury, proposals and ballots live in a part of the contract that is published once and cannot be changed, so a caper's past decisions do not depend on anyone maintaining the software. The part that handles trading and execution can be replaced, either by a vote of the members of the $CAPER caper or by the protocol operator. What is a caper describes the design, and Execution covers what a passed proposal can do.

References

The repository figures on this page were read 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.