Case Study: Self-Custodial Mobile Crypto Wallet

Project Goals

We were requested to develop a next-gen, self-custodial mobile crypto wallet that founders could take to market quickly. Deliver a safe crypto wallet where users are the only ones who own their access (private keys and seed phrases) and pair it with a way to restore lost access via a decentralized social recovery solution called “Guardians” (explained later in this piece). 

The first release was to ship EVM coverage (balances, send/receive, NFTs, swaps, history, WalletConnect) with a path to add Solana and Bitcoin later without rewriting UX flows. The wallet had to embed fiat on-ramps that settled directly to user addresses while remaining provider-agnostic so vendors could be changed without app rebuilds. For real-world assets (RWAs), the requirement was to make backing provable on-chain with clear redemption tied to real market pricing. Finally, the core needed to remain non-custodial and data-minimal to create a regulatory runway for ID-bound and compliant flows across regions.

Crypto Wallet Development

Our Approach

We developed the wallet so all cryptographic authority lives on the device. Keys are generated locally, encrypted at rest, and used for local signing. Servers never access keys or secret phrases.

This gives stronger safety, simpler compliance story, and true self-custody for both retail and institutional users. This also reduces audit scope: reviewers focus on the vault, recovery sessions, and transaction execution.

Guardians: Crypto Wallet Recovery

Decentralized social recovery (“Guardians”) replaces fragile seed phrases with a threshold-based, human-friendly recovery model. The wallet owner (the Ward) designates trusted contacts (Guardians) who can help restore access if a device is lost. Unlike custodial resets, no single person—and not our servers—can take control; recovery requires a qualified majority (e.g., 2 of 3 or 3 of 5), preserving true self-custody while making recovery practical for normal users.

Under the hood, the app creates a recovery secret on the user’s device, splits it into shards (secret-sharing), and encrypts each shard to a Guardian’s public key. We only relay ciphertext; we can’t decrypt or reconstruct anything. If the Ward loses access, they initiate a session-bound recovery; Guardians receive signed prompts and approve. Once the threshold is met, the Ward’s device reassembles the secret locally, restores the wallet, and rotates keys so any old material becomes useless. Approvals are single-use and time-boxed to prevent replay.

Security and UX guardrails make the model resilient in the real world: over-provision extra Guardians in case someone is unavailable, support clean replacement flows, encourage out-of-band checks (voice/DM) to reduce social-engineering risk, and provide an audit trail so the Ward can see who approved and when.

Chains integration

This is our way of shipping value fast without painting ourselves into a technical corner. EVM gives you the biggest reachable cohort with one signing scheme (secp256k1) and mature tooling, so we land immediate utility — balances, send/receive, NFTs, swaps, history, WalletConnect. Then, instead of hard-coding chain characteristics into the app, we isolate them behind a narrow contract. It means new chains don’t force us to redesign the app or retrain users. Because the chain-specific characteristics live behind adapters, sending, receiving, swapping, and confirming scope and behave the same whether it’s EVM or Solana/Bitcoin. We can add those networks when we’re ready — without rewriting screens, reworking flows, or confusing users who already learned the wallet. This gives faster launches, fewer regressions, lower support load, and a consistent UX across chains.

We standardize the transaction lifecycle for every chain, then hide each chain’s specifics behind an adapter so the app (and user) sees one consistent flow:

• One universal flow: Every chain implements the same five steps — build → estimate → sign → send → watch.
  
  • Build = prepare a transaction.
  • Estimate = get a fee quote.
  • Sign = approve with the user’s private key on their device.
  • Send = broadcast to the network.
  • Watch = track confirmations and handle edge cases (like reorgs).
    
    
• Chain specifics are written inside the adapter:
  
  • EVM needs a nonce, gas, and calldata, signs with ECDSA.
  • Solana builds a message with account metas and signs with ed25519.
  • Bitcoin builds a PSBT (Partially Signed Bitcoin Transaction), then finalizes and signs that PSBT.
    
    
• Each adapter declares what it can do (e.g., supports-NFTs, fee-bump, EIP-1559, PSBT). The app reads those properties, so it only shows features that actually work on that chain.
  
  
• If a chain changes, we ship a new adapter version without breaking older flows.
  
  
• The app discovers which adapters are available at run time (by region, cohort, or feature property). That lets us roll out Solana or Bitcoin gradually, switch providers, or disable an unhealthy adapter without touching the UX.
  
  
• We develop the same metrics for all adapters (build/estimate/sign/send/watch). Analytics, error handling, and retries look identical across chains.
  
  

