
How to make Money on Polymarket
Guide to prediction markets, probability economics, and onchain edge

Fileverse: Redefining Private Data Ownership and Collaboration in Web3
Why a new data layer matters

Aztec is the blockchain that Mastered the Privacy Problem
Positioning Aztec in the Privacy Landscape



How to make Money on Polymarket
Guide to prediction markets, probability economics, and onchain edge

Fileverse: Redefining Private Data Ownership and Collaboration in Web3
Why a new data layer matters

Aztec is the blockchain that Mastered the Privacy Problem
Positioning Aztec in the Privacy Landscape
Share Dialog
Share Dialog
Subscribe to DYORLabz
Subscribe to DYORLabz
<100 subscribers
<100 subscribers
Identity remains one of the most persistent architectural challenges in both centralized and decentralized digital systems. Traditional Web2 identity infrastructures are inherently centralized, rely on trusted intermediaries, and optimize for access control at the expense of privacy. They accumulate vast amounts of personal data, creating attractive targets for breaches, enabling pervasive tracking, and exposing users to inference attacks.
Early Web3 identity experiments largely replicated these shortcomings replacing usernames with wallet addresses, social graphs with onchain registries, and KYC portals with NFT-based profiles while inheriting the same linkage and surveillance properties. ZKPassport introduces a fundamentally different paradigm: identity as a set of cryptographically verifiable properties rather than a persistent public identifier.
Listen to our podcast with co-founder ZKPassport Here
Digital identity systems must simultaneously satisfy three requirements: authentication, authorization, and auditability. Web2 solutions (OAuth, social login, centralized identity providers) achieve these by concentrating data and control in a small number of trusted parties, resulting in well-documented privacy and security failures.
In Web3, the introduction of self-custodial wallets shifted key management to users but did not resolve the semantic identity gap. A wallet address controls a private key; it does not intrinsically represent a natural person, a legal entity, or any stable attribute. Users routinely operate multiple wallets, share keys with agents or organizations, and deploy automated accounts. Treating wallet addresses as persistent identities therefore produces:
Permanent onchain linkage of all activities
Cross-protocol and cross-chain correlation
Behavioral profiling and inference attacks
Public identity graphs that grow richer over time
These are not theoretical risks; they are observable today in onchain analytics platforms, MEV strategies, and regulatory compliance tooling.
A cryptographically sound identity system for decentralized environments must satisfy five non-negotiable properties:
Selective disclosure – Reveal only the minimal set of attributes required for a given interaction.
Unlinkability – Prevent correlation of interactions across contexts without explicit user consent.
Cryptographic verifiability – Allow any party (including smart contracts) to verify claims without learning underlying data.
Decentralized trust – Rely on distributed or multi-party issuance rather than a single authoritative registry.
Onchain composability – Integrate seamlessly with smart contracts, tokens, DAOs, and private execution environments.
Existing Web3 identity primitives like ENS names, soulbound tokens, onchain schemas, and public KYC NFTs fundamentally violate at least the first two criteria.
ZKPassport redefines identity as a collection of signed, user-held credentials that assert specific predicates over real-world attributes. Instead of issuing statements of the form “this wallet belongs to Alice,” the system issues credentials that enable proofs of the form:
“The holder possesses a valid, unrevoked credential from trusted issuer i”
“The holder satisfies predicate P (e.g., age ≥ 18, accredited investor status, non-sanctioned jurisdiction)”
“The holder is not on revocation list R”
Crucially, the zero-knowledge proof reveals nothing beyond the validity of the predicate. No personal data, no unique identifier, and no linkage to other proofs are disclosed unless the user deliberately chooses to do so. This is property-based identity, not pseudonymity or self-sovereign identity in the classical sense.

