Discussion - Wallet future

Hi all,

As the Foundation is expected to wind down soon, one important consequence is that Wallet development, at least in its current Foundation-led form, will also come to a stop.

Given that the Wallet is one of the main entry points into the ecosystem, I think it is important for the community to discuss what role we want it to play going forward, and what level of support or development we are willing to commit to.

The purpose of this topic is not to push a specific outcome, but to outline the main questions and trade-offs so we can decide on a clear path forward.


1. What level of Wallet development do we want?

The first question is whether the Wallet should simply be maintained in its current form, or whether we want to continue actively developing it.

Option A — Maintenance only

One possible path is to consider the current Wallet feature set sufficient for the near future.

The Wallet already has a strong foundation and supports most existing ecosystem use cases. Under this approach, the focus would be limited to:

  • bug fixes;

  • security updates;

  • compatibility updates;

  • basic maintenance required to keep the Wallet functional and reliable.

This would avoid committing significant resources to new development while still preserving the Wallet as a useful tool for the ecosystem.

The main trade-off is that the Wallet would likely not evolve much beyond its current state.

Option B — Continued feature development

Another path is to continue actively improving the Wallet.

The Wallet is arguably the central point of interaction with many parts of the ecosystem. Continuing to develop it could help:

  • improve user experience;

  • support new ecosystem use cases;

  • attract new users;

  • retain existing users;

  • make integrations with other ecosystem components easier.

However, this option would require considerably more development effort, funding, coordination, and long-term ownership. It would also require clarity on who is responsible for prioritization, implementation, and maintenance.


2. How should Wallet development be organized?

Separate from deciding whether the Wallet should be maintained or actively developed, we also need to decide how development should be organized after the Foundation steps back.

There are a few possible approaches:

A. Community-led open-source project

The Wallet could become a fully community-driven open-source project, where development is handled by contributors from the ecosystem.

In this model, the codebase would remain open, contributors could propose improvements, and development priorities could be discussed publicly.

This approach would preserve openness and decentralization, but it may also make progress less predictable unless there are committed maintainers responsible for reviewing, merging, and coordinating work.

B. Maintained by a core developer or dedicated team contracted by the DAO

Another option is for the DAO to contract a core developer or a small team to maintain and develop the Wallet.

This would provide clearer ownership, continuity, and accountability. It would also make it easier to plan releases, prioritize work, handle security issues, and ensure the Wallet remains reliable.

The trade-off is that this requires ongoing funding and some level of centralized responsibility.

C. Hybrid approach

A middle-ground approach would be to keep the Wallet open-source and community-accessible, while also having one or more DAO-funded maintainers responsible for coordination, code review, releases, and critical maintenance.

This could allow the broader community to contribute, while still ensuring that the project has reliable ownership and does not depend entirely on volunteer availability.


3. Wallet neutrality, funding, and long-term sustainability

Separate from the questions of development scope and ownership, there is another important discussion to have: what principles should guide the Wallet going forward, and how should its development be funded?

Historically, because the Wallet was developed by the Foundation, it was expected to remain impartial and operate as a non-profit public good.

This meant avoiding certain types of functionality, such as:

  • revenue-generating features;

  • preferential ecosystem integrations;

  • commercial partnerships;

  • features that could be seen as favoring one project, service, or dApp over another.

With the Foundation stepping back, it may be worth re-evaluating whether this approach should continue unchanged.

There seem to be a few possible paths:

A. Keep the Wallet as a neutral public good

The Wallet remains community- or DAO-maintained, with no monetization and no preferential integrations.

This would preserve the current role of the Wallet as a neutral ecosystem tool, but it would also mean that maintenance and development need to be funded externally.

B. Allow the Wallet to become self-sustaining

The Wallet could be allowed to explore revenue streams, partnerships, or integrations that help fund its own development and maintenance.

This could make the Wallet more sustainable long term, but it may also raise questions around neutrality, governance, and which integrations are acceptable.

C. Keep the main Wallet neutral, but allow independent forks

