Summary: SIP Protocol is best understood not as another bridge, mixer, or wallet, but as privacy middleware that wraps intent-based settlement. Its primary materials frame it as an application-layer privacy stack that sits between apps and chains: the SDK constructs shielded intents, the privacy layer hides recipients and amounts with stealth addresses and Pedersen commitments, the proof layer handles funding / validity / fulfillment proofs, and adapter layers route into settlement systems like NEAR Intents plus chain-specific components such as Zcash and wallet integrations. The most analytically useful detail in this pass is that SIP’s own roadmap openly distinguishes the aspirational story from the current implementation: the project says today’s M17 architecture still leaves sender and claim flows meaningfully linkable, and that full privacy requires a later Pool-PDA-plus-ZK-claim design. That makes SIP a useful comparison point for stealth-address standards, intent routers, privacy pools, and compliant-disclosure systems because it exposes where privacy actually lives: SDK defaults, proof systems, claim architecture, viewing-key policy, and settlement backend choice.
What it does:
Provides an SDK and intent-building layer that lets apps request transparent, shielded, or compliant transactions with a single privacy setting
Uses stealth addresses to hide recipients and Pedersen commitments to hide amounts while keeping transaction validity machine-verifiable
Adds viewing keys and scoped disclosure paths so transaction details can be selectively revealed for auditors or compliance workflows
Routes shielded intents through external settlement infrastructure rather than replacing it, with NEAR Intents currently serving as a main routing / solver layer in the project’s public materials
Maintains a proof layer for funding, validity, and fulfillment proofs, with Noir/Barretenberg selected as the main proving stack and Zcash remaining a distinct settlement/privacy dependency
Expands toward same-chain Solana and Ethereum privacy flows while also documenting that current claim architecture remains partly linkable and incomplete from a full-privacy perspective
Key claims:
The organization profile and docs homepage repeatedly describe SIP as “the privacy standard for Web3” and, more concretely, as a privacy layer between applications and blockchains rather than as a new base chain or standalone settlement network.
The main repository README gives the clearest architectural framing: SIP adds a privacy layer to cross-chain intents via NEAR Intents and Zcash, with stealth addresses, Pedersen commitments, zero-knowledge proofs, and viewing keys as the main primitives.
The architecture document makes the control plane unusually legible. It splits the system into SDK, privacy, proof, and adapter layers, then shows separate dependencies on wallets, NEAR Intents, Zcash RPC, and proof providers. That decomposition is more analytically useful than filing SIP as a generic privacy app.
The most important caveat is in the public roadmap, which says the shipped M17 design delivers only partial privacy because the sender remains visible and the claim path is linkable. SIP’s own proposed fix is a later pool-style escrow plus ZK claim-proof architecture. This admission is exactly why the project is worth cataloging: it exposes where “private intents” can still leak.
The roadmap’s privacy-architecture section explicitly contrasts SIP’s preferred “cryptographic privacy” route against pool mixers, arguing that stealth addresses, hidden amounts, and viewing keys create a different regulatory and operational posture from stranger-mixing systems. Whether or not that claim fully holds, it is a core self-description that shapes how SIP wants to compete.
The architecture doc’s viewing-key hierarchy is analytically important because it turns compliance from a vague promise into a concrete control surface: auditors, internal teams, regulators, time scopes, and purpose scopes can all become separate disclosure domains.
The proving-system ADR shows a second hidden control surface: SIP chose Noir/Barretenberg over Halo2 mainly for browser-friendly proof generation and developer velocity. That matters because the privacy promise depends not just on cryptography in the abstract, but on which proving stack is practical enough to ship client-side.
The SDK README reveals that SIP also wants to intermediate backend choice. It exposes provider abstractions and even multiple privacy backends, which means application developers may inherit routing and privacy-policy decisions from SIP’s middleware layer rather than from the underlying chain alone.
The strongest comparison frame is therefore not “privacy wallet” or “cross-chain bridge,” but “shielded-intent middleware whose real authority sits in SDK defaults, proof backend choice, claim design, settlement adapters, and viewing-key disclosure policy.”
Whitepaper: No canonical standalone SIP whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official docs site, the organization/profile README, the core repository README, the architecture document, the roadmap, and the SDK README; see ../whitepapers/sip-protocol-primary-sources-2026-05-11.md.