Vera is a Cosmos chain that logs what the Source ecosystem claims

A transparency log as its own chain

Vera is presented as Source's trust layer, and the repository description is precise about its role. It is a trust protocol, acting as the transparency log for the Source ecosystem.

The mechanism implies a specific design. A transparency log is an append-only record that anyone can read and that participants can prove membership against. Putting it on its own chain rather than inside an application means the record has its own consensus, its own history and its own availability, and that the parties who write to it do not have to be trusted to keep it honestly.

The stack makes the choice clear. The go.mod is built on the Cosmos SDK at 0.50.14, with CometBFT at 0.38.21 for consensus, IBC go v10 for inter-chain transfers, the Ignite CLI v28 for the developer workflow, and buf for protobuf generation. The repository layout follows the Cosmos SDK conventions closely, with an x/ directory for the chain modules, api/ and proto/ for the generated and source types, app/ for the application wiring, cmd/ for the entry points, and types/, utils/, tools/, tests/ and testutil/ around them.

The homepage is docs.source.network/vera, and the default branch is dev, not main, which tells you something about where the work sits.

For an engineer, the interesting question is what a writer puts in the log and what a reader proves. The protocol layer is in the x/ modules and the types in types/, and the example directory shows the intended usage, with example/access_ticket/, example/bearer_auth/, example/bearer_token_gen/ and an example/sdk/.

Two Docker commands and you have a chain

The fastest way to see Vera running is the standalone image, and the README recommends Docker for exactly that reason.

The repository contains a Dockerfile which, if run with the environment variable STANDALONE=1, spins up a new single node Vera network. Building the image is:

docker image build -t vera:latest .

and starting it is:

docker run -p 9090:9090 -p 26657:26657 -p 26656:26656 -p 1317:1317 -e STANDALONE=1 vera:latest

The four published ports are the standard set for this stack. 9090 is the REST API and the Swagger documentation, 26657 is the CometBFT RPC, 26656 is the peer-to-peer port, and 1317 is the gRPC gateway.

The container will start a new network with no fees and a funded faucet account which can be used. The funded account is static for all new instances of the standalone deployment, and can be imported by a keyring outside Docker or a wallet such as Keplr to broadcast transactions. The README publishes the account mnemonic in plain text, which is correct for a development account and would be indefensible for anything else.

A complete list of the Dockerfile parameters is in the docker readme, and the compose file in the repository does the same thing with a single service, the same four ports, STANDALONE set to 1 and a named volume mounted at /vera.

The dev chain runs with zero fees and a built-in faucet

The development setup is scripted, and the script does more than start a binary.

Running the chain locally is either the entrypoint script or compose:

# Run build/verad directly
./scripts/dev-entrypoint.sh start
# or using Docker
docker-compose up

The dev-entrypoint.sh script runs ./scripts/genesis-setup.sh internally and automatically initializes a new node with chain ID vera-dev, creates the validator and faucet keys, and configures the development settings.

Those settings are the useful part for anyone building against the chain. The genesis setup configures zero-fee transactions with allow_zero_fee_txs = true for easier testing. The minimum gas prices are set to 0.001uopen,0.001ucredit. IBC transfers are enabled. The API and Swagger documentation are enabled. CORS is enabled so the API can be interacted with locally. Prometheus metrics are enabled. And there is a built-in faucet with test funds.

The practical effect is that a developer can send transactions without acquiring tokens, and can call the REST API from a browser-based front end without a proxy in between, which is exactly what you want when the point of the exercise is to explore the API rather than to run a production network.

Nodes use $HOME/.vera by default, so the state directory follows the same convention the Docker image reproduces with its /vera volume and the node user home directory.

Building the chain with Ignite and buf

The build has three steps, and the prerequisites are Go 1.23 or later, the Ignite CLI for proto generation and, optionally, Docker.

# Generate protos
make proto
# Build the binary
make build # or "make build-mac" for macOS
# Install globally
make install

The proto step is the interesting one, because the type generation is split across two buf templates. The standard template excludes three files, proto/vera/orbis/document.proto, ring.proto and tx.proto, and a second template then generates those three separately with proto/buf.gen.orbis.optional.yaml, after which the previously generated pulsar files for them are removed. In other words, three types are generated through a different path from the rest, which usually means those types have a different generation mode, and the Makefile keeps the two consistent by cleaning up after the first pass.

The Makefile also defines the other targets a contributor needs. make test runs go test ./..., and make test:all runs the test matrix through scripts/run-test-matrix, which first builds a test_env_generator. make simulate uses ignite chain simulate. make fmt runs gofmt and buf format. make docs serves the Go package documentation with pkgsite on port 8080. make docker builds the image as ghcr.io/sourcenetwork/vera:dev, and there is a demo binary target, build/token-protocol-demo, which is the only mention of a token protocol example anywhere in the repository listing.

