Beyond DAOs: Design Decisions for Internet Organizations

Photo by Mourizal Zativa on Unsplash

This is a guide for builders creating what some might call “DAOs” (decentralized autonomous organizations). The problem with saying “DAO” is that no one seems to quite agree on what a DAO is, let alone what it means to be “decentralized”, “autonomous”, or even an “organization”.

One rough definition you could use for DAOs is that they are organizations that are run by decentralized, transparent code rather than a dominator hierarchy. Though as many DAO builders can attest, that’s not necessarily how they work in practice. Oftentimes, only a small subset (if any) of DAO operations are run on-chain, and many organizations that call themselves “DAOs” are run like a traditional, centralized start-ups. Even OG protocol DAOs like MakerDAO are more centralized and opaque than you might think.

A common response to this type of DAO criticism is to kick the can down the road and imagine that it’s only a matter of time before all parts of the DAO stack are on-chain (“we’re sooooo early”). The other common response is to wallow in cynicism and despair about the failed promise of DAOs.

Neither of these responses are particularly helpful for builders who want to create organizations governed by code. Speaking abstractly about “DAOs” doesn’t acknowledge the diverse reasons you may want to build a decentralized organization — capital formation, transparency, decentralized contribution, bottoms-up information processing, censorship resistance, etc — and the specific tools you’d need to implement that functionality.

In this post, we’ll cleverly side-step this conceptual quagmire by largely abandoning the abused and overloaded term “DAO”. Instead, we will discuss “internet organizations”. Like DAOs, internet organizations can enable new modes of coordination by modeling the flow of power and value through code rather than top-down management. However, whereas DAOs ostensibly aim for fully decentralized governance, an internet organization can aim for a mix of decentralized and centralized decision-making depending on the context. And whereas DAOs might aim to model the entire organization on-chain, an internet organization may selectively model different parts of the organization on-chain or off-chain for specific reasons. Internet organizations are a superset of DAOs and offer a more expansive and permissive definition of online governance.

This post is a practical design guide on how code can determine the flow of power and value between members of internet organizations. We’ll explore both the web2 and web3 tools that mediate this flow by determining who gets to join the organization, who has power, and who gets paid. We’ll explore the internalized assumptions and worldviews of these tools and the complications that can arise when you try to compose them into a single consistent and coherent framework. It’s one thing to talk about how an internet organization or DAO could work, but it’s quite another thing to implement it with today’s tooling.

Our discussion will mostly focus on blockchain tooling though we’ll also discuss centralized, web2 tools as valid alternatives. This post will largely be focused on the Ethereum ecosystem because that’s where the DAO tooling ecosystem is the most developed. While you can build your custom governance tools, we’ll focus on how existing tooling can be composed within an organization. Both DAOs and internet organizations can be associated with a legal governing structure like an LLC or non-profit, but these legal structures are out of scope for our discussion. We’ll only be discussing how tools model the flow of power and value through code.

To frame these design decisions, we’ll use the following framework:

1. Membership: Who is part of the organization?
2. Power: Which members can take which actions?
3. Value: How do members share in the value they create?

By the end of this guide, you’ll have a solid grasp of the building blocks you need to compose to create your internet organization, the limitations with how these building blocks interoperate with each other, and a sense of what still needs to be built in in the internet organization tooling ecosystem.

1. Membership

What does it even mean to be part of an organization? In a traditional company, we think of members as employees and shareholders who have minimum involvement in day-to-day decisions.

But in an internet organization, member relationships are much more complicated and ambiguous. For example, in many DAOs, owners can span from passive investors to active contributors on the core team, and DAO contributors can span from folks who pop into the Discord from time to time to totally anonymous contributors who complete bounties.

This ambiguity turns out to matter quite a lot in internet organization design — you need to be able to clearly define your members before you can design transparent (and scalable) governance processes for those members.

We can break down internet organization membership into two distinct categories, which often exist in parallel in internet organizations:

• 1.1 Liquid financial membership: Members have a liquid financial interest in the organization.
• 1.2 Contributor membership: Members have an execution or funding role within the organization.

As we’ll see, these two forms of membership each have their own goals, implementations, and limitations with currently available tooling. These limitations have real implications for how power is distributed in an internet organization.

It’s important to remember that defining contributor membership is totally separate from how financial membership is defined. And while you don’t need to have a model for financial membership, you do need to have a model for contributor membership.

1.1 Liquid Financial Membership

In liquid financial membership, you can freely buy and sell membership to the organization. This style of membership is uniquely enabled by blockchain token standards (e.g. ERC20, ERC721, ERC1155) which allow for a record of ownership to be transferred without an intermediary. These blockchain standards will be the focus of this section.

UniSwap’s UNI token and a Bored Apes Club NFT are both examples of financial membership. There are also illiquid versions of financial membership, which have very different purposes and implementations. We’ll discuss illiquid financial membership more in the Contributor Membership section below.

The most important use of liquid financial membership is incentive alignment — the generic incentive of money is used to coordinate decentralized members to act toward the greater good of the project, without worrying about the specifics of how the greater good is achieved. When financial membership is working well, token holders take it upon themselves to promote or even contribute directly to the project without being explicitly told to do so.

Critically, financial membership gives token holders an opportunity to “vote with their feet”. The ability for token holders to sell when they don’t agree with the direction of a project is a strong accountability backstop even in the absence of any formal governance mechanisms. Oftentimes, liquid financial membership is paired with some version of governance rights. Internet organization builders are attracted to financial membership because it’s a simple way to bootstrap financing, largely because this style of fundraising is not tightly regulated as of writing. This style of membership has also become very popular because DAO tooling makes it trivial for even non-technical users to create their own liquid token.

While liquid financial membership can be powerful, reader beware — it is extremely difficult to make financial membership work in the long term. Successful financial membership requires heroic feats of technical, economic, and social engineering, and getting financial membership wrong can quickly crater your organization. Moreover, because it’s so easy for liquid financial membership to raise money in the short term and so difficult for it to work sustainably in the long term, liquid financial membership is prone to scams, which the blockchain community refers to as “rug pulls”.

Getting liquid financial membership to work sustainably requires a token to have the following factors:

• Liquidity: The liquidity of financial membership is both its greatest and most dangerous quality. It’s great in that it can make it very easy to raise capital and align incentives, but disastrous in that it attracts mercenary capital that will flee at the first sign of danger and leave your treasury devastated.
• Utility: For liquid financial membership to not be a purely high-volatility speculative asset, this form of membership must have utility. The most common form of utility is governance rights, though other forms of utility can include exclusive access to a community/product or a well-defined cut of the project’s core economics.
• Community: Decentralized communities thrive when individual participants feel individually compelled to contribute to the success of the project. Doing this effectively is a strategic and high-effort activity that often involves dedicated community managers, grants, partnership development, technical support, etc.

Let’s explore three common approaches for liquid financial membership:

• The ERC20 Protocol Token
• NFT Collection Membership
• Social Token

Each of these methods is appropriate in specific contexts and each must think about liquidity, utility, and community management in different ways. Let’s dive in:

1.1.1 The ERC20 Protocol Token

The most classic style of tokenized liquid financial membership is a fungible ERC20 token that is both the governance token and a liquid asset (e.g. AAVE, UNI, etc). While mixing governance with money can be a recipe for corruption in some cases, the combination works for DeFi protocols because it allows for transparent and credible coordination of multiple entities who don’t know/trust each other. Since the whole point of these protocols is moving money around, money is an effective way of aggregating signal across the ecosystem. ERC20 tokens can also be an effective way for a DAO to bootstrap its financing. Classic DAO governance systems like the Compound Governor and Aragon were originally built for ERC20 governance.

It’s easy to create an ERC20 governance token. Most DAO builder tools give you the option to create an ERC20 token through their UI. However, it’s extremely difficult to get token mechanics right, motivating the use of tokenomic simulation tools such as cadCad. Let’s consider these challenges through the lens of our liquidity, utility, and community framework:

