Non-Custodial Wallet Development
Non-custodial wallet is software where private key never leaves user device. No intermediate storage, no servers to hack or freeze. Keys with user—assets with user.
Architectural Decisions
Architecture choice determined by two questions: where is key stored and how are transactions signed.
HD-wallet (Hierarchical Deterministic) per BIP-32/BIP-44 standard—base architecture for most modern wallets. From one seed-phrase (BIP-39, 12 or 24 words) derive key tree. User backups only mnemonic, wallet automatically recovers all accounts.
Derivation tree for Ethereum: m/44'/60'/0'/0/n, where n is account index. For Bitcoin different networks use different coin_type: 0 for mainnet, 1 for testnet.
MPC-wallet (Multi-Party Computation)—private key never exists complete with any party. Signing happens through threshold signature scheme (TSS) protocol like GG20 or CGGMP21. Eliminates single point of failure but complicates implementation.
Smart contract wallet—EOA (Externally Owned Account) replaced by smart contract. ERC-4337 standard (Account Abstraction) enables:
- Social recovery
- Batched transactions
- Gasless operations via Paymaster
- Multisig without separate multisig contract
Secure Key Storage
This is most critical part. Approaches by platform:
| Platform | Solution | Security Level |
|---|---|---|
| iOS | Secure Enclave + Keychain | High |
| Android | StrongBox / TEE + Keystore | High |
| Desktop | OS keychain + AES-256 file encryption | Medium |
| Browser Extension | SubtleCrypto API + encrypted storage | Medium |
| Hardware | Secure Element (HSM) | Maximum |
Seed-phrase encrypted via Argon2id (key derivation) with user password before storage. Never MD5/SHA1.
Blockchain Connection
Web3 providers: ethers.js 6.x or viem for EVM-compatible networks. For multichain—wagmi as abstraction layer.
RPC endpoints: public nodes (Infura, Alchemy, QuickNode) for production. For privacy—own node or multiple providers with fallback.
WalletConnect v2—standard protocol for dApp connection. Uses relay-server only for encrypted message transmission, keys never transmitted.
Transaction Signing
User initiates transaction → wallet shows details → user confirms → key from Secure Storage signs data → signed transaction sent to network.
EIP-1559 transactions use maxFeePerGas and maxPriorityFeePerGas instead of gasPrice. Wallet should get current data from eth_feeHistory and suggest three speed levels.
EIP-712—structured data for signing (typed messages). Let user see exactly what they're signing, not just hash.
Transaction Simulation
Before signing—critically important to simulate transaction. Tenderly, Alchemy Simulation API or local forked node allow:
- Show expected balance changes
- Warn about suspicious approve (unlimited approval)
- Detect wallet drain attempt
Token and NFT Support
Auto-detect ERC-20 through Transfer events + Moralis/Alchemy NFT API. For custom tokens—manual import by contract address with Etherscan API verification.
What We Develop
Complete non-custodial wallet stack: mobile app (React Native or Flutter) or browser extension, HD-derivation with secure seed storage, WalletConnect v2 integration, EVM networks support (Ethereum, BSC, Polygon, Arbitrum, Optimism), basic token/NFT discovery, transaction simulation before signing. Architecture—zero server components storing keys.