Warcamp Workstream Commitment Allocation

Background and Problem

Historically, Warcamp has been organized as an umbrella DAO (Warcamp proper) and four subDAOs: the Magesmiths, Rangers, Paladins, and Alchemist circles. These circles are organized roughly by function, and many Warcamp projects and workstreams involve tight collaboration across circles.

That structure has worked well for the majority of Warcamp’s history, but there are several changes under way that are stretching its capabilities:

  • Contributor growth: Warcamp’s contributor base is expanding, and expected to continue expanding even further in the near future.
  • New contributors: Relatedly, we now have several new contributors who need to gain context.
  • Modularization: the DAOhaus platform is being re-architected to support more modular development.


These changes are revealing several tensions.

  1. Contributor onboarding is challenging because there are so many things happening and they are not very legible to those without existing context and connections.
  2. We often find ourselves having meetings with upwards of 20 people at once, which is neither an efficient use of people’s time nor an effective way to develop & disseminate the appropriate information to reach consensus.
  3. Our integrated structure does not match our desired modular platform architecture. This could create a problem if we “ship our org structure”.
  4. We find ourselves wanting a way to spin up cross-functional workstreams, but are hesitant to do so in a top-down fashion.
  5. Moving towards a modular cross-functional workstream structure threatens our unified compensation program.
  6. It is becoming harder to collectively hold each other accountable to the responsibilities we informally take on.

Idea: Workstream Commitment Staking

The foundation of this idea is that attention/effort/time (here-after referred to as “commitment”) is a scarce resource. One that we have explicitly built into our systems via the Commitment Compensation Track.

Instead of prioritizing projects by allocating financial budget top-down from the DAO, under this approach we would identify relevant projects by individual contributors allocating their commitment across workstreams that they or others have spun up.

The result has the potential to be a bottom-up means of…

  • prioritizing projects,
  • defining of contributor role(s) and responsibilities,
  • surfacing information about who is working on what

Also, it could create an organic, flexible, and fractal structure that naturally combines…

  • functional “centers of excellence” (akin to our current circles)
  • cross-functional workstreams (similar to the yeeter project)
  • individual tasks / responsibilities (eg note-taker or tweeter)

Potential implementation


  • Warcamp Commitment token (let’s call it $WCC here)
    • Each cycle, Commitment Track contributors get an amount of $WCC equalivalent to their commitment % for that cycle
    • Retroactive Track can allocate up to ==X== tokens at any given time, depending on where they are focused at that point
  • Workstreams. These can be almost anything, including…
    • functional groups (eg “Rangers”)
    • cross-functional workstreams (eg the yeeter project)
    • individual tasks or responsibilities (eg note-taker or PR spokesperson)
    • workstreams can be substreams of other workstreams


  • Contributors can stake $WCC on workstreams to signal their commitment to and involvement in that workstream
  • Contributors can unstake any number of $WCC from workstreams at any time, eg to switch to another workstream(s)
  • Contributors can permissionlessly create new workstreams at any time and at any granularity

Data Generated

  • Time x quantity of $WCC staked on each workstream
    • in total and for each contributor
  • Ideally some kind of dashboard to display this info

Contributor Compensation

  • Continues as-is in our flexible compensation program. Compensation continues to flow from Warcamp to contributors.
  • Staking data could be used as an input into coordinape evaluations

MVP implementation

We could simulate this at reasonable fidelity (though in a much more trusted way) in something like google sheets

Potential future enhancements

  • Bring in a financial funding component for double-opt-in workstream spin-up (similar to Govrn’s Outcome Coalitions concept)
  • Enable individuals (contributors or HAUS holders) to signal that it would be valuable for others to stake commitment on a particular workstream
  • Enable some kind of granular permissioning for workstreams to help ensure that contributors are a good fit for what they’re working on
  • Enable explicit fractal staking, ie staking $WCC on the Rangers workstream gives you Rangers Commitment tokens (say, $RC) to stake on substreams related to Rangers. This one is pretty intense :sweat_smile:


