Namada Wallet mobile. Key management open source

Hello!

TNSO team decided to open source the key management part of our code, with a good intentions.

This is a fork of the latest app version 1.7.0 (1)
It has seen some community adoption and real-world feature testing on mainnet since July 2025.

The app built with cross platform Flutter framework and uses 1 single source code for both platforms: Android and iOS.

Code parts:

  1. Key management: create, import.
  2. Transparent assets balance with a refresh logic.
  3. Custom UI components and original UX/UI flow.

Note: may contain not well structured and a little bit duplicated code, maybe we’ll cleanup it when we’ll have a time.

6 Likes

Build & reproduction report - namada-sdk-wrapper-keychain (Termux / proot-distro Ubuntu, ARM64)

Short summary
I attempted to build namada-sdk-wrapper-keychain in Termux → proot-distro (Ubuntu arm64). Build finishes for libnamada_wrapper.so (Rust), but attempts to prepare a minimal Node.js CLI (using ffi-napi) fail: native addon build for ffi-napi breaks on Node 20 / ARM64 (node-gyp errors). Also observed runtime ES module require error when launching the demo CLI.


Environment

Device: Android (Termux + proot-distro)

Distribution: proot-distro Ubuntu (arm64)

Node: v20.19.4

npm: 9.2.0 (used for some steps)

yarn: 1.22.22

Rust: rustc 1.91.0, cargo 1.91.0

Termux storage available; working directory ~/namada-sdk-wrapper-keychain


What I cloned

git clone GitHub - GE-Tnso/namada-sdk-wrapper-keychain

(and later the wallet keychain repo)


Commands I ran (full reproduction)

Run in proot-distro / Ubuntu session:

(prepare basic environment in Termux + proot-distro)

proot-distro login ubuntu

Clone repo (example)

cd ~
git clone GitHub - GE-Tnso/namada-sdk-wrapper-keychain
cd namada-sdk-wrapper-keychain

Install JS toolchain if needed

npm install -g yarn
yarn install

Build Rust wrapper (this completed)

cargo build --release

Check produced artifact

ls -lh target/release/libnamada_wrapper.so
sha256sum target/release/libnamada_wrapper.so

=> 2f6522344cd982c2785d98fa92a32af479b08b19f384a163698fbbf195bbf69c

Create minimal Node CLI and install ffi-napi (this is where failure occurs)

mkdir -p ~/namada-cli && cd ~/namada-cli
cat > package.json <<‘EOF’
{
“name”: “namada-cli”,
“version”: “1.0.0”,
“type”: “module”,
“main”: “index.js”,
“dependencies”: {
“ffi-napi”: “^4.0.3”,
“ref-napi”: “^3.0.3”,
“inquirer”: “^9.2.7”,
“chalk”: “^5.3.0”
}
}
EOF

yarn install

OR: npm install (similar issues)


Observed failures (key excerpts)

When yarn install runs, ffi-napi triggers native build via node-gyp and fails with C++/N-API / header mismatch errors:

gyp ERR! build error

../src/ffi.cc:58:41: required from here
/usr/include/nodejs/src/js_native_api.h:528:44: note: initializing argument 4 of ‘napi_status napi_add_finalizer(napi_env, napi_value, void*, node_api_basic_finalize, void*, napi_ref__**)’

error: invalid conversion from ‘napi_finalize’ {aka ‘void ()(napi_env__, void*, void*)’} to ‘node_api_basic_finalize’ {aka ‘void ()(const napi_env__, void*, void*)’} [-fpermissive]

make: *** [ffi_bindings.target.mk:117: Release/obj.target/ffi_bindings/src/ffi.o] Error 1
gyp ERR! stack Error: make failed with exit code: 2

At runtime (after partial setup), Node throws:

ReferenceError: require is not defined in ES module scope

because package.json contains “type”: “module”

Summary: ffi-napi C++ addon fails to compile under Node 20 + system Node headers on ARM64 (Termux/proot). The napi / node-addon-api expectations appear to mismatch the installed Node headers.


Successful build artifacts (proof)

Rust build produced libnamada_wrapper.so:

-rwxr-xr-x. 2 root root 73M target/release/libnamada_wrapper.so
SHA256: 2f6522344cd982c2785d98fa92a32af479b08b19f384a163698fbbf195bbf69c

(If needed, I can provide the file or upload a copy - currently stored locally in my Termux storage.)


Additional notes & reproduction hints

I reproduced on a clean proot-distro Ubuntu install inside Termux (ARM64). The same ffi-napi build fails consistently.

Attempting npm cache clean, re-installing node-gyp, installing make, g++, Python etc. did not resolve the napi type conversion errors.

git clone of tnso-project/namada-wallet-mobile-keychain returned 404 (repo not found), so I used the wrapper repo above.


