Onchain KYC has become the critical infrastructure layer for bridging traditional finance with decentralized protocols. Yet every implementation faces a fundamental compliance trilemma: you can optimize for Privacy, Compliance, or Usability — but not all three simultaneously. This article dissects the four leading approaches — zkKYC, Soulbound Tokens (Galxe Passport), Market-based Verification (Civic Gateway), and W3C DID/VC Standards (KILT) — so compliance officers and developers can choose based on their actual constraints, not marketing claims.
Primary keyword: onchain KYC Secondary keywords: zkKYC, Galxe Passport, Civic, KILT, selective disclosure, travel rule
Why Traditional KYC Breaks on Blockchain
Traditional KYC was designed for centralized institutions with trusted databases. Blockchain breaks every assumption:
- Centralized honeypots: The 2023 Binance KYC leak exposed 1M+ users' PII. Celsius' bankruptcy revealed unencrypted identity data on AWS S3 buckets. On-chain, there is no "delete" button.
- FATF Travel Rule mismatch: The Financial Action Task Force requires VASPs to share originator/beneficiary data for transfers >$1,000 (IVMS101 format). But DeFi has no VASP — just pseudonymous addresses interacting with smart contracts.
- Onboarding friction: Chainalysis estimates 60-80% drop-off during KYC for DeFi protocols. Vietnamese users, accustomed to Momo/ZaloPay's 30-second onboarding, abandon flows requiring document uploads and video calls.
The core problem: blockchain is public by default, compliance is private by requirement. Any solution must reconcile this without creating new centralization vectors.
The Four Approaches to On-Chain Identity
| Approach | Core Primitive | Privacy Model | Compliance Readiness | Main Trade-off |
|---|---|---|---|---|
| zkKYC | ZK-SNARKs/STARKs | Selective disclosure via ZK proofs | High (Travel Rule compatible) | Complex UX, trusted setup |
| Galxe Passport | Soulbound Tokens (SBT) | On-chain visibility, v2 adds ZK | Medium (issuer-dependent) | Centralized issuer |
| Civic Gateway | Market-based verifiers | Selective via Gateway protocol | Medium (Gatekeeper quality) | Incentive alignment |
| KILT Protocol | W3C DID + VC | Selective disclosure (BBS+) | High (standards-based) | Polkadot ecosystem lock-in |
Approach 1 — zkKYC: Zero-Knowledge Proofs for Selective Disclosure
How It Works
zkKYC moves verification off-chain and submits only a zero-knowledge proof on-chain. The flow:
- Issuance: User completes KYC with a trusted issuer (Polygon ID, zkMe, Rarimo). Issuer signs a credential (hash of PII + attributes) into a Merkle tree.
- Proof Generation: User locally generates a ZK-SNARK proving: "I possess a valid credential in the Merkle tree" + "I satisfy predicate P (e.g., age > 18, not sanctioned)" — without revealing the credential itself.
- On-chain Verification: Smart contract verifies the proof. Nullifier prevents double-spending the same credential.
Key Players
| Protocol | Standard | Identities Issued | Notable Integration |
|---|---|---|---|
| Polygon ID | Iden3 (custom ZK) | 2M+ | Aave, Uniswap hooks, Polygon zkEVM |
| zkMe | ZK-SNARK (Circom) | 500K+ | BNB Chain, Linea, zkSync |
| Rarimo | ZK-SNARK (Halo2) | 300K+ | Social recovery, cross-chain identity |
Technical reality: Polygon ID's TypeScript SDK is production-ready (~200k gas per verification). zkMe offers mobile SDKs but requires Circom circuit knowledge for custom predicates. Rarimo focuses on social graphs — different threat model.
When to Choose zkKYC
- Priority: Maximum privacy + regulatory compliance
- Team: Has ZK engineering capacity or budget for audited circuits
- Jurisdiction: FATF/MiCA compliant regions requiring Travel Rule adherence
- Avoid if: Building for non-technical users, need rapid MVP, or operate in jurisdictions banning privacy tools
Approach 2 — Galxe Passport: Soulbound Tokens as Identity
The SBT Model
Galxe Passport mints a non-transferable ERC-721 (Soulbound Token) representing verified identity. Unlike zkKYC, the credential is the on-chain token — visible to everyone.
Issuance flow:
- User completes KYC via Galxe's partnered providers (Sumsub, Veriff, etc.)
- Galxe mints Passport SBT to user's address
- Protocols check
balanceOf(user) > 0or query Passport metadata
v2: zkGalxe Adds Privacy Layer
Galxe Passport v2 (2024) introduced zkGalxe — ZK proofs over the SBT metadata. Users can now prove "I hold a valid Passport" without revealing which Passport or its attributes. This addresses the core SBT privacy critique.
Adoption metrics (2024):
- 14M+ unique users across Galxe ecosystem
- 3.5M+ Passport holders
- 4,000+ integrated protocols (Linea, Scroll, Mantle, Berachain)
Centralization Risk
Galxe is the sole issuer. If Galxe censors, goes offline, or is compelled by regulators, 3.5M identities are affected. No revocation registry exists — expired Passports remain valid on-chain until manually burned.
When to choose Galxe Passport:
- Need instant integration with 4000+ protocols
- User base already in Galxe ecosystem (quest platforms, airdrop farmers)
- Compliance requirements accept centralized issuer model
- Avoid if: Censorship resistance is non-negotiable, or need cross-ecosystem portability
Approach 3 — Civic & Gateway: Market-Based Verification
Gateway Protocol Architecture
Civic's Gateway protocol (via Identity.com) introduces economic incentives for verification:
- Requester (protocol) posts a verification request with reward (CVC tokens)
- Gatekeepers (verified entities: exchanges, KYC providers, DAOs) bid to verify
- User selects Gatekeeper, completes KYC, receives credential
- Credential stored on-chain via Gateway's registry; Gatekeeper earns CVC
Differentiation: Competing Verifiers
Unlike Galxe (single issuer) or zkKYC (fixed issuer set), Gateway creates a market for verification. Gatekeepers compete on price, speed, jurisdiction coverage, and reputation. Users choose based on trust requirements.
Multi-chain reality: Gateway operates on Solana, Polygon, BSC, Base, and Ethereum mainnet. CVC token bridges via Wormhole — adding bridge risk.
Incentive Alignment Challenges
- Gatekeeper quality: No slashing for bad verifications (reputation only)
- CVC volatility: Rewards denominated in volatile token
- Sybil resistance: Gatekeeper onboarding requires Identity.com approval — re-centralization
When to choose Civic Gateway:
- Need multi-chain coverage without separate integrations
- Want competitive verification pricing
- Accept token-incentivized trust model
- Avoid if: Require deterministic compliance guarantees, or operate in jurisdictions restricting utility tokens
Approach 4 — KILT Protocol: W3C DID/VC Standards on Polkadot
Standards-First Architecture
KILT implements W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) natively on its Polkadot parachain. This is not a proprietary standard — it's the same spec used by EU eIDAS 2.0, Microsoft Entra Verified ID, and ISO/IEC 18013-5 (mDL).
Core components:
- DIDs:
did:kilt:4nx...— user-controlled identifiers - CTypes (Claim Types): JSON schemas defining credential structure (e.g., "KYC-CType" with fields: name, dob, nationality, documentHash)
- Attesters: Trusted entities (banks, governments, KYC providers) that sign credentials
- Revocation Registry: On-chain bitmap for efficient credential status checks
Polkadot Ecosystem Dependency
KILT's parachain architecture means:
- Native to Polkadot: Native XCMP messaging to other parachains (Acala, Moonbeam, Astar)
- EVM access: Via Moonbeam (EVM-compatible parachain) or bridges — adds latency and trust assumptions
- No native Ethereum mainnet deployment: Developers targeting Ethereum DeFi face friction
Adoption: Energy Web Chain (energy sector), Polkadot ecosystem projects (Acala, Parallel Finance), German government pilot (GAIA-X).
When to Choose KILT
- Priority: Standards compliance, interoperability with tradfi/government systems
- Stack: Building on Polkadot or Substrate
- Regulatory: Need W3C VC alignment for EU/US regulatory dialogues
- Avoid if: Primary target is Ethereum/EVM DeFi, team lacks Substrate/Rust expertise
Selective Disclosure: The Technical Bridge
Selective disclosure is where privacy meets compliance. Three technical approaches dominate:
| Technique | Mechanism | Standard | Used By |
|---|---|---|---|
| BBS+ Signatures | Multi-message signatures with selective reveal | IETF draft, ISO 23264 | KILT, cheqd, Dock |
| SD-JWT | JWT with selective disclosure via hash digests | IETF RFC 9599 | EU eIDAS 2.0, Microsoft Entra |
| ZK-SNARKs (Merkle) | Proof of membership + predicate satisfaction | Custom circuits | Polygon ID, zkMe, Rarimo |
Travel Rule + Selective Disclosure = Compliant Privacy
The FATF Travel Rule requires transmitting: originator name, account number, address, national ID, DOB + beneficiary name, account number.
Selective disclosure enables:
- Originator proves "I am KYC'd by licensed VASP X" without revealing name/address to beneficiary
- Beneficiary proves "I am not on sanctions list" without revealing identity to originator
- VASPs exchange IVMS101 payloads off-chain; ZK proofs attest to payload validity on-chain
Open regulatory question: Will FATF accept ZK proofs as "reliable, independent source documents" per Recommendation 10? Current guidance is silent. Most VASPs currently transmit full IVMS101 — selective disclosure remains theoretical for Travel Rule compliance.
Compliance Officer Decision Framework
Use this checklist to match your constraints to the right approach:
| Constraint | zkKYC | Galxe Passport | Civic Gateway | KILT |
|---|---|---|---|---|
| Max privacy required | ✅ Best | ❌ Public SBT | ✅ Selective | ✅ Selective |
| FATF Travel Rule ready | ✅ (with IVMS101) | ⚠️ Issuer-dependent | ⚠️ Gatekeeper-dependent | ✅ (W3C VC) |
| Fastest integration | ❌ Complex SDK | ✅ 4000+ protocols | ✅ Multi-chain SDK | ❌ Polkadot only |
| Censorship resistance | ✅ (decentralized verifiers) | ❌ Single issuer | ⚠️ Market-based | ✅ (decentralized) |
| Standards compliance | ❌ Proprietary | ❌ Proprietary | ❌ Proprietary | ✅ W3C DID/VC |
| Vietnam/local KYC providers | ⚠️ Limited | ✅ Sumsub/Veriff integrated | ✅ Local Gatekeepers possible | ⚠️ Limited |
Decision logic:
- Building on Polkadot/Substrate? → KILT
- Need maximum privacy + have ZK engineering? → zkKYC (Polygon ID for EVM, zkMe for multi-chain)
- Need fastest go-to-market + accept centralization? → Galxe Passport
- Need multi-chain + competitive verification market? → Civic Gateway
- Regulatory dialogue requires W3C standards? → KILT (or advocate for zkKYC standards)
Developer Integration Reality Check
| Metric | Polygon ID (zkKYC) | Galxe Passport | Civic Gateway | KILT |
|---|---|---|---|---|
| SDK Language | TypeScript, Rust, React Native | TypeScript (Passport SDK) | TypeScript, React Native | Rust, TypeScript (Polkadot JS) |
| Verification Gas | ~200-500k gas | ~150k gas (SBT mint) | ~180k gas (credential) | ~250k gas (VC verify) |
| Wallet Support | MetaMask Snaps, WC v2, AA | All EVM wallets | All EVM + Solana wallets | Polkadot.js, Talisman, SubWallet |
| Custom Predicates | Circom circuits (audit needed) | Limited (v2 zkGalxe) | Gatekeeper-defined | CType schemas (no code) |
| Mainnet Ready | ✅ Polygon, Ethereum, L2s | ✅ Ethereum, L2s | ✅ Multi-chain | ✅ Polkadot + Moonbeam |
Hard truths:
- zkKYC circuits require audits. A bug in age>18 circuit = compliance failure. Budget $50-100k for circuit audit.
- Galxe Passport = vendor lock-in. Migration means re-KYC all users.
- Civic Gateway = CVC token dependency. Protocol economics affect verification costs.
- KILT = Polkadot commitment. Not a library you "add" — it's an architecture decision.
Vietnam Context: High Adoption, Unique Constraints
Vietnam ranks top 5 globally for crypto adoption (Chainalysis 2023), yet operates in a regulatory grey zone:
- No comprehensive crypto law: SBV (State Bank) prohibits crypto payments; Decree 107/2023 prepares AML/CTF framework for future VASP licensing.
- Circular 14/2024/TT-NHNN: Banks must monitor crypto-related transactions — de facto KYC pressure on ramps.
- Local payment rails: Momo (30M users), ZaloPay (25M users) dominate. Any on-chain KYC must integrate with these for fiat on/off-ramp.
- Terminology: "KYC" used directly in tech circles; "Xác thực danh tính" for general audience. "Token gắn liền" for SBT.
Vietnamese opportunity: A privacy-preserving KYC that plugs into Momo/ZaloPay via API, supports Vietnamese ID cards (CCCD), and outputs ZK proofs for DeFi protocols — this doesn't exist yet. First mover captures the market.
FAQ
1. Is onchain KYC legally compliant? Depends on jurisdiction. FATF Travel Rule accepts "reliable, independent source documents" — zkKYC proofs may qualify but untested. EU MiCA requires CASP licensing; on-chain KYC can support compliance but doesn't replace licensing. Always engage local counsel.
2. What happens if a zkKYC issuer goes offline? Users retain credentials locally. Verification continues if verifier contract has the issuer's verification key. Risk: issuer key rotation requires user re-credentialing. Polygon ID supports key rotation via governance; zkMe less mature.
3. Can Soulbound Tokens be revoked? ERC-721 has no native revocation. Galxe relies on off-chain metadata expiry (ignored by naive integrators). KILT's revocation registry is the only robust on-chain solution. Always check revocation status before trusting any credential.
4. How does selective disclosure work with Travel Rule? Theoretically: VASPs exchange full IVMS101 off-chain; ZK proofs attest to "IVMS101 payload matches KYC record" on-chain. Practically: No VASP does this today. Regulatory clarity needed.
5. Which protocol has the best developer experience? Polygon ID for EVM teams (TypeScript SDK, extensive docs, active Discord). KILT for Polkadot/Substrate teams. Galxe for quest/airdrop platforms needing instant user verification. Civic for multi-chain apps accepting token economics.
6. What are the gas costs for on-chain verification?
- zkKYC verification: 200-500k gas (~$5-15 on Ethereum, <$0.01 on L2s)
- SBT mint/transfer: 150-200k gas
- VC verification (KILT): 250-350k gas
- Recommendation: Deploy verifiers on L2 (Arbitrum, Base, Polygon) or use account abstraction to sponsor gas.
Conclusion
There is no silver bullet for onchain KYC. The compliance trilemma forces explicit trade-offs:
- zkKYC wins on privacy and standards alignment — but demands ZK engineering maturity
- Galxe Passport wins on distribution and speed — but centralizes trust in one issuer
- Civic Gateway wins on multi-chain flexibility and market dynamics — but introduces token volatility and incentive complexity
- KILT wins on regulatory credibility via W3C standards — but locks you into Polkadot
Start with your threat model, not the technology. Map your jurisdiction's requirements, your users' privacy expectations, your team's technical capacity, and your protocol's composability needs. Then choose the approach whose trade-offs you can defend to regulators, users, and your engineering team.
The next frontier: interoperability standards (DIDComm, CAIP-10, ERC-4337 account abstraction for credential portability) and regulatory clarity on ZK proof acceptance. Until then, build modular — abstract the identity layer so you can swap implementations as the landscape evolves.
Article updated: 2026-08-20 Author: Blockchain Compliance Researcher + Smart Contract Developer Sources: FATF Guidance 2021, Polygon ID/zkMe/Galxe/Civic/KILT official docs, W3C DID/VC specs, Chainalysis 2023, on-chain metrics via Dune Analytics