Warden Protocol: a Cosmos SDK chain monorepo with one proprietary module

One repository holding the chain, its contracts and three web clients

The wardenprotocol repository is a monorepo, and the top-level listing shows how much it carries. There is `warden/` for the chain itself, `cmd/` for binaries, `api/` and `proto/` for the interface definitions, `go-client/` for a Go client, `solidity/` and `contracts/` for the EVM side, `precompiles/` for chain-provided contract implementations, and `tests/` for the suite. Alongside those sit `spaceward/`, `snap/` and `automated-orders/`, which are JavaScript projects, plus `shield/`, `keychain-sdk/` and `prophet/`.

The project description says this is a monorepo for Warden Protocol and its services, and general information lives on wardenprotocol.org. Code-level documentation is split deliberately: a documentation website for learning and joining the network, and a `protocol-developer-docs/` directory in the repository itself for anyone contributing to the protocol. That split is unusual and worth noting, because protocol changes are the kind of thing that goes stale on a marketing site.

The GitHub language field for this repository reports TypeScript, which reflects the three JavaScript subprojects but understates the reality. The chain is Go: `go.mod` names the module `github.com/warden-protocol/wardenprotocol` and targets Go 1.26.0. Treat it as a Go project with frontend and service sidecars attached.

The pinned forks in go.mod are the architecture in miniature

The `go.mod` file is the most informative file in the repository, because the replace directives there are where the chain's actual design decisions live. It swaps `github.com/99designs/keyring` for a Cosmos fork of keyring, replaces `github.com/ethereum/go-ethereum` with `github.com/cosmos/go-ethereum` at `v1.16.2-cosmos-1`, and pins `github.com/gin-gonic/gin` to `v1.9.1` with a comment citing a security advisory.

The require block underneath confirms the stack. You have `github.com/cosmos/cosmos-sdk v0.53.6`, `github.com/cosmos/evm v0.6.2`, `github.com/cosmos/ibc-go/v10 v10.5.0`, `github.com/CosmWasm/wasmd v0.61.2` and `github.com/cometbft/cometbft v0.38.21`. That combination is the interesting part: an IBC-capable Cosmos chain that also embeds an EVM, so Solidity contracts and Cosmos modules can coexist on the same chain with a shared security and settlement layer.

It also means the chain is not drop-in compatible with an upstream Cosmos SDK deployment. Two of the three replaces point at Cosmos forks of third-party libraries, so a library expecting stock `go-ethereum` will not build against it unchanged. There is also a replace for `github.com/syndtr/goleveldb` pinned to a specific commit, with a comment calling it a broken replacement.

Release, Docker and a Makefile that tells you to stop using make

The build tooling is unusual enough to trip people up. The root `Makefile` is a shim whose only real target prints a message:

  Mac OS:      brew install just
  Arch Linux:  pacman -S just

Those lines are the whole of its advice, and it tells you the project uses `just` instead of `make`. The real recipes live in `justfile`, `wardend.just` and `localnet.just`. The `justfile` uses `mod` to pull those in, so `just --list` is the correct way to discover what is available. Recipes include `deploy-contract`, which stores and instantiates a CosmWasm contract and echoes back the address, and `release-publish-docker`, which builds a `ghcr.io` image for `wardend` or `wardenkms`.

The `Dockerfile` is a multi-stage build covering all three JavaScript projects, which tells you how separate they are. It starts from `node:lts-alpine` with Python and build tools added, installs pnpm 9 globally, then builds the automated-orders libraries with yarn:

RUN yarn install --frozen-lockfile && \
    yarn build:libs && \
    rm -rf packages/*/src packages/*/node_modules packages/*/tsconfig*

Later stages build the `snap/` project with npm and the `spaceward/` project with pnpm. The spaceward stage is also where the frontend configuration is wired, through build arguments passed as environment variables:

ENV VITE_WARDEN_RPC_URL=%WARDEN_RPC_URL%
ENV VITE_WARDEN_REST_URL=%WARDEN_REST_URL%
ENV VITE_WARDEN_EVM_URL=%WARDEN_EVM_URL%

So a single container build covers the chain tooling, the snap client, SpaceWard and the order automation libraries, each with its own package manager. There is a second Dockerfile at the root named `warden.Dockerfile` alongside the general `Dockerfile`, which suggests the chain node itself is built separately from the services.

Apache 2.0 across the board, except x/async and SpaceWard

The licensing section of the README is unusually explicit, and it is the first thing to read in this repository. The project is released under Apache 2.0, with two exceptions. The SpaceWard folder and the `x/async` module are not covered, and `x/async` specifically is described as governed by a proprietary licence at `warden/x/async/LICENSE`, with use, modification and distribution stated to be strictly limited.

The README goes further than most projects do and names the origin of the code. Elements of the project are based on work made by Qredo Ltd on Fusion Chain, released under Apache 2, with details in the `NOTICE` file at the root. The repository also carries a `CODEOWNERS` file and a `.licenserc.json` configuration, which together suggest licence headers are enforced automatically rather than by convention.

Two details are worth holding onto as you read. First, GitHub reports the repository's licence as Apache-2.0, which is accurate for most of the tree but says nothing about the proprietary module. Second, the README instructs anyone wanting to use the restricted source to email [email protected], which means the terms for `x/async` are negotiable rather than fixed. If you are evaluating this code commercially, that email is a gating step, not a formality.

Where the 1.0 releases and the EVM module fit

The repository has three tagged releases: v1.0.0 on 2026-03-03, v1.0.1 on 2026-03-23, and v1.0.2 on 2026-08-23. The last push to the repository was on 2026-08-27, so development was still moving shortly after the newest tag.

The v1.0.2 release notes are a single change, and it is informative about where the work goes. It bumps `cosmos/evm` to v0.6.2 and rejects vesting account creation, which is the kind of change that only becomes necessary once a chain has real accounts to restrict. A release with one commit in it also tells you the tag is not a curated milestone but a point in the dependency and behaviour timeline.

The `precompiles/` directory and the `solidity/` and `contracts/` directories are where the EVM integration is implemented, and the pinned `cosmos/go-ethereum` fork is what makes that possible. Precompiles are the mechanism by which a Cosmos chain exposes native functions to Solidity contracts at fixed addresses. If you are reading this repository to understand how the two execution models meet, that directory plus the `cosmos/evm` version pin is the shortest path.

Who this monorepo is actually for

This is infrastructure for people building a Cosmos application chain, and the go.mod pins make that clear. Nobody outside that world needs the fork list, the CosmWasm deploy recipe or the precompile directory. What general readers can take from it is a worked example of running two execution environments on one chain.

The prerequisites are heavier than they look. You need Go 1.26, a `just` toolchain rather than make, Docker with buildx for the release images, and familiarity with both Cosmos SDK module development and Solidity contract deployment. The `localnet.just` and `wardend.just` files suggest there is a scripted local network, which is how you would realistically evaluate the chain, but that is more setup than a library dependency.

The other honest limitation is that this repository is a moving target with a young release history. Three 1.0 tags inside about six months, an EVM module that was still being bumped in the newest release, and a proprietary module still being negotiated by email are all signs of a project in progress rather than a settled dependency. If you need a stable module to build on, the Cosmos SDK version is pinned and readable. If you need the Warden chain itself as infrastructure, the documentation website and the protocol developer docs in the repository are where you would start.

Editorial conclusion

This monorepo is a fair reference for anyone building an application chain that needs Cosmos SDK modules, CosmWasm contracts and an EVM in the same repository, because the go.mod replace directives and the multi-stage Dockerfile show exactly what that combination costs you in forks and pinned versions. It is not a starting point for a small chain, since the release process alone assumes Docker, a `just` toolchain and a published ghcr.io image. Two things decide it for you. Check x/async first, because it is the one directory under a proprietary licence and you cannot treat the repository as uniformly Apache 2.0. Then confirm that the Cosmos SDK version your work expects matches the pinned v0.53.6, because this chain tracks its own fork points and a mismatch will not be obvious until a node refuses to sync.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. warden-protocol/wardenprotocol on GitHub