AlphaWallet: an Android wallet built as a tokenisation platform

A wallet that is also a platform for tokenised products

AlphaWallet is presented as an advanced, open source Ethereum mobile wallet and dApp browser for Android, but the description in the README is more specific than that: an open source programmable blockchain apps platform.

The distinction matters. A wallet is a thing you hold keys in. A platform is a thing you build a product on top of. The README positions the project as compatible with the TokenScript tokenisation framework, offering businesses and their users in-depth token interaction, a clean white label user experience and advanced security options, supporting all Ethereum based networks.

The white label angle is the reason the project exists in this shape. The philosophy section says the goal is to give businesses the whitelabel tools they need to develop their ethereum wallets and join the tokenised economy. The README also says the project was founded by blockchain geeks and business professionals who believe blockchain technology will have a massive impact on the future and reshape how software is built. That is a statement of intent from the people who wrote it, and it explains why the codebase looks like an application framework rather than a small wallet.

The proof-of-concept list is concrete enough to be useful. AlphaWallet and TokenScript have been used by tokenisation projects including the FIFA and UEFA blockchain tickets, Bartercard's Qoin ecommerce ecosystem, several automobile car ownership portals, and others. The README explicitly invites forkers who want a token locked visible in their fork, which tells you the intended downstream user is a business shipping its own branded wallet.

The primary language is Java, the licence badge in the README says MIT, and the homepage is alphawallet.com. The repository is not archived, and the last push was on 2026-06-28.

TokenScript and the SmartToken idea

TokenScript is the layer that makes this more than a wallet with a token list, and it is worth understanding because it is the part that distinguishes the project from other open source Ethereum wallets, as the README says outright.

The mechanism is that a token can be extended with business logic that runs natively inside the app and comes with signed code to prevent tampering or phishing. The README calls these SmartTokens and describes them as traditional fungible and non fungible tokens extended with business logic. The claimed benefit is that rich functions that dApps previously struggled to implement become possible, and that you can get your token working on iOS and Android in real time without building your own Ethereum wallet.

The signing is the important half. If the logic that governs a token is signed, then the wallet can verify that the behaviour it is running came from the token issuer and was not modified in transit. Without that, a smart token is just a script an attacker could rewrite, and the whole idea collapses. This is a different trust model from a plain ERC-20, where the token contract on chain is the only thing that matters.

The app's role in that model is stated plainly: AlphaWallet is the browser for users to access these SmartTokens, so the user gets the full implementation of the use case without leaving the wallet. The README points at the TokenScript documentation and a separate TokenScript-Examples repository for what can be built.

The downside of the model is that a business adopting it is buying into a tokenisation framework with its own specification, its own examples and its own versioning, on top of the Ethereum stack itself. Two specifications to track rather than one.

Token standards and the network list

The coverage claims are broad, and they are stated in a way that lets you check them.

On token standards, the README says the wallet supports native ERC20, ERC721, ERC1155 and ERC875. That spans fungible tokens, the two common non-fungible standards, multi-token standards, and ERC875, which is the standard used for the tokenised tickets in the use cases listed.

On networks, the supported list covers Ethereum, Gnosis, Ethereum Classic, Binance Smart Chain, Heco, Polygon, Avalanche, Fantom, the L2 chains Optimistic, Arbitrum and Linea, and Palm. Testnets are listed separately: Sepolia, Holesky, Binance Test, Fuji for Avalanche, Fantom Test, Polygon Test, Optimistic Test, Arbitrum Test, Cronos Test and Palm test. Separating the test list from the main list is a small sign of care, since a developer integrating against a chain needs a testnet of the same kind.

The feature list is short and marketing-shaped: beginner friendly, Secure Enclave security, Web3 dApp browser, TokenScript enabled, interaction with DeFi, DAO and games through SmartTokens, and no hidden fees or technical background needed. The Secure Enclave item is the one to look into if key security is your concern, because it means the wallet is meant to keep the secret key in the platform's hardware-backed keystore rather than in the app's own storage, and that is the difference between a wallet you can use on a phone you lose and one you cannot.

The dApp browser is the other half of the product, with a Discover dApps section. Adding an entry is a pull request against a single JSON file, app/src/main/assets/dapps_list.json, which is a low-friction way to grow the catalogue and a simple one for a business to add its own front end.

Building from source with Android Studio, Infura and JDK 17

The getting started section is a numbered list, and it is worth following in order because two of the steps are not obvious.

Step one is to install Android Studio, step two is to clone the repository, and step three is to obtain a free Infura API key and replace the existing one in build.gradle. The Infura key is a dependency of the build configuration, so a fresh clone will not talk to an Ethereum node until you supply one.

Step four is to generate a GitHub personal access token with read:packages and read:user permission. Step five is to add the credentials to the Gradle properties file in your home directory, ~/.gradle/gradle.properties, as the properties block shows:

gpr.user=Your GitHub Email
gpr.key=The GitHub Personal Access Token you created in previous step

The key names are gpr.user and gpr.key, which is short enough to be easy to misremember and easy to get wrong, and the token scope is deliberately narrow, read access to packages and to your user, which is what a dependency resolution step needs and nothing more.

Step six is the build itself, either from Android Studio or by running the Gradle wrapper on the command line. The README notes that you can build it from the command line just like other Android apps, that JDK 17 is the version now supported by Android, and that the project builds with the JetBrains JDK. More detail is in BUILD.md in the repository, and a general overview in the docs directory.

