Sonr and a Cosmos SDK chain for identities and personal data

What the chain actually holds

Sonr is described as a blockchain ecosystem combining decentralized identity, secure data storage and multi-chain interoperability, built on Cosmos SDK v0.50.14, providing self-sovereign identity through W3C DIDs, WebAuthn authentication and personal data vaults, all without requiring cryptocurrency for onboarding.

The repository description says the same in fewer words: a decentralized identity network built for the InterChain, with topics covering cosmos-sdk, decentralized-identity, did, dwn, libp2p and sonr.

Three custom modules carry the functionality, and the README documents each with its own command examples.

The DID module implements the W3C DID specification, with gasless WebAuthn registration so DIDs can be created without cryptocurrency, multi-algorithm signatures, external wallet linking for MetaMask and Keplr, and W3C-compliant verifiable credential issuance.

The DWN module is the personal data store: structured data records with hierarchical organisation, protocol-based interactions with enforceable data schemas, secure vaults with enclave-based key management, and multi-chain support that covers both Cosmos SDK and EVM transaction building.

The service module is a decentralised service registry, with DNS-based domain ownership proof, verified service endpoint registration, and permission management through UCAN capability integration.

The audience is an identity or credentials developer who has decided that a Cosmos SDK chain with IBC is the right substrate, rather than someone looking for a drop-in DID library.

Gasless registration, and the security rules around it

The onboarding path is the feature that differentiates the project, and it comes with its own security section in the README.

The premise is that a user can create a first decentralized identity without owning cryptocurrency, by registering with WebAuthn. The CLI form is short:

# Register with WebAuthn (no tokens required!)
snrd auth register --username alice

The second variant registers and creates the vault in one step:

# Register with automatic vault creation
snrd auth register --username bob --auto-vault

The security rules for this path are stated as a separate list under gasless transaction security, and the constraints are narrow: the mechanism is limited to WebAuthn registration only, full cryptographic validation is required, credential uniqueness is enforced, and there is anti-replay protection.

That last pair, uniqueness and anti-replay, is the crux of any gasless registration scheme. If a credential can be replayed, then registration becomes an account takeover vector, and if uniqueness is not enforced, one user can claim another's identifier. The README asserts both are handled, and the design pushes the cost of the security onto WebAuthn's own guarantees: origin validation, challenge-response authentication, device binding and attestation verification.

The rest of the security story is about key material. The multi-algorithm support list covers Ed25519 described as quantum-resistant, ECDSA on secp256k1 and P-256, RSA at 2048, 3072 and 4096 bits, and WebAuthn's own ES256 and RS256.

For a project whose selling point is that you do not need tokens to start, this is where an evaluation should spend its time, since the registration path is the one that bypasses the normal economic gate.

The three modules as command line operations

The CLI is the primary interface, and the command shapes show how the modules relate to each other.

For the DID module, creating an identity is a transaction:

# Create a DID
snrd tx did create-did did:sonr:alice '{"id":"did:sonr:alice",...}' --from alice

Linking an external wallet takes the wallet address and type:

# Link external wallet
snrd tx did link-external-wallet did:sonr:alice \
  --wallet-address 0x742d35Cc6635C0532925a3b8c17C6e583F4d6A42 \
  --wallet-type ethereum \
  --from alice

and resolving is a query, which is the read side of the same module:

# Query DID
snrd query did resolve did:sonr:alice

The DWN module creates a vault, writes a record against a protocol, and lists records for an owner:

# Store a record
snrd tx dwn write-record '{"data":"...", "protocol":"example.com"}' --from alice

The service module does domain verification in two steps, initiate and verify, then registers a service with a permission list:

# Register service
snrd tx svc register-service my-service example.com \
  --permissions "read,write" --from alice

Note the pattern across all three: the protocol identifier is part of the data, not a separate concept. A DWN record names the protocol it belongs to, and a service is registered against a domain it has proved ownership of. Both are examples of a chain that carries claims about identity rather than just transferring value.

Building the node and running a local chain

The build is Go and Make based, and the quick start covers the common path.

# Clone the repository
git clone https://github.com/sonr-io/sonr
cd sonr

# Install the binary
make install

# Verify installation
snrd version

Running a chain locally has several entry points depending on what you need. A single-node testnet for quick iteration is make localnet, a multi-node testnet with Starship is make testnet-start, and make testnet-stop shuts it down. Building is make build, the Docker image is make docker, and make proto-gen regenerates code from the proto files.

