Grant Ships: The Evolutionary DAO Game

[deltajuliet]

Original Document

Grant Ships: The Evolutionary DAO Game

​Authors: Matt Davis (ui369.eth), Jordan Lesich (jord.eth)

Date: Feb 19th 2024

Executive Summary

The Grant Ships design detailed below is a comprehensive solution targeted at large DAOs with a decentralized vision.

We’ve learned that the “Evolutionary Container” is the core value prop of Grant Ships which can be implemented partially, iterating toward a fuller solution over time. While we’d love to see the comprehensive solution we detail here implemented in full, we believe that getting the iterative evolution flywheel in any shape or form is beneficial for any DAO and we support partial implementations as well.

Vision

Grant Ships is a meritocratic, evolutionary, capture-resistant grants framework/game that enables decentralized communities to deploy capital in an effective, transparent and accessible way.

Mission

At the heart of Grant Ships’ mission is a commitment to merit. We believe that the best way to distribute grants is to work within a game cycle where the best allocators receive the largest rewards and are given the largest portion of available funds to allocate. \

With Grant Ships, the best grants programs aren’t selected or even voted in through proposal. The best grant programs are discovered through open and decentralized competition followed by community votes to assess performance. \

Grant Ships aims to allow communities to evolve ideal grants programs that are responsive to the needs of the community, as communicated by the community itself.

Overview

Grant Ships is a competitive DAO game where a set number of “Ships” simultaneously operate their own onchain grants programs under a structured, codified ruleset. Over the course of a game round, they are free to implement their own grant allocation strategies.

When a round ends, the DAO is presented with each Ship’s portfolio including allocation decisions and grantee performance (e.g. milestones completed, value delivery metrics). DAO members then vote on the performance of each Grant Ship, ideally providing reasoning for their decisions.

In the following round, each Ship receives funds in proportion to the votes they received. If a Ship did not receive enough votes (i.e. by meeting a DAO-defined minimum threshold), they “crash and burn” and their spot becomes open for a new Ship Operator to fill. This feedback from the DAO sets the stage for the next round. The Ships take off from this new starting position, and again compete to best align with the DAO’s needs.

Over time, as a consequence of direct feedback and impact from iterative DAO votes, the most aligned Ships with the best allocation strategies rise to the top. This creates the “evolutionary” factor that is core to the Grant Ships value proposition.

The Need for a Game

​With traditional DAOs, we usually only get 2 choices for how we distribute funds to contributors:

1. Make monolithic allocation proposals and vote on each one
2. Delegate large portions of the treasury to centralized councils and hope that they are effective, honest and aligned with the needs of the DAO.

The benefit of voting for every grant proposal is the transparency that results. Provided that the DAO contract automatically executes transactions following a vote, we can say that the DAO truly gets to decide which grant it wants to fund.

However, there are many drawbacks to this design, including governance fatigue, inactivity, and extremely high friction for contributors.

Centralized councils and workstreams offer a more streamlined alternative. Contributors needn’t spend weeks deliberating in forums and voters needn’t be concerned with deciding on every grant. However, councils have little incentive to deliver great results or remain accountable to external contributors.

Also, there is no incentive for voters to examine the results of a centralized grants program, and even if they were so inclined, the information is usually siloed across a constellation of Telegram chats, spreadsheets, and gated discord chats. \

Moreover, with both these models, we have no way of knowing who the talented actors are. We want the highest amount of capital to be stewarded by the best allocators who direct it to the most talented builders. To truly compare the results of one program versus another, we must have a controlled standardized system where programs compete under the same ruleset.

In other words, we need a game.

In the following sections, we will outline how Grant Ships leverages modular, onchain protocols to gain the focus and efficiency of centralized grants programs, while still maintaining a high degree of decentralization, voter signal, and most importantly: clear incentives to perform.

What is a Grant Ship?

A Grant Ship is an entity with permission to approve grant applicants and make allocations within the Grant Ships game. Ideally, these entities will be a subDAO. During each funding round, Ships are allocated funds to be distributed to successful Grant applicants.