Likely benefits

  • allows us to maintain our current compensation structure
  • bottom-up prioritization of of warcamp workstreams
  • maintains contributor autonomy
  • bottom-up and dynamic contributor “role” definition
  • allows us to test this kind of staking mechanic for potential future externalization via conviction voting or something
  • clearly defines working groups

Potential challenges/drawbacks

  • need to think more carefully through how this should work for retroactive track contributors
  • doesn’t address HAUS utility/demand in the short run
  • could be fairly complicated to implement
  • probably a lot of other things I haven’t thought about

An alternative approach for the retroactive track is to have retro contributors stake on workstreams in retrospect. This would be more accurate, but would forgo some of the benefits of staking concurrently/prospectively, in particular visibility into who is working on what. Also, it would create further operational distinction between tracks, which is undesirable.

More thinking is needed here, though, so please chime in with your ideas!

1 Like

One thing to note is that this system could encompass holacracy-style roles, expressed as workstreams that individuals stake $WCC on and/or create

1 Like
  • Overall, I really like this proposed approach.
  • In particular, I appreciate the fact that it expressly expects contributors to have full agency to direct their own work and define roles/workstreams they engage in - rather than being defined by the roles or workstreams they join.
  • This allows us to cleanly deprecate the old system of Contribution From Circles, which has become largely vestigial since most of the DAO has moved to Commitment Track (esp for Alchemist, which have no retroactive contributors still active)
  • This could definitely be managed to start with as a spreadsheet or a collaboratively edited flowchart (eg, google sheets or lucidchart), edited maybe once or twice a month.
  • I also think this is a good forcing function to get contributors to think critically about where we’re spending our time and what’s actually the most valuable thing we could be working on
  • It also creates visibility / legibility for everyone to see what everyone is working on, which could hopefully promote some context-sharing-by-curiousity (eg “Oh, like nine people are working on this thing, I should probably go find out about it”)

This could be very powerful, but should be treated carefully.
As I see a natural progression, Version 1 of this framework asks contributors to allocate points according to what they think will be most valuable for them to do.

A version 2 could add a second allocation (every contributor gets SRC = to their WCC), that identifies what they think the most valuable work that needs to be done, across the DAO. This could do a lot to highlight areas of work that are being underserved, and guide contributors to

  1. take on those responsibilities that are recognized as needed but not being served (SRC > WCC)
  2. Or, lead contributors to move away from workstreams that aren’t being recognized as needed (SRC < WCC)
  3. Or, signal to contributors that perhaps some work needs to be done to share out the value of the workstreams they’re dedicated to - since it may not be obvious to folks not involved why something is critical, the benefits and risks, etc. (SRC < WCC)

That said, not worth setting up that scaffolding in detail until we’re happy with the first version


I like this, It addresses some of the issues I’ve been feeling. Like providing agency for an individual to pursue emergent initiatives.

A few other things that might be worth addressing here.

Ownership/responsibility - I think some kind of ownership role for new initiatives would be helpful, A role that has the responsibility to determine what further resources might be necessary. Potentially with some agency over the initiative to lead resources. Also may be responsible for requesting more budget when needed.

Communications - Some process of updates to the larger core team and for highlighting excellence within the circle (or blocks/problems) . Probably a responsibility of the lead ownership role. Also a shared repository, wiki or tool of notes/completed tasks/current needs of a work stream.

Profiling - although a members ‘stake’ will tell us a lot about what they are interested in. Some sort of self assignment of skills would be helpful for new members and new work streams.

Accountability - we need a way to see that people are doing what they say they are doing. If not what actions can be taken as a core team to help. may be a responsibility of the lead but also how to asses a lead

Life cycle - maybe the staking will highlight when an initiative should be shelved/sunset (basically no one stakes in it any more) we may want some process around retros in this case. Also if the larger core team sees a work stream as wasteful or dangerous, there may need to be some type of escalation to lower priority or signal concerns.


Just as another side to this, I personally haven’t felt this as a problem, but understand thinking about it now makes sense.

One of my main concern is how this structure will be reflected in Discord, are we keeping things in buckets there are we splitting everything out into work streams like the Raid Guild server? I personally find that structure pretty overwhelming, but that might just be me. For example, I think it would be vey difficult for the design team to not have a shared channel anymore and it’s just per work stream.

