Latest updates from version v1.0.0-alpha: Zero Leak is on Devnet 🔥
"The pre-seed investment would be used to create the Regulatory Sandbox, which consists of putting the current version of the project into production to validate the technical and practical approach in the market through presentations to the National Data Protection Agency (ANPD), law firms focused on Digital Law, and professionals who excel in the area of Privacy and Data Protection."
Zero Leak in 30 seconds
Zero Leak is a privacy-first age verification protocol that allows platforms to verify age without ever receiving personal data. It replaces identity disclosure with cryptographic proof anchored on Solana and verified via WebAuthn. Age verification anchored in Solana, with dynamic and biometric off-chain proof. No third-party selfies, processing of tax registration documents, or analysis of credit card data. Auditable privacy with public anchoring. No personal data leaves the device. Not to the chain, not to the relayer, and not to the website requesting the verification! MANIFESTO
In compliance with Law No. 15,211/2025 🇧🇷 and 13,709/2018 🇧🇷, Regulation (EU) 2016/679 🌍 (GDPR) and the Online Security Law of 2023 🇬🇧
Zero Leak is an age verification infrastructure built on four principles:
- The proof resides on the user's device, through a locally encrypted Verifiable Credential (VC). Legal advantage: extreme data minimization, exempting the platform from liability for the storage/processing of personal data.
- The anchor lives on-chain in Solana through a PDA seal that proves the user exists, has been audited by a Trusted KYC (Zero Leak's human agent, for example), and has not yet been revoked. Legal advantage: auditable guarantee of compliance.
- Age is dynamic, calculated in real time from the date of birth within the VC, and never published on the chain. Legal advantage: Compliance for age verification regulations applied with Privacy by Design / Default.
- Authorization is momentary; each verification produces an ephemeral (60s) single-use JWT linked to the session. Legal advantage: mitigation of intrusion risks and specific purpose of sharing credentials for access at a particular time.
The result: the verification site receives a signed boolean (ageOk: true, tier: 18), it never processes the user's facial identity, date of birth, tax ID, or financial data.
Summary
Here is the complete technical approach for the Zero Leak project, defining the system architecture, cryptographic standards, on-chain mechanics, and off-chain data flows.
Zero Leak implements a "Privacy by Design / Default" architecture. It completely decoupling identity verification from data storage by relying on localized proof execution and decentralized state anchoring.
- Zero PII On-Chain or In-Transit: No Personally Identifiable Information (PII) such as Date of Birth (DOB), photos, or government IDs ever leaves the user's device.
- Dynamic Off-Chain Execution: Age is calculated dynamically on the user's device at the time of verification, ensuring authorization without exposing static birth dates.
- Momentary Authorization: Verifications yield single-use, short-lived (60s) JSON Web Tokens (JWTs) cryptographically bound to a specific session.
┌──────────────────────┐ ┌─────────────────────────┐ ┌─────────────────────────┐
│ KYC Operator │ │ Relayer │ │ Solana RPC │
│ (/kyc — desktop) │ HTTPS │ (Next.js API routes) │ JSON │ localnet / devnet / │
│ ├───────▶│ ├───────▶│ mainnet │
│ - create intent │ │ - pays the fees │ │ │
│ - approve/reject │ │ - signs as authority │ │ Program: │
│ - write VC hash │ │ - validate the WebAuthn │ │ ID... │
└──────────────────────┘ │ - emits ephemeral JWT │ └─────────────────────────┘
└────────┬────────────────┘ ▲
│ │
│ HTTPS │
▼ │
┌──────────────────────┐ ┌─────────────────────────┐ │
│ PWA Wallet │ │ Verifier (desktop) │ │
│ (/wallet — mobile) │ │ (/verify) │ │
│ │ │ │ │
│ - WebAuthn passkey │ │ - displays QR code │ │
│ - VC cipher AES-GCM │ │ - JWT polling │ │
│ - IndexedDB local │ │ - Read VerifiedSeal PDA ├────────────────────┘
│ - sign assertion │ │ │
└──────────────────────┘ └─────────────────────────┘
Privacy by Design
| Principle | What this means in practice |
|---|---|
| Dynamic Off-chain | Age is calculated from the DOB at the time of proof; birthdays do not require on-chain rewrites. |
| Minimal On-chain | Only: existence, status (Verified/Revoked), vc_hash, passkey_id_hash, tier, issued_at. |
| Biometrics as a Key | The passkey (FIDO2/WebAuthn) is the only thing that can initiate a proof. |
| No Public PII | The chain does not store tax identification numbers, facial recognition data, names, DOBs, nor does it process images. Only hashes. |
| No User Private Key | All writes are paid for and signed by the relayer authority. |
| Auditable Human Revocation | Only the KYC operator can revoke; the transaction is visible in the explorer. |
The Solana smart contract (zero_leak) acts strictly as an immutable, minimized state layer to anchor the existence and validity of a Verifiable Credential (VC).
- Program Accounts (PDAs):
ProgramConfig: Derived via[b"config"]. Stores the global authority (Pubkey) and apausedstate (kill-switch).VerifiedSeal: Derived via[b"verified-seal", passkey_id_hash]. Stores thevc_hash, timestamp metadata, and astatusflag (0 = PENDING,1 = VERIFIED,2 = REVOKED).
- Access Control: The user holds no Solana private keys and pays no gas. The Relayer (Authority) signs and sponsors all transactions (
initialize_seal,set_verified_seal,revoke_seal), ensuring tight control over state mutation. - Data Minimization: The chain only records uninvertible SHA-256 hashes. It is computationally infeasible to derive identity or age from the on-chain data.
Accounts
ProgramConfig
PDA [b"program_config"]. Contains:
| Field | Type | Description |
|---|---|---|
authority |
Pubkey |
The only signer authorized to issue/revoke seals. |
paused |
bool |
Kill-switch global. |
VerifiedSeal
PDA [b"seal", passkey_id_hash[..32]]. Contains:
| Field | Type | Description |
|---|---|---|
passkey_id_hash |
[u8; 32] |
sha256(credentialId) — derived from passkey. |
vc_hash |
[u8; 32] |
sha256(canonical_jcs(vc)). |
tier |
u8 |
14, 16, 18, … |
status |
u8 |
0=Initialized, 1=Verified, 2=Revoked. |
issued_at |
i64 |
Unix epoch of issuance. |
bump |
u8 |
PDA bump. |
Instructions
| Instructions | Who signs | Effect |
|---|---|---|
initialize_program(authority) |
anyone (1 time) | Create the ProgramConfig. |
initialize_seal(passkey_id_hash) |
authority | Reserve the PDA seal before KYC. |
set_verified_seal(vc_hash, tier, issued_at) |
authority | Mark the seal as Verified. |
revoke_seal() |
authority | Move the seal to Revoked. |
Discriminators
The first 8 bytes of each account follow the Anchor pattern (sha256("account:" + name)[..8]) and are manually deserialized in lib/solana/decode.ts — we don't depend on IDL Anchor at runtime, which makes the client lighter.
The off-chain architecture handles intent generation, transaction sponsorship, local storage, and cryptographic challenges.
- Relayer (Next.js API): A stateless intermediary that constructs, signs, and dispatches Solana transactions. It handles WebAuthn challenges, verifies assertions, reads PDA states, and issues the final JWT.
- KYC Console (
/kyc): The interface used by the trusted operator to validate documents, assign a compliance tier, and trigger the Relayer to anchor the data on-chain. - PWA Wallet (
/wallet): A mobile-optimized Progressive Web App. It acts as the secure execution environment. It registers the WebAuthn passkey, handles local encryption/decryption, computes age dynamically, and signs authentication challenges. - Verifier (
/verify): The consuming desktop/web client that generates a verification challenge (QR code), polls the Relayer via SWR, and receives the session-bound JWT upon successful user verification.
Relayer (lib/server/* + app/api/*)
- Stateless: Each request rebuilds the transaction from scratch.
- In-memory store for intents, sessions, and passkeys (
lib/server/store.ts), replaceable by Redis/Upstash without contract change (next step). - Network-agnostic: Switching from devnet to mainnet is done simply by changing
SOLANA_RPC_URL.
PWA Wallet (lib/pwa/*)
- AES-GCM 256 with a non-extractable
CryptoKeypersisted in IndexedDB (zl_vault.keys). - AAD = passkey_id_hash, ensuring that the vault key leak alone does not decrypt VCs.
- Age calculated locally (in device) (
lib/pwa/age.ts) — never sent to the network
Verifier Desktop (app/verify) - Digital Platforms (3rd Parties)
- Generates the
sessionIdin the relayer withrequiredAge. - Displays
https://<host>/unlock?=<sessionId>in SVG QR code (zero image depth). - It performs Polling SWR every 1 second to detect when the session is decided.
Unlock Mobile (app/unlock)
- Minimalist page, optimized for small screens.
- Wrap in
<Suspense>because ofuseSearchParams(Next 15). - Use
navigator.credentials.get()with the challenge issued by the relayer and post the assertion.
The system relies on a combination of asymmetric signatures, canonical hashing, and symmetric local encryption.
- Passkey Derivation:
passkey_id_hash= SHA256(credentialId_bytes)- This 32-byte hash acts as the deterministic seed for the Solana
VerifiedSealPDA.
- Credential Hashing (On-Chain Anchor):
- The VC is serialized using the JSON Canonicalization Scheme (RFC 8785) to ensure deterministic ordering.
vc_hash= SHA256(JCS(VC_JSON))- Any modification to the VC alters the hash, invalidating the on-chain verification.
- Local Storage Encryption (AES-GCM):
- The raw VC is never stored in plaintext. It is encrypted locally in the PWA using a non-extractable AES-GCM 256
CryptoKeystored in IndexedDB. - The 32-byte
passkey_id_hashis passed as Additional Authenticated Data (AAD) to cryptographically bind the encrypted payload to the specific passkey.
- The raw VC is never stored in plaintext. It is encrypted locally in the PWA using a non-extractable AES-GCM 256
- Session Tokens (JWT):
- Uses HMAC SHA-256 (HS256).
- Contains an ephemeral lifespan (
exp = now + 60s), a unique identifier (jti), and a strict audience bound to the Verification Session ID (aud = sessionId) to prevent replay attacks.
Cryptographic Schemes
passkey_id_hash
passkey_id_hash = SHA-256(credentialId_bytes)
32 raw bytes, used as the PDA on-chain seed.
vc_hash (canonical JCS)
The VC is serialized using JSON Canonicalization Scheme (RFC 8785) — ordered keys, numbers in canonical JSON.stringify, without spaces.
vc_hash = SHA-256(JCS(vc_json))
This ensures that any minimal change to DOB/tier/issuedAt produces a different hash, and that the calculation is reproducible in any language.
AES-GCM Vault
plaintext = utf8(JSON(vc))
nonce = randomBytes(12)
key = CryptoKey(AES-GCM, 256, non-extractable) # IndexedDB
aad = passkey_id_hash # 32 bytes
ciphertext = AES-GCM-encrypt(key, nonce, plaintext, aad)
Proof JWT
header = { alg: "HS256", typ: "JWT" }
payload = {
iss: "zero-leak-relayer",
aud: <sessionId>,
sub: <seal_pda>,
jti: <uuid>,
tier: 18,
ageOk: true,
exp: now + 60,
iat: now
}
signature = HMAC-SHA-256(SESSION_JWT_SECRET, base64url(header) + "." + base64url(payload))
- Onboarding (Intent Creation) & Key Generation: The user visits the KYC operator. They open their PWA application and click on “Register my age”. They click on “Register passkey” and then on “Continue”. They use their fingerprint to create a “Zero Leak User” access key on the device and initialize their Zero Leak wallet. The PWA generates a
WebAuthnaccess key and anAES-GCMvault key. Thispasskey_id_hashkey is sent back to the KYC operator. - Anchoring (On-Chain) & Secure Storage: The operator verifies the user's physical documents and enters the date of birth and level. The repeater constructs the
VC, calculates thevc_hash, and executes theset_verified_sealinstruction in Solana. The Relayer sends theVCin plain text to the user's PWA exactly once. The PWA encrypts it with theAES-GCMkey and stores it in theIndexedDB. - Verification Challenge: A third-party site (Verifier) requests an age check, generating a session ID with a required age tier and displaying a QR code.
- Off-Chain Proof: The user scans the Verifier's QR code with their PWA. The PWA triggers a local biometric prompt (
WebAuthn), decrypts the VC, dynamically verifies the age condition, and signs the session challenge. - Final Authorization: The Relayer validates the WebAuthn signature against the on-chain
VerifiedSealstatus and the providedvc_hash. If valid, it issues an ephemeral JWT to the Verifier, granting access.
Components
| Layer | Location | Responsibility |
|---|---|---|
| Solana Program | ID... |
PDAs program_config and verified_seal; instructions initialize_seal, set_verified_seal, revoke_seal. |
| Relayer | app/api/** (Next.js Route Handlers) |
Transaction construction/signing, WebAuthn registration, account decoding, JWT issuance. |
| PWA Wallet | app/wallet |
Passkey + IndexedDB vault with VC encrypts using AES-GCM; generates assertions. |
| KYC Console | app/kyc |
On-site operator UI; creates intents and triggers the relayer. |
| Verifier | app/verify |
Site that asks for proof: generates challenge, displays QR code, receives JWT. |
| Unlock (mobile) | app/unlock |
Receive the challenge via QR code and respond with the biometric assertion. |
All responses are JSON and follow the contract
{ ok: boolean, ...payload }or{ ok: false, error: string }.
GET /api/program
Returns the live network configuration and the state of the ProgramConfig PDA. Tolerant of missing AUTHORITY_KEYPAIR and unreachable RPC.
{
"ok": true,
"network": {
"rpcUrl": "https://api.devnet.solana.com",
"environment": "devnet",
"programId": "Gs1VdZ...",
"authorityPubkey": "9X7q...",
"authorityConfigured": true
},
"programConfig": {
"pda": "Hk2D...",
"exists": true,
"authority": "9X7q...",
"paused": false,
"reachable": true
}
}POST /api/kyc/intent
Creates a KYC intent with a passkey_id_hash declared by the client.
Body: { "passkeyIdHash": "<hex 64>" }
GET /api/kyc/intent/:id
Polling the state of an intent (pending → verified | rejected).
POST /api/kyc/verify
Operator endpoint: receives { intentId, dob, tier }, assembles the VC, calculates vc_hash, anchors set_verified_seal, returns the VC to the PWA.
POST /api/seal/init
Body: { "passkeyIdHash": "<hex 64>" } → runs initialize_seal on the chain.
GET /api/seal/:passkeyHash
Reads PDA verified_seal and returns { status, tier, vcHash, issuedAt, pda }.
WebAuthn
| Route | Verb | Function |
|---|---|---|
/api/webauthn/register/options |
POST | Generates PublicKeyCredentialCreationOptions. |
/api/webauthn/register/verify |
POST | Validates attestation, registers the passkey. |
/api/webauthn/auth/options |
POST | Generates PublicKeyCredentialRequestOptions for a session. |
/api/webauthn/auth/verify |
POST | Validates assertion, checks on-chain, issues JWT. |
Verifier Sessions
| Route | Verb | Function |
|---|---|---|
/api/session/create |
POST | { requiredAge: 18 } → { sessionId, challenge, expiresAt }. |
/api/session/:id |
GET | Polling from the desktop verifier; returns the JWT when issued. |
| Striker | What he tries | Why he fails |
|---|---|---|
| On-Chain snooper | Inferring age or identity | The chain only sees passkey_id_hash and vc_hash, both are computationally intractable pre-images. |
| Malicious verifier site | Reusing another user's JWT | JWT is HS256, valid for 60 seconds, with a unique jti and fixed aud (session_id). |
| Dishonest KYC operator | Issuing a seal without validating the document | Revocation is public and on-chain; audit detects discrepancy. |
| Compromised relayer | Forging evidence | Not allowed: the assertion is signed with the user's private passkey, which never touches the relayer. |
| Theft of user's device | Using the owner's VC | Every assertion requires userVerification: "required" (biometrics/PIN). |
| Theft of IndexedDB dump | Decrypt the VC offline | The AES key is non-extractable + AAD linked to the passkey hash. |
| MitM on the HTTPS channel | Hijacking JWT | TLS + aud=session_id + nonce per session prevents replay in another context. |
Building Zero Leak required integrating standard Web 2 infrastructure (WebAuthn, PWAs) with the decentralized state of Web 3, all while respecting the strict principles of data minimization. To achieve this goal, I developed solutions that circumvented three major technical bottlenecks:
The problem was the need to anchor a cryptographic hash of the user's Verifiable Credential (vc_hash) in the blockchain. However, standard JSON does not guarantee the order of the keys, and different environments (Node.js relay vs. mobile browser) can introduce microscopic variations in whitespace or number formatting. A standard JSON.stringify() would generate different SHA-256 hashes for the same underlying data, breaking the entire verification mechanism on the blockchain. To solve this, I implemented the JSON Canonicalization Scheme (RFC 8785). Before hashing, the VC is strictly serialized: keys are lexicographically ordered, whitespace is removed, and numbers are standardized. This ensures absolutely deterministic hashing in any language or environment. A vc_hash generated by the Next.js Relayer perfectly matches the hash derived within the PWA, ensuring fail-safe integrity when validating the VerifiedSeal in Solana.
The problem is that the standard client library @coral-xyz/anchor is incredibly powerful, but introduces a huge payload into the JavaScript package. Since the Zero Leak wallet is a mobile-focused Progressive Web App (PWA), forcing the client to load heavy IDL parsers and dependencies would severely degrade Interaction Time (TTI) and the overall user experience (which was planned to be as seamless as possible from the outset). To solve this, I completely removed the heavy Anchor client dependencies at runtime. Instead, we manually calculate the 8-byte Anchor discriminators (sha256("account:VerifiedSeal")[..8]) and interact with the Solana RPC using raw buffer deserialization (lib/solana/decode.ts). We build the raw instructions using @solana/web3.js primitives. The impact of this change was an extremely fast and lightweight front-end package. The application reads PDAs and builds the verification logic in milliseconds, maintaining the feel of a native application without sacrificing the security of the Anchor program architecture.
The problem was to achieve a "seedless" and "gas-free" user experience, so we used WebAuthn (Passkeys) for user authentication. The challenge was to securely bind the biometric data from the user's physical device to both the on-chain state of Solana and the locally encrypted data, without ever exposing a private key or personally identifiable information (PII). To solve this, I developed a three-part cryptographic binding using the WebAuthn credentialId:
- Derivation: We took the raw bytes of the Passkey ID generated by the hardware and created a 32-byte
passkey_id_hash(SHA-256). - On-chain: This 32-byte hash acts as the deterministic seed to find the user's PDA
VerifiedSealon Solana ([b"verified-seal", passkey_id_hash]). - Local storage: The same hash is injected as Additional Authenticated Data (AAD) into our AES-GCM 256 encryption algorithm.
The result of this approach is security, because if an attacker somehow extracts the vault from IndexedDB, they will not be able to decrypt the Verifiable Credential. Even if they extract the local AES key, decryption will fail without the hardware-bound access key ID. This establishes an unbreakable and leak-proof chain of trust, from the secure enclave of the user's phone to the Solana blockchain.
Complete the installation of the development stack using the official documentation:
https://solana.com/pt/docs/intro/installation
This version of the product was developed on the Ubuntu 22.04.5 LTS 64-bit operating system using the following configuration:
Rust: rustc 1.91.1 (ed61e7d7e 2025-11-07) Solana CLI: solana-cli 3.0.10 (src:96c3a851; feat:3604001754, client:Agave) Anchor CLI: anchor-cli 0.32.1 # 1.0.0+ if Ubuntu 24.04+ OS Surfpool CLI: surfpool 0.12.0 Node.js: v24.10.0 Yarn: 1.22.1
Create a standard Anchor project structure named "zero_leak".
anchor init zero_leakGo to the /zero_leak folder and replace the files in this project with the ones in the /solana-contract folder:
/solana-contract/Anchor.toml > /zero_leak/Anchor.toml/solana-contract/lib.rs > /zero_leak/programs/zero_leak/src/lib.rs/solana-contract/zero_leak.ts > /zero_leak/tests/zero_leak.ts
To view the Program ID generated in the /zero leak folder, run:
solana address -k target/deploy/zero_leak-keypair.jsonUse this Program ID to change the value of the variable zero_leak = "ZLBr1111111111111111111111111111111111111111" in [programs.localnet] in the file Anchor.toml in /zero_leak.
To automatically synchronize the Program ID in the lib.rs file (located in /zero_leak/programs/zero_leak/src/lib.rs), run:
anchor keys syncThe field declare_id!("ZLBr1111111111111111111111111111111111111111"); in lib.rs will be changed.
Open another terminal and run:
solana-test-validator --resetOR
surfpool startTo compile the program (smart contract), deploy it, and quickly run the tests in /zero_leak, execute:
anchor test --skip-local-validatorThe expected output is: 21 passing (Xs), where X is the time in seconds for the tests to be executed.
In /zero_leak/tests/zero_leak.ts
Twenty-one tests were conducted to confirm an active Root of Trust (RoT) architecture in compliance with the following legal instruments: Law No. 15,211/2025 (ECA Digital)¹, Law No. 13,709/2018 (LGPD)², Regulation (EU) 2016/679 (GDPR)³ and Online Safety Act 2023⁴ to ensure a hierarchical trust governance model.
Root of Trust Architecture
The Solana contract implements a hierarchical trust model anchored in:
-
ProgramConfig (Global Authority Layer)
- Defines the trusted Relayer (authority)
- Controls system-wide states (e.g., pause/kill switch)
-
VerifiedSeal (User Trust Layer)
- Deterministic PDA derived from
passkey_id_hash - Represents a cryptographic identity anchor
- Stores only hashed credentials (vc_hash) — never raw PII
- Deterministic PDA derived from
-
State Machine
PENDING → VERIFIED → REVOKED- Enforced through strict transition rules
Categories (21 Tests)
1. Identity & Authentication (5 tests)
Validates binding between user identity and cryptographic primitives.
Scenarios:
- Valid
passkey_id_hashinitialization - Rejection of zero/invalid hashes
- Deterministic PDA derivation
- Uniqueness of identity anchors
- Replay attack resistance
Legal Mapping:
- Law No. 15,211/2025 🇧🇷: "enhanced protection of digital identity, principle of the best interests of children and adolescents" (Art. 3); "adopt effective measures to prevent access by children and adolescents" (Art. 9), "on each access" (Art. 9, § 1); "proportional, auditable and technically secure measures to ascertain the age or age range of users" (Art. 12, item I).
- Law No. 13,709/2018 🇧🇷: "use of technical measures to protect personal data from unauthorized access" (hash validation and rejection of invalid values) (Article 6, item VII); "preventing the occurrence of damages due to the processing of personal data" (Article 6, item VIII); "guaranteeing the prevention of fraud and the security of the data subject in identification and authentication processes" (Article 11, item II, subparagraph "g").
- Regulation 2016/679 (EU) (GDPR) 🌍: "Data protection by design" (use of cryptographic hash as pseudonymized identity) (Art. 25); "accuracy" (identity correctly linked to the holder) (Art. 5 (1)(d)); "Security of Processing" (resistance to replay attacks and cryptographic integrity) (Art. 32).
- Online Safety Act 2023 🇬🇧: *"requires a provider to use age verification" (Section 12(4)) *"legal obligation to verify the identity of users" (User identity verification)" (Section 64).
2. Integrity & State Machine (5 tests)
Ensures correctness of lifecycle transitions.
Scenarios:
- Valid transition:
PENDING → VERIFIED - Re-verification with same hash (idempotency)
- Invalid transition rejection
- Counter overflow protection
- Timestamp consistency
Legal Mapping:
- Law No. 15,211/2025 🇧🇷: "perform risk management of its resources" (Article 8, item I).
- Law No. 13,709/2018 🇧🇷: "data quality" (consistency of the state) (Art. 6, item V); "adoption of effective measures capable of proving the observance and compliance with the rules for the protection of personal data" (Accountability) (Art. 6, item X).
- Regulation 2016/679 (EU) (GDPR) 🌍: "lawfulness, fairness and transparency" (valid transactions ensure the legitimacy of the state) (Art. 5 (1)(a)); "integrity and confidentiality" (protection against invalid states) (Art. 5 (1)(f)); "Accountability" (lifecycle consistency) (Art. 24); "ability to ensure confidentiality, integrity" (determines that processing ensures appropriate security of personal data) (Art. 32 (1)(b)).
- Online Safety Act 2023 🇬🇧: ""design of functionalities" and the "regulatory compliance arrangements" of services work correctly to mitigate risks effectively to users" (Safe by Design) (Sections 10(4), 12(8), 27(4), and 29(4)).
3. Authorization & Governance (4 tests)
Validates hierarchical control via Root of Trust.
Scenarios:
- Only authority can update relayer
- Unauthorized calls rejected
- Pause/unpause behavior enforced
- Kill-switch blocks all state mutations
Legal Mapping:
- Law No. 15,211/2025 🇧🇷: "Parental supervision and hierarchical control" (parents can release content and be held legally responsible) (Art. 18); "requirements in security control mechanisms that do not allow modification or manipulation of interfaces that circumvent protection" (Art. 18, § 2).
- Law No. 13,709/2018 🇧🇷: "rules of good practices and governance focused on mitigating risks" (Art. 50).
- Regulation 2016/679 (EU) (GDPR) 🌍: "Corresponds to the Accountability Principle and the requirement that controllers implement data protection by design and by default, limiting control and granting authority only to processors that provide sufficient security guarantees" (Articles 24, 25 and 28). Online Safety Act 2023 🇬🇧: "ensures the effectiveness of access restriction and control processes, or suspension of functionalities when the system presents or suffers threats" (requirements related to government policies applicable to providers)* (Sections 10, 15, and 71).
4. Privacy & Data Minimization (3 tests)
Ensures no leakage of personal data.
Scenarios:
- Only
vc_hashstored on-chain - PII never persisted
- Revocation wipes cryptographic linkage
Legal Mapping:
- Law No. 15,211/2025 🇧🇷: "establishes that the processing of personal data must be guided by good faith and transparency, requiring the use of only information strictly necessary for legitimate purposes and informed to the data subject" (Art. 12 § 1); "the verification of the age of children and adolescents may be used solely for this purpose" (Art. 13).
- Law No. 13,709/2018 🇧🇷: "Principle of Necessity" (restricts the use of data to the minimum) (Article 6, item III); "anonymization" (data loses the possibility of direct or indirect association with an individual) (Article 5, item XI and Article 12).
- Regulation 2016/679 (EU) (GDPR) 🌍: "data minimization" (data should be limited strictly to what is necessary) (Art. 5 (1)(c)); "Security of processing" (encryption to mitigate leaks) (Art. 32).
- Online Safety Act 2023 🇬🇧: "protecting users from a breach of any statutory provision or rule of law concerning privacy that is relevant to the use" (Section 22 (3)).
5. Revocation & Lifecycle Control (2 tests)
Validates post-verification governance.
Scenarios:
- Seal revocation clears
vc_hash - Re-verification after revocation allowed
Legal Mapping:
- Law No. 15,211/2025 🇧🇷: "removal of content that violates the rights of children and adolescents as soon as they are notified of the offensive nature of the publication by the victim" (Art. 29) and "suppliers of products or services must observe the right to contest the decision" (contestation/reverification for removed cases) (Art. 30).
- Law No. 13,709/2018 🇧🇷: "consent may be revoked at any time by express manifestation of the data subject" (Art. 8, § 5 and Art. 15, item III); "deletion of personal data processed with the consent of the data subject" (Art. 18, item VI).
- Regulation 2016/679 (EU) (GDPR) 🌍: "the data subject has the right to withdraw or revoke consent at any time in a simplified manner" (Art. 7 (3)); "right to erasure" (mandatory deletion of links or data when revoked) (Art. 17).
- Online Safety Act 2023 🇬🇧: "when the provider is alerted by someone about the presence of any illegal content, [...], remove that content promptly." (Sections 10 (3)(b), 38 (1)(c) and 72 (3)(a)).
6. Auditability & Traceability (2 tests)
Ensures full lifecycle observability.
Scenarios:
- Event emission correctness (
SealInitialized,SealVerified, etc.) - Timestamp consistency across lifecycle
Legal Mapping:
- Law No. 15,211/2025 🇧🇷: "to take proportionate, auditable measures" (Article 12, item I); "semi-annual reports, in Portuguese, to be published on the provider's website" (Article 31, heading).
- Law No. 13,709/2018 🇧🇷: "accountability and reporting" (Article 6, item X).
- Regulation 2016/679 (EU) (GDPR) 🌍: "Records of processing activities" (strict maintenance of records and documentation on all processing activities) (Art. 30).
- Online Safety Act 2023 🇬🇧: "Transparency Reporting" (requires the issuance of metrics and traceability) (Sections 77 and 78); "Record-keeping" (specific duties of record keeping and regular reviews) (Sections 23 and 34).
Cross-Mapping: Solana Contract Tests ↔ Legal Requirements
| Test Category | 🌍Regulation 2016/679 (EU) (GDPR) | 🇧🇷13,709/2018 | 🇬🇧Online Safety Act 2023 | 🇧🇷15,211/2025 |
|---|---|---|---|---|
| Identity & Authentication (Ex.: PDA derivation, Hash validation) |
Art. 5(1)(d), 32: Accuracy and adoption of technical security measures for cryptographic protection. | Art. 6 (V, VII), 46: Data quality and technological security against unauthorized access. | Sec. 64: Provider's duty to offer reliable identity verification options (User identity verification). | Art. 9 (§1), 12 (I): Reliable age verification and obligation to adopt technically secure measures. |
| Integrity & State Machine (Ex.: Transition verification, Overflow) |
Art. 5(1)(f), 32(1): Integrity, confidentiality, and ensuring continuous resilience of systems. | Art. 6 (VII), 46: Protection against accidental or unlawful alterations and guaranteeing state security. | Sec. 10(2), 27(2): Requirement of proportionate measures in the design to mitigate and manage system vulnerabilities. | Art. 12 (I): Technological measures in digital environments that are secure, proportionate, and immune to exploitation. |
| Authorization & Governance (Ex.: Pause/Kill-switch, Role limits) |
Art. 24, 32(4): Controller responsibility and obligation to act only under documented authority/instruction. | Art. 6 (X), 39: Accountability and treatment restricted to instructions authorized by the controller. | Sec. 71, 10, 12: Prohibition of actions outside the Terms of Service and requirement for corporate governance controls. | Art. 17 (§4), 34: Systemic restriction of access and submission to governance by administrative authorities. |
| Privacy & Data Minimization (Ex.: PII not on-chain, Only vc_hash) |
Art. 5(1)(c), 25(2): Data minimization restricted to what is necessary and Privacy by Design. | Art. 6 (III), 12: Principle of the necessity and validity of processes that make data opaque (such as irreversible hashes). | Sec. 22(3), 33(3): Implementation of security measures that prioritize and protect the privacy of personal data. | Art. 7 (§1), 12 (§1): Highest degree of privacy protection "by default" and absolute restriction of excessive sharing. |
| Revocation & Lifecycle Control (Ex.: Seal revocation, Lifecycle wipe) |
Art. 7(3), 17: Simplified withdrawal of consent at any time and Right to be Forgotten (Erasure). | Art. 8 (§5), 15 (III), 18 (VI): Simplified revocation, termination and consequent elimination of data links. | Sec. 10(3), 38, 72: Architecture that allows for swift removal processes (takedown) and fulfillment of contract termination. | Art. 29, 30: Duty of immediate removal from reach and guarantee of dispute/reverification flows after removal. |
| Auditability & Traceability (Ex.: Event emission, Timestamp sync) |
Art. 5(2), 30: Proactive accountability and full documentation of processing activities (logs). | Art. 6 (X), 37: Demonstration of effectiveness (accountability) and complete historical record of processing operations. | Sec. 23, 34, 77, 78: Obligations to maintain records and issue Transparency Reports. | Art. 12 (I), 31, 33 (§3): Technologically auditable measures, generation of semi-annual reports and tracking of sanctions. |
References
[1] BRAZIL. Law No. 15,211, of September 17, 2025. It provides for the protection of children and adolescents in digital environments (Digital Statute of Children and Adolescents). Brasilia, DF: Presidency of the Republic, 2025. Available at: https://www.planalto.gov.br/ccivil_03/_ato2023-2026/2025/lei/l15211.htm. Accessed on: May 22, 2026.
[2] BRAZIL. Law No. 13,709, of August 14, 2018. General Law for the Protection of Personal Data (LGPD). Brasilia, DF: Presidency of the Republic, 2018. Available at: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm. Accessed on: May 22, 2026.
[3] EUROPEAN UNION. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). Official Journal of the European Union, L 119, p. 1–88, 2016. Available at: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng. Accessed on: May 22, 2026.
[4] UNITED KINGDOM. Data Protection and Digital Information Act 2023. London: Parliament of the United Kingdom, 2023. Available at: https://www.legislation.gov.uk/ukpga/2023/50. Accessed on: May 22, 2026.
frontend/
├── app/
│ ├── api/
│ │ ├── program/route.ts # GET — Network info + ProgramConfig status
│ │ ├── kyc/
│ │ │ ├── intent/route.ts # POST — operator creates intent
│ │ │ ├── intent/[id]/route.ts # GET — PWA does polling
│ │ │ └── verify/route.ts # POST — The operator activates the relayer.
│ │ ├── seal/
│ │ │ ├── init/route.ts # POST — initialize_seal
│ │ │ └── [passkeyHash]/route.ts # GET — reads VerifiedSeal PDA
│ │ ├── webauthn/
│ │ │ ├── register/{options,verify}/route.ts
│ │ │ └── auth/{options,verify}/route.ts
│ │ └── session/
│ │ ├── create/route.ts # POST — verifier opens session
│ │ └── [id]/route.ts # GET — JWT polling
│ ├── kyc/ # operator console
│ ├── wallet/ # User PWA
│ ├── verify/ # desktop verifier QR screen
│ ├── unlock/ # mobile page of the challenge
│ ├── layout.tsx
│ ├── page.tsx # landing
│ └── globals.css # design
├── components/
│ ├── ui/ # shadcn/ui
│ └── zl/
│ ├── logo.tsx
│ ├── top-nav.tsx
│ ├── network-badge.tsx
│ ├── hash-chip.tsx
│ └── status-pill.tsx
├── hooks/
│ ├── use-mobile.ts
│ ├── use-toast.ts
├── lib/
│ ├── env.ts # localnet/devnet/mainnet detection
│ ├── crypto/
│ │ ├── hash.ts # sha256 helpers
│ │ └── vc.ts # canonical JCS + vc_hash
│ ├── pwa/
│ │ ├── aes.ts # AES-GCM 256
│ │ ├── idb.ts # IndexedDB layer
│ │ ├── age.ts # dynamic calculation
│ │ └── webauthn.ts # SimpleWebAuthn browser wrapper
│ ├── server/
│ │ ├── relayer.ts # build/sign/send + PDA reading
│ │ ├── passkeys.ts # WebAuthn registration (in-memory)
│ │ ├── store.ts # intents + sessions
│ │ └── jwt.ts # HS256, 60s
│ └── solana/
│ ├── connection.ts # Cached connection
│ ├── keypair.ts # JSON / base58 / base64 loaders
│ ├── pdas.ts # findProgramAddress
│ ├── instructions.ts # raw Anchor IX builders
│ ├── idl.ts # program constants
│ └── decode.ts # manual deserializers
├── public/
├── scripts/
│ ├── initialize-program.mjs # Initialize program for Devnet deployment
│ └── zero_leak.json # IDL Zero Leak
└── package.json
Built with Next.js 16, TypeScript,
@solana/web3.js,@simplewebauthn/*, Tailwind CSS v4 and shadcn/ui.
Go to the /frontend folder and run:
npm installRename the file .env.example to .env.local and fill in all the variables.
# Localnet: http://127.0.0.1:8899
# Devnet: https://devnet.helius-rpc.com/?api-key=YOUR_KEY
# Mainnet (RPC Fast): https://solana-rpc.rpcfast.com/?api_key=YOUR_KEY
SOLANA_RPC_URL=
# Execute: cat ~/.config/solana/id.json
AUTHORITY_KEYPAIR=
# Execute: node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
SESSION_JWT_SECRET=
# In /zero_leak execute: solana address -k target/deploy/zero_leak-keypair.json
NEXT_PUBLIC_PROGRAM_ID=
# Ngrok url WITH "HTTPS://" and WITHOUT the "/" at the end
NEXT_PUBLIC_WEBAUTHN_ORIGINS=
NEXT_PUBLIC_WEBAUTHN_RP_NAME=Zero Leak
# Ngrok url WITHOUT "HTTPS://" and the "/" at the end
NEXT_PUBLIC_WEBAUTHN_RP_ID=Open another terminal and run:
ngrok http 3000Visit the URL: http://127.0.0.1:4040
https://1a2b-3c4d.ngrok-free.app, open the .env.local file and paste it into: NEXT_PUBLIC_WEBAUTHN_ORIGINS= and ONLY the domain ("the address without https://") into: NEXT_PUBLIC_WEBAUTHN_RP_ID=. Also add ONLY the domain from the URL that ngrok generated ("the address without https://") to: allowedDevOrigins in the next.config.mjs file. Click on the grok URL https://1a2b-3c4d.ngrok-free.app and then click on: Visit Site.
Execute:
npm run devApp pages and routes
| Route | Who uses it | What it does |
|---|---|---|
/ |
Public | Institutional landing page with visual explanation of the flow. |
/kyc |
Operator | On-site console: creates intent, captures DOB, chooses tier, triggers emission. |
/wallet |
User (mobile) | Wallet PWA: registers passkey, receives VC, shows seal status on-chain. |
/verify |
Third-party website (desktop) | Opens a session and displays the QR code for the user to scan. |
/unlock?s=… |
User (mobile) | Receives the challenge, performs user verification, and responds to the relayer. |
Operation by Environment (localnet / devnet / mainnet)
| Environment | SOLANA_RPC_URL |
When to use |
|---|---|---|
| localnet | http://127.0.0.1:8899 |
Local developer with solana-test-validator running. |
| devnet | https://devnet.helius-rpc.com (Helius) |
Public staging (program already deployed). |
| mainnet | https://solana-rpc.rpcfast.com (RPC Fast) |
Production — Dedicated RPC is recommended. |
⚡ On Mainnet I will use RPC Fast: To provide a seamless user experience similar to Web2, this 1 second continuous polling engine must be powered by the RPC Fast infrastructure. Because the verifier must constantly query the network to detect the exact moment the on-chain seal is validated, RPC Fast's ultra-low latency and highly reliable endpoints are crucial. This ensures that the digital platform grants real-time access at the exact moment the biometric proof is processed, completely avoiding delays from RPC bottlenecks or rate limit rejections. Zero Leak is designed to handle high-throughput, real-time age verification for digital platforms at scale. To achieve a frictionless and without compromising the decentralized Root of Trust, our architecture relies heavily on RPC Fast's premium infrastructure:
- Yellowstone gRPC Streaming: In a production environment, instantly detecting when a user resolves the biometric QR code challenge is critical. By leveraging RPC Fast's Yellowstone gRPC, our Relayer can subscribe directly to
VerifiedSealPDA state changes. This eliminates the need for heavy, repetitive HTTP polling and drops verification authorization latency from seconds down to milliseconds. - High Rate Limits (500 req/s): Digital platforms often experience massive traffic spikes (e.g., a sudden influx of users logging into a game server or streaming platform). RPC Fast’s high rate limits ensure our Relayer can query on-chain verification statuses and process passkey assertions concurrently without hitting API bottlenecks that would otherwise lock users out.
- Reliable Relayer Execution & CU Allowances: Zero Leak utilizes a gasless, sponsored-transaction model where the Next.js Relayer acts as the sole payer and signer. RPC Fast's reliable endpoints, dedicated bandwidth, and increased Compute Unit (CU) allowances ensure that critical state mutations—like
set_verified_sealand immediate compliancerevoke_sealactions—land consistently on-chain, even during severe network congestion.
The detectSolanaEnvironment function in lib/env.ts infers the environment from the RPC hostname, and the NetworkBadge indicates it visually.
- green → healthy network
- amber → Keypair not configured or RPC unreachable.
- gray → relay with error
Case Study
John Doe is 14 years old and is registering his cell phone for age verification on the servers of a communication platform like Discord. He went with his parents to an authorized Zero Leak authentication station at the Shopping Center in his city.
- Access the URL that ngrok generated on your mobile phone and click on
Visit Site. Then, click onRegister my age. - Click on
Register passkeyand then onContinue. Use your fingerprint to create an access key (Zero Leak User) on the device and initialize your Zero Leak wallet. - Share the generated code with the human agent at the Zero Leak station (visit the
/kycpage). The operator will enter your date of birth and send it to the Verifiable Credential (VC) in the PWA. Your phone will keep verifying until the registration badge appears in a few seconds.
Note: For technical demonstration purposes, I have shared all the logs that occur behind the scenes of the operation, such as: Local Age Engine (+14, +16 and +18), On-Chain Seal (SEAL_PDA, VC_HASH, PASSKEY_ID_HASH, STATUS, VERIFIED_AT and COUNTER) and Local-Only Credential (schema, issuer, dateOfBirth, minimumAgeTier, issuedAt and nonce). The technical evaluator will have the necessary clarity of the proposal by analyzing this information with the lib.rs contract and auditing the blockchain logs.
Access Blocked
Visit /verify to test the usability flow of the lockout in the user experience. By default, Required age tier is selected as 18, so just click the Issue challenge button to generate an authenticator QR Code. Scan the QR Code and visit the generated URL to solve the verification challenge by clicking the "Authorize with passkey" button. After using your fingerprint, you will be denied access (because we are impersonating John Doe, who is only 14 years old!).
Access Granted
Visit /verify to test the successful usability flow in the user experience. By default, Required age tier is selected as 18, so select +14 and click the Issue challenge button to generate an authenticator QR code. Scan the QR code and visit the generated URL to complete the verification challenge by clicking the "Authorize with passkey" button. After using your fingerprint, you will have access to the digital platform.
Now, 14-year-old John Doe has access to his favorite communication platform's servers every time he logs in. Without exposing his personal data or his parents' personal data. Quickly, practically, and securely.
Team Location: Brazil 🇧🇷
Team Size: Solo Participant
Role: Solo Founder, Legal Engineer & Full-Stack Developer
Hello, I'm Frederico Stefano Rocha 👋 I worked as a Full-Stack programmer for over a decade (2014 to 2025). I am currently founding an early-stage startup focused on innovation in the areas of Law and Government (LegalTech/GovTech), with the mission of developing useful, easy-to-use solutions based on Artificial Intelligence and Blockchain.
While I am participating in this hackathon alone, I maintain a strong network of professional partners. My profile uniquely positions me to build Zero Leak, as my background sits exactly at the intersection of complex software architecture and strict legal compliance:
Legal & Compliance Expertise
- Bachelor's Degree in Law — Centro Universitário UNA.
- Postgraduate (Lato Sensu) in Digital Law and Data Protection — EBRADI (Brazilian School of Law).
Technical & Business Expertise
- 11+ Years of Industry Experience — Full-Stack Development (self-employed).
- Specialization in Mastering Web3 (Blockchain, Crypto, NFTs & Metaverse) — University of Nicosia.
- MBA in Web 3.0 — Descomplica Faculdade Digital.
- Postgraduate (Lato Sensu) in Data Science and Big Data — PUC-MG (Pontifical Catholic University of Minas Gerais).
- Specialization in Artificial Intelligence in Healthcare — Stanford University School of Medicine.
- MBA in Business Intelligence — Descomplica Faculdade Digital.
- Postgraduate (Lato Sensu) in AI Applied to Growth Marketing — Descomplica Faculdade Digital.
- Technological Graduation in IT Management — UNI-BH (Centro Universitário de Belo Horizonte).
The main challenge of Zero Leak is to map complex legislation, such as Law nº 15,2011/2025 and Law nº 13,709/2018 of Brazil, and also Regulation (EU) 2016/679 (GDPR) of the European Union and the Online Security Law of 2023 of the United Kingdom, directly into the immutable logic of smart contracts. My extensive practical experience in Full-Stack programming, combined with my postgraduate degree in Digital Law and Data Protection, allowed me to safely architect a truly Privacy by Design Web3 infrastructure, without depending on legal interpretations from third parties at the Colesseum Frontier Hackathon, but to maintain constant progress in the development cycle after the validation phase with users in a controlled environment, it is essential to listen to strategic partners and work with a multidisciplinary team of trained professionals.
Zero Leak is on Devnet. (2026-05-06)
Zero Leak on MainNet with RPC FAST is coming... (in Sandbox)
Program Account
Gc4gctNHzd8PRA1dpfsc6DyxX3Tg8GefXYs8PNcq7Wa2
Initialize Program
2Ui5Q1fVxi9q6biSkFJRpUnBtZmwahoUbUy4rKDKchY9jBpmZqpkLvW6LamjLd1N2CjbUn94RtcXpjEFxYW7Z8QV
Seal PDA
4UKqFn5agAvWrtRC8rwe2iwQST2xkgtqo29BjhfFhUXr
- Durable persistence (Redis/Upstash) for intents, sessions, and passkeys.
- JavaScript SDK for verification websites to integrate with 2 lines of code.
- Support for multiple authorities (multi-tenant KYC).
- Platform attestations (Apple/Android Key Attestation) for passkey hardening.
- Internationalization (AR / PT-BR / DE / FR / ES).
Complete to-do list: To-Do Zero Leak on Colosseum Frontier Hackathon
"The United Arab Emirates has made significant progress in regulating child digital safety with the entry into force of Federal Decree-Law No. 26/2025 on Child Digital Safety in January 2026. This law mandates age verification/assurance mechanisms for digital platforms, social networks, streaming services, online games, and providers operating in or serving users in the UAE. In contrast, the Brazilian context following Law No. 15,211/2025 reduced the accountability of streaming platforms, a result of strong lobbying influence from the sector, creating a more permissive and less demanding regulatory environment regarding age protection and access control for minors. In this scenario, the UAE positions itself as a potentially strategic market for solutions like Zero Leak. The regulatory trend in the UAE indicates an increased demand for digital identity technologies, content security, and compliance for international platforms operating in the region. When I was in Dubai, I realized that technology was not only used for consumption or entertainment, but also as social infrastructure. In practice, the city functions as a continuous layer of digital services connected through apps like DubaiNow and UAE PASS. This explains why issues such as digital reputation, identity verification, online security, and the quality of social interactions have such significant cultural and economic weight in the UAE."
© 2026 Zero Leak. Source-Available Software.