The repository is a heavy Android project, not a small sample. Alongside app/ there is dmz/, which holds the dApp browser side, plus lib/, util/, hardware_stub/, fastlane/ for release automation, gradle/, scripts/, a gulpfile.js at the root, an e2e.sh script, a build.sh, a Gemfile, codecov.yml and a Gitpod setup with its own Dockerfile. There are separate CI workflows for lint, unit tests and end to end tests, which is the level of rigour you would expect from an application that other people fork for production.

Forking it for your own token

The README has a short section on customising the appearance of a wallet fork, and it says that if you are forking AlphaWallet and have a token you want to be locked visible, this can now be done easily. That is the entire section, which is both useful and revealing.

Useful because it names the specific capability: a pinned token in the fork, so a business can guarantee its own token is prominent in the wallet it ships. Revealing because the section is three sentences, and the broader whitelabel story in the philosophy section is much longer.

So the practical question for an adopter is how much of the white label story is implemented and how much is aspiration. The README documents the token visibility, the token addition path through the TokenScript repository, and the dApp catalogue entry through a pull request to the assets JSON. It does not document a theme system, a rebrand procedure, a configuration file for branding, or a build flavour per customer. The section on customising the appearance of a fork exists and is short, which suggests the answer for most teams is to edit the code.

The other integration point is TokenScript itself. If you want to include TokenScript and extend your token functionality, the README refers you to the TokenScript repository rather than describing the integration steps here, and the TokenScript-Examples repository holds the sample implementations, including the car ownership portal example.

For a team evaluating this, the honest reading is that a fork is a supported path with a documented but small surface area, and the real work is in understanding TokenScript and in the Java codebase, not in a configuration file.

Where AlphaWallet is the wrong tool

The first case is the release cadence. The tagged releases are v3.84 in July 2024, v3.85 in September 2024 and v3.87 in December 2024, and the last push to the repository was on 2026-06-28. So the code is being touched while the published versions have not moved for a while. For a business shipping a wallet to its own users, that gap is the first thing to ask about, because your fork's base determines which fixes and which chain support you inherit.

The second case is the dependency on a hosted provider. The build wants an Infura key, and the wallet as a product depends on node infrastructure. The README does not describe self-hosted nodes or an RPC configuration surface, and a business that has a policy about routing its users' transactions through a third party, or that wants to avoid depending on someone else's service, will not find what it needs in this documentation.

The third is the ecosystem question. This is an Ethereum wallet with TokenScript. If your asset lives on a chain outside the listed networks, or your use case is not a token with embedded business logic, the TokenScript machinery is overhead and the use case list in the README does not include anything like yours.

The fourth is the day-to-day wallet experience. The feature list is oriented to onboarding and to dApp interaction rather than to the day-to-day concerns of a wallet people use for payments, such as transaction history handling, fee selection, or reliability of notifications. If you are choosing a wallet for yourself rather than for a business, this project is not competing for that role.

The fifth is the build environment. Java, Gradle, Android Studio, JDK 17, a GitHub token and a provider key, with the Gradle wrapper and the app and dmz modules to work through. That is a real setup cost, and it is the cost that a business pays in exchange for shipping its own wallet instead of integrating with someone else's.

Licence signals that disagree, and what the repository holds

The licence picture is inconsistent, and that is worth resolving before you build on it. The README carries an MIT licence badge pointing at the LICENSE file, and the project is described as MIT licensed in the badge row. The package.json in the repository records the licence as GPL-3.0, with the author given as Smart Token Labs. The LICENSE file itself is in the repository root, and this article does not interpret it, but two different licences in one project, one of them copyleft, is a question for whoever handles your compliance rather than a detail to skip.

The repository layout shows a mature application rather than a library. There is a .all-contributorsrc file, a FUNDING.json, a Gemfile alongside the Gradle build, a gulpfile.js for the front end assets, fastlane/ for release automation, a codecov.yml for coverage, a hardware_stub/ directory for device testing, an e2e.sh script and a scripts/ directory, plus .bundle/ and .gitpod.yml with .gitpod.Dockerfile for a one-click development environment.

The npm package.json is a side project, with a single dependency on normalize.css, a main entry of gulpfile.js and a test script that reports that no test is specified. The JavaScript tooling is there for the front end, and the real build and test story is Gradle based with the lint, unit test and end to end test workflows in CI.

The contribution guidance is short and specific: report bugs as GitHub issues including your operating system, device, version number and steps to reproduce. For a project that other teams fork, that is the level of detail that determines whether a bug report is actionable, and it is a reasonable place to look for how responsive the maintainers are.

The homepage is alphawallet.com, and the README links a Gitpod badge, so a contributor can get an environment without installing the Android toolchain locally.

Editorial conclusion

Adopt AlphaWallet if you are an organisation that needs a white label Ethereum wallet for a token you issue, and you can support a Java and Gradle Android codebase with upstream dependencies. Do not adopt it as a general purpose everyday wallet if you need a maintained retail application, since the newest tagged release is v3.87 from 2024-12-01 while the last push was on 2026-06-28, and do not assume the licence position is settled, because the README badge and the project file disagree, with the README saying MIT and package.json recording GPL-3.0. Verify first that your token can be expressed as TokenScript, that the networks you need are in the supported list, and that you can build the app with JDK 17 and an Infura key before committing to it.

Frequently asked questions

Official sources

1. AlphaWallet/alpha-wallet-android on GitHub
2. License: MIT
3. Project website
4. README
5. Releases