Loopring has announced that it will shut down the Loopring Wallet by the end of June 2025. For users, this means migrating assets, updating interfaces, and—most critically—losing continuity. No exploit. No protocol failure. Just a business decision that turns a once-critical access point into a dead end.
This isn’t a bug. It’s a feature of the current wallet infrastructure landscape.
Loopring’s exit highlights a deeper risk baked into wallet architecture: one that affects users today, but should concern developers even more. When access to wallets depends on a third party, continuity becomes fragile. This blog steps back from the shutdown itself to examine what happens when developers build on infrastructure they don’t own—and how that choice shapes the reliability, trust, and future of onchain UX
Wallets aren’t just accounts anymore—they’re infrastructure. They manage keys, initiate transactions, and define how users create and interact with onchain value. When access to that infrastructure is abstracted behind a third-party SDK or service, developers don’t own that layer—they rent it.
When that service ends, users lose access and trust. Developers lose continuity and control. And the app’s onchain experience fractures at the wallet boundary.
Loopring’s shutdown isn’t just a matter of user inconvenience. It’s a warning: even non-custodial tooling becomes a point of failure when it’s embedded as a service, not built as infrastructure.
This is where architecture matters. Wallets can be:
Branded apps that live outside your product experience
SaaS-style services that insert external control over custody and UX
Embedded wallets that live inside your app, stored on-device, and fully owned by users
The first two come with dependency risk. The last one doesn’t.
Most wallet SDKs today simplify onboarding by centralizing hard parts—key management, gas, recovery. But in doing so, they introduce a single point of failure, whether technical or organizational. When the provider shuts down, developers scramble. When terms change, apps adapt or break. When custody shifts, users lose ownership.
That’s not infrastructure. That’s exposure.
RallyProtocol takes a different approach. It doesn’t provision wallets for your users—it gives you the tools to embed wallets directly into your app: on-device, invisible, and developer-controlled. No third-party custody. No vendor lock-in. No shutdown notices.
With RallyProtocol:
Keys are generated and stored on the user’s device, encrypted by the secure enclave
Wallets are embedded directly into your mobile UX—not bolted on or handed off
You own the flow from session to transaction, from auth to signing
When wallets live on-device and within your app, you don’t lose them when a custody provider pivots.
Loopring isn’t the only one. Centralized wallet layers can—and have—disappeared. It’s not always malicious. Sometimes it’s a pivot. A funding issue. A strategic exit.
The result is the same: disruption.
For mobile apps, this fragility is fatal. Users expect continuity. Developers need control. RallyProtocol is built for both. It’s wallet infrastructure that doesn’t assume trust, doesn’t require a contract, and doesn’t go dark.
RallyProtocol is a wallet toolkit for mobile developers who want full ownership of their app’s onchain experience. It provides key management and recovery components for embedding secure, on-device wallets—no custody layers, no forced UX, and no centralized gatekeepers. Permissionless, open source, and built for vertical integration.
Your wallet. Your app. Nothing in between. Start building at rallyprotocol.com.
