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.

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.