A few thoughts on some points, to have some counter arguments:

‘1 - Contributor onboarding is challenging because there are so many things happening and they are not very legible to those without existing context and connections.’

  • I’ll be curious how we’ll be able to structure this that simultaneously doesn’t put a lot of extra coordination burden on every work stream while providing enough context so a new contributor can understand walking in

‘2 - We often find ourselves having meetings with upwards of 20 people at once, which is neither an efficient use of people’s time nor an effective way to develop & disseminate the appropriate information to reach consensus.’

  • For me, the only meeting I’m in with 20+ people is the warcamp weekly. I don’t count Haus Party or Campfire because they don’t include important information dissemination or decision-making topics
  • We would need to find a way to not silo decisions that affect the entire group into meeting with just a few people. This might be in forum posts or whatnot, but wanted to note it. I worry that if something like the Warcamp weekly becomes a meeting where only a few attend the rest of the DAO no longer has a voice which I think it swinging things too far in the other direction
  • We could also look into a better method for us to come to decisions rather than roundtable debates as well - I’m wondering if this statement about meeting size is truly the underlying problem we need to address

‘6 - It is becoming harder to collectively hold each other accountable to the responsibilities we informally take on.’

  • There are a few notes here and there in this thread about accountability and tracking this. Of course I agree that if someone isn’t pulling the weight they said they were it should be addressed, but it does worry me a little as the language used can lead me to thinking that a lot more process and everyone watching each other type mentality could come into play. May be extreme to think that, but I wanted to note (maybe it’s my past toxic managers making me interpret that way)
  • There was talk of having a buddy system type thing to keep accountable to that didn’t materialize, I could see putting more structure around that idea

I like the direction this is going with concern about the complexity. We are growing. Although the rate of growth right now is manageable it could drastically increase at any time. Wen moon?

There are some basic haus keeping projects that could dramatically improve the onboarding experience without a major organizational overhaul.

  • Improving Discord structure and roles
  • Enhancing our documentation
  • Optimizing the on-boarding flow

Improvements in these areas would make providing new contributors context in a scalable and modular way easier.

These projects actually may provide use cases to test these Commitment Staking ideas but are kinda the dirty work that few are motivated to do. This surfaces an issue of incentivizing the effort that would have a better reward to risk ratio. It may be helpful for us to explore this deeper.

How can we account for the needs of the DAO? How can we visualize opportunities and obstacles?

I posit that the too many people in meetings problem is related to fomo and a not wanting to miss an opportunity to spend time with the super smart people in our community. This could be addressed with improved meeting notes and a consideration of recording allowing for asynchronous consumption. We could also have a time explicitly dedicated to bringing together a bunch of big brains and adjust the format accordingly. Monday’s Warcamp could serve this purpose with minor modifications.

Making a series of smaller adjustments hopefully enables us to experiment with the bigger ideas at play in a more intentional way.

We do need to find ways of making our attention/effort/time more composable. I agree this can be accomplished with project based workstreams and cross-functional teams. We need to determine how to strengthen and reinforce these concepts in our community with the existing work to be done. This alone will have significant benefits.

The “centers of excellence” slash current circles is something that if we can figure out could potentially have a large impact on the space. Establishing best practices and providing inspiration based on specialization. The Spotify model accomplishes this with Guilds.

I am excited about the idea of staking on workstreams. However, I think there is some foundational work that needs to be prioritized before effectively exploring this concept.

We should be mindful that estimation is hard. It improves with practice and restrospective learning but requires effort. We have not historically been good at tracking work to be done and organizing projects. Much of our time is reactive rather than proactive.

Maybe we can focus on getting the workstream concept up-to-speed prior to considering staking. How is a workstream defined? What are the requirements for creating a new workstream? How do we make it easy to flow between workstreams based on what individuals want to work on and where they may be able to add value?

We want to make sure the barriers to creativity remain low. Having too much process required prior to exploration may become a blocker and deterrent. Just a risk we should keep in mind and an opportunity to provide flexibility and time dedicated to jam.

