Frequently Asked Questions
What is the difference between MPC and multi-sig?
Multi-sig requires M-of-N on-chain signers — each signer has a complete key and the contract enforces the threshold. This is visible on-chain and requires a transaction to change the signer set. MPC distributes the key into shares that are never combined — signing happens as a distributed computation, the resulting signature is indistinguishable from a single-key signature, and no on-chain contract is required. MPC is more flexible and private; multi-sig is simpler and fully on-chain verifiable.
What is ERC-4337 and should we use it?
ERC-4337 is the account abstraction standard that allows smart contract accounts to act as wallets — enabling social recovery, session keys, gas sponsorship and batch transactions without a seed phrase. It is the correct architecture for consumer wallets targeting mainstream users who should not be expected to manage seed phrases. The tradeoffs: EVM-only, requires bundler infrastructure, slightly higher gas cost per transaction. For cross-chain wallets or chains without 4337 support, hybrid architectures are available.
How do you handle seed phrase backup securely?
For non-custodial wallets, seed phrase backup options are: user writes it down (most common, highest loss rate), encrypted cloud backup with user-controlled encryption key (convenient, depends on cloud provider security), Shamir Secret Sharing split across multiple locations, or hardware wallet as backup. ERC-4337 social recovery eliminates the seed phrase entirely for EVM wallets. We recommend designing the backup UX to make secure backup the path of least resistance, not an optional step users skip.
What chains can the wallet support?
EVM chains (Ethereum, Arbitrum, Base, Polygon, BSC, etc.) share key format and signing algorithm — one implementation covers all. Solana uses a different key derivation path and Ed25519 signing. Bitcoin uses a different UTXO model and transaction format. Each non-EVM chain is approximately 4–8 weeks of additional engineering. We recommend launching with the chains where your users actually live rather than listing 50 chains on day one with untested implementations.
How should we handle transaction fees for users?
ERC-4337 paymasters allow you to sponsor gas fees for users (they transact without needing ETH) or accept payment in ERC-20 tokens. This is the cleanest UX solution for onboarding non-crypto-native users. For non-EVM chains, gasless transactions require chain-specific solutions. Fee abstraction significantly increases conversion on first transaction — users who encounter a "you need ETH for gas" message before they can use the product frequently abandon.
What regulatory considerations exist for wallet products?
Non-custodial wallets (user holds keys) generally do not require money transmitter licensing as the developer never controls funds. Custodial wallets (you hold keys) require MSB registration in the US, VASP registration under FATF guidelines, and specific licensing in the EU (MiCA), UK (FCA), UAE (VARA) and other jurisdictions. MPC wallets with server-side key shares occupy a regulatory grey area that varies by jurisdiction. We strongly recommend legal review of your custody model before launch.
Can we add WalletConnect to an existing app?
Yes. WalletConnect v2 has React Native and web SDKs that integrate into existing React Native apps in approximately 2–3 weeks for basic connectivity and 4–6 weeks for full production integration including session management, transaction simulation display and error handling. The main complexity is transaction display — your app must parse and render arbitrary Ethereum transactions in a way users can understand before signing.
How do you secure the backend of a custodial wallet?
Custodial wallet backend security requires: private keys stored in HSM (AWS CloudHSM, Thales, or similar) never in application memory, transaction signing in an isolated signing service with no internet egress, multi-party approval for large withdrawals, rate limiting and anomaly detection on withdrawal requests, immutable audit logs for all signing operations, and regular penetration testing. The backend is the single point of failure — it must be designed with the assumption that every other layer will eventually be compromised.
