Summary: Orange Pass is best understood not as just a wallet-adjacent Chrome extension or a generic zkTLS badge, but as a schema-driven browser-proof sub-protocol inside Orange’s broader reputation stack. Its core mechanism is a split workflow: a schema specifies which Web2 page and API response matter, the extension opens the relevant site and captures the needed request flow, a notary/verifier infrastructure helps validate or proxy the TLS exchange, and the resulting attestation is signed and returned to apps or onchain storage. That makes Orange Pass a useful comparison point between lower-layer web-proof primitives like TLSNotary and productized reputation systems like Human Passport or Orange Humanity Score. The main analytical questions are who defines schemas, who operates the notary, when Proxy mode is considered acceptable versus MPC mode, which third-party account facts become standardized enough to verify repeatedly, and how much downstream trust shifts from raw proof generation into the signed attestation format and the applications that accept it.
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:
Orange Pass is valuable as a separate corpus entry because it isolates the browser-proof and attestation-issuance layer that would be analytically flattened if kept only under Orange Protocol’s broader reputation branding.
The developer docs make the real control surface concrete: proof generation depends less on abstract zkTLS rhetoric and more on schema authorship. Whoever defines the relevant pageUrl, apiUrl, regex or JSON-path matching logic, and redaction fields decides which offchain fact is even legible.
The mode split matters. Proxy mode is the default for performance, which suggests the common operational path is not the strongest cryptographic one. MPC mode is available when needed, but the docs make clear that transport-mode choice is an explicit trust/performance tradeoff rather than a hidden implementation detail.
The MPC-mode docs also surface the hidden issuer role. A notary collaborates in TLS setup, records transcript commitments, constructs an attestation body, and signs it. In practice, many downstream consumers will trust the notary signature and schema semantics more directly than they will inspect lower-layer transcript-proof details.
The attestation format is built to be reusable across applications. recipient binds a proof to a wallet, while user_hash ties it to an account identifier in the source application, which helps explain how Orange tries to prevent repeated reuse of the same Web2 account under multiple recipients.
The current schema examples are revealing because they skew toward exchange-account ownership, KYC, and balance thresholds. That makes Orange Pass less like a universal web-proof rail and more like a strategically curated proof surface for sybil resistance, gating, and reputation boosting.
Orange Pass is especially useful in the corpus because it sits between lower-layer web-proof primitives and higher-layer score systems. Without keeping this layer explicit, it is too easy to flatten TLSNotary, Primus, Orange Protocol, Human Passport, and exchange-account proof products into one generic identity or zkTLS bucket.
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.