The team ships one app.
No product roadmap, no pivots, no second app. The wallet exists so that on day one of mainnet a working interface exercises every protocol feature.
The reference wallet
The first application we ship.
The reference wallet for Adamant — built by the same engineers who wrote the protocol specification. Open source. Self-custodial. The only application the team will ever ship.
REFERENCE IMPLEMENTATION · OPEN SOURCE · CLICKABLE PROTOTYPE
§01 / WHAT IT IS
A reference application,not a product strategy.
The team that specifies Adamant ships exactly one application: this wallet. It exists to prove the protocol's properties translate into a usable product, and to give the early ecosystem a known-good starting point. Other developers are expected to build their own wallets. This one will not be the canonical interface forever.
Forkable from the first commit.
Apache 2.0 — same licence as the protocol. Anyone can fork, ship a competing wallet, or extract components. The team holds no proprietary advantage.
Keys never leave the device.
No hosted wallet, no server-side state, no recovery service. The team operates no infrastructure for this wallet beyond publishing the source.
A built proof of the spec.
Every property the whitepaper specifies is exercised here: shielded transactions, view-key disclosure, on-device proof verification, threshold-encrypted submission, native account abstraction.
§02 / TRY IT
Three tabs.Click through any one.
Every screen of the reference wallet, navigable. Three live phones below, each landing on a different tab — Wallet, Verify, Node. Tap into any of them and use the bottom tab bar to move between any sub-screen the production app will surface.
Prototype only. Not a wallet. Holds no real assets. Reflects intended UX of the production application.
§03 / WHAT IT EXERCISES
Five protocol properties,five working surfaces.
Each tab in the prototype demonstrates a property the whitepaper specifies. The wallet is not the only way to use these features — it is the team's working proof that each one translates into a usable interface.
WALLET TAB WP §2.3 · §8.5
Chain-verified, on every load.
The home screen carries a footer showing the recursive proof verified locally on the device, in milliseconds, with no node, no RPC, no trust assumption. The user sees the chain's last verification and can re-verify with a tap. No other wallet on any other chain can show this.
→ Property: Phone-verifiable
SEND WP §2.2 · §3.6 · §8.4
Shielded is the default.
Sender, recipient, amount, and contract execution are encrypted to the upcoming epoch's threshold key before the transaction leaves the device. There is no toggle to "go private." Privacy is the path of least resistance; transparency is the per-transaction opt-out.
→ Property: Privacy by default · Encrypted mempool
VERIFY TAB WP §2.3 · §8.5
A first-class Node Watcher screen.
A dedicated tab where the wallet downloads the latest 5–10 KB recursive proof and verifies the entire chain history locally in 50–200 ms. Result is a 0 or a 1 — not a probability. Tap once; trust nothing.
→ Property: No light-client trust
NODE TAB WP §9.10
Run a service node from the same app.
Toggle a flag and the wallet's host device begins serving light-client queries to other wallets — earning ADM directly via payment channels or validator-funded infrastructure budgets. AC-only, Wi-Fi-only, background-only by default.
→ Property: Permissionless infrastructure
SETTINGS · VIEW KEYS WP §2.2 · §7
Selective disclosure, per scope.
Generate a view key that lets a counterparty, a tax authority, or an auditor see exactly the transactions you choose — within a date range, an amount range, or a label scope — without granting any spending authority. Revocable. Auditable. The compliance posture transparent chains cannot offer.
→ Property: View-key disclosure
EVERY ACCOUNT WP §4
Native account abstraction, always.
Every account in the wallet is a smart account from the first deposit. Programmable validation logic, per-account spend limits, multi-sig and threshold accounts at the protocol layer — no "upgrade your account" flow because there is nothing to upgrade.
→ Property: Account abstraction
§04 / STATUS
A working prototype.Implementation pending.
The wallet exists today as a clickable React prototype defining every screen of the reference implementation. The production build is part of the same engineering effort that produces the protocol's reference client and ships when the chain is ready.
PHASE 01 · CURRENT
UX prototype
Clickable React prototype defining every screen in the reference wallet. Iterates alongside the protocol specification.
PHASE 02 · NEXT
Production implementation
Native iOS, native Android, and a desktop reference build. Open source from the first commit. Same Apache 2.0 license as the protocol.
PHASE 03 · LAUNCH
Available at genesis
App stores, F-Droid, direct download. Available the day the chain is. After that, the team's role is maintenance; the ecosystem ships its own wallets.