DAOs were a new, experimental answer to the question of “how do we coordinate in virtual worlds?” In some ways, answering whether they did this well wasn’t directly my aim, since this is still largely an experiment after all. What I was interested in was simpler: if all this data is public, can we use it to govern better?

This question led to building TreasureCorp: a tool that consolidated on-chain data for a DAO and attempted to extract meaningful insight from it. It surfaced questions about how governance worked in practice: Who proposes the most ideas? What was the success rate? What’s the spread of consensus? How is voting power distributed? How many people actually participate?

At first glance, this was just another set of metrics for DAO members to ingest, but it helped answer questions about the health of their governance processes. If every proposal passes with a strong majority, that could mean genuine consensus, or it could mean members didn’t feel comfortable dissenting, or that they didn’t fully understand what they were voting on. If the same group consistently initiates proposals, or turnout is low relative to the number of members, then you have an engagement issue.

Similarly, for treasury metrics: What’s a holistic view of the DAO’s assets across all wallets and chains? What’s the inflow-to-outflow ratio? In addition to these metrics, there was also the ability to run simple what-if scenarios: Given the current burn rate, what’s our likely runway in five years? What happens to our treasury if token X’s price drops 30%?

The purpose of all these metrics was, broadly, transparency. Individually, these metrics are useful. Together, they were meant to give a clearer picture of the system as a whole. If the aim was to work towards a better way of coordinating, then making these activities transparent and digestible to the average DAO member was the approach I took. My assumption was straightforward: more transparency would lead to clearer governance, which in turn meant more accountability, which should allow for better decisions to be made. The assumption didn’t quite hold.

What I learned

In building TreasureCorp, I learned a few things. First, despite all the data around the decision itself being on-chain, everything in the lead-up to it, or perhaps more importantly after it, isn’t. The discourse around a proposal (or lack thereof), the influence certain individuals hold (which can’t be quantified with a voting power metric), and most importantly, the outcome after a proposal passes. Did it ever have the intended impact? Not all data can be meaningfully captured. The social layer matters just as much, if not more.

Second, DAOs lower the barrier to entry. This meant that both the burden and upside of deliberation and decision-making were distributed across more people. In theory, this should lead to broader involvement in decision-making: more voices, more input, better outcomes. In practice, it often led to the opposite. Decision fatigue set in. People either followed how others voted or didn’t vote at all. Participation dropped, and with it, the idea of decentralised governance that most DAOs set out to achieve. In reality, a small group often ended up carrying most of the weight. At this point, governance starts to drift towards theatre. While the mechanisms were there, the substance behind them weakened.

Building challenges

In terms of building the product, the main challenges I found were twofold.

First, there is no standard DAO. Governance structures vary. Treasury solutions vary. On-chain data, despite being queryable, remained fragmented across explorers, APIs, contracts, and chains, all of which needed to be queried differently. This made it difficult to build a one-size-fits-all product.

Building TreasureCorp meant stitching together a data ingestion and processing pipeline that relied on external APIs, dealt with gaps in coverage, and attempted to serve data in real time without breaking under rate limits or cost constraints.

Second, there was a product problem. Different DAOs had different problems they wanted to address. For MoonDAO, it was about making grant funding transparent, linking treasury funds to projects down to individual contributors. For UnlockDAO, it was about tracking budgets and reporting spend across sub-teams. This raised the question: how do you make a product general enough to be sufficiently useful across many use cases, while avoiding becoming a custom solution for a unique use case that only a single DAO needs insight into?

Reflection

Looking back, transparency was a broad stroke I used to address a whole host of underlying issues: token voting failure, plutocracy, informal power, governance theatre, and more. Ultimately, the scope was too large. But it did help surface questions. It did capture the imagination of DAO members, both in terms of rethinking their governance and treasury structures and realising they needed better tooling to support them. But it didn’t necessarily lead to any form of action being taken.

What building TreasureCorp did give me was a better question than the one I started with: how do we make governance systems accountable, not just visible?