Each active Ship can design and implement its own grants system, with the goal of providing grants to people or projects that support the known priorities of the DAO.

A Note about Milestones

This document will assume that Grant Ship Operators are granting and distributing grants that are milestone-based. Due to the modular nature of Grant Ships’ design, many other allocations strategies can be supported, but for simplicity we focus on milestones here.

Participant Roles

Participants within Grant Ships w/Allo are divided into 4 main roles:

• Game Facilitators
• Grant Ship Operators
• Grant Recipients
• DAO Voters

Role Permissions and Responsibilities

Each role’s permissions are tied to a Hats Protocol NFT. If you possess the hat, you have the permissions. The Top Hat grants permission to assign and unassign hats from other actors. This Top Hat should be held by the DAO’s governing body.

DAO Voters

• Distributing initial allocation of funds to the game contract
• Periodically voting on Ship performance to determine future funding levels
• Revoking and reassigning roles as needed

Game Facilitator

• Approving fund allocations (after due diligence, such as KYC and deny list accounting), allowing Grant Ships to distribute at their discretion.
• Activating or Deactivating the Grant Ship funding pools
• Withdrawing funds from deactivated Grant Ship Funding pools
• Flagging Grant Ships that are not operating in good faith, (e.g. Ships that have failed to make allocations, that make repeated attempts to fund bad actors, etc)
• Resolving Grant Ship flags that no longer apply
• Posting updates as needed

Grant Ship Operators

• Allocating (earmarking) funds for Grant Recipients
• Distributing funds to Grant Recipients when appropriate
• Capturing Grant Recipient details and including them in the disclosure
• Reviewing Milestones declared by the recipient
• Rejecting invalid Milestones
• Declaring Milestones for recipients (or recipient can do it)
• Posting updates as needed

Grant Recipients

• Registering as a potential Grant Recipient for grants
• Declaring Milestones (or Grant Ship operator can do it)
• Submitting milestone completion
• Posting updates as needed

This diagram shows the major actions available during the application and payout portion of a funding round. It does not include the TCR vote that informs funding levels, or the optional updates posted by each role.

Problem Statements and Solutions

This section aims to outline the problems we see with traditional grant programs and how Grant Ships provides solutions to each.

Problem: Undiscovered Potential

DAOs have no way of knowing who their community’s best allocators and contributors are.

• Monolithic grant programs have no point of comparison to weigh efficacy per token spent.
• Voters are usually only presented with the choice of continuing a grant program or killing it. This low-definition yes/no signal provides little meaningful or nuanced feedback for program managers.
• Without a regular assessment of performance, we aren’t determining who is doing a good job.

Solution: Experimentation and Adaptation

​The first developed strategy, GrantShipStrategy.sol, is based on milestones and direct funding. Direct funding is flexible enough that multiple Ships can try out different strategies to find out what works best.

• The GameManagerStrategy contract allows us to adapt other Allo strategies into GrantShips for additional experimentation (e.g. quadratic rounds, hackathon formats, etc).
• GameManagerStrategy contract provides an “A/B” test environment where we can more easily compare allocation practices.
• Transparency and feedback from the voting community create an evolutionary factor that should lead to the best allocation strategies thriving and propagating.

Problem: Friction and Uncertainty for Talented Builders

Qualified builders often find too much friction and uncertainty to justify the pursuit of a DAO grant.

• As a builder trying to get funded by a DAO, a lot of time and effort is spent identifying communities with funding opportunities, researching what they need, building reputation, networking, courting delegates, generating proposals, and if they are lucky enough to get feedback on a forum, fending off trolls in the comment section.
• It’s difficult to justify investing this time and effort, especially when outcomes are uncertain. Unless there is a clear path to getting a quick yes or no answer, most talent won’t even enter the scene.
• With direct DAO votes on grants, grantees are tasked with writing proposals to please the majority of the DAO (at the time of voting) and whoever is currently the loudest in the forum (at the time of discussion). Often this results in bland, omnibus proposals that are designed by committee.

