Summary: Grant Ships is best understood not as a single grants app, but as a way to horizontalize grantmaking by turning funding rounds into parallel, semi-autonomous “ships” that compete for future budget based on voter evaluation of their prior allocations. Its reusable mechanism is the split between local allocator autonomy and shared meta-governance: each ship gets its own mandate, stewards, review process, and budget, while the broader ecosystem uses shared infrastructure and later voting rounds to decide which ships were effective and should control more capital next. That makes it a useful comparison class for Allo Protocol, Gitcoin Grants Stack, EasyRetroPGF, and other systems where the real question is not just how grants are paid, but how allocator authority is partitioned, judged, and reweighted over time.
What it does:
Treats each grant ship as a modular, self-contained funding round with its own scope, team, governance rules, budget, and timeframe
Uses a fleet model so multiple ships can run in parallel on shared infrastructure rather than routing all applications through one central committee
Frames allocator competition itself as the mechanism: ships make allocations first, then voters judge ship performance and steer future capital toward the allocators they think worked best
Uses Allo donation voting as the stated voting strategy for evaluating ships and adjusting future funding shares
Pairs ship disclosures and referee review with Hypercert minting so past allocations can be inspected as impact claims before later voting rounds
Uses Hats Protocol role structures to separate ultimate DAO authority from delegated operational roles such as referees, facilitators, and ship operators
Key claims:
The Gitcoin mechanism page gives the cleanest concise framing: Grant Ships are modular, self-contained funding rounds that operate independently while leveraging shared infrastructure like Allo Protocol, which is why this belongs in the corpus as a grantmaking-structure pattern rather than only as a one-off Arbitrum experiment
The proposal’s strongest reusable idea is that grant allocation becomes an evolutionary game: grant-giving subDAOs compete to best deploy capital, and later voter judgment acts as the “fitness function” deciding which allocators deserve more influence in subsequent rounds
The proposal explicitly separates roles into delegated voters, referees, facilitators, ships, and recipients, which matters because it shows authority is distributed across election, review, fund-release, and impact-reporting layers rather than resting in one voting contract
The Step 1 / Step 2 design is analytically important: ships first signal allocation disclosures, referees review and release funds while minting Hypercerts, and only later do voters judge ship performance; that means evaluation is downstream of allocation rather than embedded directly in initial recipient selection
The proposal’s use of Hats Protocol is not decorative. It is the constitutional layer meant to let the broader DAO revoke or reassign authority, making revocation and role topology central to the mechanism’s trust model
The use of Allo’s donation voting strategy plus explicit vote modifiers shows that the mechanism is not just decentralized grantmaking, but also active experimentation with how allocator evaluation weights get shaped offchain and onchain
The build proposal is useful because it confirms Grant Ships was conceived as an integration surface stitching together Hats Protocol, Hypercerts, and Allo, which makes it a good comparison case for multi-protocol governance products rather than a pure single-contract primitive
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the Gitcoin mechanism page plus the DAO Masons proposals and build materials; see ../whitepapers/grant-ships-primary-sources-2026-05-09.md.