zkTLSPrivacyCryptography

zkTLS: The Cryptographic Bridge Between Web2 and Web3

Dec 1, 2025
8 min read

Understanding Zero-Knowledge Transport Layer Security and how it enables privacy-preserving proofs of government data.

Zero-Knowledge Transport Layer Security (zkTLS) represents a paradigm shift in how we prove data authenticity without exposing the underlying information. By leveraging the security properties of TLS—the protocol that secures all HTTPS connections—zkTLS enables users to generate cryptographic proofs that data originated from a specific server, without revealing the data itself.

The Fundamental Problem

Traditional DeFi protocols face an insurmountable challenge: they cannot natively access off-chain data. A user claiming '$500k annual revenue' could be truthful or fraudulent—the smart contract has no way to verify. This information asymmetry forces protocols to treat all users as maximum risk, necessitating 150-200% overcollateralization. zkTLS solves this by creating cryptographic attestations of real-world data that maintain privacy while proving authenticity.

How zkTLS Works

Every HTTPS session involves a TLS handshake where the client and server exchange certificates and establish session keys. The server's certificate is signed by a trusted Certificate Authority (CA), cryptographically binding the server's identity to its domain. zkTLS exploits the fact that the client possesses these session keys and can prove, in zero-knowledge, that: (1) The ciphertext decrypts correctly under valid session keys, (2) These keys were derived from a handshake with the CA-certified server, (3) The plaintext satisfies a specific predicate (e.g., 'contains revenue > $100k').

Reclaim Protocol Architecture

In Zolvency, we implement zkTLS using the Reclaim Protocol, which employs a three-party model: the User (prover), the Data Provider (e.g., nfse.gov.br), and Attestor Nodes (decentralized verifiers). When a user logs into the government portal, their browser establishes a TLS session. Reclaim's SDK captures the session transcript and generates a STARK-based zero-knowledge proof that specific data was served by the government server. The proof includes the CA certificate chain, encrypted traffic, and a commitment to the extracted fields—but crucially, never reveals the raw HTML or cookie values.

import { Reclaim } from '@reclaimprotocol/reclaim-sdk'

async function proveNfseIncome(sessionCookie: string) {
  const reclaim = new Reclaim.ProofRequest(APP_ID)
  
  // Configure the TLS session to prove
  reclaim.addContext(
    'https://www.nfse.gov.br/EmissorNacional/Notas/Emitidas',
    {
      method: 'GET',
      headers: { Cookie: sessionCookie },
      responseType: 'html'
    }
  )
  
  // Define what to prove (without revealing values)
  reclaim.addPredicate({
    field: '.nota-fiscal .valor-total',
    operation: 'sum',
    threshold: 100000 // R$ 100k
  })
  
  // Generate STARK proof (~30-60 seconds)
  const proof = await reclaim.generateProof()
  
  return {
    proof: proof.zkProof,
    publicInputs: proof.commitment, // Hash of extracted data
    signature: proof.attestorSignature
  }
}

Security Guarantees

zkTLS provides three critical security properties. **Soundness**: No polynomial-time adversary can generate an accepted proof for forged data, as this would require either breaking TLS encryption (computationally infeasible) or compromising the CA (out of scope). **Zero-Knowledge**: The proof reveals nothing about the plaintext beyond the specified predicate. An observer learns only that 'revenue > threshold' is true, not the actual revenue value, client names, or transaction dates. **Authenticity**: The proof cryptographically binds to the server's CA-signed certificate, preventing man-in-the-middle attacks and ensuring data provenance.

Comparison with Alternatives

Traditional oracle solutions (Chainlink, Band Protocol) require the data provider to expose an API or cooperate with the oracle network, creating centralization vectors and privacy concerns. API-key-based integrations are easily forgeable and don't provide cryptographic authenticity. zkTLS, by contrast, operates entirely client-side using standard browser capabilities, requires zero server cooperation, and produces proofs verifiable by anyone with the CA certificate bundle.

Real-World Performance

Generating a zkTLS proof currently takes 30-60 seconds in a modern browser (WebAssembly + Web Workers). Proof sizes range from 100-500 KB for STARK proofs, which we compress to ~1 KB for on-chain verification using a Groth16 wrapper. Gas costs for verification are approximately 200k-300k gas (~$0.10-$0.15 at current prices). These metrics are acceptable for credit verification workflows, which are infrequent (quarterly re-verification) and high-value (unlocking thousands in borrowing capacity).

Conclusion

zkTLS represents the missing cryptographic primitive for Web3's integration with legacy systems. By enabling privacy-preserving, authenticated data extraction from any HTTPS endpoint, it unlocks use cases from credit scoring to medical records to educational credentials—all without requiring centralized intermediaries or exposing sensitive information. At Zolvency, zkTLS is the foundation that makes under-collateralized DeFi lending possible while maintaining both security and privacy.

Want to Build with Zolvency?

Integrate privacy-preserving credit verification into your DeFi protocol.