This online crypto wallet is a universal power socket, where each chain is a plug adapter. Whatever you plug in, the device sees the same interface and works the same way.

React Native + Go

In terms of this crypto wallet development project, we chose React Native on the client without splitting the codebase. It means we write the app once (in React Native) and ship it to both iOS and Android, instead of maintaining two separate codebases. 

Anything security-sensitive — creating private keys, storing them, and signing transactions — runs in the phone’s native security layer (iOS Keychain/Secure Enclave, Android Keystore/StrongBox) and is unlocked by internal means. Because that work happens in native code and secure hardware, private keys stay undisclosed, which reduces the risk of their compromise.

For performance, the app keeps heavy cryptography off the JavaScript “UI thread” so the interface doesn’t freeze. If computationally heavy cryptography runs on the UI thread, frames can’t render within ~16 ms, so the app freezes. These tasks are pushed to native/background threads (via RN native modules/JSI), the computation is done there, and only the result returns to the UI — keeping taps, scrolls, and animations smooth.

The wallet also “virtualizes” long lists (only renders what’s on screen), caches blockchain metadata locally (so we don’t re-fetch it every time), and preloads important screens in the background. The effect: balances and history show up quickly and feel responsive — even when the network is slow or unreliable.

Provider-agnostic rails (fiat, swaps, bridges)

Abstraction prevents vendor lock-in and lets us switch providers without shipping a new app. Users get a stable flow; the business gets leverage over vendors.

Providers integrated at the early stage:

• Swing (cross-chain aggregator)
• Onramper (fiat to crypto)

We’ve built a universal plug for fiat and swapping/bridging, so the app interacts with a single, stable interface instead of being hard-wired to any one vendor. When a user taps “Buy” or “Swap,” the app sends an intent (what asset, how much, from/to where). The backend then chooses the best provider for that user at that moment — based on fees, region/KYC rules, uptime — and returns a session the app can host. Private keys never leave the device. When approval is needed, the wallet signs the transaction locally and continues.

For swaps/bridges we developed a strict, repeatable pipeline — quote → route → simulate → sign → submit.

• Quote: ask multiple sources what the trade would return right now.
• Route: pick the path (AMMs/bridges) that balances return, fees, and reliability.
• Simulate: run the route to catch failures before money moves.
• Sign locally: user approves on their device.
• Submit: broadcast and monitor to finality.

Technical Highlights

Self-custody by design

• Keys generated, encrypted, and stored on device; signing occurs locally.
• Backend cannot access keys or secret phrases; no “support backdoor.”
  
  

Guardians (social recovery)

• Default 2/3 approval.
• Recovery secret sharded and per-Guardian encrypted (ECIES/RSA, ECDSA).
• Services act as relay only; reassembly and key rotation happen on the user’s device.
  
  

‍

Multi-chain via adapters

• Unified interface: Build → Estimate → Sign → Send → Watch.
• EVM first (secp256k1), Solana (ed25519) and Bitcoin (UTXO/PSBT) plug in without UX rewrites.
• Consistent flows across chains; complexity isolated behind adapters.
  
  

React Native + Go

• RN for a single iOS/Android codebase with native secure storage.
• Go services for concurrent I/O (quotes, handshakes, signaling, fallbacks).
• Stateless patterns reduce operational risk and simplify scaling.
  
  

Provider-agnostic solution

• Fiat on-ramp abstraction delivers funds to user addresses.
• Swaps/bridges as a contract: quote/route/simulate/sign/submit. Providers can be added or replaced without client updates.

Results

We delivered the requested next-gen, self-custodial mobile crypto wallet: users alone control access to their funds, and “Guardians” provides seedless, threshold-based recovery without introducing a custodian. Fiat on-ramps were integrated behind a provider-agnostic interface that settles crypto directly to user addresses, letting developers switch vendors without app rebuilds. For RWAs, the app surfaces on-chain proof of reserves and clear redemption tied to real market pricing, making backing verifiable. Throughout, the core remained non-custodial and data-minimal, creating a practical regulatory runway for ID-bound and compliant flows across regions.

‍