trust-web3-provider: a TypeScript bridge between dApps and wallets

A provider between the dApp and the wallet

trust-web3-provider is a modular TypeScript library designed to offer Web3 interfaces, enabling a wallet to connect with decentralized applications. The repository description calls it a Web3 javascript wrapper provider for iOS and Android platforms, and the architecture is drawn plainly in the README:

  +----------------+            +------------------+           +---------------+
  |                |            |                  |           |               |
  |      dApps     |  <----->   |   web3 provider  |  <----->  |  your wallet  |
  |                |            |                  |           |               |
  +----------------+            +------------------+           +---------------+

That middle box is the point of the project. A dApp wants to ask a wallet to sign a transaction or share an address. The wallet is a native application that owns the keys and cannot be loaded into a browser tab. The provider is the contract between them: a JavaScript object the dApp can call, which forwards requests to the wallet and returns responses.

The benefit is that neither side is coupled to the other. The wallet implements one interface rather than one per dApp framework, and the dApp integrates one library rather than one per wallet. For a wallet that wants to be usable across hundreds of dApps, that inversion is the whole argument, and it is why the project exists in the shape of a modular library with a package per chain rather than as a single bundled file.

The audience is therefore two-sided: wallet developers embedding the provider, and dApp developers consuming it.

Cosmos, Solana and Ethereum, each with its own standard

The README lists the supported chains with a pointer to per-package documentation: Cosmos with its own README under the cosmos package, Solana marked as fully compatible with the Wallet Standard, and Ethereum marked as EIP-1193.

Those annotations are the substantive detail, because each chain has a different convention for how a wallet should be addressed from JavaScript. Ethereum's EIP-1193 is the request-provider pattern, with a request method taking a method name and a parameter object, and it is the closest thing the ecosystem has to a common convention. Solana's Wallet Standard is a different shape, built around a wallet interface object with its own feature detection, and the README says the Solana package is fully compatible with it. Cosmos has its own address and signing model, and its package documents it separately.

The modular structure follows from that. Rather than one entry point with a chain parameter and conditional branches, the project has one package per chain, each with its own README, and the packages share a common core. A dApp that only supports Solana should not have to download Ethereum code, and a wallet that supports one chain should not carry the weight of the others.

The repository also points to a document on adding a new chain, which tells you that extending the library is an expected activity rather than a fork-and-patch affair.

A Bun monorepo with generated packages

The top level entries show the build shape: packages/ for the per-chain packages, android/ for the Android side, templates/ for scaffolding, docs/ for the guides, scripts/ for the automation, plus rollup.config.js, tsconfig.json, eslint.config.js, a .releaserc.json for semantic-release, and a .prettierrc.

The toolchain is Bun rather than the more common npm or pnpm pairing, which is visible in the scripts:

  "scripts": {
    "lint": "eslint .",
    "build": "bun build --entrypoints ./index.ts --outdir ./dist --target browser",
    "test": "bun test",
    "dev": "bun run ./scripts/link.ts",
    "build:packages": "bun run ./scripts/build.ts",
    "generate": "bun run ./scripts/generate.ts",
    "publish": "bun run ./scripts/publish.ts",
  }

Four of those deserve a note. The build target is browser, which is correct for a library whose whole job is to run inside a web page. The dev script links the workspace packages together locally, which is what makes adding a chain a comfortable loop. The generate script produces something, presumably the package scaffolding, and the templates/ directory is what it works from. The publish script is separate from the build, because publishing a package is a different risk profile from compiling it.

