hollab.eth

Demo

About

# Hollab — product description Minimalistic on-chain Holacracy: verifiable structure and governance outcomes on-chain; coordination and content off-chain. --- ## The problem Organizations running on-chain face **three coordination systems that rarely compose**: 1. How people divide and own work 2. How AI agents participate in that work 3. How money moves in response to decisions Today, authority structures live in Notion pages and wikis — easy to dispute, hard to audit, and opaque to other smart contracts. DAOs tried to fix this by putting governance on-chain but defaulted to **token voting as the primary mechanism**, then bolted on informal delegation (e.g. ENS Working Groups, Aave service providers, Lido’s multisig committees). The result: - Deliberation quality depends on how many informed token holders show up on a given day - Structural authority stays **unverifiable** - **Every** decision — including operational ones — tends to get routed through a vote --- ## The solution **Hollab** is a minimalistic on-chain Holacracy framework. It gives organizations a **credible, tamper-proof record of who has authority to do what**, governed through a structured constitutional process, with **token-holder oversight as a configurable layer on top** — not the foundation. ### On-chain vs off-chain The core design is a strict split. **Only commitments go on-chain. Coordination stays off.** **On-chain** (verifiable, permanent): - Organizational structure: circles, roles, memberships - Role definitions: purpose, domains, accountabilities - Governance outcomes: adopted or rejected - Elected role assignments and authority boundaries **Off-chain** (coordination, content, discussion): - Meeting facilitation flow - Proposal content and objection deliberation - Tactical triage and day-to-day discussion - Informal coordination nuance Holacracy (the organizational framework this derives from) already defines distributed authority: roles with explicit purpose, domains, and accountabilities, organized into circles, evolved through **Integrative Decision-Making (IDM)**. What it lacked was a substrate that makes that structure **verifiable** and **programmable**. Hollab is that substrate. **AI agents are first-class participants** — not assistants bolted on the side. They hold roles, raise tensions, own projects, and join meetings under the same process constraints as humans. A **`HOLLAB.MD`** interface contract standardizes how any agent instance plugs into a circle’s authority structure. --- ## The process · · · ### 1. Create an organization Sign in, state your mission. That’s it — you have an org with an **anchor circle** on-chain. Name is optional; you can decide it together later. ### 2. Invite members Bring in the people who will do the work. Each member gets a **wallet-linked identity** in the org. ### 3. Governance huddle — define how you work Run a **governance meeting** to shape the org’s structure. Members propose roles through **IDM** — present a tension, clarify, react, test objections, adopt. In this first huddle you might: - Create roles: *Lead Dev*, *Designer*, *Community Lead* - Elect a **Facilitator** and **Secretary** - Create a **Community circle** — an open circle where token holders (supporters, users, collaborators) can participate in the org’s governance ### 4. Tactical huddle — align on what to do first Run a **tactical meeting** to triage and commit to first actions. This isn’t governance (no structural changes) — it’s the team getting aligned. Projects and next-actions might include: - Create a website - Set up visitor tracking - Set goal: 100 unique weekly visitors (OKR) - Decide on the organization’s name ### 5. Community joins An external collaborator buys the governance token and joins the **Community circle**. They now have: - Visibility into the org’s structure, roles, and decisions (on-chain) - A structured channel to propose ideas — same tension-driven process, not a Discord free-for-all - Voting power on proposals that affect the community ### 6. Community and org govern together The community member proposes: *“Add a capybara to the landing page.”* The proposal goes through **IDM** in the Community circle. If the org has `daoVoteRequired` enabled, the org’s internal circles **and** the community token holders both vote. The capybara gets its day in court. --- **The full loop:** create an org → structure it through governance → align through tactical meetings → grow a community → govern together — on one framework.

How it's made

Hollab is an on-chain Holacracy framework — a pnpm + Turborepo monorepo with Solidity contracts (Foundry), a Ponder event indexer, and a Vite + React UI connected via Dynamic. Contracts (packages/contracts, Solidity 0.8.28 + Foundry): Two layers — the Holacracy stack (CircleRegistry, RoleRegistry, GovernanceProcess, GovernanceMeeting) and the DAO stack built on OpenZeppelin (GovToken with ERC20Votes, HolGovernor, TimelockController, AccessManager). OrganizationFactory deploys ERC-1167 clones of all three Holacracy contracts per org, then calls HolGovernorFactory to wire up the DAO layer and ENSSubdomainRegistrar to register <orgname>.hollab.eth pointing to the org's governor — all in one transaction. Meeting components (TacticalMeeting, GovernanceMeeting, ActionVoting) are deployed separately via MeetingComponentsFactory — kept separate to stay under EIP-170's 24 KB contract size limit, and to allow multiple component sets per org (e.g. one per circle). GovernanceProcess state machine (7 states): proposals move Draft → Active → Integrating → Adopted, with side exits to Withdrawn, Discarded, or Escalated. Twelve change payload types cover the full Holacracy spec: CreateRole, AmendRole, RemoveRole, CreatePolicy, AmendPolicy, RemovePolicy, MoveRole, Election, and four WithRefs variants that attach content pointers. Objections have their own 6-state machine (Raised → Testing → Valid/Invalid → Resolved/Abandoned), allowing the facilitator to invalidate unconstitutional objections without blocking the proposal. CircleTreasury wraps OpenZeppelin's TimelockController — circle leads hold PROPOSER_ROLE to schedule operations, the elected facilitator holds CANCELLER_ROLE to veto, and EXECUTOR_ROLE is open so anyone can trigger execution after the delay. The treasury accepts ETH via receive() and ERC-20 via depositToken(), with syncFacilitator() keeping the canceller role aligned with the current elected facilitator. Escalation path: when GovernanceProcess.escalateToDAO() is called, it creates an on-chain governor proposal on HolGovernor whose calldata is abi.encodeCall(GovernanceProcess.executeEscalatedProposal, (proposalId)) — so a successful token-holder vote + timelock delay directly triggers structural execution with no intermediary. The hacky part — logs as ledger: Meeting coordination (IDM steps, objection rounds, reaction passes) is never written to storage — only emitted as events. Only the final structural outcome (CircleRegistry, RoleRegistry) hits storage. This keeps governance affordable and keeps deliberation off the permanent public ledger. For richer content, the ContentRefs pattern lets callers attach off-chain blobs: submitProposalWithRefs and raiseObjectionWithRefs accept arrays of (fieldNameHash, ContentRef{contentHash, DataVisibility}) pairs stored on-chain as _proposalContentRefs[proposalId][fieldHash]. Visibility is an enum — Public, OrgEncrypted, RoleEncrypted — so the chain proves what was adopted without exposing the content to everyone. Ponder indexer (apps/hollab-indexing): 30+ event handlers across 9 files feed 25 schema tables covering organizations, circles, roles, policies, proposals, objections, meetings, outputs, checklist items, metrics, treasury deposits, join requests, and tensions. MeetingComponentsFactory emits MeetingComponentsDeployed on each deployment; Ponder's config uses that event's parameters to dynamically register the new clone addresses — no manual indexer reconfiguration needed when a new org deploys. Frontend (apps/hola-modern): React + Vite, reads org state from indexing-client (typed GraphQL wrapper over Ponder), sends transactions via viem. Dynamic handles wallet auth and surfaces the org's ENS name in the topbar.