Solution: Transparency and Clarity

​By leveraging Allo Protocol, we can provide a structured, predictable, and transparent step-by-step process. There is never any ambiguity about what to do next.

• The Grant Ships UI allows candidates to fully understand the opportunities in front of them. They can quickly assess which program suits their talents.
• Clearly defined roles and simple rules dispel uncertainty by providing transparent insight into the process as a whole.

Solution: Competitive, Merit-based Allocations

• Talented contributors have many programs to apply to. If they are displeased with the performance of one Ship, they can apply to another.
• In the voting round, Ship operators are judged by the performance of their portfolio. The Ships that seek great contributors will outcompete those who simply wait around for applications.
• Ships will compete based on contributor experience. The Ship that can provide the fastest response times, the best support, and even promotion will ultimately win the best contributors.
• Because Grant Ships splits the funding between smaller, more focused grants programs, Contributors never have to undergo the lengthy proposal process.
• Contributions are judged once the round is complete. This allows contributors to build according to their own vision.

Problem: No Way to Win: Opacity vs Transparency

Grant administrators can either invest a lot of time and energy in broadcasting their activities to the community, creating an overhead burden or they can stay more opaque and risk losing trust.

• It’s hard for program managers to make everyone happy. They can choose to focus on allocation at the expense of record-keeping to reduce overhead, but this creates opacity that may lead to suspicion and mistrust among stakeholders.
• On the other hand, radical transparency is great for voters, but the program manager spends more time publishing funding decisions, outcomes, communications, timelines, updating records, and tracking transactions that are scattered through many walled gardens, among many organizations.
• Even worse, all this work results in off-chain records that can be easily altered, deleted, or corrupted.

Solution: Passive Record Keeping

• Grant Ships solves this problem by using the chain as the central source of truth. Records are automatically generated, and fully transparent to all
• Record-keeping is a passive side effect of giving grants. Onchain transactions which are linked to immutable offchain data create a mesh of rich, indisputable records that help illustrate any user’s intentions and reasoning.
• In the app, onchain events are aggregated into easy-to-consume feeds that provide full context and insight into grants program operations.
• Additional content can be posted onchain by any actor within the system by publishing an UpdatePosted event.

Problem: Overhead, Waste & Redundancy

Repeated actions that are performed among many circles could be delegated to discrete roles.

• Grant allocators are often overly focused on creating systems for recipient applications and tracking distributions in spreadsheets. They could instead be exclusively focused on scouting for and allocating to great teams and projects.
• Every grants program has administrative overhead for reporting, KYC/KYB, securing funding, and more. All of this could be delegated to a well-designed governance and contract system and done just once per community.

Solution: Meritocratic Funding

• TCR voting at the end of each round lets an allocator’s performance at allocation serve as its best bet to secure additional funding. This frees grants programs from the overhead of constantly applying for additional funding when they should be focused on effectively allocating the funds they have.

Solution: Role Delegation

We integrated Hats Protocol with Allo in GameManagerStrategy and GrantShipStrategy to provide clear role distinctions and appropriate division of responsibility.

• Roles allow us to divide labor among different function calls. We now know, through immutable code, which role is responsible for which steps in the grant-giving process.
• Roles can be revoked and reassigned as needed.

Problem: Voter Fatigue and Context Overhead

Using a yes or no Vote for each Grant has way too much context overhead for the voting community and leads to voter fatigue.

• It’s not practical to expect every voter to gain context and make informed votes on every grant.
• Grant recipients each have massive overhead to educate the community on why their proposal is worthwhile and also on the outcomes after funding.
• The high overhead cost inhibits the provision of numerous voter decision points, making more granular decisions impractical.

Solution: Clear Decisions

• Grant Ships provides simple decision paths for the voter without the need for extensive study.
• We replace massive context proposal voting with a series of smaller, targeted contextual votes.
• Many granular decisions are delegated to representatives once, and the community only has to vote on their performance over time.

Solution: Structure

