| description | Learn about delegation, the delegation lifecycle, and the Delegation Framework. | |||||
|---|---|---|---|---|---|---|
| sidebar_label | Overview | |||||
| toc_max_heading_level | 3 | |||||
| keywords |
|
Delegation is the ability for a MetaMask smart account to grant permission to another smart contract or externally owned account (EOA) to perform specific executions on its behalf. The account that grants the permission is called the delegator account, while the account that receives the permission is called the delegate account.
The Smart Accounts Kit follows the ERC-7710 standard for smart contract delegation. In addition, users can use delegation scopes and caveat enforcers to apply rules and restrictions to delegations. For example, Alice delegates the ability to spend her USDC to Bob, limiting the amount to 100 USDC.
You can create the following delegation types:
A root delegation is when a delegator delegates their own authority away, as opposed to redelegating permissions they received from a previous delegation. In a chain of delegations, the first delegation is the root delegation. For example, Alice delegates the ability to spend her USDC to Bob, limiting the amount to 100 USDC.
Use createDelegation to create a root delegation.
An open root delegation is a root delegation that doesn't specify a delegate. This means that any account can redeem the delegation. For example, Alice delegates the ability to spend 100 of her USDC to anyone.
You must create open root delegations carefully, to ensure that they are not misused.
Use createOpenDelegation to create an open root delegation.
A delegate can redelegate permissions that have been granted to them, creating a chain of delegations across trusted parties. For example, Alice delegates the ability to spend 100 of her USDC to Bob. Bob redelegates the ability to spend 50 of Alice's 100 USDC to Carol.
See how to create a redelegation guide to learn more.
An open redelegation is a redelegation that doesn't specify a delegate. This means that any account can redeem the redelegation. For example, Alice delegates the ability to spend 100 of her USDC to Bob. Bob redelegates the ability to spend 50 of Alice's 100 USDC to anyone.
As with open root delegations, you must create open redelegations carefully, to ensure that they are not misused.
Use createOpenDelegation to create an open redelegation.
When creating chains of delegations via redelegations, it's important to understand how authority flows and can be restricted.
- Each delegation in the chain inherits all restrictions from its parent delegation.
- New caveats can add further restrictions, but can't remove existing ones.
This means that a delegate can only redelegate with equal or lesser authority than they received.
The delegation flow consists of the following steps:
%%{
init: {
'sequence': {
'actorMargin': 30,
'width': 250
}
}
}%%
sequenceDiagram
participant Delegator
participant Delegate
participant Manager as Delegation Manager
participant Enforcer as Caveat enforcer
Delegator->>Delegator: Create delegation with caveat enforcers
Delegator->>Delegator: Sign delegation
Delegator->>Delegate: Send signed delegation
Note right of Delegate: Hold delegation until redemption
Delegate->>Manager: redeemDelegations() with delegation & execution details
Manager->>Delegator: isValidSignature()
Delegator-->>Manager: Confirm valid (or not)
Manager->>Enforcer: beforeAllHook()
Note right of Manager: Expect no error
Manager->>Enforcer: beforeHook()
Note right of Manager: Expect no error
Manager->>Delegator: executeFromExecutor() with execution details
Delegator->>Delegator: Perform execution
Note right of Manager: Expect no error
Manager->>Enforcer: afterHook()
Note right of Manager: Expect no error
Manager->>Enforcer: afterAllHook()
Note right of Manager: Expect no error
The delegator creates a delegation, configuring a scope and optional caveats that define the conditions under which the delegation can be redeemed.
The delegator signs the delegation, producing a verifiable signature that the Delegation Manager can later validate.
The delegator sends the signed delegation to the delegate. A dapp can store the delegation in the storage solution of their choice (such as a local database, Filecoin, or other databases), enabling retrieval for future redemption.
The delegate submits the signed delegation to the Delegation Manager by calling redeemDelegations() with the
delegation and execution details.
The Delegation Manager validates the input data by ensuring the lengths of delegations, modes, and
executions match. It also verifies delegation signatures, ensuring validity using ECDSA (for EOAs) or
isValidSignature (for contracts).
If the signature validation passes, the Delegation Manager executes the beforeHook for each caveat
in the delegation, passing relevant data (terms, arguments, mode, execution calldata, and delegationHash) to
the caveat enforcer.
If beforeHook validation passes, the Delegation Manager calls executeFromExecutor to perform the delegation's
execution, either by the delegator or the caller for self-authorized executions.
The Delegation Manager runs each caveat enforcer's afterHook and afterAllHook to verify post-execution conditions.
See how to perform executions on a smart account's behalf for a step-by-step guide.
The Smart Accounts Kit includes the Delegation Framework, a set of comprehensively audited smart contracts that collectively handle smart account creation, the delegation lifecycle, and caveat enforcement.
It consists of the following components:
| Component | Description |
|---|---|
| Delegation Manager | Validates delegations and triggers executions on behalf of the delegator, ensuring tasks are executed accurately and securely. |
| Caveat enforcers | Manage rules and restrictions for delegations, providing fine-tuned control over delegated executions. |