# AWallet is an open source Algorand wallet where the key never leaves the browser

> AWallet is a Vue 3 wallet for Algorand built on the JavaScript SDK, with multisig accounts, rekeying, WalletConnect and a peer-to-peer Liquid Auth path. It has been open source since 2021, ships as a static HTML and JavaScript bundle, and runs under AGPL-3.0.

**scholtz/wallet** — Open source algorand wallet and algorand web tools - governors tools, payment gateway, ..

- Repository: https://github.com/scholtz/wallet
- Website: https://wallet.biatec.io
- Stars: 663 · Forks: 36
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/scholtz-wallet

## A community wallet, open source since 2021, with the source on GitHub

AWallet is an Algorand community wallet, built by community for community, fully open source since 2021. The repository description is broader still, calling it an open source Algorand wallet and Algorand web tools, with governor tools and a payment gateway among them.

That framing matters for a wallet. Most wallets are closed, and the reasoning is usually commercial rather than technical: whoever holds the keys holds the liability, and the code that decides what to sign is a place an attacker wants to look. A wallet that publishes its source is making a different argument, that a user should be able to check what signs their transactions rather than trust that it does the right thing.

The source is at github.com/scholtz/wallet, the technology stack is Vue3 with the JavaScript AlgoSDK, and the project also describes a CI/CD path to pure HTML and JS. That last part is a deliberate constraint. The build produces static files that run without a backend of its own, which means the wallet can be served from a CDN, from GitHub Pages, or from a page of your own, and the signature operations happen in the browser.

The licence is AGPL-3.0, which is the strong copyleft variant. For a wallet that is the right default, since it means anyone running a modified version as a service must also publish their modifications. The repository carries a LICENSE.md, a SECURITY.md, a CHANGELOG.md, a Voting.md, and an audits directory, which is a fairly complete set of governance and assurance artefacts for a project of this size.

## Key management: import, export, destroy, and an Algo25 Shamir backup

The feature list starts with the operations that determine whether a wallet is usable at all.

Creating a wallet, exporting a wallet, importing a wallet, and destroying a wallet are all supported. Export is the one that deserves attention, because a wallet that can export its secret key is a wallet whose security depends on the user's storage discipline rather than on the software. The project does not pretend otherwise, and it pairs export with a backup mechanism: Algo25 Shamir backup, which splits the secret into shares that can be reassembled.

The rest of the account model covers creating an account, creating a multisign account, and adding a public account. Account overview and transaction overview are the two read views, which in practice means the wallet shows what you hold and what has happened to it.

Payment operations cover sending algo payments and signing and sending multisig payments. That last one is the reason a multisign implementation is worth the trouble: in a multisig account the transaction has to be signed by more than one key, and the wallet handles creating and submitting the transaction while the individual signers each authorise it. A wallet that cannot do this forces you to move funds out of the multisig account and into a single signature account to spend anything, which defeats the purpose of having a multisig account.

The multilingual support is worth a mention because it is a wallet feature rather than a translation feature. A wallet used by people who are not comfortable in English has to work in their language, and this one ships locale files with a dedicated check script for them.

## Rekeying across standard, multisig and already rekeyed accounts

Rekeying is the least familiar feature on the list and the most Algorand specific.

Rekeying of standard accounts, multisig accounts and rekeyed accounts is supported. The third case is the interesting one. In Algorand, an account can be rekeyed so that a different key can sign on its behalf, which is how delegation and account takeover recovery work. Once an account is rekeyed, the original account key is no longer the one that authorises spending, and rekeying a rekeyed account is how you undo that and restore control.

A wallet that only supports rekeying a standard account leaves a gap: you could set up delegation, but you could not take it back, and you could not do it for an account you had already rekeyed by other means. Supporting all three cases means the wallet can act as a recovery tool as well as a setup tool, which matters when a key has been rekeyed somewhere else.