Another possibility is to maintain the main Wallet as a neutral base wallet, while allowing separate teams or entities to create independent forks.

These forks could experiment with additional features, commercial integrations, or revenue models, while remaining separate from the DAO or community-maintained Wallet.

In this approach, the neutral Wallet remains a public good, while more product-oriented versions can evolve independently, just like any other ecosystem dApp.


Questions for discussion

A few key questions seem worth addressing:

  • Is the current Wallet feature set sufficient for the near future?

  • Should the community fund only maintenance, or also continued feature development?

  • Should Wallet development be community-led, DAO-contracted, or a hybrid of both?

  • Who should be responsible for releases, security fixes, and long-term maintenance?

  • Should the main Wallet remain strictly neutral and non-commercial?

  • Should monetization or commercial integrations be allowed if they help make the Wallet sustainable?

  • Would a forked model be healthier than changing the role of the main Wallet itself?


I think reaching alignment on these questions is important before making any commitments around funding, ownership, or development priorities.

Curious to hear how others see the future of the Wallet, both in terms of development scope, ownership, and long-term sustainability.

Note - These questions are asked in the context of me being available to facilitate whatever path we do choose.

6 Likes

The discussion is not that easy to get started when we don’t know what resources we actually have available. And most brain power is directed towards the transition process.

What I believe we need in the short term is to ensure continuity and the establishment of the DAO. It needs to be set up and allowed to stabilize a bit before it can realistically decide on these strategic directions.

What we need to decide now, is how we can secure the transition in the short term. And short term I mean 6-9 months. We will need to maintain both the Wallet and the Gateway. Possibly more, but the remaining FND members likely have better insight into that than I do.

Any proposal that offer this maintenance service and assisting the transition is highly welcomed.
I don’t want to kill the strategic discussion. Only emphasize the short term needs versus the longer term strategic directions.

1 Like

Generally I think for now until the transition happens, we just need maintenance so the network is functional on all bases.

In the meanwhile I would start chatting with Foxy on how the wallet can integrate better with the Hyperscale RS because there might be some technicalities that we need to consider.

From a business and sustainability perspective we should consider any means more or less to get some revenue. Survival should be the main priority at this point, and some revenue is essential.
I’m not saying adding ads in the wallet, but maybe some swaps, or some fiat integrations if possible, etc.

Another thing i brought up in the Hyperscale RS chat and saw that might have some legs for support, is to have this wallet with a white label approach in mind so that it is easily customisable or branded by companies.
Some of the friction right now for companies adopting wallets is that they are hard to adopt as “in house” products.

If we are going to increase adoption and sell to these businesses easily the Radix narrative, just let them use the wallet easily, fork it but to start as a clean slate from a UI perspective, and what’s on the background to be thesame, like backend, etc.
ONE WALLET with different skins/themes.

It will be easier to go to a bank, organization, etc, hey, here’s our wallet, just fork it and slap your LOGO on top. make it yours, but share the same top security underneath.

This is something I think would lower the friction for adopotion as one solution doesn’t fit all cases.

1 Like

Neutral , a tech developed as Neutral as posible , and Develop as Core and of course not monetization …what kind of joke is a wallet monetized. of course the fund to develop it must to be outside from it.

  • Is the current Wallet feature set sufficient for the near future? YES

  • Should the community fund only maintenance, or also continued feature development? It is inconceivable not to consider that development should continue; however, we need to understand what percentage of Radix’s budget can be allocated

  • Should Wallet development be community-led, DAO-contracted, or a hybrid of both? at the beginning, I think DAO contracted

  • Who should be responsible for releases, security fixes, and long-term maintenance? best option would be a wallet team could emerge, The initial approach is clearly to let the current devs continue

  • Should the main Wallet remain strictly neutral and non-commercial? a white label option would be great

  • Should monetization or commercial integrations be allowed if they help make the Wallet sustainable? yes sure, anything that could create cash flow should be allowed

  • Would a forked model be healthier than changing the role of the main Wallet itself? a forked one could be possible but given the current low usage I think the current wallet could and should be used for now

