Permissions & Signers

All of the account contracts [Simple, Dynamic and Managed] share the same permission model. In this section, we'll describe this permission model in detail.

Account Permissions

An account recognizes only two types of actors:

[1] Admins

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.

Assigning Admin Permissions

Existing admins on the account can add new admins, remove existing admins or renounce their own admin status.

This is done by simply calling the setAdmin function:

/// @notice Adds / removes an account as an admin.
function setAdmin(address account, bool isAdmin) external;

[2] Non-admins with permissions (Signers)

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.

Assigning Signer Permissions

Each individual signer has their own permissions to use the account. Admins set the permissions for signers.

A signers on an account are managed by the account admin and signers can be restricted to:

• Only call specific wallets with the account.
• Transfer a specific native token amount out of account.
• Only use the account in a specific time window.

These restrictions are set in the SignerPermissionsRequest struct. To set the permissions for a given signer, the setPermissionsForSigner function is called.

struct SignerPermissionRequest {
    address signer;
    address[] approvedTargets;
    uint256 nativeTokenLimitPerTransaction;
    uint128 permissionStartTimestamp;
    uint128 permissionEndTimestamp;
    uint128 reqValidityStartTimestamp;
    uint128 reqValidityEndTimestamp;
    bytes32 uid;
}

/// @notice Sets the permissions for a given signer.
function setPermissionsForSigner(SignerPermissionRequest calldata req, bytes calldata signature) external;

The function uses EIP-712 typed data signatures. That means an admin must fill and sign the SignerPermissionRequest payload and pass the payload and produced signature to the function. This is so that a bundler can be used to send the transaction while still being able to perform a permissions check.

Security note:

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.

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.

Account Factory Permissions

For all three types of account factory (simple, dynamic and managed), the following role exists:

• 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).

For Simple & Dynamic accounts, there is no permission control on the factory contract.

For Managed Account Factories, an extra role exists:

• EXTENSION_ROLE: Only a holder of this role can perform upgrades to the children account contracts created by the managed account factory.

SDK Usage