JAW vs Dynamic: where keys, accounts and permissions live

A new user opens your app on their phone. With JAW, they choose a username and confirm with Face ID or a fingerprint. That one step creates their passkey and their smart account, and, if your app has an ENS name, a name of their own such as alice.yourapp.eth [25], [26]. The next time they approve a payment, it is the same passkey prompt [23].

With Dynamic, the same user signs up with email, SMS, a social account or an existing wallet, and Dynamic creates an embedded wallet once they have authenticated [3], [5].

Both are good ways to put a wallet in an app, and they are built for different jobs. Dynamic is a broad wallet and login platform: many chains, many login methods, onramps and native mobile SDKs, and part of Fireblocks since October 2025 [2], [18], [19], [21]. JAW goes deep on one thing: smart accounts on EVM networks and Solana, where the passkey is the signer, every key the user delegates to is held to its limits onchain, and a lost passkey can be replaced through recovery methods the user picks, from guardians to zkEmail, zkOAuth and zkPassport [35], [39], [49]. This post compares the two where they overlap, and says plainly where each is the better choice.

At a glance

User experience

A passkey from the first tap. A JAW user signs up with a username and a passkey, and the account and its name are created together, with "no separate 'now set up your ENS name' step" [26]. Dynamic supports passkeys for signing in, but "a user cannot create an account with a passkey", so passkeys come after an email, SMS or social sign-up [4].

One passkey for EVM and Solana. The same passkey also signs on Solana, where each JAW account is a Swig smart wallet with the passkey as its signer [50]. Sign-up gives the user an EVM address, a Solana address and one ENS name that resolves to both, from a single passkey prompt. Fees on Solana can be paid in SOL, USDC or USDT, and Solana apps that embed JAW find it as a standard Solana wallet through Wallet Standard.

One prompt, or none. At JAW, the passkey is the signer, so the prompt that signs a user in is the same kind of prompt that approves a transaction [23]. For flows that should not ask every time, the user approves a permission once, "and subsequent interactions don't require individual biometric prompts" until it expires [36].

Wallet screens, or your own. On the web, JAW ships the screens for sign-in, transaction approval and permission grants, with your app's name, logo, colors and font style [28]. The approval screen decodes calls to known contracts and previews the balance changes before the user approves [29]. Teams that want full control can build their own UI or go headless with the Account class [30], [31]. Dynamic recommends its JavaScript SDK for new web apps, and that SDK "is headless: there is no built-in modal, wallet picker, or login form. You build all UI yourself" [6], [7]. It gives teams a solid simulation API, with expected asset changes and a Blockaid security verdict, to build their own review screen on [8]. Dynamic's ready-made web widget lives in its React SDK, which it now labels legacy [7].

One account across apps. In JAW's default mode, "the same wallet can be used across any app using CrossPlatform mode" [27]. Dynamic's JavaScript SDK "does not support global wallets yet", and its wallets "are scoped to your own app" [9].

Gas in stablecoins, picked at approval. When the app does not sponsor gas, JAW's built-in screens let users pay it in stablecoins such as USDC or USDT, with no setup from the app [32], [33]. On Dynamic, paying gas in an ERC-20 token goes through ZeroDev [10], which starts with "a Zerodev account and projects for each network you want to support" [11].

Permissions, subscriptions and AI agents

This is the biggest difference for any product that moves money without a click per transaction.

Dynamic's policies are allow and deny lists of addresses, plus a value limit on "the maximum amount that can be transferred in a single transaction", checked in a trusted execution environment at signing time [13]. Anything beyond that, such as a monthly budget, a team builds in its own backend with Dynamic's transaction review webhooks [14]. To let a backend or agent act for a user, Dynamic offers delegated access, which gives the developer a key share and a per-wallet API key, and needs the Enterprise plan in production [15].

JAW puts the limit in the account. With wallet_grantPermissions, an API based on ERC-7715, a user grants a key a spend limit per token that resets every minute up to every year, the contracts and functions it may call, and an expiry [37]. "The PermissionManager smart contract validates every transaction at the contract level" [39], and any permission "can be revoked instantly" [36].

A per-transaction limit caps each payment. A budget caps the total over time, which is what these need:

• Subscriptions. The user approves a cap such as 10 USDC a month. The service charges each month with no user interaction, and the user cancels by revoking the permission [38].
• AI agents. "A human approves once during setup, and the agent runs autonomously after that within scoped, on-chain permissions". If the agent's key leaks, "damage is bounded" [39]. JAW's CLI includes an MCP server for agents [40], and agents can pay for APIs in USDC over x402 [41].

Dynamic's agent docs offer server wallets, agent wallets and delegated access, and its server wallets can pay for APIs through HTTP 402 flows, including x402 [16]. The difference is where the limit lives: with JAW, the agent gets a budget inside the user's own account, and a contract enforces it.

Recovery

If a user loses every device that holds their passkey, JAW recovery gets them back into the same account, at the same address [49].

• Methods the user picks. Ahead of time, the user chooses how they can get back in and how many of those methods must approve. The options are guardians, such as a friend's passkey or a hardware wallet key; zkEmail, for an email address; zkOAuth, for a social login such as Google; and zkPassport, for a passport. The zk methods (coming soon) prove control without putting the email, the account or the passport details onchain [49].
• A time-lock with a veto. An approved request waits through a delay, and the account can cancel it during that window. After the delay, the new passkey is added to the account [49].
• Permissionless. "The proofs carry authorization, so a relayer can request and execute on behalf of a locked-out user." The recovery contract has no owner and cannot be upgraded, so nobody at JAW approves a recovery or holds a recovery key [49].
• Every chain at once. Each method approves once, and the same approval recovers the account on every EVM chain it enrolled [49].

Dynamic's recovery protects the key share instead: a Google Drive backup, a wallet password, or offline recovery that pairs a share in the user's Google Drive with one the developer holds [20]. Recovery covers JAW's EVM accounts, not Solana accounts.

Developer experience

Every JAW account is an ERC-4337 smart account from the start [35]. To sponsor gas, a team plugs in a paymaster such as Pimlico or Etherspot [32]. On Dynamic, sponsored gas uses a one-time EIP-7702 delegation to Dynamic's contract, works only with its V3 MPC wallets, and needs the Enterprise plan on mainnet [12]. ERC-4337 smart wallets go through ZeroDev [11].

JAW is a standard EIP-1193 provider: "If your app works with MetaMask, it works with JAW" [22]. With wagmi, it is one connector [42]:

import { createConfig, http } from 'wagmi';
import { mainnet } from 'wagmi/chains';
import { jaw } from '@jaw.id/wagmi';

const config = createConfig({
  chains: [mainnet],
  connectors: [jaw({ apiKey: 'YOUR_API_KEY' })],
  transports: {
    [mainnet.id]: http(),
  },
});

From there, the app uses the wagmi hooks it already knows, such as useSendCalls, plus useGrantPermissions and useRevokePermissions for permissions [43], [37]. Dynamic also works with wagmi, through its own sync package [17]. For backends and React Native, JAW's Account class runs headless [31], [44]. The SDK is open source under Apache-2.0, and the account and permission contracts are open source under MIT and audited by Nethermind [46], [47].

Keys

Dynamic splits signing between a share on the user's device and a share Dynamic uses inside a trusted execution environment, and "the complete private key never exists, even within the TEE" [1]. It is careful engineering. JAW has no shares: the passkey is created in the device's secure enclave, and "there is no session token that, if stolen, grants signing access" [23]. JAW's servers keep only passkey metadata such as credential IDs and public keys [24].

Where Dynamic is a better fit

• More chains. Bitcoin, Sui, TON, Stellar and more, on top of EVM and Solana [2]. JAW covers EVM networks and Solana [34], [50].
• Login choices. Email, SMS, social login and external wallets [3]. JAW signs users in with a passkey [23].
• Native mobile apps. Swift, Kotlin and Flutter SDKs with a built-in sign-in UI, plus React Native and Unity [19], [7]. JAW supports React Native through its headless Account class [44].
• Getting money in. Card and bank onramps from providers such as Banxa, Coinbase and MoonPay, plus swaps [18]. JAW's add-funds screen shows a deposit address and QR code, with no card or bank onramp [45].

Using JAW alongside Dynamic

Adding JAW does not mean removing anything. JAW is a standard wagmi connector [42], and JAW's Reown AppKit guide shows it next to other wallets, with the same wagmi hooks working whichever one the user picks [43]. A team can keep Dynamic for Bitcoin and the other chains JAW does not cover, or for fiat onramps, and give its EVM and Solana users JAW accounts with passkeys, onchain permissions and names [23], [36], [26].

Pricing

Dynamic prices by monthly active users, and has no free plan for production: every account gets a free sandbox for building and testing, and going live needs a paid plan. The self-serve Growth plan is $249 a month for up to 5,000 users, then $0.05 for each additional one. A user counts "if they log in at least once a month or when an embedded wallet (including pre-generated wallets) is created for them". Gasless transactions and delegated access are on the Enterprise plan [21].

JAW prices by credits, used when accounts act. The Build plan is free with 125,000 credits a month for up to 1,500 accounts, and the Grow plan is $200 a month for 1,000,000 credits. Creating an account or sending a transaction uses 30 credits, a signature or a permission change 20, and signing in to an existing account uses none [48]. Dynamic's price list was checked on October 16, 2026, and JAW's on October 9, 2026.

Which one to choose

Choose Dynamic if you need chains beyond EVM and Solana, email or social login, native mobile SDKs or fiat onramps.

Choose JAW if you build on EVM or Solana and want passkey sign-up, wallet screens you can use or replace, one account across apps, budgets over time that the blockchain enforces for subscriptions and AI agents, recovery for EVM accounts through guardians, zkEmail, zkOAuth or zkPassport, with no provider in the loop, and stablecoin gas without extra setup.

To try it, get an API key at dashboard.jaw.id and start with the docs.

Sources

All accessed October 9, 2026, except 16 and 21, rechecked on October 16, 2026.

Dynamic sources 1 to 21, JAW sources 22 to 50

1. MPC architecture: https://www.dynamic.xyz/docs/embedded-wallets/mpc/architecture
2. Chain support: https://www.dynamic.xyz/docs/embedded-wallets/chains/overview
3. Authentication methods: https://www.dynamic.xyz/docs/auth/dynamic-auth/auth-methods
4. Passkey sign-in and registration: https://www.dynamic.xyz/docs/javascript/building-ui/passkey-sign-in-registration
5. Embedded wallets quickstart: https://www.dynamic.xyz/docs/javascript/wallets/embedded-wallets/quickstart
6. React quickstart for the JavaScript SDK: https://www.dynamic.xyz/docs/javascript/reference/react-quickstart
7. Docs index (SDK list, React SDK marked legacy): https://www.dynamic.xyz/docs/llms.txt