Finding balance with all these concepts is not going to be easy. However, I think we have the right group to make progress on all of these fronts and inspire the bigger community.

Maybe it’s all meta and we move this forward with a Workstream Commitment Staking project.


This is an interesting concept! I have a few musings.

  • I can see how this is addressing the strain of rising contributor numbers within the framework of Circles that are perhaps already reaching the boundaries of their own internal accountability and coherency. Creating a more nimble and modular workstream system with some sort of interface where others can see what is being worked on in a dynamic way is a sensible replacement.
  • Is this staking a form of forecasting, task/time-tracking, or group organizing? It feels like it is all three (and probably more things), but each of those things has different user journeys and resulting workflows. They also have different problems they are trying to solve (predictability, accountability/transparency, cohesion).
  • This may increase the burden of onboarding because it is adding additional token actions and task tracking to a process where tasks/available work is already fairly obfuscated for new contributors, so I’m glad that making what tasks are available more clear is recognized as a source of existing tension. I think that should continue to be a central concern going forward, particularly for new contributors.
  • The more granular the tasks are, the higher I could see the admin burden being for people who wear many hats. I wonder if a good middle ground would be something in the spirit of “what do you expect will take up 75% of your time?” so that the focus never ends up on trying to predict (or constantly/retroactively adjust) staking for incidental tasks. For instance: if someone’s entire role in the DAO is note-taker, this makes sense as a stake for them. If someone just happens to be taking notes some of the time, tracking that perhaps shouldn’t be necessary.

This sounds like a great model for accountability in the commitment model. We might be able to leverage something like Sobol to coordinate around the shorter term goals within circles and how they relate to the DAOhaus wide goals. Would likely still need tracking to associate completion.

MetaFactory and it looks like Bankless have explored it:


Also want to highlight nestr

they are offering a similar value prop and have been building in DAO support and specifically integrations for the daohaus platform


This is a fantastic post and I am super glad this is the direction we are headed in.

The response and reflection here has sufficiently addressed my concerns, so I will only voice those things I am immediately concerned about when reading this proposal.

Emergence is an inherent piece of the culture at DAOhaus, so as you can imagine there is a relatively constant rate of new ideas/projects/workstreams that could be made available - for that I am left energized by the opportunity it presents us to make waves in this ecosystem, yet I am cautious about our own ability to keep up with communicating the changes such that new contributors who come through the funnel of discord anathema, along with documentation being misguided presents both an opportunity to improve as well as a risk to be cognizant of as we continue to progress as a collective and an ecosystem.

@e2t hit the nail on the head, highlighting immediate actions that we can take to improve:

  • documentation & support
  • discord role system & permissions
  • user / contributor onboarding UX

These are three issues that I am explicitly interested in improving. Circle leads can help me by determining what their needs are for onboarding new contributors - filling out this form here! - ClickUp forms

Some processes that I have begun thinking about in relation to onboarding that I will share:

  • Documentation needs to be updated immediately to reflect some hard processes that have been added to the discord, such as moonlight bot - and using the @warcamp-temp role to grant access to new contributors as well as the distinction for new contributors that if they have earned HAUS from a Coordinape epoch they can stake it, if not or the new contributor purchased HAUS, that will not be sufficient for making a member proposal!

  • Clarity needs to be added around the process of transition from the retroactive <> commitment compensation track, and there especially needs to be more breadth given to the different tracks, supporting linking processes across different sections or areas within the handbook

  • We have an opportunity to explore using an app called - app.otterspace.xyz. this could have the impact of facilitating a more seamless onboarding experience for everyone that comes to DAOhaus, where in order to gain access to the server a new member will receive a DM from the otterspace bot saying actions need to be taken before entering.

  • Once complete, the new member is added to the discord, where the leveling and roles are managed by otterspace and NFTs are used to gain access to new levels within the discord for taking certain actions that are deemed valuable. NFTs, referred to as badges are configurable by the DAO and can be composed with other apps - check out the deck for more!

  • Our focus toward onboarding needs not to just be our core contributor DAO, we also need to think about user acquisition, supporting the DAOs already on DAOhaus with new people, creating better support for new summoners to create their own DAOs, as well as think about the “contributor path” as it pertains to an individuals own set of priors - cultural values, skills, passion, as well alignment within or across the workstream/project/circle they want to contribute to. This led to the creation of the Discovery survey scaffolding that I am working on with @_jp

