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 dataversion: TLSN protocol versionmeta: Metadata about the verificationnotaryUrl: URL of the notary service used
extraction: Object specifying fields to extract from HTTP transcript (optional)response.body: Extract fields from the HTTP response bodyjmespath: 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 (alwaystruefor success responses)data: Object containing the compressed proof datazkProof: Serialized ZK proof data (seal) - used to verify the proof on-chainjournalDataAbi: 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 (alwaysfalsefor error responses)error: Object containing error detailscode: 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 keymethod: 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 queriesextractedValue0: 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