You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 5, 2024. It is now read-only.
* add Krishang's table
* add tables to how it works
* add signers page
* add info on factory contracts & initializing accounts with an personal wallet key
* add account, key & wallet terms
* remove unused file
|**Upgradeability**| Non-upgradeable | Account upgrades controlled locally by account admin. | Account upgrades controlled centrally by account factory admin.|
23
+
|**Upgradeability**| Non-upgradeable | Account upgrades controlled locally by account admin. | Account upgrades controlled centrally by the parent account factory admin. |
24
24
|**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. |
In order to issue smart wallet account contracts for users, an account factory contract must be deployed.
47
+
A factory contract is a contract which clones an implementation contract which defines the functions and logic on the clone.
48
+
49
+
To create accounts with the factory contract, the `createAccount` function is called. This function calls `_initializeAccount`
50
+
which initializes the account and sets the default admin on the account.
51
+
52
+
## One Account Per Personal Wallet
53
+
54
+
The thirdweb Account Factories are designed so that only one account can be created per personal wallet key.
55
+
This means that any one personal wallet can only be a default admin on one account per factory.
56
+
57
+
This is because, when the account contract is cloned by the factory, the account is craeted deterministically
58
+
via the `cloneDeterministic` function. This function takes a `salt` as a parameter to predict the deployment address. The `salt` is calculated using the
59
+
default admin address. Since the deployment address will be the same if the default admin is the same, if an account
60
+
already exists at that address, the transaction will revert.
|**Upgradeability**| Non-upgradeable | Account upgrades controlled locally by account admin. | Account upgrades controlled centrally by the parent account factory admin. |
92
+
|**Expected Usage**| 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. |
All of the account contracts [[Simple](https://thirdweb.com/thirdweb.eth/AccountFactory), [Dynamic](https://thirdweb.com/thirdweb.eth/DynamicAccountFactory) and [Managed](https://thirdweb.com/thirdweb.eth/ManagedAccountFactory)] share the same permission model. In this section, we'll describe this permission model in detail.
7
+
8
+
## Account Permissions
9
+
10
+
An account recognizes only two types of actors:
11
+
12
+
### [1] Admins
13
+
14
+
Admins have **unrestricted access** to the account; call any functions on the contract, use the contract without going through the ERC-4337 infrastructure (bundlers, EntryPoint, etc.), withdraw the account's native token balance, and so on.
15
+
16
+
### Assigning Admin Permissions
17
+
18
+
Existing admins on the account can add new admins, remove existing admins or renounce their own admin status.
19
+
20
+
This is done by simply calling the `setAdmin` function:
21
+
22
+
```solidity
23
+
/// @notice Adds / removes an account as an admin.
24
+
function setAdmin(address account, bool isAdmin) external;
25
+
```
26
+
27
+
### [2] Non-admins with permissions (Signers)
28
+
29
+
Signers must go through ERC-4337 infrastructure (bundlers, EntryPoint, etc.) to use an account to execute transactions. Signers can use an account under certain restrictions.
30
+
31
+
### Assigning Signer Permissions
32
+
33
+
Each individual signer has their own permissions to use the account. Admins set the permissions for signers.
34
+
35
+
A signers on an account are managed by the account admin and signers can be restricted to:
36
+
37
+
- Only call specific wallets with the account.
38
+
- Transfer a specific native token amount out of account.
39
+
- Only use the account in a specific time window.
40
+
41
+
These restrictions are set in the `SignerPermissionsRequest` struct.
42
+
To set the permissions for a given signer, the `setPermissionsForSigner` function is called.
43
+
44
+
```Solidity
45
+
struct SignerPermissionRequest {
46
+
address signer;
47
+
address[] approvedTargets;
48
+
uint256 nativeTokenLimitPerTransaction;
49
+
uint128 permissionStartTimestamp;
50
+
uint128 permissionEndTimestamp;
51
+
uint128 reqValidityStartTimestamp;
52
+
uint128 reqValidityEndTimestamp;
53
+
bytes32 uid;
54
+
}
55
+
56
+
/// @notice Sets the permissions for a given signer.
57
+
function setPermissionsForSigner(SignerPermissionRequest calldata req, bytes calldata signature) external;
58
+
```
59
+
60
+
The function uses [EIP-712](https://eips.ethereum.org/EIPS/eip-712?ref=portal.thirdweb.com) typed data signatures. That means an admin must fill and sign the `SignerPermissionRequest` payload and pass the payload and produced signature to the function.
61
+
This is so that a bundler can be used to send the transaction while still being able to perform a permissions check.
62
+
63
+
#### Security note:
64
+
65
+
A signer cannot have 'catch-all' permissions where they can call any target contract, or transfer any amount of native tokens. This is an important security consideration, since it is common (unfortunately) for private keys to get lost or leaked. In this way, the account encourages usage through purposeful signer keys.
66
+
67
+
Even though an account may have 'recovery', having your admin keys leaked means whoever has your admin keys has unrestricted control over the smart wallet.
68
+
69
+
## Account Factory Permissions
70
+
71
+
For all three types of account factory (simple, dynamic and managed), the following role exists:
72
+
73
+
-`DEFAULT_ADMIN_ROLE`: Only a holder of this role is eligible to set the contract metadata of the account factory (i.e. name, description, image and any other metadata to associate with the contract).
74
+
75
+
**For Simple & Dynamic accounts, there is no permission control on the factory contract.**
76
+
77
+
For Managed Account Factories, an extra role exists:
78
+
79
+
-`EXTENSION_ROLE`: Only a holder of this role can perform upgrades to the children account contracts created by the managed account factory.
0 commit comments