Overview
All of thirdweb’s smart wallets are EIP-4337 smart contract wallets with role-based permission control.
Users can deploy a smart wallet for individual use, and app developers can issue smart wallets to their users programmatically.
thirdweb’s smart wallets have the following features by default:
- Have multiple owners
- Execute transactions (single and batched).
- Send and receive native tokens.
- Send and receive ERC-721 and ERC-1155 NFTs.
- Multicall-able.
- Store contract metadata.
Choose the right smart wallet setup for your app. thirdweb offers the following three different kinds of smart wallets:
Simple | Dynamic | Managed | |
---|---|---|---|
Upgradeability | Non-upgradeable | Account upgrades controlled locally by account admin. | Account upgrades controlled centrally by the parent account factory admin. |
User persona | Developer wants to issue simple smart wallets to their users. They do not anticipate that users wallets will need any feature upgrades. | Developer wants to issue smart wallets to their users. They do anticipate feature upgrades to user wallets but do not want to push upgrades to user wallets without consent. | Developer wants to issue smart wallets to their users. They do anticipate feature upgrades to user wallets, and want to push upgrades to user wallets for seamless/invisible UX for upgrades. |
Simple smart wallets
Account.sol
& AccountFactory.sol
The Account
smart wallet is a simple smart wallet that comes with all the basic benefits of account abstraction, along with the mentioned default features.
App developers can issue Account
smart wallets programmatically by deploying an AccountFactory
smart contract.
The Account
smart contract is non-upgradeable. Developers should use this wallet if they do not anticipate making any future upgrades to their users’ wallets.
Dynamic Smart Wallets
DynamicAccount.sol
& DynamicAccountFactory.sol
The difference between DynamicAccount
smart wallet and Account
smart wallet is that DynamicAccount
is an upgradeable smart contract written in the dynamic contract pattern.
App developers can issue DynamicAccount
smart wallets programmatically by deploying a DynamicAccountFactory
smart contract.
The admin of a given DynamicAccount
smart wallet is allowed to make upgrades to their own smart wallets. This is the right wallet for developers who anticipate providing opt-in upgrades to their users’ wallets.
Example Use Case of Opt-In Upgrades:
A game with in-game NFT items wants to offer its players the ability to store their NFT items in a staking vault as soon as their wallets receive these NFTs. This would be an upgrade to the smart wallet contract’s onERC721Received
and onERC1155Received
transfer hooks.
The game can provide this upgrade as an opt-in upgrade to their players.
Managed Smart Wallets
ManagedAccount.sol
& ManagedAccountFactory.sol
Like DynamicAccount
, the ManagedAccount
smart wallet is an upgradeable smart contract written in the dynamic contract pattern.
App developers can issue ManagedAccount
smart wallets programmatically by deploying a ManagedAccountFactory
smart contract.
The admin of the ManagedAccountFactory
contract can push upgrades to all ManagedAccount
that it creates. This admin does not require any permissions on the ManagedAccount
smart wallets to do so. An upgrade to the features of ManagedAccount
applies to all ManagedAccount
smart wallets created by the factory. This is the right wallet for developers who anticipate pushing upgrades to their users’ wallets.
Example use case of push upgrades:
An app wants its user wallets to only be able to own NFTs within its ecosystem. This would be an upgrade to the smart wallet contract’s onERC721Received
and onERC1155Received
transfer hooks.
The app can enforce this behaviour by pushing this upgrade to its user wallets.