Summary: POTLOCK Lists is worth cataloging as a distinct lower-layer primitive inside the broader POTLOCK stack because its interesting mechanism is not grants in general but programmable list maintenance over accounts. The official materials frame lists as Spotify playlists for any account, with explicit owner / admin / registrant / user roles, application settings, registration-status states, upvotes, and batch membership management. Those lists are then reused as practical infrastructure for public-goods discovery, donation baskets, membership requirements, airdrop waitlists, and—most importantly—eligibility checks in POTLOCK’s quadratic-funding pots. That makes POTLOCK Lists a useful comparison point for Kleros Curate, clr.fund recipient admission, and other registry-like systems: the key question is whether list authority sits in open challenge and arbitration, or more directly in owner/admin custody, default-status policy, application permissions, and whichever list becomes socially canonical.
What it does:
Lets anyone create lists of NEAR accounts with configurable name, description, cover image, admins, and application settings
Supports explicit role splits across owner, admin, registrant, and ordinary user rather than hiding moderation power inside one backend operator
Lets owners/admins batch add or remove accounts, update registration status, transfer ownership, and tune whether applications are open or admin-only
Tracks registration states such as Pending, Approved, Rejected, Graylisted, and Blacklisted, plus registrant/admin notes and who performed the registration
Allows open users to upvote lists and, when permitted, apply to join them with contextual notes
Is enforced in the latest POTLOCK quadratic-funding pots, where a list can become part of the eligibility criterion for which accounts may apply to a round
Key claims:
The live docs describe lists as Spotify playlists for any account, which is a useful shorthand because the primitive is not only for grants recipients; it is a reusable account-curation layer that can be repurposed across multiple funding and community workflows.
The strongest protocol insight is the role split. POTLOCK Lists makes owner/admin authority explicit: owners can add/remove admins, transfer ownership, update statuses, set default registration status, and add/remove accounts in batches, while admins inherit most but not all of that power.
The contract interface is analytically useful because it makes admission policy legible through concrete fields such as default_registration_status and admin_only_registrations. Those two settings largely determine whether a list behaves like an open signup surface, a moderated allowlist, or an owner-run curated registry.
The docs explicitly say lists are enforced in the newest quadratic-funding contracts. That means list maintenance is not just a discovery feature; it can directly shape who may enter downstream capital-allocation systems.
The official public-goods registry living on list_id = 1 is a valuable control-surface signal. Even when anyone can create lists permissionlessly, one socially recognized canonical list can still become the practical legitimacy layer for wallets, frontends, and round operators.
Compared with Kleros Curate, POTLOCK Lists is a useful lower-bound registry design because it exposes curation without a dedicated challenge/arbitration court. Practical power sits more plainly in ownership transfer, admin assignment, registration defaults, application permissions, and status updates.
The use cases listed in the docs—membership requirements, airdrop waitlists, community signal through upvotes, donate-to-all baskets, and RetroPGF-style signals—show that POTLOCK Lists belongs in the corpus as reusable registry middleware, not just as a UI feature under the POTLOCK brand.
Whitepaper: No standalone POTLOCK Lists whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official live docs, contract overview, and lists contract interface notes collected in ../whitepapers/potlock-lists-primary-sources-2026-05-12.md.