Migration from one auth and embedded wallet provider to another can seem daunting. You have users, they might have wallets, and a subset of them will have assets in their wallets, making it a fun adventure of a migration. But have no fear! We can help. Below, we put together a guide on migration strategies you can think through depending on your use case. At the end of the guide you’ll also find some helpful tips and techniques to ensure the migration all goes smoothly.
When in doubt, talk to us. Migrations can get complex, and we’d love to help
guide you through them. You can set up a call with us
here
If you don’t want to migrate yet, but want to take advantage of Dynamic on top of your existing provider, you can also use our Third Party Authentication feature.
We put together a simple flow chart to help you identify the right migration strategy:
You pretty much just swap out the modals. If you use wagmi, add our wagmi connector and follow our rainbowkit guide, but in general, no migration needed. After the initial update to the Dynamic modal, you can stay on our connect-only mode and not store any user info with Dynamic, or alternatively start adding more sophisticated features.
You built your own front end wallet connector or use Rainbowkit/ConnectKit, and in addition implemented a SIWE on your own, authenticating users and creating sessions for them.
For front end changes, you can follow path A above. In addition, you can use our create wallet endpoint to generate users and add wallet records to them. When they first log in, they will verify wallet ownership via SIWE (we provide that and return a JWT - you don’t need to do this), and you’re done.
You use Auth0, Firebase or another web2 user management system, or alternatively created something on your own. You store your users’ emails and basic info.
For any profile information that Dynamic does not yet explicitly support, you can add these in the user.metadata, which is a key-value object
When they log in, we verify their emails
And that’s it. You’re done. When your users log in next time around, we will verify their email addresses/social login information independently as part of the auth flow, and issue a JWT once you have successfully logged in.
Your users have an EOA embedded wallet, but it only serves as a signer for an AA layer (safe, zerodev etc).
Hence, you’ll want to add the Dynamic-powered embedded wallet as a second signer to the AA layer, or alternatively swap signers from the old embedded wallet one to the Dynamic one
Main activities
You’ll want to have the end user add their new Dynamic wallet as a second signer to the smart contract wallet, or alternatively have them replace the current signer with a second signerSteps
This is non-trivial, and we recommend that we chat before starting this
process. You can book time here
If your users have assets in their existing embedded wallets, then you’ll want to ensure they move those over to their new Dynamic-powered embedded wallets. To do this, you’ll want to build a migration flow for your users either using your own UI to prompt asset transfer (recommended), or by sending them to a tool such as BulkSender.
As you import your users into Dynamic, you may want to notify other systems and take further action - webhooks allow you to do exactly this. We have events such as user.created, user.updated, wallet.created and many more (find the full list here).Setting them up is as simple as providing a URL to post to in the Dynamic Dashboard and selecting which events you’d like to subscribe to (there’s a full guide here).