Overview

• What it was: DAOhaus makes open-source tools that let a group run a Moloch DAO, an on-chain organisation with a shared treasury that decides by vote, without writing code. In 2022 it began rebuilding its app on new contracts, Moloch v3, and I stayed with the work through 2024.
• My role: core contributor in research, design and coordination, from January 2022.
• What changed: the v3 admin app and summoner shipped; the team had a research and testing practice, shared documentation and a regular public conversation; and through a DAO of DAOs, member DAOs voted on DAOhaus's own governance.

I joined DAOhaus's core team in January 2022, as it began rebuilding its app on Moloch v3, after about a year as a part-time contributor. My job was keeping about twenty people across development, design and community pointed the same way. I turned meeting notes into shared strategy, drew the maps that showed how the teams fit together, and worked on the new app's UX and UI, its testing and its documentation. In public, I hosted HAUS Party, our weekly salon, and wrote for the blog. And I represented Moloch DAO in UberHaus, later PublicHaus: a DAO of DAOs whose members voted on how DAOhaus itself was governed.

The problem

DAOhaus was a decentralized team. About twenty contributors across front end, back end, design, project management and content decided things in calls, chat threads and forum posts, and the v3 rebuild changed both the contracts and the app at the same time. Work moved fast in many places at once, and the reasons behind decisions were easy to lose.

The product had its own version of the same problem. Moloch DAOs are powerful and hard to read. One DAO had been flooded with spam proposals. A proposal that called an outside contract could hide what it would actually do. New users kept asking the same basic questions before they summoned a DAO. v3 added more power still: shamans with administrative control, treasuries that members could or could not ragequit from (leave the DAO with their proportional share of the funds), delegated voting, and tokens a DAO could make transferable or not. Each new capability was something else to explain.

How I worked, across three layers

The interface: research, testing and documentation

In March 2022, with a fellow contributor, I set up a UX Research & Testing workstream for the rebuild. Its goal, in the words of our first meeting: "We require some concrete evidence - that is battle tested - to justify our decisions." We kept it small: a project rather than a standing team, a Tuesday sync, a testing column on the v3 board, and a nine-step method that ran from identifying users and listing our assumptions, through interviews, personas and a problem statement, to finding the riskiest assumption, testing it and iterating. Testing treated the documentation as the hypothesis: "Docs are the hypothesis, testing is the experiment."

It matters what the workstream did and didn't decide. Several design calls came before it. The summoner had already been merged from two modes into one configurable form, so people could see their whole DAO on one page. What the workstream added was a shared list of questions to test across summoning, the treasury, membership and proposals, and a method for testing them. Around it, research ran in a few forms:

• Summoning workshops with DAO operators and would-be summoners, held weekly in spring 2022 on the existing app while v3 was being designed.
• Internal alpha testing. In September 2022, one session caught a proposal marked ready to pass although it hadn't met quorum, no sign in the interface that a vote was still processing, and long titles pushing a proposal's link out of its card.
• Short interviews at a community workshop (MCON2). One builder said ragequit made a DAO's budget hard to plan, because the treasury could shrink at any time. One operator wanted new members to grow into governance power gradually. One community lead said their hardest problem was keeping contributors engaged.

The clearest line from research to the shipped app is a team one. From our first design meetings in January 2022, the notes kept returning to proposals whose contracts couldn't be verified: "Need a warning for unverified contracts." The core-UI work that summer asked for "a bigger warning". v3 shipped it. When the app can't decode what a proposal will do on-chain, it says so, twice, in plain words:

I also worked on the v3 documentation, and in 2023 I recorded user-guide walkthroughs, among them making a proposal and sending tokens from the treasury. Through 2023 and 2024 the work carried on in the admin app: usability fixes and better support for the DAO's Safe treasuries.

The story: notes into shared strategy

I took notes at the meetings and turned them into shared strategy: write-ups the whole community could read, so that people in a design call and people in a development call were working from the same picture. I drew maps and diagrams that helped the teams coordinate, communicate and collaborate. My main focus was community building, developer relations and outreach; knowledge management and coordination with other DAOs were part of the same job.

Spring 2022 gives a concrete example. To bring the Rangers, the group behind our articles and events, into the same workflow as the developers building v3, I set up the Rangers' project boards to match the developers', drew diagrams of how work moved through them, and wrote a first backlog of tasks. The Rangers then tracked their progress on those boards in their weekly sync. When a weekly contributor discussion about how to organise the DAO's Discord channels spun out of control, I drew a map of how DAOhaus, its core contributors (Warcamp) and UberHaus fit together.

By May the limits were clear. In my own assessment that month, the testing workstream "did not seem to be able to hold the higher-level sense making that was 50% of the initial motivation". So I sketched a separate workstream that would gather what was happening across the DAO and present its internal debates as short, neutral summaries and diagrams. As far as the record shows, that one stayed a proposal; the boards are what ran.