• Liquidity: The primary issue that ERC20 governance tokens face is token volatility. Token volatility can quickly tank interest in a protocol and deplete an organization’s funding if they don’t carefully manage its treasury. ERC20 tokens often need to be paired with clever mechanics to reduce volatility and push up the price over time. A common mechanic is “staking rewards” to offer yield for holding governance tokens, which in turn reduces sell pressure and increases buy pressure. By itself, staking rewards can result in extremely volatile token prices which can ultimately tank the protocol. An increasingly popular design pioneered by Curve is the veToken design. In veTokens, users must lock up their tokens for a defined period of time to receive staking rewards and governance rights. Longer staking periods = larger rewards/governance “boosts”. There’s a lot that could be said for token design but that warrants another blog post (or textbook).
• Utility: The most common way that utility is handled with this style of financial membership is through governance rights. Done poorly, protocol token governance rights either don’t exist or resemble something closer to “governance theater”. Done well, protocol token governance rights allow a protocol to collectively source the best ideas from the community, give members a financial claim to the core economics of the protocol, and give members direct on-chain control over the most important critical components of the protocol (e.g. treasury, protocol parameters, etc). For example, Curve’s CRV holders can vote directly on-chain on how to incentivize its liquidity pools. In Helium, a protocol that aims to create a decentralized wireless network, creators of hotspots are rewarded in the protocol token for creating hotspots, and protocol tokens are “burned” to send data over the network. Token utility may also become increasingly important over time as regulators take a harder stance on what tokenized assets are securities. Giving tokens utility is powerful but it’s an economic/technical engineering exercise that’s not for the faint of heart.
• Community: Protocol tokens can be carefully allocated to cultivate a community to use and build on the project. This is commonly done through token incentives/grants. One interesting model is Optimism’s Retroactive Public Goods Funding model which retroactively rewards projects that added value to its ecosystem.

Protocol tokens tend to add value in contexts like DeFi and Layer 1s where the problem that the protocol aims to solve is well understood and the token itself directly helps to solve that problem. If an internet organization is aiming to solve a problem that is not well defined or is quickly evolving, protocol tokens will look closer to speculative assets rather than useful tools for your organization.

1.1.2 NFT Collection membership

In NFT collection projects (e.g. Bored Apes, Doodles), NFTs can act both as membership passes that grant access to a community as well as financial assets that are expected to appreciate as the community grows. The hope is that NFT holders will shill the NFT collection, both through affinity to the brand and because of their shared financial interest. If everything goes well, the NFT collection may cross the chasm from being a speculative JPEG to something that looks more like a social club.

NFT collections have their own challenges for liquidity, utility, and community management.

• Liquidity: NFT collections must strike a delicate balance between exclusivity and liquidity. A common tactic to manage this tension is to issue 10K NFTs in a collection, which will hopefully allow just enough token holders to create liquidity. Liquidity is king because, in the same way that DAOs that issue ERC20 protocol tokens live and die by their token price, NFT projects live and die by their “floor price”.
• Utility: Successful NFT projects usually give some form of utility or at least a credible expectation of future utility. The most common utility for NFT projects is exclusivity (token-gated Discords, Telegrams, in-person events, allowlist for token drops, merchandise, etc) and there are many tools like Guild, Tropee, and Lit Protocol that make it relatively easy to create this type of utility for an NFT collection. Though less common, some NFT projects, like Doodles, have governance rights attached to them. An even less common and much more difficult form of utility is giving NFT a portion of the underlying economics of the project. Famously, Bored Apes NFTs give holders licensing rights for their Ape. Another project, Royal, gives holders of NFTs that represent songs a cut of the streaming royalties.
• Community management: Compared to launching an ERC20 token, launching a NFT collection is much more about social engineering than technical/economic engineering. Making this type of financial membership work is all about getting your NFT into the hands of influencers, securing high-profile collaborations, intensive Discord community management, and being very lucky.

In short, successful NFT projects are not just a matter of creating 10K JPEGs. Making a collection successful is an intensive and ongoing community management effort that generally isn’t appropriate for an internet organization unless it’s a cornerstone of the organization’s strategy.

1.1.3 Social Tokens

Social tokens are also ERC20 tokens that act as financial assets. However, in contrast to protocol tokens, the utility of a social token is to grant access to a community or creator. The dynamics of social tokens are similar to NFT profile picture (PFP) communities — holders of the token are incentivized to become active contributors to the projects to increase its value. The most famous PFP community is FWB (Friends with Benefits) though there are also tools like Roll or Coinvise that allow creators to quickly create their own social token.

Social tokens have similar challenges to both ERC20 protocol tokens and NFT collections.

• Liquidity: Like NFT collections, a key challenge of social tokens is that there is an intrinsic tension in social tokens between catering to a well-defined community and liquidity. On one hand, a social token must be sufficiently niche to be an interesting community, but it must also be large enough to have trade volume.
• Utility: In projects like FWB, the utility of the token is exclusive membership to a social club. This type of exclusivity is similar to NFT collections (e.g. token-gated events, Discords, etc) and can use many of the same tools, but the end goal is much more about creating “stickiness” by getting token holders to connect with each other. Other projects like Roll seek to create utility for social tokens by allowing artists/creators to use social tokens as a way of incentivizing engagement with the creator. The emphasis in this case is less on getting token holders to connect with each other, and more on the relationship between the creator and the token holder. This latter form of utility is shallower and doesn’t fully harness the power of liquid financial membership. For a social token to be useful in building a community rather than just being a speculative financial asset, social token holders should feel compelled to directly contribute to the community rather than passively consume content.
• Community management: Like NFT collections, social tokens require a well-coordinated, high-effort community engagement plan.

Given the challenges with liquidity and the ongoing effort required to maintain a community, social tokens likely aren’t a great fit for most projects. Compared to NFT projects, social tokens are a less battle-tested model.

1.2 Contributor Membership

Contributor membership defines who has a role in actually getting work done on behalf of the internet organization. It can be used to define who is a part of a guild/team, who has specific permissions and roles, who has the ability to access funds, and who gets paid. Since collaboration over the internet happens through online tools, these tools effectively define who’s a member and what power those contributors have. All internet organizations have some way of defining contributor membership.

“Contributor” is a slippery concept in internet organizations. Sometimes a contributor is fully employed by the internet organization. Sometimes a contributor is someone who completes bounties on DeWork. Sometimes, a contributor is someone who pops into Discord every now and then to share a couple of memes.

We’ll use “contributor” broadly to encompass people and entities that offer time and/or financial contributions. In the case of financial contributions, we’re concerned here with illiquid financial membership. In illiquid financial contributions, you may have a claim over the project’s treasury or revenue in proportion to your financial contribution, but your membership is either difficult or impossible to sell.

Unfortunately, internet organizations generally don’t have one cohesive model of contributor membership. While a traditional organization like an LLC or nonprofit may have a single “employee directory”, internet organizations often don’t have a cohesive way of defining who their contributors are and how they relate to each other. Internet organizations need to use multiple contribution tools in parallel (e.g. Github, Discord, contributor NFTs, etc) that each have their own models for what membership means. These models of membership may not be interoperable with each other.

This can make it difficult to form a clear picture of how membership and power work in an internet organization. This is unfortunate both because it reduces transparency and also because it can be difficult for internet organization builders to manage. Let’s discuss how different tools model “contributors”, the implicit worldview of each model, and the likely difficulties internet organization builders will encounter when using these models.

1.2.1 Implicitly Feudal Web2 Membership

Internet organizations often need to rely on traditional web2 SaaS tools like Notion and Twitter to get work done. These centralized tools often allow users to create smaller units of local administration — Reddit subreddits, Facebook groups, Notion teams, and Discord servers — that are governed by the community (Jhaver et al., 2021).

Unfortunately, these tools are often built to support traditional companies and nonprofits that structure themselves as dominator hierarchies. These tools have an “admin’’ who determines who can use the tool and the power available to any given member of the organization. Researcher Nathan Schneider has described the embedded worldview of these tools as “implicit feudalism”.

Using implicitly feudal tools is not necessarily a problem for an internet organization, and for many organizations, it’s unavoidable given the current state of available tooling. Implicitly feudal tools are abundant, polished, and easy for internet organizations to quickly start using. For example, an internet organization may not see who has admin privileges over a Mailchimp account as being a critical governance priority. However, it is important to understand which tools are implicitly feudal as it will define the boundaries of what powers can be directly controlled by community governance.

