Relysia is part of our team's experience. People now on the Nexentra team contributed to it before or independently of Nexentra, and the Relysia case study shows the product. This piece is about the two very different audiences it had to serve at once.
Two kinds of user, one platform
Crypto products usually end up choosing. Everyday users need a wallet simple and safe enough to trust with real assets. Developers need infrastructure they can build on without writing blockchain plumbing from scratch. Most platforms serve one well and the other badly.
Relysia set out to do both: a non-custodial wallet for people, and Blockchain-as-a-Service APIs plus the Relysia JS SDK for the teams building on top.
How does self-custody change the design?
In a non-custodial wallet, users control their own mnemonics and private keys. No support desk can reset a lost key. That makes security a design problem as much as a technical one.
A few principles guided the flows:
- Slow down at the moments that can't be undone. Creating a wallet and backing up the recovery phrase deserve full attention, not a "skip for now" link.
- Confirm before sending, clearly. The amount, the destination and what happens next should be impossible to misread.
- Warn about risk without crying wolf. Risk alerts only work if they're kept for things that matter.
Errors are part of the product
Blockchain networks don't behave like a tidy test environment. Requests can be slow, transactions take time to settle, and things fail in ways the user didn't cause. Error handling was built into sending, receiving, token minting and address management, so users always know the state of their money, even when the network is having a bad day.
A vague "something went wrong" is tolerable in a to-do app. In a wallet, it makes people panic.
Infrastructure for builders
On the developer side, structured APIs and the JS SDK let other applications create wallets, retrieve transaction history and work with BSV token protocols programmatically. Good developer infrastructure has the same qualities as a good interface: predictable behaviour, clear errors and no surprises. Authentication and session handling had to hold up for the wallet and for the external apps using it.
What carries over to other products
You don't need to build a wallet for these lessons to apply. Any product that handles money, health data or anything irreversible benefits from the same habits: design the risky moments first, treat error states as real screens, and test under real conditions rather than ideal ones. The same thinking runs through our custom software work.
- #Blockchain
- #Bitcoin SV
- #Wallet UX
- #Security
- #SDK
- #Case study
