​
What is an Embedded Wallet?

You can think of an embedded wallet like a powerful web-account. An embedded wallet is a programmable web3 crypto wallet that can be issued invisibly to customers on your website. Customers with an embedded wallet can immediately receive digital tokens and make on-chain interactions without needing to go through the complexities of understanding the intricacies of typical EOA wallets like metamask or Phantom.

Dynamic embedded wallets are fully non custodial.

​
Further Configuration

​
Multi-chain

Dynamic offers embedded wallets on EVM compatible networks and Solana. If you enable both, they will both be created at once and whichever you have marked as “primary” will be shown as the primary address in their profile upon sign in.

To enable embedded wallets for EVM or Solana networks the respective chains must also be enabled. You can find more information about enabling chains and networks here.

​
Signing & Security Methods

After the wallet is generated and attached to the user, they still need to authenticate with their embedded wallet in order to transact and sign. There are two ways you can allow them to do this:

  1. Passkey: The user will be prompted to create a passkey. This passkey will be used to sign transactions and messages. This is the default option.
  2. One Time Code: The user will be prompted to enter a one time code sent to their email. This code will be used to generate a session key which can sign transactions and messages.

If you are using SMS login, we highly recommend using passkeys over one time codes, read more here

​
Security Prompt Behavior

In this section of the dashboard you can choose whether the user needs to authenticate (“claim”) the embedded wallet at the point at which it’s first generated for them, or if this action should be deferred to when they send their first on-chain transaction or off-chain message.

If you toggle on the “On first transaction” option, a pre-generated wallet will be created for the user. They will be prompted to add a signing method when they need to use the wallet for the first time such as sending a on-chain transaction or signing an off-chain message.

That’s compared to the second option (“At initial signup”) which will require the user to add a signing method before they can continue with the sign-up flow.

Deferring can be very helpful if you want to reduce friction in the sign-up flow, but it’s important to note that if you choose this option, the user will not be able to sign messages or transactions until they have completed, however their wallet can still receive assets.

​
Manual Mode

Inside the dashboard configuration section for Dynamic wallet as-a-service, you will see that you are provided with the choice as to whether “Manual mode” is toggled on or off. When it is off (the default), the wallet creation flow will be triggered automatically during signup. If you toggle it on, you will need to trigger the wallet creation flow yourself. You can find more information about this in the creating wallets section.

​
Wallet recovery

You can learn more about this toggle in the Recovery guide here.

​
Content Security Policy (CSP)

Embedded wallets use iframes to provide one more security layer to the wallet. If you enforce CSP on your website, you will need to add the following to your frame-src directive:

​
Account Abstraction

You can turn these embedded wallets into smart contract wallets using our account abstraction feature.

Was this page helpful?

NFT/Token GatingCreate a wallet before signup (Pregeneration)