vlayer

• Name: vlayer
• URL: https://www.vlayer.xyz/
• Category: verifiable data infrastructure / zk-and-MPC verification middleware / web-proof and onchain-proof platform
• Summary: vlayer is proof middleware for developers who want web, email, and onchain facts to land inside application logic or EVM contracts. The useful layer is not generic verifiable data rhetoric. It is the developer surface around prover execution, verifier contracts, and proof compression. Strong rail, still middleware.
• What it does:
  • Generates cryptographic web proofs from HTTPS requests and responses using TLSNotary-based proving infrastructure
  • Offers three main developer surfaces: server-side proving for token-authenticated APIs, client-side proving for cookie/session-authenticated resources, and ZK proving for blockchain use cases
  • Compresses web proofs into succinct zero-knowledge proofs using RISC Zero so verified data can be stored or checked onchain more efficiently
  • Exposes a Solidity-oriented Prover/Verifier architecture in which private inputs are handled offchain and public outputs plus proof verification land on EVM-compatible chains
  • Supports use cases such as account and asset verification, wallet recovery, identity and compliance checks, reputation proofs, social/account ownership proofs, historical-balance checks, and cross-chain proof-based logic
• Key claims:
  • The official docs say vlayer is powered by TLSNotary plus Zero Knowledge Proofs and Multi-Party Computation to verify private data without exposing sensitive information
  • The docs explicitly position server-side and client-side proving as general web-proof infrastructure for any application environment, while ZK proving is the blockchain-specific compression layer for onchain verification
  • The vlayer book says Prover contracts execute on vlayer zkEVM infrastructure while Verifier contracts validate proofs and execute on EVM-compatible chains, which is the clearest architectural clue for categorization
  • The Prover docs say inputs are private by default, proofs are not persisted by vlayer, and developers are responsible for tracking proof usage in their Verifier contracts
  • The public GitHub organization description also links a Veridise audit report, suggesting the team is exposing audit artifacts alongside product docs rather than relying on marketing copy alone
• Whitepaper: No canonical standalone vlayer whitepaper or litepaper was surfaced in this pass. The strongest primary sources were the official site, docs.vlayer.xyz, the vlayer book, and the public GitHub organization; see ../whitepapers/vlayer-primary-sources-2026-04-27.md.
• Sources:
  • https://www.vlayer.xyz/
  • https://docs.vlayer.xyz/
  • https://docs.vlayer.xyz/server-side/introduction
  • https://docs.vlayer.xyz/client-side/introduction
  • https://docs.vlayer.xyz/blockchain/introduction
  • https://book.vlayer.xyz/
  • https://book.vlayer.xyz/getting-started/how-it-works.html
  • https://book.vlayer.xyz/advanced/prover.html
  • https://book.vlayer.xyz/advanced/verifier.html
  • https://github.com/vlayer-xyz

Internal linkages

• Best anchors: tlsnotary, reclaim-protocol, and zkemail.
• Read vlayer as the application-facing proving layer, not the lower-layer provenance primitive underneath it.

Control surface

• The leverage sits in prover execution, verifier-contract design, supported proof routes, compression choices, and which data sources become first-class in the developer stack.

• What matters is how much application logic gets built around vlayer-specific proving and verification flows.

• Last reviewed: 2026-06-14 UTC