There are tools that allow some extent of community-led, or at least transparent, provisioning of membership in web2 tools. Guild, which we’ll explore in detail later on, allows for token-gated permissioning to web2 tools like Google Docs and Github. Discord offers a permissions management API that enables Discord bots to programmatically provision Discord roles based on predefined criteria. Other web2 tools like Open Collective and Loomio allow community control over financial resources and decision-making, respectively. However, each of these tools are implicitly feudal in the sense that they each rely on the concept of an admin.

1.2.2 Blockchain-Based Membership

Each of the remaining contributor membership models we’ll discuss are blockchain-based and can enable ways of defining contributor membership that aren’t implicitly feudal. When membership is recorded transparently on the blockchain, it can be used to directly control on-chain resources through communal decision-making and serve as a single source of truth across multiple tools for who is a member.

Though the devil is in the details, and each of these blockchain-based membership models has its own limitations regarding its:

• Interoperability with other web2 and web3 tools.
• Suitability for organizations of different sizes and goals.
• Difficulty to implement and maintain.
• Ability to work within different communal decision-making systems.
• Financial feasibility for broad governance participation.

A shared limitation between all blockchain-based definitions of membership is that, as of writing, the user experience of interfacing with the blockchain can be challenging for even technically literate contributors. This may make blockchain-based membership systems less compelling, depending on which community the internet organization is meant to serve.

Membership via proposals
Moloch-style DAOs (e.g. most notably DAOHaus) add new members via proposals that are voted on by the group. This works well for organizations that are intended to be less than ~150 people, but it doesn’t scale well to larger organizations.

Members of Moloch DAOs have a claim over the treasury that’s proportional to their financial contribution to the organization. An interesting feature of Moloch DAOs is that they have a “rage quit” function which allows members to quit at any time with their portion of the treasury if a proposal passes that they don’t agree with. The intention of rage quitting is to protect members from the tyranny of the majority.
Moloch-style DAOs work well where a limited set of members need to pool funds and collaborate to achieve some kind of objective. Prominent Moloch DAOs are often grants DAOs (Metacartel), investment clubs (The LAO), and freelancer groups (Raid Guild).

Moloch-style DAOs are a highly opinionated version of how an internet organization operates, and building your own custom implementation of membership via proposals would be a high-effort exercise.

Multisig
Multisig (short for “multisignature”) is the OG version of a DAO. Multisigs must have a certain threshold of signatures for any given transaction to be executed (e.g. 3 out of 7 signatures must sign for execution). Though a multisig is possibly the simplest implementation for thinking of what a “DAO” can look like, multisigs like Gnosis Safes are highly customizable. For example, a Gnosis Safe can have different voting thresholds for different kinds of transactions and transactions can be gated by whether or not something happens in the real world (via reality.eth).

Most DAOs (regardless of whether they are built on ERC20, NFTs, etc) will use multisig for some of their functionality. Since multisig accounts are simply Ethereum accounts, they can hold ERC20 tokens and NFTs. This directly ties governance process to control over shared resources. Though given a multisig’s relatively simplistic voting mechanism, they’re generally not appropriate for groups of contributors larger than ~15 people.

Non-transferable NFTs
Defining membership via NFTs has the huge benefit of playing nicely with web3 tools that have token-gated access to Telegram groups, events, Discord channels, content, etc. When NFTs are used for permission-gated membership they are generally non-transferrable, which is important so that sensitive permissions can’t be bought and sold.

There are different models for how these NFTs are administered. In one model offered by the NFT guilds tool Otterspace, an admin has control over minting NFTs to members as they onboard, and burning NFTs as they offboard. Hats Protocol takes an alternate approach that allows admin rights over roles to be governed in arbitrary ways. The former mode of admin rights is easier to start working with quickly, but the latter holds the promise of much stronger community accountability.

Some tools like Metropolis and Hats Protocol actually combine the benefits of multisig and NFTs by determining who is a signer based on who holds a particular NFT. This combines the benefits of multisig (built-in on-chain governance and treasury) with the benefits of NFTs (interoperability with web3 tooling).

NFTs are emerging as a way of representing teams and roles within internet organizations, and programmatically granting access based on who holds that role. However, it’s one thing to create an NFT representing a role in a team, but it’s quite another to give these NFTs rights and permissions. We’ll explore this further in the Rights and Responsibilities section.

Fundraising DAOs
For fundraising DAOs, like those created by Juicebox, the ERC20 token is simply a claim on the treasury. So when a project like Constitution DAO was not able to purchase the Constitution with the funds it raised, holders of the PEOPLE token were able to redeem their token for a portion of the DAO’s treasury.

Investment DAOs
Investment DAOs (e.g. Syndicate and Unique.vc) need to have less than 100 people to fall under the SEC definition of an “investment club”. These clubs often have an admin-controlled process and a time-limited window for adding new members to the organization. While an Investment DAO’s goal is to make money, they don’t do so by pumping up the price of the membership they do so by speculating in NFT / ERC20 tokens of other projects

NFT Fundraising
NFT collections are also used as a way of fundraising and giving donors an NFT reward for their contribution to the cause. In this case, NFT holders often don’t have a claim over the treasury.

Reputation Tokens
Reputation tokens are non-transferable and are intended to quantify a member’s past contributions. Reputation tokens can be used to determine both a member’s voting power and share of the treasury. Building systems to quantify and reward reputation has long been one of the holy grails of DAOs, but building such systems has proven to be challenging.
Colony has one of the most built-out implementations of on-chain reputation. Reputation in Colony is intended as a measure of recent contributions, decays over time, and can be increased/reduced through arbitration. Other projects like SourceCred and Coordinape aim to capture reputation through off-chain means.

In any case, reputational systems for DAOs have not caught on to the mainstream. This could mean that reputational systems for DAOs are a ripe area for building, but it could also mean that its efforts here are likely to be fruitless. Take it as you will.

1. Takeaways

• Liquid financial membership can be a powerful tool for internet organizations, but it requires intensive technical/economic/social engineering to make a liquid financial membership that doesn’t resemble a Ponzi scheme.
• There is not a single cohesive framework for thinking about contributor membership in internet organizations, and organizations will likely need to use multiple contributor membership models in parallel. This makes it difficult for internet organizations to be transparent and accountable in how power flows between contributor members.
• Current tooling may be adequate for certain well-defined use cases like investment DAOs, freelance cooperatives, NFT communities, etc. Building new ways of representing membership to support novel and ambitious use cases will require building custom tools, which can be very difficult, especially if you’re building on-chain.

2. Power

In any organization, members must make decisions on how to create and consume limited common resources like money, attention, brand, etc. An organization must determine who has access to the treasury, who decides which initiatives to pursue, who can make changes to critical tech infrastructure, and who can speak publicly on behalf of the organization. In short, the organization must determine how power is distributed within the organization.

In a traditional organization, the distribution of power is simple — ultimate power rests in the CEO who sits at the top of the hierarchy. The CEO delegates power down the hierarchy, and an organization chart captures this hierarchy where different domains are grouped into teams. How the organization chart translates into access/permissions is centrally controlled through identity management tools like Okta. These tools allow a single email identity and an organization chart to automatically result in permissions across dozens of tools.

Managing rights and responsibilities in internet organizations can be more complicated for a few reasons:

• Organizational structure: As we’ve already discussed, defining “membership” in an internet organization can be deceptively complex and ambiguous, which makes it much more difficult to clearly define who has power within an internet organization. If “contributor membership” is, in reality, a hodge-podge of inconsistent different models for thinking about membership that aren’t easily interoperable with each other, it’s very difficult to clearly define the roles/responsibilities of those members and how those members should relate to each other.
• Permissions: If the organization doesn’t have a unifying model for organizing contributor members, it’s difficult to consistently manage the permissions of those members like you can in a centralized company with tools like Okta
• Decision-making systems: In a traditional company, ambiguity in how decisions are made can be easily resolved via top-down control through the hierarchy. But in an internet organization, this ambiguity results in a lack of transparency and accountability, which is dangerous in a decentralized organization. Removing this ambiguity requires enshrining offline decision-making processes into code, but social systems are difficult to model.

The result of these challenges is that it can be difficult to tell how power actually flows within internet organizations. This matters for a few reasons.

