# Trust Wallet Core: a C++ wallet engine for 130+ chains

> Trust Wallet Core is a cross-platform, cross-blockchain wallet library written mostly in C++, with strict C interfaces and bindings for Swift, Kotlin, Rust, Go, Wasm and Node. It is for teams that need signing and key management in their own app, not a finished wallet.

**trustwallet/wallet-core** — Cross-platform, cross-blockchain wallet library.

- Repository: https://github.com/trustwallet/wallet-core
- Website: https://developer.trustwallet.com/wallet-core
- Stars: 3,571 · Forks: 1,990
- Language: C++
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/trustwallet-wallet-core

## What wallet-core actually solves, and who it is for

Writing a wallet means implementing elliptic curve signing, mnemonic handling, HD derivation paths, address encoding and per-chain transaction serialization, then repeating that work for every chain you support. Trust Wallet Core packages that work as one library. The README describes it as "an open-source, cross-platform, mobile-focused library implementing low-level cryptographic wallet functionality for a high number of blockchains", and states that most of the code is C++ with strict C interfaces plus idiomatic interfaces for Swift on iOS and Java (Kotlin) on Android.

The audience is narrow and specific. This is for teams building their own wallet application, exchange withdrawal flow or signing service who want to own the UI and the backend while delegating key handling and transaction construction. The README lists Coinpaprika, crypto.com, Frontier, Tokenary, xPortal and Slingshot among projects using it. It is not for someone who wants an installable wallet. The repository contains no user interface, no node client and no broadcasting logic; those are the integrating application's responsibility.

## The C++ core and the language bindings around it

The architecture is a single C++ implementation exposed through a stable C interface, with per-language wrappers generated on top. The top-level layout reflects this: src/ holds the C++ implementation, include/ the public headers, and swift/, kotlin/, rust/, wasm/, jni/ and flutter/ hold the language surfaces. protobuf-plugin/, codegen/ and codegen-v2/ generate the glue that turns protobuf message definitions into typed calls in each target language, and registry.json plus docs/registry.md carry the chain list. trezor-crypto/ is vendored, which is worth noting if you audit dependencies.

Data flow follows the same shape in every language. The application builds a protobuf request (a mnemonic, a derivation path, a signing input), passes it across the C boundary, and receives a protobuf response. Because the request and response types are protobuf messages, the same call looks structurally identical in Swift, Kotlin or Rust; only the wrapper syntax changes. Chain-specific behaviour lives behind that boundary, so adding a chain means adding to the core and the registry rather than writing new bindings.

The CI badges in the README name the surfaces the project builds and tests on every change: iOS, Android, Linux, Rust, Wasm, Kotlin and Docker. That list is the honest statement of what is exercised. Flutter, Python and a Windows build are listed separately under Community as community-maintained projects, with an explicit note that this is not an endorsement.

## Installing wallet-core and signing your first transaction

Build instructions are not in the README; it points to developer.trustwallet.com/wallet-core/building. What the repository does provide is a Dockerfile at the top level that installs the toolchain, including clang-14, llvm-14, cmake, ninja-build, libboost-all-dev and ccache, and pins rustup to version 1.29.1 with per-architecture checksums. Building inside that image avoids reproducing the toolchain by hand.

For iOS, the README's SPM path is to download the latest Package.swift from GitHub Releases into a local WalletCore folder and reference it by path:

```swift
.package(name: "WalletCore", path: "../WalletCore"),
```

The README also allows a remote URL pointing at the master branch, but warns that it "points to recent (not always latest) binary release". If you need a reproducible build, the local path plus a pinned release is the safer of the two.

Then add both products to the target's dependencies. WalletCoreSwiftProtobuf is required, not optional, because the API is protobuf-shaped:

```swift
.product(name: "WalletCore", package: "WalletCore"),
.product(name: "WalletCoreSwiftProtobuf", package: "WalletCore"),
```

CocoaPods still works with a single line in the Podfile, though the README says it "will discontinue in the future", so new iOS work should start on SPM:

```ruby
pod 'TrustWalletCore'
```

Android is the least convenient path. Releases are hosted on GitHub Packages, so the README states you need to add a GitHub access token before you can install it, and it links to an installation guide and to the build.gradle in the Android sample. Plan for credential management in CI before you start.

The README marks three surfaces as beta: npm, Go and Kotlin Multiplatform. The npm package installs as shown, and the Go, KMP and C++ integrations each have a sample directory in samples/:

```js
npm install @trustwallet/wallet-core
```

For a first real use, the most direct route is walletconsole/, the command line tool in the repository, which exercises the same core without an app shell. The README does not document its command set, so read the tool's own help output rather than assuming flags.

## Where wallet-core is the wrong tool

The library stops at signing. It does not talk to nodes, does not broadcast transactions and does not track balances. A wallet built on it still needs an RPC provider or indexer per chain, and that is where most of the operational cost of a multi-chain wallet actually lives. Teams that assume the library covers the network layer will be surprised by how much remains.

Platform coverage is uneven. Android distribution requires a GitHub access token, which is friction in any CI pipeline and a supply-chain consideration if your build environment is shared. CocoaPods is on a deprecation path per the README. The npm, Go and Kotlin Multiplatform surfaces are labelled beta, so pinning to a specific release and testing upgrades matters more there than on the iOS and Android paths.

