In today's Web3 projects, everyone claims to be using 'ZK', but when you really ask:

"How do you call your proof?"

Most likely the answer is: We run the prover on our own server.

Why? Because calling proofs is too difficult:

  • There is no unified interface

  • There is no abstract layer standard

  • Each proving system has to be adapted individually

  • Want to dynamically pass parameters and combine tasks? Forget it

ZK was supposed to be a universal module for Web3, but it has turned into something like a research project.

The Proof Request model launched by Boundless may be the first protocol layer structure to standardize, interface, and compose proof requests.@Boundless #Boundlessnertwork $ZKC

It is not a proof engine; it is the "API layer of ZK".

📬 What is Proof Request? It is a task definition template and a structured request standard.

You can understand Proof Request as a "task container on the chain."

It includes:

  • Proof Spec: the proof system to be called (Halo2, Plonky2, etc.).

  • Input Spec: task input parameter structure (supports multiple types).

  • Constraint Config: circuit operation constraints (duration, memory, output format).

  • Callback Rule: result return path (on-chain events / data interfaces).

  • Reward Type: incentive method (instant rewards + Vault).

This is like an API request package:

You write the parameter structure, pass it to the Boundless network, and the network automatically completes scheduling, execution, and feedback.

And this request of yours does not require you to deploy a prover yourself, does not need to manage task scheduling, fault tolerance, or concurrency, and only needs to focus on:

"What do I want to prove?"

🧱 Why this is hugely significant for Modular / AI / DePIN projects.

Now the Modular project is on the rise:

  • Separation of the Execution layer.

  • Separation of the DA layer.

  • Pluggable Sequencer layer.

  • Composable smart contracts are becoming increasingly important.

But the ZK part is extremely fragmented:

  • Every project is writing its own circuits.

  • Every Rollup must deploy its own verifier.

  • No "unified proof channel".

The Proof Request mechanism of Boundless allows:

  • zkLogin → Define user login proof request template, unify calling prover.

  • zkML → Model parameters + input images packaged into a task request with one click.

  • zkVoting → Define voting snapshot circuit, DAO can directly call.

  • zkIntent → After path search, send execution intent as a task.

All of this can be run through a "ZK request layer" ---

ZK as a service, like API as a service.

🛠️ What capabilities does the Proof Request support? Not only templates but also modular combination capabilities.

The design of Boundless goes far beyond "standardizing structures."

It also supports:

  • Task nesting: a Proof Request can call another request as a dependency (realizing multi-circuit linkage).

  • Parameter mapping: supports calling external chain data as parameter injection in tasks.

  • Task routing: route by task type to a specific proving system (compatible with more future proving tech).

  • Permission control: the project party can set a specific request whitelist to avoid malicious resource abuse.

  • Version management: each task template update will generate a version hash to ensure traceability.

They have almost done everything you can think of regarding the "ZK API structure".

🧠 Who needs this the most? Not users, but developers.

ZK is not a user experience technology; it is essentially a developer tool.

Who is suffering the most? It is these people:

  • Game developers want to add privacy verification between user actions.

  • Wallet developers want to do zkLogin but don't understand circuits.

  • AI verification protocols want to add trusted guarantees to model operations.

  • Multi-chain account systems want to generate zk sessions but lack prover resources.

They don’t not want to use ZK; rather:

"Affording" ZK is too difficult.

Proof Request is designed for these people:

  • Can't write proof systems? No problem, you just need to write request templates.

  • No prover? The system automatically helps you allocate, execute, and return.

  • Want multi-task concurrency? Use nested task writing.

  • Want to write results to the contract? Just add Callback rule and event synchronization.

You no longer need to understand Halo2; you only need to understand business logic.

🎬 Summary: The ZK project should not start from the prover; it should start from the Proof Request.

Boundless abstracts tasks into structures, breaks proofs into requests, and hands execution over to the network.

It is not "part of the ZK project"; it is "the tool platform for all ZK projects."

This is not just efficiency optimization, but:

  • Lower the access threshold.

  • Standardize proof input and output.

  • Decouple ZK from business logic.

  • Use ZKC as execution credentials.

Whether you can run the prover yourself is not important; what matters is:

Can you write a request like calling GPT and then get a trusted result?

If one day all ZK projects no longer run proofs themselves but instead send unified Proof Request interface requests, then Boundless will become the "infrastructure backend" of the ZK world.