From a political perspective, being able to explicitly model the flow of power could enable new forms of transparent governance. Without transparent governance, internet organizations default to a structure that resembles a dominator hierarchy — a single person has critical passwords, admin privileges, and treasury access. If the flow of power could more explicitly be modeled, it could enable heterogeneous and composable forms of online governance, sometimes referred to as “modular politics”, that organically evolve over time in response to the needs of the community. Modeling an organization’s politics as code would also reduce the process of burden of implementing ambitious forms of non-hierarchical governance like Teal organizations and Holacracy, which can be onerous to implement in an offline setting.

From a practical perspective, internet organizations struggle to delegate authority between members, which makes it likely that 1–2 members will bottleneck the organization. Even if an internet organization explicitly wanted to model itself as a dominator hierarchy, having a way to explicitly model the delegated permissions in that hierarchy would be useful.

We’ll explore how the flow of power can be modeled over the dimensions:

• 2.1 Organizational structure: How are subunits of the organization defined
• 2.2 Roles and permissions: How is power delegated to individual users and subunits?
• 2.3 Decision-making systems: How does the organization and its subunits make decisions on how to use scarce common resources?

2.1 Organizational Structure

Organizational structure is important in internet organizations for the same reason it’s important in traditional organizations. Breaking an organization into smaller groups allows specialized teams to concentrate relevant domain-specific information, permissions, and decision-making authority into a group of qualified individuals.

In principle, any organizational structure is possible within an internet organization. You can make a direct democracy as well as a dictatorship, republic, futarchy, etc. However, as of writing, actually modeling an internet organization into smaller components that are interoperable across multiple tools isn’t well supported. Interoperability issues severely limit the modeled structures’ ability to directly show and control the flow of power within an organization.

Since organizational structure is just an abstraction of membership, modes of representing organizational structure inherit the messiness of defining membership. Organizational structures are either defined not at all or via a smattering of web2 and on-chain tools.

2.1.1 Implicitly Feudal Web2 Teams

The most common way of defining teams in internet organizations, including DAOs, is via centralized web2 tools. Perhaps there’s a Google Sheet or Notion with a list of members and their teams or maybe it’s defined based on whoever has a particular Discord role. A central admin might use these team definitions to manually configure the permissions of a team’s members. These working groups can be centrally controlled by the core team or informally defined by loose associations of contributors hanging out in a Discord. In any case, defining membership in this way is implicitly feudal. These teams are not autonomous units, don’t directly have power over shared resources, and generally can’t be given programmatic access to specific tools (e.g. a shared Twitter account or an Asana board).

This style of team membership is not necessarily a problem — it’s fast and easy to implement with current tooling. However, when an internet organization designer defines teams in this way, it’s at least important to recognize how this constrains the governance possibilities within the organization. For example:

• New organizational forms: When membership is opaque, organizations lose out on organizational structures like Teal organizations that harness the power of a decentralized workforce.
• Transparency: If it’s not clear exactly who has control over what, organizations have a tenuous claim over any version of “decentralized” or “autonomous”
• Adaptability: When it’s not obvious who has power, it’s difficult to dynamically add new contributors and communally evolve the organization over time.

2.1.2 On-chain Teams

The remainder of the methods we’ll discuss for defining organizational structure are blockchain-based. Defining teams on-chain is powerful because it programmatically gives team members access to common resources, token-gated web2/web3 tooling, and shared decision-making frameworks. However, projects for modeling organizational structure on-chain are still early and/or have serious limitations.

Multisigs
One of the most common ways of defining on-chain teams is via multisigs (e.g. Gnosis Safe). Since multisigs can, themselves, be signers of other multisigs, you can create many different kinds of organizational structures with them. Metropolis (f.k.a. Orca) is a tool built for managing multisig working groups, or “Pods’’. Pod membership is defined via an ERC1155 NFT contract which allows it to play nicely with other tools that define membership by NFTs. Each pod member gets 1 vote, and you can optionally have a pod manager that has rights to add/remove members.

As powerful and flexible as multisigs are, there are still limitations. Multisigs are designed for smaller groups of signers and shouldn’t be used for modeling groups more than ~15 people. Also, if you’re not using NFTs to determine who is a signer on a multisig, you won’t have interoperability with tools in the web3 ecosystem that define membership via NFTs

NFT Gated Guilds
An increasingly important way of defining organizational structure is via ERC-721 or ERC-1155 NFTs. Defining membership via NFTs is important because NFT token gating is an increasingly common pattern for web2-based DAO tools. For example, you could set up a private Discord channel, collaborative workspace, and Kanban board that’s token-gated by individuals who hold your NFT. These NFTs are generally non-transferable.

However, the core problem with defining organizational structure via NFTs contracts is that while it’s easy to say that a group of NFTs is a guild, circle, team, etc, it is much harder to define on-chain how these guilds relate to each other and allow flexibility in who gets to determine guild membership.

The simplest and most common implementation is to have a single admin who has complete rights over who holds a guild NFT. For example, an emerging guild membership tool, Otterspace, defines each guild as its own ERC721 contract that has an admin who can mint/burn guild NFTs at will. Similarly, Badger defines membership via ERC1155 “badge” and allows the organization “owner” to delegate badge creation rights to other members of the organization.

Another ambitious approach for defining organizational structure and roles is the Hats Protocol. In the Hats Protocol, each organization has a single ERC-1155 NFT contract where each organizational role is its own token. The innovation of the Hats protocol is that each Hat can have authority over other hats, creating a “hat tree”. In Hats, eligibility to wear a hat and whether a hat can be worn at all can be toggled on-chain in arbitrary ways. This means that Hats can be used to model virtually any organizational structure.

Domains
Some tools are opinionated on how teams relate to each other and roll up into the larger organization. Colony, a DAO management tool, is split into “domains” that can be split further into subdomains to represent teams/circles/projects/etc to group contextual information. Each domain has permissions that can be assigned for funding, arbitration, admin, etc and its own wallet. Voting power in subdomains rolls up to voting power in larger domains. Colony’s particular model of modeling subDAOs lends itself to a hierarchical structure, though each rung of the hierarchy is decentralized. The drawback of Colony’s model is that 1) it’s very opinionated on how a DAO works and 2) it defines domain membership in a different way than most other web3 tools so it loses interoperability.

2.2 Roles and Permissions

Defining an organizational structure isn’t particularly meaningful unless the organizational structure is connected to roles and permissions. Unfortunately, it’s often opaque exactly what roles/permissions any given team has. Part of the issue here goes back again to issues in defining internet organization membership. Since membership is difficult to clearly define in internet organizations, it’s also difficult to define internal membership structure, and since it’s difficult to define internal membership structure, it’s difficult to clearly define the permissions within that organizational structure.

An additional difficulty that DAOs, specifically, face is that the relevant permissions in a DAO are defined both on-chain and in web2 tools that have varying levels of web3 integrations. This makes it impossible for most DAOs to have a single cohesive framework for managing how permissions are distributed in an organization. This is both a governance risk and a pain in the ass to manage.

2.2.1 Web2 Roles

Most day-to-day operations of a DAO are run on traditional web2 tech. Code is reviewed on Github, conversations happen on Discord, hot takes are published on Twitter, etc. Many tools are built assuming a traditional hierarchical structure where a single admin can call the shots. There are some workarounds to integrate web3 permissioning into old-school web2 tools and there are an increasing number of token-gated web2 tools, but this permission management for web2 tools remains a challenge for many internet organizations.

Implicitly Feudal Web2 “Admin”
Unfortunately, most web2 tools have the concept of an “admin” and there often aren’t great ways for internet organization governance to programmatically change who’s an admin or know who has admin rights. Even web2 tools that cater to web3 communities (e.g. Discourse. Coordinape, Guild.xyz, Otterspace, etc) rely on the concept of an “admin”. If an admin cannot be programmatically chosen through an organization’s governance tooling, then it will be chosen through an offline process. These offline processes introduce discontinuities that limit the ability of an internet organization to model how power flows between its members.

Mutlisig wallet login
Many DAO tools are largely built on web2 rails, but allow log-in via a blockchain wallet. When a tool allows for log-in via crypto wallet, a multisig could technically be the admin for the tool. Multi-sig access to a web2 tool can distribute control though it can also be cumbersome to manage if it’s not set up thoughtfully (e.g. do you really need 4 of 7 signers to give you permission to sign into your Kanban board admin panel?). Some tools, particularly those that directly manage funds (e.g. Utopia and Parcel) explicitly require a multisig to be the admin of the tool.

