However, trust itself remains poorly defined. "Trustless," "trusted," "trust assumptions," "trust-minimized" — these terms get thrown around constantly in coordination discourse. They are used loosely and often each mean something different. Even scholars can't agree. Williamson (1993) calls calculative trust a contradiction in terms, Gambetta (1988) models trust as subjective probability, while Rousseau and colleagues (1998) conclude that deterrence isn't trust at all.

An engineering discipline requires a clear, actionable model of what trust is. This article introduces just that.

I propose that:

1. Trust is a prediction — a principal's probabilistic forecast of an agent's behavior, strong enough to guide a decision.

2. Trust is about resources — concerns the principal's resources that may be impacted by the agent's behavior.

3. Trust is contextual — always scoped to an agent, a domain, and an environment.

4. Trust has two components — informed by what the principal knows about the agent (which I'll call pistis, borrowing from Jordan Hall) and how the environment shapes the agent's behavior (hardness, borrowing from Josh Stark).

5. Trust is measurable in resource value — quantified as the maximum resource exposure a principal would accept in a given context.

My goal with this model is to make trust not just describable but also engineerable.

1. Trust is a Prediction

Any time you lend a friend your car, grant a team authority over a budget, or enter a partnership, you are placing your resources under someone else's discretionary control. That is delegation: one party (the principal) relying on another (the agent) to act in a way that (hopefully) furthers the principal's interests. Delegation can be hierarchical, like a board appointing a CEO; or reciprocal, like cofounders splitting responsibilities, in which case both parties are simultaneously principal and agent.

Since delegation exposes a principal's resources to risk, they will delegate only if they are sufficiently confident that their agent won't abuse their resources or if the potential payoff is worth the risk. The latter is important and warrants an investigation of its own, but our focus in this article is on the former. The principal's confidence is a forecast: a prediction of the agent's behavior within the context of the delegation. That prediction is trust.

There is precedent for this view. Gambetta, notably, defines trust as "a particular level of the subjective probability with which an agent assesses that another agent will perform a particular action, both before he can monitor such action and in a context in which it affects his own action." Trust matters precisely because it drives the principal's decision about what to delegate, how much, and to whom.

2. Trust is About Resources

Those decisions — what to delegate, how much, and to whom — are decisions about resources. A principal doesn’t predict an agent’s behavior in the abstract; they care about behavior because of its impact on their interests. To give this precision, I model everything the principal cares about, including everything that may be at stake in a delegation, as a resource. The prediction that constitutes trust is, fundamentally, a prediction about what will happen to the principal’s resources as a result of the delegation.

What counts as a resource? In my model, nearly everything: physical goods like foodstuffs and building materials, digital goods like software and information, conceptual goods like money and intellectual property, and relational goods like reputation and privacy. What makes them all resources is that the principal values them, and the agent's behavior can affect that value.¹ And in every case, the principal is asking the same thing: can I trust you with these resources? My car? This data? My child’s safety?

Importantly, the resources at stake extend beyond those the principal explicitly delegates. Delegating access to electronic data may not risk the data itself, but the agent could use that access to damage other resources the principal values. This full footprint is the principal's resource exposure: everything at stake as a result of the delegation, not just the budget, data access, or materials handed over.

3. Trust is Contextual

As a principal's prediction, trust is necessarily perspectival: it is the principal's perspective about a specific agent within a specific context. Alice's trust in Bob to cook dinner is a different prediction from her trust in Bob to manage a treasury. As Hardin (2002) puts it: A trusts B to do X. Saying "I trust you" is always shorthand — with what? and to do what? The full statement specifies the agent, the domain, and the conditions.

We can break down context into two distinct components: a domain (subject of the delegation) and an environment (external conditions). The domain is the objectives and tasks the principal wants the agent to complete on their behalf, as well as the resources the principal delegates to accomplish them — the subject of the delegation — which, as we established in the previous section, are what the trust prediction is ultimately about.

Abstractly, the domain comprises the set of potential actions the agent may take that are either enabled by the delegated resources or may impact the principal's resources at stake. Our earlier examples of delegation were primarily framed in terms of domain: driving a car, managing a budget, and cooking dinner. Consider entering a partnership: in this reciprocal delegation, two individuals endeavor to collaborate towards a common goal. That goal, and the resources they pool to achieve it, constitutes the domain.

The environment is the set of external conditions that shape which actions an agent can or is likely to take in relation to the domain. The reciprocal delegation of a partnership is forged with legal documents that define the bounds of the partnership itself: what each partner is allowed or not allowed to do, and how those rules are enforced. Those mechanisms are part of the environment.

4. Pistis and Hardness: The Two Components of Trust

Thus far, we've established that trust is a prediction, and that this prediction is made in relation to a context composed of both domain and environment. It follows, then, that trust must be informed by both. The principal's read on the agent matters, and so do the environmental conditions that shape the behavior of any agent in that position. This is where my model parts ways with much of the trust literature.²

Williamson argues that "calculative trust" (reliance based on rational incentives) is a contradiction in terms. Rousseau et al. go further: they conclude that "deterrence" (compliance enforced by consequences) is not trust and exclude it from their model. On this view, environmental constraints are a substitute for trust — control rather than confidence. I disagree: if trust is the prediction, and the environment changes the prediction, you cannot exclude the environment's contribution. The prediction is trust; you cannot separate the output from one of its components.

Consider a familiar case: you meet someone and learn they attended your alma mater. You immediately trust them a little more. Most people would call this social trust — a sense of shared identity, common experience, maybe even shared values. And some of that is real. But much of what's actually at work here is the web of mutual connections you likely share: second- and third-degree relationships that create latent reputational accountability. If this person wrongs you, word travels through a network that matters to both of you. At worst, you know how to find them. That influence on their behavior is environmental, not personal; and it is doing more work than many people realize.

This environment — a shared alma mater — is just as important as the actual personal relationship that develops between those two people. An actionable model of trust needs to account for both, separately, so we can reason about how they combine and how to strengthen each one.

Pistis

The first component of trust draws from the principal's assessment of the agent itself: who is this person? what is their nature? Borrowing from Jordan Hall (2026), I call this pistis.

Pistis corresponds to the delegation domain. Adapting Mayer, Davis, and Schoorman's (1995) well-known framework, a principal's pistis for an agent reflects their assessment of the agent's competence, integrity, and intrinsic alignment (shared values, identity, mission). Track record, judgment under pressure, character: these are all properties of the agent as the principal perceives them, not of the environment. Reputation in this sense serves as an information input to pistis; a compressed record of how the agent has behaved in prior contexts.

Hall's description of pistis is excellent:

[The] capacity to enter into a relationship of calibrated mutual reliance — a relationship grounded neither in naive hope nor pragmatic contract but in demonstrated reliability, transparent action, and progressive deepening. [...] You decide to work together on something small. They deliver. Or they don't. Over months, maybe years, you build a picture of who they are. But that picture is always partial, always mediated by narrative — theirs and yours. People perform reliability. People perform transparency. And the performance is sometimes indistinguishable from the real thing until the moment it isn't.

Once pistis exists between two parties, the marginal cost of creating trust is very low. Teams with strong pistis move fast precisely because they don't burn energy on verification. But pistis is formed through direct experience, and it is expensive to build. As Hall describes, it is slow to form, fragile, and it doesn't scale easily. Dunbar's number is essentially the point at which we run out of bandwidth for building and maintaining pistis.

Hardness

The second component of trust is derived from the environmental factors that shape an agent's behavior, regardless of who the agent is. Borrowing from Stark (2022), I call this hardness.³ Where pistis asks "who is this agent?", hardness asks "what could/would any agent in this position do?"

Hardness ranges on a continuum from soft to hard: from social norms and reputational accountability to structural incentives (token stakes, collateral, profit-sharing) and institutional mechanisms (laws, contracts, professional licensing) and physical laws and smart contracts.

Some hardness is pre-existing — inherited from physics, geography, existing social networks, or legal jurisdiction. But much of it can be engineered. Stark notes that humanity has progressively learned to create hardness: first by harnessing atoms, then by building institutions, and now by creating blockchains and deploying smart contracts. Hardness is a design lever for engineering trust. You can choose how much hardness to build into an environment, what kind, and at what cost.

The cost structure of hardness varies across the spectrum. Institutional hardness can be expensive to establish and enforce (lawyers are not cheap). Smart contracts, by contrast, can be deployed relatively cheaply and are essentially free to maintain. But since both mechanisms are agent-agnostic, hardness scales where pistis cannot.

Trust = Pistis + Hardness

This is the core of the model: trust is the aggregate of pistis and hardness, a single prediction composed of both inputs. To see why, consider how the two interact. Within a given delegation, pistis and hardness are economic substitutes. A principal can reach the same level of trust through different compositions: high pistis and low hardness, or the reverse, or any mix in between. For example, a malicious agent who bonds $50k in a slashable contract can still be trusted with up to $50k. Even though pistis is zero, hardness is high, so the principal can still trust the agent in this context.

But zoom out across time, and the relationship changes: pistis and hardness are economic complements. Return to the fellow alumnus you met earlier. The shared alumni network — the latent reputational accountability that let you trust them a little more — is a form of hardness. That hardness makes it safe enough to collaborate on something small, creating the opportunity for pistis to form out of direct evidence of their competence and character. As pistis grows, you're willing to delegate more, and eventually to build new hardness together: more scalable structures that couldn't have been built without the relationship.

This is roughly how healthy institutions work: the structure creates the conditions for relationships to form, not the other way around. Hall describes this as a progressive ladder — "observe, coordinate, depend, bind" — each step earned and also reversible if proven unwarranted. My model provides a mechanism for that ladder: hardness lowers the cost of the first step, and pistis compounds from there.

5. Trust is Measured in Resource Value

Earlier we asked: can I trust you with my car? With this data? With my child's safety? But there's a further question lurking in each of these: how much is at stake? Can I trust you with $100? What about $100K? If trust is a prediction about the principal's resource exposure, then it has a natural unit: the value of those resources. Trust is the maximum resource exposure a principal would accept in a given context — the trust capacity of that context.

The $100 case is easy since money comes in its own units. But the same logic applies to any resource the principal values. What we want to measure is resource value:⁴ the value of a resource to the principal, in whatever terms the principal can estimate it. It is this valuation — not the resource’s type or natural units — that provides a common denomination. Just like trust, resource value is always perspectival and contextual. Even $100K means something different to a billionaire than to someone living paycheck to paycheck, and your privacy matters more to you in some contexts than others.

Resource value is quantifiable. Not because every resource has natural units, but because principals are always making comparative judgments about resources. You may not be able to put a precise dollar figure on your privacy, but every day you trade it off against other resources, like access to social media or e-commerce convenience.

We can measure both pistis and hardness in terms of resource value. Because of the direct relationship between a principal's resources and an agent's incentives, hardness is correlated with resource value. A $50K slashable bond covers $50K of resource value, while a confidentiality agreement protects the value of the information it covers. If you can value the resource (as principals always do, even if implicitly), you can measure the hardness.

Pistis is less obvious. But consider: you'd trust a close friend to watch your kids for an evening, but you might not extend the same social trust to a neighbor you've only met once or twice. In both scenarios, the same resource (your child's safety) is at stake. The difference, entirely in your assessment of the person, has a clear magnitude; and it's denominated in how much that resource is worth to you.

Both components are denominated in the value of the resources at stake. That commensurability is what makes trust engineerable: we can substitute one for the other — if pistis drops, compensate with more hardness — and we can identify gaps. If a delegation requires a certain trust capacity, how much do we already have from pistis and pre-existing hardness, and where could the rest come from?

As an illustration, consider Alice delegating $100K of treasury authority to Bob. Based on their working history and personal relationship, she estimates that she would be comfortable delegating up to $60K to Bob in the domain of treasury management in the absence of any environmental conditions; this is her her pistis for Bob in this domain. Alice also requires that Bob post a $50K slashable bond. Together, $60K of pistis and $50K of hardness creates sufficient trust capacity for Alice to make the delegation.

But now replace Bob with an unknown agent: pistis drops near zero, and the $50K bond alone isn't enough. To close the gap, Alice could add more hardness (such as a tighter spending cap or requiring that the new agent get approval from Alice for certain types of transactions), or invest time building pistis with the new agent.

Let's look at one more example: a family choosing between two colleges for their child. At one school, the family has close ties to faculty and staff — people they've known for years and whose judgment they trust deeply. The school sits in a state with weak institutional oversight and limited liability for student welfare. At the other school, the family knows no one, but it operates under strict regulatory oversight, mandatory safety protocols, and serious legal exposure if a student is harmed through negligence. The compositions of pistis and hardness are nearly opposite in these two scenarios, yet both contexts can earn the family's trust.

Applying the Model: Trust and Fractal Delegation

The five propositions above define an atomic model of trust within a single delegation. That model is a primitive; a building block we can apply in many ways. One of the most revealing is to ask what happens in a delegation chain: Alice delegates to Bob, who delegates to Carol. What are the dynamics of trust across the links?

Each link is its own delegation. The agent becomes a principal themselves and forms a new prediction of their agent's behavior. But the two components of trust behave very differently across those links, in particular with respect to the principal's resource exposure. Pistis gives a principal confidence in their direct agent's behavior. But its relevance degrades with each nested delegation, because the domain gets narrower at each link. Alice's pistis for Bob in one domain does not tell her much about Carol in a narrower domain, even if Bob has pistis for Carol.

Consider a common corporate scenario. The CEO has high pistis for her VP in the broad domain of finance. The VP delegates a narrower sub-domain to a contractor. The CEO's pistis for the VP doesn't cover that narrower domain; it was never scoped to. So the CEO's resource exposure passes right through to the contractor. If the contractor shirks their responsibility, "my VP vouched for him" is cold comfort.

Hardness, on the other hand, does not degrade across delegations. A hard boundary at any point in the chain caps risk for everyone above it, regardless of what happens below. If the VP adds a robust contractor agreement with liability terms and a performance bond, the CEO's resource exposure is capped at that boundary, regardless of what happens downstream, of domain, or whether the CEO has ever met the contractor. In the AI delegation literature, Tomasev et al. (2026) call these boundaries "liability firebreaks."

In a delegation network, pistis must be assessed at every link. Hardness applied at any link can be relied upon throughout the entire chain. The ability to model both components of trust is what makes trust designable at organizational scale.

Toward an Engineering Discipline of Trust

The model defines an atomic primitive of trust: a single delegation, decomposed into measurable, designable components. From that primitive, we can formalize the tradeoffs between pistis and hardness, design environments that produce the right composition for a given delegation, and reason about how trust propagates through networks. For any given system, we can specify what hardness to build, where to invest in pistis, and how much resource exposure each part of the system can bear. We can ask what a given trust composition costs and perhaps even predict its impact on the expected payoff of a delegation. These are design questions, and they are answerable. An actionable, quantitative model is the foundation for an engineering discipline of trust.

The model already reframes one of crypto's most misleading claims. "Trustless" does not mean the absence of trust. Rather, it means a trust composition dominated by hardness rather than pistis. Blockchains combine cryptography and economic incentives to produce trust with minimal pistis requirements. The distributed computing and economic stake involved in that combination entails massive fixed costs, but it yields a platform for cheap, programmable trust in the form of hardness.

The need for this kind of trust engineering is more acute than ever. Humans' shared biology, priors, norms, and evolved social intuitions give us enough common ground that many behaviors can be assumed without being designed for. AI agents do not share this constitution. For non-human agents, the predictability assessments that humans make implicitly must be explicitly designed for.

Society will need entirely new coordination infrastructure. Establishing an actionable model of trust is how we begin.

My thanks to Brennan Mulligan, Sara Norval, Nick Naraghi, Alex Murray, dancingpenguin.eth, Shelby Steidl, and Abram Dawson for their helpful comments on earlier drafts.

1. Resources here are not limited to instrumental goods. Anything the principal values (including ends in themselves like relationships and privacy) counts as a resource in this model, because delegation can put any of them at stake.

   
   

2. Tomasev et al. (2026) arrive at a compatible decomposition from the AI delegation literature, defining trust as the delegator's degree of belief in a delegatee's capability to execute a task in alignment with explicit constraints and implicit intent. Their "explicit constraints" map onto hardness; "implicit intent" maps onto pistis.

3. Hall arrives at a similar concept through a different lineage, calling it horkos — the ancient Greek oath-bond, the ritual counterpart to pistis. "Computers are incapable of making promises," Hall writes. "But they are constructed from oaths." I prefer Stark's label: hardness foregrounds the material and institutional spectrum, where horkos emphasizes the binding act. Both capture the insight that predictability can be built into the environment, but hardness better serves an engineering frame.

4. Resource value is closely related to utility in the economic sense. Both capture the idea of subjective valuation from a decision-maker's perspective. I use "resource value" to avoid the baggage of expected utility theory, which carries assumptions about rationality, cardinal measurement, and probability weighting that are unnecessary here.

   
   

This article is my attempt to explore and explain why RetroPGF — or what I’m tentatively calling Retroactive Ecosystem Revenue Replacement (RERR?) — is such a promising innovation. I also make some associated recommendations for future rounds.

I) What is RetroPGF all about?

I believe that the program currently known as RetroPGF has the potential to revolutionize the way we fund “public goods.” As I see it, its purpose is to prevent the underproduction of OP Collective ecosystem goods with credibly neutral revenue replacement.

Part 1 of this article is devoted to breaking down and exploring that statement, organized by its key phrases.

The purpose of RetroPGF: to prevent the underproduction of ecosystem goods with credibly neutral revenue replacement

"Prevent underproduction"

Many goods that are underproduced because they can't generate enough income to cover the opportunity cost of producing them. Sometimes this is referred to as "market inefficiency," and sometimes it's called the "public goods problem." But as we’ll see in the next two sections, it's not just pure public goods that are underproduced. “OP Collective” As the OP team has repeatedly stated, RetroPGF is not for charity but a strategic initiative designed to maximize the long term value of the OP Collective. This includes, I think, the value of the $OP token. In other words, this is a selfish, for-profit program. It is focused only on promoting the development of goods that create positive value for the OP Collective. Any value those goods create for other ecosystems is welcome but purely incidental.

Of course, the mechanism itself is not limited to the OP Collective. Any other ecosystem can employ their own instance of it. What’s important to understand is that any single instance of the mechanism is focused on promoting the value of a specific ecosystem. "Ecosystem goods" An ecosystem good is a good that creates value for its ecosystem above and beyond its users' reservation price.

Ecosystem Good: A good that creates value for its ecosystem above and beyond the sum of its users' reservation prices

From classical economics, a person's reservation price for a good is the highest amount they are willing to pay for it. This is typically a function of the value they get from using the good as well as the available alternatives/substitutes. The more the good benefits them, the more they are likely to be willing to pay. And their reservation price for that particular good likely falls if there are other goods that could provide similar benefits.

What are some of the reasons why an ecosystem good might create value that is not reflected in its users’ reservation prices?

1) Non-excludability and non-rivalrousness ("public goods").

