Summary: PLCR Voting is best understood not as a full governance system or a registry by itself, but as a reusable lower-layer voting primitive for ERC-20-weighted polls. Its primary materials describe a Solidity system where users deposit voting rights into one contract, commit salted-hash votes across multiple simultaneous polls, reveal later, and keep the maximum amount of non-actively-used tokens withdrawable instead of fully immobilizing balances poll by poll. The reusable mechanism insight is that PLCR separates voting-right custody, per-poll hidden commitments, partial token locking, reveal/rescue flows, and downstream reward or slashing policy into distinct layers. That makes it a useful comparison point beneath token-curated registries and other onchain secret-ballot systems that otherwise appear as single bundled applications.
What it does:
Lets token holders participate in multiple concurrent token-weighted polls while preventing double-voting within any single poll
Uses commit-reveal voting so ballot direction stays hidden during the commit phase and is only disclosed in the reveal phase
Keeps track of the maximum amount of tokens locked across outstanding polls, allowing unused voting rights to remain withdrawable instead of freezing all deposited tokens
Supports rescue/unlock flows for unrevealed votes after reveal periods end, avoiding permanent lockup when users forget salts or fail to reveal
Acts as a generic poll primitive that downstream systems like token-curated registries can call for challenge resolution, reward accounting, or status updates
Key claims:
The repository README is explicit that PLCR exists to let users vote in multiple polls simultaneously without double-voting inside a poll. That concurrency property is the main mechanism, not just the use of commit-reveal secrecy.
The adChain walkthrough is especially useful because it explains why partial lock matters: naïve per-poll locking harms token liquidity, while PLCR tries to preserve as much withdrawable balance as possible.
The primitive also cleanly separates layers that later TCR narratives often blur together. PLCR itself manages hidden commitments and token locking, but staking penalties, challenge rewards, and registry-state transitions live in the calling application.
The repository docs make another analytically important point: in its described form, PLCR does not itself slash minority voters. That means secret ballot, multi-poll concurrency, and economic punishment are not one inseparable mechanism.
The dev diary also exposes a notable implementation choice: linked-list-based tracking of token commitments across polls. That makes liquidity preservation a state-management problem inside the voting primitive rather than a mere UI convenience.
PLCR Voting belongs in the corpus because it gives the registry and curation cluster a clean lower-layer baseline beneath adChain-style TCRs, Kleros-style dispute systems, and other token-weighted onchain voting designs.
Whitepaper: No canonical standalone PLCR whitepaper surfaced in this pass. The strongest primary materials were the ConsenSys repository README and adChain’s detailed implementation walkthrough collected in ../whitepapers/plcr-voting-primary-sources-2026-05-13.md.