Dynamic
- Name: Dynamic
- URL: https://www.dynamic.xyz/
- Category: wallet-infrastructure company / embedded-wallet and identity operator / hosted signer workflow platform
- Tags: ethereum-ecosystem solana-ecosystem
- Summary: Dynamic belongs in
companies/because the useful question is notwhat does the SDK expose?in isolation. A named operator runs the dashboard environments, identity and auth workflow, embedded-wallet creation, session and API-scope controls, audit-log surface, recovery packaging, and the default signing stack many apps inherit. That makes Dynamic better read as a company-run wallet-control plane than as a standalone protocol or neutral account primitive. - What it does:
- Provides embedded-wallet infrastructure for apps that want wallet creation, auth, and user-wallet management without operating the stack themselves
- Packages low-level APIs together with prebuilt SDK and UI flows across web, mobile, server, and agent-facing integration paths
- Runs a dashboard-centered environment model where teams create accounts, configure environments, and manage the hosted wallet stack
- Exposes enterprise access controls such as SSO, scoped API access, and unified audit-log workflow around the signer and developer surface
- Supports external-wallet connectivity and multichain app integrations aimed at fintech, crypto, and stablecoin products
- Sells TSS-MPC, TEE-assisted security, recovery paths, and sub-second signing as one hosted operator shell rather than as a narrow cryptographic primitive
- Key claims:
- The homepage says Dynamic offers
wallet infrastructure that turns crypto demand into revenueand frames the product around fintech, crypto, and stablecoin apps that want users to trade, earn, pay, and move money on crypto rails - The docs welcome page says Dynamic provides
one complete wallet stackand tells teams to create an environment in the Dynamic dashboard, which is a direct signal that the real operating surface is a company-run control plane rather than a bare SDK - The wallet-infrastructure page says Dynamic supports enterprise-grade wallets powered by TSS-MPC, customizable thresholds, TEEs, and sub-second signing, which is useful because it locates key-management and signing policy inside one packaged vendor boundary
- The security page highlights SSO, scoped API access, and events plus audit logs, which makes the operator boundary more concrete than generic
embedded walletmarketing - The homepage and feature pages currently claim 50M+ users onboarded, 800+ external wallets supported, sub-second signing, and 99.9% uptime; those scale numbers are still vendor claims, but they reinforce that Dynamic should be read as active production infrastructure rather than a thin wrapper
- Dynamic’s security materials also say the company inherits Fireblocks’ security expertise, practices, and operational rigor, which is a reminder that vendor lineage and operator workflow are part of the trust story users actually inherit
- The homepage says Dynamic offers
- Whitepaper: No classic whitepaper or litepaper is the useful artifact here. The strongest primary materials are the homepage, docs portal, wallet-infrastructure page, and security page; the source capture for this split is saved in
../whitepapers/dynamic-company-primary-sources-2026-08-08.md. - Sources:
Internal linkages
- Product / legacy alias note: dynamic.
- Best adjacent hosted-wallet company reads: privy, turnkey, and dfns.
- Reusable lens: when a team sells a
complete wallet stack, the real leverage usually sits in identity, dashboard workflow, signing policy, recovery, and what the hosted operator makes easiest to ship by default.
Protocol / company boundary
- Keep dynamic only as a legacy alias for older links.
- Keep this entity note focused on the named operator boundary: dashboard environments, identity linking, session and API-scope controls, embedded-wallet workflow, audit-log visibility, recovery packaging, and the default signing stack apps inherit.
- That split matters because Dynamic is not usefully analyzed as a neutral protocol surface. The practical question is who runs the hosted auth-and-signing workflow and which defaults developers adopt when they use Dynamic instead of operating their own wallet stack.
Control surface
-
Practical leverage sits in dashboard and environment administration, identity linking, session issuance, API-scope controls, audit-log visibility, key-share and recovery policy, supported-wallet and chain packaging, and whatever signing or sponsorship defaults the app inherits.
-
The sticky dependency is not only MPC or TEE design. It is the company-run workflow around provisioning, policy, monitoring, and recovery.
-
Read Dynamic as a hosted wallet-and-identity operator boundary, not as a durable account primitive.
-
Last reviewed: 2026-08-08 UTC