StarkWare Unveils Private KYC on Starknet: Zero-Knowledge Identity Verification Without Exposing Personal Data
StarkWare's Private KYC demo uses zero-knowledge STARK proofs and STRK20 privacy features to let users prove specific identity attributes on Starknet without revealing their passport, name, or address. Here's how the system works and what it means for compliant Web3 development.
Identity verification online runs on a model that has not changed in over a decade. To prove you are over 18, you hand over your full passport. To confirm you hold a valid credential, you surrender your name, date of birth, nationality, and document number. Every check creates another copy of your identity, sitting in another database, waiting to become the next breach statistic. In 2025, the United States alone recorded 3,322 data compromises — a 79 percent increase over five years — and the global average cost of a data breach now sits at $4.4 million.
On June 24, 2026, StarkWare introduced a fundamentally different approach. The company unveiled Private KYC, a working demonstration of zero-knowledge identity verification built on Starknet that lets users prove specific attributes — such as being over 18 or holding a valid credential — without ever revealing the document behind them. The system uses STRK20, Starknet's privacy capability for ERC-20 tokens, combined with STARK proofs to achieve what the company calls selective disclosure: the verifier learns exactly what they need to know, and nothing else.
The Problem: Identity Verification Is Broken
Today's KYC processes follow a collect-and-store model. A user uploads their passport. The verifier copies it, hashes it, stores it. If the verifier gets breached — and eventually, most do — the user's complete identity document is exposed. There is no way to separate the attribute being checked from the document that proves it. Proving you are over 18 means exposing your birthdate, your passport number, and your full legal name. Proving you are not on a sanctions list means exposing everything about you to a screening database.
This model creates what security researchers call a verifier honeypot — a single database containing thousands of full identity documents, each one a liability. The breach at any one of these verifiers compromises every user who ever submitted a document to them. And because KYC data is static — your birthdate and passport number do not change — a single breach creates permanent exposure.
StarkWare's Private KYC proposal breaks this model by moving the proof, not the document. The identity stays encrypted on the user's own Starknet account. Only the zero-knowledge proof of a specific attribute travels to the verifier.
What Is Private KYC?
Private KYC is a demonstration application built on STRK20, Starknet's privacy extension for ERC-20 assets. It shows how government and institutional identity verification can work when proving an attribute no longer means surrendering the data behind it.
At its core, the system replaces document submission with cryptographic proof generation. Instead of uploading a passport to a verifier's server, the user scans it locally on their own phone. The NFC chip read confirms the document is genuine — signed by its issuing authority — without any third party touching the raw data. The identity is then encrypted directly to the user's public Starknet account. No viewing key exists; the encrypted identity is never decryptable. From that point forward, only the zero-knowledge proofs of specific attributes, generated by the user on their own device, ever become visible to anyone else.
This is not a theoretical concept. Private KYC is a working demo that StarkWare uses to walk government and institutional teams through ZK-identity on Starknet. It gates a shielded private claim from a payout pool to identified accounts only, demonstrating that verification and the action it unlocks can happen entirely without the verifier ever seeing the identity behind the account.
How STRK20 Makes Selective Disclosure Possible
STRK20 is Starknet's privacy capability for fungible tokens, extending the standard ERC-20 interface with confidentiality features. In the context of Private KYC, STRK20 provides three critical primitives that make the system work.
First, programmable eligibility. A verified attribute — such as over-18 status — becomes an onchain signal that any smart contract can read and act on. This is not a static badge stored in a database. It is a cryptographic proof registered on Starknet that other contracts can check, without the identity behind it ever being exposed. Identity and value sit on the same privacy layer, composable with the rest of the Starknet ecosystem.
Second, self-custodied identity. The holder encrypts their identity directly to their own public Starknet account. No central verifier collects or warehouses the raw document. The encrypted identity has no viewing key and is never decryptable — only the attributes the holder chooses to prove are revealed. This inverts the traditional KYC model: instead of the verifier holding the data and the user hoping it stays secure, the user holds the data and the verifier receives only the specific proof they need.
Third, selective disclosure with no verifier honeypot. An institution confirms eligibility by reading a public onchain registry — essentially a list of verified accounts and their proved attributes — without ever scanning, storing, or becoming a liability for personal identity data. The registry contains only the fact that an account proved it is over 18, not the birthdate, passport number, or name that proves it.
The User Flow: Four Steps to Privacy-Preserving Verification
The Private KYC demo follows a single holder through four steps, from scanning a passport to receiving a gated transfer.
Step one: Self-service passport scan. The user opens the app on their own phone and scans their passport using the camera and NFC chip read. The chip read cryptographically confirms the document is genuine — signed by its issuing authority — without anyone else handling it. There is no verification desk, no document upload to a third-party server, no copy made.
Step two: Encrypted registration. The user connects their Starknet wallet, and the app encrypts the identity data to their own public Starknet account. Attributes such as over-18 are registered to a public onchain registry. Each passport can register only once, binding one verified identity to one onchain account and preventing Sybil attacks.
Step three: Proof generation and onchain submission. The app generates a zero-knowledge STARK proof of the registered attributes and submits it onchain. From this point, the attribute — for example, that a specific onchain account has proved it is over 18 — can be checked by any verifier that needs it. The name, date of birth, and document number behind that proof stay encrypted and never leave the user's control.
Step four: Gated private transfer. A verifier reads the onchain registry to confirm an account is identified, and the demo gates a shielded private claim from a payout pool to identified accounts only. The entire flow — verification and the action it unlocks — happens without the verifier ever seeing the identity behind the account.
Why This Matters for Web3 Developers
Private KYC may be a demo aimed at governments and institutions, but the underlying infrastructure has direct implications for builders in the Web3 space. The STRK20 privacy layer and the onchain attribute registry are not proprietary — they are Starknet-native capabilities that any developer can integrate into their own applications.
Consider the use cases. A DeFi protocol could gate access to a permissioned liquidity pool by checking an onchain over-18 attribute, without ever collecting user KYC data or assuming the legal liability that comes with it. A DAO governance system could require proof of jurisdiction — a user proves they are not in a restricted country — without knowing where exactly the user lives. An NFT mint could verify that participants are accredited investors using onchain proofs, without the organizer ever seeing a single tax document.
Each of these examples follows the same pattern: the contract checks an onchain registry for a proved attribute and gates an action behind it, while the underlying identity data remains encrypted and self-custodied. This is the developer story Private KYC is telling: identity verification can become a composable onchain primitive, no different from checking a token balance or verifying a signature.
Starknet's account abstraction model also plays a role here. Because Starknet accounts are smart contracts, identity attributes can be associated with the account itself rather than with an externally owned address. This opens the door to recoverable identity — if a user loses their signing key, the encrypted identity can be re-associated with a new key through the account's recovery logic, without re-verifying the document.
The Regulatory Context: MiCA, Data Breaches, and Institutional Demand
The timing of Private KYC is not coincidental. The European Union's Markets in Crypto-Assets Regulation transitional period ends on July 1, 2026, less than a week from now. MiCA mandates customer due diligence for crypto-asset service providers across all 27 EU member states, meaning thousands of platforms will need compliant KYC flows — and the data protection obligations that come with them under GDPR.
At the same time, the cost of identity data breaches continues to rise. The 3,322 U.S. data compromises recorded in 2025 represent a 79 percent increase over five years, and each breach of a KYC database exposes static data — passport numbers, birthdates, addresses — that cannot be changed once leaked. The liability model where every verifier stores a copy of every identity document is approaching its breaking point.
Private KYC offers a path where compliance and data protection are not competing priorities. A platform regulated under MiCA could verify that a user is an EU resident and not on a sanctions list, using onchain zero-knowledge proofs, without ever storing the passport data that proves those facts. The verifier meets its regulatory obligations. The user retains control of their identity. The liability of holding a database of passports disappears.
What Builders Should Know
For developers already building on Starknet, or those watching the zero-knowledge identity space, Private KYC surfaces several practical considerations.
The STRK20 standard is the key unlock. STRK20 extends ERC-20 with confidentiality primitives, and Private KYC demonstrates one application of those primitives applied to identity rather than token balances. Understanding STRK20's selective disclosure model is the entry point for building privacy-preserving applications on Starknet. The Starknet developer documentation includes STRK20 reference implementations and testing guides.
The onchain attribute registry is a public good. Verified attributes registered onchain through Private KYC are readable by any contract. This means identity verification becomes composable: a single proof of over-18 status registered by one application can be consumed by any other application the user chooses to interact with. Builders should think of onchain identity attributes as reusable primitives, not application-specific checkpoints.
The NFC passport chip read is a critical security component. The chip contains a digital signature from the issuing authority that cannot be forged without physical access to the passport's secure element. This is what allows the Private KYC flow to dispense with a centralized verification desk: cryptographic verification of the document replaces institutional trust in the verifier.
Conclusion: Identity as a Proof, Not a Document
StarkWare's Private KYC demonstration makes a clear argument: the era of identity-as-document-submission is ending. When zero-knowledge proofs can verify exactly the attribute a verifier needs — and nothing else — collecting and storing full identity documents becomes not just a privacy liability, but an unnecessary one.
The demo gates access to a payout pool rather than a production financial service, and the STRK20 standard is still maturing. But the architecture is sound, the cryptographic primitives are proven, and the regulatory tailwinds — from MiCA enforcement to the rising cost of data breaches — are pushing institutions toward exactly this kind of solution.
For Web3 developers, the takeaway is straightforward: onchain identity verification with selective disclosure is no longer theoretical. The infrastructure exists on Starknet today, and the tools to build privacy-preserving KYC flows into your own applications are available. Whether you are building a DeFi protocol that needs compliant user onboarding, a DAO that requires jurisdictional proofs, or a gaming platform that needs age verification without collecting documents, the pieces are now in place. If you are ready to build, thirdweb offers developer plans that scale with your project.