Summary: Census3 is voter-admission middleware, not token analytics. The useful mechanism is the split between token registration, holder indexing, strategy definition, census generation, and later anonymous-proof compatibility. Keep it around because it makes electorate construction explicit.
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.