• Rhythmic governance cycles create predictable, palatable demand for voter attention.
• Responsibilities are divided across multiple roles (provided via Hats Protocol) with periodic review and associated voting periods available to provide accountability.
• Hats Protocol roles span multiple contracts, allowing a greater degree of specialization; people can focus on what they’re good at without duplicating work, absolving the voting community from making many small decisions.

Solution: Isolation of Variables

• The A/B test environment provided by Grant Ships allows clean comparisons to be made between allocation strategies. The voting signal then determines the relative funding levels of these allocators rather than only allowing a binary “yes or no” on each issue.
• All Ships start at the same time. All Ships operate within the same rules and produce comparable, documented results by the game end.
• This provides a cleaner way to compare DAO allocation mechanisms and the efficacy of allocators.

Problem: The Risk of Capture & Incompetence

Choosing to delegate large amounts of capital to Grants Councils does not guarantee that the Grants Council will be effective or trustworthy.

• Grants councils are entrusted with a lot of power and authority over funding decisions and are often also responsible for reporting on their outcomes. Capture is possible, incompetence is possible, and oversight is difficult.

Solution: Revocable Privileges

Delegation of certain authorities is an effective and necessary pattern within a DAO, but there needs to be a meaningful way to revoke that authority when needed.

• Grant Ships’ integration with Hats Protocol provides revocable privileges, reducing the risk of capture and “loyalty through sunk cost” - see Spencer Graham’s ‘Anticapture’
• Game Facilitators and Grant Ships can all be suspended or replaced by a DAO vote as needed.

Solution: Accountability through Transparency

• Transparent allocation through automated reporting provides an incentive to be effective and trustworthy.
• Broadcasting all meaningful events within the grant-giving process provides signal to the DAO for accountability purposes.

Solution: Reasonable Safeguards

• Game Facilitators screen and approve allocator Grant Ships and, once approved, allow Grant Ships to initiate Recipient funding allocations.
  • This can ensure DAO KYC/KYB standards are met for every recipient in a standardized manner, without relying on each allocator to do it right.
• Checks and balances are provided because Game Facilitators approve grant recipient allocations, but Grant Ships handle distributions at their discretion.
  • With Allo, allocation and distribution are distinct actions and provide a ‘two key’ security mechanism.
    • Allocation earmarks the funds for a particular recipient.
    • Distribution disburses them only to that recipient.
• Game Facilitators can apply Yellow or Red Flags to a Grant Ship in instances of rules violation or acts of bad faith.
  • Yellow Flags are like a verbal warning, creating an attestation of the event with context for voter review.
  • Red Flags also create an attestation of the event with context but additionally lock down the Ship’s ability to distribute funds.
  • Both Yellow and Red Flags remain active on a Ship’s profile until resolved by a Game Facilitator, but remain in the event feed as context for voters.

Problem: No budgets

• ​Voting for every issuance of Grant funds, whether to a group of Allocators or an individual project assures that setting a regular budget in DAOs is nearly impossible.
• Without a governance framework or SubDAO that manages grant funds, only ‘emergent’ grant budgets are possible. i.e. Let’s see what the DAO decides to spend and say that’s what the budget was.
• Bulky grant proposals to the DAO create uncertainty and irregularity in funding rhythms. This makes budgeting difficult or impossible, as the DAO at any time could decide to fund a larger or smaller grants program, and that could change at any time with a newly passed proposal.

Solution: Rhythm and Cadence

• The GameManagerStrategy contract can enforce a regular cadence of grant giving - a defined start time and end time for each round - that can be tied to different funding cycles (i.e. monthly, quarterly)
• This creates a system where you could allocate a portion of sequencer fees to grants creating a reliable grants funding stream.

Solution: Budgets and Funding Faucets

• ​Grant Ships functions like a funding faucet that can be filled by the DAO for eventual distribution.
• Once the pool is funded, as many Grant Ships in whatever variety required can be spun up to handle distribution to individual recipients.
  • With full adoption of the Grant Ships system it’s reasonable to predict that fewer and fewer Yes or No grant proposals will need to go to the DAO. Instead, funding streams could be designated for the Grant Ships funding pool. Grants programs could apply to be a Grant Ship and receive funding from the pool.
  • Grant recipients can then apply to these Grant Ships to receive funds.
  • Voters maintain influence and control through the regular voting and revocable privilege systems.
  • This allows the DAO to create a budget for grants that can be increased or decreased as needed.

