Privacy Model
This page explains how Hadinet Africa protects your personal data using zero-knowledge proofs, encryption, and a privacy-first architecture.
The Core Principle
Traditional identity verification requires you to hand over personal data to every service that needs to verify you. Each copy of your data is a breach waiting to happen.
Hadinet reverses this: you prove a fact about yourself (e.g., "I am a verified resident of Nigeria") without revealing the underlying data (your name, ID number, address, or photo).
Data Lifecycle
During Verification
Your Documents -> KYC Provider (processes them) -> Verification Result
|
v
Attestor TEE (sees result briefly)
|
|-> ZK Proof (stored on-chain)
|-> Metadata only: country, level, status
+-> Personal data: DISCARDED
After Verification
- Your documents: Only exist on your device and at the KYC provider (per their retention policy)
- Your personal data: Not stored by Hadinet anywhere
- Your verification proof: Stored on the Cartesi rollup, tied to your wallet DID
- Your verification metadata: Country code, provider name, verification level — no PII
What "On-Chain" Means for Your Privacy
When we say data is stored "on-chain," it is natural to worry about public exposure. Here is what actually happens:
1. Input Encryption
All data sent to the Cartesi rollup is encrypted before it reaches the blockchain. It is encrypted with the rollup's public key, so only the rollup VM can decrypt it.
2. Selective Disclosure
Only non-personally-identifiable metadata is stored:
verified: truecountry_code: "NG"verification_level: "enhanced"provider: "smile_id"zk_proof: [cryptographic data]
3. No Reverse Engineering
There is no path from the on-chain data back to your personal identity. The country code "NG" applies to 200+ million people. The verification level is one of a few standard categories. None of this narrows down who you are.
Document Vault Encryption
Documents stored in the vault use a separate encryption layer:
| Property | Detail |
|---|---|
| Algorithm | AES-256-GCM |
| Key Derivation | PBKDF2 with unique salt per document |
| Storage | IPFS (Pinata, private gateway) |
| Metadata | On-chain (file name, type, size — no content) |
| Who can decrypt | Only the attestor TEE with the vault encryption key |
Documents are encrypted before they leave the attestor's Trusted Execution Environment. IPFS stores only encrypted blobs — even Pinata (the storage provider) cannot read your files.
What Hadinet Cannot Do
- It cannot access your personal data — the attestor processes it in-memory inside a TEE and discards it
- It cannot fake a verification — ZK proofs are tied to real TLS sessions with real KYC providers
- It cannot link your wallet to your real identity — only the KYC provider knows both, and they do not share it with Hadinet
- It cannot delete your on-chain proof — once recorded on the blockchain, your verification is permanent and tamper-proof
- It cannot read your vault documents — without the encryption key held inside the TEE
Privacy Guarantees Summary
| Guarantee | How It Is Achieved |
|---|---|
| No PII stored | Personal data discarded after ZK proof generation |
| On-chain privacy | Input encryption + non-PII metadata only |
| Document privacy | AES-256-GCM encryption before IPFS upload |
| Identity privacy | Pseudonymous DID derived from wallet — no real name linkage |
| Provider isolation | KYC provider does not know your wallet; Hadinet does not know your personal details |
Next Steps
- Trust Model — What you trust each component with
- Zero-Knowledge Proofs — How ZK proofs work in detail
- Encryption — Technical encryption details