Orange Pass

• Name: Orange Pass
• URL: https://docs.orangeprotocol.io/orangepass/introduction
• Category: zkTLS browser-proof middleware / notary-backed web-data attestation sub-protocol / reputation-input primitive
• Summary: Orange Pass is browser-proof middleware inside Orange’s broader reputation stack. The useful surface is narrower than the branding suggests: schema-defined web proofs, notary or proxy operation, signed attestations, and downstream score or gating products that decide those attestations count.
• What it does:
  • Ships as a Chrome extension that lets users prove facts about their accounts or activity on third-party Web2 sites without revealing the full underlying data
  • Uses schema IDs that define the verification target, including the required pageUrl, apiUrl, response-matching rules, and fields that may be selectively disclosed
  • Defaults to a Proxy mode in which the user’s browser communicates through a verifier-controlled proxy for speed, while retaining an MPC mode for cases where proxy access is unsuitable
  • Returns signed attestations containing fields such as recipient, verifier_address, verifier_signature, data_hash, schema_id, task_id, and user_hash
  • Supports practical proof types centered on exchange and account facts, such as account ownership, KYC status, and threshold balance checks for Binance, OKX, Bybit, Gate, and KuCoin
  • Feeds first-party score products such as Orange Humanity Score, where the attestations become reusable reputation inputs rather than one-off verification events
• Key claims:
  • Keep this note separate because it isolates the proof-issuance layer that would disappear if everything were folded into Orange’s broader reputation branding.
  • The real control surface is schema authorship. Whoever defines the pageUrl, apiUrl, matching logic, and redaction fields decides which offchain fact is even legible.
  • Proxy mode is the default fast path. MPC mode exists, but the docs treat it as a tradeoff, not the ordinary path.
  • The notary or verifier role matters more than the zkTLS label. Downstream users will usually trust the signed attestation and schema semantics, not inspect transcript machinery.
  • Current schemas skew toward exchange-account ownership, KYC, and balance thresholds, so this reads more like a curated proof surface for gating and reputation than a universal web-proof rail.
• Whitepaper: No standalone Orange Pass whitepaper surfaced in this pass. The strongest primary materials were the official Orange Pass introduction, developer guides, MPC-mode documentation, and Orange Humanity Score usage notes collected in ../whitepapers/orange-pass-primary-sources-2026-05-13.md.
• Sources:
  • https://docs.orangeprotocol.io/orangepass/introduction
  • https://docs.orangeprotocol.io/developer-guides
  • https://docs.orangeprotocol.io/orangepass/introduction/mpc-mode
  • https://docs.orangeprotocol.io/orangepass/how-to-use
  • https://www.orangeprotocol.io/
  • https://github.com/orange-protocol

Internal linkages

• Keep the comparison set short: tlsnotary, reclaim-protocol, and human-passport.
• That keeps the note on browser-proof middleware and downstream gating, instead of spraying across every identity stack with a badge product.

Control surface

• The leverage sits in schema authorship, verifier or proxy operation, mode defaults, signed-attestation format, and which downstream Orange score products or partners decide those attestations count.

• So read Orange Pass as a narrow browser-proof issuance layer inside a reputation stack, not as a general-purpose web-proof anchor.

• Last reviewed: 2026-06-13 UTC