If a good is non-excludable, its producers can't prevent people from using it even if they don't pay. Natural resources like timber and fish stocks have this property. We, however, care more about goods that are produced, and a popular example is free public transport (we'll come back to this one).

If a good is non-rivalrous, one person's use doesn't diminish the ability for other people to use it too, and so there's no need to pay for the privilege to use it before others. A good example is broadcast media, including videos, podcasts, newsletters, etc.

Together, non-excludability and non-rivalrousness form the classical definition of a public good. A good is a public good, so the typical line goes, if it is both non-excludable and non-rivalrous. But such a categorical approach devolves into a mistakenly binary understanding, leading to heated disagreements about which projects count as public goods.

The reality, though, is that the differences between types of goods is much less clear-cut, for at least several reasons. First, excludability and rivalrousness are spectrums rather than discrete categories.

Second, excludability depends on the domain of interest. What looks like a club good (non-rivalrous and excludable) from one perspective may look more like a public good (non-rivalrous and non-excludable) from a narrower perspective.

Third, there's a similar phenomenon on the rivalry dimension, where the margins are important. No good is infinitely abundant, but a good can behave very differently when it's relatively abundant compared to when it's relatively scarce. Water, for example, likely feels like a non-rivalrous public good in a rainforest and more like a rivalrous precious resource in a desert.

Finally, excludability and rivalrousness are not always inherent properties of a good that cannot be changed. Consider the free public transport example. There, non-excludability is a choice! The producers of this good could easily exclude non-paying users — certainly you have paid bus or train fare in your lifetime — but they have chosen not to.

2) The user is the product