Landscape

We recognize the accomplishments, breakthroughs and positive contribution of existing grant-giving organizations, frameworks, and systems. Grant Ships is a “meta-framework” within which grant-giving systems that are specific about allocation strategies can operate. Any existing grant-giving model could operate and thrive within the Grant Ships meta-framework.

Grant Ships itself is silent on specific strategies for grantee selection and allocation and we hope the current rich grant allocation ecosystem sees the opportunity provided by Grant Ships to share and evolve their approaches over time.

Grant Game Theory Dynamics

In Grant Ships, we harness the power of competition to enhance performance. At the end of each funding round, Ships receiving high ratings from the voting community receive increased funding, while those with lower ratings receive reduced allocations. \

The community also determines overall funding levels divided among Ships, creating an incentive for the Ships to perform well as a whole. This mechanic creates rewards and consequences for the Ships and hopefully leads to an interesting balance of cooperation and competition, motivating Ships to strive for excellence and driving the overall success of the network. \

The main goal of Grant Ships is to enhance the effectiveness of grant allocation by encouraging the evolution of high-impact strategies over time. We anticipate game theory dynamics to emerge over time, where observing and learning from the success of other programs leads to continuous improvement across all programs. This ensures that no single participant or program can gain an advantage without others also adapting and improving, promoting a competitive and collaborative improvement environment where high standards emerge collectively.

Reputation and Impact

By default, Grant Ships doesn’t directly measure the impact of each Ship Operator. Instead, it measures votes from the governing community to determine funding levels for each Ship. However, it is likely that community voters will factor impact (and many other factors) into their voting decisions. \

All grant cycle events that occur within Grant Ships are published as events onchain. These events are aggregated and displayed in a feed within the app to provide always-up-to-date context for voters. \

Grant Ships will have the capacity to integrate with external assessment and reputation protocols to provide relevant context for voters making decisions on a particular Grant Ship.

By providing this performance and reputation data in an open format, we anticipate a community reporting ecosystem emerging around Grant Ships to inform voters on performance trends among Grant Ships and give Ships real-time feedback on their performance.

Metric Feedback

The design of Grant Ships is compatible with direct incorporation of metrics as feedback for Ship Operators. A governing DAO could select and supply key metrics that are tied directly to a Ship’s performance evaluation in lieu of or in combination with a DAO community vote.

The voting technology underpinning Grant Ships could be adapted to allow the governing DAO to select and configure these key feedback metrics through surveys, contests and votes. This would provide an additional level of sophistication for the Ship Operator feedback loop.

Contractual Governance

Grant Ships can be seen as a smart contract-backed Governance OS for a grant-giving sub-DAO. Structure is enforced by the contracts. Individuals take up roles within that structure.

Where a typical DAO might have rules and operational flows written on paper and enforced through social convention, most of the rules of the Grant Ships game are enforced by code and the rest are enforced by DAO-elected Game Facilitators.

We see this pattern as one of the most important aspects of Grant Ships and a step toward delivering on the promise of smart contract-based governance. \

Grant Ships is designed to be a progressively decentralized game. Early implementation will maintain some centralization as the game mechanics are being learned and future rounds will have free and fair elections for all positions within the game, including administrators and Ship operators. At this point governance decisions will be handed over to the DAO.

This is made possible through the integration with Hats Protocol which provides a revocable role and permissions framework. Game Facilitators, Grant Ships, and Delegated Voters are all holders of a Hats Protocol NFT, which is owned by the governing community (e.g. a DAO) and can be revoked and reassigned through a vote.

This diagram shows the high level relationship between GameManagerStrategy and GrantShipStrategy and the various roles. Major actions taken within the game broadcast events that are compiled into real-time feeds.

