vlayer docs
REST API

POST /compress-web-proof

Under Development: This API is currently in development. Documentation and endpoints may change. For production use, please contact our team.

POST /api/v0/compress-web-proof

Generate a ZK proof from a Web Proof. The process:

  • Verifies the Web Proof:
    • Verifies the HTTP transcript - Confirms the integrity of the recorded HTTP request/response data
    • Verifies the Notary's signature - Validates the cryptographic signature from the trusted notary service
    • Confirms data origin - Ensures the data comes from the expected domain specified in the original request
    • SSL certificate validation - Verifies the server's SSL certificate and its complete chain of authority
    • Extracts plain text transcript - Retrieves the verified HTTP request/response data for further processing
  • Parses HTTP transcript - Extracts and decodes the HTTP request/response data
  • Applies extraction queries - Extracts specified fields from the response body using JMESPath for JSON parsing
  • Generates ZK proof - Creates a zero-knowledge proof attesting to the Web Proof verification and extracted data
  • Computes extraction hash - Creates a cryptographic hash of the queries used for on-chain validation

Request Body

  • presentation: Web Proof object (direct output from Web Prover Server /prove)
    • data: Hex-encoded proof data
    • version: TLSN protocol version
    • meta: Metadata about the verification
      • notaryUrl: URL of the notary service used
  • extraction: Object specifying fields to extract from HTTP transcript (optional)
    • response.body: Extract fields from the HTTP response body
      • jmespath: Array of JMESPath expressions for JSON parsing

Current Support: Only response.body with jmespath is currently supported. Support for other sources (response.headers, request.url) and formats (exact, regex, xpath) is planned for future releases.

Response Body

Success Response

  • success: Boolean indicating if the operation succeeded (always true for success responses)
  • data: Object containing the compressed proof data
    • zkProof: Serialized ZK proof data (seal) - used to verify the proof on-chain
    • journalDataAbi: ABI-encoded public outputs containing verified Web Proof data - used as the claim being proven

Looking for decode info (types, values, Solidity snippet)? Use POST /api/v0/debug/journal-decode-helper with the same request body.

Error Response

  • success: Boolean indicating failure (always false for error responses)
  • error: Object containing error details
    • code: Error code string (e.g., "INVALID_REQUEST", "PROOF_GENERATION_FAILED")
    • message: Human-readable error message

Understanding journalDataAbi

The journalDataAbi is an ABI-encoded tuple containing all the public outputs from the ZK proof. This is the data that was proven and will be decoded in your Solidity smart contract.

Quick Start: Call /debug/journal-decode-helper with the same request to get a solidityCodeSnippet! It provides ready-to-use Solidity code that you can copy directly into your contract for decoding the journal data.

Encoding Format

The journalDataAbi is encoded as tuple parameters in the following order:

(
  bytes32 notaryKeyFingerprint,  // Fingerprint of the notary's public key
  string method,                 // HTTP method (e.g., "GET", "POST")
  string url,                    // The URL that was proven
  uint256 tlsTimestamp,          // Unix timestamp (in seconds) from the TLS session
  bytes32 extractionHash,        // Hash of the extraction queries
  ...extractedValues             // Your extracted values (dynamic types)
)

Important: The order and types in your abi.decode must exactly match the order of your extraction queries and their detected types. If you extract ["price", "symbol"], you must decode them in that same order.

Example

Extract Price and Symbol from JSON Response

curl -X POST https://zk-prover.vlayer.xyz/api/v0/compress-web-proof \
  -H "Content-Type: application/json" \
  -H "x-client-id: 4f028e97-b7c7-4a81-ade2-6b1a2917380c" \
  -H "Authorization: Bearer jUWXi1pVUoTHgc7MOgh5X0zMR12MHtAhtjVgMc2DM3B3Uc8WEGQAEix83VwZ" \
  -d '{
    "presentation": {
      "data": "014000000000000000ee32d73a6a70e406a31ffa683416b7376...",
      "version": "0.1.0-alpha.12",
      "meta": {
        "notaryUrl": "https://test-notary.vlayer.xyz/v0.1.0-alpha.12"
      }
    },
    "extraction": {
      "response.body": {
        "jmespath": ["price", "symbol"]
      }
    }
  }'

The included credentials are for limited public use. For production use, please contact our team.

Response:

{
  "success": true,
  "data": {
    "zkProof": "0xffffffffa1b2c3d4e5f6...",
    "journalDataAbi": "0xa7e62d7f17aa7a22c26bdb93b7ce9400e826ffb2c6f54e54d2ded015677499af..."
  }
}

The journalDataAbi contains the ABI-encoded tuple with all public outputs.

To obtain decoding helpers (types, values, and ready-to-use Solidity snippet), call POST /debug/journal-decode-helper with the same request body.

When decoded in Solidity using the provided snippet, the journalDataAbi will provide:

  • notaryKeyFingerprint: Fingerprint of the notary's public key
  • method: HTTP method ("GET")
  • url: The URL that was proven ("https://data-api.binance.vision/api/v3/ticker/price?symbol=ETHUSDC")
  • tlsTimestamp: Unix timestamp from the TLS session (1234567890)
  • extractionHash: Hash of the extraction queries
  • extractedValue0: Price value ("3500.50")
  • extractedValue1: Symbol value ("ETHUSDC")

extractedValue0 and extractedValue1 are dynamic fields - they appear when using the extraction field in the request, and are automatically named with consecutive numbers starting from 0.

Future: Multiple Sources and Formats

Coming Soon: Future releases will support extracting from multiple sources (headers, URLs) and using different formats (exact match, regex, XPath):

{
  "extraction": {
    "response.body": {
      "jmespath": ["price", "symbol"]
    },
    "response.headers": {
      "exact": ["Content-Type", "X-RateLimit-Remaining"]
    },
    "request.url": {
      "regex": ["symbol=([A-Z]+)"]
    }
  }
}

Extraction Hash Calculation

The extractionHash (included in journalDataAbi) is a cryptographic hash of all extraction queries, used by smart contracts to validate that the ZK proof was generated with the expected field extractions. This prevents query substitution attacks where an attacker might try to extract different fields than intended.

Order Matters: The order of your extraction queries directly affects the hash calculation. Changing the order of queries (e.g., ["price", "symbol"] vs ["symbol", "price"]) will produce a completely different hash, causing on-chain validation to fail.

How It's Calculated

The hash is computed using keccak256 (Ethereum's hashing algorithm) over the concatenated source, format, and query strings for each extraction, in the order they appear:

import { encodePacked, keccak256 } from 'viem';

const sources = ["response.body", "response.body"];
const formats = ["jmespath", "jmespath"];
const queries = ["price", "symbol"];  // Order matters!

const packed = encodePacked(
  ["string", "string", "string", "string", "string", "string"],
  [sources[0], formats[0], queries[0], sources[1], formats[1], queries[1]]
);

const extractionHash = keccak256(packed);
// This hash must match the expectedExtractionHash in your smart contract