Questions / requests for maintainers

  1. Node / ffi-napi support: Are there official or recommended Node versions for building the JS CLI (for example Node 18 LTS)? If Node 20 is supported, can maintainers provide guidance for building ffi-napi on ARM64 (Debian/Ubuntu/Termux)?

  2. Prebuilt binaries: Could you publish prebuilt libnamada_wrapper.so for aarch64 (or a simple release artifact) to avoid native build on mobile? A prebuilt .so would help testers on Android/Termux.

  3. ffi-napi replacement: Consider providing a pure-N-API binding (or a prebuilt node binding) that avoids node-gyp native compilation on mobile/arm64.

  4. ES module / CommonJS: Example index.js/packaging guidance: if you publish an example CLI, indicate whether it expects type: “module” or CommonJS; adjust the sample code accordingly (avoid require in ESM).

  5. Build matrix in docs: Please add a short supported-platforms note (Linux x86_64, arm64, Node versions) in README so testers know the expected environment.


Attachments / logs

I can attach:

a short terminal log (key errors) - inline above

the produced libnamada_wrapper.so SHA256: 2f6522344cd982c2785d98fa92a32af479b08b19f384a163698fbbf195bbf69c

full yarn install output / npm debug log on request


Final remark

This is reproducible on Termux/proot Ubuntu (arm64) with Node 20. The core issue appears to be native addon compilation for ffi-napi under Node 20 / arm64 (N-API mismatch). For mobile testing and CI, having prebuilt artifacts or official build instructions for ARM would unblock many testers.

1 Like

Report: Python Compatibility with Namada Keys, Derivation, and Wallet Logic

I spent some time testing Python-based tooling for BIP39, SLIP-10, and BIP44 key derivation in the context of Namada. Below is a detailed summary of what works well, what works partially, and what currently cannot be done in Python due to missing specifications or SDK components.


What Works Well:

Python (with bip_utils, pycryptodome, bech32, base58, etc.) can fully handle the following:

  1. BIP39 mnemonic generation and validation
    Both 12-word and 24-word mnemonics work fine. Validation is reliable, seed generation is correct.

  2. SLIP-10 Ed25519 master key derivation
    Using bip_utils, SLIP-10 Ed25519 master keys and hardened child paths can be derived without any issues.

  3. Cosmos / Osmosis key derivation (m/44’/118’/0’/0/0)
    Derivation works perfectly. Python produces valid secp256k1 private keys and Bech32 (cosmos1… / osmo1…) addresses.

(If Bip44Coins.OSMOSIS is missing, Bip44Coins.COSMOS works as a drop-in replacement.)

  1. Ethereum derivation (m/44’/60’/0’/0/0)
    ECDSA secp256k1 keys and checksummed Ethereum addresses are derived correctly.
    This covers USDC / USDT / DAI on ERC-20.

  2. Namada transparent key derivation (SLIP-10 Ed25519)
    The hardened path
    m/44’/877’/0’/0’/0’
    works correctly in Python.
    Python successfully produces valid raw Ed25519 private and public keys for transparent accounts.


What Works, But With Limitations:

  1. Creating a fully valid Namada transparent address
    Python can derive the raw keypair (priv/pub) but cannot transform the public key into a complete Namada transparent address because the encoding scheme is Namada-specific and not publicly documented.
    There is no official Python SDK for this, so final address construction requires the Rust codebase or the Namada CLI.

  2. Using seed phrases generated by some JS wallets (e.g., Leap)
    Some multi-coin wallets use non-standard or modified mnemonic formats.
    Python BIP39 validation rejects these as invalid.
    Only strict BIP39 mnemonics are supported.

  3. Osmosis coin constants in bip_utils
    Depending on the version of bip_utils, Bip44Coins.OSMOSIS may be missing.
    Fallback to COSMOS works, but the library itself is inconsistent across versions.


What Does Not Work At All:

  1. Shielded (Sapling) keys for Namada
    Namada shielded accounts rely on Sapling (ZIP-32, proving keys, note commitments, nullifiers).
    There is no Python implementation, no documentation, and no available Sapling/halo2 bindings.
    Therefore:
    Shielded key generation or recovery in Python is impossible.

  2. Namada transaction creation and signing
    Python cannot build or sign Namada transactions of any kind.
    The following are not possible:

transparent transfers

shielded transfers

unshielding

staking/bonding

IBC transfers

fee calculation

message serialization

Namada uses a custom serialization format and custom logic for signatures, which is only implemented in Rust.

  1. Parsing or generating Namada wallet files (wallet.toml / wallet.json)
    These files contain Namada-specific structures:

key IDs

nullifier sets

note commitments

Sapling metadata

encoding formats not documented publicly

Python tooling cannot reproduce or parse these formats.


Overall Summary:

Python is fully capable of generating BIP39 mnemonics, deriving seeds, and producing SLIP-10 Ed25519 keys. This means transparent Namada keys can be produced correctly from a BIP39 seed. Python also handles Cosmos, Osmosis, and Ethereum derivation reliably.

However, Python cannot construct actual Namada transparent addresses, cannot work with shielded accounts at all, cannot serialize or sign Namada transactions, and cannot interpret or create Namada wallet files. All higher-level Namada functionality (transactions, IBC, shielded logic) is currently locked inside the Rust SDK with no available cross-language documentation.

To make Python tooling feasible, Namada would need to publish:

  1. A full transparent-address encoding specification

  2. A public specification for key formats (transparent + shielded)

  3. Documentation for transaction serialization and signing

  4. A minimal Python or JS SDK exposing key handling and message building

Until that happens, Python can only be used for key derivation, not for interacting with the Namada network.

1 Like