Skip to main content

ZK-TLS Flow

This section details the step-by-step flow of data from the Web2 provider to the blockchain verification.

Sequence Diagram​

sequenceDiagram
    participant U as User
    participant B as Binance (Provider)
    participant E as Extension (Deeproof)
    participant D as Dashboard
    participant C as Smart Contract

    U->>B: 1. Login & Visit Dashboard
    Note right of U: User must have KYC Level ≥ 2
    
    B-->>E: 2. API Response (User ID, KYC Level)
    E->>E: 3. Intercept & Validate Data
    Note right of E: Checks if KYC Level is sufficient
    
    U->>E: 4. Click "Verify Identity"
    
    E->>E: 5. Generate ZK Proof (Client-Side)
    Note right of E: Input: UserID, Trapdoor<br/>Output: Proof, Commitment
    
    E-->>D: 6. Send Proof Data
    D->>U: 7. Request Transaction Signature
    U->>C: 8. Submit Proof On-Chain
    
    C-->>C: 9. Verify Proof (Groth16)
    C-->>D: 10. Emit Verification Event
    D-->>U: 11. Update Status to "Verified"

Detailed Steps​

1. Data Capture (Client-Side)​

  • Action: User logs into Binance.
  • Mechanism: The Chrome extensions injects a script that hooks into XMLHttpRequest and fetch.
  • Target: Specifically watches for the get-user-base-info endpoint.
  • Data Captured: userId (internal ID) and kycLevel (verification status).

2. Proof Generation (Local)​

  • Inputs: The captured userId and a locally generated random secret (trapdoor).
  • Computation: The snarkjs library runs inside the extension to generate a Groth16 proof.
  • Output: A Zero-Knowledge proof attesting that the user controls a valid Binance account with kycLevel >= 2, without revealing the userId.

3. On-Chain Verification​

  • Submission: The user sends the proof to the Deeproof smart contract via their wallet.
  • Verification: The contract checks the proof against the verification key.
  • Result: If valid, the user's wallet address is mapped to a verified status on-chain.