# Taho Extension: a community-owned Web3 wallet built as two packages

> Taho is a browser extension wallet whose repository splits trusted key-handling code from untrusted popup UI, and whose last push was on 2026-08-24. Here is how it installs, how the build works, and where it stops being the right tool.

**tahowallet/extension** — Taho, the community owned and operated Web3 wallet.

- Repository: https://github.com/tahowallet/extension
- Website: https://taho.xyz
- Stars: 3,204 · Forks: 427
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/tahowallet-extension

## What Taho is and who the repository is written for

Taho is a Web3 wallet distributed as a browser extension. The README frames the project against a single dominant wallet and a single infrastructure provider owned by one conglomerate, and argues that this concentration undermines Ethereum's censorship resistance. That framing is the product's pitch, and it tells you who the code is for: people who want to run a wallet they can inspect and rebuild themselves, and developers who intend to modify it.

The repository is not a library you import. It is an application you build. The package.json marks it as private, the main entry is index.js, and the scripts are all build, lint, test and release tooling. If you are looking for an npm dependency that adds wallet connectivity to your own dapp, this is the wrong shape of project. If you want to install a wallet, the distribution channel is the browser extension directories, and the source build exists for contributors and for people who prefer not to trust a store binary.

## The two-package split: trusted background versus untrusted ui

The most interesting design decision in the repository is structural. The README states that the extension is built as two packages, background and ui. The background package holds the extension's background script and the ui package holds the code powering extension popups. These are separate packages specifically to separate their threat models: ui is treated as untrusted code, background is treated as trusted code.

The consequence is a rule about key material. Only background should interact with key material regularly, and ui should reach it only through a carefully maintained API. That is a real constraint on anyone writing a feature, because it means a popup screen cannot simply read a private key. The README also says background is intended to minimize external dependencies, with dependencies generally version-pinned and yarn used to verify build integrity. The supply chain argument is explicit: fewer dependencies in the trusted package means less surface for an attack through a transitive package.

There is a cost to this that the documentation does not discuss. Every new capability that touches keys needs an API boundary, a message type and probably a validator, so a feature that would be trivial in a single-package extension becomes a cross-package change here. That is the trade the maintainers chose, and it is defensible, but it is slower to build against.

## Installing Taho and running a first build

The README's quickstart is a source build, not a store install. It assumes nvm, then yarn. The comments in the README note that yarn install may hit scrypt node-gyp failures and can be rerun with --ignore-scripts if it does.

```bash
nvm use
nvm install
npm install -g yarn
yarn install
yarn start
```

The yarn start script runs a continuous webpack build that auto-updates on changes. Once it is running, the README says the bundles for each browser land in dist/<browser>, and you load them through the browser's own developer flow: the Firefox temporary installation instructions, or the Chrome developer-mode instructions, substituting brave://extensions, edge://extensions or opera://extensions as appropriate.

By default the build rebuilds for every browser on each save. The README shows how to narrow that, which matters on a slow machine:

```bash
yarn start --config-name firefox
yarn start --config-name chrome
```

On some Linux distributions, including Ubuntu 20.04, the README says you must point npm at your python3 executable first:

```bash
npm config set python /usr/bin/python3
```

For a production bundle the script is yarn build, which the README says writes a ZIP per browser bundle under dist/. There is also a Dockerfile that builds from node:16-alpine, copies .env.prod to .env, sets SUPPORT_BROWSER to firefox, and copies the resulting dist directory into a scratch stage. Note that the Dockerfile runs yarn install with --frozen-lockfile followed by || true, with a comment that a sqlite compile error during install does not cause problems. That is a deliberate decision to swallow an install failure, and it is worth knowing before you trust a container build.

## Validators, CSP and why the schema files exist

The README has a short section on validators that is easy to skip and expensive to ignore. To add or change a validation function you write the schema in a .ts file for typing, register the schema with the validator function name in generate-validators.ts, update jtd-validators.d.ts or json-validators.d.ts with the type definition, and run yarn run generate:validators. Then you import the generated validator.

The stated reason is specific: this setup exists so the project does not need to include unsafe-eval in its Content Security Policy. A browser extension that compiles schemas at runtime would need unsafe-eval, which widens what injected code can do. Generating validators at build time removes that need. It is a small example of the same instinct as the background/ui split: move work to build time so the runtime surface stays narrow.

The practical consequence is that validator changes are a multi-file edit plus a code generation step, and forgetting the generation step leaves your typing and your runtime validator out of sync. The README does not describe what happens when they drift.

## Local chain, commit signing and the release process

For development against mainnet behaviour, the README points to dev-utils/local-chain/README.md and gives a quick start of cd dev-utils/local-chain, yarn install, yarn start. That gives you a local fork to test against rather than spending real funds.