Token-Gated Permissions
Increasingly, there are new ways for web2 tools to be token-gated by ERC20, 721, or 1155 holdings. With currently available tooling, an internet organization can token-gate access to much of the tooling it uses. This may make it easier to onboard/offboard contributors and transparently communicate how power is distributed. However, these token-gating tools are generally still ultimately controlled by a central admin. There are several different implementations for token-gating web2 tools:

• Token-gated access to traditional Web2 Platforms: Guild is the most popular tool for token-gating access to traditional web2 platforms. An admin can create a “role” that can be gated by both web2 criteria (twitter follows, membership of another Discord, etc) and web3 criteria (ERC20, 1155, 721 token holdings). The admin can give each role special access to Discord roles (which could give you special permissions within the Discord server), access to Github repos, Google docs, or a Telegram chat. Roles are still centrally controlled by an individual(s) who has admin power over both the guild and the web2 platforms the guild connects to. So it’s not “decentralized” but it is a transparent and distributed way of handling permissions. It’s also very easy to use for new DAOs.
• SDK for token-gated access: Lit protocol offers a way of configuring token-gated access control conditions (e.g. member of a DAO, holds NFT in the collection, X amount of tokens) to static content dynamic content. Token gating conditions can be arbitrarily complex and can be built for any dApp.
• Tools with web3 integrations: There are web3 analogs to traditional web2 products — DeWork (Asana), Charmverse (Notion), Parcel (Rippling) — but these tools still have a lot of kinks to work out and may not offer on-chain based permissions that correspond to how your on-chain roles are set-up. For example, most of these tools expect permissions to be defined as fungible/non-fungible tokens which doesn’t work if a given group is defined by a multisig or non-NFT based membership system like Moloch DAOs.

2.2.2 On-chain Roles

On-chain roles are often defined via OpenZepplin’s access control module that allows you to set a “owner” of a contract as well as more granular permissions (e.g. “minter”, “burner”, etc). These roles are powerful in that they directly control on-chain functionality and can theoretically allow for transparent DAO governance. However, in reality, non-technical DAO contributors often don’t know these on-chain roles exist unless a decentralized application (dApp) chooses to display them. And even if a dApp choses to display the role, it’s unclear who owns that account. In their worst form, “decentralized” protocols have an admin key that can give a single user a backdoor to do whatever it wants. If the key is lost or stolen, the protocol can be compromised

To reduce these risks, a common and best-practice pattern is for each on-chain role to be a multisig. In other words, instead of having “Joe” as the on-chain admin, you create a multisig with Joe, Kathy, and Suzy as signers.

2.3 Decision-making systems

Organizations need to define how groups of individuals/entities in the organization arrive at decisions on how to use scarce resources.

In a traditional company, the way power works is very simple. There is a single boss who is overseen by a board of directors. This boss might delegate power or create communal decision-making processes, but at the end of the day the boss is really the one in charge. The nice thing about this arrangement is that it’s very easy to implement. If there’s ever any ambiguity in who makes a decision, it’s very easy to resolve — just keep asking up the hierarchy until you get to the boss. Enforcement of a decision is also fairly easy — the dominator hierarchy enforces decisions through fear rather than any form of programmatic control.

Many internet organizations, and even many “DAOs”, operate in this same way. For the decentralization hardliners, this is heartbreaking because internet organizations have the opportunity to enable entirely new forms of spreading power and making decisions. Internet organizations could allow a decision-making process to be the boss rather than have the process be for a boss to make all the decisions. When process is the boss, power can be held by those closest to the problem rather than at the top of the pyramid. When process is the boss, malicious power plays and embezzling could be impossible.

But modeling process is challenging. Human decision-making in the offline world is often messy and opaque, but it makes up for that in speed and flexibility. Let’s explore several challenges that internet organizations face in modeling decision-making processes:

• 2.3.1 Financial vs contributor governance: How does the project split governance power between liquid financial members and contributor members?
• 2.3.2 Resource control: Does the governance system directly control communal resources?
• 2.3.3 Governance participation: How many members need to vote to make a decision?
• 2.3.4 Voting power: How is decision-making power distributed among members?

2.3.1 Financial vs Contributor Governance

The classic way governance is modeled in DAOs is by assigning governance rights to liquid financial membership — an ERC20 token or NFT that represents decision-making power within the DAO. Financial members can vote to oust the head of the organization, in a similar way to how the CEO of a corporation is ultimately accountable to its shareholders.

Liquid financial members can also informally vote by “voting with their feet” and selling their tokens. This pushes down the token price and signals to the DAO leadership whether they need to change course.

Liquid financial membership is good at decision-making in certain kinds of contexts. As Vitalk has pointed out, decentralized decision-making tends to add value in “concave” decision-making environments where the wisdom of the crowd gives better answers. This includes:

• DeFi Parameters: When an organization’s purpose is allocating money (i.e. DeFi), spreading decision-making power based on financial stake makes a lot of sense. DeFi protocols can use bottom-up decision-making to understand how to optimally control how money flows in the protocol. For example, holders of MakerDAO’s MKR coin have direct on-chain governance rights over the most critical parameters of the protocol including the types of tokens that can be used as collateral (e.g. this discussion on whether a gold-backed token PAXG should be allowed as collateral in MakerDAO).
• Treasury Control: One of the most powerful aspects of on-chain governance is that the token holders can be given direct on-chain control over the treasury instead of giving a single flawed human the keys. Many DAO proposals are for major capital outlays and grants (e.g. most Gitcoin proposals are budget requests).
• Leadership Accountability: Some of the most contentious and participated-in proposals rare regarding the removal of DAO leadership (e.g. proposal to remove the director of ENS foundation). In one interesting example of a decentralized system at work, a proposal to create a centralized governing body within MakerDAO was soundly defeated by MKR holders.

Though liquid financial membership is not strong for situations that call for highly coordinated, consistent, and decisive decision-making like strategic decisions. These types of decisions are better left to a smaller group of specialized contributor members.

However, decision-making among contributor members often looks very similar to its centralized counterparts — a loose hierarchy. Perhaps this is totally fine. Perhaps “decentralization” generally doesn’t need to (or shouldn’t) extend into how contributors are organized. After all, centralized organizations can move quickly without the overhead of figuring out process.

But, again, something is lost when internet organizations take this route. Because even if an organization wanted to model itself as a benevolent dictatorship, there would still be value in modeling that power structure on-chain; at least it would be transparent to contributors how power flows in the organization.

Though bringing offline systems of governance online could enable what’s been described by “modular politics. Systems that implement modular politics could be composable, heterogenous governance systems (e.g. one branch of DAO is a direct democracy and another branch is a dictatorship) that organically evolve over time.

Actually implementing modular politics is challenging for the same reasons we’ve already explored above — it’s difficult to model contributor membership and connect that membership coherently to shared decision-making processes and resources (particularly off-chain resources). How membership is defined boxes you into certain types of decision-making systems:

• Off-chain: If membership is defined off-chain (e.g. Discord roles, web2 tool membership, etc), then contributor members won’t have programmatic access for making on-chain transactions or accessing on-chain funds.
• Multisig: Multisigs, particularly Gnosis Safe, have their own ecosystem of tools for extending multisig functionality. While you could implement any style of governance that requires M of N votes to pass, you can’t have quorums or calculate governance power in clever ways like quadratic funding, different voting weights for different signers, etc.
• Custom implementation: Tools like Colony and DAOHaus use their own on-chain methods of defining membership which doesn’t play nicely with the broader crypto ecosystem. Consequently, these tools have built-in governance tools. This means that you lose flexibility in how you design your governance process, but you gain a well-integrated governance/membership system.
• Fungible and non-fungible tokens: When membership is defined via fungible (ERC20) and non-fungible (ERC721) tokens, there are a wide variety of DAO decision-making tools available.

Even if we put aside the web3-specific challenges of implementing modular politics, implementing them is still extremely challenging in a fully web2 context. While there are some early experiments in implementing a web2 version of modular politics (ModPol, PolicyKit), modular politics hasn’t been implemented at scale and it’s not yet clear whether software can/should model messy human systems.

2.3.2 Resource Control

There is a wide spectrum of how governance systems control common resources.

