Orange Protocol

  • Name: Orange Protocol
  • URL: https://docs.orangeprotocol.io/
  • Category: reputation-minting protocol / identity-and-attestation middleware / proof-of-personhood and score orchestration / browser-proof sub-protocol
  • Summary: Orange Protocol is reputation middleware with a browser-proof sidecar. The useful split is between data providers, model providers, dispatcher logic, and minted outputs. Orange Pass adds a separate web-proof path on top. That keeps data access, scoring, proof issuance, and downstream gating from getting flattened into one vague identity product.
  • What it does:
    • Lets applications invoke models against selected datasets tied to a DID or wallet address, then fetch raw results or export them as verifiable credentials or NFTs
    • Defines a modular architecture with Data Providers, Model Providers, a Dispatcher, and a reputation-minting service
    • Claims to support mixed inputs including onchain activity, app data, social profile data, reviews, KYC information, and other offchain signals
    • Positions itself as middleware for builders who want programmable reputation outputs and as a self-sovereign portal for users who want to manage linked data and claims
    • Ships Orange Pass, a browser extension that proves facts from third-party web services and returns signed attestations to apps or onchain storage
    • Offers Orange Humanity Score (OHS), a downstream score surface that combines onchain identity and linked Web2 accounts and can reuse outside proof-of-personhood providers such as BrightID and Human Passport
  • Key claims:
    • The architecture docs make the real mechanism explicit: Orange separates who exposes data from who defines scoring logic and from who packages the result into portable credentials.
    • The Data Provider / Model Provider split is the reason the note matters. Orange is less a single score and more a pipeline where different actors decide what data is available and how it gets turned into a reputation output.
    • The configurable-reporting docs show that export matters as much as compute. Verifiable credentials and NFTs are the delivery format that lets scores and reports travel across apps.
    • The self-sovereignty docs say requests carry user-signature data and emphasize selective disclosure, which suggests Orange wants user consent at request time even if the downstream attestation path still depends on operator-controlled components.
    • Orange Pass adds a distinct trust surface. Its proof flow depends on schema definitions, a browser extension, and a notary/backend that signs attestations, so schema authorship and signer trust matter at least as much as the privacy story.
    • OHS shows Orange is not just neutral middleware. It also runs its own first-party score surface for campaign access and proof-of-humanity-style gating.
  • Whitepaper: No canonical standalone Orange Protocol whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official documentation pages for the core architecture, self-sovereignty model, Orange Pass proving flow, MPC mode, configurable reporting, and Orange Humanity Score. See ../whitepapers/orange-protocol-primary-sources-2026-05-10.md.
  • Sources:

Internal linkages

  • Best comparison points: human-passport, openrank, and talent-protocol.
  • Use Orange when the question is who controls data admission, model choice, and output portability rather than who merely issues a static score.

Control surface

  • Power sits in schema and dataset admission, model registration, dispatcher routing, Orange Pass notary/signer trust, and the export formats Orange chooses to make portable.

  • Read it as a reputation-and-proof pipeline with a first-party gating business attached, not as a neutral identity primitive.

  • Last reviewed: 2026-06-04 UTC