Over the next week or so, I will be focusing on creating some processes that can be referenced by existing contributors to help on-board new individuals, leveraging the aforementioned buddy-system to retain existing contributors as well as bring in new ones - (possibly incorporating a permanent and a rotating buddy that will help contributors to remain in sync with the work that everyone on a given project/workstream/circle is doing.)

The new contributor buddy-system will require attention from connectors, or the people responsible for supporting new contributors with everything they need to begin adding value in DAOhaus and be successful.

The process will likely vary for different contributor types, but these are the key components for onboarding new contributors into the DAOhaus ecosystem (assuming we preserve our existing structure and do not use otterspace):

  • join discord
  • self introduction (why you are here, how you found out about us, and what you would like to do)
  • connector makes initial contact in discord - points them to HAUS roles and drops a calendly link to meet with one of the connectors or offers to schedule a discovery call
  • connector has call with new contributor, uses a template script to provide a run-down on all of things DAOhaus: intro valuable resources, discord setup, opportunties to engage with community, potential tasks / bounties, and workstreams/projects/circles if deemed appropriate by connector. Connector also gains valuable information about the new contributor and collects any resources or data that the contributor provides.
  • connector then takes the appropriate measures to level up the contributor or support the contributor with additional materials for acquainting themselves with governance, compensation, etc.
  • once a minimum level of trust is established, meeting 2/3 of the trust requirements to be added, the connector can provide the new contributor with the @warcamp-temp role
  • connector is then responsible for being that new contributors POC, such that they are responsible for making sure that the new contributor is kept up to speed and is feeling confident about their transition into work at DAOhaus.
  • new contributors can request to change their connector by tagging @connector role in the DAOhaus discord or asking their connector to switch, switches should be encouraged and allow for new contributors to find their path.
  • more process here soon…

I will be iterating on this tomorrow and into the weekend. Thank you all -


These are great Ideas, Spencer. My only concern at the moment is that staking might create a popularity contest between workstreams. By this I mean that staking might derail some people from joining less 'sexy" groups/projects working on things that are just as important (if not more important) than the workstreams with the most staked tokens. Might be worth to consider creating some kind of additional incentive layer to get people to join less exciting projects in order to create more equal distribution between workstreams.

Also, a potentially effective management tool for something like this (visibility + also allows people to self assign) might be Zenhub.


I think a system like this would add a lot of benefit if it were set up properly and engaged with reliably, which would take practice.

I think there’s an important precursor to an attention-management system like this, and one of the fundamental building blocks for a self-managed organization like ours and that’s role-awareness. The idea being that any time you do work for the org, you are doing it from within a role.

That role can be implicitly or explicitly defined. Right now most of the roles are implicit (undocumented), or we could say there are 4 broad roles (Paladin, Ranger, Alchemist, Magesmith). But, I’m also sensing more granular roles within those categories that are not well-defined yet. For instance, I think Spencer is operating from some kind of Payroll role, which could be Paladin, but I would have to do a lot of work to extract the purpose and accountabilities of that role to make it explicit.

That information would be helpful in this context, especially if I were clear on my own roles and then we could have role-to-role engagement. It moves the conversation a half-step away from pure opinion and consensus which risks potential gridlock and poor/partial adoption of new initiatives like this one.

When we can talk about which roles are sensing the tensions, and which roles are taking on projects, this conversation would

  1. become more specific
    2)contribute to building “organizational memory” so all players, including newer ones can more easily track and engage with what’s going on
  2. Systems like this one proposed to track effort & attention & project focus would have an additional level of abstraction to operate within. A human can energize a role, and a role can engage with a workstream or project. Then, when the human changes their mind, leaves the role or leaves the org, the role remains and the organizational memory is intact.

This has me thinking about some potential phases that could be implemented. By breaking something big like this into phases, we have time to integrate concerns and also practice the new skills required to do this kind of thing.


