# Namada: a Rust L1 for asset-agnostic shielded transfers > Namada is a Proof-of-Stake L1 written in Rust that puts a Multi-Asset Shielded Pool at the centre of its design. This review covers what the MASP does, how to build the node and client from source, and where the project's own documentation stops short. **namada-net/namada** — Rust implementation of Namada, a Proof-of-Stake L1 for interchain asset-agnostic privacy - Repository: https://github.com/namada-net/namada - Website: https://namada.net - Stars: 2,516 · Forks: 1,015 - Language: Rust - License: GPL-3.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/namada-net-namada ## The problem Namada targets: privacy that is not tied to one asset Most privacy systems are built around a single asset. A shielded pool for one token lets you move that token privately, but the moment value arrives from another chain the privacy stops at the bridge. Namada's stated goal is different: a Proof-of-Stake L1 that enables multi-asset shielded transfers for any native or non-native asset. The README frames the project as multichain asset-agnostic data protection, and the repository topics list privacy and zkp alongside blockchain and rust. The intended audience follows from that. This is infrastructure for people who want to hold and transfer assets that originate elsewhere without exposing the transfer graph, and for teams building on a chain that treats IBC as a first-class citizen. The README states full IBC protocol support, which is what makes the non-native asset claim plausible rather than aspirational: value arrives over IBC and enters the shielded pool rather than being wrapped by a custodian. There is a second audience that is easy to miss. Namada rewards users of the Multi-Asset Shielded Pool for their contributions to the shielded set, paid in native protocol tokens. That turns privacy from a cost into something with an incentive attached, and it means the shielded set is meant to grow rather than stay a niche feature. Whether that mechanism works as intended is a question the README does not answer; it describes the reward, not the parameters. ## How the pieces fit: CometBFT, the shielded pool, and a Rust workspace of 40-plus crates Consensus is delegated. Namada uses CometBFT, and the README pins the ledger to CometBFT v0.37.17, which must be installed and available on path. The Dockerfile shows the same pin from the other direction: it clones the cometbft repository at tag v0.37.17 and runs make build in a golang:1.21.0 stage, then copies the resulting binary into the runtime image. So a Namada node is really two binaries cooperating, and the version pairing is not incidental. Above consensus sits the MASP, the Multi-Asset Shielded Pool. The README describes it as supporting shielded transfers for any native or non-native asset, with users rewarded for contributing to the shielded set. A wallet is shipped to mediate user interaction with the protocol, which matters because shielded flows are not something you hand-assemble from raw transactions. The codebase is organised as a Cargo workspace. The root Cargo.toml lists members including crates/shielded_token, crates/proof_of_stake, crates/ibc, crates/governance, crates/ethereum_bridge, crates/vm, crates/wallet, crates/sdk and crates/light_sdk, among others. That split is worth reading as a map of the system: proof-of-stake, governance and IBC each get their own crate, the shielded pool has one, and the transaction and validity-predicate machinery is separated into tx, tx_env, tx_prelude, vp, vp_env and vp_prelude pairs. The wasm packages are deliberately excluded from the workspace and built separately, which is why the Makefile has a build-wasm-scripts-docker target. Two design choices stand out. Cubic slashing is named in the README as part of the proof-of-stake system, and governance is stake-weighted and on-chain. Neither is unusual in isolation, but together they mean that misbehaviour and protocol changes are both handled by the same validator set that secures the chain. The ethereum_bridge crate suggests a second ingress path beyond IBC, though the README does not describe it. ## Installing Namada from source and running the client for the first time The README gives a single command to build and install the node, client and wallet executables from source. It also notes that at least 16GB RAM is needed to build from source, which is a real constraint on a laptop or a small CI runner. The command verifies that a compatible CometBFT is available and attempts to install it if not. ```bash make install ``` After that, the README says the main namada executable will be available on path. You can confirm the build produced what you expect by asking the binary for help, which is also the Dockerfile's default command. ```bash namada --help ``` If you would rather not build on your own machine, the repository ships a Dockerfile that produces four binaries. The runtime image exposes four ports and sets NAMADA_LOG_COLOR to false, so log output is plain text in container logs. ```bash docker build -t namada . docker run --rm namada --help ``` The Dockerfile copies namada, namadan, namadaw and namadac into /usr/local/bin, and exposes 26656, 26660, 26659 and 26657. Those are the ports you would need to map if you run a node rather than just the CLI. For developers working on the protocol rather than using it, the README adds a separate step to build the provided validity predicate and transaction wasm modules, and asks contributors to run formatting and linting before a pull request. ```bash make build-wasm-scripts-docker make fmt make clippy ``` Logging is controlled by the NAMADA_LOG environment variable, which accepts error, warn, info, debug or trace. The README states the default is info for all modules except CometBFT ABCI, which carries a lot of debug logging. For finer control it points at the tracing-subscriber EnvFilter directives, and for tests written with the test_log::test macro it suggests setting RUST_LOG, for example RUST_LOG=info cargo test -- --nocapture. ```bash RUST_LOG=info cargo test -- --nocapture ``` ## Where Namada is the wrong tool, and where the documentation goes quiet The README carries its own warning: the codebase is still experimental, try at your own risk. That is not a formality. It means anyone treating this as a settled ledger for high-value settlement is reading past the project's own statement about itself. The dependency situation is the second constraint. Namada does not ship a consensus engine; it requires CometBFT v0.37.17 on path. That pin couples your upgrade schedule to two release trains, and the Dockerfile shows how specific the pairing is. If you cannot control which CometBFT build is installed on a host, running a node becomes awkward. The Hermes compatibility table is the third. It maps Namada binaries to Hermes versions, and the entries are not uniform: v101.0.0 pairs with upstream Hermes 1.13.0, v1.1.1 with 1.11.0, while v1.1.0 and v1.0.0 pair with namada-specific forks tagged 1.10.5-namada-beta18 and 1.10.4-namada-beta17-rc2. The README describes this as a maintained fork that adds support for Namada. Anyone relaying IBC packets between Namada and another chain should read that table as a hard constraint rather than a suggestion, and should notice that the table's newest row is v101.0.0 while the current release line is v201.0.11. The README does not explain that gap. What is missing is equally telling. The README does not document rollback, does not describe how to recover a node after an upgrade, and does not cover the ethereum_bridge crate beyond its presence in the workspace. It points to docs.namada.net for user guides and specs.namada.net for specifications, which is where those questions would have to be answered. Rust API documentation is not hosted; the README tells you to build it yourself with cargo doc --open, optionally with --no-deps to limit the build to local crates. ## How Namada differs from a general-purpose smart contract chain The closest comparison is a general-purpose L1 with a smart contract VM. Namada does have a VM crate and a validity predicate model, so it is not without programmability. The difference is where privacy sits. On a general-purpose chain, privacy is an application you deploy, and each application builds its own shielded pool for its own asset. On Namada, the shielded pool is at the protocol level and is explicitly multi-asset, so a token that arrives over IBC can enter the same pool as the native token rather than needing its own privacy layer. That changes who does the work. An application team on a general-purpose chain maintains its own circuits, its own anonymity set and its own incentive design. On Namada, the README describes protocol-level rewards for contributing to the shielded set, which is an attempt to grow one shared anonymity set rather than many small ones. The trade-off is that you inherit the protocol's choices: its asset support, its parameters and its release cadence. Namada is also not a general smart contract platform in the way an EVM chain is, so if your requirement is arbitrary on-chain logic, the comparison ends quickly. A second comparison is with a single-asset privacy chain. Those can be simpler and more predictable, but the README's framing makes clear that asset-agnostic support is the point of Namada. If you only ever move one asset, the multi-asset machinery is overhead you are carrying for no benefit. ## Maintenance, releases and what the GPL-3.0 and MIT split means for you The repository is not archived, and the last push was on 2026-09-18. Releases are frequent: v201.0.11 on 2026-09-18, v201.0.10 on 2026-09-11 and v201.0.9 on 2026-08-10. The versioning is unusual and worth understanding before you pin anything. The workspace Cargo.toml declares version 0.251.0, while the release tags are v201.0.x. The repository also carries a VERSIONING.md file and a CONSENSUS_VERSION file at the top level, which suggests the project distinguishes between software versions and consensus versions. The README does not explain the scheme, so read VERSIONING.md before assuming a tag maps cleanly onto a crate version. Upgrade cost is driven by two things. The CometBFT v0.37.17 requirement means every node upgrade has a consensus-engine component. The wasm build step means validity predicates and transaction modules are compiled separately from the workspace, so a change touching them is not covered by a plain cargo build. For a validator, that is a real operational burden; for someone only using the client, it is mostly invisible. The licence situation is split. The README badges show Namada Apps under GPL v3 and Libraries under MIT, and the repository carries LICENSE-GPL and LICENSE-MIT as separate files. The Cargo.toml workspace package metadata declares license = "MIT". So the same repository contains code under two licences, and which one applies depends on which part you are using. If you plan to link against Namada libraries in a proprietary product, the MIT side is the relevant one; if you are modifying the applications, GPL v3 applies. This is a description of what the files say, not legal advice, and the boundary between the two is something your own counsel should confirm against the actual file layout. ## Conclusion Adopt Namada if you need shielded transfers across assets that originate on other chains and you are willing to build from source and track a fast-moving release line. Do not adopt it if you need a stable, audited, production-grade ledger today: the README itself calls the codebase experimental. Before committing, verify the CometBFT v0.37.17 dependency is on your path, check the Hermes compatibility table against the Namada binaries you plan to run, and read the Install section of the user guide for options beyond make install. ## FAQ ### What is Namada? Namada is a Proof-of-Stake L1 written in Rust for interchain, asset-agnostic privacy. It uses CometBFT consensus and supports multi-asset shielded transfers for any native or non-native asset. ### How do I install Namada? The README gives a single command, make install, which builds and installs the node, client and wallet executables from source and verifies that a compatible CometBFT is available. It notes that at least 16GB RAM is needed to build from source. ### Which CometBFT version does Namada require? The README states the ledger currently requires CometBFT v0.37.17 to be installed and available on path. The Dockerfile builds that exact tag in a separate stage. ### How do I change Namada's log level? Set the NAMADA_LOG environment variable to error, warn, info, debug or trace. The README says the default is info for all modules except CometBFT ABCI, which has a lot of debug logging. ### What licence is Namada under? The repository carries two licences. The README badges show GPL v3 for the Namada apps and MIT for the libraries, with LICENSE-GPL and LICENSE-MIT as separate files, and the workspace Cargo.toml declares license = "MIT". ## Sources - [License: GPL-3.0](https://github.com/namada-net/namada/blob/main/LICENSE) - [namada-net/namada on GitHub](https://github.com/namada-net/namada) - [Project website](https://namada.net) - [README](https://github.com/namada-net/namada/blob/main/README.md) - [Releases](https://github.com/namada-net/namada/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/namada-net-namada