The Docker build itself is a two stage build from golang:1.26.2 producing the verad binary, and the runtime image is debian:bookworm-slim with the binary, the default config toml files and the entrypoint script. It also creates a symlink named sourcehubd pointing at verad, and it accepts optional environment variables for a genesis file, a mnemonic and CometBFT keys, so an operator can supply their own instead of letting the entrypoint generate them.

The dependency list, and the two pinned workarounds

The go.mod is where the protocol's real shape shows. Beyond the Cosmos SDK, CometBFT and IBC, the direct dependencies include the TBD SSI SDK, buf for protobuf work, the Ignite CLI, lestrrat-go/jwx for JSON web tokens, go-jose for JOSE, mizufinance's decaf377-go, which is a threshold cryptography library, skip-mev's block-sdk, docker's client library, gorilla/mux, the gRPC gateway in both v1 and v2 flavours, and hashicorp go-metrics.

The threshold crypto library and the JWT library are the two that explain what the example directories are for. The examples cover access_ticket, bearer_auth and bearer_token_gen, so a reader can see how a request is authorised against the chain's records, and the threshold crypto dependency is consistent with a design where some operation needs a threshold of parties rather than a single key.

There are also two replace directives, and both have comments explaining them. The first pins gin to v1.7.0 to fix an upstream vulnerability, and the second replaces the broken goleveldb with a specific commit.

Those two lines are the honest summary of what building a Cosmos application in 2026 involves. The framework is a large dependency graph, some of it moves faster than the ecosystem can track, and the result is a manifest with pinned overrides that a reader should not skim past, because each one is a decision someone had to make about a security advisory or a broken release.

Where Vera is the wrong tool

Three cases, and the first is about what a chain in this state can promise.

The repository ships a development network. The standalone image starts a single node with no fees and a static funded account whose mnemonic is printed in the README, and the development chain runs with zero-fee transactions and a faucet. That is exactly what you want for local development and exactly what you cannot run in production, and the release history reflects the stage: the tags are v0.3.2, v0.3.1 and v0.2.0 with the title Testnet 1, which is a naming that says where it is.

The second is the operational weight. A Cosmos chain is a validator set, a consensus engine, a proposer, IBC for inter-chain transfers and a key management story for validators and faucet keys. If what you need is an append-only log of attestations that a small set of parties write to, a single service with an append-only store and signed entries would be a smaller thing to own, and Vera is not that.

The third is the coupling. The chain is built on the Cosmos SDK, the Ignite CLI and CometBFT, and the README points the developer at the Ignite tutorials and the Cosmos SDK documentation rather than at protocol-specific guides, so the learning curve includes a framework you would otherwise not have needed. The example directory is the place where that cost is lowest, and it is worth reading the access_ticket and bearer_auth examples before committing to the integration.

Licence, releases and what to check first

The licence is Apache-2.0, with the text in a LICENSE.txt file at the repository root, so the code can be used, modified and redistributed under permissive terms with the notice retained.

The maintenance picture is mixed in an interesting way. The last push was on 2026-10-06 and the repository is not archived, so the code is still moving. The recent releases are v0.3.2 on 2025-06-05, v0.3.1 on 2025-05-28 and v0.2.0, titled Testnet 1, on 2024-02-08. So there is a gap of more than a year between the last published tag and the last commit, and the work since then is on the dev branch.

That matters for anyone integrating. The default branch is dev, so a clone gives you the development line, and the published v0.3.2 tag is a year older than the tip of that branch. Which version your client should talk to is a question worth answering before you write any code, since the chain identifier differs between the standalone image and the development chain, and the standalone deployment is configured through the environment variables in the Dockerfile while the dev chain is configured by the genesis script.

The protocol documentation lives at docs.source.network/vera, and the repository also carries a docs/ directory, a manual/ directory and an example/ directory. The api/ directory holds the generated code and the proto/ directory the source definitions, with the Swagger documentation served by the node itself, so the fastest way to understand the API is to start a standalone node and read the docs it serves.

Editorial conclusion

Vera suits a developer who wants to run a Source trust layer locally, integrate against its REST API, or read the protocol's data model before committing an application to it, and the standalone image makes that a two command exercise. It is the wrong tool if you need a production ready trust network, because what the repository ships is a development chain with a static faucet account and a public mnemonic, and the published releases stop at a testnet line. Verify first which chain your client expects, since the standalone deployment and the development chain use different chain identifiers and the default branch is dev rather than main, and read the protocol documentation at docs.source.network/vera before designing an integration against the API.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sourcenetwork/vera on GitHub