That last point is so important that one particular flavor of it deserves its own category. I'm talking about advertising.

In one (naive) sense, advertising is the perfect funding model for "public goods." There is a reason that goods like broadcast media, social media, and search engines have so many ads. Each of these is to varying-but-large degrees both non-excludable and non-rivalrous. So instead of charging people to use them, the producers of these goods sell to other people access to those users' attention and (in some cases) data.

This is great in a lot of ways. People get to use really valuable goods for "free," and businesses get a valuable opportunity to convince those people to buy other goods that may be valuable to them. But, as we know, those goods aren't really free. We pay for them with our attention and (in some dystopian cases) our private data.

Worse, the producers of those goods optimize for something other than creating value for their users. Instead, they optimize for creating value for their customers, the advertisers. This distorts the goods themselves, sometimes in ways that cause real harm.

3) Positive externalities and network effects

Many goods create positive externalities. Scientific research often creates lots of benefits in addition to answering the specific research question. Buying a beehive and keeping bees is a fun hobby but also helps pollinate local trees.

Some externalities result from network effects, where every additional user of a good makes that same good more valuable for all the other users. Media platforms, developer infrastructure, and web3 protocols all create a lot of network externalities.

Network effects are especially interesting because producers of goods with network effects have an incentive to charge lower prices to encourage more usage and garner stronger network effects. In fact, often the optimal price for the use of such goods is zero. No wonder social media networks are some of the largest purveyors of the user-is-the-product strategy.

As a mini-summary, this section made two primary points:

A) It's helpful in practice to think more in terms of degrees of “ecosystem good-ness” than in binary terms about public goods vs. non-public goods. It's not just pure public goods that we want more of.

B) The producers of goods can in some cases trivially change the properties of their goods, and are therefore subject to incentives that we might be able to influence with the right mechanisms, such as RERR.

“Credibly neutral"

It’s not enough to produce just any ecosystem goods. The goal is to produce as many ecosystem goods as possible that create net positive value. This requires that nobody in the ecosystem be able to place their thumb on the scales. If an undeserving good is over-rewarded, more deserving goods will be under-rewarded, distorting the resource allocation signals we’re working so hard to facilitate. Worse, producing goods for the ecosystem will become less attractive, resulting in less ecosystem goods.

"Revenue replacement"

Until RetroPGF came along, ecosystem goods were primarily funded with the type of financial resource called capital. Capital is an input into a productive process that seeks to create valuable outcomes or outputs. Examples of capital allocation include all forms of investment, business loans, crowdfunding mechanisms, and most grant programs. Because it is proactive, capital only has limited information to work with; capital allocators must place bets on which goods are going to be most valuable. Some of these bets pay off, but many do not. And many — many! — goods that would have been very valuable don’t even get a chance because no allocator had the necessary vision to fund them.

Retroactive funding is different. Rather than an expectation of future returns, it is a reward for having already produced valuable outputs or outcomes; it is the return that capital expects. And unlike proactive funding, retroactive funding gets to work with the full knowledge of how much value a certain good created.

The most common form of retroactive funding is revenue allocated by paying customers. When you buy a good at the store, you are sending revenue to the business that produced the good. For that business, revenue is the return on the capital invested in producing the good. Without the potential for revenue, there would be no — or at the least, far too little — reason to invest in that business.

