Snapshot V1: running the off-chain governance client yourself

What Snapshot V1 is, and who it is built for

The README describes Snapshot as an "off-chain gasless multi-governance client with easy to verify and hard to contest results". Every word in that sentence matters for scoping. Off-chain means votes are not transactions on a blockchain, so a voter does not pay gas to participate. Gasless follows from that. Multi-governance means one interface serves many separate organizations, each with its own space and its own proposal history. Client means this repository is the user-facing application, not the service that stores and serves proposals.

That last point is the one people get wrong. Snapshot V1 is the Vue front end. The README points at snapshot.org and docs.snapshot.org for the product and its documentation, and it tells developers that a local instance connects by default to a hub at https://testnet.hub.snapshot.org. A hub is therefore an external dependency of this codebase, not something the repository contains. If your goal is to run a voting platform end to end, this repository is one half of it.

The audience is correspondingly narrow. It suits developers who want to build or modify a governance interface that reads spaces and proposals from a Snapshot hub, front-end engineers comfortable in Vue and Vite, and teams who want to fork the reference client rather than write one from scratch. It does not suit someone looking for a hosted voting product, and it does not suit anyone who wants a backend they can deploy and forget.

How the client is wired: Vue, GraphQL and a hub

The stack is visible in package.json and the top-level layout. The build tool is Vite, configured in vite.config.ts, with Vue as the framework and Tailwind plus PostCSS for styling. State and data fetching lean on Apollo: @apollo/client and @vue/apollo-composable are both dependencies, which points to GraphQL as the way the client reads governance data. The @snapshot-labs/snapshot.js package is present, and that is the library that handles the Snapshot-specific logic such as proposal and vote formatting.

Wallet and signature handling come from the ethers project packages (@ethersproject/wallet, @ethersproject/providers, @ethersproject/contracts and friends) together with @snapshot-labs/lock, which is the wallet connection layer. ENS resolution is present through @ensdomains/eth-ens-namehash, which is why a development URL can be an ENS-style name rather than a numeric address. There is also @shutter-network/shutter-crypto, which indicates support for encrypted proposals, and @pusher/push-notifications-web and @sentry/vue for notifications and error reporting.

The data flow that follows from this is straightforward. The browser loads the Vue application, the application asks a hub over GraphQL for spaces and proposals, the user connects a wallet, and a vote is signed rather than broadcast as a transaction. The repository also carries a snapshot-spaces entry, which is a git submodule: package.json runs git submodule update --init in a preinstall step, so the spaces data is pulled in at install time rather than vendored. That is a detail worth knowing before you debug a missing-spaces error, because it fails at install, not at runtime.

Installing Snapshot V1 and pointing it at a hub

The README gives a short set of yarn commands. Install dependencies first. Note that the preinstall script initialises git submodules, so the clone needs to be a git clone, not a downloaded archive, for that step to work.

yarn

Start the development server with hot reload. The package.json dev script runs Vite on port 8080.

yarn dev

The README says to test your code at http://localhost:8080/#/fabien.eth. That hash route is a space or profile identifier, so replace it with a space that exists on the hub you are using.

By default the instance talks to the testnet hub. To change that, or any other value, the README says to create a .env.local and overwrite values from .env. The repository ships a .env at the top level, so the pattern is to copy the keys you want to change rather than edit .env directly.

cp .env .env.local

If you prefer a container, the README documents a Docker path. The Dockerfile uses node:18-alpine, installs build tooling, runs yarn install --frozen-lockfile twice, builds, and exposes port 8080.

docker build -t snapshot .
docker run --name snapshot -p 8080:8080 snapshot

After the container starts, the README again points to http://localhost:8080/#/fabien.eth. For a production bundle, run yarn build, which invokes vite build.

Where Snapshot V1 stops being the right tool

The clearest limitation is architectural: this repository does not vote, store or serve anything by itself. It renders what a hub returns. If you want a self-contained governance system, you need a hub as well, and the README does not document how to run one. It points at docs.snapshot.org for documentation, which is where that question has to be answered.

The second limitation is the default configuration. A fresh clone talks to https://testnet.hub.snapshot.org. Testnet data is not mainnet data, so a first run that looks empty is the expected outcome until you set a hub that carries the spaces you want. The README does not spell out which hub serves production spaces; it only tells you the default and how to override it.

Third, the install path has non-obvious requirements. The preinstall hook runs git submodule update --init, so a source tarball or a shallow clone without submodules will fail before the app ever starts. The Dockerfile installs git, python3, gcc, g++ and make, which tells you the dependency tree includes native modules that need a compiler. That is a heavier build than a pure JavaScript front end, and it is the kind of thing that breaks on minimal CI images.

Finally, the README documents no rollback, no migration path between hubs, and no upgrade procedure. If you fork this client, the upgrade cost is on you to work out from the diff.

How it differs from a conventional voting application

The natural comparison is with a conventional governance application where a vote is a transaction: the user pays gas, the vote is written to a chain, and the result is whatever the chain says. Snapshot V1 inverts that. Votes are signed messages recorded off-chain, which is why the README calls the client gasless. The trade-off is verification: an off-chain result has to be independently checkable, which is what the "easy to verify and hard to contest" phrasing in the README is about, and it is not the same guarantee as a transaction receipt.

Within the Snapshot ecosystem itself, the more useful distinction is V1 against the newer interfaces. This repository is explicitly the V1 interface, and the README points readers to snapshot.org for the current product. If you are starting a new integration today, check what the current documentation recommends before forking this codebase, because a V1 client will track the V1 data shapes rather than whatever comes next.

Against hand-rolling a front end on the same hub, the difference is effort rather than architecture. A custom client would still talk to a hub over GraphQL and still need wallet connection and signature handling. Snapshot V1 gives you those pieces already assembled in Vue, at the cost of inheriting its structure, its Vue version and its build setup.

Licence, maintenance and what a fork costs you

The repository is MIT licensed, and package.json repeats the MIT identifier. MIT is permissive: you can use, modify and redistribute the code, including in closed products, provided the licence and copyright notice are preserved. This is not legal advice, and if you are redistributing a modified client you should read the LICENSE file in the repository rather than rely on this summary.

On maintenance, the last push was on 2026-09-14. That is recent enough that the codebase is not stale, but the repository has no retrieved releases, so there is no tagged version to pin against. If you fork it, you are tracking the master branch, and the package.json version is 0.1.4, which reads as pre-1.0 rather than a stable release line.

The practical upgrade cost follows from that. There is no release channel to subscribe to, so upgrades mean diffing master against your fork. The dependency list is large and includes beta-tagged packages, such as @vue/apollo-composable at 4.0.0-beta.11, which means upstream breaking changes can arrive without a major version bump on this project's side. Budget for reading the diff, not for a changelog.

Editorial conclusion

Adopt Snapshot V1 if you are building a governance interface on top of an existing Snapshot hub and want the reference client as a starting point, or if you need to run the front end against a testnet hub for development. Do not adopt it if you expect the repository to give you a voting backend: the README describes a client, and the hub it talks to is a separate service. Before committing, verify three things in your own environment: that yarn install completes the git submodule step, that your .env.local points at the hub you actually intend to use, and that your chosen hub serves the spaces you care about. The default hub is the testnet one, so a first run that shows no proposals usually means the hub setting, not the code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. snapshot-labs/snapshot-v1 on GitHub