The chain count is a headline number, but it is a maintenance surface. Each supported chain carries its own transaction format, fee logic and address encoding, and chain upgrades happen on their own schedules. If you support a long tail of chains, you inherit the cadence of the upstream project. The release history shows frequent patch releases, which is a reasonable signal for chain fixes but also means you should have a defined upgrade window rather than tracking master.

Finally, the README's own disclaimer positions the project as led and managed by Trust Wallet. That is a governance fact to weigh: direction is set by one company, even with a large contributor community.

## How it compares with bitcoinj, ethers and web3 libraries

The closest comparison is a single-chain library such as bitcoinj. bitcoinj is a Java implementation of the Bitcoin protocol: it includes peer-to-peer networking, block and transaction handling, and wallet state, so an application can connect to the network directly. Wallet Core is the opposite trade: it covers many chains but deliberately stays out of the network layer, exposing key handling and transaction construction through a C interface. Choose bitcoinj if you are building a Bitcoin-only Java application and want the network stack included. Choose Wallet Core if you need the same signing code to run on iOS, Android, Rust and Wasm across many chains.

The second comparison is the JavaScript stack, ethers or web3.js. Those are JavaScript-first, Ethereum-first and depend on a JSON-RPC endpoint supplied by the application. They are easier to start with if your product is a web front end, and they have no native build step. Wallet Core's npm package is one of the surfaces the README marks as beta, and the core is C++ compiled to Wasm for that target, so the web path is not the project's centre of gravity. If your wallet is browser-only and Ethereum-only, ethers is the shorter route. If you need native mobile performance and a chain list that includes Bitcoin, Cosmos, Solana and BNB, the comparison reverses.

## Licence, releases and the cost of keeping up

The project is Apache-2.0, which permits commercial use, modification and distribution with the usual conditions around notices and patent grants. There is a separate LICENSE-3RD-PARTY.txt at the top level, and trezor-crypto/ is vendored, so a compliance review should read both files rather than only the root LICENSE. This is not legal advice; the point is simply that the dependency inventory is not a single file.

The release cadence is visible and frequent: 4.8.1 on 2026-09-07, 4.8.2 on 2026-09-11 and 4.8.3 on 2026-09-18, with the last push to the repository on 2026-09-18. Patch releases at that rate usually mean chain fixes and binding updates, and they are the practical argument for pinning a version rather than following master. The README's own warning that the master branch "points to recent (not always latest) binary release" is the concrete reason: a branch reference can leave you on a build that is behind the newest tagged release without any change on your side.

Upgrade cost is dominated by the protobuf boundary. Because requests and responses are protobuf messages, a field added upstream can change generated types in every language surface. Budget for regeneration and a test pass across your supported chains on each bump, not just a dependency version change.

## Conclusion

Adopt Trust Wallet Core if you are building a mobile or multi-chain wallet and want the cryptography, address derivation and transaction signing handled by a library that Trust Wallet itself depends on. Do not adopt it if you expect a runnable wallet: there is no UI, no node access and no transaction broadcasting in the repository, so you supply those layers yourself. Before committing, verify the chain you need appears in docs/registry.md, read the audit reports in the audit directory, and check whether the binding you plan to use is one of the ones the README still marks as beta.

## FAQ

### What is Trust Wallet Core?

It is an open-source, cross-platform, mobile-focused C++ library implementing low-level cryptographic wallet functionality for a high number of blockchains, with idiomatic interfaces for Swift and Kotlin. It is a core part of the Trust Wallet app and is used by other projects as well.

### Which blockchains does Trust Wallet Core support?

The README states it supports more than 130 blockchains, including Bitcoin, Ethereum, BNB, Cosmos and Solana, with the full list in docs/registry.md.

### How do I install Trust Wallet Core in an iOS project?

The README supports Swift Package Manager and CocoaPods, with CocoaPods marked for discontinuation in the future. For SPM you download the latest Package.swift from GitHub Releases into a local WalletCore folder and add both the WalletCore and WalletCoreSwiftProtobuf products to your target's dependencies.

### Why does installing Trust Wallet Core on Android need a GitHub token?

Android releases are hosted on GitHub Packages, so the README states you need to add a GitHub access token to install the dependency. It links to an installation guide and to the build.gradle in the Android sample for the exact configuration.

### Does Trust Wallet Core broadcast transactions or connect to nodes?

The repository describes the library as implementing low-level cryptographic wallet functionality, and the top-level layout contains no node client or networking layer. The README does not document transaction broadcasting as a library capability, so the integrating application supplies that.

### Is Trust Wallet Core the same as the Trust Wallet app?

No. The README describes Wallet Core as a core part of the Trust Wallet app, and the contributing section distinguishes bugs in WalletCore, which go to GitHub issues, from bugs in the TrustWallet app, which go to customer support.

## Sources

- [License: Apache-2.0](https://github.com/trustwallet/wallet-core/blob/master/LICENSE)
- [Project website](https://developer.trustwallet.com/wallet-core)
- [README](https://github.com/trustwallet/wallet-core/blob/master/README.md)
- [Releases](https://github.com/trustwallet/wallet-core/releases)
- [trustwallet/wallet-core on GitHub](https://github.com/trustwallet/wallet-core)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trustwallet-wallet-core