As discussed in the last section, revenue from paying customers and resulting market prices are, under the right conditions, the best signals for allocating resources towards the production of goods. But as we've already seen, ecosystem goods don’t meet those conditions and therefore have a hard time earning revenue from paying customers. Since typical markets cannot effectively allocate resources towards them, the production of ecosystem goods is typically funded by non-market means such as proactive grants. And like other methods of proactive funding, grants programs often fail to maximize value created both by errors of commission and of omission.

Retroactive Ecosystem Revenue Replacement (RERR) brings the benefits of revenue-based funding to ecosystem goods. When executed properly, it ensures that all ecosystem goods are economically rewarded according to the value they created for the ecosystem in question, generating the resource allocation signals that lead to the full production of ecosystem goods.

Retroactive revenue replacement recognizes that some ecosystem goods are pure public goods that have no hope of earning revenue of any sort, while others can earn some revenue but not enough to warrant their full production. Retroactive revenue replacement replaces the revenue ecosystem goods cannot earn because of their ecosystem good-ness. The amount of retroactive revenue replacement a particular good should receive is given by the formula:

$$RERR (g, t) = V - E$$

Where…

• $$g$$ is the ecosystem good in question

• $$t$$ is the time period in question

• $$V$$ is the total value that good $$g$$ created for the ecosystem within time period $$t$$

• $$E$$ is the income already earned by (or other value accrued) good $$g$$ as a result of $$V.$$ Note that Income includes both actual revenue and proactive funding that does not expect a financial return, such as grants. It should not include for-profit investment.

One way to think about retroactive revenue replacement is as something like a government subsidy, but with a few key differences:

• Allocated by the ecosystem’s community itself rather than a centralized government

• Amounts are determined retroactively rather than proactively

• Any ecosystem good is eligible, not just those identified a priori

One last point. Just like actual revenue is the return that most proactive capital allocation expects, retroactive ecosystem revenue replacement creates the possibility of return on investment or a business loan. Allocating revenue replacement, therefore, to projects that received investment — including from venture capital — should be encouraged.

RERR creates an incentive for projects to focus on producing ecosystem goods as their primary business activity — as opposed to a side effect of their main business — as well as an incentive for investors to fund such projects.

II) How can future rounds better execute on this idea?

Here are my recommendations for Round 4 and beyond.

Change the name & clarify the purpose

Retroactive Public Goods Funding is a well-meaning label, but in practice it has been woefully misunderstood. “Public goods” is especially misleading, since it causes people to think only of pure public goods and miss the majority of what the program is trying to fund. And many people think the program is designed to fund any and all public goods when the focus is specifically on goods that create value for the OP Collective ecosystem. For all the reasons explored in part I above, my current best idea is something like Retroactive Ecosystem Revenue Replacement, or perhaps Ecosystem Goods Revenue Replacement.

Similarly, the OP team should work on clarifying and explaining the purpose of this program. A high leverage concept to explain further is the “$$impact == profit$$” framing of the objective. I would start by replacing profit with revenue, since the latter is more strongly correlated with value created.

Establish clear timeframes for each round

To actually serve as revenue replacement, RERR funding needs to be tied to a specific set of value created. The simplest way to do this is to set a clear timeframe for each round. For example, Round 4 could be defined to allocate funding to OP projects according to the impact they generated between January through June 2024. Require more regimented data and disclosures from projects Unlike actual revenue — which is paid by users who have decided the good is more valuable than the cost — the unique properties of ecosystem goods require that RERR is allocated by non-users. This creates a high need for accurate data, related to both the total value created by a given ecosystem good (V) and the amount of income the project already received for that value created (E).

Where should this data come from? Some of this data can be scraped from public sources, much like the excellent OpenSource Observer does. But much of the necessary data is either not publicly available or difficult for outside observers to know where to find. Rather, the people in the best position to supply that data are the project teams themselves. And since they are the most direct beneficiaries of RERR funding, it makes sense that they be required to supply it.

With badgeholder and community input, the OP team should establish a more detailed, specific, and extensive set of data requirements for projects to be eligible to receive RERR. Ideally this also includes information about how badgeholders and other analysts can verify the data they provide.

Create more tools to surface and share information among badgeholders

Even with extensive and accurate data provided with project submissions, sifting through all of the projects is no easy task. Already in Round 3 badgeholders had virtually no hope of reviewing all 600+ projects in the depth necessary to make fully-informed allocation decisions, and the number of projects will only grow from here.

Lists were a good start in the direction of sharing the load, but badgeholders need more and better tools to generate and share information with each other. Here are a few early ideas:

• A way to comment on data provided or claims made by a project such that other badgeholders can see it

• A way to flag or mark data or claims as disputed such that other badgeholders can see it

• More generally, a shared space for badgeholders to discuss projects asynchronously

Experiment with phased evaluation

Badgeholders are tasked with allocating to projects based on the fuzzy concept of “impact,” but are given no official guidance about how to assess impact in practice. While it’s correct for the OP team to not dictate this in a top-down fashion, it leaves each badgeholder with the extremely difficult challenge of simultaneously determining a) what they think counts as “impact” and b) the amount of impact created by each project.

I would like to see Round 4 address the sequential nature of these tasks with a multi-phased process. Here’s a very high level outline of how it could work:

• Phase 1: Establish what counts as “impact”. Badgeholders create a set of metrics and criteria for evaluating project impact. Given the many ways to create impact, the output of this phase should be a diverse set of metrics.

• Phase 2: Evaluate impact. Badgeholders evaluate projects based on the metrics and criteria outlined in Phase 1.

Experiment with goals => impact => metrics

We can take this phased approach even further. Much like measuring project impact is downstream of defining impact, defining impact is downstream of identifying goals and objectives. I hope to see future rounds incorporate more explicit goal-setting of some kind. Of course, the goals shouldn’t be dictated by the OP team; rather, they should be established in a bottoms-up, concave fashion.

Setting goals would have two primary benefits. First, it would provide grounding that would help determine how to measure impact, e.g. in Phase 1 described above. Second, it would help producers of ecosystem goods decide what to build.

Experiment with predictions

Prediction markets might help address the too-many-projects-to-evaluate challenge by pointing badgeholders to the projects most likely to have created high impact. Properly setting up a prediction market with well-tuned parameters is not easy, but I think it’s worth experimenting with.

Deprioritize near-term badgeholder expansion

There is a lot of work to do and a lot of experiments to run. Expanding the badgeholder group much beyond its current size is likely to make those experiments significantly harder to conduct, and unlikely to yield much incremental decentralization or credible neutrality benefits in the near term. I would therefore deprioritize expansion of the badgeholder group until more progress is made in other areas.

The goal of governance is to DO things. Governance is about taking ACTION.

Decision-making is important, but it is just one aspect of taking action.

“Governance = decision-making” is wrong

Governance is a specific category of coordination. All governance is coordination, but not all coordination is governance. Coordination enables a network of agents to work together to bring about change within some domain of the world.

When a network of agents has shared resources it can use to help bring about that change, it engages in governance to take actions using those resources. 

As a comparison, when a network of agents does not have shared resources, it engages in non-governance coordination to guide the separation actions of individual agents

The Anticapture framework models actions as cycles of four phases: evaluate, propose, decide, execute. 

In non-governance coordination, the network of agents together may engage in the first three phases. The decide phase generates signals that the individual agents use to guide execution of their own actions.

But in governance, the network of agents engages in all four action phases. The decide phase selects the action, which the network then executes.

To exclude the execution phase of actions from governance is to misunderstand what governance is.

“Governance = decision-making” is outdated

The mischaracterization of governance as decision-making is an artifact of the legacy world. It is a reflection of the incompleteness of the governance systems we’ve been limited to creating in the past.

Until very recently, it was literally impossible for agents in a network to collectively execute an action using the network’s shared resources. Instead, many legacy governance systems rely on trusting individual people to execute actions on behalf of the many. “Governance” came to refer to the process for deciding which action to trust a single agent to execute.

But we no longer live in that world. Thanks to blockchains and smart contracts, for the first time in human history we have the ability to distribute executive power across multiple agents. 

