This is Part 2 of a two-part series. Read Part 1: How Zero-Knowledge Proofs Fix Compliance’s Identity Problem for the three compliance primitives (zkKYC, zkProof of Solvency, zkAudit) and the identity-privacy paradox.

What zkTLS Actually Costs to Run: Processing Power and the Scaling Question

Part 1 established the primitives of Zero Knowledge. Zero-knowledge proofs let a user prove they passed KYC, or that an exchange holds sufficient reserves, or that every transaction in a reporting period complied with every rule. All without exposing the underlying data. Three compliance use cases are in production today.

But the model has a structural dependency. Someone needs to issue the initial credential. A KYC provider must verify the identity and sign the attestation. An exchange must commit its balance sheet. A regulator must define what counts as a compliance rule.

This is the bootstrap problem that zkTLS solves. Zero-knowledge Transport Layer Security lets any standard HTTPS website serve as the source of truth. If you can log into your bank, your payroll provider, or your credit monitoring service, zkTLS can generate a cryptographic proof that a specific fact from that session is true, without the server ever knowing a proof was generated.

The question for the institutional reader is not whether the cryptography works. It is what the cryptography costs to run at scale. How much processing power does it take to generate a single proof? How expensive is it to create a new circuit for a new data source? And can this infrastructure scale across thousands of financial institutions, each with different web portals, different data formats, and different TLS configurations?

Here is what the production data shows.

What is a ZK circuit? A circuit is a mathematical program that encodes exactly what you are proving. It is not general-purpose like a CPU. It is single-purpose: one circuit proves “this user’s FICO score exceeds 700 from Equifax’s web portal.” If you want to prove the same thing from TransUnion’s portal instead, you need a different circuit. If Equifax redesigns their login page, you need to update the circuit. If the compliance rule changes from “score above 700” to “score above 680,” you need a new circuit. This is why circuit creation, not proving speed, is the scaling bottleneck. Every circuit must be designed, tested, audited by a firm like Nethermind, and redeployed whenever the upstream data source or compliance rule changes. The cost per circuit audit runs well into six figures. The number of circuits you need equals the number of data sources you connect to multiplied by the number of compliance rules you enforce.

---

The Three Approaches, With Numbers

Figure 4: zkTLS attestation flow. The user initiates a standard TLS session with the bank. A notary witnesses the encrypted traffic via MPC: neither party holds the full session key. The user generates a ZK proof from selected data points. The smart contract verifies the proof on-chain. The bank is never aware a proof was created.

There are three ways to build zkTLS: multi-party computation, proxy-based routing, and trusted execution environments. They differ in how much processing they require, how detectable they are by the target server, and what they cost to scale.

MPC: Strongest Security, Highest Overhead

MPC-based zkTLS splits the TLS session key between the user and a notary using multi-party computation. Neither party holds the full key. The server sees a standard TLS connection and cannot detect the notary. The security guarantee is strong. The processing cost is material.

The academic benchmark is DECO, created at Cornell IC3 and published at ACM CCS 2020. The original implementation required 475 megabytes of communication overhead to extract a 2 kilobyte payload. That is a 237,500x overhead ratio. Total runtime was 50 seconds per proof. DECO was never successfully implemented in production, and the paper’s authors have acknowledged the performance constraints.

Subsequent protocols have improved on this significantly. Primus Labs achieved a 14x reduction in communication overhead and a 15.5x improvement in runtime compared to DECO’s baseline. TLSNotary, rebuilt from scratch in Rust by the Ethereum Foundation’s PSE team in 2022, uses garbled circuits and oblivious transfers to reduce computational cost. Opacity Network layers EigenLayer economic security on top of MPC, adding slashing conditions for colluding notaries.

The state of MPC as of May 2026: proof generation takes 30 to 60 seconds for TLSNotary, depending on the complexity of the predicate and the size of the TLS session being proven. DECO’s optimized handshake takes 2.85 seconds for the handshake, 2.52 seconds for query execution under split keys, and 3 to 13 seconds for ZK proof generation, depending on predicate complexity. Total: roughly 8 to 18 seconds per proof. Primus Labs’ improvements bring that closer to 3 to 5 seconds.

The constraint is not cryptographic security. It is that MPC approaches generate high networking and computation overhead, making them best suited for small payloads where latency is not a strict constraint. They are not practical for high-frequency compliance checks or streaming data. They are practical for the use case that matters most for institutional compliance: a user generating a single proof once per session, proving a specific fact, and submitting it to a smart contract.

Proxy: Fastest, But Detectable

