Authors: Matt Davis (ui369.eth), Chris Wylde (boilerrat.eth), Jordan Lesich (jord.eth)
Date: Feb 19th 2024
Grant Ships is a meritocratic, decentralized, capture-resistant grants framework that enables communities to deploy capital in an effective and accessible way.
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 progressively larger sums to allocate.
With Grant Ships, the best grants programs aren't selected or even voted in through proposal. The best grant programs and the most talented allocators will be discovered through open and decentralized competition. With these core ideals in mind, we designed a grants framework called Grant Ships.
Grant Ships strives to make full use of the distributed nature of its natural habitat, Arbitrum DAO. It aims to not only enhance the decentralized, onchain technical capabilities of Arbitrum but also to cultivate a vibrant, dynamic community where groundbreaking ideas are brought to fruition, setting new standards for ecosystem development.
At its core, Grant Ships is a 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 round, they are free to implement their own strategies and compete to provide the best results. When a round ends, the DAO is presented with each Ship's portfolio and votes in a Token Curated Registry (TCR) on the performance of each Grant Ship. In the following round, each ship receives funds in proportion to the votes they received.
[[toc]]
With DAOs, we usually only get 2 choices for how we distribute funds to contributors. We either make proposals and vote on every grant, or we delegate large portions of the treasury to centralized councils and hope that they are effective and remain honest.
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.
This section aims to outline the problems we see with traditional grant programs and how Grant Ships provides solutions to each.
We are working in the dark. DAOs have no way of knowing who the best allocators and contributors are.
- Monolithic grant programs have no point of comparison to weigh efficacy per token spent.
- Voters are only ever presented with the choice of continuing a grant program or killing it. This low-definition 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.
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. Qualified builders often find too much friction and uncertainty to justify the pursuit of a web3 grant.
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.
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.
Using a yes or no Vote for each Grant has way too much context overhead for the voting community and leads to voter fatigue.
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.
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.
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 Sub DAO of Arbitrum DAO. 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 Arbitrum DAO.
Ship operators must follow the rules of the game, such as alignment with our compliance policy and providing a high level of ethical standards. Other than that, operators are free to run their ships as they please. They may set up their own communications channels and create their own rules that they will follow.
Participants within Grant Ships w/Allo are divided into 4 main roles: Game Facilitators, Grant Ship Operators, Grant Recipients, and Delegated Voters.
For the beta round, the Hat for Delegated Voters will be held by a designated Game Administrator responsible for setting up the game and translating votes into game parameters.
Future versions will be automated and have the hat held by a DAO contract managed by voters or a delegated security council.
This section details at a high level each role's permissions and responsibilities. These permissions each correlate to onchain events (i.e. contract function calls).
This diagram shows the major actions available to each role within the game for a single funding round. It does not include the TCR vote that informs funding levels, or the optional updates posted by each role.
We recognize the accomplishments and breakthroughs 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 metaframework. 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.
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 established game theory dynamics such as the Nash Equilibrium principle 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.
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.
Grant Ships can be seen as a smart contract-backed Governance OS for a grant-giving sub-DAO. Structure is enforced by the contracts and 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. 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. While the beta and alpha rounds will maintain some centralization as the game mechanics are being tested, future rounds will have free and fair elections for all positions within the game, including administrators and ship operators. All governance decisions will be handed over to Arbitrum DAO.
This is made possible through the integration with Hats Protocol which provides a revokable 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. Arbitrum 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.
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 will be 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.
Grant Ships has developed a compliance policy which all participants are expected to sign off on and follow. Failure to stay in compliance could result in the immediate revocation of a player's permission to play the game through the red flag mechanism.
The mechanics of this revocation will be further explained in our technical overview.
Within the regular flow of the game, Delegated Arbitrum 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 Arbitrum DAO community retains control of the Grant Ships program and can hold votes as needed to revoke permissions or withdraw funding from the program.
The public-facing rulebook for Grant Ships is at rules.grantships.fun.
This will be updated with user guides, screenshots, and tutorials as the game develops.
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.
Grant Ships uses Allo protocol and two custom Allo strategies to:
Grant Ships has two separate Allo strategy contracts that work together to create the game structure: GameManagerStrategy and GrantShipStrategy.
More detailed documentation on the Grant Ships solidity contracts can be found in the Github repo.
allocate
and distribute
funds from the common funding pool into sub-pools for each Grant ShipThe 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.
allocate
funding to Operator selected Recipients.distribute
funds for a completed milestoneThe 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.
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.
GrantShipStrategy is a modified version of Allo’s Direct Grants Strategy with changes to integrate with Hats and to allow integration with the GameManagerStrategy meta-strategy.
When a Grantee is selected by a Grant Ship Operator for a grant, the Operator can request Milestones from the Grantee or supply them themselves. Under the hood, distribution is tied to milestones. If an Operator doesn't want to use milestones and prefers to use bulk distribution, the Operator could submit a single milestone for the full grant amount and use that to distribute the funds all at once.
This Milestone functionality is provided by GrantShipStrategy.sol
.
In Allo strategies, funding events are split across 2 functions: _allocate
and _distribute
. Once funds are allocated for a particular recipient, they can then be distributed to send the funds.
Ship Operators approve Grantee applications and an update is posted to signal Game Facilitators to allocate funds distribution. Game Facilitators call the _allocate
function, which clears the Grant Ship Operator to call the _distribute
function to make the actual distribution.
The contracts each include _registerRecipient
functions that allow anybody to submit an application to these contracts. GameManagerStrategy.sol
receives Grant Ship applications which can be approved or rejected. and once a GrantShipStrategy.sol
instance is spun up for an approved Grant Ship, it receives applications for grants to that Grant Ship.
Every Recipient, Grant Ship, and Game Facilitator will have a feed of game lifecycle events and UpdatePosted events. Beginning with the Game Start event, every major event within the game (i.e. every contract function call) generates an event. These events are aggregated into a feed within the app.
Each role can post an UpdatePosted event whenever they like. These events are added to the relevant feeds and are intended to allow actors to provide additional context to voters.
Game Start is triggered by Game Facilitators through the startGame
function in GameManagerStrategy after initial funds distribution to sub-pools. The Game End event occurs by a call to stopGame
after a specified amount of time and locks all Grant Ship activity until a new round begins.
Facilitators can flag ships with a yellow or red flag. Flags can be marked as resolved by Game Facilitators.
A yellow flag is like a community note or warning that goes into a Grant Ships event feed for voter review. When a yellow flag is resolved this goes into the ship's feed with Game Facilitator notes about the resolution.
A red flag immediately locks down a Grant Ship preventing them from making further distributions. When a red flag is resolved it unlocks the corresponding ship and adds that context to the ship's feed.
GrantShipStrategy.sol is a modified version of Allo's default DirectGrantStrategy based on milestone funding. Due to the composable nature of Allo protocol's strategy pattern, it will be possible to create additional strategies (e.g. quadratic funding, streaming, hackathons, etc) and use them within the Grant Ships game.
All permissions are administered through the Hats protocol. This means that to have a particular permission within the game, you must hold a particular Hat. Internally, Hats represents the role of an NFT. If this NFT is reassigned, the corresponding permissions are reassigned.
Hats provides revokable roles to provide capture resistance and lets a DAO or council assign and revoke game roles as needed.
More detailed information on contract specifics can be found in the contract repo documentation.
As of February 2024, we are in our first development cycle creating an MVP and planning a beta test. This document provides a holistic view of the whole Grant Ships framework including the vision for a fully decentralized future, and refers to some features that will not be included in the beta release.
These features are:
Instead of a direct implementation of these features in the MVP, we use the following workarounds:
A future version of Grant Ships will include:
Game theory, a study of strategic decision-making, plays a critical role in shaping the dynamics of Grant Ships. By leveraging game theory principles, Grant Ships aims to create a competitive yet collaborative environment, driving participants toward optimal performance and contribution. This section explores the key game theories utilized in Grant Ships and how they influence behavior and outcomes within the ecosystem.
In this hypothetical scenario the maximum total impact that can be obtained would be a score of 6. According to Nash's Equilibrium, if both ships were working towards the same goal, that is the score that would be achieved. If one ship was working toward that goal and the other doing something else, the total score that can be achieved is 1. If they are both working towards low-impact grants, the highest score achievable is 2.
The achievement of Nash Equilibrium within Grant Ships is beneficial across multiple levels. For the Arbitrum ecosystem, it brings stability and efficiency; for grant recipients, it ensures fairness, diversity, and consistency; and for individual Grant Ships, it results in strategic efficiency, competitive advantage, and stronger community alignment. This equilibrium is not about uniformity but about finding the most effective role each player can have in a complex, dynamic system, leading to collective growth and innovation.
Elinor Ostrom's groundbreaking work on managing commons offers eight principles for the effective governance of shared resources. These principles are represented with the decentralized, community-driven nature of Grant Ships:
Chris Wylde (Boilerrat.eth)
Jordan Lesich (Jord.eth)
Matt Davis (UI369.eth)
Nash, John (1950) Equilibrium points in n-person games: Proceedings of the National Academy of Sciences 36(1):48-49.
Ostrom, E. (1990). Governing the Commons: The evolution of institutions for collective action. Cambridge University Press.