Anchor: the Antelope light wallet with local key storage and EOSIO Signing Request support

A light wallet for the Antelope chain family, not for one chain

Anchor is described in its own README as an open-source Antelope wallet, and the package.json calls it an Antelope Light Wallet with simple tools for basic activities and advanced tools for power users. The description in the repository metadata names the networks it targets: Vaulta, formerly EOS, plus WAX, Telos and other Antelope networks.

That family coverage is the point. A wallet that supports one chain can hardcode that chain's resource model, its transaction format and its node conventions. Anchor instead supports nearly every Antelope-based blockchain, with new networks added as they launch, and the repository carries a nodes.md file at the top level, which is where the chain and node configuration lives. The keyword list in package.json includes eos and eosio, and the topic list adds authenticator and wallet.

The user interface covers common Antelope functions, and the README names token transfers, resource management and governance. Resource management is the part that has no equivalent on other chains: an Antelope account holds CPU and NET resources, and a transaction that exceeds them fails unless the account delegates more or the transaction is scheduled. A wallet that surfaces that concept is doing something a generic Ethereum-style wallet cannot.

The other pieces of the feature list are about how the wallet talks to the rest of the world. Greymass Fuel integration provides limited free CPU and NET resources to every account on compatible networks, which is a sponsored relay service rather than something the wallet itself implements. EOSIO Signing Request support lets external applications ask Anchor to sign, which turns the wallet into a signing provider for dApps.

The primary language is JavaScript, the licence is MIT, and the default branch is dev.

Local AES-256 key storage, and the Ledger option

The security claims are stated in one bullet and they are the ones to scrutinise.

The README says keys are stored locally using AES-256 and that your private keys never leave the wallet. For an Electron wallet, that is the meaningful distinction, because the alternative architecture, where a web service holds or proxies keys, cannot make the same statement. Anchor is a desktop application that runs on your machine, keeps the key itself in its own local storage, and encrypts it at rest.

The second bullet is optional integration with Ledger hardware wallets for additional key security. Optional is the operative word, and it marks a design choice: the hardware wallet path is an alternative to the software key path rather than a requirement. A user without a device uses the locally encrypted key, and a user with one can move signing to a separate piece of hardware where the private key never enters the desktop environment.

That combination is what makes Anchor a plausible option for a user who holds meaningful balances and also a plausible option for one who does not, which is why both audiences are in scope. It is also the reason the wallet can sit next to EOSIO Signing Request integration: the signing request flow is a case where an external application asks for a signature and the wallet, and optionally the hardware device, is the one that decides.

The repository layout backs the claim of a full application rather than a thin wrapper. There is an app directory for the application code, internals for shared internals including a scripts directory, build and resources directories, docs, flow-typed, and a set of webpack configuration files for the main process, the renderer and the development DLL build. The renderer is the visible UI and the main process is the privileged side that touches the filesystem and the network, and the separation between the two is standard Electron practice.

EOSIO Signing Request, and what it changes for dApp users

The EOSIO Signing Request protocol is the feature that moves Anchor from being a standalone wallet to being part of a larger system, and it deserves its own section because it changes what a user does.

Without it, a dApp on an Antelope chain has to ask the user to open their wallet, find the right account, copy a payload into a text box and paste it back. The signature request protocol replaces that with a flow in which the dApp hands the wallet a structured request and the wallet returns the signed payload. The README calls this rich integration with external applications, and the repository for the protocol is linked from the feature list.

The topics attached to the repository include eosio-signing-request and authenticator, which is the terminology used for a wallet in that role. A wallet acting as an authenticator takes a request from an application, shows the user what is being asked for, and signs it if the user approves.

There is a design consequence worth naming. Once a wallet can sign on behalf of another application, the approval step is the security boundary. The wallet has to show the user what the request actually does, and it has to be careful about requests it does not understand. The README's feature list does not describe how the approval interface works, and the documentation site at anchorwallet.io is where a user would look for that detail.

The interesting pairing is Anchor with Greymass Fuel here. Fuel provides free CPU and NET resources to every account on compatible networks, so a request that arrives through an external application can be sponsored by the relay without the user spending anything, and the wallet is the part that still has to get the signature right.

Downloading it, and the signature check the README insists on

The README is unusually direct about where to get the application, and the reason is credential theft rather than ordinary caution.

It urges all users to only download Anchor from one of two locations: the download page at anchorwallet.io/download, or the README and releases section of the repository at github.com/greymass/anchor. When downloading from either location, it says to check the URL bar of your browser to ensure you are in the correct place and not visiting a phishing link. For a wallet that holds spendable keys, a fake download page is a direct path to a drained account, and the instruction to check the URL bar is aimed at exactly that.

The current release is v1.4.0, and the README lists four artefacts for it: a Windows Installer, a macOS Package, a Linux deb and a Linux AppImage. The per-OS instructions are given as well, so a macOS user opens the DMG and drags the Anchor icon into Applications, a Windows user runs the EXE installer, and a Linux user picks either the AppImage or the DEB.

The verification step is the part most download pages omit. The README says all releases on GitHub will have shasum256 hashes signed by jesta on keybase, and that if these signatures do not match, it is possible you have obtained a release not published by the Greymass team. The repository carries a shasum.sh script at the top level, and the bump script in package.json touches shasum.sh along with package.json, the app package and the locale files, so the hashes are updated as part of the release process rather than by hand afterwards.

The last push was on 2026-10-17, and the release history shows v1.4.0 on 2026-09-18 after a long gap from v1.3.12 and v1.3.11, both dated 2023-06-27. That gap is worth noting: the project was quiet for roughly three years and then shipped a new major line, so anyone on the older builds should treat v1.4.0 as a jump rather than a routine update.

Building from source, and the Node version mismatch in the docs

The README documents building the application yourself, and the steps are Electron build steps rather than library installation.

First the repository is cloned and dependencies are installed at the root and in the app directory.

git clone https://github.com/greymass/anchor.git anchor
cd anchor
nvm use v14
yarn --frozen-lockfile --ignore-engines
cd app
yarn --frozen-lockfile
cd ..

Then the packaging step depends on the host operating system, with npm run package-mac on MacOS, npm run package-linux on Linux and npm run package-win on Windows. The README states the constraint plainly: you currently must build the binary for the desired operating system on that operating system, with Windows builds built on Windows and macOS on macOS. After the build completes, the files are located in the releases folder within the project folder.

The development mode sequence is a separate block, and it starts with a build-dll step before installing dependencies.

git clone https://github.com/greymass/anchor.git anchor
cd anchor
nvm use v13
yarn build-dll
yarn --frozen-lockfile
cd app
yarn --frozen-lockfile
cd ..
npm run dev

Here the documentation and the repository disagree, and the discrepancy matters. The README tells you to use Node 14 for packaging and Node 13 for development, while the engines field in package.json requires Node 22.12.0 or later. The build scripts also set NODE_OPTIONS=--openssl-legacy-provider, which is the flag used to work around the OpenSSL 3 change that removed algorithms older webpack and babel dependencies rely on. In other words, the README's node version guidance is stale relative to the current package metadata, and the build-dll step with the legacy provider flag is the part that is actually load-bearing for the older toolchain.

Other details of the setup show up in the file list. There is a .nvmrc pinning a Node version, babel.config.js, an .eslintrc with a separate eslint webpack configuration, a .stylelintrc, a .prettierrc, and a .flowconfig with a flow-typed directory, so the project carries Flow type annotations alongside TypeScript-era tooling. The crowdin.yml file at the top level indicates that the interface translations are managed through Crowdin.

How Anchor compares with the other ways to hold Antelope assets

Two alternatives cover most of the ground, and each differs from Anchor in a way that comes down to where the keys live.

The first is the web wallet route. A browser-based wallet served from a site holds nothing on your machine and asks you for a private key to import, or hosts the key for you. That removes the local storage question entirely and makes the wallet available anywhere, but it moves the trust boundary to the server and to the site, and an import of a raw key into a web page is exactly the flow that phishing pages are built to exploit. Anchor's insistence on two download locations and a signed shasum256 hash is the direct answer to that risk, and a user who distrusts handing a key to a web page is the user this wallet is for.

The second is the command line. On Antelope chains, keosd and the cleos client have long handled key management and transaction signing for users who do not want a GUI. The difference is scope rather than principle. cleos is a general purpose client for chain operations, which means it also covers node administration, deploying contracts and querying chain state, at the cost of an interface that has to be learned rather than clicked. Anchor is the option for a user who wants token transfers, resource management and governance without a command line, and who accepts that advanced chain operations are not its job.

There is a third route that overlaps with Anchor: hardware wallet plus a lightweight client. A Ledger device can sign for a web interface, which gives the hardware security without a desktop application, and the README's optional Ledger integration means Anchor is not the only way to reach that combination. The reason to prefer Anchor is the bundled experience: the ESR signing request, the resource management screens and the per-network configuration in one place, rather than a signing device plus a separate front end for each dApp.

None of these comparisons makes Anchor the right answer for everyone. It is a desktop application for a specific chain family, and the honest boundary is that the ecosystem it serves is narrow while the feature set inside it is broad.

Editorial conclusion

Anchor fits a desktop user who holds Antelope chain assets and wants keys encrypted locally with the option of a hardware signer, and it does not fit a mobile user or anyone needing a web wallet, since the release artefacts listed in the README are a Windows installer, a macOS package and two Linux builds. Before installing, download only from anchorwallet.io/download or the releases page of the repository, and confirm the shasum256 signature against the key published by jesta on keybase, because the README states that a mismatch means the release did not come from the Greymass team.

Frequently asked questions

Official sources

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