Most teams treat embedded wallets as a single integration, providing social onboarding for users to get a wallet and easily get started on blockchain rails. Deploying embedded wallets into your app can be achieved in a few days or less, but that framing sells the technology short.
What you build on top of embedded wallet infrastructure over the following weeks and months determines how much functionality that initial integration can actually support, from policy controls to yield or swap integrations. Each of these capabilities builds on the last, turning a basic wallet into a full financial product without forcing you to rebuild the integration from scratch.
Fireblocks offers embedded wallets through Dynamic, which it acquired in October 2025. To date, Dynamic has onboarded more than 50 million users to embedded wallets across every EVM network, every SVM network, Bitcoin, Sui, and TON. While embedded wallets are powerful from day one, the bigger gains show up over the next 90 days, as you layer on the recovery, policy, and stablecoin infrastructure that turns a basic wallet into a complete financial product.
Here is what a potential rollout looks like, from a working wallet on day one to a fully extended operation 90 days later:
Day 1: Users Onboard and Walk Away With a Non-Custodial Wallet
You can have working embedded wallets on day one of your integration. Your users sign in with email, phone, or a social account, and a wallet is spun up for them in the background. For most of your users, the wallet is invisible. They experience it as a normal account, while underneath they hold a real onchain wallet with full non-custodial ownership.
The architecture matters here, especially for large fintechs and exchanges whose top priority is security, staying compliant, and speed. Fireblocks embedded wallets are secured by TSS-MPC, a threshold signature scheme where a complete private key never exists in one place. A user share stays on the user’s device and a server share participates in signing inside a Trusted Execution Environment, so signing happens in a distributed manner. Signing runs sub-second, and users can independently recover their wallets if needed. You get the onboarding of a Web2 product without taking custody of anyone’s assets.
From day one, you also inherit the security and compliance posture that regulated industries expect: SOC 2 Type II certification, regular independent audits, and a bug bounty program. That’s the foundation in place before you write a single line of product code.
Week 1: Fund Wallets, Sponsor Gas, and Enable Chains
Within the first week, the wallet stops being an empty container. You enable the chains you care about, sponsor gas so users never have to hold a native token to transact, and set up funding options so users can easily move money in and out.
A few capabilities worth touching on during this window are:
- Gas sponsorship: You can pay transaction fees on users’ behalf and add approval logic. Users are able to transact immediately, without any friction around gas or network fees.
- Pre-generated wallets: You can create wallets for users before they ever authenticate, generated programmatically from your backend against an email or phone number. This means users can claim a wallet that already has funds waiting for them, before they’ve created an account.
- Bring your own auth: Teams already running Auth0, Firebase, Supabase, or their own auth provider do not need to migrate. Wire Dynamic into your existing JWT and your users get embedded wallets without any change to your current login flow.
By the end of week one, you have wallets that hold value and move it. Most teams get here in days, and what comes next is where the real product starts to take shape.
Month 1: Build the Product Users Come Back For
By the end of the first month, the goal is a product users actually transact through. The wallet stops being infrastructure and starts driving engagement. The capabilities to get there are all available to layer on in this phase:
- Accept crypto from anywhere: Fireblocks Flow lets users fund their wallet from any external wallet or exchange, settling in whatever stablecoin you choose. Cross-chain conversion happens automatically, so a user paying in ETH on Arbitrum can fund a USDC balance without any manual work.
- Earn: Idle balances can earn yield through vaults and lending markets routed to Aave, Morpho, and Sentora. Users deposit assets and earn interest, with positions tracked in real time.
- Cross-chain swaps: A single integration path lets users move between assets and chains without navigating bridges or protocols themselves.
- Spend with cards: You can issue virtual Visa debit cards funded directly by users’ stablecoin balances, so a balance becomes spendable anywhere Visa is accepted.
A month in, you are no longer demoing a wallet. You are running a money app, and you got there in weeks, not the months it would have taken building this from scratch.
Day 60: Controls, Resilience, and Scale
With your user base and balances growing, the next phase is operationalizing. The good news: most of this is configuration, not a rebuild. Policies and rules let you define exactly what wallets can and cannot do, enforced at signing time so nothing moves unless it passes your checks. You can:
- Run allowlists so wallets only interact with addresses you approve, and block transactions to addresses flagged as malicious
- Set value limits that cap how much moves in a single transaction.
- Use webhooks to stream policy violations and wallet events into your own systems, so activity flows into your SIEM and for compliance reporting and security monitoring.
Alongside policies, this phase is where you turn on the resilience features for scale: developer-hosted backups so enterprises keep key-share backup infrastructure under their own control, device registration to stop account takeovers, and step-up authentication or MFA to protect sensitive wallet actions.
This is the work that makes the rest of the rollout defensible. And for any team moving real money or operating in production, it is not optional.
Day 90: Automation and Agents
The 90-day mark is where embedded wallets stop being a user-facing feature and start being infrastructure your whole stack can build on. Two new directions open up here:
- Delegated Access: Your app can act on a user’s behalf, signing transactions for recurring payments, scheduled operations, or automated flows, while the user stays in full control and can revoke that access at any time. Approval happens through the user, a new key share is issued, and access never extends beyond the approved operations.
- Agentic payments: Agents get wallets that can pay for services autonomously or on behalf of an approved user. With HTTP 402 flows like x402, an agent can hit a paywalled API, pay, and retry without a human in the loop.
Ninety days in, you have moved from “users can log in” to a wallet that funds itself, defends itself, automates back-office flows, and powers agent-driven payments. None of that required rebuilding the integration you shipped in week one. To see what this looks like for your product, explore Fireblocks embedded wallets or book a call with our team to map the rollout to what you are building.