In public, I hosted HAUS Party, our weekly community salon on web3, crypto and DAOs, where we interviewed guests, and I wrote for the DAOhaus blog.

The incentives: a DAO of DAOs

DAOhaus also tried to share its own governance. UberHaus, later PublicHaus, was a DAO of DAOs: member DAOs each sent a delegate. I was Moloch DAO's representative there and attended most, if not all, of its meetings. I was directly involved in planning a federated ecosystem, in which the member DAOs vote on how DAOhaus itself is governed: an experiment in truly decentralized governance. It went beyond the plan: the member DAOs did vote on DAOhaus's own governance.

What we built

v3 shipped as two open-source apps: the summoner, shown above, which creates a DAO, and the admin app, where its members propose, vote, manage membership and hold a treasury. Between them, a group could run a Moloch v3 DAO from start to finish without writing code.

From contract calls to forms

A Moloch v3 DAO is a set of contracts, and every decision it makes ends in a contract call. Calling those contracts directly means encoding each call by hand. We put each one behind a form.

Summoning is a single transaction that sets up the DAO, its voting and non-voting tokens, its rules, its shamans and its first members. The summoner lays all of that out on one page, and each field says in a sentence what it does: how long votes stay open, what share of voting power a proposal needs to pass, whether members may transfer their tokens, and that the DAO can change these later by proposal.

Once the DAO exists, nearly everything it does is a proposal, offered as a menu of plain requests. The basic ones are a signal (a question put to a vote, with nothing moving on-chain), a request for voting or non-voting tokens, a token swap in which someone offers tribute in exchange for DAO tokens, and a payment from the treasury. The advanced ones change the DAO itself: its voting and grace periods, quorum, minimum retention, sponsor threshold and proposal fee; whether its tokens can be transferred; and its shamans, outside contracts given admin, manager or governance powers, picked from a list of permission levels rather than set in code. A member can be removed by turning their voting tokens into non-voting ones, so they keep their share but lose their vote. For anything the menu doesn't cover, a DAO can connect to another app through WalletConnect or build a multi-step transaction, and the app decodes what that proposal will do, or warns, as shown above, when it can't.

Whatever it does, a proposal follows the same steps: a member with enough voting power sponsors it, members vote, a grace period gives anyone who disagrees time to leave, and then it can be executed. Each step is a button on the proposal.

Ragequit is the guarantee underneath all of it. A member who disagrees can leave with their proportional share of the treasury, through a two-step form: choose how many voting and non-voting tokens to give up, then which treasury tokens to take. A DAO can also hold more than one Safe. The treasury is the one members can ragequit from; others, such as an operations budget, sit outside it.

Each of those forms stands for a call that moves money or changes who holds power, so the words around the fields carry the weight: what a quorum is, why there is a grace period, what a shaman can do. That is where our research, documentation and testing met the product.

Proposals and voting

Every proposal shows where it is: needs a sponsor, voting, grace period, ready to execute, passed, failed, cancelled or expired. The detail view decodes what the proposal will do on-chain.

Members

The members page leads with what governance turns on: each member's voting power, who they delegate to, and their voting and non-voting tokens. A member's profile shows their share of each treasury token, which is what ragequit would pay out.

Treasury

v3 let a DAO hold more than one Safe. The safes page marks which treasury members can ragequit from, and shows the funds the DAO holds apart for operations.

Outcome

• v3 shipped as the DAOhaus admin app and summoner, on a shared component library that other teams could build with.
• Not everything made the first release. An early v3 scope kept the member list and profile the same as v2 and left out delegation and transfers of voting and non-voting tokens. Delegation was on the member profile by the time the admin app was built in late 2022; transferring DAO tokens came in 2024.
• The app kept improving after launch, with usability fixes and better Safe treasuries through 2023 and 2024.
• The team worked from shared ground: a research and testing practice, documentation that doubled as the test plan, user guides, written strategy anyone could read, and a weekly public conversation.
• The federated vote happened. Member DAOs voted on DAOhaus's own governance through UberHaus, which became PublicHaus and later funded community research such as Creator Collector Reciprocity.

Reflection

The testing workstream did what it was built to do at the level of the product: it gave a distributed team a shared list of questions, a method and a cadence. The harder work sat above it. Turning notes into shared strategy, mapping how the teams fit together, and representing one DAO inside another were all ways of keeping a decentralized team legible to itself, and that is what this study is about.

I also learned how much of UX research in a DAO is shared work: setting up the cadence, writing things down, keeping design, documentation and testing in step. "Docs are the hypothesis, testing is the experiment" is still how I'd start a new team.