• Offline: There is an opaque offline decision-making process (e.g. a working group in a Discord or a steering committee meeting) that makes decisions but doesn’t directly control how those decisions are implemented.
• Off-chain: There is a codified decision-making process supported that clearly lays out how decisions are made but is separate from how those decisions are executed.
• On-chain: There is a codified decision-making process via smart contracts. The decisions of these contracts are automatically executed for transferring treasury funds or executing on-chain transactions.

Offline
Offline governance is generally how decisions are made by contributor members within internet organizations. While major decisions might be put up to a proposal vote for liquid financial members, contributor members handle most day-to-day decisions via informal Discord conversations, face-to-face meetings, etc. It’s often not clear to contributors (or outside observers) which decisions are being made, what the alternatives are, and whether or not they have a say in the final decision. When a decision is made, there is often an additional step(s) to actually implement the decision. Someone trusted needs to merge a pull request, withdraw money from a bank account, sign a contract with an investor, etc.

Offline process is the default and easiest way of handling day-to-day decisions; however, it misses out on the opportunity to transparently model how decisions are made by a group and ensure that those decisions will actually be executed as intended. Offline process also requires that certain contributors have special access to offline resources (bank accounts, Github admin rights, etc). It is often not clear who has this special access, and this can be abused.

The advantage of offline decision-making processes is that it’s very fast which can be important in certain situations like addressing a security vulnerability. Also, its obscurity can be useful in certain sensitive situations like legal issues.

Off-chain
Off-chain decision-making processes improve upon offline governance by formalizing the process of creating decisions via proposals/votes, though the decision-making process still does not have direct control of any resource. There are off-chain decision-making tools made for both fully web2 and web3 contexts.

Common web2 decision-making tools include Discord and Slack voting bots, in which server members vote on proposals with emojis. Another communal decision-making tool is Loomio, which was born out of the Occupy Wall Street movement. Collaboration tools like Miro and Retrium are also frequently used as informal decision-making tools.

For blockchain-based internet organizations (DAOs) the most common off-chain decision-making tool is Snapshot voting. A “snapshot” is a record of on-chain token balances for a DAO at the time that a proposal is created. The snapshot of these balances is used to determine voting power. Voting power can be calculated in creative ways that would be gas-cost prohibitive on-chain. Snapshot offers single-choice voting, approval voting, quadratic voting, instant runoff voting, and weighted voting. Snapshot even allows you to define your own custom voting strategies based on whatever weighting rules the DAO sees fit.

Off-chain voting has become an increasingly popular choice for DAOs over the last few years. On-chain gas fees is an important reason why — moving voting off-chain can help encourage voter participation. Another is that as crypto has entered the mainstream, there has been less of a hardliner, decentralization-maxi attitude across the crypto ecosystem. DAO builders sometimes feel that token holders aren’t too concerned about whether they’re using the most possibly decentralized tooling, so they just opt to build in a more centralized way because it’s easier. Yet another reason is that only a subset of common resources are on-chain anyway so some level of offline processes to execute decisions is generally unavoidable. There are also interesting experiments like reality.eth which can execute off-chain Snapshots decisions on-chain, partially closing the gap between decision-making and execution.

It’s also worth noting that some organizations, like Wikipedia, build their own custom governance tools for managing decentralized communities (Forte et al, 2014). The “roll your own” governance approach can be powerful, but it is out of scope for our discussion. We’re primarily interested in how existing tools can be composted to model governance processes.

On-chain
On-chain governance is really the Platonic ideal of how online governance should work. The appeal of on-chain governance is two-fold. On one hand, the voting system and votes themselves are transparently recorded on-chain. Though the other, often not understood aspect, is that the decision of on-chain votes is often automatically executed without requiring a human intermediary. For example, if a protocol passes a proposal to increase staking rewards, the staking rewards will automatically increase after the vote without needing to have a fallible human in the mix.

There are different models for thinking about on-chain decision-making:

• Token voting: This is the most common style of on-chain decision-making. In this style of decision-making, am NFT or ERC20 token translates into governance power. There are common frameworks for token voting (e.g. Aragon and Compound Governor) though theoretically any voting system can be built with token voting.
• Multisig: Multisigs use a basic version of voting where M of N signers is required to execute a multisig transaction. Since multisigs are wallets they can directly control funds and execute transactions. Multisigs are extremely common for controlling treasuries and executing critical on-chain functionality like contract upgrades.
• Tool-specific voting systems: Specialized DAO builders like DAOHaus and Colony have their own systems of membership with opinionated ideas about how decision-making works.

2.3.3 Governance Participation

A core problem of online governance is voter participation. There a few angles to this problem

• Information: If bottoms-up information processing does, indeed, create better decisions in certain contexts, then you would want more votes because that means more information.
• Attacks: Imagine a voting system that requires a simple majority vote to pass and a 3-day voting period. An attacker could submit a proposal to “Send treasury funds to my personal account”. If people aren’t paying attention and the proposal passes, the transaction to drain the funds is automatically executed and no one can do anything about it. This scenario is critical and needs to be avoided.
• Agility: Waiting for a proposal to get momentum and pass takes time, and sometimes you need to respond quickly. For example, if the ability to upgrade your smart contracts is gated by the DAO and you discover that you have a smart contract vulnerability, you’ll want a way to respond quickly without going through a lengthy proposal process.

There are different strategies for managing these concerns, and which strategy makes sense for your organization depends on its goals. Ideally, we’d be able to mix these governance strategies for different parts of an organization, modular politics style, but, unfortunately, this isn’t easy to implement coherently with the current state of internet organization tooling.

Quorum and Delegation
Compound-style governance is one of the most popular frameworks for on-chain governance, and it handles governance participation issues via quorum and delegation strategy. In this style of governance, you must have a minimum amount of tokens to make a proposal. Voting takes place over three days and there’s a minimum quorum for votes (defined in absolute terms). A proposal is executed if there’s a majority vote (after a timelock).

The problem with quorums, however, is that they can prevent important proposals from getting passed if voter participation is low. Voter fatigue is a very real issue for this style of governance. Compound-style governance’s approach to this problem is through delegation. Similar to representative democracy, voting shares can be delegated to another voter who will theoretically thoroughly research each proposal and vote. Though like traditional representative democracies, delegation comes with its own slew of issues — delegate compensation, bribes, term limits, etc — that the DAO ecosystem hasn’t quite solved yet. This style of governance prioritizes decentralization and cautiousness at the expense of speed and is generally more appropriate for fully decentralized DeFi protocol DAOs. Quorum-based voting and delegation are also available with some off-chain voting tools like Snapshot.

Optimistic governance
In optimistic governance, instead of voting on every proposal, actions are continuously executed unless challenged. The intention of this design is to optimize for speed of execution and avoid the gas-intensive process of voting on-chain for every transaction.

A popular implementation of optimistic governance is Aragon Govern. The purpose of Aragon governance is to ensure that actions taken by the organization follow the constitution without needing to vote on every single action. There are designated members who can post collateral to create transactions on behalf of the organization. Challenges are handled by Aragon Court which allows anyone to dispute a transaction for a certain amount of time before it’s executed.

Colony uses a similar mechanism. A member can generally execute a transaction on their own and the transaction will execute unless challenged.

Optimistic governance prioritizes speed over decentralization and is a better fit for smaller organizations.

Holographic Consensus
The purpose of holographic consensus is to allow an organization to dynamically switch between different voting strategies for different kinds of decisions. There is limited available collective attention, and it attempts to find a way for allowing small groups to make decisions that would be in line with the larger group’s interest.

DAOstack’s implementation of holographic consensus allows a limited number of “boosted proposals” at any given time. Anyone (not just an organization member) can stake tokens on whether a proposal will pass, and proposals are boosted once they have a minimum threshold of staked tokens. When a proposal is “boosted” it only needs a relative majority to pass rather than an absolute majority.

Theoretically, this could allow an internet organization to get the best of both worlds — quick action on uncontroversial decisions and long deliberation for more controversial ones. This style of governance is promising though it has limited tooling support and has not yet entered the mainstream.

2.3.4 Voting Power

There’s a lot that can be said about different methodologies for calculating voting power and how each methodology impacts voter participation, minority voter protection, Sybil resistance, etc. Instead of detailing every possible flavor of voting methodology let’s highlight a few:

