Dynamic Embedded Wallets

​

Setting things up

In V1 of the SDK, using Embedded Wallets is as simple as one, two, three, four!

That’s it! By default, we will launch the wallet creation flow after the user confirms OTP. It will look like the following:

​

Passkeys

By default, the user with authenticate for their embedded wallet using Passkeys (which interact via secure enclaves). Passkeys and secure enclaves are ideal for mobile-first application experiences and cross-device use cases.

By simple analogy, passkeys and secure enclaves are similar to a safety deposit box vault. That is, your end users have a key to access their locked box (i.e., wallet), while enjoying the benefits of having the box secured with vault-level security. The safety deposit box is inside the vault, but only the end user, with their key, can access the contents inside the box.

Once a user completes authentication (email or social), they will receive a prompt to create a passkey (TouchID, FaceID), after which they will automatically get a wallet, and can sign transactions using that passkey.

Since passkeys are synced using a keychain (e.g. iCloud, Google Password Manager, 1Password), end-users can use their passkeys across other devices once they authenticate.

​

Important notes

​

Defer Passkey Creation

You will find a section under the embedded wallet configuration called “Wallet Claim Behaviour”. In this section 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 pregenerated wallet will be created for the user. They will be prompted to add a passkey 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 passkey 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 added a passkey, however their wallet can still receive assets.

​

Defer Wallet Creation

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 “Hooks and Callbacks” section below.

​

Hooks and Callbacks

If you have chosen Manual wallet creation, you will need to trigger the wallet creation flow yourself. To do this, you can use the new “createEmbeddedWallet” hook. Here’s an example!

import { useEmbeddedWallet } from “@dynamic-labs/sdk-react-core”

const { createEmbeddedWallet, userHasEmbeddedWallet } = useEmbeddedWallet();

const onClick = async () => {
    if(!userHasEmbeddedWallet()) {
      try {
        const walletId = await createEmbeddedWallet();
        // do whatever you want with that Id
      } catch(e) {
        // handle error
      }
    }
}

return (
    <button onClick={() => onClick()}>Create Wallet</button>
)

You can find the complete specification of this hook in the SDK reference section here.

There is also a callback available for you if you need to hook into the action of a wallet being successfully created. It’s called “onEmbeddedWalletCreated” and the spec can be found here.

​

Account Abstraction

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

​

Technical Deep Dive

You have installed the Dynamic SDK, chosen your end-user auth method, and enabled embedded wallets. The End User comes to your website and initiates account creation, what actually happens now?

1. Dynamic authenticates the End User via Email OTP or Social Sign-in.
2. After authentication, the user is prompted to create a passkey, which leads to embedded wallet creation.
3. The user’s device requests a biometric. A passkey is generated.
4. Dynamic sends a Challenge (a random sequence of numbers of letters), which is automatically signed, forming a signature to confirm user control. The user’s credential is safeguarded in their device’s enclave.
5. Post-signature, Dynamic instructs Turnkey, our non custodial key management provider to create a wallet.
6. Turnkey checks passkey details and links them with the user, an action encrypted in an AWS Nitro Enclave. Dynamic receives a UUID to associated the key with its user.
7. With a confirmed wallet, users can secure transactions using the passkey.

For more details about storage in the AWS Nitro Enclave see docs here

​

Q&A