The Ruleset

We have developed an initial set of rules for how the game is organized and played. As mentioned in the previous section, most of the operational flow is enforced by the backing smart contracts. The rest of the rules are enforced by game facilitators through their ability to assign yellow or red flags when violations occur. Yellow and red flags are a contract mechanism that allows Game Facilitators to signal violations for voter consideration or revoke a Ship’s distribution permissions respectively.

These rules are subject to change as the game is tested and becomes more decentralized. They will ultimately be decided by the governing DAO. This paper gives a brief overview of the rules and what you will find in the current version of the rule book.

Delegated Voters

Within the regular flow of the game, Delegated Voters vote to elect Grant Ships when the game begins. After each funding round, Voters have an opportunity to vote for their favorite Grant Ships. Funds are then allocated proportional to voting totals in the subsequent round.

Outside of the regular flow of the game, the community may initiate a vote to revoke or reassign roles within the game. For example, if Game Facilitators are abusing power or not acting by their mandate, the DAO can revoke their role and assign new Game Facilitators. \

In this way, the DAO community retains control of the Grant Ships program and can hold votes as needed to revoke permissions or withdraw funding from the program.

Technical Overview

Key Integrations

​Hats Protocol

Grant Ships incorporate Hats protocol to represent the roles as hats NFTs, so roles can be assigned to and revoked by the holder of the ‘top hat’ (e.g. a grants council or community DAO contract). This reduces capture risk by allowing the replacement of actors from any role as needed.

Allo Protocol

Grant Ships uses Allo protocol and two custom Allo strategies to:

• Define and enforce the actions available to each role
• Track participants using the Allo registry
• Divide the act of funding into a multi-step process that includes allocation, distribution, and documentation. \

Grant Ships has two separate Allo strategy contracts that work together to create the game structure: GameManagerStrategy and GrantShipStrategy.

The Grant Ships Contracts

​More detailed documentation on the Grant Ships solidity contracts can be found in the Github repo.

GameManagerStrategy.sol (The Metastrategy)

​Holds the common funding pool

• Creates and initializes each Grant Ship sub-pool (which are created by GrantShipStrategy.sol)
• allocate and distribute funds from the common funding pool into sub-pools for each Grant Ship
• Enforces round start and stop times, and allows initiation of new game rounds.

The GameManagerStrategy.sol contract serves as the foundation for the Grant Ships game. It allows Game Facilitators to set the initial parameters, review Grant Ship applicants, and initiate the game when Grant Ship Operators have been selected. It has permission to make calls into the GrantShipStrategy and distribute funds.

GrantShipStrategy.sol (The Funding Strategy)

• Allows potential grant Recipients to apply
• Allows Recipients or Grant Ship Operators to specify milestones for distributions
• Allows Recipients to signal that a milestone is complete
• Allows Game Facilitators to allocate funding to Operator selected Recipients.
• Allows Grant Ship Operators to distribute funds for a completed milestone
• Allows Game Facilitators to issue a Yellow or Red Flag to a Grant Ship
• Locks down Grant Ship Operator permissions when a Red Flag is active
• Allows funds to be withdrawn back into the GameManager pool if needed

The GrantShipStrategy contract is also an Allo Strategy with an associated funding pool.

Multiple instances are initialized by GameManagerStrategy - one for each Grant Ship. Once the game is started the contract handles applications from potential Grant Recipients and the submission of milestones.

Game Facilitators can make calls into this contract to flag a Grant Ship with Yellow or Red Flags. Yellow Flags are like notes or warnings that go into the public feeds. Red Flags lock down Ship operations until the flag is resolved.

Event Broadcasting

​Every major action in both GameManagerStrategy and GrantShipStrategy emits an event, creating records that can be aggregated into feeds. In each function where the caller is making a decision, an optional parameter Metadata _reason is included to provide additional context.

The UpdatePosted event allows Game Facilitators, Grant Ship Operators, and Grant Recipients to make posts directly to their feeds as needed.

[owocki]

very curious to see how the grant ships experiment in gg23 goes!