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.
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)
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)
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, though the company’s own timeline dates it to 2019, when it was announced (Tribute Labs); Flamingo (NFTs), Neptune (DeFi), Neon and Noise followed. The size of the family depends which page of that site you read: the story page says the communities coordinated over $200M in assets, while the about page says 20+ DAOs and over $150M across 300+ projects. The current roster lists nineteen DAOs and Neptune is not among them. 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.
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 was switched off, and the manner of it is more precise than an abandoned domain. Every architecture link in the README points at tributedao.com, which is also the repository’s declared homepage, and that host serves nothing: the apex carries no address record, so all 24 of those links are dead, and the Internet Archive’s last capture is 13 April 2026. The domain itself is maintained, though. It still carries Google mail records and an SPF entry and its registration runs to March 2027, and openlaw.io, the older brand, is in exactly the same state. What ended the site was a pair of commits: on 24 June 2026 the CNAME files binding the domain to GitHub Pages were deleted from the documentation and UI repositories, and the documentation repository was archived two seconds later (commit).
That makes the durability lesson the opposite of the one first drawn here. The documentation is not lost: the same site, all 194 pages of it, is still published at openlawteam.github.io/tribute-docs-website, deep pages included, and swapping the host into any dead README link resolves it (example). It survived because a static-site generator had built it into a repository, and it died on the web only where it depended on a domain the company chose to stop pointing. The durability question is therefore not whether a company keeps renewing a domain – this one did – but whether the documents sit at an address that does not depend on the company pointing it anywhere.
The same organisation is still shipping on the other side of the pivot: openlawteam/gate, created on 13 April 2026, is an AI pull-request reviewer, and the GitHub account now displays as TributeLabs. The framework is retired; the team is not.
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, DIVEST, METADATA (rewriting the caper’s own token metadata), 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: it opens only to a member who has cast a ballot, the only way a member earns soulbound vote tokens, and pays a share set by the same earned weight that governs their votes – so a holder who has never voted has no exit at all, not a zero-value one, however much they bought on the curve. 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.
CNAME deletions read on 19 September 2026.