We can do this at smaller scales (up to ~15 agents) with multisig wallets like Safe. We can do it at medium scales (up to ~150 agents) with frameworks like the Moloch DAO v2 smart contracts, and we can even do it at large scales (thousands – perhaps millions? – of agents) with frameworks like the Governor smart contracts.

We are just starting to explore these new tools, but already we can create governance systems that actually cover the full breadth of governance. It’s time to update our understanding accordingly.

“Governance = decision-making” is dangerous

Limiting your conception of governance to just one part of the whole is a great way to design bad governance systems. 

If you ignore the actual goal of governance – taking action – you're liable to create a system that is exposed to capture, just like our broken governance systems in place throughout society today. 

The power to execute actions is where true hard power lies. Executive power can trivially override decision-making power. A capture-resistant governance system must distribute executive power as well as decision-making power. But a governance system that does not acknowledge the importance of the execute phase of actions will never be able to do this.

Time to DAO

Our new ability to design governance systems that actually cover the full breadth of governance is a profoundly important shift. We may look back on it as one of the most important advances in human history.

Let's use these new tools to their full potential. Let's build real DAOs.

Special thanks to the many people who have greatly influenced my thinking and provided feedback to various versions of this article: Nick Naraghi, Aaron Soskin, David Ehrlichman, Jon Hillis, Ven Gist, Tracheopteryx, David Phelps, Kames Cox-Gheraghty, Nich Kesonpat, Travis Wyche, Tae, Christian Lemp, Joshua Tan, Kevin Seigler, Chase Chapman, Marcus Phillips, Stefen Deleveaux, earth2travis, Daniel Ospina, Lane Rettig, Richard Bartlett.

We see the story of resource and governance capture so often we accept it as a fact of life.

An executive embezzles funds from his firm for a lavish vacation. A politician accepts “campaign contributions” from an industry consortium in return for supporting a law that unfairly crowds out new competitors. A corporate board chair guides her company to acquire a friend’s business for an excessive premium.

Constrained by the realities of the world of atoms, the safest way to manage resources shared by the many has been to place them in the custody of a trusted few. Organizations’ internal governance policies, striving to address the risk that even those few cannot be trusted, are backed by external governance policies enforced by governments.

Each of those governance systems are in turn forced to place shared resources in the custody of a few, creating opportunities for bad actors to capture an organization’s shared resources for selfish wants, or worse, to capture the very governance mechanisms designed to prevent resource capture in the first place.

This model of “security” by hierarchies of concentrated power has long been the status quo. While it has enabled organizations to help create the modern world of relative luxury in which we live, it leaves a lot to be desired. If humanity is to solve challenges like climate change and public goods infrastructure, we must come up with methods of managing shared resources with significantly lower risk of capture.

Recently, there has been a breakthrough. Blockchains and smart contracts have revealed a new trust model for governance over shared resources that relies instead on a combination of cryptography and wide distribution of power. This model makes possible a new category of governance, called capture-resistant governance.

The promise of capture-resistant governance is managing shared resources in a way that prevents capture of those resources by bad actors. In so doing, it also unlocks a new frontier of what is possible together. The amazing fluidity, flexibility, and adaptability exhibited by early web3-native communities is testament to what’s possible when our governance structures avoid capture of shared resources without the rigidity of traditional approaches.

This article introduces Anticapture, a framework for understanding capture-resistant governance. Anticapture seeks to understand the fundamentals of capture-resistant governance by examining how organizations – modeled as networks of agents – take actions to manage resources in service of their objectives.

By the time you’re finished reading, you’ll be equipped with the beginnings of a taxonomy and a set of terminology to use in the context of DAOs, decentralized communities, and capture-resistant governance.

This article begins by defining the key components of the Anticapture framework, and then puts it to the test to answer one foundational question:

1. Agents and networks

2. Shared resources

3. Actions and their four phases

4. Case Study: What makes a DAO a DAO

5. Where to go from here?

1. Agents and Networks

Agents are individual entities that have the ability to take actions. Agents can be individual humans, software acting on behalf of an individual or group (e.g., an Ethereum client), or a group of multiple agents.

Anticapture models any group, community, or organization of agents as a network. Networks provide grounds for formal analysis, including the relationships between nodes. One example is how the strength of those relationships impacts the network’s susceptibility to capture.

Networks where most agents have relationships with one another resist capture by relying on the game theory of repeated interactions – in other words, trust. On the other hand, when most agents in a given network do not have strong relationships with one another – such as in larger networks, when agents don’t initially know each other, or when some agents have anonymous digital identities – the network must rely not on trust but on stronger protections against internal capture. The next sections will explore where such stronger protections can come from.

2. Shared Resources

Anything we can use to do or get what we want – from basics like energy, food, and water to more complex things like financial assets, tools, and social reputation – is a resource.

When a resource is under the power of a single agent, we consider it a private resource.¹ Private resources cannot, by definition, be captured by internal agents. They can be captured by external agents unless the agent controlling the resource is autonomous (see the Execute section).

When a resource is under the power of a network of agents, we consider it a shared resource. Historically, shared resources have been susceptible to capture by agents both inside and outside the network.

The important difference between a private and a shared resource is the structure of power over it. Money, for example, can be owned either by a single person or by a company, government, et cetera.

Some resources can only be private. Short of mind control, nobody can force you to pay attention or to spend your time in a particular way. They may induce you to do so by changing your incentives, but the actual resources of time and attention remain under your power.²

Some resources can only be shared. Power over such resources is distributed and cannot be privatized. We call these distributed resources. One reason many distributed resources cannot be controlled by any single agent is that they are emergent properties of some larger system.

Like agents and (as we’ll see in the next section) actions, the Anticapture framework treats resources as recursive concepts. Agents can be networks of agents, and every action by a given agent is composed of smaller actions by sub-agents. Similarly, agents often use one resource to deploy a second resource with the goal of impacting a third resource.

The first level of resource in the previous sentence is often a coordination mechanism or governance structure. While in everyday discourse these aren’t often considered resources at all, the Anticapture framework treats them as such because actions taken by agents can impact them, and they can be captured.

While potentially daunting at first, this approach provides a simple way to model what can be complex dynamics, thereby laying the groundwork for both formal analysis and concise terminology.

3. Actions and Their Four Phases

Actions are how agents put resources to work to achieve their goals. All governance over shared resources is conducted via actions.

In the Anticapture framework, actions have four phases.

1. Propose: delineate the options on the table

2. Decide: select the preferred option

3. Execute: put the selected option into action

4. Evaluate: analyze the impact of the executed action

These phases are cyclical. The Evaluate phase of one action often feeds into the Propose phase of a subsequent action.

These phases are also recursive. Each phase is itself composed of all four phases. Network actions are composed of actions by individual agents. And this is fractally true at many levels. Organizational actions are composed of actions taken by individuals, which are composed of actions taken by networks of neurons.

The next sections examine each of these stages in turn, focusing on their role in the lifecycle of an action and how they relate to power over and susceptibility to capture of shared resources. As we step through each phase, keep in mind that fundamental power is power over a resource itself, while soft power is the ability to influence those with fundamental power.

Note that while an agent can capture a shared resource by accumulating either fundamental or soft power over it, the biggest risk is associated with fundamental power. Networks are most susceptible to capture during action phases where fundamental power is wielded, and therefore those phases are where capture-resistant mechanisms are most crucial.

Propose

The agent’s agenda is set in the Propose phase. What problems should the agent attempt to solve? Which choices should the agent consider?

Participation in the Propose phase within a network spans from centralized to decentralized, describing how widely distributed the power to add options to the network’s agenda is.

In networks where the agenda is informal and doesn’t define which actions can be executed, the power to propose is influential rather than fundamental. Proposals don’t impact these networks’ shared resources, so the risk of capture is low and a degree of centralization is acceptable.

However, in networks where actions must go through a formal proposal process – particularly those using capture-resistance mechanisms – the power to propose is an expression of fundamental power because it directly impacts the list-of-proposals shared resource. A decentralized Proposal phase is critical to protecting such networks from capture.

Decide

Options on the agenda are selected for execution in the Decide phase. Should the agent execute the proposal or not? Which of the proposed options should the agent choose?

