MyEtherWallet: client-side Ethereum wallet with offline builds

Running the MyEtherWallet development environment

For local development, the README says to complete the setup steps above and skip the production build. The development command is short:

npm run dev

The command runs the update task before starting the Vue CLI service in watch mode. The README says the application should then be running at `https://localhost:8080`. The HTTPS detail matters because a local wallet interface should not be casually treated as an ordinary HTTP development page. The documentation does not explain certificate creation, browser trust configuration, or behavior when the certificate is rejected, so those points need verification in the local environment.

The README also documents an optional Intercom integration. To enable it locally, create a `.env` file containing the following key:

INTERCOM_ID={yourIntercomKey}

The documentation says Intercom is disabled when that key is absent. Since the README's privacy claims concern MyEtherWallet's own approach, enabling an optional communication service should be treated as a separate configuration decision. The code block above is a configuration fragment rather than a command.

For npm permission errors, the README suggests changing ownership of the npm directory:

sudo chown -R $(whoami) ~/.npm

That command changes local file ownership and should be understood before it is run. The README also points developers to a specific GitHub issue comment for other setup problems, rather than providing a more complete troubleshooting matrix.

Release signatures and the MIT-licensed codebase

The project uses the MIT license, so the repository includes the license text in its root `LICENSE` file. The license grants the permissions and conditions stated by that license, including use, modification, distribution, and sublicensing subject to its conditions. This is a factual description of the declared license, not legal advice. Users who redistribute the software or bundle it with another product still need to review the license text and preserve the required notices.

Release verification is an explicit part of the documented workflow. The README directs users to download `MEW-PUP-KEY-GPG` from the repository, obtain the signed `.sig` file and matching unsigned `.zip` archive, import the public key, and verify the signature. The commands are:

gpg --import <MEW-PUP-KEY-GPG path>
gpg --verify MyEtherWallet-<version>.zip.sig MyEtherWallet-<version>.zip

The README gives `v6.9.22-hotfix.1` as its example version, while the package metadata supplied for the repository identifies version `6.9.27`. The release list also includes newer `v7.x` releases. That difference means a reviewer should select the archive and signature pair that matches the release being checked, rather than copying the example version unchanged. Signature verification establishes that the files match the signer, but users still need to obtain the correct files and assess the repository and release context.

Where MyEtherWallet differs from running a full Ethereum node

The clearest alternative described by the project is a full Ethereum node. MyEtherWallet's stated goal is to let people interact with the blockchain without running a full node. A full-node workflow instead requires operating blockchain software, synchronizing chain data, maintaining storage and infrastructure, and accepting the operational responsibilities that come with validating data locally. MyEtherWallet is intended for users who need the wallet interface but do not want to run that infrastructure.

This difference does not make the two approaches equivalent in trust or availability. The README does not specify which RPC provider, endpoint, or network data source a particular deployment uses, so it would be incorrect to claim that MyEtherWallet always verifies blockchain state independently. The project also does not document a complete node configuration or a guaranteed offline network mode.

The offline build should also be understood narrowly. The README says `npm run build:offline` creates an offline version whose `index.html` can be opened from `/dist`. It does not say that every Ethereum operation will work without a network connection, nor does it describe transaction broadcasting when no network is available. Offline generation and offline interaction are related but separate claims.

Maintenance and upgrade considerations

The repository is not archived, and its last push was on 2026-10-14. Recent releases include `v7.6.0` on 2026-10-01, `v7.5.1` on 2026-09-24, and `v7.5.0` on 2026-09-22. That release activity and recent push indicate that the repository has current development activity at the time of this review. The repository does not establish a long-term support policy or the compatibility window for every hardware wallet and chain integration.

Upgrade cost is not limited to downloading a new archive. The local development workflow uses a lockfile and an update step, and the package metadata shows separate build, lint, unit-test, and end-to-end-test commands. A developer maintaining a local fork must account for dependency changes, configuration changes, browser compatibility, and the consequences of changing key-handling or transaction-signing behavior. The README explicitly warns that `npm update` can indicate packages to update or packages to add to `package-test.js`, which makes the upgrade process a repository maintenance task rather than a single application update.

The project's own release verification workflow gives users a concrete integrity check. The GPG key and matching signed archive should be obtained from the repository's release materials. The README does not document rollback instructions, migration guidance for existing wallets, or a formal upgrade compatibility matrix, so those items are not assumed here.

Editorial conclusion

MyEtherWallet fits users who want a browser-based Ethereum interface, can keep their own keys, and need an offline build or hardware-wallet workflow. It is less suitable for someone who needs managed accounts, automatic custody recovery, or a full node's independent blockchain data. Before adopting it, verify the release signature with the repository's GPG key, inspect the generated `dist` build, and confirm that the chosen hardware wallet supports message signing, data signing, EIP1559 signing, and the required Ethereum-based chains.

Frequently asked questions

Official sources

1. License: MIT
2. MyEtherWallet/MyEtherWallet on GitHub
3. Project website
4. README
5. Releases