POP System Design

In the Proof of Prompt protocol, system interactions involve four participants: the User, the Prover, the Proxy, and the Large Language Model (LLM) Service Provider.

Protocol Background and Comparison

The core concept of Proof of Prompt is similar to zkTLS [1], which integrates zero-knowledge proofs into the TLS communication process to ensure data integrity and authenticity. In our system, the user initiates a request to the LLM via the Prover. The Prover forwards the request to the LLM service provider through a third-party Proxy.

The LLM processes the request and returns a response via the Proxy to the Prover, who then delivers it to the user. The entire TLS communication occurs only between the Prover, Proxy, and LLM provider. Since the user does not directly participate in this process, there may be concerns about the Prover tampering with the response. To eliminate this trust issue, Proof of Prompt requires the Prover to generate a zero-knowledge proof that the response it returns is exactly what the LLM produced and has not been altered. This ensures a high level of tamper-proof security.

The implementation of this protocol can significantly enhance the trustworthiness and security of AI agents, unlocking high-value use cases such as on-chain asset management, hedging, financial agents, and payment systems—all of which require highly trustworthy AI.

Design Advantages

Compared to existing ZKML frameworks like ezkl [2], Proof of Prompt significantly reduces system overhead. For example, generating a proof for a simple GPT-2 model with ezkl may take several hours, making it impractical for large-scale models provided by services like OpenAI or DeepSeek.

We propose a more pragmatic trust model: instead of having the user verify the internal execution of the LLM, the system assumes the trustworthiness of major LLM providers and focuses on ensuring that the Prover does not tamper with the output.

This design reflects real-world needs. Major LLM providers have a strong reputation incentive, their services are widely used, and they have been extensively validated. In contrast, the Prover node is typically invisible to the user and is more likely to be the point of tampering—making it the critical component to constrain.

Trust and Security Model

We assume that the Proxy and Prover are not colluding. To reinforce this assumption, we recommend decentralizing the Proxy in real-world deployments to avoid single points of failure or trust.

For simplicity, we initially assume that the user's prompt and the final response will be uploaded on-chain in plaintext (privacy protection methods will be discussed in later sections).

Technical Challenges and Fundamental Solution

The primary technical challenge lies in the fact that the Prover can forge ciphertext. Even if the user observes a piece of ciphertext, they cannot determine whether it was genuinely obtained through a TLS session with the LLM provider or arbitrarily generated and encrypted locally by the Prover.

To address this issue, we introduce a Proxy signature mechanism: when the Proxy receives the encrypted response from the LLM, it signs the ciphertext and uploads both the ciphertext and its signature on-chain. Subsequently, the Prover provides a zero-knowledge proof to demonstrate the following claim:

The plaintext obtained by decrypting the ciphertext is exactly the response generated by the LLM.

The core of this proof lies in verifying the correctness of the symmetric decryption process, which can be efficiently implemented using existing work such as Dubhe [3].

Verification Process

Since the LLM’s response typically includes the user’s prompt, a validator (e.g., a miner) only needs to verify the following to confirm the response is legitimate:

• Validate the Proxy’s signature on the ciphertext.

• Check that the decrypted plaintext includes the user's original prompt.

• Verify the zero-knowledge proof provided by the Prover.

Once these steps are completed, the validator can confirm that the Prover has honestly returned the genuine response from the LLM.

Privacy-Preserving Design

If the user wishes to keep the prompt and response content private, we propose the following solution:

After sending the prompt and receiving the response, the user uploads their hash values to the blockchain instead of the plaintext. Let:

• H1 = Hash(prompt)

• H2 = Hash(response)

Assume that the response’s substring [i:j] corresponds exactly to the prompt.

• The ciphertext of the response is uploaded on-chain by the Proxy.

• The Prover uses the plaintext response w as a witness to generate a zero-knowledge proof for the following statements:

  • Hash(w) = H2

  • Hash(w[i:j]) = H1

  • Decrypt(ciphertext) = w

As long as the validator (e.g., miner) can validate the Proxy’s signature on the ciphertext and verify the Prover’s zero-knowledge proof, they can be confident that the response truly originated from the LLM and was not tampered with—without revealing any plaintext content.