Category: token-holder governance middleware / voter-eligibility service / census-construction infrastructure
Summary: Census3 is best understood not as a generic token analytics service, but as voter-admission middleware that turns token-holder or credential-holder datasets into publishable weighted Merkle censuses for governance. Its reusable mechanism is the split between token registration, ongoing holder indexing, strategy definition, census generation, and later anonymous-proof compatibility. That makes Census3 a useful comparison class for Snapshot strategies, Guild-style membership gating, Gitcoin Passport integrations, and any governance stack where the real power lies in who defines the electorate and how that electorate gets transformed into a usable proof set.
What it does:
Tracks holder addresses and balances for registered tokens on Ethereum-based networks and keeps those indexes updated over time
Builds Merkle-tree censuses compatible with Vocdoni elections, using holders as eligible voters and balances as vote weights
Supports multiple input types including ERC20, ERC721, ERC777, POAP, and Gitcoin Passport Score, with additional types documented as planned
Lets integrators define voter-eligibility strategies using predicate logic across one or more tokens instead of only “all holders of token X”
Publishes generated censuses to IPFS and exposes a REST API for token registration, strategy creation, and census generation
Produces zk-friendly censuses that can also be used in anonymous voting flows
Key claims:
The official docs are very clear that Census3 is a wrapper around Vocdoni’s onchain-census design. Its purpose is to spare integrators from manually registering tokens or generating storage proofs, which means it is an abstraction layer over voter-admission complexity rather than just a data indexer.
The main README frames the service as an API that keeps token-holder balances updated in real time and then uses that data to create Merkle-tree censuses. The key analytical move is that electorate construction becomes a standing service, not a one-off snapshot.
The strategy system is the most important reusable primitive. The docs support predicate expressions such as BTC OR ETH or USDC AND (ETH OR (BTC AND DAI)), plus weighting behaviors like AND:sum, AND:mul, OR:sum, and OR:mul. This makes Census3 closer to a governance-eligibility DSL than to a simple token-balance snapshot.
Census3’s supported sources already extend beyond ordinary fungible-token holdings. The docs and README mention POAP and Gitcoin Passport support, showing how the service can blend asset ownership with softer identity or participation credentials.
The docs explicitly warn that while popular assets like ETH are theoretically usable, it is infeasible for Census3 to maintain a fresh index of all transactions for that kind of high-traffic asset. That practical limit matters because it means the service favors curated governance tokens and bounded communities over universal-chain electorates.
The service also introduces its own control surfaces: someone must register tokens, define strategies, provide RPC endpoints and external-provider credentials, and decide how stale or fresh scans are acceptable before a census is generated.
Because censuses are published to IPFS and built with zk-friendly Merkle trees, Census3 does more than define membership; it prepares that membership for later anonymous voting and proof-serving workflows.
Census3 is a strong corpus entry because it helps separate two governance layers that often get flattened together: the governance front end where communities think they are “voting,” and the eligibility middleware where the electorate is actually composed.
Whitepaper: No canonical standalone Census3 whitepaper surfaced in this pass. The strongest primary materials reviewed were the official Census3 docs page, the Census3 repository README, and the API docs pointer; see ../whitepapers/census3-primary-sources-2026-05-10.md.