1 Like

Short answer: 1B, 2B, 3B+C

I am convinced that the battle for the end-user activity and volume is no longer being fought at the technical protocol level (L1/L2), but at the point of interaction. The chain itself has become a commodity, what matters now is the frontend, the Radix Wallet User Experience.

Our goal:

  • Financial Sustainability: Achieving independence from current DAO holdings through organic protocol revenue.

  • Simplification: Reducing the cognitive load during the first point of contact.

  • Onboarding: Minimizing “Time-to-Value.” A user should be transaction-ready from download to usage within 60 seconds.

  • Ecosystem Synergies: Increasing activity and TVL by aggregating existing dApps (Astrolescent, Caviarswap, Ociswap, Surge, Delphi etc.) directly within the core user experience.

While the current Radix Wallet is technically brilliant and serves as a great showcase for the network’s security, we must recognize that “security through complexity” is a hurdle for mass onboarding. I advocate for a strategic fork of the current wallet to perfectly serve two target groups:

  1. Radix Core Wallet (The Fork): This serves as the open-source foundation, offering full technical control for power users, validators, and developers.

  2. New Radix Main Wallet (The Commercial Wallet): The current app available in the stores (Google Play/Apple) should be transformed into an intuitive, commercialized “Super-App.” It will function as the easy-to-use frontend.

To capture the mass market and gain activity, the new commercial wallet should integrate:

  • Basic Mode (Default): A clean interface focusing on biometrics (FaceID/TouchID) instead of complex seed phrase hurdles at the start.

  • Native Frontend: Direct UI integration for Tools (Debix) and dApps such as Perpetuals (Surge), Prediction Markets (Delphibets), DEX aggregators (Astrolescent/Caviar) and a dApp Browser.

  • Fiat Bridge: Integrated On- and Off-ramps to close the Web2/Web3 gap between bank accounts and DeFi. Fact: Case studies from Transak show that native fiat integrations can increase conversion rates by up to 400%.

A decisive point is the financial sustainability of wallet development:

  • Fee Model: Implementation of a competitive service fee of up to 0.4% on in-wallet transactions (swaps, perps, predictions, on-ramps). Compared to MetaMask (approx. 0.875%), this is extremely fair and attractive.

  • DAO Treasury: These revenues flow directly into the DAO. This allows commercial wallet users to indirectly fund the development of the


My Conclusion: We need to stop viewing the wallet as a simple token manager. It is our marketplace where supply meets demand. By combining user convenience with Radix’s inherent security, we can unlock the mass market. Thus I would advocate for options 1B, 2B, 3B+C.

Action Plan

  1. Forking & Branding: Ensuring power users retain their familiar environment while the current downloaded wallet will be transformed into a easy-to-use-super-wallet.

  2. UI/UX Redesign: Reducing onboarding time to under 60 seconds via biometric focus.

  3. Tools/dApps Integration: Seamlessly integrating Radix dApps such as Astrolescent, Surge, Delphibets via API/Hooks and a dApp Browser.

  4. Monetization: Starting organic DAO funding through in-app activity with a up to 0.4% service fee.

  5. Marketing Push: Positioning the new Radix Wallet as the simplest Web3 wallet in the app stores.

Happy to discuss!

1 Like

this is the most important feature, download the app, buy token with your credit card, and start using the dApp… but how to do that ? any research available ? or any way to dig into it quickly ? which payment provider could offer such a ramp to be easily integrated in the dapp ?

Alchemypay as a provider already offers XRD, the DAO or foundation would need to pay a integration fee - once it is done and integrated in the wallet, all dApps could gain from that one integration.

this one ? đź’¸ Alchemy Pay Ramp

It is not only an integration fee to be paid, but also a new integration layer to have the wallet communicate with alchemy pay.

That one, yes!

Well, some integration work has to be done, yes!

Radix’s “Dream”
Radix’s biggest differentiator has always been scalability with low fees. If they adopt a model that penalizes large holders or small users in the future, they will lose their competitive advantage against other fast networks.