ZKPassport consists of:
Trusted validators verify attributes:
Age
Jurisdiction
Accreditation
Compliance status
Uniqueness
They issue cryptographic credentials to the user.
The user holds them.
Not the issuer.
Not the chain.
When interacting with a smart contract:
User generates proof of:
“I satisfy condition X.”
Proof reveals:
Nothing beyond validity.
No:
Name
Passport number
Address
Wallet history
Smart contract verifies:
Mathematical correctness of proof.
Not:
Personal data.
This is the fundamental innovation.
Identity data
Credential contents
Cross-platform usage
Personal metadata
Validity of claim
Compliance status (boolean or threshold-based)
Eligibility for action
User holds credential
↓
Generate ZK proof of condition
↓
Smart contract verifies proof
↓
Access granted
No Identity graph is created.
Core Technical Primitives
Trusted issuers (governments, regulated entities, DAOs, or decentralized validator sets) perform offchain verification of real-world attributes and issue cryptographic credentials. Each credential is a signed message containing only the necessary attributes, bound to a user-controlled keypair (wallet or dedicated ZK key). The credential is stored exclusively by the user never published onchain.
Zero-Knowledge Proof Generation
Using succinct non-interactive zero-knowledge proofs (e.g., Groth16, PLONK, or STARK variants), the user generates a proof that:
They hold a valid signature from an authorized issuer
The credential satisfies the required predicate
The credential has not been revoked (via efficient accumulator or Merkle-tree techniques)
The proof is constant-size, verifiable in a smart contract, and when properly constructed unlinkable across sessions.
Selective Disclosure
Users can prove arbitrary Boolean combinations of attributes (age, accreditation, jurisdiction, KYC status, uniqueness, etc.) while revealing only the logical outcome. Name, exact birth date, document number, and any other PII remain private.
Comparative Analysis
System | Data Custody | Linkability | Selective Disclosure | On-Chain Verifiability | Privacy Risk |
|---|---|---|---|---|---|
Web2 OAuth / Social Login | Centralized | High | None | None | Very High |
ENS / NFT Profiles | Public ledger | High | None | Full | High |
Traditional KYC NFTs | Public ledger | High | Limited | Full | High |
ZKPassport | User-held | Low (by design) |
Pattern 1: Compliance-Gated DeFi Pools
A regulated lending protocol requires proof of KYC/AML and accredited-investor status before deposit. The smart contract accepts a ZK proof of the predicate “valid KYC credential from issuer set S AND accredited-investor flag = true.” No whitelists, no persistent onchain identity, no jurisdiction leakage.
Pattern 2: Sybil-Resistant DAO Governance
Voters submit a non-linkable ZK proof of a uniqueness credential (e.g., proof-of-personhood or government-issued uniqueness document) at vote time. The contract records only the proof verification and vote weight. No public voter registry, no wallet clustering possible.
Pattern 3: Jurisdiction-Restricted Real-World Asset (RWA) Access
Tokenized securities contracts accept proofs of “residence in approved jurisdiction AND not on sanctions list.” The same credential can be reused across multiple protocols without creating cross-protocol linkage.
Pattern 4: Private Agent Authorization
Autonomous agents prove they operate under a verified compliance credential issued to their human principal, without revealing the principal’s wallet graph or identity.
Pattern5: Cross-Protocol Credential Reuse
A single credential (e.g., accredited-investor status) is used in Protocol A and Protocol B. Because each proof is generated fresh and contains no common identifier, the protocols cannot correlate the user’s activity.
ZKPassport is not a standalone solution but a policy layer that composes cleanly with:
Private execution environments (e.g., Aztec, ZK-rollups with private state)
Private data storage and collaboration (e.g., Fileverse-style encrypted spaces)
Private payment systems and intent solvers
Example: An Aztec private contract can require a ZKPassport proof of KYC at call time, then execute entirely within the private domain. The identity layer gates access; the execution layer protects the computation.
Efficient, unlinkable revocation – Traditional CRLs or accumulator-based revocation can leak metadata. Ongoing work explores zk-friendly accumulators, dynamic membership proofs, and per-credential revocation tokens that preserve zero-knowledge properties.
Multi-credential aggregation – Users often hold credentials from multiple issuers. Aggregating them into a single succinct proof while maintaining unlinkability and efficient verification is non-trivial.
Usability and key management – Seamless integration into consumer wallets, social recovery mechanisms that do not compromise credential privacy, and intuitive credential management interfaces remain critical UX-cryptography intersections.
Standardization of credential schemas and predicates – Interoperable formats for real-world attributes (age ranges, jurisdiction codes, accreditation tiers) that preserve privacy and allow cross-issuer composition.
ZKPassport reframes the classic tension between privacy and verifiability. Rather than forcing a binary choice between “no one knows anything” and “everyone can see everything,” it enables property-based trust: systems can verify exactly what they need, when they need it, without creating persistent surveillance infrastructure.The approach is conceptually related to classical anonymous credential systems (Camenisch-Lysyanskaya, Idemix, U-Prove) and attribute-based access control, but it is the first to achieve native, gas-efficient composition with public blockchains and smart contracts at internet scale.In an era where both Web2 platforms and public blockchains default to comprehensive data exposure, ZKPassport demonstrates that regulatory compliance, Sybil resistance, and access control can be achieved without mass surveillance or public identity graphs. It is not merely an incremental improvement; it is a foundational shift toward privacy-native decentralized systems.Identity in Web3 need not be a public registry or a social graph. It can and should be a cryptographic tool for proving facts without revealing secrets. ZKPassport provides a concrete, production-ready path toward that future.
Identity remains one of the most persistent architectural challenges in both centralized and decentralized digital systems. Traditional Web2 identity infrastructures are inherently centralized, rely on trusted intermediaries, and optimize for access control at the expense of privacy. They accumulate vast amounts of personal data, creating attractive targets for breaches, enabling pervasive tracking, and exposing users to inference attacks.
Early Web3 identity experiments largely replicated these shortcomings replacing usernames with wallet addresses, social graphs with onchain registries, and KYC portals with NFT-based profiles while inheriting the same linkage and surveillance properties. ZKPassport introduces a fundamentally different paradigm: identity as a set of cryptographically verifiable properties rather than a persistent public identifier.
Listen to our podcast with co-founder ZKPassport Here
Digital identity systems must simultaneously satisfy three requirements: authentication, authorization, and auditability. Web2 solutions (OAuth, social login, centralized identity providers) achieve these by concentrating data and control in a small number of trusted parties, resulting in well-documented privacy and security failures.
In Web3, the introduction of self-custodial wallets shifted key management to users but did not resolve the semantic identity gap. A wallet address controls a private key; it does not intrinsically represent a natural person, a legal entity, or any stable attribute. Users routinely operate multiple wallets, share keys with agents or organizations, and deploy automated accounts. Treating wallet addresses as persistent identities therefore produces:
Permanent onchain linkage of all activities
Cross-protocol and cross-chain correlation
Behavioral profiling and inference attacks
Public identity graphs that grow richer over time
These are not theoretical risks; they are observable today in onchain analytics platforms, MEV strategies, and regulatory compliance tooling.
A cryptographically sound identity system for decentralized environments must satisfy five non-negotiable properties:
Selective disclosure – Reveal only the minimal set of attributes required for a given interaction.
Unlinkability – Prevent correlation of interactions across contexts without explicit user consent.
Cryptographic verifiability – Allow any party (including smart contracts) to verify claims without learning underlying data.
Decentralized trust – Rely on distributed or multi-party issuance rather than a single authoritative registry.
Onchain composability – Integrate seamlessly with smart contracts, tokens, DAOs, and private execution environments.
Existing Web3 identity primitives like ENS names, soulbound tokens, onchain schemas, and public KYC NFTs fundamentally violate at least the first two criteria.
ZKPassport redefines identity as a collection of signed, user-held credentials that assert specific predicates over real-world attributes. Instead of issuing statements of the form “this wallet belongs to Alice,” the system issues credentials that enable proofs of the form:
“The holder possesses a valid, unrevoked credential from trusted issuer i”
“The holder satisfies predicate P (e.g., age ≥ 18, accredited investor status, non-sanctioned jurisdiction)”
“The holder is not on revocation list R”
Crucially, the zero-knowledge proof reveals nothing beyond the validity of the predicate. No personal data, no unique identifier, and no linkage to other proofs are disclosed unless the user deliberately chooses to do so. This is property-based identity, not pseudonymity or self-sovereign identity in the classical sense.

