Accounting for DAOs

Responsibility Accounting has existed since the 70s. It could find a lot more traction in DAOs than it ever did in traditional corporations.

March 2, 2022 | 4 minute read

Of all the traditional organizational practices, accounting is maybe the most rigid and top-down. Meaning it doesn’t generally vibe well with DAOs. But DAOs need accounting practices and they need them ASAP. Luckily a system exists that is perfect for DAOs - maybe even better for DAOs than traditional organizations: Responsibility Accounting.

If you google Responsibility Accounting, you’re going to find a bunch of complex systems, specialized software, and articles filled with accounting jargon that may or may not make sense.

Ignore all of that.

At it’s core, Responsibility Accounting is this:

Every line item – every profit, expense, or investment – has an individual who is responsible for it.

There are two reasons why this is important:

  1. It’s transparent and measurable
  2. It incentivizes effectiveness

Transparency

When a budget is created, it should be tied to a set of KPIs. Those KPIs need not necessarily be financial, but the goal is to calculate the “return on investment” of that budget.

Krause House recently passed a proposal that funds two members to moderate and hype a channel in their discord. The goal: to make it the go-to place for banter during an NBA game. The metrics: number of original posts (not posted by the two moderators) per day. One of the incredible and still under-leveraged things about DAOs is that everything is transparent including, in this case, the number of times the moderators post and the number of original posts per day (the key metric).

This sort of accounting is even more transparent when it goes on-chain. A product team could easily create a set of Dune dashboards that track their spending (i.e. paying out bounties) and tie that to their user acquisition (new wallets signing a transaction with an authentication token).

It’s impossible to hide how tokens are moving on mainnet. So at the end of a term, you either reached your goal or you didn’t. The accounting is transparent which means it is easily auditable by the community.

Effectiveness

The purpose of Responsibility Accounting is to calculate the return on investment at the most local level possible. Given a set of resources (i.e. two people months and $300 USDC), what is the most expedient way to achieve the goal (make the #nba-banter channel a common destination for in-game banter).

It is now up to the team to decide the most effective way to achieve that goal. The decision is local. And they’re incentivized to achieve the goal as effectively as possible to improve their effective hourly rate.

Pushing decision making to the most local level possible is a key component of success for DAOs. Calculating the ROI at the most local level possible too makes these small groups accountable to the rest of the DAO.

How to Implement Responsibility Accounting

Creating a Budget

First, a budget is allocated.

I love the way Krause House handles this, where community members are able to submit proposals to a vote based on the needs they see and projects they want to take on.

We’ve adopted something similar at Cabin. The City Council decides on top-level goals and a budget for a season. Then any individual or team can propose a quest that helps move the organization closer to those goals.

Pet3rpan also recently outlined a good approach whereby subDAOs are formed and funded every three months. Their KPIs are reviewed every three months after operating and their subsequent budgets are approved based on their performance.

Regardless of the path your DAO follows, a budget should be allocated, tied to a set of metrics, and a person or team made responsible for it.

Measuring

It’s not enough to set metrics. They have to be tracked and ideally they are reported autonomously (as opposed to self-reported).

Over the lifecycle of a budget you want to measure:

  1. The current state (so that you can later calculate the ROI)
  2. Progress and improvement
  3. The end result

How you do this will depend a lot on what the goal is. And the goal doesn’t have to be (nor should it necessarily be) financial. That’s a bad vibe when we’re talking about a community. The Krause House proposal is a great example: they’re calculating the number of posts per day in a channel as a proxy for engagement.

Reviewing

The budget should conclude with some sort of review period where the performance of the team is shared back with the rest of the group, perhaps in a town hall. This is where your DAO’s culture becomes more important than your accounting.

Someone either hit their KPIs or they didn’t. What happens next depends a whole lot on how your DAO views these metrics and the act of hitting them. Some teams intentionally set very ambitious goals with the expectation that they will most likely fail to meet them. Others set more measurable objectives with the intention they should at least be met, but ideally exceeded. This is a call you and your DAO get to make.

The important part here is that you review the performance, calculate the ROI, and over-communicate the results.

My take is that all data is useful data. If someone did hit their KPIs then you got what you wanted (i.e. the goal itself), but that’s not all the data you have: you also got an insight into how to get what you want (i.e. how the goal was achieved). Both of these factor into a team’s performance.

Concluding Thoughts

A key component of DAOs is that decision making and execution gets pushed to the people closest to the problem, with hard and soft accountability tools to ensure they’re being a good steward:

Centralization

Responsibility Accounting is one such hard accountability measure. A project is created and decentralized to an individual or small group that is then responsible to the rest of the organization for their return on investment.

Whether a goal is met or not, there should be a collective effort to mine the experience for everything you can. By doing this, your DAO can build up your own pattern language for decentralized execution.