DRAFT: GUI Wallet Competition

General
1

Note: this document is a draft for the purpose of soliciting feedback. Details may not be final yet.

Wallet Competition

The Neptune Cash ecosystem is evolving at an incredible pace. The requests for features are stacking up across the board, and the neptune-core developers can barely keep up. Among all feature requests, one category stands out for its large tally: a graphical user interface wallet.

Meanwhile, the code base is evolving into a stabler and more modular state, to the point where it is possible to contribute meaningfully without intricate knowledge of the rest of the system.

In response to this market demand, in order to release some of the pressure on the neptune-core team, and since it is possible, we have decided to outsource the development of GUI wallets. Not to some well-defined firm or individual contractor, but to the community at large. Specifically, we are launching a competition to solicit contributions from anyone who pleases. And there is a bounty for the winner(s).

Scope

The competition focuses on graphical user interfaces for managing the user’s Neptune Cash wallet. In particular, we are looking for programs that present users with a smooth user experience as they import and export Neptune Cash wallet seeds, and send and receive Neptune Cash transactions.

Bounty

The total prize money amounts to 11’000 Neptune coins, of which at least 6’000 will go to the winner. The remaining 5’000 coins will be distributed among the runners-up according to a distribution at the discretion of the judges.

For each winning submission, the entire reward will be disbursed as one Neptune Cash transaction to an address supplied by the winning teams. Further distribution is the responsibility of the winning teams.

Eligibility

The minimum requirements for the GUI Wallet program are as follows.

  • The GUI Wallet must be capable of standalone operation, meaning that it must participate in the Neptune peer-to-peer protocol itself or manage a process that does it.
  • By default, no secrets (cryptographic or other) leave the device. Functionality for exporting secrets must be expressly selected.
  • The GUI Wallet must be capable of importing and exporting seed phrases; these seed phrases must be compatible with the neptune-cli commands import-seed-phrase and export-seed-phrase.
  • The GUI Wallet must be capable of sending and receiving Neptune coins.
  • The GUI Wallet must be capable of tolerating reorganizations.
  • The entire software package must be licensed under the MIT license or similar. Moreover, it must have an up-to-date Github repository.
  • The GUI Wallet must run on Linux.

The following features are optional.

  • A mode of use whereby the GUI Wallet communicates with a separate process or server without managing it, such as an instance of neptune-core running on the same machine or even another machine over the internet.
  • A mode of use whereby the GUI Wallet interacts with an external party to outsource the production of proofs or other work-intensive tasks.
  • Support for other operating systems besides Linux, or even platforms like web or smartphone.

Judgment

Judgment is reserved for the neptune-core team who may at their discretion elect judges to outsource judgment to. The neptune-core team and any elected judges are barred from receiving bounties.

The judges will evaluate the eligible submissions according to the following criteria, listed in order of importance.

  1. User experience.
  2. Ease of installation.
  3. Code quality, git discipline, test coverage, release build distribution.
  4. Community response.
  5. Resource requirements.

Projects will not be penalized for reusing code that was developed by other teams, provided that such code is duly attributed. However, the judges will take into special consideration and rate highly the original sources of such code reuse instances.

The judges will base their judgments on the snapshot of the repository taken at the deadline for submission and will not take into account later commits. The judges’ evaluations and scores will be published when the winners are announced.

Timeline

  • 2025-04-16: Competition Announcement Draft Published
  • 2025-05-01: Competition Announcement Finalized
  • 2025-10-01: Deadline for Submissions
  • 2025-11-01: Judges’ Report on Eligibility
  • 2026-01-01: Winner(s) Announced & Payout(s) Arranged

How To Submit

  • Create a Github repository.
  • Develop a GUI Wallet.
  • Mark the repository “public”.
  • Announce the submission in the forum on the official GUI Wallet Competition thread before the deadline.

Draft

This document is in draft status, meaning that a) details may not be final, and b) feedback is requested. Feel free to comment on this thread.

2

Linux alone seems pretty limited. Easier for the developer perhaps, but our goal is to support all common platforms and end-users.