ZKPassport consists of:
Trusted validators verify attributes:
Age
Jurisdiction
Accreditation
Compliance status
Uniqueness
They issue cryptographic credentials to the user.
The user holds them.
Not the issuer.
Not the chain.
When interacting with a smart contract:
User generates proof of:
“I satisfy condition X.”
Proof reveals:
Nothing beyond validity.
No:
Name
Passport number
Address
Wallet history
Smart contract verifies:
Mathematical correctness of proof.
Not:
Personal data.
This is the fundamental innovation.
Identity data
Credential contents
Cross-platform usage
Personal metadata
Validity of claim
Compliance status (boolean or threshold-based)
Eligibility for action
User holds credential
↓
Generate ZK proof of condition
↓
Smart contract verifies proof
↓
Access granted
No Identity graph is created.
Core Technical Primitives
Trusted issuers (governments, regulated entities, DAOs, or decentralized validator sets) perform offchain verification of real-world attributes and issue cryptographic credentials. Each credential is a signed message containing only the necessary attributes, bound to a user-controlled keypair (wallet or dedicated ZK key). The credential is stored exclusively by the user never published onchain.
Zero-Knowledge Proof Generation
Using succinct non-interactive zero-knowledge proofs (e.g., Groth16, PLONK, or STARK variants), the user generates a proof that:
They hold a valid signature from an authorized issuer
The credential satisfies the required predicate
The credential has not been revoked (via efficient accumulator or Merkle-tree techniques)
The proof is constant-size, verifiable in a smart contract, and when properly constructed unlinkable across sessions.
Selective Disclosure
Users can prove arbitrary Boolean combinations of attributes (age, accreditation, jurisdiction, KYC status, uniqueness, etc.) while revealing only the logical outcome. Name, exact birth date, document number, and any other PII remain private.
Comparative Analysis
System | Data Custody | Linkability | Selective Disclosure | On-Chain Verifiability | Privacy Risk |
|---|---|---|---|---|---|
Web2 OAuth / Social Login | Centralized | High | None | None | Very High |
ENS / NFT Profiles | Public ledger | High | None | Full | High |
Traditional KYC NFTs | Public ledger | High | Limited | Full | High |
ZKPassport | User-held | Low (by design) |
Pattern 1: Compliance-Gated DeFi Pools
A regulated lending protocol requires proof of KYC/AML and accredited-investor status before deposit. The smart contract accepts a ZK proof of the predicate “valid KYC credential from issuer set S AND accredited-investor flag = true.” No whitelists, no persistent onchain identity, no jurisdiction leakage.
Pattern 2: Sybil-Resistant DAO Governance
Voters submit a non-linkable ZK proof of a uniqueness credential (e.g., proof-of-personhood or government-issued uniqueness document) at vote time. The contract records only the proof verification and vote weight. No public voter registry, no wallet clustering possible.
Pattern 3: Jurisdiction-Restricted Real-World Asset (RWA) Access
Tokenized securities contracts accept proofs of “residence in approved jurisdiction AND not on sanctions list.” The same credential can be reused across multiple protocols without creating cross-protocol linkage.
Pattern 4: Private Agent Authorization
Autonomous agents prove they operate under a verified compliance credential issued to their human principal, without revealing the principal’s wallet graph or identity.
Pattern5: Cross-Protocol Credential Reuse
A single credential (e.g., accredited-investor status) is used in Protocol A and Protocol B. Because each proof is generated fresh and contains no common identifier, the protocols cannot correlate the user’s activity.
ZKPassport is not a standalone solution but a policy layer that composes cleanly with:
Private execution environments (e.g., Aztec, ZK-rollups with private state)
Private data storage and collaboration (e.g., Fileverse-style encrypted spaces)
Private payment systems and intent solvers
Example: An Aztec private contract can require a ZKPassport proof of KYC at call time, then execute entirely within the private domain. The identity layer gates access; the execution layer protects the computation.
Efficient, unlinkable revocation – Traditional CRLs or accumulator-based revocation can leak metadata. Ongoing work explores zk-friendly accumulators, dynamic membership proofs, and per-credential revocation tokens that preserve zero-knowledge properties.
Multi-credential aggregation – Users often hold credentials from multiple issuers. Aggregating them into a single succinct proof while maintaining unlinkability and efficient verification is non-trivial.
Usability and key management – Seamless integration into consumer wallets, social recovery mechanisms that do not compromise credential privacy, and intuitive credential management interfaces remain critical UX-cryptography intersections.
Standardization of credential schemas and predicates – Interoperable formats for real-world attributes (age ranges, jurisdiction codes, accreditation tiers) that preserve privacy and allow cross-issuer composition.
ZKPassport reframes the classic tension between privacy and verifiability. Rather than forcing a binary choice between “no one knows anything” and “everyone can see everything,” it enables property-based trust: systems can verify exactly what they need, when they need it, without creating persistent surveillance infrastructure.The approach is conceptually related to classical anonymous credential systems (Camenisch-Lysyanskaya, Idemix, U-Prove) and attribute-based access control, but it is the first to achieve native, gas-efficient composition with public blockchains and smart contracts at internet scale.In an era where both Web2 platforms and public blockchains default to comprehensive data exposure, ZKPassport demonstrates that regulatory compliance, Sybil resistance, and access control can be achieved without mass surveillance or public identity graphs. It is not merely an incremental improvement; it is a foundational shift toward privacy-native decentralized systems.Identity in Web3 need not be a public registry or a social graph. It can and should be a cryptographic tool for proving facts without revealing secrets. ZKPassport provides a concrete, production-ready path toward that future.
Full |
Full (via ZK) |
Low |
Full |
Full (via ZK) |
Low |
No activity yet