---
title: "Llama"
url: "https://caper.network/wiki/dao-governance/tooling/frameworks/llama"
updated: 2026-08-09
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Llama

|  |  |
| --- | --- |
| **Category** | Onchain governance and access-control framework (Solidity / Foundry) |
| **Built by** | Llama — a DAO service provider whose [GitHub organisation](https://github.com/llamaxyz) dates to 12 November 2020 |
| **Framework launched** | Repository created 10 January 2023; first instances deployed on-chain 19 August 2023 |
| **Status** | 🔴 Wound down — llama.xyz resolves to nothing, and all 52 of the organisation's public repositories are archived (last push anywhere, 16 August 2024) |
| **Still deployed on** | Ethereum, Optimism, Arbitrum, Base, Polygon, Blast, Zora — [one factory address](https://etherscan.io/address/0xFf5d4E226D9A3496EECE31083a8F493edd79AbEB) on every chain |
| **Measured adoption** | 21 instance creations across the three chains readable this run; ~14 distinct organisations |
| **Audits** | Three [Spearbit](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit.pdf) reviews and one [Code4rena](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Code4rena-Audit.md); the last is [v1.1.0, January 2024](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit-3.pdf) |
| **Licence** | MIT |
| **Related** | [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity), [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), [Hats Protocol](/wiki/dao-governance/tooling/membership/hats-protocol), [OpenZeppelin Governor](/wiki/dao-governance/tooling/voting/openzeppelin-governor) |

**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](/wiki/daos/lending/aave-dao) in particular; its repository list still reads as a record of that work, from [the Aave treasury dashboard's ETL](https://github.com/llamaxyz/aave-etl) through [an escrow between Friends With Benefits and Gamma Strategies](https://github.com/llamaxyz/fwb-liquidity-provisioning) to [the Gitcoin–Radicle Public Goods Alliance](https://github.com/llamaxyz/gtc-rad-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](/wiki/dao-governance/concepts/analysis/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](/wiki/dao-governance/tooling/treasury/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](/wiki/dao-governance/tooling/membership/hats-protocol) for the role-as-token idea and [Zodiac](/wiki/dao-governance/tooling/frameworks/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](https://etherscan.io/address/0xFf5d4E226D9A3496EECE31083a8F493edd79AbEB) — 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](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit.pdf), [Code4rena](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Code4rena-Audit.md), a second Spearbit in August 2023, and [a third for v1.1.0 in January 2024](https://github.com/llamaxyz/llama/blob/main/audits/Llama-Spearbit-Audit-3.pdf). All four reports, and the framework's own [documentation directory](https://github.com/llamaxyz/llama/tree/main/docs), are still readable in the [archived repository](https://github.com/llamaxyz/llama) — 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](https://etherscan.io/address/0x585ebAC736B9d9A8Ee26C7A9fDa7a3987b4ff517), whose Uniswap proposal work has [its own repository](https://github.com/llamaxyz/def-uniswap-proposal) in the same organisation; MYSO; Daylight; and [Towns Mainnet](https://etherscan.io/address/0x343998c7056f75341C434E4db39A8be99A5EA4B4).
- **Base (7).** [Moonwell](https://basescan.org/address/0x9Ea8D23f0221A46152dF67097184C701899553B7), Socket, River, Drakula, Daylight, plus the launch-day Llama and Demo instances again.
- **Arbitrum (9).** [Perennial](https://arbiscan.io/address/0x635DE406f437911BCefFE6973CeD931A4ceb6cce), 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](/wiki/dao-governance/tooling/dao-tooling-overview) 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](/wiki/dao-governance/concepts/analysis/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](/wiki/governance/execution) 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](/wiki/foundations/what-is-a-caper) for the shape of that split.

## References

All figures on this page were read directly on 9 August 2026. [The llamaxyz GitHub organisation](https://github.com/llamaxyz) — 52 public repositories, every one flagged archived, latest push anywhere 16 August 2024. [llamaxyz/llama](https://github.com/llamaxyz/llama) — the framework repository, archived, MIT, created 10 January 2023. [LlamaFactory on Ethereum](https://etherscan.io/address/0xFf5d4E226D9A3496EECE31083a8F493edd79AbEB) — 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.