I think there should be two classes of GUI wallet:

  1. Desktop ( runs on Mac, Linux, Windows )
  2. Mobile. (runs on Android, Iphone)

And perhaps bonus points for a wallet that runs on all of those platforms. Eg the Dioxus rust framework supports both desktop and mobile targets (in theory).

3

Let me clarify the intention of this line.

The intention is not to disincentivize or disallow support for other platforms. In fact, multi-platform support is a good thing and should probably be mentioned explicitly as a category wherein contestants can earn extra points.

The intention is to streamline the judging process by using the same benchmark for all submissions.

In light of that clarification, perhaps a better choice of words is:

The GUI Wallet must run on Linux, although support for other platforms is encouraged.

4

Here is a suggestion that I am relaying from a private channel because I believe it can benefit from public discussion. I find the motivation compelling.

Extend the scope to web wallets.

Specifically, call for wallets that run in the browser, in addition to or instead of the call for standalone wallet applications.

For the purpose of this discussion, a web-wallet is not a web front-end to a node-with-wallet that lives on some external server. Instead, a web wallet runs entirely in the browser. Secret keys never leave the user’s computer.

Examples:

Motivation: standalone wallet applications can contain malware. Users (those who do not audit and compile the source code themselves) need to trust not only the good intentions of the developers but also their iron-right devops practices and the integrity of the PKI infrastructure against which they can authenticate the application they use. In contrast, a web wallet with the imprimatur of the core team induces no extra trust assumptions and therefore lowers the barrier to entry.

Speaking for myself again: web wallets pose particular engineering challenges, though they are by no means insurmountable.

Specifically, in order to initiate a transaction you must produce a bunch of proofs using Triton VM. So the Triton VM prover would have to run in the browser, which is a challenge in and of itself. Moreover, despite the many optimizations Triton VM is home to, generating these proofs takes time and computational resources. Currently, neptune-core spawns a new process for each proof, for two reasons. The most important reason is that if the required resources are unavailable, the external process is killed by the operating system and neptune-core can recover gracefully[1]. The second reason is asynchronicity: while the proof is being produced in the background neptune-core can continue handling blocks and transactions and other peer messages and serving the user interface. Yes there are other ways to achieve asynchronicity besides spawning new external processes, but the point is that some asynchronous solution is necessary when a user interface is involved.

And if you are tempted to outsource the production of these proofs to some external server, well, you can’t, not without letting secret keys leave the user’s computer. [2]

I have very little experience with web programming, so it is possible that I am underestimating the state of web programming. If so, please disillusion me of these imagined difficulties:

  • asynchronous (probably no issue at all)
  • run optimized rust code (cross-compilation?)
  • gracefully catch unmet resource requirements (?)

  1. Admittedly, the gracefulness can be improved further. ↩︎

  2. There is a compromise solution that might be relevant here. The web wallet would produce only the LockScript proofs, which are comparatively cheap. The other proofs would be outsourced. Under this division of labor, the web wallet would retain control of spending keys, but would lose privacy relative to the external server. Phrased differently, the external server could undermine many of the protections on privacy that regular transactions guarantee, but they would not be able to re-route funds to a destination of their choosing. ↩︎

5

A web wallet will be nice to have certainly, but I would say it is a more ambitious project, for the reasons you mentioned, and more. It will likely entail compiling some or all of the neptune crates to wasm, for starters.

I think also that web-wallets for other cryptocurrencies typically do not attempt to run a full node. think of syncing and storing all the blocks in a browser. Instead they would connect to a full node somewhere. So this underscores the need for an architecture that moves wallet out of neptune-core, so that it can concentrate on managing the blockchain, and serving various wallets of all types. But that architecture change is itself a substantial project.

In short, at present a desktop wallet software seems the most achievable to me. Though it would also benefit from a modular architecture, so to my eyes, it looks better to delay the competition until such an architecture begins to take shape and there is at least a proposed set of APIs for such an independent wallet to use.

crawl. walk. run.

horse, then cart.

etc.