• Time-based weighting: Soon, Snapshot will allow you to create weight votes based on how long someone has held your token.
• Locking and boosting: The veToken model pioneered by Curve awards higher voting power for locking your governance tokens.
• Conviction voting: Instead of evaluating one proposal at a time, the organization evaluates multiple proposals simultaneously. Members can allocate voting power across multiple proposals. The longer a given member’s preference for a proposal holds (i.e. the more “conviction” the voter has), the more voting power the proposal earns.
• Quadratic voting: Voting power is calculated as the square root of token holdings. This voting strategy reduces the influence of whales on governance.
• Token-based weighting: Give voting power to multiple NFT collections and/or ERC20 tokens, and give each token different voting weight.

Different decision-making tools usually offer only a small subset of voting power calculation methodologies, and some of the more exotic and creative methodologies may not be fully practical in on-chain voting systems. This is both because some on-chain voting power calculations can have prohibitively high gas costs and smart contract development is risky and expensive. Snapshot is very flexible in how voting power can be calculated, and you can even write plug-ins to define your own voting strategies.

2. Takeaways

• With the current state of online governance tooling, it’s very difficult to both represent sets of contributors and map those contributors to common resources, permission, and decision-making processes.
• There is a huge unexplored design space for modeling how power flows within an organization. There are good reasons why this is unexplored — it’s difficult to model human decision-making systems with current tooling.

3. Value

All organizations — whether it’s a nation-state, corporation, or internet organization — must determine how the value collectively controlled by the organization is enjoyed by its members. Distributing value is critical to any organization in that it enables contributor members to have both the ability and incentive to continue actively contributing to the organization.

Compared to traditional organizations, internet organization designers have unique tools at their disposal for thinking about how value can be distributed amongst its members:

• Indirect value distribution: With tokenized financial membership, a community can be indirectly incentivized to contribute to the good of the organization.
• Direct value distribution: The internet enables new forms of ephemeral and fluid ways to pay a decentralized network of contributors to complete tasks.

3.1 Indirect Value Distribution

Internet organizations can indirectly reward their contributors, early adopters, and believers in the organization through the increase in the price of the organization's native token.

We’ve already discussed this style of indirect value distribution in detail during our liquid financial membership discussion. But to recap, the most important use of liquid financial membership is incentive alignment — the generic incentive of money is used to coordinate decentralized members to act towards the greater good of the project, without worrying about the specifics of how the greater good is achieved. This type of value distribution can be powerful, but it’s very difficult to get right.

This style of value distribution is also not sufficient in giving contributor members the ability and incentive to continue contributing. Most contributors can’t bank on the rise of a token to pay their bills and the contribution of any given member is usually relatively unlikely to directly result in a token price increase. For most of the day-to-day work of an internet organization, the organization will need to directly pay contributors.

3.2 Direct Value Distribution

In direct value distribution, a member is directly compensated for their contribution to the team. This can look a lot like traditional employment, though there are also novel forms of compensation enabled by the internet.

An oft-cited framework for thinking about how internet organizations can enable new forms of contribution and compensation is Coase’s Theory of the Firm. The Theory of the Firm states that organizations bring workers in-house because it has lower transaction costs compared to negotiating separate contracts for every single thing job to be done.

Internet organizations can significantly reduce the transaction costs of creating new contracts and enable forms of contributorship other than employment. With remote work, talent and information are more fluid and accessible than ever, and ephemeral contracts are easier to create and enforce. Blockchain also has unique features that lower transaction costs for bringing on contributors. On-chain contracts are enforceable by code rather than a costly legal process, and the pseudo-anonymity of the blockchain also allows some projects to avoid the lengthy and costly process of a traditional employment arrangement.

Though even though the promise of decentralized work is compelling, the reality is messier. Oftentimes, online governance tools are disconnected from how contributor compensation and compensation funding are handled by centralized, opaque processes. Some of the more novel and exciting methods of calculating contributor compensation are immature and only appropriate in certain circumstances. Most important of all, these novel contribution models are, again, limited by the inconsistent models available to internet organizations for representing contributor membership, organizational structure, and decision-making.

Compensation in internet organizations generally happens through two separate steps:

1. Funding the compensation pool
2. Calculating individual compensation

3.2.1 Funding the Compensation Pool

Oftentimes, an internet organization’s governance process defines a budget for how contributor compensation, and then the specifics of how individual contributors are compensated happen through a separate off-chain process. Different governance frameworks determine this lump sum in different ways:

• Don’t compensate for contributions: Investment clubs like Syndicate and Unique.vc don’t compensate contributors for their time. The reason for this is that for one of these DAOs to stay within SEC’s definition of an “investment club”, each member is expected to contribute equally to the club; Otherwise, investment club membership would be construed by the SEC as a security
• Governance vote for compensation budget: Protocol DAOs may create a proposal for a lump sum budget for compensating a group of contributors.
• Management fee percent: With Juicebox, a fundraising DAO builder, a proportion of DAO tokens (each of which has rights to a proportion of the DAO treasury) can be automatically set aside to compensate contributors.
• Formula to balance financial and time contributions: Colony uses a formula to balance the share of the treasury that’s claimable through reputation (time-decaying measure of contribution) and financial contributions.

There are a few frameworks like Colony and DAOHaus that handle individual contributor compensation directly through the governance mechanism. Though given the noise of paying individual contributors through a proposal, this occurs via optimistic governance and is only appropriate for smaller organizations. The tools allow members with adequate reputation/stake to send payments on behalf of the organization. The payment can then be disputed by other members of the organization. However, even though the individual compensation is awarded directly through a governance mechanism, the logic to calculate how much each individual contributor should be paid happens through an off-chain or offline process.

3.2.2 Calculating Individual Compensation

Regardless of how funding is allocated for a pool of contributors, there still needs to be a way of determining how much any given individual contributor should be paid. Models for determining individual compensation include:

• Recurring payments
• Bounties
• Reputational systems

These methods are largely run outside of governance processes and often rely on off-chain or centralized processes for determining the amount of each payment.

Recurring Payments
A common contributor payment model is something that closely resembles a traditional employee. A contributor gets paid a set amount each week to contribute over a loosely defined set of responsibilities.

This model is very useful when there’s high uncertainty in the nature of a task that a contributor might need to do (e.g. finance, leadership, operations roles). This type of contributor model is also very useful for locking down unique talent and creating institutional memory. The model works and we all understand it, but there are potentially more creative compensation options that fully tap into the power of a fluid, decentralized workforce.

There are countless web2 tools for handling recurring payments and invoicing that we won’t cover here, but here are a few recurring payment tools enabled uniquely by blockchain tooling:

• Periodic token payments: A contributor, sometimes an anonymous contributor, is paid through regular payments of ERC20 tokens.
• On-chain streaming: In streaming, an organization can continuously “stream” ERC20 tokens to another DAO or individual. Payment is received as it is earned rather than retroactively. On-chain payroll to become trustless, transparent, and relatively simple to administer. Superfluid and Sablier are well-known streaming tools.
• Token vesting: Contributors are awarded tokens that vest as the contributor continues to work on the organization. This is sometimes managed off-chain though there are tools like Liquifi that help manage token vesting schedules.

Bounties
Bounties work well for functions where the task can be reasonably well defined well ahead of time. This can include engineering, marketing, and repetitive operational tasks.

Bounties have enabled decentralized work on the internet long before web3. For example, Mechanical Turk enables a decentralized army of contributors to get paid for completing simple, often repetitive, tasks. HackerOne allows companies to offer bug bounties to ethical hackers, and Replit also offers a bounty tool for software development tasks.

In web3 context, bounties can be offered through web3 project management tools like Dework and Wonderverse. With a bounty, you create a task and set a crypto payout for that task. Anyone can claim that task and if the work is reviewed as satisfactory, the contributor is paid. Admins of these tools can choose permissions of who can claim a task and set payouts for each of the tasks. Dework gates access to certain tasks /admin functionality via Discord roles whereas Wonderverse allows you to token-gate these roles directly. Gitcoin’s Bounties program works in a similar way, except that it’s specifically targeted to bounties for engineering tasks on Github. Another tool, Station, allows contributors to propose a scope of work to the DAO and specify whether the payment should be made in advance or at task completion.