Participation in the Decide phase spans from centralized to decentralized, describing the proportion of agents in the network having a voice in the decision-making process.

We often assume that decision-making is where the power lies. After all, bosses make decisions, and bosses have the power. Right?

Well, not quite. In the context of a network action that impacts a shared resource, bosses are indeed the final decision-makers, but more importantly they have the power to execute the actions they select. By itself, a decision about what action to pursue does not impact the network’s shared resources. To do so, the decision must be paired with execution.

Therefore, risk of capture in the Decide phase is not catastrophic. While there are in many cases benefits to decentralized decision-making, it is not a strict requirement for effective capture-resistance. We’ll see why in the next section.

Execute

In capture-resistant governance, execution is king. The Execute phase is where the selected action is brought to bear. It’s where the action is carried out, and where resources are deployed and affected.

Participation in this phase spans from centralized to decentralized, describing the proportion of agents in the network sharing the power to execute actions selected in the Decide phase.

As we’ve alluded to, in a network, agents who can participate in this phase wield fundamental power in the form of direct control over the network’s shared resources. If this power is concentrated in the hands of a few, the network is highly susceptible to capture by internal agents. No matter how decentralized the Decide phase may have been, there is nothing structurally preventing those with executive power from ignoring the result and executing their desired action.

Even if such a network avoids capture, centralized execution can have other negative effects. As we saw in the previous section, anybody without executive power involved in decision-making must win the favor of executives to see their recommendation put into action. Even if the Decide phase is technically decentralized, in practice a centralized Execute phase exerts a centralizing force on decision-making.

This is how many traditional organizations operate. Non-executives are subservient and have far less chance of having a significant impact on the organization.³

Decentralized execution changes the game. Where centralized execution creates existential capture risk, decentralized execution acts as a strong backstop to other forms of capture. As long as executive power in a network remains distributed across a wide portion of the agents, the network has flexibility to experiment with various forms of decision-making and evaluation.

Separation between decision-making and executive power is uniquely possible within capture-resistant structures. It is why decentralized decision-making is not a strict requirement. It is also why decentralized organizations can be fluid and adaptable. When executive power is decentralized, leadership can truly emerge from anywhere.

Due to its property of changing the state of the world, Execution has a second dimension. This occurs on a spectrum from dependent to autonomous, describing the extent to which execution can be stopped, altered, or otherwise interfered with by an external agent.

Most traditional organizations rely on rules and regulations imposed by a higher body for protection from internal capture. Actions they execute are subject to approval by external actors, which means they are susceptible to capture by those same actors. A network that executes actions autonomously, on the other hand, is resistant to capture by external agents.

Evaluate

Agents analyze the impact of executed actions in the Evaluate phase. This evaluation often becomes an input into the Propose phase for subsequent actions, initiating new action cycles.

Participation in the Evaluate phase spans from centralized to decentralized. The degree of decentralization is often determined by the transparency of the network’s operations. If the network is organized on a public blockchain and communicates in public, even external agents can participate in evaluating its actions.

Evaluation is informational in nature and does not itself impact shared resources, so participants may wield influence but not fundamental power. While a decentralized Evaluate phase is often valuable, it is not a strict requirement for effective capture-resistant governance.

4. Case Study: What Makes a DAO a DAO

The Anticapture framework can be used to investigate a number of questions relating to capture-resistant governance, many of which we’ll explore in subsequent articles. Today, we start by examining one of the most burning questions in this space: what makes a DAO a DAO?

Most approaches to answering this question to date default to referring to particular technologies (e.g., “A DAO is an organization run via smart contracts”) or prescribing structures (e.g., “DAO members have tokens and use them to vote on proposals”). For a definition to endure beyond existing implementations, however, it must remain un-opinionated and stick to first principles.

With the Anticapture framework in hand, we can conceptualize DAOs as a strong form of capture-resistant governance. In a sense, this means that DAOs inherit the basic properties of the parent class of capture-resistant governance. Like any instantiation of capture-resistant governance, DAOs are networks of agents, they manage shared resources, and they have a purpose.

A DAO’s purpose does not need to be explicit, and a DAO might have more than one purpose. Indeed, a DAO’s purpose(s) might even emerge from varied motivations of the agents in its network. To say that a DAO has purpose is simply to say that it acts with intent.

Finally, like other forms of capture-resistant governance, DAOs protect their resources to some degree from capture.

What distinguishes DAOs from those other forms is how and how strongly DAOs resist capture. Specifically, DAOs are resistant to capture at the most vulnerable point: the Execute phase (as explained above) — the point where a network takes actions over their shared resources.

When DAOs take actions that impact or leverage their shared resources, the execution of those actions occurs in both a decentralized and autonomous fashion. The decentralized aspect of the execution requires that all agents in the network share the power to execute actions, and is how DAOs primarily resist capture by internal agents. On the other hand, the autonomous aspect of the execution requires that no agents outside the network have power to execute – or alter – the DAO’s actions, and is how DAOs primarily resist capture by external agents.

Putting it all together, we can summarize as a single-sentence definition of a DAO:

A DAO is a network of agents who share common purpose, and are the only ones who hold the power to execute actions that manage a set of shared resources.

We’ll explore this definition and its implications often in subsequent articles. In the mean time, if you’re a DAO operator, you may be wondering why permissionlessness is nowhere to be found. That is intentional: since it is possible for executive power to be sufficiently decentralized without being open to the entire world, permissionlessness is not necessary to resist capture. In fact, in some circumstances permissionless participation can actually threaten a DAO’s resistance to capture by creating more attack vectors. Conflating decentralization with permissionlessness is one of the most common mistakes in the DAO space.

5. Where to go from here?

Your mission, should you choose to accept it, is to use the Anticapture framework in your thinking, discussions, and work related to DAOs and other forms of governance. When coming across a new decentralized community, or when working within your own community, ask yourself how susceptible it is to capture. What shared resources does it own and how does it manage them? How distributed (or concentrated) is the executive power?

As you do this, you may find that many communities calling themselves DAOs fall short of the criteria suggested by the Anticapture framework. Some of these aspiring DAOs may be structured as tokenized communities with a multisig treasury “controlled” by Snapshot signaling, where executive power is concentrated in a handful of multisig signers.

If you happen across one of these less-capture-resistant organizations, consider two things. First, how might it alter its structure to become more capture-resistant? And second, what valuable properties does it have that are worth exploring and should possibly be preserved in the new structure?

In this article we touched on the attributes that make capture-resistant governance a powerful new tool for human progress, and we used the framework in one example to better articulate what a DAO truly is. In future posts, we’ll explore the Anticapture framework further and in more detail to develop a full taxonomy of the many forms of capture-resistant governance.

Until then, good luck resisting capture!

Footnotes

1. “Private” in this context refers to the general concept of power and control described here, not to the specific exercise of power in the form of access control or obfuscation (as in “privacy”).

2. Claims on such resources, however, can be shared.

3. Social dynamics and reputation can mediate these effects, but only partially and under certain conditions, such as when executives have public reputations to uphold.

Welcome to Part 3 of our Goodhart’s Forest series on DAOs and tokens. Previously, we’ve examined the dangers that lie within the Forest and how DAOs can keep themselves safe. Here, we’ll explore how a DAO might safely leave their Garden and enter the Forest.

As protection from the mutually-amplifying forces of Ethereum’s permissionless, adversarial Dark Forest and Goodhart’s Law, a DAO can construct a Safe Garden in which their members can iteratively align around both their shared purpose and their method for achieving it. With permissioned membership, share-based voting, minimalist governance architecture, and ragequit, Moloch DAOs make excellent Safe Gardens.

Many DAOs will be perfectly satisfied to remain forever in their Gardens. But some DAOs, once they’ve matured, will benefit from entering the Forest.

Why leave the safety of the Garden? The very attributes that make Goodhart’s Forest scary are what make it attractive. Once a DAO has sufficiently honed its purpose and operations, the power of token incentives and the freedom of the permissionless Ethereum environment evolve from risks to opportunities.

How to Leave the Garden