Proxy-based zkTLS routes TLS traffic through a trusted proxy node that witnesses and attests to data provenance. The proxy handles the encryption. The user generates ZK proofs client-side. The approach trades cryptographic decentralization for speed.

Reclaim Protocol pioneered the proxy model. Proof generation takes 2 to 4 seconds from a mobile device with no app or extension required. Reclaim has the largest production footprint in zkTLS: more than 1 million verifications, 25 clients, 30 blockchains, and 889 community-built data sources as of May 2026. Its academic paper, “Proxying is Enough,” demonstrates a probability of breaking security at 10 to the power of negative 40.

zkPass uses a hybrid model: proxy witness in production, MPC as backup. It supports more than 200 schemas from 70 data sources, runs on Base, BNB, Scroll, Linea, Arbitrum, and Optimism, and is likely the first zkTLS project with a liquid token.

The operational constraint: proxy-based approaches are detectable by the target server. The proxy node has a known IP address and behavioral signature. If a major bank’s security team decides to block zkTLS proxy traffic, the proof generation fails for all users of that bank. Reclaim mitigates this with residential proxies and rotating IPs, but the detectability is structural, not incidental. MPC approaches do not have this limitation.

TEE: Negligible Overhead, Hardware Trust

Trusted execution environments like Intel SGX run computations in a tamper-proof hardware enclave isolated from the host operating system. The approach adds almost no overhead. The TLS session runs normally inside the enclave, and the attestation is signed by the hardware. Clique is the leading TEE-based zkTLS project.

The constraint: trust shifts from cryptographic assumptions to hardware assumptions. Intel SGX has been broken via side-channel attacks multiple times. The security guarantee is only as strong as the chip manufacturer’s ability to prevent physical attacks against their silicon. For institutional deployments where cryptographic security is table stakes, TEE-based approaches introduce a trust assumption that may not be acceptable.

---

The Real Scaling Problem

For an institutional compliance workflow, the per-proof processing cost is not the bottleneck. A user generating one proof per session, taking 2 to 60 seconds depending on the protocol, is acceptable for KYC, credit checks, and income verification. These are not high-frequency operations.

The bottleneck is circuit creation. Every zkTLS proof is specific to a particular web endpoint, a particular data format, and a particular predicate. If the bank redesigns its account summary page, the proof generation logic breaks. If the payroll provider changes its HTML structure, the data extraction template fails. If you want to verify income from ADP, credit scores from Equifax, and employment status from Workday, you need three separate schemas: each requiring a new circuit, each requiring its own audit, each maintained against upstream changes.

This is the same circuit design constraint established in Part 1: you need to know what you are proving before you can build the proof system. For zkTLS, the constraint is sharper because the data sources are not under your control. Web2 services change their interfaces. Banks deprecate old portal versions. Payroll systems restructure their JSON output. Every upstream change requires a downstream circuit change.

The scaling math is straightforward. If an institutional deployment needs to verify income across 200 payroll systems, as TransCrypts does using zkPass, that is 200 schemas to build and maintain. If a lending protocol wants to verify bank balances across the top 50 U.S. banks, that is 50 schemas. If a credit scoring protocol wants to verify FICO scores from three credit bureaus with different web interfaces, that is three schemas. Each schema needs to be designed, tested, audited, and redeployed whenever the upstream system changes.

Reclaim Protocol’s approach to this is pre-configured data sources: 889 community-built providers as of May 2026. This is the right model for scaling, but it is still bounded by community contribution. Every new data source requires someone to build the provider. Every provider breakage requires someone to fix it. The approach scales with community effort, not with cryptographic throughput.

---

What This Enables, Despite the Constraints

The processing and scaling constraints are real, but they do not disqualify zkTLS for the use cases that matter most for institutional compliance. Here is what is running in production today.

Undercollateralized DeFi lending. 3Jane, a credit-based money market on Base backed by Paradigm, lets borrowers connect their wallet to their Web2 financial data using Reclaim Protocol’s zkTLS. The 3CA algorithm underwrites against on-chain transactions, off-chain credit scores from Equifax and TransUnion, and Plaid-connected bank accounts. It generates unsecured USDC credit lines of up to $141,000 per user. The bank never knows a credit check was performed. The smart contract never sees the bank balance. The cost: one proof per credit check, generated in 2 to 4 seconds.

Employment and income verification. TransCrypts uses zkPass to establish TLS sessions with more than 200 payroll and HRIS systems. An employee generates a verifiable proof of employment and income that a mortgage lender or background check company verifies instantly. No document upload. No manual review. No PII transferred. The verification is FCRA-compliant. The cost: one proof per verification request.