Meritocratic Systems
Instead of relying on the goodwill and judgment of some central administrator, a long-held dream of blockchain enthusiasts has been to make compensation purely meritocratic. There have been many experiments and countless speculative ideas for what reputational systems could look like, but the reality is that none of them have been clearly proven out. You likely don’t want to make reputational compensation the centerpiece of your compensation strategy, but they are likely useful for supplementing the compensation models described above.

Though regardless of their limitations, these meritocratic systems help enable contributors to begin adding value to an organization without necessarily having a formal employment relationship.

• Coordinape Gifting Circles
  With Coordinape, there is a set aggregate amount of compensation that can be paid in a given period, and contributors vote on how they think that payment should be distributed each period. At the end of each period, users write a summary of their contributions. Users are given a set amount of GIVE tokens each epoch to allocate, and each GIVE token represents a percentage of the payroll budget set for that circle. There are a couple of major challenges with this mode of compensation. First, it can be easy for allocations to not be distributed fairly, especially when there are team members whose work is less visible or understood. And even if allocations are distributed fairly, compensation that varies greatly from week to week can be unworkable for some contributors who need a steady paycheck. There are different strategies to mitigate these challenges. The allocations determined by each circle are not set in stone and can be manually adjusted by the circle’s admin. Coordinape effectively just spits out a file with different payout amounts — it doesn’t directly handle payouts itself. You can also allow some contributors to get paid in steady recurring amounts so they don’t need to deal with the uncertainty of Coordinape. Coordinape allows circle members to opt-out of receiving allocations. Another strategy is to give contributors a baseline salary and then use Coordinape for calculating a bonus for each period.
• Centrally Controlled Retroactive Payment
  Sometimes, contributors will help for free on an early-stage, but promising, project with the hopes that they’ll be rewarded with a generous token allocation when the token launches / NFT drops. For example, in emerging NFT PFP communities, it’s common for contributors to become very active in the project’s discord in hopes that they’ll be recognized and placed on an “allowlist” for the NFT Mint. This mode of compensation isn’t sustainable and only really works when a project is in its early stages and has lots of hype. This model is also easy for contributors to game (e.g. spamming a Discord with unproductive messages).
• Retroactive Public Goods Funding (PGF)
  Whereas the compensation methods described so far are largely for individuals contributing to a project, retroactive public goods funding is about funding projects for their demonstrated contribution to the larger ecosystem/society. “Contribution” is generally determined via a voting mechanism. Gitcoin is a prominent retro-PGF tool that funds open source projects whereas Optimism is a Layer 2 that uses retro-PGF to fund utilities built for Optimism. Retro-PGF is an interesting tool for projects trying to cultivate an ecosystem, but it’s generally not an appropriate contributor compensation tool for most projects.
• On-chain Reputation
  The “trustless” ideal would be for the reputation to be fully recorded on-chain. While there has been plenty of speculation and inspiring thought pieces of what on-chain reputation could look like and accomplish, the sad truth is that there really aren’t many workable implementations. Colony has created one of the most built-out implementations of reputation. In Colony, “reputation” is a time-decaying measure of past contribution (as well as arbitration results and reward for bootstrapping a colony). When a contributor is paid, they get a reputation for both their “skills” and the “domain” in which the work was performed. This calculation is performed off-chain and reported periodically on-chain through “reputation mining”. Reputation determines both decision-making power and how the organization’s profits are split, but it’s not the primary way that compensation is determined. Reputation cannot be transferred. When revenue is received by the Colony DAO, the organization can trigger a rewards payout that is a geometric average of past reputation/token holdings.
• Off-chain Reputation
  While on-chain reputation is a worthy goal, the reality is that most work happens off-chain. SourceCred is a project that attempts to quantify this work as a score and use that score to determine compensation. With SourceCred, you earn “Cred” (a nontransferrable token) via an algorithm that weights activity across various web2 platforms. The organization’s admin chooses weights for what creates cred (e.g. liking a post, etc) across the tools SourceCred supports (GitHub, Discourse, and Discord). You earn “grain” which is a fixed-price digital currency in proportion to your cred. Grain can be used as a share of future income or a weight of a community member’s vote. Grain can be allocated based on most recent contributions or a combination of lifetime cred/grain earnings. SourceCred is good at measuring tangible things like a Github/Discord activity but it struggles to keep track of intangible work like meetings, emotional labor, etc, and it’s vulnerable to gaming. SourceCred is simply a template — it’s not a hosted server that collects data, and one must be technical to set it up. Some major projects like MakerDAO, 1Hive, Token Engineering Commons, etc are experimenting with SourceCred.

3. Takeaways

• Determining how individual contributors are compensated is largely disconnected from the organization’s governance system.
• While there are many experiments on how to determine individual compensation based on a retrospective assessment of contributions, these experiments have limitations that will hold back their ability to go mainstream.
• Bounties have proved to be a high-leverage compensation tool in internet organizations, though they are only useful in situations where scope of work can be clearly defined like engineering and marketing.
• Internet organizations have proven that they can get high leverage from a group of decentralized contributors who may not have a formal legal relationship with the organization.

Conclusion

Tradable financial assets (ERC20 tokens, NFTs) have become entangled in the popular imagination with “online governance”. However, liquid financial membership is generally only appropriate in specific contexts like DeFi protocols, NFT communities, and social tokens. Even in an appropriate context with the best intentions, liquid financial membership is extremely difficult to get right. Even if you can get it right, it still does not capture how power and value flow between contributors of the organization.

Unfortunately, current tooling makes it difficult to consistently map definitions of contributor membership to permissions and decision-making systems. Internet organizations often use multiple on-chain, off-chain, and offline models for defining contributor membership in parallel. Without a single way of defining contributor membership, it’s very difficult to assign members to subunits of an organization, give rights/permissions to specific users programmatically, and clearly define how contributors make decisions together. This makes it difficult to model how power flows within an organization and can make internet organizations more difficult to manage than their traditional offline counterparts.

As an aspiring internet organization builder, choosing the right mix of models of membership, power distribution, and value distribution may feel overwhelming. This feeling is warranted. Getting these factors right requires serious technical, economic, and social engineering, and like any software product, it’s unlikely that a builder will be able to get it right on day one. Usually, builders would handle this uncertainty by starting small and iterating to the right organizational configuration over time. However, this is difficult to do with the current set of tooling. These tools are often opinionated about how online governance should work and may not be fully interoperable with each other. Choosing the wrong tool can narrow your options for how power and value can be modeled in your organization. In addition, iteration cycles while building on-chain can be slow and expensive.

It may be the case that the ecosystem is young and that the trickiest problems will get ironed out over time. Though internet organization builders still need to have a path forward despite the current limitations. So how do builders claw their way out of this seemingly dismal situation? I think there are a couple of different routes:

• Be selective: The reality is that current tooling is unlikely to model every aspect of how power and value flow through your organization. Rather than attempting to design all organizational processes as code, it’s more productive to ask where the most value is unlocked in your organization by modeling processes as code (e.g. capital formation, bottoms-up information processing, streamlining delegation of power, tapping into a decentralized workforce, etc). And rather than trying to build everything on-chain, it’s more productive to ask where building on-chain helps your organization achieve its goals (e.g. censorship resistance, composability across the web3 ecosystem, innovative economic models, etc).
• Focus on niche use-cases: Despite the limitations of today’s internet organization tooling ecosystem, certain well-defined use cases — investment clubs, DeFi protocols, NFT communities, professional guilds, fundraising, etc — are served reasonably well with current tooling.
• Explore beyond the blockchain: Building on-chain can be slow, expensive, and risky. While blockchain can be a powerful tool to control the flow of power and value in an organization, it’s not necessarily the right tool for every single internet organization. For example, organizations like Wikipedia have been able to harness the power of a decentralized network of contributors without any blockchain component. Online governance is bigger than blockchain, and looking beyond the blockchain may enable you to build faster. In fact, many “DAO tools” are mostly web2 products with a wallet login.
• Build the ecosystem: While the limitations we’ve explored may be discouraging for some, they will be a call to build for others.

Thank you to Daniel Ari Friedman, Spencer Graham, Lucia Korpas, Eike Post, Nathan Schneider, and Philip Sheldrake for reviewing and giving feedback on earlier drafts.