Thank you, everyone, for your thoughtful commentary, ideas, and concerns! It’s heartening to see this much engagement in this format – makes me think that we need to be doing more long form communication.

After reading everyone’s feedback, I’d like to clarify a few things that I think will address some of the main challenges, and also respond specifically to some of the common concerns I’m seeing. I’ll also share some ideas for how this might be implemented in phases, plus an example.


“Workstream” is a flexible, catch-all concept

In this system, “workstream” is a very generic term. It encompasses basically anything contributors are spending their time on, and includes everything from functional circles associations, to cross-functional projects, to individual roles and tasks.

The benefit of that general approach is to allow each contributor to describe they are allocating their time/effort/etc at whatever level of detail is most appropriate for them. In other words, contributors can get as specific as they want to get. The approach allows them to weight the benefits of specificity against the admin/process overhead and complexity they are creating for themselves. See below for an example.

What is “staking”?

Eventually, I think it can be all three. But at first, it only needs to be a reflection of existing focus/attention.

In this sense, “staking” is kind of a misnomer. The relevant action is more like an allocation, which in the initial phases is merely an expression of how you are currently spending your time/effort/focus. Later, we can layer in more staking-like concepts, eg with formal accountability as well as some signaling mechanics. But for now, its easiest to think of it simply as allocation.

We don’t need a token

While doing this on-chain with a token has a number of benefits – mainly trustlessness and composability – it is not at all necessary. We can do this just as effectively using spreadsheets or potentially even one of the tools suggested in the thread (Zenhub, Nestr, Sobol, etc).

Common Concerns


I think an important first step towards improved accountability is visibility into what people are working on. If people can be relatively easily made aware of what others are working on without having to look over their shoulder, accountability can be applied informally/socially. That basic information also creates a substrate on which to add more formal accountability mechanisms later, if we deem appropriate.

Role-definition and awareness

I think a light version of this system can actually help surface the roles that are currently implicit within our DAO. I suspect this may drive better awareness of what those roles are, and help us be intentional about how we define roles.

Complexity and process overhead

I’m in full agreement here. The last thing we want to do is introduce a ton of process and administrative overhead. That said, I actually don’t think this needs to be very process heavy at all, especially at first.

What this system does not do is require anybody to list all the granular tasks they are working on. Rather, it allows them to identify what they’re focused on at whatever level of specificity they choose. In other words, it allows each contributor to choose the amount of process that’s right for them. See my example below for how this could work.

What about the “dirty” work?

This is a real challenge for our DAO right now. A future phase of this system where we start signaling what we think is valuable for others to work on may help incentivize contributors to take on my dirty work.

In the meantime, we can try simply listing out those things that are under-focused. The mere act of seeing something on a list to do may trigger somebody to take it up.

Implementation Phases

Phase 1: existing workstreams

  • Goal: surface existing circles, projects, and roles
  • Contributors allocate their $WCC points to the following:
    • Their existing circle(s), ie functional groups
    • Their existing projects (if they exist), ie cross-functional workstreams
    • Their existing roles – whether currently explicit or implicit (can be self-defined)
    • Where identified roles or projects fall within a circle’s purview, points are allocated to the lower level of grain.
  • Contributors can be as specific or generic as they see fit. It’s totally fine to allocate everything at the circle level if you don’t want to get into the nitty gritty of specifying your projects or roles.
  • No formal standards for how workstreams are defined

See below for an example using my (Spencer’s) circles, projects, and roles

Phase 2

  • get more concrete about how workstreams are defined and what information we use to describe them
  • start forming new workstreams, including
    • new cross-functional projects
    • newly identified roles
    • newly identified functional groups (circles)

Phase 3

Example (using my own “workstreams”)

My current commitment % is 90%, so I have 90 $WCC points. I allocate them as outlined in the table below.

Note that I got fairly specific in a couple places (primarily my various work within Paladins), but left other areas pretty generic. That includes non-role and non-project allocation to the circles in general, to represent miscellaneous and or as-yet-unspecified contributions I make to the circles.

This table took me only ~10 minutes to create, completely from scratch.

