I don’t know much about the technical aspects, but it looks like a lot of work is going to work。I have a question about the market：How many active users does Unstoppable Wallet currently have？
However, I believe there may be some misunderstanding here, likely due to a lack of deeper technical background - so I’ll try to clarify.
First, while Grim is indeed an actively maintained project and a great effort by the community, it’s a standalone wallet not a modular mobile library intended for reuse or integration into third-party wallets. Earlier Android wallets also fall into this category, and unfortunately, most of them are now outdated or unmaintained.
Second, Unstoppable Wallet is a fully native mobile app written in Kotlin for Android and Swift for iOS. We don’t use Flutter or React Native, which means we cannot just drop in web-based or cross-platform solutions. Integration must follow our internal architecture standards, performance constraints, and security models. This includes wallet initialization, key derivation, transaction lifecycle management, Tor support, and custom UI layers - all of which must be implemented from scratch.
Third and this is key - the majority of existing community-built solutions are not structured or documented in a way that makes them suitable for safe reuse. In our experience, it’s actually more efficient, secure, and maintainable to build production-grade libraries from the ground up than to adapt poorly documented or monolithic codebases.
So when we mention building “mobile libraries,” we’re not referring to wrapping legacy code - we’re talking about building clean, modular, reusable components that can serve both our wallet and other future integrations in the Grin ecosystem.
Lastly, I’d kindly suggest that any evaluation of the cost or complexity of this work be based on the actual technical requirements involved. It’s important that the conversation remains grounded in the technical realities - not assumptions.
1 Like
On average, Unstoppable has around 50,000 monthly active users across iOS and Android platforms. That’s just the visible part. A significant share of our privacy-minded users install the app via F-Droid or direct APK, where tracking is either minimal or intentionally absent by design. So while we can’t provide precise metrics for that segment, it’s safe to say the real usage is notably higher.
Unstoppable attracts a crowd that values self-custody, open-source software, and censorship resistance - and we’ve been building for them since day one. This makes it a natural match for protocols like Grin.
1 Like
Thanks for being open to community feedback on where to focus your efforts for Grin
i think we better focus on ardocrat’s valuable points, a significant part of the community strongly believes that Multisignature support is a critical, core priority for Grin right now.
DEX integration is, something most of us in the community are eagaer to see.This could even become a feature within your wallet and it is both win win.
If your team could help bring this Multisig functionality to life – perhaps by building on that existing work or integrating it, would be a massive win for the Grin ecosystem and directly address a major desire from the community. It’s a feature many “Grinners” are truly rooting for.
Maybe this would be a highly impactful area for your team to contribute to, we can work long term together.
This integration to wallet and libraries sure a work, preferring long time commitment and work both benefits us more.
4 Likes
If I got it right, they are going to implement Android and iOS libraries that can be re-used by other mobile developers.
As an example, I found their implementations of Bitcoin libraries for Android and iOS:
This is well documented with the examples how to use the libaries. Other (minor) cryptocurrencies libraries are not that well documented on their GitHub though.
If they implement Android and iOS libraries for Grin and if they document it well, then it is already worth considering to fund the development, even without wallet integration.
For those who are against the proposal, and think we shouldn’t pay for wallet integrations in general, you could trick your mind by thinking that we are paying $60k for Kotlin(Android) and Swift(iOS) libraries for Grin, not for wallet integration and it is up to Unstoppable wallet to integrate these newly created libaries into the wallet or not 
3 Likes
It means you need to maintain your app all the time to follow their standards at UI/and so on, tomorrow they can drop all code and go to Rust, converting it with AI, like they are doing it with C/C++, by using Native applications (bu running it like a game) you dont need to maintain Android/iOS UI stack.
That means you want to rewrite Grin in Java/Kotlin and Swift, its hard work and can be waste of time as mentioned above, wrapper can be done with FFI and code generator, we have also Python implementation GitHub - grinventions/mimblewimble-py: Pure Python implementation of Mimblewimble protocol for Grin cryptocurrency.
2 Likes
One technical question arised after an internal discussion.
@ddadybayo How are you going to implement grin wallet functionality into your libraries? Are you going to re-use (wrap) grin-wallet code (Rust) or re-write it in Swift and Kotlin?
3 Likes
We do not intend to wrap or bind the existing grin-wallet Rust code via FFI. Instead, we plan to implement native libraries in Swift (iOS) and Kotlin (Android) from scratch. This decision is based on several key factors:
- Architectural Consistency
Unstoppable Wallet is a fully native, high-performance application with strict architectural guidelines. Introducing foreign Rust code via FFI would violate our threading, memory, and security models, and significantly complicate maintainability and long-term support. - Performance & UX Constraints
Mobile platforms have specific constraints around memory, background execution, and concurrency. A clean native implementation allows us to fully optimize for these environments — especially important for privacy-preserving chains like Grin, where node communication and slatepack handling are sensitive to latency and user flow. - Security & Isolation
Crypto wallets are attack surfaces. Having auditable, self-contained code written in platform-native languages greatly improves our ability to harden the application against edge-case vulnerabilities and bugs. Relying on opaque bindings to a foreign codebase would introduce risk. - Codebase Maturity & Documentation Gaps
Whilegrin-walletis functional, its documentation is sparse, and the internal architecture (e.g., around transaction construction, slatepack workflows, and keychain derivation) isn’t easily reusable or modularized for third-party consumption. We’ve assessed the codebase and determined that greenfield implementation is more predictable in terms of delivery and maintainability.
1 Like
Appreciate the conversation and all who took part. It’s clear our proposal didn’t strike the right chord with the Grin community and that’s fair.
We’ve decided to hit pause on the integration for now. Maybe we’ll revisit it in the future, when stars align and there’s more clarity on direction and priorities.
Until then, I’ll still be around if anyone wants to dive into technical discussions or needs input on wallet architecture, mobile security, or anything else low-level and real.
Keep building.
2 Likes
hi,ddadybayo.
Thank you for your enthusiasm and patience, the grin community is a decentralized governance community organization with many opinions and ideas, and I hope that both the unstoppable wallet and grin will be successful.
I wish you all the best
4 Likes