Main Track Proposal: Noir WebProof SDK

[KyoungWan]

Main Track Proposal: Noir WebProof SDK

Summary

This project aims to build the WebProof SDK, a developer toolkit that enables Noir developers to verify Web2-based data using Zero-Knowledge proofs, specifically through zkTLS.

The project will deliver:

• A zkTLS verification flow implemented entirely in Noir
• Predicate-enabled JSON field extractor and manifest generator
• A WASM-based SDK available in both JavaScript and Python environments

By abstracting the complexity of zkTLS proof generation and verification, the WebProof SDK will help developers easily and securely build zkTLS-based applications within the Noir ecosystem.
All components will be open-sourced and designed to serve as foundational infrastructure for future real-world applications of zkTLS.

---

Motivation

zkTLS is a powerful primitive that allows developers to cryptographically prove that a piece of data originated from a trusted Web2 source. It is essential infrastructure for privacy-preserving protocols like zkKYC, zkLogin, zkEmail, and zkP2P.

However, there is currently no practical zkTLS application or tooling available within the Noir ecosystem.

• Existing projects like Pluto, Reclaim, and Primus are implemented in Circom, making them incompatible with Noir and its toolchain.
• There exist basic Chacha20, JSON circuit written in noir. However, it is not in Incrementally Verifiable Computation format. To use the Supernova folding scheme, circuits in IVC format are needed.

Furthermore, current zkTLS implementations have structural limitations:

1. Lack of predicate support in JSON parsers
   Most existing circuits can only extract data from hardcoded paths (e.g., response.items[5].balance).
   In real-world use cases such as proving the balance of a specific token from a list of assets, flexible condition-based extraction like balance > 10000 && token == "ETH" is required.

2. Difficulty in constructing a manifest
   Developers must manually inspect and configure each API response to define what fields to prove.
   This leads to slow development and frequent errors.
   Below is an example manifest used to generate a zkTLS proof for Binance Pay transactions.
   Making this manifest from scratch is very tricky.

{
  "proving": {
    "manifestVersion": "1",
    "id": "binance-pay-transactions",
    "title": "Binance Pay Transactions",
    "description": "Generate a proof that you have a certain amount of transactions",
    "prepareUrl": "https://api.binance.com/sapi/v1/pay/transactions",
    "request": {
      "method": "GET",
      "version": "HTTP/1.1",
      "url": "https://api.binance.com/sapi/v1/pay/transactions",
      "headers": {}
    },
    "response": {
      "status": "200",
      "version": "HTTP/1.1",
      "message": "",
      "headers": {},
      "body": {
        "json": [
          "data",
          0,
          "uid"
        ],
        "contains": "this_string_exists_in_body"
      }
    }
  }
}

---

Methodology

There is no need to reinvent the wheel. Pluto already provides open-source boilerplate infrastructure for zkTLS, including a proxy server that captures TLS traffic and formats it into a usable format.

We will reuse Pluto's TLS handling and proxy components as-is, and focus our work on implementing the core proof logic and circuits with Noir. Additional components like predicate support, manifest tooling, and SDK packaging will be designed specifically for the Noir ecosystem.

Based on this, our development will include:

