DAO Governance on Argumentree: From Open Discussion to Recorded Verdict

The treasury vote nobody actually discussed

The proposal asked for a meaningful slice of the treasury. It passed. Participation was a single-digit percentage of eligible tokens, three large holders supplied most of the weight, and the deliberation — such as it was — lived in a chat channel moving at four hundred messages a day, two forum threads, and a voice call with no minutes. A month later, when the funded team missed its first milestone, a member asked the obvious question: what exactly did we think we were approving, and who examined it? Nobody could answer. Not because nobody had examined it — two members had raised precisely the risk that materialized — but because their objections were messages 214 and 380 in a channel nobody would ever scroll back through.

This is the standard failure of DAO governance, and it is not a voting problem. On-chain voting works: it is transparent, tamper-proof, and final. What fails is everything before the vote — deliberation scattered across media that don't accumulate, arguments that the median voter never encounters, and a reasoning record that evaporates the moment the vote closes. Vitalik Buterin's critique of coin voting makes the deeper point: the vote aggregates preferences, and when the preference-forming step is broken, the aggregation faithfully records a poorly-formed consensus.

The fix is structural: run the deliberation as an argument tree — one place, one claim under examination, every argument attributable and challengeable, the community's verdict visible before anything goes on-chain, and the whole record permanent. This tutorial walks that workflow as it runs today (Part 1), then previews the integrated proposal flow on the roadmap (Part 2). For why the tree model fits token-governed communities generally, the blockchain governance hub makes the full argument; for governance principles beyond tooling, see DAO governance best practices.

Setup: the DAO Governance use case

One decision matters before anything else: create the tenant with the DAO Governance use case. Use-case selection happens at signup, and DAO Governance is the one use case with meaningfully different capabilities — it is what the governance-specific features in this tutorial key off. A workspace created as, say, Corporate Strategy will not show them regardless of plan tier. Each DAO gets its own tenant — its own subdomain, membership, and visibility rules — so multi-community setups stay cleanly separated.

• ✓Checkpoint: tenant created with DAO Governance selected as the main use case; members invited before the first governance topic opens.

Part 1 — the deliberation flow, live today

The workflow runs from question to recorded verdict in six steps. Everything in this section works now, on any DAO-use-case tenant:

1. 1Open the governance topic as a root claim. Not a headline — a decidable statement: "The DAO should fund the infrastructure grant at the requested amount for two quarters." A claim that can be supported, attacked, and eventually judged is what makes every later step work. Checkpoint: the root is a statement someone could disagree with, not a topic label.
2. 2Build the case — by hand or by extraction. Two routes, same destination. Members author pro and con arguments directly, sorted per category, each argument one claim with its evidence. Or — usually faster for a debate already underway — paste the existing discussion text and let AI extraction convert it into a proposed argument tree, which members review and refine rather than transcribe. Messages 214 and 380 become visible nodes instead of buried scrollback. Checkpoint: every substantive point from the scattered discussion has a node; duplicates merged.
3. 3Run the AI check. The AI validation pass flags weak spots — unsupported claims, duplicated arguments, missing counterpoints — before members spend attention on them. Treat it as a lint pass on the case, not a judge: it tightens the tree; it decides nothing. Checkpoint: flagged arguments fixed, merged, or consciously kept.
4. 4Rate — and read the root-node verdict. Members rate the arguments; the aggregation rolls up to the root, giving the community a visible verdict on the question before anything goes on-chain. This is the tutorial's payoff step: instead of discovering sentiment through the vote itself, the DAO sees where it stands — and where it is split — while there is still time to deliberate. Checkpoint: broad participation in rating, not just the usual voices; splits identified.
5. 5Challenge, negotiate, evaluate — the three chains. A member who doubts an argument opens a Q&A chain on it: question, author's answer, follow-up, answer — four turns, complete, attributable. Two factions backing different positions run a Compromise chain — a proposed middle position, negotiated on the record, which either produces an amended position or documents precisely where the split lives. A formal assessment runs as a Review chain. All three replace the four-hundred-message channel with dialogues someone can actually read. Checkpoint: every contested argument has a completed chain; no live objection exists only in chat.
6. 6Record the outcome. When the DAO's binding on-chain vote concludes — in whatever mechanism the DAO uses — the result is recorded on the tree next to the deliberation that produced it, and the dashboard keeps the topic as a permanent, linkable record. The month-later question — what did we think we were approving, and who examined it? — now has a URL. Checkpoint: outcome recorded; the tree linked from wherever the DAO announces results.

Part 2 — the integrated proposal flow (roadmap)

The workflow above starts manually: someone opens the topic, someone pastes the discussion. The integrated proposal flow closes that gap — a proposal enters the system automatically, and the full lifecycle runs in one place:

1. 1Import — a new proposal is picked up automatically and lands as a governance topic.
2. 2Extraction — the proposal text is converted into an argument tree, ready for member review.
3. 3Deliberation — Q&A chains challenge the case; Compromise chains negotiate amendments between factions.
4. 4Vote — the deliberated proposal is put to a vote within the flow.
5. 5Review — a closing Review chain evaluates the outcome and the process, feeding the DAO's next iteration.

The chain-specific groundwork is where the per-DAO wiring lands: the Ethereum, Arbitrum, Cardano and Polkadot governance pages cover what structured deliberation looks like against each ecosystem's governance model.

Honest limitations

• ✗The binding vote is not here. Ratings and the root verdict are deliberative signals; the decision that moves treasury funds is the DAO's own on-chain mechanism, and this workflow does not change that.
• ✗Structure doesn't fix turnout by itself. A readable tree lowers the cost of informed participation — a voter can absorb the case in minutes instead of scrollback hours — but it cannot make token-holders care. Pair it with the DAO's own participation incentives.
• ✗Token-weight dynamics live outside the tree. Argument ratings are per-member; they do not model coin-weighted power, and a whale outvoting the deliberation on-chain remains possible. What the record changes is that it happens visibly, against a documented case.
• ✗Part 2 is roadmap. Automatic import and the integrated vote require per-DAO, per-chain wiring on request — do not plan a launch around them being self-serve.
• ✗Deliberation at scale has failure modes of its own — cascades, brigading, polarization. Independence discipline (rate before reading the distribution) matters here as everywhere; see when crowds go wrong.

Practical lessons

• ✓Extract, don't relitigate. If the debate already happened in chat, paste it — extraction turns hours of scrollback into a reviewable tree in minutes, and the discussion's authors see their points represented rather than restarted.
• ✓Put the tree link in the vote announcement. The single highest-leverage habit: every on-chain vote links its deliberation record, so a voter is one click from the full case. Reasoning nobody can find is reasoning that doesn't exist.
• ✓Run the Compromise chain before the vote, not after the fork. A visible split at the rating step is the cue — negotiate the amendment while the proposal can still change.
• ✓Keep one topic per decidable question. Omnibus proposals produce omnibus trees nobody can judge; split them, and let each root carry its own verdict.

The month-later question, answered

Rerun the treasury proposal through the workflow. The scattered debate got pasted and extracted on day one; the two members' objections are nodes with ratings, not messages 214 and 380. One objection survived a Q&A chain with the proposers and pushed a Compromise chain that added a milestone gate to the proposal before it went on-chain. The root verdict showed a divided community — visibly, before the vote, at a link every voter saw in the announcement. And when the milestone question came a month later, the answer was a URL: here is what we approved, here is who examined it, here is the risk we saw and the gate we added because of it. The vote was always on-chain. Now the reasoning is somewhere too.