Onchain KYC đã trở thành lớp cơ sở hạ tầng quan trọng để kết nối tài chính truyền thống với các giao thức phân tán. Tuy nhiên, mỗi triển khai đều phải đối mặt với một vấn đề cơ bản về tuân thủ: bạn có thể tối ưu hóa cho quyền riêng tư, tuân thủ hoặc khả năng sử dụng – nhưng không phải tất cả ba yếu tố cùng một lúc. Bài viết này phân tích bốn phương pháp hàng đầu – zkKYC, Soulbound Tokens (Galxe Passport), Xác minh thị trường (Base) (Civic Gateway), và W3C DID/VC Standards (KILT) – để các nhà quản lý tuân thủ và các nhà phát triển có thể chọn giải pháp phù hợp với các hạn chế thực tế của họ, không phải dựa trên những tuyên bố về marketing.
Primary keyword: onchain KYC Secondary keywords: zkKYC, Galxe Passport, Civic, KILT, selective disclosure, travel rule
Tại sao KYC truyền thống bị phá vỡ trên 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 | Sẵn sàng tuân thủ | 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 | Trung bình (tùy thuộc vào nhà phát hành) | Centralized issuer |
| Civic Gateway | Market-based verifiers | Selective via Gateway protocol | Medium (Gatekeeper quality) | Incentive alignment |
| KILT Protocol | W3C DID + VC | Selective disclosure (BBS+) | Cao (các tiêu chuẩn - 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 | Sự tích hợp đáng chú ý |
|---|---|---|---|
| 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.
KPIs (đến năm 2024):
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
Khác với Galxe (người phát hành duy nhất) hoặc zkKYC (một tập hợp người phát hành cố định), Gateway tạo ra một thị trường để xác minh. Các Gatekeeper cạnh tranh về giá, tốc độ, phạm vi thẩm quyền và uy tín. Người dùng chọn Base dựa trên các yêu cầu tRust.
Thực tế đa chuỗi: Gateway hoạt động trên Solana, Polygon, BSC, Base và mainnet Ethereum. Mã thông báo CVC được kết nối qua Wormhole – tăng nguy cơ kết nối.
Các thách thức về sự đồng bộ hóa các khuyến khích
- Gatekeeper chất lượng: Không cắt giảm cho các xác minh không tốt (chỉ dựa trên uy tín)
Khi lựa chọn Gateway Civic:
- Cần hỗ trợ đa chuỗi mà không cần các tích hợp riêng biệt
- Muốn có mức giá xác minh cạnh tranh
- Đồng ý với mô hình tRust dựa trên khuyến khích bằng token
- **Tránh nếu cần đảm bảo tuân thủ xác định, hoặc hoạt động trong các khu vực pháp lý hạn chế các token có giá trị sử dụng
Phương pháp 4 — KILT Thông lệ: W3C DID/VC Các tiêu chuẩn về Polkadot
Kiến trúc dựa trên tiêu chuẩn
KILT thực hiện W3C Mã định danh phân cấp (DIDs) và Verifiable Credentials (VCs) trên parachain Polkadot của nó. Đây không phải là một tiêu chuẩn độc quyền – nó là tiêu chuẩn tương tự được sử dụng bởi EU eIDAS 2.0, Microsoft Entra Verified ID và ISO/IEC 18013-5 (mDL).
Các thành phần chính:
- DIDs:
DID:KILT:4nx...— các định danh được người dùng điều khiển - CTypes (Các loại yêu cầu): các mô hình JSON xác định cấu trúc chứng chỉ (ví dụ, "KYC-CType" với các trường: tên, ngày sinh, quốc tịch, documentHash)
Polkadot Tùy thuộc hệ sinh thái
Kiến trúc parachain của KILT có nghĩa là:
- Native cho Polkadot: Gửi tin nhắn XCMP native đến các parachain khác (Acala, Moonbeam, Astar)
- Truy cập EVM: thông qua Moonbeam (parachain tương thích với EVM) hoặc các cầu nối — tăng độ trễ và các giả định về tRust
Phát triển: chuỗi Energy Web (ngành năng lượng), các dự án hệ sinh thái Polkadot (như Acala và Parallel Finance), dự án thử nghiệm của chính phủ Đức (GAIA-X).
Khi nào nên chọn 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+ Đơn ký | 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 | Dây chuyền tùy chỉnh | 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
Câu hỏi về quy định chưa được giải quyết: liệu FATF có chấp nhận bằng chứng ZK như là "thư liệu nguồn đáng tin cậy và độc lập" theo Khuyến nghị 10 không? Hướng dẫn hiện tại không nói gì về vấn đề này. Hiện tại, hầu hết các VASP đều truyền tải toàn bộ IVMS101 – việc tiết lộ chọn lọc vẫn chỉ là lý thuyết đối với việc tuân thủ quy định của Travel Rule.
Cơ chế quyết định của người phụ trách tuân thủ
Sử dụng danh sách kiểm tra này để phù hợp các giới hạn của bạn với phương pháp phù hợp:
| Kiểm duyệt | zkKYC | Galxe Passport | Civic Đường dẫn | KILT |
|---|---|---|---|---|
| Yêu cầu bảo mật tối đa | ✅ Tốt nhất | ❌ Public SBT | ✅ Chọn lựa | ✅ Chọn lựa |
| FATF Travel Rule sẵn sàng | ✅ (với IVMS101) | ⚠️ Tùy thuộc vào nhà phát hành | ⚠️ phụ thuộc vào Gatekeeper | ✅ (W3C VC) |
| Tích hợp nhanh nhất | ❌ SDK phức tạp | ✅ 4000+ giao thức | ✅ SDK đa chuỗi | ❌ Polkadot chỉ |
| Kháng cự kiểm duyệt | ✅ (những người xác minh phân tán) | ❌ Nhà phát hành duy nhất | ⚠️ Thị trường-Based | ✅ (giải phóng trung tâm) |
| Tuân thủ các tiêu chuẩn | ❌ Độc quyền | ❌ Độc quyền | ❌ Độc quyền | ✅ W3C DID/VC |
| Các nhà cung cấp Việt Nam/ địa phương KYC | ⚠️ Số lượng hạn chế | ✅ Sumsub/Veriff được tích hợp | ✅ Các địa phương có thể có Gatekeeper | ⚠️ Số lượng hạn chế |
Lý thuyết quyết định:
- Có xây dựng trên Polkadot/Substrate không? → KILT
- Cần mức độ bảo mật tối đa + có kỹ thuật ZK không? → zkKYC (cho EVM, zkMe cho nhiều chuỗi)
- Cần tốc độ nhanh nhất vào thị trường + chấp nhận tập trung? → Galxe Passport
- Cần nhiều chuỗi + thị trường xác minh cạnh tranh? → Civic Gateway
- Diálogo pháp lý yêu cầu tiêu chuẩn W3C không? → KILT (hoặc ủng hộ tiêu chuẩn zkKYC)
Kiểm tra thực tế về việc tích hợp nhà phát triển
| Đơn vị đo | Polygon ID (zkKYC) | Galxe Passport | Civic Đường dẫn | KILT |
|---|---|---|---|---|
| Ngôn ngữ SDK | TypeScript, Rust, React Native | TypeScript (SDK Passport) | TypeScript, React Native | Rust, TypeScript (Polkadot JS) |
| Xác minh khí | ~200-500k khí | ~150k gas (mint SBT) | ~180k gas (credential) | ~250k khí (VC kiểm tra) |
| Hỗ trợ ví | MetaMask Snaps, WC v2, AA | Tất cả các ví EVM | Tất cả các ví EVM + Solana | Polkadot.js, Talisman, SubWallet |
| Điều kiện tùy chỉnh | Circom mạch (cần kiểm toán) | Có hạn (v2 zkGalxe) | Gatekeeper được định nghĩa | Mô hình CType (không có mã) |
| Sẵn sàng cho Mainnet | ✅ Polygon, Ethereum, L2 | ✅ Ethereum, L2 | ✅ Multi-chain | ✅ Polkadot + Moonbeam |
Sự thật khó chịu:
- zkKYC các circuit cần được kiểm toán. Một lỗi trong circuit >18 tuổi = thất bại trong việc tuân thủ. Mở rộng ngân sách 50-100k cho kiểm toán circuit.
Bối cảnh Việt Nam: Tỷ lệ áp dụng cao, các ràng buộc độc đáo
Việt Nam nằm trong top 5 thế giới về việc chấp nhận tiền điện tử (Chainalysis 2023), nhưng hoạt động trong khu vực pháp lý không rõ ràng:
- 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.
Cơ hội cho Việt Nam: Một KYC bảo vệ quyền riêng tư kết nối với Momo/ZaloPay thông qua API, hỗ trợ thẻ ID Việt Nam (CCCD) và tạo ra bằng chứng ZK cho các giao thức DeFi – điều này vẫn chưa tồn tại. Nhà đi trước sẽ chiếm lĩnh thị trường.
Hỏi đáp
1. Onchain KYC có hợp pháp không? Tùy thuộc vào thẩm quyền. FATF Travel Rule chấp nhận "thư mục tài liệu đáng tin cậy và độc lập" - chứng minh zkKYC có thể đáp ứng yêu cầu nhưng chưa được kiểm tra. EU MiCA yêu cầu cấp phép CASP; onchain KYC có thể hỗ trợ tuân thủ nhưng không thay thế cho việc cấp phép. Hãy luôn liên hệ với luật sư địa phương.
2. Nếu một nhà phát hành zkKYC đi offline, thì sẽ xảy ra gì? Người dùng vẫn giữ các thông tin xác thực ở địa phương. Kiểm tra sẽ tiếp tục nếu verifier contract có khóa xác thực của nhà phát hành. Rủi ro: việc thay đổi khóa nhà phát hành yêu cầu người dùng xác thực lại. Polygon ID hỗ trợ thay đổi khóa thông qua quản trị; zkMe còn chưa phát triển.
3. Có thể hủy bỏ Soulbound Token không? ERC-721 không có chức năng hủy bỏ bản địa. Galxe dựa vào thời hạn hết hạn của metADAta ngoài chuỗi (không được các nhà tích hợp sơ khai chú ý). KILT's Revocation Registry là giải pháp duy nhất đáng tin cậy trên chuỗi. Luôn kiểm tra trạng thái hủy bỏ trước khi sử dụng bất kỳ chứng chỉ nào.
4. Làm thế nào Selective Disclosure hoạt động với Travel Rule? Hypothét: VASP trao đổi toàn bộ IVMS101 ngoài chuỗi; bằng chứng ZK chứng minh rằng "payload IVMS101 phù hợp với ghi chép KYC" trong chuỗi. Thực tế: Không có VASP nào thực hiện điều này hiện nay. Cần sự minh bạch về quy định.
5. Thông qua giao thức nào có trải nghiệm tốt nhất cho các nhà phát triển? Polygon ID cho các nhóm EVM (SDK TypeScript, tài liệu chi tiết, Discord hoạt động). KILT cho các nhóm Polkadot/Substrate. Galxe cho các nền tảng quest/airdrop cần xác minh người dùng ngay lập tức. Civic cho các ứng dụng đa chuỗi chấp nhận kinh tế token.
6. Chi phí gas cho xác minh trên chuỗi là bao nhiêu?
Kết luận
Không có giải pháp thần kỳ cho onchain KYC. Trilemma tuân thủ buộc phải có những sự cân nhắc rõ ràng:
- zkKYC giành chiến thắng về bảo mật và sự đồng bộ hóa tiêu chuẩn – nhưng đòi hỏi sự trưởng thành trong kỹ thuật ZK
Bắt đầu với mô hình mối đe dọa của bạn, không phải với công nghệ. Hãy vẽ ra các yêu cầu của cơ quan quản lý, các mong đợi về quyền riêng tư của người dùng, khả năng kỹ thuật của đội ngũ của bạn và nhu cầu về khả năng kết hợp của giao thức. Sau đó, chọn phương pháp mà bạn có thể bảo vệ trước các cơ quan quản lý, người dùng và đội ngũ kỹ thuật của mình.
Vùng tiếp theo: tiêu chuẩn tương thích (TERM_30__Comm, TERM_51__, TERM_52__ TERM_53__ cho khả năng di chuyển chứng chỉ) và sự minh bạch trong quy định về việc chấp nhận bằng chứng ZK. Cho đến khi đó, hãy xây dựng theo mô hình modular – trừu tượng lớp xác định để bạn có thể thay đổi các phương thức thực hiện khi môi trường phát triển.
Bài viết được cập nhật: 2026-08-20 Tác giả: blockchain Nghiên cứu tuân thủ + Tiến sĩ lập trình hợp đồng thông minh Nguồn: FATF Hướng dẫn 2021, Polygon ID/zkMe/Galxe/Civic/KILT tài liệu chính thức, W3C DID/VC thông số kỹ thuật, Chainalysis 2023, các chỉ số trên chuỗi thông qua Dune Analytics