POTLOCK primary sources — 2026-05-09

What I reviewed

• Official docs home:
  • https://docs.potlock.io/
• Vision / roadmap material:
  • https://docs.potlock.io/readme/end-game
• Contract architecture overview:
  • https://docs.potlock.io/contracts/contracts-overview
• Lists contract docs:
  • https://docs.potlock.io/contracts/lists-live
• Official repository:
  • https://github.com/POTLOCK/core
  • https://raw.githubusercontent.com/POTLOCK/core/main/README.md

Key takeaways from primary sources

• POTLOCK is most useful as a corpus entry because it treats public-goods funding as a composable protocol stack rather than a single round operator. The docs repeatedly frame it as an “Open Funding Stack.”
• The contracts overview page makes the main architecture explicit: donation rails, lists, registry, sybil scoring, pot factory, pot contracts, campaigns, and voting. That decomposition is the primary analytical value.
• The Lists contract is especially strong as a reusable idea. It turns curation into a first-class onchain object: lists can be used for discovery, application gating, membership requirements, upvote signaling, and “donate to all” baskets.
• POTLOCK’s docs state that the official public-goods registry lives on list_id = 1. That is a concrete example of how a permissionless substrate still tends to accrete canonical social layers.
• The Nada.bot / sybil contract is a major practical governance surface because humans, admins, and weights determine who qualifies for participation under anti-sybil rules.
• The Pot contract description is unusually candid that quadratic-funding payouts are calculated offchain and then initiated onchain with a cooldown veto period. This is important for comparing POTLOCK with other QF systems that blur the boundary between computation and settlement.
• The end-game page is ambitious and sometimes aspirational, but it is still useful because it names the intended decentralization path directly: progressive decentralization, multiple clients, optional fees, tokenization, identity aggregation, and ecosystem-run funding infrastructure.
• Compared with dGrants, POTLOCK leans more into operational funding products and contract modules; compared with Allo, it exposes curation and identity controls more explicitly at the application layer.

Specific source signals worth retaining

• Docs home: “Open Funding Stack” framing, current product modules, and emphasis on composability.
• End game page: progressive decentralization, council governance, token model, client diversity, identity/privacy, agent usage, and growth roadmap.
• Contracts overview: the clearest single-page map of the protocol’s actual moving parts and named contracts.
• Lists docs: owner/admin roles, registration states, upvotes, public-goods registry convention, and the idea of reusable curated funding lists.
• Core repo README: confirmation that the stack is centered on multiple contracts rather than a monolith, even though the README itself is fairly skeletal.

Why this entry belongs in the corpus

• POTLOCK belongs because it makes usually hidden funding-stack control surfaces unusually legible.
• It is useful next to Gitcoin Grants Stack, dGrants, and Allo because it highlights that public-goods funding depends not only on matching formulas but on who runs lists, who defines human thresholds, who deploys rounds, and which front ends become canonical.
• The reusable insight is that grants infrastructure often centralizes in curation, identity, and operator workflows even when contract deployment is permissionless.