The Tribute DAO Framework was the contract set that came out of the first legal DAO. Where DAOhaus packaged Moloch as a no-code app and Aragon built a general-purpose permissioning kernel, Tribute took the specific machinery that The LAO needed to operate as a member-directed venture fund and generalised it into swappable modules. Its own README calls it “our team’s tribute to the MolochDAO ecosystem” – the same team had helped build Moloch v2, and Tribute is the attempt to keep Moloch’s guarantees while making everything around them replaceable. (openlawteam/tribute-contracts)

It is included here as a frozen framework rather than a live option. The repository has been archived read-only, its last release was v2.10.0 on 17 October 2024, and the documentation site every link in it points to has since gone off the internet entirely. That combination – working code, unreachable docs – is the specific way DAO infrastructure tends to die, and it is worth reading as carefully as the design.

What it was trying to fix

The README states five problems with the DAO frameworks of 2020, and every design decision below traces back to one of them: lack of modularity, which made DAOs hard to extend or upgrade; rigid voting and governance mechanisms, which blocked experimentation; high costs, especially for on-chain voting; single-token structures, which fused economic and governance rights that a venture DAO needs separated; and lack of NFT support, which kept the model away from collector and art DAOs. The pitch was assembly rather than configuration – “low cost and easy to develop components that can be assembled like lego blocks.” (Tribute DAO Framework README)

Core, adapters, extensions

The architecture separates state from behaviour more strictly than Moloch did. Three core contracts hold the DAO itself: DaoRegistry tracks all state changes and is the only thing that can be mutated directly; CloneFactory deploys a DAO as a cheap clone; DaoFactory creates and initialises one and registers its modules. Core contracts never reach out to the world – information flows inward only.

Behaviour lives in adapters, twelve of which shipped, chosen to make the framework feature-compatible with Moloch v2: Configuration, Distribute, Financing, GuildKick, Managing, OffchainVoting, Onboarding, Ragequit, Tribute, TributeNFT, Voting and Withdraw. Adapters hold no DAO state of their own; they call into the registry. Extensions – Bank, NFT, ERC20 and Executor – sit alongside them for capabilities several adapters share, keeping the registry itself small.

Holding it together is an access-flag ACL. Each adapter is granted only the flags it needs, checked by a hasAccess modifier on the registry: REPLACE_ADAPTER, SUBMIT_PROPOSAL, UPDATE_DELEGATE_KEY, SET_CONFIGURATION, ADD_EXTENSION, REMOVE_EXTENSION, NEW_MEMBER. A module without the flag simply reverts. The consequence that matters politically: because Managing holds REPLACE_ADAPTER, a Tribute DAO can vote to change its own rules – onboarding terms, voting method, exit conditions – without redeploying. Modularity is a governance surface, not just an engineering convenience.

Two adapters carry the Moloch inheritance directly. Ragequit preserves the exit right – burn your units, take your proportional slice – and GuildKick preserves the members’ power to remove someone. The Tribute and TributeNFT adapters are the framework’s namesake: a prospective member offers ERC-20 tokens or an ERC-721 asset to the treasury in exchange for internal units, which is exactly how a venture or collector DAO admits capital. (MolochVentures/moloch)

Who ran on it

Tribute’s deployments were the OpenLaw family of venture and collector DAOs rather than a broad third-party ecosystem. The LAO went live in April 2020 as a Delaware LLC running a Moloch v2 fork; Flamingo (NFTs), Neptune (DeFi), Neon and Noise followed, and Tribute Labs’ own account puts the assets coordinated across those communities at over $200M. That is both the framework’s strength and its limit: it was built to the requirements of accredited-investor, legally-wrapped investment DAOs, and it was maintained by the company that operated them rather than by a framework community of its own.

How it went quiet

Tribute Labs published its own trajectory, and it does not run through the framework. OpenLaw began in New York in 2017; The LAO launched in 2019; the company rebranded to Tribute Labs in 2022; from 2024 it moved to “the intersection of AI agents and autonomous organizations”; and in 2025 it launched ADIN, an AI-native venture platform, which is what the site now describes. (Tribute Labs, “Our Story”)

The contract repository tracks that shift. The final release is v2.10.0, published 17 October 2024 – the 48th and last of the npm package first published in May 2021 – and the repository is now archived, GitHub’s read-only state, which is a maintainer’s explicit statement rather than an inference from commit dates.

The documentation did worse. Every architecture link in the README points at tributedao.com, which is also the repository’s declared homepage. That domain no longer resolves at all – no DNS record, not a redirect or a parked page – and the Internet Archive’s last successful capture of it is 13 April 2026. The code, the tests and the published package survive on GitHub and npm; the explanation of how any of it fits together survives only in the archive. For anyone evaluating a framework, the durability question is not just whether the contracts still work but whether the documents that make them usable are hosted somewhere that outlives the company’s domain renewals.

How Caper approaches this

Tribute and Caper sit on opposite sides of one question: should an organisation be able to vote to change its own rules?

Tribute’s answer is yes, and its Managing adapter is the mechanism – a passed proposal can replace the module that governs onboarding, voting or exit. Caper’s answer is no. A caper’s executable proposals are limited to five kinds fixed in the contract: PAYOUT, INVEST, VOTE (casting one caper’s ballot in another’s), DIVEST, and UPGRADE – and UPGRADE is not a per-caper lever at all. The contract asserts that an upgrade option may only appear on the $CAPER caper itself, because one platform-logic swap applies to every caper at once. An individual caper cannot rewrite its curve, its fee, or its exit rule by voting, however large its majority.

The exit rule is where the difference bites hardest. Moloch-style ragequit, which Tribute inherits, pays any member their proportional slice on demand. Caper’s exit is deliberately narrower: exit() requires a non-empty bucket of the caper’s soulbound vote tokens and aborts without them, and the payout share is the canonical vote weight (t·v)/(V·T) – so a holder who never voted has no exit at all, not a zero-value one. Tribute buys flexibility and accepts that the terms a member joined under can be voted away; Caper fixes the terms and accepts that they cannot be tuned to a particular organisation’s needs.

References

• OpenLaw / Tribute Labs, openlawteam/tribute-contracts – source, README architecture, archived status, MIT licence.
• npm, tribute-contracts – release history; v2.10.0 published 17 October 2024.
• Tribute Labs, tributelabs.xyz – company timeline, DAO family, ADIN.
• Internet Archive, tributedao.com capture, 13 April 2026 – the framework documentation, which is no longer served live.
• MolochVentures, moloch – the v1/v2 contracts Tribute builds on.