Bandada

  • Name: Bandada
  • URL: https://bandada.pse.dev/
  • Category: privacy-preserving group-management middleware / anti-sybil credential-gating infrastructure / Semaphore-adjacent anonymous-membership tooling
  • Summary: Bandada is group-management middleware that sits between credential checks and anonymous signaling. The point is not the privacy branding. The point is that it makes admission policy, member storage, proof serving, and admin control visible instead of pretending the whole problem starts and ends with the downstream zk signaling primitive.
  • What it does:
    • Lets admins create and manage privacy-preserving groups through a dashboard, API, SDK, or self-hosted deployment
    • Supports both manual groups and credential-based groups, including invite-link flows and eligibility checks tied to external accounts or attributes
    • Offers onchain and offchain group-management paths rather than limiting the system to one membership substrate
    • Provides credential validators and an extensible credentials library so builders can define which proofs or account properties gate entry
    • Integrates with Semaphore-compatible group structures so members can later produce anonymous proofs or signals in downstream applications
    • Handles large-group operational needs such as offchain member storage and server-side Merkle-proof generation
    • Exposes admin-facing API-key control for adding or removing members in supported group types
  • Key claims:
    • The official docs define Bandada as infrastructure for managing privacy-preserving groups and explicitly frame credential groups as anti-sybil admission filters. That makes it more useful to catalog as admission-and-membership middleware than as a generic identity app.
    • The FAQ provides the clearest analytical split from Semaphore: Semaphore handles anonymous group-membership proofs and signaling, while Bandada fills the offchain group-management and member-storage gap. This is exactly the kind of layer separation the corpus is trying to preserve.
    • That same FAQ adds two practically important details. First, Bandada is designed to work with both onchain and offchain groups. Second, it emphasizes server-side Merkle-proof generation for large groups, which reveals a real operational control surface that later anonymous-signaling apps may inherit without exposing it directly.
    • The official site and launch post show Bandada is not only a developer library. It includes a dashboard and end-user flows for joining groups, plus multiple admission paths: direct member insertion, invitation-based entry, and credential-based entry. So the project packages governance over who counts as an eligible anonymous participant, not only the proof machinery.
    • The GitHub repository is especially useful because it makes the full stack explicit: API, dashboard, demo client, verification contracts, and JavaScript libraries. That decomposition helps separate storage, admin UX, verification contracts, and developer integration instead of flattening everything into one zk identity label.
    • The launch post also clarifies Bandada’s intended trust surface: admins choose credential requirements such as GitHub or Twitter-based criteria, while developers can extend validator logic through the credentials library. In practice, this means authority can centralize in provider support, validator policy, and hosted deployment defaults even when downstream signaling is anonymous.
    • A useful comparison insight is that Bandada sits between systems like Guild and Semaphore. Relative to Guild, it is oriented toward private or pseudonymous membership sets rather than openly visible community roles. Relative to Semaphore, it is focused less on the signaling primitive and more on how groups are created, populated, maintained, and proven.
    • The project cleared the bar because it gives the identity and sybil-resistance clusters a cleaner upstream comparison point for group administration, eligibility curation, member storage, proof serving, and provider dependencies — surfaces that often matter as much as the eventual anonymous vote, attestation, or message.
  • Whitepaper: No canonical standalone whitepaper surfaced in this pass. The strongest primary materials were the official docs, official site, launch post, and source repository collected in ../whitepapers/bandada-primary-sources-2026-05-11.md.
  • Sources:

Internal linkages

  • Best upward reads: semaphore, guild, and human-passport. Those keep the note on anonymous group proofing, admission policy, and stronger anti-sybil identity rails without turning it into a zk-identity directory.

Control surface

  • The real leverage sits in validator support, invite rules, admin API control, proof-serving defaults, dashboard custody, and hosted-versus-self-hosted deployment.

  • Bandada matters because it is the admission layer in front of anonymous signaling, not the signaling primitive itself.

  • Last reviewed: 2026-05-26 UTC