Grant Ships primary sources — 2026-05-09

What I reviewed

Key takeaways from primary sources

  • Grant Ships is a strong addition because it treats grantmaking structure itself as the mechanism under study. The novel question is not just who gets grants, but how allocator authority is split into multiple competing ships and then reweighted over time.
  • The Gitcoin mechanism page provides the cleanest simple definition: modular, self-contained funding rounds operating independently while sharing infrastructure. That is the core abstraction worth retaining.
  • The proposal adds the crucial evolutionary layer: ships are supposed to compete on allocation quality, and voter judgment in later rounds acts as a fitness function deciding which allocators should control more capital.
  • The role split is analytically important. Delegated voters, referees, facilitators, ships, and recipients all hold distinct powers, which means governance is distributed across election, disclosure review, fund release, and impact assessment.
  • The proposal’s workflow deliberately separates allocation from evaluation. Ships disclose intended allocations, referees review and execute them while minting Hypercerts, and only then do voters judge ship performance in subsequent rounds.
  • Hats Protocol is central because it is the constitutional mechanism for role delegation and revocation, not just an implementation detail.
  • Allo donation voting and explicit vote modifiers matter because they reveal a second-order governance surface: not only who votes, but how voting weight is shaped to reward participation or engagement.
  • The build proposal is useful corroboration that the system was intentionally designed as a composition of existing primitives — Hats, Hypercerts, and Allo — rather than a brand-new monolith.

Specific source signals worth retaining

  • Gitcoin mechanism page: strongest concise description of the fleet model and why it scales grantmaking horizontally.
  • Main proposal: best source for the game logic, role structure, Step 0 / Step 1 / Step 2 flow, and the idea of voter signal as allocator fitness testing.
  • Build proposal: useful for confirming intended protocol integrations, the implementation team structure, and the existence of a dedicated rule book / website path.
  • Repository README: weaker than the proposal for mechanism detail, but still useful confirmation that the public site/repo framing consistently describes Grant Ships as a community-governed funding game.

Why this entry belongs in the corpus

  • It extends the public-goods funding cluster beyond round software into allocator-competition design.
  • It is a useful comparison class for Allo, Gitcoin Grants Stack, EasyRetroPGF, and Questbook because it moves the main design problem upward from recipient selection to allocator selection.
  • The reusable insight is that grant systems can decentralize by creating many grant operators and then governing the operators competitively, rather than by trying to perfect one centralized review committee or one voting round.