Cake Wallet packs Monero, Bitcoin and Solana into one Flutter app

One repository, two applications and thirteen chains

Cake Wallet describes itself as an open-source, noncustodial and private multi-currency wallet for Android, iOS, macOS and Linux, and the same repository also produces Monero.com, a Monero-only wallet for Android and iOS. That second app matters more than it first appears. A Monero-only build is a defensible product decision in a codebase that otherwise spans Monero, Bitcoin, Litecoin, Bitcoin Cash, Ethereum, Polygon, Base, Arbitrum, Solana, Tron, Nano, Zano and Decred, and the README notes that exchanging to and from other assets is supported even there.

The application-level feature list is where the trade-offs show. Custody is noncustodial, the user holds keys, and the app includes a built-in exchange for dozens of pairs, fiat purchases of BTC, LTC, XMR and ETH, and fiat selling by bank transfer. It also allows selecting custom nodes and servers, which is the setting that matters most for a Monero user who wants to route through their own infrastructure.

Two security and privacy settings are named directly: Tor-only connections, and Cake 2FA. On-chain addressing goes beyond raw strings, with support for OpenAlias, Unstoppable Domains, Yats and FIO Crypto Handles, plus an address book and local transaction notes.

For a developer, the relevant fact is that this is a Flutter application written in Dart with the default branch set to dev.

The cw_ packages are where the real work sits

The top level of the repository is the most informative document in it. Each chain gets its own package: `cw_bitcoin`, `cw_bitcoin_cash`, `cw_core`, `cw_decred`, `cw_dogecoin`, `cw_evm`, `cw_monero`, `cw_mweb`, `cw_nano`, `cw_solana`, `cw_tron`, `cw_wownero`, `cw_zano` and `cw_zcash`, alongside `cw_shared_external` and `cw_custom_lints`.

The naming carries information. EVM chains share `cw_evm` rather than each having a copy, which is consistent with the README grouping Ethereum features as ERC-20 token storage, adding custom tokens by contract address, and toggling Etherscan for transaction history. Bitcoin and Litecoin each get their own package because their distinguishing feature is coin control, choosing specific outputs to spend, alongside automatic address generation and multi-recipient batch sends. `cw_monero` is where the privacy-specific behaviour lives: retaining the view key on the device, full subaddress and account support, a configurable restore height for faster syncing, trusted nodes for faster syncing, and a node proxy compatible with Tor and i2p.

The presence of `cw_dogecoin`, `cw_zcash` and `cw_mweb` is worth noting against the README's coin list, which omits Dogecoin and Zcash. The package layout and the marketing list are not in one-to-one agreement, which is a small reminder to read the code rather than the feature bullets.

`cw_core` is the shared layer, and `cw_custom_lints` suggests the project enforces its own lint rules rather than accepting the framework defaults.

Building means a pinned Flutter, Go and NDK container

The README does not offer a one-line build. It points to per-platform guides under `docs/builds/` for Android, iOS, Linux, macOS and Windows, which is the honest arrangement for a Flutter app that also carries native code.

What is visible is the Dockerfile, and it pins hard. The base image is `debian:13`, Go is fixed at `1.24.1`, Flutter at `3.41.9`, the Android SDK command-line tools at `13114758`, the platform at `35` and the build tools at `34.0.0`. The image tag in the build comment records the same combination along with `ndkr28` and `ruststablenightly`, which tells you that native Rust and an NDK toolchain are part of a normal build, not an optional extra.

The intended invocation is a multi-platform buildx push straight from the repository root:

docker buildx build --push --pull --platform linux/amd64,linux/arm64 . -f Dockerfile -t ghcr.io/cake-tech/cake_wallet:debian13-flutter3.41.9-ndkr28-go1.24.1-ruststablenightly

The environment is set deliberately rather than inherited. `HOME` is redirected to `/root` because the image may need to migrate a home directory later, and `ANDROID_HOME`, `ANDROID_SDK_ROOT` and a `PATH` extension covering the command-line tools, platform-tools and emulator are exported together. Locale variables are pinned to `en_US.UTF-8`.

