ERC-7710: Smart Contract Delegation

Abstract

---

This proposal introduces a standard way for smart contracts to delegate capabilities to other smart contracts or Externally Owned Accounts (EOAs). The delegating contract (delegator) must be able to authorize a DelegationManager contract to call the delegator to execute the desired action.

This framework empowers a delegating contract with the ability to delegate any actions it has the authority to perform, thereby enabling more flexible and scalable contract interactions. This standard outlines the minimal interface necessary to facilitate such delegation.

Additionally, this proposal is compatible with ERC-4337, although its implementation does not necessitate ERC-4337.

Motivation

---

The development of smart contracts on Ethereum has led to a diverse array of decentralized applications (dApps) that leverage composability to interact with one another in innovative ways. While current smart contracts are indeed capable of working together, enabling these interactions, especially in the realm of sharing capabilities or permissions, remains a tedious and often gas-expensive process, which lacks backwards compatibility.

Currently, for a smart contract to interact with or utilize the functionality of another, it typically requires hardcoded permissions or the development of bespoke, intermediary contracts. This not only increases the complexity and development time but also results in higher deployment and execution gas costs. Moreover, the rigid nature of these interactions limits the ability to adapt to new requirements or to delegate specific, limited permissions in a dynamic manner.

Additionally, the need to repeatedly sign messages for each interaction creates friction in user experiences, particularly in scenarios requiring frequent or automated interactions.

The proposed standard aims to solve these challenges by enabling the creation of long-lived sessions and delegated permissions through a single signature. These delegations can be used to:

• Establish persistent sessions with dApps that don't require repeated signing
• Grant bounded permissions to AI agents or automated systems
• Create shareable invite links with specific capabilities
• Enable third-party delegates to act within well-defined policy constraints

By allowing the creation of open-ended yet policy-constrained delegations with a single signature, this standard helps minimize user interactions while maximizing their meaningful content. Users can grant specific capabilities with clear boundaries, rather than repeatedly signing similar permissions.

The proposed standard aims to simplify and standardize the process of delegation between contracts, reducing the operational complexity and gas costs associated with shared capabilities. By establishing a common framework for delegating permissions, we can streamline interactions within the Ethereum ecosystem, making contracts more flexible, cost-effective, and adaptable to the needs of diverse applications. This opens up new possibilities for collaboration and innovation, allowing dApps to leverage each other's strengths in a more seamless and efficient manner.

Specification

---

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Terms

• A Delegator is a smart contract that can create a delegation.
• A Delegation Manager is a smart contract that validates delegation authority and calls on the Delegator to execute an action. It implements the ERC7710Manager interface. A Delegation Manager verifies and processes delegation redemptions, and multiple Delegation Managers can exist with different implementations. A contract account can be its own delegation manager.
• A delegation is an authority given to another address to perform a specific action.
• A delegate is a smart contract, smart contract account, or EOA that has authority to redeem a delegation.
• A redeemer is a delegate that is using a delegation.

Obtaining Delegations

The process by which a delegate obtains a delegation is intentionally left out of scope for this ERC. This ERC focuses solely on the interface for redeeming delegations and the validation of delegation authority. The mechanism for requesting and granting delegations may be implemented in various ways depending on the use case, such as through ERC-7715 or other protocols. This separation of concerns allows for flexibility in how delegations are created while maintaining a consistent interface for their redemption.

Overview

Redeeming a Delegation

When a delegate wishes to redeem a delegation, they call the redeemDelegations function on the Delegation Manager and pass in the action they want to execute and the proof of authority (ie delegation) which they are executing on behalf of. The Delegation Manager then verifies the delegation's validity and, if valid, calls the privileged function on the Delegator which executes the specified capability on behalf of the Delegator.

Interfaces

ERC7710Manager.sol

The Delegation Manager MUST implement the redeemDelegations which will be responsible for validating the delegations being redeemed, and will then call the delegators to execute the actions.

The bytes array _permissionContexts passed in as a parameter to the redeemDelegations function contains the authority to execute a specific action on behalf of the delegating contract.

The bytes32 array _modes and the bytes array _executionCallDatas passed in as parameters to the redeemDelegations function are arrays of mode and executionCalldata, which are defined precisely in ERC-7579 (under the "Execution Behavior" section). Briefly, mode encodes the "behavior" of the execution, which could be a single call, a batch call, and others. executionCallData encodes the data of the execution, which typically includes at least a target, a value, and a to address.

The three arrays MUST be interpreted as a list of tuples, where each tuple consists of (_permissionContexts[i], _modes[i], _executionCallDatas[i]). The function MUST revert if the arrays have different lengths. Each tuple represents a single delegation redemption with its associated permission context, execution mode, and execution data. Implementations MUST enforce atomicity of the batch.

Permission Verification

While this interface does not include an explicit method for checking delegation permissions, dApps SHOULD verify permissions before attempting to execute actions by:

1. Simulating the redeemDelegations call with the intended parameters
2. Using the simulation results to determine if the delegation would succeed
3. If the simulation fails, the dApp can request new or updated permissions from the user

This simulation-based approach provides stronger guarantees than a method exposed by the delegation manager, as it validates the entire execution context rather than the claims of the delegation manager.

Rationale

---

The design of this ERC is motivated by the need to introduce standardized, secure, and efficient mechanisms for delegation within the Ethereum ecosystem. Several considerations were taken into account:

Flexibility and Scalability: The proposed interfaces are designed to be minimal yet powerful, allowing contracts to delegate a wide range of actions without imposing a heavy implementation burden. This balance aims to encourage widespread adoption and innovation.

Interoperability: Compatibility with existing standards, such as ERC-1271 and ERC-4337, ensures that this approach can be seamlessly integrated into the current Ethereum infrastructure. This encourages adoption and leverages existing security practices.

Usability: By enabling contracts to delegate specific actions to others, we open the door to more user-friendly DApps that can perform a variety of tasks on behalf of users, reducing the need for constant user interaction and enhancing the overall user experience.

This ERC represents a step towards a more interconnected and flexible Ethereum ecosystem, where smart contracts can more effectively collaborate and adapt to users' needs.

Execution Interface

A previous iteration of this spec defined Action as a simple (target, value, data) tuple, and defined a specific execution interface on the delegator that is executeDelegatedAction(Action _action) which the Delegation Manager is supposed to call.

That approach had a few downsides:

• Existing smart accounts won't be compatible with this spec (unless they happen to implement the execution interface).
• The execution behavior is limited to a single call, since Action could only encode a single call. It made complex execution behaviors such as batching, delegatecall, and CREATE2 impossible.

To solve the first issue, we decided to remove the requirement for the delegator to implement any specific interface. Rather, we rely on the Delegation Manager to correctly call the delegator, and we rely on the fact that a delegator would only create _permissionContexts for a Delegation Manager that knows how to correctly call it.

To solve the second issue, we decied to adopt the execution interface from ERC-7579, which had to solve a similar problem within the context of modular smart accounts: defining a standardized execution interface that can support many types of executions.

Reference Implementation

---

For a minimal reference implementation focusing on delegation redemption, please see Example7710Manager.

For a complete reference implementation of a Delegation Manager, see the MetaMask Delegation Framework, which includes features such as:

• EIP-712 signature validation for delegations
• Support for both EOA and contract signatures (ERC-1271)
• Caveat enforcement for fine-grained delegation control
• Batch delegation processing
• Delegation revocation mechanisms

The MetaMask implementation demonstrates one way to build a robust delegation system while adhering to this standard's interface requirements.

Security Considerations

---

The introduction of customizable authorization terms requires careful consideration of how authorization data is structured and interpreted. Potential security risks include the misinterpretation of authorization terms and unauthorized actions being taken if the interface is not properly implemented. It is recommended that applications implementing this interface undergo thorough security audits to ensure that authorization terms are handled securely.

Permission Verification

dApps MUST NOT assume that having received a delegation in the past guarantees future execution rights. Delegations can be revoked, expire, or become invalid due to state changes. To ensure reliable operation:

1. Always simulate delegation redemptions before submitting them on-chain
2. Handle simulation failures gracefully by requesting new permissions when needed
3. Consider implementing retry logic with escalating permission requests
4. Be prepared for delegations to become invalid between simulation and execution

Needs discussion.

Copyright

---

Copyright and related rights waived via CC0.