Cowrie Research

sismo

4 min read

Sismo

  • Name: Sismo
  • URL: https://docs.sismo.io/
  • Category: privacy-preserving identity-and-attestation middleware / zero-knowledge SSO / data-group proof infrastructure / badge protocol
  • Tags: ethereum-ecosystem
  • Summary: Sismo is private account-binding and eligibility-proof middleware. The useful split is between the local Data Vault, the trusted Commitment Mapper, Data Group root publication, and the attester-controlled badge layer. Keep it as a note on group-proof plumbing, not as a catch-all zk identity bucket.
  • What it does:
    • Lets users aggregate wallets and supported web2 accounts inside a private local Data Vault and generate zero-knowledge proofs from that vault
    • Offers Sismo Connect as a crypto-native SSO layer for apps to request proofs of account ownership, group membership, or app-specific anonymous identifiers (vaultId)
    • Defines Data Groups as sets of supported accounts with associated values, then uses Merkle roots as the onchain source of truth for later proof verification
    • Runs Sismo Hub and Factory flows for creating group generators, data providers, groups, badge metadata, and app integrations
    • Uses a Commitment Mapper service to convert proof of account ownership into a SNARK-friendly commitment receipt that can later be verified in proving schemes
    • Stores attestations in an onchain registry where authorized issuers can record or delete attestations, while a stateless ERC-1155 badge view exposes them as non-transferable badge balances
  • Key claims:
    • The strongest reusable primitive in Sismo is not “identity” in the abstract; it is the split between account aggregation, proof generation, group construction, and attestation issuance. The docs make clear that those layers are handled by different components with different trust assumptions.
    • The Data Vault docs show that Sismo wants users to aggregate wallets and supported web2 accounts locally, then prove claims about those accounts without publicly linking them. That is analytically distinct from issuer-centric attestation systems that begin from public credentials rather than private account aggregation.
    • The vaultId mechanism is especially useful for comparison work. It gives each app an anonymous app-specific identifier derived from the vault secret and app ID, which means Sismo can offer uniqueness and anti-double-claim guarantees without defaulting to a globally public identity object.
    • The Commitment Mapper is one of the most important control surfaces. Sismo’s own docs explicitly call it a trusted offchain service that verifies ownership proofs, enforces one commitment per account, and issues signed receipts. That means Sismo’s privacy story still depends on an intermediary trust anchor even though the downstream proofs are zero-knowledge.
    • The Data Group docs and Sismo Hub README reveal another major control surface: who creates group generators, what data providers are used, how group values are assigned, and when Merkle roots get published. In practice that means eligibility design and group maintenance sit upstream of the nominally neutral proof layer.
    • The contracts README and AttestationsRegistry contract make the attestation layer concrete: only authorized issuers can record or delete attestations, and badges are a stateless non-transferable ERC-1155 view over registry balances. So the badge surface looks open to verifiers, but issuer authorization and collection control remain governance chokepoints.
    • Sismo belongs in the active corpus because it helps separate several layers that are often flattened together under “zk identity”: private account binding, trusted ownership translation, reusable eligibility-group generation, anonymous app-specific uniqueness, and governed attestation issuance.
  • Whitepaper: No canonical standalone Sismo whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official docs README, the Data Vault / Data Groups / Commitment Mapper docs, the Sismo Hub README, and the protocol contracts repository. See ../whitepapers/sismo-primary-sources-2026-05-10.md.
  • Sources:

Internal linkages

Control surface

  • The badge layer is the easy part to see. The real choke points are Commitment Mapper operation, group-generation policy, issuer admission, and the app defaults around vaultId or badge sufficiency.
  • That is why this note belongs on proof middleware, not on generic zk identity vibes. The leverage sits in the machinery that turns private account ownership into commitment receipts, reusable group roots, and app-friendly proof flows.

Governance / control risk

  • Practical authority can accumulate around who operates the Commitment Mapper, which group generators and data providers are treated as canonical, which issuers can write/delete attestations, and how app integrations interpret vaultId uniqueness or badge sufficiency.

  • The real choke points sit in Commitment Mapper trust, group policy, issuer admission, and app defaults, not in the thin label zk identity or badges.

  • Last reviewed: 2026-06-04 UTC

Graph View

Backlinks