The polkadot-js extension, a browser signer that injects itself into a dapp

One job, stated plainly

The repository description says it is a simple browser extension for managing Polkadot and Substrate network accounts in a browser, allowing the signing of extrinsics using those accounts, and it also provides a simple interface for compliant extensions for dapps. The README is more candid about the scope. The extension injects a @polkadot/api Signer into a page along with the associated accounts, and as it stands it does one thing, it only manages accounts and allows the signing of transactions with those accounts. Two things it explicitly does not do are worth repeating because they define the boundary. It does not inject providers for use by dapps at this early point, and it does not perform wallet functions where it constructs and submits transactions to the network. The project calls itself a very simple scaffolding browser extension and an extensible POC implementation, and for an evaluator that is the honest summary: a signer and an account list, with the transport and the wallet left to somebody else.

Four packages, one entry point

The repository is split into a number of packages and the split is by role rather than by feature. The extension package holds all the injection and background processing logic and is described as the main entry. The extension-ui package holds the UI components used to build the popup. The extension-dapp package is a convenience wrapper for working with the injected objects, simplifying data extraction for any dapp that wishes to integrate the extension, or any extension that supports the interface. The extension-inject package is the counterpart for extension developers, a convenience wrapper that allows an extension to be injected for use by any dapp. There is also a manifest story. The extension directory holds manifest_chrome.json and manifest_firefox.json, one per browser for compatibility reasons, plus a dummy manifest.json that is only used by the build. That dummy file matters because the build scripts copy one of the two real manifests over it before compiling, which is how a single source tree produces two different browser packages.

Installing from a store, or from source for Firefox

For users, the extension is distributed through the Chrome web store and the Firefox add-ons site, and the README shows a screenshot of the interface. For developers working on the Firefox build from source, the instructions are more specific. You uncompress the master-ff-src.zip archive, enable corepack, install the dependencies with yarn install, and build all the packages with yarn build. The three build steps are short.

corepack enable
yarn install
yarn build

The documentation is careful about one thing, that the packages/extension/build directory will contain the exact code used in the add-on and should exactly match the uncompressed master-ff-build. If you want to regenerate the compressed master-ff-build.zip and master-ff-src.zip files yourself, there is a command for that, yarn build:zip:ff. That equality check is a useful detail for anyone automating a release, because it means the published archive and the build output are expected to be byte for byte the same thing.

Loading an unpacked build in Chrome and Firefox

The development version instructions walk through both browsers. For Chrome you build with yarn build:chrome, with a note that you may need to enable corepack first, then go to chrome://extensions, make sure the Development flag is set, and use Load unpacked pointing at packages/extension/build. After a change, you refresh the extension. For Firefox you build with yarn build:ff, go to about:debugging#addons, tick Enable add-on debugging, and use Load Temporary Add-on pointing at packages/extension/build/manifest.json, reloading the extension after each change. When you then visit https://polkadot.js.org/apps/ the extension injects itself. Once added, you can create an account with a generated seed or import an existing one, and the apps UI shows those accounts labelled with the extension, in the form of the account name followed by the word extension in parentheses. The general lesson for a dapp developer is that the extension only appears on pages that ask for it, so a local dapp on your own machine will not trigger the injection until it is pointed at the right origin.

The injected interface, as a contract

The API section is the part a dapp developer actually codes against, and the README spells it out. The Injected object returned by enable carries an accounts interface and a standard Signer interface, and a provider field that is documented as not injected as of yet, with the subscribable provider for the polkadot-js API commented out and explained as something that could be passed to the API itself on construction in the dapp. An Account carries a read-only ss-58 encoded address, an optional genesisHash that is empty when the account applies to all of them, and an optional display name. The Accounts interface has a get method returning the current list and an optional subscribe method that takes a callback and returns a function to unsubscribe. The Signer extends the Signer interface from the API and exposes the sign interface, and it communicates with the extension over sendMessage. The design goal is stated as generic interfaces rather than an all-or-nothing integration, so that several extensions can be installed at once and the user picks which one fits.

Two small wrappers, one for each side

The convenience layer is what makes the generic interface usable. From the dapp developer's side, the only work needed is to include the @polkadot/extension-dapp package and call the appropriate enabling function to retrieve all the extensions and their associated interfaces. From the extension developer's side, the only work required is to enable the extension through the razor-thin @polkadot/extension-inject wrapper, after which any dapp using the interfaces will have access to it. When more than one extension is present, each one populates its own entry through the injection interface and each is made available to the dapp, which is what allows several signers to coexist rather than one overwriting another. The approach is used to support multiple external signers in the polkadot-js apps project, and the documentation for dapp development lives in the polkadot-js docs site, with usage samples for the extension-dapp package. The practical consequence for a dapp team is that you write against the wrapper rather than against a specific wallet, and the user chooses.

The build is a rollup pipeline with two browser targets

The root package.json describes the delivery chain. The project is a yarn workspace with yarn 4.9.2 as the package manager, Node 18.14 or newer required, an ES module type with sideEffects false, and workspaces set to packages/*. The build script runs the Chrome build and then the Firefox one, and each of those copies the matching manifest file over the dummy manifest.json, runs the polkadot-dev-build-ts compiler, produces a zip archive with a distinct destination and source archive per browser, and finally runs the rollup step through polkadot-exec-rollup. The release build calls polkadot-ci-ghact-build, and there is a separate i18n step that runs the i18next scanner with its own config file, so the extension's translations are regenerated as part of the build. The repository also carries the usual scaffolding for a large TypeScript monorepo, with a rollup.config.js, four tsconfig variants, an eslint config, a prettier config, a test bundle HTML file for manual testing, and a .nvmrc for the Node version. The version in the manifest is 0.64.1, and the release tags are v0.64.0 from 2026-07-31, v0.63.1 from 2026-03-31 and v0.62.6 from 2025-11-26, with the last push on 2026-09-23. The licence is Apache-2.0, which is the permissive grant most of the polkadot-js packages use.

Editorial conclusion

The polkadot-js extension fits a dapp developer who needs the user to sign an extrinsic in the browser, and it fits a wallet team that wants its own extension to be usable by any polkadot-js dapp without modifying the dapp. It does not fit a dapp that needs a provider injected, because the README says providers are not injected at this early point, and it does not fit a user who expects a full wallet, since it does not construct and submit transactions. Verify three things before building on it: that the interface your dapp needs is one the extension actually exposes today, that your browser is one of the two the project ships builds for, and that you are reading the current interface definition rather than an older one, since the provider field is documented as commented out and the interface is still described as evolving.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. polkadot-js/extension on GitHub
4. README
5. Releases