This is also where the difference between AWallet and a general purpose wallet shows. The rekeying case is not exotic in Algorand, and a wallet that leaves it out pushes the user to a command line tool. The trade-off is that rekeying is an irreversible operation in the sense that it changes who controls the account, so a wallet that offers it must present it carefully, and the audit trail in the transaction overview becomes the record of what happened.

## Two DApp connection paths, WalletConnect and Liquid Auth

The wallet connects to DApps in two ways, and the difference between them is the most interesting design decision in the project.

The first is WalletConnect, the familiar relay based pairing where a session is brokered through a server and the two sides talk over it.

The second is Liquid Auth, documented in the project under docs/LIQUID_AUTH.md, and described as passkey-linked, peer-to-peer WebRTC, with ARC-0001 and ARC-0060 signing. Read that carefully. A passkey linked connection means the authorisation is bound to a device credential rather than to a shared key in a browser storage. Peer-to-peer WebRTC means the session does not need a relay server sitting in the middle of it. The two arc numbers refer to Algorand Request Comments, which is how the signing request is framed.

So the wallet offers a conventional path and a path that removes the relay and the shared secret from the trust model, and the second one exists in the same codebase alongside the first. That is a genuine alternative rather than a naming exercise.

The interesting engineering question is why both are there. Liquid Auth requires passkey support in the browser and a peer connection that has to be established, which is more demanding than a pairing code. WalletConnect works everywhere a browser does. Supporting both means the wallet can offer the stronger model where it is available and still function as a normal Web3 wallet where it is not, and it means a DApp developer can support the wallet without caring which path a user picks.

## Vue 3 and the JavaScript AlgoSDK, built to static files

The technology stack is Vue3 and the JavaScript AlgoSDK, and the deployment story is a continuous integration pipeline that ends in pure HTML and JS.

The package manifest shows how the project is built and checked. The build runs a type check and then the bundler:

```json
    "build": "vue-tsc --noEmit && vite build",
```

Vite is the bundler and vue-tsc is the Vue aware type checker. The dev and serve scripts both point at vite, and there is a separate server script that runs browser-sync against a config file called bs-config.js, so the development loop is a live-reloading server rather than a static file.

The test story is worth noting because it tells you what the project considers a regression. There is a playwright directory with playwright.config.ts and playwright.unit.config.ts, a run-app-for-test script that starts the dev server on port 8080, and a test script that runs the unit tests and then the playwright tests. Browser-level tests against a wallet are the only kind that would catch a broken signing flow, and running the app on a fixed port for the test runner is the standard way to make that repeatable.

There are also two type check scripts, one with tsc and one with vue-tsc, and a check-locales script that builds the scripts and then runs scripts/check-locales.js, which validates that the translation files are consistent. The scripts have their own tsconfig at tsconfig.scripts.json, which means the build tooling is type checked separately from the application code.

The package manager is pinned to pnpm at 11.10.0, and the repository has a pnpm-workspace.yaml alongside the lock file, so the project uses pnpm workspaces.

## Deployments: a stable on-premise instance and a set of main branch previews

The wallet is deployed in several places, and the project is clear about which one to use.

The recommended deployment is wallet.biatec.io, described as the most stable deployment, running on a private onprem Kubernetes cluster run by Scholtz and Co, with the Docker image released after some time in the main branch deployment. So the stable domain trails the main branch: fixes land on main, and the stable instance picks them up after a delay.

There is also a deprecated environment at a-wallet.net. The text says the biatec wallet has been started under the brand name AWallet, and that under this domain is the same deployment as under the biatec domain with most stable deployment, and that this environment is deprecated with wallet.biatec.io the preferred domain. The project description calls the deprecated domain the biatec wallet and the newer one the AWallet wallet, which is a naming inconsistency worth being aware of when you are following documentation.

Then there are the main branch deployments, which are previews of unreleased code:

