If You Forked Status Today, What Would You Change First?
I’ve been working on Status for a very long time, and for much of that time, I’ve had the persistent feeling that something about the app’s architecture was off.
The entire system was built around profiles — and everything, from chat to wallets, was deeply tied to them. But at the same time, certain things like global settings applied across all profiles, and importing keys or accounts into a profile felt confusing and inconsistent.
This really hit me recently while working on improved support for Keycard. I realized: there’s no way to simply buy a Keycard, configure it, and manage your keys — without first creating a profile. That alone is a sign of over-coupling. But even that wasn’t the worst part.
The real problem? The onboarding wall.
To even start using the app, users are forced to create keys and choose a password. It’s a hurdle. And even if they get past it, they still can’t immediately experience the full functionality of the app. There’s more setup, more hidden steps. More friction.
I’ve also heard countless voices in the community over the years — some saying they’re not interested in crypto at all and just want a messenger, while others say the opposite: they only care about the wallet and don’t want chat features at all.
This reinforces a simple truth: the app should adapt to the user, not the other way around.
Every user should be able to configure Status to match their needs. If they only want a wallet, they should be able to hide everything else and just use that. If they only care about messaging, they shouldn’t be forced to go through wallet setup.
This isn’t just about UX — it’s about modularity, performance, and security. Features that aren’t used shouldn’t run in the background, make network requests, or consume resources. They should be truly off — as if uninstalled.
If I were to redesign Status today — if I forked it for myself — I would treat it more like a operating system. When you launch it, you should instantly have access to all core functionality. You should be able to explore and use major features without needing to create or import keys, or set a password.
Let’s take a look at how that could actually work.
Everything Is a DApp
In this new architecture, every feature is its own DApp — modular, optional, and self-contained.
- The chat becomes a DApp.
- Communities — a DApp.
- The wallet? Also a DApp.
- Keycard support? DApp.
- A browser with pinned DApps on the home screen? You guessed it — also a DApps.
- WalletConnect — yes, it’s not the most secure protocol, but if the user wants to use it, it should be available as an optional DApp.
Each DApp runs in isolation and only if the user chooses to enable it.
(Technically, not everything we’re calling a “DApp” here is a decentralized application in the strictest sense — but for the sake of simplicity, we’ll use “DApp” to refer to any independent module within this system.)
This gives us an incredibly flexible foundation: you could run Status with just one DApp — the keys module.
A minimal setup where the user can generate, import, export, and sign with their keys — all locally, with no network connection required.
That brings us to the first and most fundamental DApp in this ecosystem:
DApp 1: Keys
The keys module is the backbone of the system. It’s responsible for managing the user’s keys — stored locally, encrypted (or not) based on user preference.
It includes everything needed for:
- Generating new key pairs
- Importing and exporting keys
- Signing transactions and messages
This module is independent. It can run completely on its own. It doesn’t require any other modules to function — and that’s what makes it powerful. You could use Status just as a local key management tool, and nothing more.
DApp 2: Messenger
The Messenger DApp would look and feel very similar to what we currently see on the Messages tab in Status today — but with a key difference:
It must be accessible without keys.
Users should be able to open the messenger and start exploring public channels in read-only mode, without having to generate or import keys. No onboarding wall. No password prompt. No friction.
Only when a user wants to send a message — whether it’s a direct 1:1 chat or a participation in a group — would they need to create a profile and link a key from the Keys DApp.
This opens up a range of possibilities:
- Seamless switching between profiles (and therefore keys) without restarting the app.
- Anonymous profiles, temporary identities, or fully branded ones tied to ENS names — all interchangeable with one tap.
- Trying the messenger experience instantly, with no commitment.
One interesting idea would be to create Telegram-like public channels that anyone can listen to, but only “owners” can write in. Or for example, a public ENS-filtered chat: anyone can read, but only users with a valid ENS name can post.
We could also register ENS names through the Status Network, making it easier and smoother for users to claim and use them inside the app — without dealing with the full gas-intensive on-chain UX right away.
The only dependency the Messenger DApp should have is the Keys DApp — and even that only when the user wants to write, not just read.
DApp 3: Portfolio
At this point, you might ask: “Where’s the wallet?”
Well — let’s break the wallet down into what it actually is.
Most people think of the wallet as one thing, but it’s really a collection of distinct components:
- Key management
- Transaction signing
- Account management
- Transaction broadcasting
- Portfolio view — account overviews, balances, fiat prices, NFTs, history, charts, etc.
Now here’s the catch: the biggest and most complex part of the wallet — the Portfolio — doesn’t require keys at all.
It’s entirely made up of external services:
- Address balances (Etherscan, Infura, etc.)
- Fiat prices (CoinGecko, CoinMarketCap, etc.)
- Transaction history (Alchemy, Etherscan, etc.)
- NFT previews (OpenSea APIs)
- Portfolio charts (Zerion API, DeBank, etc.)
Just like the Messenger, we can give users immediate access to the Portfolio without needing any keys or passwords.
That’s huge.
It means a new user can paste in an address — or scan a QR code — and instantly start exploring the wallet experience:
- View balances
- Watch tokens and NFTs
- See transaction history
- Track asset prices
- Explore DeFi positions
All without ever generating a key or setting a password.
This is the kind of experience people expect in 2025. Fast, frictionless, non-committal. You try first, then decide to go deeper — on your own terms. And yes — we’ll come back to account management later.
Portfolio as a Plugin Framework
The Portfolio DApp doesn’t have to be a single monolithic feature. In fact, it shouldn’t be.
Instead, it can be built as a collection of small, composable plugins, each responsible for one specific part of the portfolio view:
- A plugin for fetching address balances
- A plugin for fiat conversion
- A plugin for transaction history
- A plugin for charts
- A plugin for NFTs
- A plugin for DeFi positions
Each plugin would be isolated, easy to develop, and contribute back to the open repository.
This turns Portfolio into a platform — not just a feature.
Any developer could write a new plugin, submit it to the repo, and have it show up inside Status as an optional extension.
Over time, this would result in a growing library of community-maintained plugins — and users could choose exactly which ones they want to use. If a plugin requires API keys, users could register with the external service themselves and configure it securely inside Status.
Eventually, the Status project may decide to bundle certain default plugins — but even then, they remain just that: plugins, which users can disable, replace, or extend.
This model invites both users and developers into the platform — and that’s how real ecosystems are born.
DApp 4: Account Manager
The Account Manager is a simple but essential DApp.
It allows users to:
- Add any address manually (via text input or QR code)
- Derive addresses from existing keys in the Keys DApp
- Label and organize accounts in a way that makes sense to them
There are no keys involved by default.
This DApp is just about tracking addresses — watch-only by default.
Once an address is added, it becomes usable across the rest of the system:
- You can view its Portfolio
- You can prepare transactions for it
- You can sign and send from it — only if keys are connected
DApp 5: Network Manager
It lets users:
- Add and configure any number of Ethereum-compatible networks
- Provide custom RPC URLs and credentials
- Select a preferred network at the moment of sending
By separating this module, we allow users to break free from any default reliance on services like Infura.
They can:
- Use public RPCs
- Connect to their own node
- Or choose any gateway they trust
This also enables Status to step back from offering default transaction broadcasting — eventually, the app could ship with no built-in RPCs at all, leaving that power entirely to the user.
The Workflow Comes Together
- The user adds an address in Account Manager
- Instantly sees activity in Portfolio
- If they want to sign a transaction, they connect a key in Keys or use Keycard
- Then send it via the network configured in Network Manager
Each step is optional, composable, and reversible.
DApp 6: Browser
The Browser DApp serves as the gateway to everything else — a minimal Web3 browser with one powerful feature:
You can pin any DApp to your home screen.
This transforms the browser from a simple viewer into a personal dashboard builder.
Users can:
- Discover new DApps
- Try them without commitment
- Pin the ones they love directly to the home screen
- Remove or rearrange them at any time
DApp 7: Contacts
The Contacts DApp bridges the gap between wallet addresses and chat identities.
It lets users:
- Store contacts for the wallet (addresses and labels)
- Store contacts for the messenger (profiles, ENS names, avatars)
- Group and filter contacts by type
- Import/export address books
- Eventually: sync or export securely via encrypted backup (codex)
In a modular system, this contact manager becomes the shared address layer across all DApps
DApp 8: Keycard
The Keycard DApp allows users to manage and use Keycard — a hardware wallet and secure key storage device.
Inside this module, users can:
- Pair one or more Keycards
- Import and manage keys stored on the cards
- Use Keycard to sign transactions or messages
- Replace local signing entirely with hardware-based signing
In many cases, the Keycard DApp can fully replace the Keys DApp.
This is crucial for high-security users, hardware wallet fans, or institutions needing secure key custody.
By treating Keycard as a standalone DApp, the system remains flexible and composable:
- You don’t need to load the Keys module at all if you use only Keycard
- Or you can have both active and switch between them per use case
This plug-and-play model lets Status scale from casual users to advanced ones — without bloating the interface or logic.
And the Future: More DApps to Come
One of the biggest strengths of this modular architecture is how easily it scales.
As new technologies emerge, we can add new DApps — without touching or rewriting the core.
For example:
- A Codex DApp for decentralized encrypted backups (e.g. backup key data, DApp settings, or chat history)
- A Status Network DApp to manage identity, ENS names, community roles, or even payments
- And beyond…
Each one can be built, shipped, and updated independently.
Users install what they need — no more, no less.
The result is a living, extensible Web3 OS — not a rigid app.
This is how we evolve Status from a struggling super-app to a real platform — driven by users, supported by developers, and built for the long term.
Technical Implementation: Simplicity as Architecture
The current Status codebase suffers from over-design and over-engineering.
Everything is too tightly coupled and too heavy.
The result? Slower development, inconsistent UX, and hard-to-debug complexity.
The new architecture must be built on radical simplification.
Simplicity brings benefits across the board:
- Faster development
- Better runtime performance
- Reduced attack surface
- Easier onboarding for contributors
- Fewer moving parts = fewer bugs
Modular Navigation
Each DApp in the new system is self-contained, with its own internal navigation.
This simplifies routing in two major ways:
- Internal navigation stays inside the DApp
- Global navigation simply switches DApps, without interfering with their state
A user could open a DApp (e.g. Messenger), navigate deep into it, and then switch away to another DApp (e.g. Portfolio). When they return, the DApp resumes exactly where they left off — no reload, no state loss.
Each DApp is like a “mini-app” living inside the Status shell.
Persistent State and App Resume
Another critical feature is persistence.
When the user reopens the Status app, it should restore:
- The exact DApps that were open
- Their internal state and navigation stack
This creates an experience that feels more like a real OS and less like a fragile mobile app.
Home Screen: User-Controlled and Widget-Ready
The Home Screen is no longer just a tab bar or static layout.
It’s more like a mobile OS launcher:
- Users can add, remove, rearrange, or pin DApps
- Widgets can be added for at-a-glance info (e.g. balance preview, unread chats, gas price)
- DApp state can be minimized or reopened, just like minimizing a window
This gives users full control — and makes Status feel alive, responsive, and personal.
Demo
What you’ll see in the demo is a proof of concept — nothing more.
It’s built on top of the current Status codebase, using existing components wherever possible.
The goal is simple: to show how this new architecture could work — not to propose a final design, or a production-ready implementation.
https://youtube.com/shorts/RdC3QQdCBpc
This demo hasn’t been reviewed, approved, or formally discussed with the team.
It’s simply my personal exploration of what Status could become.
A lightweight, modular, user-friendly Web3 OS — built from the lessons of the past.
Example how it could look like for chat users.
Can This Be Done as an Update?
This is the big question everyone asks:
Can we implement all of this as an upgrade to the current Status app?
The short answer is: maybe — but with serious tradeoffs.
Technically possible? Yes.
But it would require keeping the current onboarding and profile system intact — which is a major downside. Those components are at the heart of the architectural complexity we’re trying to escape.
The real blockers:
- Massive technical debt in the codebase
- Outdated dependencies with potential security risks
- Poor performance due to unnecessary abstraction and over-engineering
- Status v2 built with focus on design over architecture, ignoring years of learning and technical insight
Fixing this incrementally would be extremely difficult and slow.
In my view, it could be a hard fork.
Like: Status Classic (the current version) and Status — a clean, simplified modular rebirth
This would allow:
- Clean separation from legacy complexity
- A performance- and security-first mindset
- Radical simplification of architecture and components
- Selective reuse of existing code where appropriate
- Retention of visual style, but restructured for speed and modularity
The goal isn’t to throw everything away —
It’s to cut free from the weight that holds us back.
If a new fork or version of Status ever happens, we must not leave users behind.
One long-awaited feature must be prioritized:
Exporting chats and contacts as an encrypted backup file.
This would allow:
- Seamless migration to the new app
- Encrypted, secure transfer of conversations and social graph
- Optional import — only if the user wants it
It’s not just a feature — it’s a promise:
You own your data. You decide where it goes.
Closing Thoughts
Of course, everything I’ve shared here is just my own thinking.
It doesn’t mean any of this will necessarily happen — or even should.
But I believe that by opening up this conversation, we can challenge assumptions, share ideas, and maybe — just maybe — find a path toward something better.
So I invite you all to join the discussion.
If even one useful idea comes out of this for the community, then it’s worth it.
Thanks for reading — and thinking — all the way to the end.
One Last Note
Many of the ideas in this post began taking shape long before Version 2 — and the post itself was written before the Offsite.
But as you may have noticed, the vision outlined here overlaps quite a bit with what was presented at Offsite.
That’s encouraging — and hopefully a sign that the ecosystem is starting to move in the right direction.
. Maybe it would have to be a separate view from the rest of these 
.