Workstream Type $WCC Points
RANGERS Circle 5
- PR spokesperson Role 15
- YAP DAO liaison Role 5
- platform and product strategy Role 7
- payroll facilitator Role 4
- coordinape facilitator Role 2
- compensation design Project 8
- workstream design Project 5
- partnerships Project 4
- revgen / HAUS value accrual Project 4
- treasury mgmt Project 4
Total 90

Sorry for the late response! I’m generally liking what I see here! Sounds like we’re going in the right direction.

The problem statements here are significant, present and multi-dimensional. I’d advocate that we narrow our focus on solving the root cause - achieving visibility and accountability of contributor bandwith . We should stay focused, make assumptions, simplify the experiment’s surface area and actually run it.


1. Segmenting and dividing my involvement into workstreams, projects and niche roles

This is because some roles and projects have not grown into new or existing workstreams yet. Also, some of these roles and projects could be shared across different functions (e.g. documentation)

In the pilot, I agree and think it’s good to start with Circles today, before going into projects and undefined roles. This helps us surface existing workstreams and move towards a first-look towards points allocation, instead of spending time over workstream design.

Suggestion: In the survey, we can ask contributors to categorize their involvement into 5 categories (Rangers, Paladins, Magesmiths, Alchemists, Weird Fit OR Others). The survey then asks for points estimation for each category, along with some follow-up questions.

Some of these follow-up questions can help us look at roles mapping and Circle formation/dissolution, but the main focus should be on a simple way to do points allocation. Beyond this, any role discovery questions / explorations should be done under UI369’s current initiative.

2. Allocating “points” to indicate my time / bandwith / effort spent on each of the above

It is hard to define and abstract one’s involvement with DAOhaus into points as everyone has different ways of interpreting their involvement. What should the points be abstracting? Time spent? Mental/emotional bandwith? Actual outcomes?

This is made more complicated by how different contributors have different affinity and ability towards different types of tasks. As humans, these subjective experiences will make it difficult to have an objective measure / judgement of points (e.g. what if there’s something that requires very little time but is something that requires a lot of mental / emotional effort to complete?)

Suggestion: I’d suggest to choose 1 point allocation model rather than a general one. Since we have been using commitment level (i.e. time spent) for contributor compensation, I suggest we use this same model for our pilot run. In the survey, after asking for their different categories, we will ask for the time spent per Circle indicated.

This should help us move forward with commitment level (i.e. time spent) as the model, having some understanding on how contributors spend their commitment levels (time). If we’d like to understand other ways to interpret and translate contributions into points, we could add in a question to ask: Does the current point allocation model (i.e. time-based) map out your contribution well? If no, why and what is a better way?

3. How do we ensure that contributors are accountable in spending the time

I agree that accountability is an issue, and that this is a good start. I feel that using time as a way to recognize contributions is not a good way. There are other tools / frameworks we can complement with the above (see next section), but we should start with a simple pilot first.

4. Even if people do spend the time, how do we ensure there are benefits to the DAO?

In the long run, I feel that commitment level (time spent) is not a good way of recognizing contributions. While most contributors are well-intentioned and spend time in the community, there could be many reasons why their time do not result in outcomes for the DAO, such as:

  • Workflows and processes can be improved
  • Meeting structures can be improved
  • Contributor does not have the right skillset
  • Contributor has not figured out the way to solve the problem
  • Team structure can be improved

These are multi-dimensional and inter-linked issues, which cannot be tracked by just looking at time or effort.

In my view, a better way to measure contributions would be to transition from a model of time / effort to an outcome-based model.

  • First, we should understand the intended outcomes we want to achieve as a DAO (i.e. For our DAO to achieve our vision and mission, what do we need to achieve?)
  • Second, we design teams and roles that own each of these outcomes.
  • Third, we design compensation and “bandwith allocation” to encourage teams / contributors to find efficient and meaningful ways to achieve these intended outcomes.

As we scale, this helps us achieve organizational efficiency and clarity in roles (among other benefits). I know that these structures typically have bad connotations of being “top-down” and “Web2-ish” but I think there is value here and there are ways for us to do it meaningfully to DAOhaus.

