Summary: EasyRetroPGF is best understood not as a new capital-allocation primitive from scratch, but as a portable “retro funding round in a box” that packages application intake, badgeholder voting, result publication, and payout execution into a forkable stack. Its reusable mechanism is the split between public eligibility and metadata attestations on EAS, private ballot storage in Postgres, and payout execution through Allo v2 with configurable tally styles. That makes it a useful comparison class for Optimism Retro Funding, Gitcoin Grants Stack, Questbook, and other systems where the nominally onchain round still depends heavily on offchain admin workflows, timing gates, voter admission, and payout-policy choices.
What it does:
Lets ecosystems fork and self-host a retroactive public-goods funding application rather than relying on a single hosted grants platform
Stores projects, profiles, lists, and approval data via Ethereum Attestation Service schemas, making applicant identity and eligibility legible onchain
Uses admin-controlled approval flows for applications and voters / badgeholders before voting opens
Lets approved voters build ballots, adjust allocations, and submit signed votes through the web app
Publishes results on a configured reveal date and exposes round statistics for operators and participants
Executes payouts through Allo v2 after operators create and fund a pool, with a choice between a simple custom tally and an “OP-style” median-plus-quorum payout calculation
Key claims:
The official site explicitly markets EasyRetroPGF as “Retroactive Public Goods Funding for everyone,” which is analytically useful because the project is positioning retro funding as a reusable deployment pattern, not only as an Optimism-specific program
The README says projects, profiles, and related metadata are stored on EAS, while votes are stored privately in Postgres and payouts run through Allo2; this separation matters because it shows the round is only partially onchain and practical authority sits in multiple layers at once
The setup docs emphasize operator configuration of voter counts, per-project caps, voting periods, registration / review periods, and admin wallet addresses, making clear that governance power is shaped heavily by round-operator settings before any vote is cast
The docs say badgeholders / voters must be added and applications approved before voting, which means the “retro” mechanism still depends on permissioning and review gates rather than open automatic inclusion
The results docs include a configurable NEXT_PUBLIC_RESULTS_DATE, showing that result visibility is itself an operator-controlled release surface rather than an immediate public consequence of ballot submission
The distribution docs expose two payout styles — a straight vote sum and an OP-style median-plus-quorum calculation — which is important because the same applicant and voter set can produce different funding outcomes depending on tally design
The .env.example and setup docs show how much authority sits in deployment configuration: schema addresses, admin allowlists, token address, strategy address, and network defaults collectively decide what kind of round this instance actually is
Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official site plus the public repository and deployment / voting / distribution docs; see ../whitepapers/easy-retro-pgf-primary-sources-2026-05-09.md.