- main.h3.a-wallet.net, a private onprem Kubernetes cluster run by Scholtz and Co
- ww2.a-wallet.net, built by GitHub and hosted on GitHub Pages
- vercel.a-wallet.net, built and hosted by Vercel
- awallet.vercel.app, built and hosted on a Vercel domain

That list is the clearest statement of what this project is. A wallet that runs as static HTML and JavaScript can be deployed to GitHub Pages or Vercel with no server of its own, and the project exercises exactly that by hosting the main branch in four different ways.

The Docker image is published as scholtz2/a-wallet on Docker Hub, and the repository has a docker directory, a k8s directory, an index.html, and a public directory for static assets.

## What the project does not claim, and where it stops

Several things a prospective user would want are simply not stated, and their absence is informative.

There is no stated claim about which browsers are supported, no stated minimum Algorand node requirement, no description of how the wallet obtains the network information it needs, and no account of what happens when a DApp asks for a signature the user does not understand. There is also no stated key custody model beyond the feature list, so whether the secret key is held in browser storage, in an encrypted local store, or in a passkey credential varies by path without the project spelling it out.

For a wallet, that gap matters more than it would for, say, a linter. The failures here are not cosmetic. A wallet that cannot be audited by its users because the storage story is undocumented is asking for trust it has not earned, and the fact that the source is available does not fully compensate.

Two further limitations are structural. The AGPL-3.0 licence means a commercial fork that is offered as a service has to publish its changes, which is the intended effect but does narrow who can adopt it. And the deployment model means the wallet you use is a static site, so updates arrive when the page reloads, which is convenient but also means a user can be running an old build for a long time without noticing.

The comparison with a hosted wallet comes down to who holds the keys and who carries the liability. A hosted wallet has a support team, a recovery process, and someone to call when something goes wrong, and it also has a company between you and your money. AWallet removes the company and gives you the source, and the cost is that recovery, support and key custody become your problem. The features list is evidence of how much the project has taken on: multisig, rekeying, WalletConnect and a peer-to-peer passkey path are all things a hosted wallet may not offer at all.

## Conclusion

AWallet fits an Algorand user or developer who wants a wallet whose code they can read, whose keys are held in the browser rather than on a server, and who needs multisig, rekeying or WalletConnect features that hosted wallets often omit. It does not fit someone who wants a custodial or exchange grade product with a support team behind it. Before using it with real funds, read the audits directory in the repository and the Liquid Auth document under docs, because signing through WalletConnect and signing through a passkey linked WebRTC path are two different trust models and the wallet supports both.

## FAQ

### What is AWallet and who maintains it?

AWallet is an Algorand community wallet, built by community for community and fully open source since 2021. The source is published at github.com/scholtz/wallet, and the most stable deployment runs on a private on-premise Kubernetes cluster run by Scholtz and Co.

### Which account features does AWallet support?

Creating a wallet, exporting, importing and destroying a wallet, Algo25 Shamir backup, creating accounts, creating multisign accounts, adding a public account, account and transaction overview, sending algo payments, and signing and sending multisig payments.

### How does AWallet connect to DApps?

Through WalletConnect, and through Liquid Auth, which is passkey-linked and peer-to-peer over WebRTC with ARC-0001 and ARC-0060 signing. The Liquid Auth approach is described in docs/LIQUID_AUTH.md.

### What licence is AWallet released under?

AGPL-3.0, with the terms in the LICENSE.md file at the top of the repository.

### Which deployment should I use for AWallet?

wallet.biatec.io is the preferred and most stable deployment. The environments under the main branch domains, including the GitHub Pages and Vercel hosts, carry unreleased main branch code, and the a-wallet.net environment is deprecated.

## Sources

- [Issues](https://github.com/scholtz/wallet/issues)
- [License: AGPL-3.0](https://github.com/scholtz/wallet/blob/master/LICENSE)
- [Project website](https://wallet.biatec.io)
- [README](https://github.com/scholtz/wallet/blob/master/README.md)
- [scholtz/wallet on GitHub](https://github.com/scholtz/wallet)

---

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