Architecture
Unlike instance-specific contracts, the identity register operates at the issuer level. All tokens you deploy across multiple instances query the same registry for verification status. This architecture prevents verification fragmentation while maintaining privacy—users verify once and transfer tokens across all your instances without re-verification.The identity register eliminates redundant KYC processes. One verification grants access to all tokens within your organization while preserving instance-level compliance rule isolation.
Identity Issuers
Only authorized identity issuers can write verification proofs to the registry. To become an authorized issuer, request identity verification service during registration or contact our team for existing accounts. Authorization ensures only trusted institutions submit verification data preventing unauthorized or fraudulent proofs.Stored Data Structure
Each verification stores minimal data on-chain using cryptographic commitments:| Field | Description |
|---|---|
user | Wallet address being verified |
kycHash | SHA256 hash of KYC documents (passport, address proof) |
countryHash | SHA256 hash of ISO 3166-1 alpha-2 country code |
investorType | Classification: retail, accredited, institutional, or qualified |
expiry | Unix timestamp when verification expires (0 = never) |
Cross-Instance Verification
When a user attempts a token transfer, the token contract queries the identity register for verification status. The register returns proof validity without exposing personal data. This check adds approximately 5,000 gas to each transfer but enables automatic compliance enforcement across all your tokens. Expired verifications fail automatically at the contract level. Revoked verifications prevent transfers immediately across all instances. Update verification status once and the change propagates to every token you’ve deployed.Identity Proofs
Learn how zero-knowledge proofs protect customer data
Customer Management
Manage verifications through portal or API