2026-07-09 –, Idea Stage
Decentralized systems have not solved the problem of eligibility (who can hold what, and who can transfer to whom) without reintroducing a centralized gatekeeper or severely compromising user privacy. This talk presents a general pattern that solves both, combining zkTLS-verified traits from authoritative real-world sources with on-chain enforcement that rejects ineligible transfers before they execute, opening up everything from compliant tokenized securities to privacy-preserving DAO membership.
Abstract
Eligibility, meaning who can hold what and who can transfer to whom, is the part of any real-world economy that decentralized systems have not solved. Holding certain securities requires being a verified person of a particular jurisdiction. Joining a regulated pool may require accreditation. Participating in some communities requires being over a certain age. Almost every implementation today falls back on calling a centralized API or trusting a permissioned issuer to attest, which puts the gatekeeper right back in the middle of the system.
This talk presents a general pattern for on-chain eligibility that doesn't reintroduce a gatekeeper. Two ideas do the work together. First, zkTLS lets a user prove facts drawn directly from authoritative real-world sources like a bank, a tax authority, a passport service, or an exchange's KYC endpoint, without any intermediary trusted to relay them. The output is a small set of eligibility traits (is a resident of jurisdiction X, has some status or accreditation, is over 18), not the underlying data. Second, the chain enforces eligibility by simulating the post-transaction state of every party touched by a transfer and rejecting the transaction atomically if any global eligibility invariant would be violated. Ineligible transfers don't need to be detected and unwound. They never execute. This work is based on the pattern we've developed at Opacity.
The combination is powerful: real-world facts arrive on-chain in a privacy-preserving form, and the transfer function uses them to enforce invariants that hold across the whole system, not just at the edges. We'll walk through the mechanism in detail, including how eligibility traits get bound to addresses, what state the simulator inspects, what invariants are practical to express (per-asset, per-jurisdiction, per-holder caps and bans), and where the costs and limits live.
We'll then look at the design space this opens up: gating DAO membership on verified credentials without doxxing members, age-restricted communities that don't need to see anyone's ID, jurisdiction-aware protocols that respect local rules without a central enforcer, and worker co-ops verifying employment status against payroll data without exposing it. The same shape (verified inputs in, eligibility traits on-chain, atomic simulation at the transfer boundary) fits all of them.
Takeaways
- Why the transfer function is the right place to enforce eligibility, and why post-hoc detection isn't good enough
- How zkTLS turns authoritative real-world data into on-chain-checkable eligibility traits without exposing the underlying data
- How simulating post-transaction state lets a protocol enforce global invariants atomically, rather than per-account heuristics
- The design space this pattern opens: DAO membership, age-gating, jurisdiction-aware protocols, employment-verified co-ops, and beyond
- Honest discussion of the limits: trust assumptions in zkTLS, simulation cost, and what kinds of invariants are and aren't practical to express
Hudson Headley is a protocol engineer dedicated to decentralized governance, worker ownership, and developing post-capitalist economic structures. He is the creator of poa.box, a no-code tool for worker and community owned infrastructure enabling collective governance, project and task management, and finances. He also is a volunteer developer for bread.coop building all sorts of solidarity tech. His day job is working at Opacity Labs.
