Snapshot Labs

• Name: Snapshot Labs
• URL: https://snapshot.box/
• Category: governance interface and data-services operator / offchain voting shell / Snapshot X service-layer operator
• Tags: ethereum-ecosystem
• Summary: Snapshot Labs belongs in companies/ because Snapshot’s real control surface is not exhausted by the governance protocol or strategy system alone. A named operator still packages the default offchain governance shell around Snapshot and the optional service layer around Snapshot X: Hub API access and API-key whitelisting, space verification, Pro upsells and manual support, the default UI and SDK path, and the indexer / relayer surfaces many DAOs inherit before they self-host or replace anything. Keep snapshot on the governance stack itself; use this note when the sharper question is who controls the service and distribution shell around it.
• What it does:
  • Packages the default Snapshot front-end, Hub GraphQL API workflow, docs/help-center surface, and broader hosted operator experience around gasless DAO voting
  • Maintains open-source repos under the Snapshot Labs organization spanning the offchain protocol Hub, UI, sequencer, Snapshot X indexer/API, SDKs, MCP server, and relayer components
  • Provides optional offchain services around Snapshot X including the API indexer, UI, sx.js SDK, and Mana meta-transaction relayer for sponsored proposal creation and voting
  • Controls API-key review and higher-rate access to the Hub API, which makes data access policy part of the practical operator boundary even when the protocol surface is public
  • Mediates legitimacy and premium workflow through manual space verification, Snapshot Pro, custom-domain support, delegation-dashboard setup, and direct support channels
• Key claims:
  • The Snapshot X services architecture says the protocol itself avoids centralized dependencies while Snapshot Labs provides a number of additional offchain services including the API, SX.js, UI, and Mana relayer, which is the clearest current reason to keep a separate entity note
  • The API-key docs say higher Hub API limits require an application form, operator review, address whitelisting, and an emailed key, which makes access to the most convenient governance-data path partly company-mediated rather than purely protocol-native
  • The space-verification docs say verified badges require threshold criteria plus support-side review, showing that one named operator still controls a meaningful legitimacy signal inside the default governance venue
  • The Snapshot Pro docs sell premium governance features such as custom domains, delegation dashboards, premium voting strategies, and dedicated Telegram support, with some setup and trial access handled manually, which is a clear operator boundary rather than a neutral protocol primitive
  • The sx-monorepo README explicitly lists the Snapshot official frontend, offchain-protocol GraphQL Hub, Snapshot X API, Mana relayer, MCP server, and sequencer in one repo family, reinforcing that the same organization touches both user-facing governance UX and the service surfaces around it
  • The docs and repo structure together show why the company split matters: Snapshot may aspire to modular and decentralized governance infrastructure, but many practical workflows still pass first through Snapshot Labs-controlled service packaging, support, and policy gates
• Whitepaper: No standalone Snapshot Labs whitepaper is the point here. The strongest primary materials are Snapshot’s docs corpus, the API-key / verification / Pro pages, the Snapshot X services architecture page, and the Snapshot Labs GitHub organization and monorepo already summarized in ../whitepapers/snapshot-primary-sources-2026-04-27.md.
• Sources:
  • https://snapshot.box/
  • https://docs.snapshot.box/llms.txt
  • https://docs.snapshot.box/tools/api
  • https://docs.snapshot.box/tools/api/api-keys
  • https://docs.snapshot.box/user-guides/spaces/get-verified
  • https://docs.snapshot.box/user-guides/spaces/pro
  • https://docs.snapshot.box/snapshot-x/services/architecture
  • https://github.com/snapshot-labs
  • https://raw.githubusercontent.com/snapshot-labs/sx-monorepo/master/README.md

Internal linkages

• Project / protocol surface: snapshot.
• Useful governance-control comparison where the hosted shell still matters separately from the protocol surface: commonwealth-labs.
• Useful adjacent governance plumbing read: census3.
• Keep the distinction explicit: Snapshot Labs is the operator and service shell around Snapshot, not a substitute for the protocol note.

Protocol / company boundary

• snapshot should stay focused on the governance stack itself: voting strategies, gasless signaling, Hub/webhook integration surfaces, and Snapshot X’s modular onchain architecture.
• This note exists for the separate question who currently controls the default service and distribution shell around that stack?
• Snapshot Labs is the sharper place to reason about Hub API access policy, verification badges, Pro packaging, custom-domain and delegation-dashboard workflow, the default UI and SDK path, and the optional indexer / relayer services around Snapshot X.
• That split matters because how does Snapshot work? and which operator controls the easiest governance path most teams actually inherit? are related but not identical questions.

Control surface

• Practical leverage sits in API-key issuance and rate-limit policy, space-verification review, premium support and feature packaging, default UI / SDK / docs flow, and the optional Snapshot X services many teams adopt before they run their own stack.

• The protocol story matters, but the operator story still matters too: the same named entity sits closest to legitimacy badges, help-center review, premium workflow, and the service surfaces that smooth over the underlying modular governance stack.

• Read the durable risk here as governance-interface and service-shell gravity. Even if proposals and strategies are legible, many communities still meet Snapshot through Snapshot Labs-controlled defaults first.

• Last reviewed: 2026-08-12 UTC