Even a mature DAO can’t just open the gate and step out into the Forest. Leaving its Garden requires preparation and — just like iterative alignment itself — a careful, gradual process.

To begin, we start at the end. A DAO that has entered the Forest will be coordinated by permissionless token governance. Here are the steps a moloch DAO can take to get there:

1. Permissioned Token Access

2. Tokenized Access to Governance

3. Permissionless Token Access

4. Fully Tokenized Governance

Step 1: Permissioned Token Access

The very first thing to do is to create the DAO token (which we’ll refer to as $TOKEN). The DAO should be the owner of the $TOKEN contract and have full control over the supply and distribution of $TOKEN.

Next, the DAO can begin to get the token into the hands of its community. That certainly includes the current DAO members, but it should also include some non-members; after all, one of the points of leaving the Garden is to enable the DAO to coordinate and benefit from interactions with a broader group of people.

The DAO has a few options for how to distribute $TOKEN. It could distribute it to verified contributors—such as current members, non-members who have contributed time, work, or funding—proportional to the contribution as determined by DAO proposal(s). Or it could devise a more mechanistic system such as Transmutation, which fills the DAO with $TOKEN in proportion to the funds the DAO disburses to achieve its goals.

Crucially, at this stage the token is not transferrable and there is no market price for $TOKEN. This is important because the DAO needs time to get it into the hands of those who are aligned with the DAO’s success. If Dark Forest predators can sink their teeth in before there is a strong base of DAO-aligned $TOKEN holders, the whole process would be at risk.

There are a couple ways the DAO can keep $TOKEN from becoming liquid. First, as the owner of the $TOKEN contract, it could alter the `transfer` functionality so that only the DAO could transfer it. Or second, it could lock $TOKEN within the DAO itself, and only “distribute” it to contributors via DAO shares or loot (non-voting shares). This is one of the features of Transmutation, and it has the secondary benefit of beginning to expand the DAO membership.

Remember, at this stage the token is still not tied to DAO governance. DAO governance decides how the token is distributed and held, but the token cannot yet be used to influence governance decisions.

Note: while a DAO can begin this process at any stage in its life, there may be some benefits to starting early, e.g. tracking early DAO contributions.

Step 2: Tokenized Access to Governance

Once the token has been distributed to a broader DAO-aligned community, the DAO can start using the token to control access to governance. This could take the form of requiring new membership proposals to include $TOKEN as tribute, or perhaps enabling $TOKEN holders to signal their preferences via snapshot voting.

Step 3: Permissionless Token Access

The DAO can also start lifting access control on the token, allowing DAO members and other $TOKEN holders in the broader DAO-aligned community to transfer $TOKEN without permission. The likely result is for a new market for the token to be created (perhaps on Uniswap or Balancer), from which a market price for $TOKEN will emerge.

With that price comes certain benefits, such as the ability to better value and reimburse DAO contributions; but also certain risks, such as exposure to market forces and adversarial actors. That is why its so crucial that the DAO have a robustly defined purpose for the token to represent and for the base of $TOKEN holders to be firmly DAO-aligned.

If the DAO had modified the `transfer` method in step 2, it could now return it to normal. If it had instead locked up $TOKEN inside the DAO, it could now encourage members to either submit funding proposals to receive their $TOKEN allotment or to withdraw their allotment by ragequitting shares and/or loot.

Some DAOs may find that ensuring a liquid $TOKEN market is in their best interest. These DAOs could seed a liquidity pool or even create incentivizes for others to provide liquidity to that market. Of course, such decisions should be made thoughtfully and in recognition of the attendant financial and regulatory risk.

Note: depending on a DAO’s circumstances, step 3 might make more sense earlier or later.

Step 4: Fully Tokenized Governance

Finally, the DAO is ready to fully melt into the community. What might this look like?

It is early, the design space is huge, and there is much research and experimentation to be done, but here are a few possibilities:

• Allow anybody who has $TOKEN to permissionlessly stake it in return for voting shares in the DAO (e.g. with a Moloch V3). Maintaining the shares concept in this way has the advantage of also maintaining ragequit (right to exit).

• Allow anybody who has $TOKEN to stake it in return for voting shares, but conditional on permission from the existing members. Together with ragequit, permissioned membership is an additional protection against hostile takeovers and other adversarial risks.

• Fully tokenize shares and voting—more akin to Compound-style governance.

Previous entries in this series

https://mirror.xyz/hq.spengrah.eth/3rogxz8MYh5SEIdCCzUXWY7eiKAs63QSgsPh-AfIRyk

https://mirror.xyz/hq.spengrah.eth/HLKF1_DKaAku_spLlnYyZKSLpqaGsPhzzijXCDsvfUU

Welcome to Part 2 of this series on Goodhart’s Forest and what it means for tokens and DAO governance. I recommend giving Part 1 a read before continuing on:

https://mirror.xyz/hq.spengrah.eth/3rogxz8MYh5SEIdCCzUXWY7eiKAs63QSgsPh-AfIRyk

In Part 1, we looked at the three dangers lurking in Goodhart’s Forest:

1. Tokens are unlikely to reflect the full breadth and nuance of their project’s goals.

2. Noisy markets fray the connection between the price of the token and project’s success in meeting its goals.

3. In a permissionless market, adversarial actors can use a project’s token to threaten its success.

These dangers impact protocols’ ability to use a token for governance and coordination. Token-governed DAOs are no exception.