Credit scoring. zkMe’s zkCreditScore lets a DeFi protocol assess credit risk based on verified FICO scores. A user proves their FICO score exceeds 700 via a zkTLS connection to their credit monitoring service. The protocol receives a boolean. The actual score never leaves the user’s device. The cost: one proof per credit check.

The common thread: these are low-frequency, high-value attestations. A user generates a proof once per session, not once per transaction. The 2 to 60 seconds of proof generation time is absorbed into the user experience of connecting a bank account or verifying employment. The circuit creation cost is absorbed into the protocol’s integration budget, same as any API integration.

---

The Three-Layer Compliance Stack

Figure 5: The three-layer compliance stack. Identity data stays with the issuer. The proof is generated on the user’s device. Only the proof touches the chain. The smart contract returns a boolean. The regulator sees a verifiable audit trail without ever accessing the underlying PII.

Part 1 described three compliance primitives: zkKYC, zkProof of Solvency, and zkAudit. Part 2 introduced a fourth: zkTLS, which solves the credential bootstrap problem by making any HTTPS website a source of truth. These four primitives compose into a three-layer architecture that eliminates data exposure at each stage.

Layer 1: Identity Issuance. A regulated entity performs KYC and AML checks. For zkKYC, the issuer signs a Verifiable Credential stored in the user’s wallet. For zkTLS, the “issuer” is any Web2 service the user already has a relationship with: a bank account, a payroll provider, a credit bureau. The processing cost at this layer is zero: the Web2 service operates exactly as it does today, unaware that proofs are being generated.

Layer 2: Proof Generation. The user’s device generates a zero-knowledge proof from either the Verifiable Credential (zkKYC) or the TLS session data (zkTLS). The proof is compact, under 1 kilobyte. The processing cost is 2 to 60 seconds per proof depending on the protocol and complexity. The proof is generated locally. No PII is transmitted.

Layer 3: On-Chain Verification. A smart contract verifies the proof and gates the action. The verification cost is less than the gas cost of an ERC-20 transfer. The smart contract returns a boolean. The regulator sees a verifiable audit trail.

The key architectural property: the data never moves. The issuer does not see where the credential is used. The verifier does not see the underlying data. The proof is the only thing that touches the chain.

---

What This Changes

For the past five years, the RWA tokenization market has been building infrastructure to solve compliance through permissioning. Permissioned chains. Whitelists that expose identity. Issuer-level controls that create single points of trust. The processing cost of these approaches is zero. The compliance check happens off-chain. The result is a simple boolean in a database.

zkTLS changes the economics. It adds processing cost (2 to 60 seconds per proof, plus the circuit creation and maintenance burden) in exchange for eliminating data exposure. The question for the institutional reader is whether that tradeoff is worth it.

For high-value, low-frequency attestations (KYC, credit checks, income verification, employment status), the answer is yes. The 2 to 60 seconds of processing time is a rounding error compared to the manual alternative: uploading a pay stub, waiting for a background check, or sending a copy of a passport to a third party. The circuit creation cost is comparable to building and maintaining any API integration. The data liability elimination is the margin.

For high-frequency, low-value attestations (every transaction, every transfer, every swap), the answer is no, not yet. MPC approaches with 30 to 60 second proof times are not viable for per-transaction compliance checks. Proxy approaches at 2 to 4 seconds are closer but still an order of magnitude too slow. The proving speed is improving rapidly. Primus Labs’ 15.5x improvement over DECO’s baseline in two years is indicative of the trajectory. But we are not there.

The architecture is here. The processing cost is known. The scaling constraint is circuit creation, not proof generation. The question that remains is regulatory precedent, and that has not been set. But the cryptographic bridge between the compliance infrastructure institutions already operate and the DeFi protocols they are building is in production, with real protocols, real metrics, and a scaling roadmap that is improving every year.

---

References

• TLSNotary Protocol
• TLSNotary: arXiv Paper (Sep 2024)
• DECO: Academic Paper (ACM CCS 2020)
• DECO: Stanford Blockchain Review Deep Dive (Aug 2025)
• Reclaim Protocol
• Reclaim: “Proxying is Enough” Paper
• zkPass
• Opacity Network
• Primus Labs: zkTLS Implementation
• Gate Learn / Delphi Digital: zkTLS Explained
• 3Jane: Unsecured DeFi Credit (whitepaper)
• 3Jane: Messari Coverage
• TransCrypts: Income Verification
• zkMe: zkCreditScore
• Chainlink: Zero-Knowledge Proof KYC