The root manifest is marked private, and the workspaces field points at packages/*, so each chain package is published independently. The dev dependencies list rollup with the commonjs, json and node-resolve plugins plus esbuild and rollup-plugin-esbuild, which is the standard pairing for bundling a TypeScript library that must work in a browser and in a native bridge.

Android, JitPack and the native side of the bridge

The repository carries an android/ directory and a jitpack.yml, and the topics list swift alongside blockchain, dapps and web3. The description frames the whole project as a wrapper provider for iOS and Android platforms, which tells you where the other half of the diagram lives.

The web3 provider is the JavaScript side of a conversation that a native wallet has to participate in. The wallet application, on iOS or on Android, holds the keys and the signing logic, and it exposes something to the page: a JavaScript bridge, a deep link, or an injected object. The provider library in this repository is the piece that standardises the JavaScript half of that conversation, so that a dApp written once works with any wallet that speaks it.

The jitpack.yml is the JVM side of distribution. JitPack builds a library from a repository and publishes it to a Maven coordinate, which is how an Android project would consume this code. Its presence, alongside the android/ directory, tells you the Android integration is a first-class part of the repository rather than something that lives in the wallet application repository.

The documentation directory holds the three guides a new contributor needs: CONTRIBUTING.md, USAGE.md for using the library, and ADD_NEW_CHAIN.md. Those last two are the entry points for the two audiences, a dApp developer taking the library as it is, and a wallet developer extending it with a chain.

Releases are automated and the patch cadence is high

The release record shows three tags within two days: v4.9.4 and v4.9.3 both on 2026-07-21, and v4.9.2 on 2026-07-20. The repository is not archived and the last push was on 2026-07-21, the same day as the most recent tag.

Several patch releases inside a couple of days is a fast cadence, and the automation behind it is visible. The root manifest includes semantic-release as a dependency along with semantic-release-export-data, and there is a .releaserc.json at the top of the tree, which is the configuration file semantic-release reads. The build:version script runs semantic-release in dry-run mode with NODE_ENV=production, which is how a release is checked before it happens.

The version number itself is the interesting part. It sits in the 4.9.x range, which means the project is on its fourth major line and its ninth minor line. For a library that other people's applications depend on, a major version every few years is a reasonable contract, and the patch releases inside a major line are the kind of thing you want automated rather than manual, because the alternative is a human deciding to cut a tag.

The semantic-release approach also means the commit messages decide the version bump, which places a burden on contributors to follow the format. The CONTRIBUTING.md document is where that convention should be spelled out.

The licence is the open question

The licence field on the repository is empty, and GitHub reports the licence as unknown. More pointedly, the top level entries are .gitattributes, .github/, .gitignore, .prettierrc, .releaserc.json, .vscode/, README.md, android/, bun.lockb, bunfig.toml, docs/, eslint.config.js, jitpack.yml, package.json, packages/, rollup.config.js, scripts/, templates/, tsconfig.json and yarn.lock. There is no LICENSE file among them.

That is a genuine gap for a library that other teams are expected to vendor into their applications and to redistribute through npm and JitPack. The licence on the published npm package and the licence on the repository are not the same question, and the answer to at least one of them is not visible from the tree.

The practical advice is to ask, in writing, before you build on it, and to get the answer for each distribution channel: the npm packages under the web3-provider scope, the Android artefact published through JitPack, and the Swift and Java bridge code that lives in the wallet application rather than here. This is not legal advice and does not need to be. It is the ordinary due diligence of confirming that a dependency you intend to ship is one you are permitted to ship.

Everything else about the project is legible from the repository: the architecture, the supported chains, the standards each chain package targets, the build tooling and the release process. The licence is the one thing you cannot read off the tree, which makes it the one thing worth asking about.

Editorial conclusion

trust-web3-provider suits a wallet team that wants one JavaScript interface to expose across iOS and Android, and a dApp developer who needs to support several chains without writing a client per chain. It does not suit a team that needs the licence to be unambiguous, because the licence field on the repository is empty and no licence file appears among the top level entries, and it does not suit a project that expects to add an unsupported chain without following the project's own scaffolding process. Before adopting, read docs/USAGE.md and docs/ADD_NEW_CHAIN.md, install one chain package into a test dApp and confirm the request and response shapes against the chain's own standard, and confirm with the maintainers which terms the published packages are distributed under.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. trustwallet/trust-web3-provider on GitHub