In particular, a token-governed DAO is at high risk of its own members making decisions that stray from the DAO’s goals because they are optimizing for the price of the token (from Danger #1), especially as the token price fluctuates in the noisy market (Danger #2). Additionally, such a DAO is powerless to stop Dark Forest predators -- including rival DAOs -- from voting maliciously or manipulating the token price to damage the DAO (Danger #3).

Here’s Zefram Lou, again, telling it like it is:

The value proposition of naive token-based voting systems, that token holders are incentivized to participate in the process and make decisions beneficial to the project, is simply without basis in reality.

Staying Safe in the Forest

For some time, the debate around the merits of token-based governance has been binary: you’re either for it or against it. Thankfully, some nuance has recently started to enter the conversation.

https://twitter.com/VitalikButerin/status/1316292848115871747

The distinction between “agile things” and “quasi-automata” is another way to think about Goodhart’s Law. The more clearly defined a thing is, the easier it is to find a metric that fully reflects the thing’s objective(s) and therefore the less likely creating an incentive out of that metric will backfire. Conversely, when a thing is in flux, defining a quantitative representation of its objectives is quite difficult and therefore less likely to succeed.

In this framing, we can see how Goodhart’s Forest is especially hostile to younger DAOs that are still figuring out what they want to do and exactly how they want to do it. And we can also see how a mature DAO — one that has refined its purpose and hardened itself to adversarial attacks and adverse market conditions — may be safer in the Forest.

How, then, can a young, vulnerable DAO give itself space to mature? The answer is to construct a safe Garden walled off from the rest of the Forest.

Building a Safe Garden with a Moloch DAO

1. Put up walls and a gate. Protect your DAO from adversarial Forest predators by making participation permissioned.

2. Don’t use a token. If there’s no token, there’s no target metric to fall prey to Goodhart’s Law.

3. Don’t hard-code operational logic. Leaving room for the social layer of the DAO to handle the bulk of coordination empowers the DAO to iterate on its purpose and operations.

If those ingredients sound familiar, they should, since they are primary properties of moloch DAOs. Moloch DAOs are permissioned, don’t use a token, and have a minimalistic, non-opinionated proposal system that pushes the majority of coordination to the social layer of the DAO.

Permissioned participation In a token-governed DAO, anybody who holds the token is able to participate in DAO operations. The intent is for only people who want the DAO to succeed will choose to hold the token, but there’s nothing stopping speculators (Goodhart’s Forest danger #2) and adversarial actors (GF danger #3) from also acquiring the token.

In a moloch DAO, on the other hand, new participants must be explicitly admitted by the existing members, which protects against those dangers. That protection contributes to the high degree of trust a moloch DAO engenders among its members, which creates room for them to take small risks together and helps the DAO iterate on its operations.

Share-based voting Membership in a moloch DAO is defined by having shares in the DAO. Those shares are not transferrable and have no price, which avoids Goodhart’s Law (GF danger #1) altogether.

Unopinionated proposal system Moloch DAO members vote on proposals with their shares. Successful proposals trigger on-chain actions like granting new shares to new or existing members, transferring DAO funds, or interacting with other smart contracts (via a minion).

What’s relevant for our purposes is that the technical conditions for a proposal to pass are as simple as can be: all a proposal needs is a simple majority of shares voting Yes, with no quorum. That simple framework enables each DAO to establish their own socially-determined conditions for proposals.

For example, Raid Guild has a rule that new members receive 100 shares in return for sending the DAO 500 DAI as tribute. The rule is technically informal; its enforcement comes not from smart contract code but from a social agreement among the members. And since it’s a social rule, the DAO has the flexibility to change it by rough consensus. Raid Guild has done just that with the creation of its Apprentice program that allows new members to work their way into the Guild instead of tributing 500 DAI.

By using social consensus to establish and enforce the majority of its rules, a DAO can be much more agile, which can help it refine its operations and mature more quickly.

Right to exit In addition to voting weight, moloch shares grant their owner a proportional claim on the assets in the DAO’s treasury. At any time, a member can exit the DAO, relinquishing their shares and receiving their proportion of the DAO’s assets. This concept, known as ragequit, is perhaps the most important property of moloch DAOs. Much has been made of ragequit’s protections against the tyranny of the majority. Less appreciated is how ragequit catalyzes a DAO to iteratively align around its purpose.

Because any member can ragequit at any time, every change to the DAO creates a decision point where members choose whether to stay or to go.

Every change in the DAO—e.g., new members added, funds disbursed, and changes in socially-enforced rules—creates a slightly different version of the DAO with slightly varied purpose and operational approach. Each member that stays with the DAO after the change has implicitly endorsed the new version. Even when a member does ragequit, the remaining members are even more tightly aligned around the DAO’s purpose.

Iterative alignment and protection from adversarial forces are the keys to staying safe in Goodhart’s Forest. The four properties of moloch DAOs form a safe Garden for DAOs to grow.

Leaving the Garden

Once a DAO has grown up within the protection of its Garden, it can start thinking about entering the Forest. How a DAO can make that transition will be the subject of Part 3 of this series.

Previous Entries in This Series

https://mirror.xyz/hq.spengrah.eth/3rogxz8MYh5SEIdCCzUXWY7eiKAs63QSgsPh-AfIRyk

Tokens are incredibly powerful incentive mechanisms, and power corrupts.

Welcome to this multi-part series, in which we’ll explore why tokens are so powerful, how things can go awry, and what can be done about it.

The challenge of human coordination is a challenge of alignment. The first step to accomplishing something as a group is to get all the individuals in the group to care about the same thing. When the group is small and homogeneous the task is easy, but aligning the tangle of divergent interests within a large and heterogeneous group can be extremely difficult.

According to all the corporate management books ever written, the best approach is to establish a small set of target metrics that represent success for your organization, and then rally everything in your organization around achieving those targets. Popular frameworks like KPIs and OKRs follow this basic principle, and it’s easy to see how they’re beneficial. Focusing on just a few metrics makes it easier to communicate and get buy-in from everybody in the organization, and, most powerfully, you can create incentives based on those metrics.

Goodhart’s Law

The power of incentives cannot be overstated. Properly devised incentive mechanisms can supercharge a group’s ability to efficiently optimize for its selected target metrics. Which sounds great — and it is, provided that those target metrics are a proper representation of the organization’s goals.

Unfortunately, metrics have an awfully hard time representing human goals. We humans are messy, fuzzy things, and often our goals cannot be reduced down to one or even a few quantifiable metrics.

Let’s examine a counter-example. Pick your favorite sport: baseball, hockey, football, the other football, curling, whatever. In every sport, there is a clear and quantifiable objective: score more (or fewer--golf is weird) points than your opponent. Or actually, is the objective to win championships? Or is it to make the most money, for example from ticket sales and sponsorships and TV deals? And if we think about it some more, are all the members of a sports organization aligned behind the same goals? Sometimes yes, but it’s pretty obvious that more often the answer is no--think of the replacement-level player who clammers for more playing time over their more talented teammate.

If even the most contrived human experiences turn out to not have clean, quantifiable objectives, imagine how blurry things can get in real life!

It gets worse. It gets worse because people still try to create target metrics. And when those targets inevitably fail to capture the full richness of human goals, those humans with their rich, messy objectives start to game the targets. They change their behavior to rack up the points without adhering to the spirit of the targets. Salespeople sell products at negative margins to meet their revenue quotas, NBA players bounce the ball off their own rim to add to their rebound total, and governments create policy to maximize GDP or the stock market without taking proper care of their most vulnerable citizens.

This is Goodhart’s Law:

“When a measure becomes a target, it ceases to be a good measure.”

The problem is not that incentives don’t work. Just the reverse: incentives work so well that when employed alongside target metrics that are ill-matched to an organization’s actual objectives, the organization ends up becoming extremely efficient at achieving a goal quite different from the one it originally was created to achieve. The organization serves the metric instead of the other way around.

Goodhart’s Forest

Token::Goal Misalignment

Tokens are what you get when you combine a target metric with a built-in incentive: you get an incredibly powerful mechanism for motivating people to do things! This power is why tokenomics is such a promising field and why so many protocols are using tokens to coordinate their communities.

But, if you read the previous section, you know that there’s a catch: while the value of a protocol’s token is meant to reflect the success of the protocol, it’s very difficult to design a token that actually captures the full breadth and nuance of the protocol’s goals. And the price incentive built into tokens leaves them especially vulnerable to Goodhart’s Law.

This give us Goodhart’s Forest Danger #1: A project’s token is unlikely to reflect the full breadth and nuance of the project’s goals.

Noisy Markets

The power of tokens’ built-in price incentives is related to why markets are often efficient at allocating resources. However, efficient markets have a number of important properties ensuring that price signals are mostly free from noise, such as low levels of information asymmetry and market manipulation.

If there’s one thing everybody in crypto would agree on, it’s that the current market is riddled with inefficiencies, manipulation, insider information, and a million other issues that obscure true price signals. This presents another problem for tokens as coordination mechanisms. As Zefram Lou puts it:

When the noise term is way larger than the actual value, that's where everything falls apart: the success of the project is basically irrelevant to the token's price! And that's exactly the case with essentially all tokens.

Within the narrow context of a token’s home protocol, supply and demand for the token will — for a well-designed system — reflect supply and demand for the protocol’s services and functionality. But no token lives within a quiet walled garden. Rather, every token lives in the noisy Forest.

Goodhart’s Forest Danger #2: Noisy markets fray the connection between the price of the token and project’s success in meeting its goals.

Monsters Lurk

What makes the Forest so noisy? Some of the noise — like the FOMO shouts from uninformed retail traders — is merely random din that washes out in the long run. More concerning is the noise made by mempool monsters, adversarial whales, and other protocols throwing their weight around.

The Forest is a permissionless and adversarial environment. Anybody can buy the token and do whatever they want with it. And anybody can create a new protocol that influences the tokens from other protocols!

For example, when Sushiswap introduced its vampire mining program, the tokens included as farming assets saw huge increases in demand. In particular, the $UMA token price rocketed from around $6 to as high as $27, which in turn led to higher APYs from and additional activity in UMA’s experimental liquidity mining program. As a result, we cannot evaluate UMA’s success by the price of the token that is meant to track that success.

Goodhart’s Forest Danger #3: In a permissionless market, adversarial actors can use a project’s token to threaten its success.

Recap

In Goodhart’s Forest, project tokens face three existential dangers:

1. Tokens are unlikely to reflect the full breadth and nuance of their project’s goals.

2. Noisy markets fray the connection between the price of the token and project’s success in meeting its goals.

3. In a permissionless market, adversarial actors can use a project’s token to threaten its success.

In Part 2 of this series, we’ll explore how projects can create a Safe Garden to protect themselves from the dangers of Goodhart’s Forest.