The local development network section separates two paths. The standard localnet auto-detects the best method for your system and works on Arch Linux, Ubuntu, macOS and others, while make dockernet runs a Docker-based localnet in detached mode and requires Docker. There is also a one-time setup script, scripts/setup_localnet.sh, which installs dependencies and configures the environment.

The test targets are worth knowing because they show what the project considers its own surface. make test-all runs everything, and there are per-module targets: make test-did, make test-dwn and make test-svc. Then there are integration tests named with an ictest prefix, covering basic chain functionality with make ictest-basic, IBC transfers with make ictest-ibc, and CosmWasm integration with make ictest-wasm. Coverage is available through make test-cover.

IPFS infrastructure has its own targets, make ipfs-up, make ipfs-down and make ipfs-status, because the vault operations need it.

A stack of forks, and what that costs you

The go.mod is the part of this repository that deserves the most attention before anyone builds on it, because it replaces substantial parts of the Cosmos ecosystem with forks.

The first replace block points cosmossdk.io/core at a pinned version, redirects cosmossdk.io/store to the evmos fork of the cosmos-sdk store, and swaps github.com/CosmWasm/wasmd for the rollchains wasmd build. The Cosmos SDK itself is replaced with a strangelove-ventures fork at a specific commit, cosmos/evm with a strangelove-ventures cosmos-evm, and go-ethereum with the evmos build at v1.10.26-evmos-rc2. Viper is held at v1.17.0 with an inline comment explaining that v1.18 and later break app overrides.

The second block replaces the keyring with the cosmos keyring, pins btcec to a version for evmos compatibility, moves the deprecated dgrijalva/jwt-go to golang-jwt v4 because the original receives no security updates, moves lyft/protoc-gen-validate to envoyproxy, and pins syndtr/goleveldb to a specific commit with a comment that a later version has issues with the store so that queries fail.

Every one of these is a deliberate decision, and the comments show the reasoning. The evmos fork is what provides EVM compatibility, and the wasmd fork is what makes CosmWasm work alongside it. But the cost is that you are running modified consensus-adjacent code, and the leveldb pin in particular is a comment about query correctness rather than security.

There is a separate chain: the Dockerfile pins a golang:1.25-alpine3.22 builder, downloads the CosmWasm wasmvm static library for the target architecture into a cache mount, and builds with CGO enabled, a muslc build tag, static linking and the ledger feature disabled. The wasmvm download step is cached by the Go module version, which is a neat trick for keeping the build reproducible without vendoring a binary.

The go.mod declares Go 1.25, and the module path is github.com/sonr-io/sonr.

Where Sonr is not the right choice

Two limits are clear.

The first is the release history. The tagged versions are v0.5.26, v0.5.25 and v0.5.24, all dated December 2024, with version names like 2024.50.5, which suggests a build-numbering scheme tied to a period rather than a semver line. The repository is not archived and the last push was on 2026-09-02, so work continues, but a 0.x version with releases that stopped in December 2024 is not a project to build a production identity system on without reading the commits since.

The second is the scope of the identity claim. The README describes W3C DID support, verifiable credentials and WebAuthn registration, which are meaningful standards. But the DID method syntax is did:sonr:, a chain-specific method, so a DID created here is resolvable by this chain rather than by the wider W3C DID ecosystem, and the external wallet linking is a mechanism for associating an existing key rather than a portable credential. If your requirement is that a user can present an identity to an arbitrary relying party, the details of the credential format and the method-specific resolution are where you would need to look closely, and the README does not describe the credential format in detail.

The gasless onboarding is also the wrong default for a system that needs Sybil resistance. A registration that requires no token is convenient and it is a real usability gain, but it removes the economic cost that makes a public identity registry hard to spam. The security section's answer is WebAuthn's device binding and attestation, and the anti-replay and uniqueness rules. Whether that is sufficient depends on what the identities are used for, and that judgement is yours rather than the project's.

Editorial conclusion

Sonr is a good fit for a developer building self-sovereign identity on a Cosmos SDK chain who needs DIDs, verifiable credentials and personal data storage that interoperate over IBC, because the three custom modules cover identity, storage and service registration in one codebase with a CLI for each. It is a poor fit for a team that wants a stable dependency tree, since the go.mod replaces the Cosmos SDK, the EVM module, go-ethereum and several libraries with forks, and the release line stopped in December 2024. Before adopting, check whether the Cosmos SDK v0.50.14 base and the Evmos integration still line up with your own security requirements, and read the gasless transaction security notes, because the registration path is the part that bypasses the usual token requirement and therefore the part with the most interesting attack surface.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sonr-io/sonr on GitHub