1. Implementing Noir circuits (we've already implemented most of it.)
   The circuits for ChaCha20, HTTP parsing, and JSON parsing have already been written in Noir. (https://github.com/elysia-dev/noir-web-prover-circuits)
   We will use the first week to improve test coverage and add predicate-handling capabilities.

2. Predicate-based JSON field extractor
   We will implement a predicate DSL to extract fields like balance where conditions such as balance > 10000 or token == "ETH" are satisfied.
   These predicates will be compiled into circuit constraints within Noir.

3. Manifest generator (Chrome extension)
   Users will be able to inspect Web API responses visually and select fields of interest.
   A manifest json corresponding the structure and fields selected will be generated automatically.

4. zkTLS proof generation SDK (Rust to WASM)
   The Rust-based proof generator will be compiled to WASM file.
   This SDK will support both browser and Node.js environments, and optionally include Python bindings.
   Example (TypeScript): generateProofFromTLS(url, predicate)

5. SuperNova-based recursive proof structure
   The proof system will be compatible with SuperNova, enabling recursive proof composition for larger or multi-step verification flows.

---

Business Model

The WebProof SDK and zkTLS circuits developed in this project will be fully open-source and free to use. We do not intend to monetize the tooling itself. This decision is intentional, as our primary goal is to accelerate zkTLS adoption in the Noir ecosystem and enable a new generation of trustless Web2-to-Web3 authentication flows.

However, we have a clear commercial roadmap that builds upon this tooling. Specifically, our team plans to launch real-world applications in the Korean market, where financial infrastructure and regulation require tailored solutions not easily accessible to global players.

We are currently developing two distinct products:

1. Fiat onramp
   Inspired by existing models like zkP2P and Reclaim, this service allows users to prove fiat transfers (e.g. via Toss, KakaoBank, or Shinhan) and receive crypto in a peer-to-peer fashion.
   Unlike Venmo-based zkP2P systems, which are not viable in Korea due to strict financial regulation and limited API access, our solution integrates with Korean financial APIs and consumer-facing services.

2. Stablecoin bridge with proof-based onramps
   In parallel, we are exploring a Korea-native stablecoin bridge product.
   While technically similar to the zkP2P onramp flow, this system uses a liquidity vault as the fiat receiver (rather than a peer) and routes the stable asset (e.g. USDK or KRW-backed tokens) to the user post-proof.

   We already prototyped this logic during the recent Noir Hackathon, demonstrating a proof-based Fiat→crypto bridge built on zkTLS and Noir. (https://www.youtube.com/watch?v=Tf8v8zD6Bb4)
   Currently, the Korean market is showing strong interest in stablecoin initiatives, and we anticipate that trusted, proof-based onramps will be a necessary component of any domestic or global stablecoin rollout in this region.

Monetization strategy

• Our approach follows a model similar to zkP2P
• Primary revenue comes from the spread between the fiat price sent and the crypto price received.
• We may introduce a protocol fee on each transaction, either as a fixed amount or a percentage of the transfer.
• In summary, we ensure the SDK remains free and open-source, while enabling sustainable monetization at the application and protocol level.

---

Timeline and Deliverables (12-week plan)

Weeks	Milestone	Details
1–2	Implementing Noir circuits	Implement chacha20, http_parser, and json_parser Noir circuits. Improve testing and integration harnesses.
3–4	Integrate basic predicate logic	Design minimal predicate syntax and implement condition handling within Noir-based JSON extraction circuits.
5–6	Extend predicate DSL	Expand predicate language (e.g. logical operators, nested paths) and test circuit generation under edge cases.
7–9	Design manifest format spec	Design a reusable manifest schema for zkTLS proof construction. Establish validation and serialization standards.
10–12	Build Chrome extension PoC	Implement manifest selection UI via browser API inspection. Allow users to generate manifest JSON from live traffic.
13–14	Integrate manifest into prover input	Connect manifest selection output with predicate-aware circuits. Validate full flow from HTTP -> manifest -> ACIR inputs.
15–17	Develop WASM-based SDK (JS & Python)	Compile Rust prover to WASM. Wrap in TypeScript and Python packages. Provide clear usage APIs.
18–19	SDK testing in multiple environments	Validate SDK across browser, Node.js, and Python.
20–21	SuperNova integration	Integrate noir circuits in SuperNova backend.
22–23	Audit and integration testing	Conduct integration tests for full proof flow, including predicate path, manifest tooling, SDK use, and recursive proof.
24	Documentation and open-source release	Publish SDK docs, sample apps, and developer guides. Release all modules as OSS on GitHub/npm/PyPI.

---

Team

ModoriLabs has developed semaphore.nr and integrated noir circuits in Pluto’s Web prover based on Supernova folding scheme. qpzm and teddav are also zk auditors in Electisec.

• @qpzm [email protected]
• @KyoungWan [email protected]
• @teddav ZK engineer. His recent work focuses on Noir-based real-world applications, including zk-tenant, a privacy-preserving identity verification system for apartment rentals, and co-match, a ZK dating app that matches users without exposing their sensitive profile data.
• @0xKarl98 [email protected]

---

Start Date

June 1, 2025

[Savio-Sou]

Hi @KyoungWan, thank you for submitting the very well-written proposal! A few thoughts if it helps:

1. Seems like the project would benefit app developers first, but not necessarily all Noir developers; if there are things that help show how the project could benefit Noir developers more broadly, I'd highly recommend including them in the proposal
2. Great if the proposal could elaborate on why SuperNova (instead of e.g. Barretenberg)

Appreciate the time and effort on drafting the piece.

[KyoungWan]

@Savio-Sou
Thank you for the thoughtful feedback.

Feedback 1
I definitely see the point that this proposal leans more toward supporting zkApp developers rather than core Noir circuit authors.

But I still believe there’s value in this project from a Noir ecosystem perspective. Even if it’s not a 100% fit with the scope of this call, it demonstrates a full end-to-end zkTLS application built entirely with Noir circuits, and we plan to open-source all of it — including the verifier circuits, manifest extraction logic, and example integrations.

I hope this can serve as a useful reference for developers who are interested in building real-world ZK apps with Noir.

Feedback 2.
The main reason is that we’re building on top of the open-source implementation by Pluto.
Pluto uses SuperNova as the proving system, and we’re continuing with that choice because it’s well-suited for TLS-style proofs, especially when dealing with long HTTP responses as input.
SuperNova’s folding scheme allows us to recursively compress many transcript segments into a single succinct proof

About Barretenberg, we expect that Barretenberg may offer an advantage in terms of enabling verification in on-chain smart contract.
Pluto currently verifies the proof off-chain only on a server, and then signs a message that the on-chain verifier checks using ecrecover.
The smart contract only verify this message was signed from whitelisted server, not verifying TLS proof.

From this perspective, we think your suggestion about Barrentenberg is very helpful and practical.
Therefore, we are currently exploring whether using Barretenberg would allow us to implement on-chain verification — or alternatively, whether the existing Pluto logic with the SuperNova backend could itself be adapted for on-chain verification.
But at this stage, we’ve decided to continue with Pluto’s original architecture for the initial implementation.