THE ISSUE
The Radix Wallet (iOS and Android) is critical ecosystem infrastructure. It is the primary full-featured way for users to manage Radix assets, approve transactions and interact with dApps.
Community messages show that some users are getting stuck. Meanwhile, an Apple or Google platform, policy or SDK change could disrupt an app that is not actively maintained. Waiting for a serious failure is the wrong strategy for the ecosystem’s main point of access.
The proposal in brief
I propose taking operational stewardship of the iOS and Android apps for an initial six months. We will help transfer the app assets, stabilise the codebase, introduce privacy-safe error reporting and establish dependable maintenance and release processes.
This first discussion asks whether the community supports the principle and which of three service levels it prefers. Commercial terms will follow before any funding decision.
I run a software development agency in the UK, where we build new websites and apps, as well as inherit and look after existing websites and apps. We have many apps under our purview that are in the app store. This is our wheelhouse.
I invite the community to:
- support or challenge the proposed stewardship model;
- indicate a preference for Package 1, 2 or 3;
- share the most important current wallet problems and user journeys; and
- suggest anything that should be included before a detailed scope and price are presented.
What needs to happen
- Transfer or delegate the Git repositories, Apple App Store and Google Play assets from the Foundation to the DAO.
- Establish secure, resilient access to the code, signing and release systems.
- Make sure both apps can be built, tested, signed and released reliably.
- Monitor Apple, Google and software-dependency changes.
- Add privacy-safe crash and error reporting so problems can be diagnosed.
- Provide a clear route for reporting and responding to user issues.
- Publish useful documentation so future maintainers and contributors can understand the project.
We will assist with the transfer where needed and where we can. The DAO will retain ownership and custody of its assets. No individual will be the sole administrator, and the handover path will be documented.
Three service levels
Every package includes an initial takeover audit. With access to Git and the app stores, we will confirm that the apps can be built, signed, released and supported safely. We will identify risks involving credentials, dependencies, security, documentation and key-person knowledge, then publish a findings report, risk register, stabilisation plan and maintainability baseline.
This is an operational code and takeover review, not a substitute for an independent security audit.
Package 1 - maintain the wallet
We take contractual responsibility for keeping the existing iOS and Android apps healthy and releasable.
This includes:
- the initial takeover audit and stabilisation plan;
- dedicated maintenance capacity within an agreed cap;
- fixing defects and stabilising problem areas;
- dependency, iOS, Android and app-store compatibility updates;
- privacy-safe error reporting and release-health monitoring;
- user issue intake and incident triage;
- critical and maintenance releases;
- ongoing operational documentation and progress updates.
In simple terms: we keep the wallet working, supported and ready to release.
Package 2 - maintain it and steward open source
Everything in Package 1, plus management of the open-source contribution process.
We will support third-party developers with their proposed changes and contributions, review and test submissions, maintain clear contribution guidance, and manage accepted work through a sensible and orderly release process. We will protect the integrity and direction of the asset while making it easier for the community to contribute safely.
In simple terms: we maintain the wallet and provide a well-managed route for others to help improve it.
Package 3 - maintain it and move it forward
Everything in Packages 1 and 2, plus dedicated capacity for community-prioritised product development.
We will maintain a public Now / Next / Later roadmap, size proposed features against the available time, and deliver the highest-value work that fits within the agreed capacity. If the community, DAO or future Working Groups want to accelerate progress, we can increase the dedicated development capacity through a transparent budget adjustment.
This package will also include the legwork needed to observe Foxy’s public Hyperscale work, identify possible mobile implications early, prepare relevant questions and integration scenarios, and invite collaboration where it would help. This does not assume or imply any commitment from Foxy, and our delivery will not depend on his participation.
In simple terms: we maintain the wallet, manage contributions and dedicate regular time to improving the product.
The first 90 days
Take control safely
- complete the repository, app-store, build, signing and dependency inventory;
- establish reproducible iOS and Android builds, or publish the blockers;
- secure access with named roles and more than one administrator;
- baseline current app health, user reports and platform risks.
Stabilise and gain visibility
- review the codebase, dependencies, tests and release health;
- introduce privacy-safe crash and error reporting;
- address the highest-risk reproducible defects within the selected package’s capacity;
- document release, incident and rollback procedures.
Operate predictably
- make maintenance releases where needed;
- establish ongoing dependency and platform monitoring;
- publish the contribution process under Packages 2 and 3;
- publish the mobile roadmap and external-dependency view under Package 3.
Secure error reporting
At present, a user may report that something failed without giving maintainers enough information to reproduce it. Privacy-safe diagnostics will help identify affected app versions, devices, operating systems and failing code paths.
Diagnostics will not be designed to collect seed phrases, private keys, recovery factors, balances, wallet addresses, transaction manifests or unnecessary transaction content. Collection, access, retention and deletion rules will be documented before production use. Security-sensitive findings will follow responsible disclosure.
Service commitment
Support will initially operate during published UK business hours through a dedicated email address and issue-intake process.
| Priority | Example | Acknowledgement | Initial assessment |
|---|---|---|---|
| P1 - Critical | loss-of-funds risk, active compromise or widespread inability to transact | 2 business hours | 4 business hours |
| P2 - High | major wallet function unavailable without a reasonable workaround | 4 business hours | Within 1 business day |
| P3 - Normal | limited defect with a workaround | 2 business days | 5 business days |
These are response and assessment targets, not guaranteed fix times. Resolution can depend on reproducibility, other Radix services, third parties, security review and Apple or Google approval. P1 containment takes priority over other work.
Documentation and accountability
We will publish progress frequently, with written reporting as the minimum. Updates will cover app health, incidents, completed work, capacity use, risks, releases and upcoming priorities.
Where useful, we also intend to create short video walkthroughs covering the architecture, important code paths, build and release processes, and maintenance procedures. Time spent learning the inherited codebase should create a lasting open-source asset - not knowledge held by one person.
At six months, the community will receive a retrospective covering outcomes, unresolved risks and a recommendation to renew, change provider, move the work into a DAO Working Group or conclude the engagement. Renewal will require a new community decision.
Boundaries and safeguards
- The DAO retains ownership and custody of the repositories and store assets.
- No individual holds sole administrative control.
- This mandate does not authorize unilateral protocol changes, DAO strategy or treasury spending.
- Security-sensitive information will not be published prematurely.
- Work and capacity will be visible to the community.
- A successor must be able to use the documentation and release process.
- The paid delivery lead will not approve their own milestones or payments.
Community input requested
I invite the community to:
- support or challenge the proposed stewardship model;
- indicate a preference for Package 1, 2 or 3;
- share the most important current wallet problems and user journeys; and
- suggest anything that should be included before a detailed scope and price are presented.