Commits on the repository must be signed. The README is blunt: no pull request will be merged if it has unsigned commits, and it links to GitHub's documentation on commit signature verification. On macOS, scripts/macos-setup.sh installs Homebrew dependencies and sets up pre-commit hooks; elsewhere you install jq, nvm and pre-commit yourself and run pre-commit install. If you skip that, your first pull request is likely to fail on hooks you never ran.

Releases go through yarn version. The README shows yarn version --patch and yarn version --minor. Bumping a version ensures the commit is on the correct release-<new-version> branch for review, attempts to switch you to a branch based on the latest origin/main if you are elsewhere, synchronizes the extension manifest version to the package version, and commits, tags and pushes. The README notes that major releases generally need more discussion than this automation allows, though they can be managed the same way. After the branch is pushed you open a pull request, which may trigger automated submission of the new version to extension directories. The repository's most recent release listed is v0.66.0 from 2026-01-19, and the last push to the repository was on 2026-08-24.

## Where Taho is the wrong tool

Taho is a browser extension. The README describes no mobile client, no hardware wallet integration, no hosted or custodial option, and no server-side component you could run instead. If your users are on phones, or if your organisation wants a wallet that lives behind an SSO and an admin console, this project does not offer that shape.

The build path is also a real constraint. You need nvm, yarn, and on some Linux distributions an explicit npm python config before yarn install will complete. The README itself anticipates scrypt node-gyp failures and offers --ignore-scripts as a workaround, which means some environments will not get a clean install without skipping install scripts. The Dockerfile goes further and tolerates a failed install outright. Anyone expecting a one-command container build should read that file before assuming the image is reproducible in their environment.

Finally, the licence is GPL-3.0, and the repository carries LICENSE, LICENSE-GPLv3.txt, LICENSE-additional-terms.txt and LICENSE.txt. Additional terms alongside GPLv3 are not the same as plain GPLv3, and the README does not explain them. If you plan to fork Taho into a product, read those files with your own counsel rather than assuming the top-level license field tells the whole story.

## How Taho differs from MetaMask in approach

The README names MetaMask directly and frames Taho as an answer to it, so the comparison is the project's own. The stated difference is ownership and infrastructure: the README argues that one wallet and one infrastructure provider under one conglomerate undermine Ethereum's censorship resistance, and positions Taho as community owned and operated.

The engineering difference visible in the repository is the package split. Taho separates background and ui into distinct packages with distinct trust assumptions, confines key material to background, and keeps background's dependency list deliberately small with pinned versions. MetaMask's architecture is not described in this material, so the honest statement is that Taho documents its own threat model in the README and MetaMask's is not part of what this repository tells you. If the trust boundary is the reason you are evaluating Taho, that section of the README is the part worth reading closely, and the LICENSE-additional-terms.txt is the part worth reading before you build on it.

## Conclusion

Adopt Taho if you want a browser wallet whose key material is confined to a background package and you are willing to build from source with yarn start, or if you are contributing to a GPL-3.0 codebase that requires signed commits. Do not adopt it if you need a hosted wallet, a mobile app, or a wallet with a documented rollback path, since the README does not describe one. Before you commit, verify three things in the repository: which browsers your build actually targets under dist/<browser>, whether the BOAR_RPC_URL_* variables in .env.example cover the chains you need, and whether pre-commit install has run, because unsigned commits will not be merged.

## FAQ

### How do I install the Taho extension from source?

Run nvm use, nvm install, npm install -g yarn, yarn install and yarn start, then load the bundle from dist/<browser> through your browser's developer extension flow. The README links to Firefox temporary installation instructions and to Chrome developer-mode instructions that also work for Brave, Edge and Opera with the matching scheme.

### Why does Taho split background and ui into two packages?

The README states the split exists to emphasize the difference in attack surface and separate the threat models: ui is considered untrusted code and background is considered trusted code. Only background should interact with key material regularly, and ui reaches it through a maintained API.

### What licence does the Taho extension use?

The package.json declares GPL-3.0, and the repository also contains LICENSE, LICENSE-GPLv3.txt, LICENSE-additional-terms.txt and LICENSE.txt. The README does not explain the additional terms, so read those files directly if you intend to fork.

### Does the Taho repository require signed commits?

Yes. The README states that commits on the Taho repository are all required to be signed and that no pull request will be merged if it has unsigned commits. The macOS setup script installs pre-commit hooks for you; elsewhere you run pre-commit install yourself.

## Sources

- [License: GPL-3.0](https://github.com/tahowallet/extension/blob/main/LICENSE)
- [Project website](https://taho.xyz)
- [README](https://github.com/tahowallet/extension/blob/main/README.md)
- [Releases](https://github.com/tahowallet/extension/releases)
- [tahowallet/extension on GitHub](https://github.com/tahowallet/extension)

---

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