§ 00 / PRINCIPLES
Private. Transparent. Sovereign.
Three principles guide every architectural and product decision we make. This page states each principle, explains how it's enforced, and names where it doesn't fully hold — in the same screen.
§ 01 / PRIVATE
PII belongs to the member, not the platform.
Personally identifiable information lives in a hardware-encrypted Secure Vault on the member's device — AES-256-GCM under a Secure Enclave (iOS) or StrongBox (Android) master key. Our servers store HMAC hashes and risk scores, never the underlying values. Data does not leave the Vault as raw attributes; spaces ask narrow questions (is this member over 18?) and receive booleans. Messaging uses MLS (RFC 9420) end-to-end encryption; we store opaque ciphertext only. Server-side metadata auto-deletes at 12 months.
Where this doesn't fully hold: Identity verification (Passport activation) routes through Didit, our KYC partner. During the 72-hour processing window, your government ID image, selfie, and liveness data physically reside on Didit's servers. Raw documents are deleted after that window per the Data Processing Agreement. Until Didit's Indian data residency on AWS ap-south-1 is GA, Indian users' KYC may transit EU infrastructure. The wallet ciphertext is mandatorily backed up to our servers; we cannot decrypt without your recovery phrase, but the encrypted blob's physical custody is ours.
§ 02 / TRANSPARENT
Members always know who has power over them.
Every space's admin team is publicly listed. Admin-team changes notify all members. Every query invocation against a member's Secure Vault is logged to the member's on-device Consumer Badge Vault. Sensitive query invocations trigger immediate member notifications. Moderation actions display the moderator's identity — anonymous moderation is not supported. Trust dependencies (KYC, payment processors, cloud, hardware OEMs) are named in the Trust page. DSA Article 17 statements of reasons are emitted at every enforcement action.
Where this doesn't fully hold: Our source code is not open. We don't yet ship reproducible builds (Android target H2 2026); we don't yet have a published third-party security audit (pre-revenue); we don't yet publish a periodic transparency report on government data requests (first edition Q4 2026); we don't yet run a paid bug bounty programme (responsible-disclosure inbox at security@clikkin.com in the meantime). The internal meaning of "Transparent" here is: we name our trust dependencies and log queries on-device. The verifiable proofs (open-source, audited, reproducible) are commitments not yet shipped.
§ 03 / SOVEREIGN
Members control identity, data, and participation. Spaces control keys, rules, and membership.
Space admin keys are hardware-backed and held by the space's admins themselves; we cannot decrypt content under those keys. Per-member key wrap (Tresorit pattern) handles the join flow. Badges are the sole authorisation primitive — no parallel permission matrices, no hidden admin overrides. Members can leave with their handle, badges, content, and wallet recovery phrase. Coin balances, badge holdings, and credential records are exportable. Every consent (tiered queries the member grants to spaces) is explicit, revocable, and logged on-device.
Where this doesn't fully hold: The wallet ciphertext is mandatorily server-backed-up (we can't decrypt, but we hold the blob). There is no self-hosting outside the Enclave tier ($50K+/year); we are not federated and don't export to ActivityPub or AT Protocol. The persona handle, the email anchor, and the account itself live on our servers — Tier-5 hard-line offence enforcement can end an account. The coin economy is fully Clikkin-controlled scrip with no external redeemability. Space-level sovereignty is real and architecturally enforced; member-level sovereignty is partial.
§ 04 / WHERE WE EXTEND TRUST
We don't claim to be trustless.
Every platform extends trust to some set of third parties and legal frameworks. Naming where that trust lies is itself a form of transparency — refusing to name it would violate the second principle. We extend trust to: Didit (identity verification, 72-hour retention per DPA), Razorpay (Indian payment processing), Stripe (US/EU/RoW payment processing), RevenueCat (IAP subscription orchestration), Hetzner / Cloudflare (cloud and edge infrastructure), Apple / Google (hardware-backed cryptography), and the legal enforceability of our contracts in the jurisdictions we operate in. Where trust is extended, we minimise it where the architecture allows, and we prefer providers whose business model is not at odds with these principles.
§ 05 / ARCHITECTURAL NOTES
Honest centralisation.
Clikkin does not use blockchain, smart contracts, or distributed consensus. All data lives on our servers. The architectural guarantees above come from encryption, key management, and access controls — not from distributing trust across nodes. This is a deliberate choice: distributed consensus introduces latency and transaction costs incompatible with the product's UX requirements, and most consumer-facing "decentralised" products re-centralise around a small set of well-funded nodes. We prefer honest centralisation with strong cryptographic minimisation of what the centre can see.