Fuel Wallet: the browser extension wallet for the Fuel network

A wallet extension for the Fuel modular execution layer

Fuel Wallet is the official wallet of Fuel, described as a modular execution layer, and it is written in TypeScript. The published product is a browser extension, and the project's own documentation says the wallet is used to access assets and to interact with decentralized applications through that extension. The home page is wallet.fuel.network.

That puts it in a specific category. It is not a general purpose key manager with plugins and hardware support, and it is not a hosted web account. It is one wallet for one chain, shipped as an extension, with a matching SDK so that DApps on Fuel can talk to it through a documented request model.

The build system reflects a larger organisation than a single extension. The repository is a pnpm workspace with members under ./packages/*, driven by turbo, with packages/ for the code, docs/ content behind the site, an examples/ directory holding a create-react-app DApp example, and a Forc.toml and fuel-toolchain.toml pair, which is the Sway toolchain configuration for the smart contract side of the Fuel ecosystem.

Two distribution channels exist. The stable one is documented at https://wallet.fuel.network/docs/install/. A separate developer build lives at next-wallet.fuel.network/docs/install/, and the project is explicit that this version is made for developers and can be unstable or buggy.

What the feature list actually covers

The documented feature set is long enough to be worth reading closely, because the shape of it says what kind of wallet this is.

Account handling covers creating a new account from a mnemonic phrase, recovering an account from a mnemonic phrase, and, under Accounts, listing all accounts, adding a new one, updating an account name, and creating an account from a PrivateKey. Balances can be checked, and networks can be managed, with a faucet for testnet.

DApp integration is the other half. The wallet can request connection, list accounts, sign messages, send transactions, and disconnect applications, and the Applications section lists connections and removes them. Transactions cover receiving assets by address or QR Code, sending assets to another wallet, transaction history, and viewing transaction details.

Two entries deserve a deliberate reading. Settings includes both "Reveal your passphrase" and "Export account privateKey". They are ordinary features in a self-custody wallet, where the recovery phrase has to be recoverable by the owner, but they are also the exact capabilities that make a compromised extension costly, and the project does not describe any hardware wallet, multisig, or key isolation mechanism anywhere in the documentation.

That silence is worth noting. The README does not mention hardware wallet support or account abstraction, so a team whose security model depends on them should confirm before adopting.

The Wallet SDK contract that Fuel DApps code against

For a developer, the SDK is the part that matters most, and it is documented separately from the wallet itself at https://wallet.fuel.network/docs/dev/getting-started/.

The documentation is organised around the operations a DApp performs, and the table of contents in the README lists them: a quickstart, then request connection, list user accounts, sign a message, transfer assets, and finally an SDK API reference. Each of those pages corresponds to a capability the wallet advertises, so the two halves line up. A DApp asks to connect, enumerates the accounts the user approved, requests a signature over a message, or asks the wallet to send a transaction, and the user can revoke access through the Applications list.

The API reference page is the contract. That is where a DApp developer finds the exact request and response shapes, the error cases, and any version specific behaviour, and it is the page to read before writing code rather than after.

The repository keeps its own contribution guides under the same site, with a contribution guide and a running locally guide. So the documentation set covers three audiences: end users installing the extension, DApp developers integrating the SDK, and contributors working in the monorepo.

A turbo monorepo with changesets driving releases

The build is a pnpm workspace with turbo as the task runner, and the scripts in the root package.json show the shape of it:

"build:website": "node ./scripts/build-website/index.mjs",
"build:web": "turbo run build:web",
"build:crx": "turbo run build:crx",
"build:all": "turbo run build:all",
"build:docs": "turbo run build:docs"

The names matter. build:crx is the browser extension, build:web is the web app, build:docs is the documentation site, and build:website is a standalone script that assembles the docs, the app and Storybook into one bundle. The dev scripts mirror them:

"dev": "./scripts/dev.sh",
"dev:docs": "./scripts/dev.sh --docs",
"dev:crx": "./scripts/dev.sh --crx",

The toolchain is pinned tightly. The engines field requires node 24.x and pnpm >=9, the packageManager field names [email protected], and there is a.nvmrc and a.tool-versions file in the tree. Linting and formatting run through biome.json rather than the ESLint and Prettier combination the file listing might suggest, and.husky/ with.lintstagedrc covers commit hooks.

Releases are managed with changesets. The scripts cover creating a changeset, versioning with and without a docs update, publishing, and a changeset:next flow, and changeset:check compares status against the master branch. The.changeset/ directory at the top level is where pending changes are recorded, which tells you the release process is driven by committed change records rather than by hand edited version numbers.

The website ships as a Docker image served by nginx on Railway

The web side of the project is deployed from a root Dockerfile, and the image is a two stage build. The first stage compiles with Node, the second serves the result:

FROM node:24-bookworm-slim AS build
RUN npm install -g [email protected]
RUN pnpm install --frozen-lockfile
RUN pnpm build:website
FROM nginx:1.27-alpine
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 80

The build stage installs the system packages python3, make and g++, which points at the native modules in the dependency tree, and it sets NODE_OPTIONS=--max-old-space-size=6144, so the site build expects up to 6 GB of Node heap. Public configuration is passed in as build arguments, including NEXT_PUBLIC_URL, NEXT_PUBLIC_CURRENT_ENV, NEXT_PUBLIC_WALLET_DOWNLOAD_URL, NEXT_PUBLIC_WALLET_INSTALL, the Algolia search keys, and the VITE_CRX_NAME and VITE_CRX_RELEASE values used by the extension build. The runtime stage copies docker/nginx.conf into the image and exposes port 80, with a health check that polls the site every 30 seconds.

Deployment follows a simple branch rule: Railway deploys the release branch, and shipping website changes means merging master into release. The default branch of the repository is master, and .railwayignore, railway.json and .dockerignore sit at the top level for that pipeline. For a team that wants to run the site itself, this Dockerfile is a complete and self-contained starting point.

Running the wallet locally from the monorepo

Local development is documented on the running locally page, and the root scripts are the entry point. pnpm dev runs scripts/dev.sh with no arguments, pnpm dev:docs runs the same script with the docs flag, and pnpm dev:crx runs it with the extension flag. There is also a dev:e2e-contracts mode, and the root package.json declares workspaces of ./packages/*, so a pnpm install at the repository root links the workspace packages together.

The prerequisites are explicit: Node 24.x and pnpm 9 or later, with [email protected] as the declared package manager. A .nvmrc and a .tool-versions file are committed so the versions can be read rather than guessed.

Two practical notes for anyone trying this. First, the build scripts for the site and the extension are separate, so a change to the extension does not require the full website pipeline, and the reverse is also true. Second, the Docker build deliberately sets PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 and NODE_ENV is only switched to production after the install, with a comment in the Dockerfile explaining that devDependencies hold the build toolchain, so turbo, next and vite. A local install that reproduces the container's behaviour needs the same ordering.

The Sway toolchain is a separate dependency from the JavaScript one. Forc.toml and fuel-toolchain.toml in the root are the configuration for compiling contracts, which the examples/ directory exercises with a create-react-app DApp.

Apache-2.0 terms, a version gap, and the not production ready warning

The licence field on the repository says Apache-2.0, and the README states the same with a pointer to the LICENSE file. For a DApp team that only calls the SDK, and for a company that wants to ship a wallet interface, the permissive terms with an explicit patent grant are the low friction choice, and they are the reason this project is a more realistic dependency than a permissively unlabelled alternative.

The version history needs reading carefully. The recent releases are v0.63.0 on 2026-02-19, v0.62.3 on 2026-02-04 and v0.60.0 on 2026-01-20, while the last push was on 2026-10-19 and the repository is not archived. The tree is therefore moving faster than the tag list, which is normal for a changesets based project, but it means the published version a user installs may be many months behind the code in the default branch.

The most important line in the README is the warning at the top: the project is under active development, some features are not implemented or can present bugs and issues, and it should not be treated as a production ready wallet. That sentence should govern the adoption decision more than any feature list. A browser extension that holds a mnemonic phrase, can reveal the passphrase and can export a private key is exactly the kind of software where a partially implemented feature is a loss scenario rather than an inconvenience, and the project is telling you so in its own words.

The next-wallet.fuel.network build is the one to avoid for anything real. The documentation describes it as made for developers and warns that it can be unstable or buggy, which makes it a testing environment rather than a release candidate.

Editorial conclusion

Fuel Wallet is the sensible choice for anyone building on the Fuel network, since it is the official wallet, it ships the SDK that DApps connect through, and its Apache-2.0 licence keeps it safe to depend on from a commercial product. It is the wrong choice for holding value you cannot afford to lose, because the project states plainly that some features are not implemented or can present bugs, and a browser extension holds a mnemonic phrase and a private key export. Verify the extension build you install is the one you expect, check the version you pinned against the releases list, and read the install page at wallet.fuel.network/docs/install/ before you import a real account.

Frequently asked questions

Official sources

1. FuelLabs/fuels-wallet on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases