EMBEDDED WALLET DEVELOPMENT
PROPELOO engineers embedded wallet systems — social/email login wallet creation, key management without seed phrase exposure, account abstraction (ERC-4337) for gasless transactions, wallet-to-wallet recovery mechanics, and the UX that makes blockchain interactions invisible to non-crypto users. An embedded wallet is not a wallet with a nice UI — it is the elimination of wallet friction from your application.
The most common reason non-crypto users do not use blockchain applications is not lack of interest — it is the wallet UX barrier. Asking users to install MetaMask, write down a 12-word seed phrase, and understand gas fees before they can use your application filters out 95% of potential users. Embedded wallets invert this: the user signs up with email or Google, a wallet is created automatically, and all blockchain interactions happen transparently through your application interface. The user never sees a seed phrase. They never pay gas manually. They never approve transactions in a separate browser extension. The blockchain is infrastructure they never think about. PROPELOO builds embedded wallet systems using account abstraction (ERC-4337) and modern key management approaches — social recovery, threshold signatures, and device-based key sharing — that preserve user custody without exposing seed phrase complexity.
Authentication, key management, transaction sponsorship and recovery are each distinct problems.
Login with Google, Apple, Twitter, Discord, email OTP, phone SMS. Wallet created automatically on first login — user never sees the wallet creation process. Existing users who connect an external wallet can link it to their social login account.
Three-shard key approach: shard 1 on device secure enclave, shard 2 in encrypted cloud backup, shard 3 with the authentication provider (Privy/Dynamic). Transaction signing requires 2-of-3 shards. User never sees the key or a seed phrase.
Smart contract wallet instead of EOA. Benefits: gas sponsorship (paymaster covers gas), transaction batching, session keys (limited time/scope signing permission), social recovery at contract level. Bundler submits UserOperations to chain.
Paymaster contract sponsors gas for user transactions. User pays in application credits, fiat card, or ERC-20 token — never in native ETH/MATIC. Gas abstraction removes the single biggest friction point for non-crypto users.
Social recovery: user designates guardians (friends, other devices) who can approve recovery. Email recovery: OTP-based re-authentication allows key reconstruction. Device recovery: new device added to key sharing arrangement.
In-app transaction confirmation UI — clear description of what the transaction does (not raw hex data). Spending limits and approval workflows. Transaction history with human-readable descriptions. No external wallet app required.
The goal is not to simplify the wallet — it is to eliminate the wallet as a concept the user must understand.
Seed phrases are the primary source of permanent user key loss. An embedded wallet that distributes key material across device, cloud backup, and authentication provider eliminates single-point-of-failure key loss while preserving user custody. The user cannot lose their wallet by losing a piece of paper.
Axiom: ELIMINATE SEED PHRASE RISK
EOA wallets require ETH for gas. Asking non-crypto users to acquire ETH before they can use your application is a conversion killer. ERC-4337 smart wallets with paymaster gas sponsorship allow users to interact with the blockchain without ever holding ETH — the application sponsors the gas, the user pays in whatever currency makes sense for the product.
Axiom: GAS ABSTRACTION IS TABLE STAKES
A new user joining a blockchain game should not see wallet addresses, transaction hashes, or block explorers unless they want to. Start with simple in-app asset display and invisible transactions. Offer advanced features (export to MetaMask, external wallet view) for users who want them. Never show blockchain complexity to users who did not ask for it.
Axiom: BLOCKCHAIN INVISIBLE BY DEFAULT
These choices define custody model, recovery options and developer integration complexity.
Impact: Integrate Privy or Dynamic for most applications — the engineering investment to build embedded wallet infrastructure from scratch is rarely justified unless you are building a WaaS product. Build from scratch only when vendor pricing, data residency, or feature requirements make integration untenable.
Impact: ERC-4337 for new products targeting non-crypto users — the gasless UX benefit outweighs the slightly higher gas cost. EOA with gas relay for products where transaction count is very high and marginal gas cost matters.
Impact: Three-shard approach for consumer applications balancing custody and recovery. Full custodial for enterprise or FinTech where compliance requires platform control. Hardware-backed for high-security contexts where user accepts no-recovery risk.
Impact: Email OTP as primary (highest user familiarity). Social recovery for advanced users. Backup phrase export as optional escape hatch for users who want to migrate to external wallets.
Full embedded wallet — social login, invisible key management, gasless transactions, in-app asset display, custom UX.
Invisible wallet for blockchain game — players use game assets (NFTs, tokens) without seeing wallet UX. Account abstraction for gasless game actions.
Embedded crypto wallet inside a FinTech application — users can hold and transact crypto without leaving the financial application.
White-label embedded wallet SDK for enterprise applications — customisable UX, compliance controls, admin wallet management.
Authentication, account abstraction, and seamless UX.
Stack: Privy / Dynamic (provider), Auth0 (enterprise), JWT session management, Social OAuth (Google, Apple), Email/SMS OTP
Stack: ERC-4337 smart wallet, Alchemy / Pimlico bundler, Paymaster contract, UserOperation SDK, Session key management
Stack: Device secure enclave, Encrypted cloud backup, Three-shard architecture, Social recovery contract, Key rotation
Stack: React / React Native, In-app transaction UI, Asset display, Transaction history, On-ramp (MoonPay)
The security model must work even when the user loses their phone, changes their email, or leaves the application.
Each key shard encrypted independently. Device shard in secure enclave (inaccessible to malware). Cloud shard encrypted with user-derived key. Auth provider shard requires active authentication session.
Email recovery flow must be protected against SIM swap and email account takeover. Time delays on recovery, additional factor verification (trusted device confirmation), and notification of recovery initiation reduce attack surface.
Paymaster contracts that sponsor unlimited gas are vulnerable to drain attacks. Per-user spending limits, per-application daily caps, and transaction simulation before sponsorship prevent paymaster exploitation.
Session keys (delegated signing permissions) must be scoped: maximum spend per session, allowed contract addresses, allowed functions. An overly broad session key is equivalent to giving an attacker full wallet access.
Authentication flows, transaction confirmation UI, recovery UX, progressive disclosure design.
Social login, wallet creation on signup, session management.
Shard architecture, device enclave, cloud backup, auth provider integration.
Smart wallet deployment, bundler integration, paymaster setup.
Paymaster policy, spending limits, application gas budget.
Email recovery, social recovery, device recovery flows.
Non-crypto user testing, recovery scenario testing, edge case validation.
With three-shard architecture, the user owns the wallet — the key is shared between the device (under user control), cloud backup (encrypted with user credentials), and the authentication provider. No single party (including the application) has the full key. The user can export the key at any time and use it in any external wallet. This is different from a fully custodial model where the application holds the key.
We design embedded wallets with key exportability as a requirement. Users can export their private key to any standard wallet at any time. If the provider shuts down, users have enough notice to export before the service ends. We also implement backup key shards in user-controlled storage as an additional safeguard.
The user signs a UserOperation (ERC-4337 transaction format). The bundler receives the UserOperation, the paymaster contract verifies it meets the sponsorship policy (within daily limit, allowed contract), and the paymaster pays the gas. The user never holds ETH. The application configures and funds the paymaster contract.
Yes. We implement both embedded wallet (for new users) and external wallet connection (for existing crypto users). External wallet users can link their MetaMask address to their social login for a unified profile, or choose to use their external wallet exclusively.
Session keys allow users to pre-authorize temporary, scoped permissions for an application (e.g., execute in-game transactions up to 50 USDC over 2 hours). The client signs once at session start, and subsequent game moves or micro-trades execute instantly in the background without intrusive approval modals.
Yes. Because embedded wallets leverage ERC-4337 smart contract accounts, users can bundle multiple operations into one atomic transaction (e.g., approve token, swap on DEX, and deposit LP tokens simultaneously), saving gas and eliminating multistep approval prompts.
We provide native SDKs for React Native, Flutter, Swift (iOS), and Kotlin (Android). Key shares are stored inside platform-native secure hardware (Apple Secure Enclave and Android Keystore) with biometric verification (Face ID, Touch ID) for signing transactions.
The developer console provides real-time telemetry on user onboarding funnel conversion, active wallet sessions, daily gas sponsorship spend, transaction throughput, drop-off rates during KYC/on-ramping, and aggregate asset holding distributions across cohorts.