Just adding a quick blurb here since I’m on the topic - I don’t mean to derail the conversation. I have already started work on this and will share more in another setting.


All in all, I think contributor accountability and visbility is a problem statement we should solve. We should stay focused, make certain assumptions and simplify the surface area of the experiment.

In the short term, I’d suggest the following actionables:

  1. In the survey, we use Circles as the main way of splitting up the contributors’ commitment level.
  2. In the survey, we use Commitment Level (Time spent) as a points allocation model. We can have additional follow-up quetions on other ways of allocating points but it should be minimal.
  3. Use “Allocation” instead of “Staking” - It’s less loaded, jargonish and scary.

In the long term, I think this is a good start and we should start looking achieving in ensuring contributor accountability. More importantly, we should start looking towards a outcome-based model of contributions which I’ll share more soon.


Thanks @arentweall for the comments! I’ll organize my response in terms of your three suggestions

Suggestion 1: focus on circles

I have two responses here, a) about the focus on circles, and b) about the use of the survey.

A. While I agree with your suggested goal of focusing on addressing the most important problems of workstream visibility and accountability, in my view limiting the pilot to circles is the right move. If the point is to surface existing projects and roles that aren’t explicitly defined today, then sticking with the one structure we do have won’t help us much.

Instead, I want to see what contributors list as their current workstreams (circles, projects, and roles), especially the ones for which we don’t yet have good labels, definitions/descriptions, or structures.

B. I’m hesitant to use the contributor compensation survey for this purpose, even for a pilot. This general concept will only be valuable if contributors make adjustments to their allocations as their focus shifts. Tying the process to a once-every-two-months event – even if just for a pilot – risks embedding too much rigidity and a slow cadence into how contributors perceive it.

Instead, I’d like to see it as a separate process that contributors engage in on their own time, whenever their focus shifts (or as they want to get more granular about how they’re expressing their commitment).

Suggestion 2: points as time spent

I agree that we should use the same measure – Commitment % – as we use for our compensation program. However, I disagree that it should be constrained to time. In fact, in our compensation program we very explicitly do not define Commitment % merely as time; rather, we leave it up to the contributor to define for themselves to best estimate their Commitment %, such as (from the docs): “time, dedication, focus, prioritization, effort, etc.”

I think we should do the same here. If some contributors prefer to use time, that’s great. If others prefer to use prioritization, that’s also great. As you said, everyone has different ways of interpreting their involvement. We should lean into that.

Suggestion 3: “allocation” not “staking”

Yes, 100% agree here.

I think there are some future valuable additions to this concept that may look more like staking, but we can cross that road when we get to it. For now, we’ll stick with “allocation”.

On Accountability

Some stray thoughts and responses.

I agree this would be wrong, but I don’t think this has ever been on the table. Rather than directly evaluating a contributor’s commitment, understanding where they are allocating their commitment enables their peers to evaluate a) whether they indeed followed through, and b) how valuable the result was to DAOhaus. Both (a) and (b) are (subjective) evaluations of output and outcomes.

I like this progression. My hope is that there can be an interplay between top-down consensus about our direction that progresses in this direction (1, 2, 3) with a bottom-up emergence that travels the other direction (3, 2, 1). Lots more to discuss here, so I’ll save it for your upcoming post, which I’m very much looking forward to!

1 Like

I’ve created a workbook for people to start experimenting with this concept. Please give it a try!

Warcamp Commitment Allocation Workbook

For this prototype, I’ve categorized Workstreams into 3 groups. These categories and labels are likely to change as we learn more about what works, and depending on the degree to which we adopt specific terminology from holacracy. But let’s start here and see how things go:

  1. Circles – groups of contributors formed around particular skills or functions (“horizontal”)

  2. Projects – groups of contributors formed around achieving particular objectives or outcomes (“vertical”). Projects can be cross-functional and can therefore be related to more than one Circle.

  3. Roles – individual responsibilities, typically related to either a Project or a Circle.

If you’ve already done role discovery with @ui369.eth, please use those roles here. And please let me know how that goes, especially if there’s a structural incompatibility!