Llama is best understood as an onchain governance-and-execution framework, not merely a role-badge system. Its official materials consistently describe a system that combines access control, proposal flow, approval/disapproval, and programmatic execution.
The repo README frames the protocol around three linked primitives: non-transferable NFTs for access control, programmatic control of funds, and modular strategies that define action-execution rules. That is already a stronger constitutional surface than standard token-voting dashboards.
The LlamaPolicy contract makes the design more concrete. Policy positions are non-transferable ERC-721 tokens, and the contract explicitly states that those policies assign roles for creating, approving, and disapproving actions. Permissions are attached to (target, selector, strategy) combinations rather than to vague organizational titles.
The LlamaCore contract shows that governance is modeled as an action pipeline: actions are created, approved, disapproved, queued, and executed. This is useful because it means Llama is not just recording preferences; it is a control plane for callable operations.
The same core contract tracks authorized strategies, scripts, action guards, policyholder nonces, and executor wiring. That suggests Llama’s real design question is not “who voted?” but “who may initiate, ratify, delay, veto, or execute which class of call under which strategy?”
Llama’s strategy architecture matters. The published deployment table includes multiple quorum variants such as relative-quantity, relative-holder, relative-unique-holder, and absolute-quorum strategies. That indicates governance logic is meant to be swapped and specialized rather than baked into one universal token-voting model.
The README’s deployment table shows Llama factory and logic contracts deployed across Ethereum, Optimism, Arbitrum, Base, Polygon, Blast, and Zora. So this is not just an experimental repo; it is infrastructure intended for repeated multi-chain instantiation.
Relative to many DAO tools, Llama shifts attention from forum signaling toward executable constitutional design. The reusable insight is that action permissions, strategy modules, and execution guards can centralize authority even when governance branding emphasizes broad participation.
Mechanism lens
Llama is a strong comparison case for the governance-tooling cluster because it sits between:
role-based access control
proposal-and-execution governance
timelock / guard design
modular constitutional infrastructure
Relative to Hats Protocol, Llama appears more centered on executable governance flow and permissioned action pipelines, while Hats is more legible as a generalized roles-and-authorities layer spanning many integrations.
Relative to Safe + Zodiac-style governance stacks, Llama packages more of the constitutional logic directly into a dedicated governance framework rather than leaving most authority structure to a custom multisig/module assembly.
The reusable insight is that non-transferable role tokens plus strategy-gated callable permissions form a higher-resolution governance primitive than token voting alone.
Whitepaper / litepaper status
No canonical standalone whitepaper or litepaper surfaced in this pass.
The strongest primary materials were the public repos and the core contract source itself.
Best current classification: onchain governance framework / executable access-control infrastructure / modular action-approval system.