For someone who wants to contribute a string, none of this matters. Translations live in `res/values/` as `strings_XX.arb` files, the language registry is `lib/entities/language_service.dart`, and each new language also needs a flag asset in `assets/images/flags/` at 42x26 pixels and an entry in `tool/utils/translation/translation_constants.dart`. Twenty-five languages are listed in the README.

One signing key across GitHub, Accrescent and F-Droid

Distribution is the part of this project with the sharpest operational edges, and the README addresses it head on. APK releases published on GitHub, on Accrescent and on F-Droid use the same signing key, and verification is done with apksigner or AppVerifier. The README publishes the SHA-256 signing certificate hash for the application id `com.cakewallet.cake_wallet` as a hex string beginning `C5:40:53:AB:0F:10:D9:54:17:62` and ending `:F5`.

Publishing that hash is what makes the claim checkable. Anyone can copy a certificate claim from a README; the value of the hash is that a user can compare it against the certificate on the file they downloaded. For F-Droid builds in particular, a single shared key across three distribution channels means one compromised upload path would reach all three, which is why the verification instructions exist.

Other distribution routes are listed as well: the App Store listing for Cake Wallet on iOS and macOS, Google Play under `com.cakewallet.cake_wallet`, an F-Droid listing, and for Monero.com an App Store id of `id1601990386`, a Google Play entry of `com.monero.app`, and APKs from the GitHub releases. The default branch is `dev`, so a clone tracks development rather than a release line.

The project is MIT licensed with `LICENSE.md` and `PRIVACY.md` at the root, and the last push to the repository was on 2026-10-16, with v6.5.0 tagged on 2026-10-12 after v6.4.6 on 2026-10-05.

Adding a fiat currency depends on an API you do not control

Contributing a fiat currency exposes a constraint that the translation workflow does not. The first step is to check with Cake Wallet support whether the desired fiat currency is available through the fiat API, because not all of them are. The rest is mapping: a currency strongly tied to one issuing country maps its ISO 4217 code to the matching ISO 3166-1 alpha-3 code in `lib/entities/fiat_currency.dart`, while a currency used across a region or organization is mapped with a reasonable interpretation instead.

That is a small step, but it draws a line the README does not soften. The fiat list is bounded by an external API, and the only way to extend it is to ask the project whether the provider already serves that currency. A contributor cannot add a currency unilaterally, which is a different workflow from adding a translation file.

The same shape appears elsewhere. Custom tokens on Ethereum are added by contract address, custom nodes are selected by the user rather than defaulted, and Monero trusted nodes are an explicit opt-in for sync speed. In each case the wallet defers to something outside the app, whether that is a token contract, a server the user names, or a fiat provider.

Where Cake Wallet is the wrong tool

Several concrete cases. If you need a hardware wallet signer, the README does not mention one. If you need a full node with your own Monero daemon behind it, the closest documented capability is choosing custom nodes and a proxy for Monero nodes, which is a client configuration rather than a server deployment. If you need a web wallet, the platform list is Android, iOS, macOS and Linux, and there is no browser build in it.

The built-in exchange is also the feature to think hardest about. A wallet that holds keys locally and also swaps between dozens of pairs and buys and sells with card or bank rails is a much larger surface than a receive-and-send wallet. The README does not document where that exchange routes orders, what its custody arrangement is, or what happens to a pending swap when the app is closed, so anyone uncomfortable with that indirection should read the docs at cakewallet.com before installing rather than after.

For developers, the build cost is the practical limit. A contributor who only wants to change a string can open a pull request against a `strings_XX.arb` file. A contributor who wants to build and run the app needs the pinned toolchain, and the presence of `cargokit_options.yaml` and a Rust nightly in the container image suggests native code is compiled during the build.

Editorial conclusion

Cake Wallet is the right fit for a user who wants Monero alongside several other chains in one app, or for a Dart developer who wants to work on one chain inside the cw_ packages without touching the whole product. The container-pinned Flutter 3.41.9, Go 1.24.1 and NDK toolchain add build complexity. Before adopting the code, read the platform guide under `docs/builds/` for your target, and confirm the signing story: APK releases from GitHub, Accrescent and F-Droid share one key, whose SHA-256 certificate hash the README publishes for `com.cakewallet.cake_wallet`.

Frequently asked questions

Official sources

1. cake-tech/cake_wallet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases