Authorize Operator
Video
Original
Abstract
A set of functions to enable meta-transactions and atomic interactions with contracts implementing an operator model, via signatures conforming to the EIP-712 typed message signing specification.
Motivation
The primary motivation for this standard is to enhance the flexibility, security, and efficiency of operator management. By leveraging EIP-712 signatures, this standard allows users to authorize operators without the need for on-chain transactions, reducing gas costs and improving user experience. This is particularly beneficial whenever frequent operator changes and cross-chain interactions are required.
Additionally, this standard aims to:
- Enable Meta-Transactions: Allow users to delegate the execution of transactions to operators, enabling meta-transactions where the user does not need to hold native tokens to pay for gas fees on each chain.
- Improve Security: Utilize the EIP-712 standard for typed data signing, which provides a more secure and user-friendly way to sign messages compared to raw data signing.
- Facilitate Interoperability: Provide a standardized interface for operator management that can be adopted across various vault protocols, promoting interoperability and reducing integration complexity for developers.
- Streamline Cross-Chain Operations: Simplify the process of managing operators across different chains, making it easier for protocols to maintain consistent operator permissions and interactions in a multi-chain environment.
By addressing these needs, the Authorize Operator
standard aims to streamline the process of managing operators in decentralized vault protocols, making it easier for users and developers to interact with smart contracts in a secure, cost-effective, and interoperable manner across multiple blockchain networks.
Specification
Operator-compatible contracts
This signed authorization scheme applies to any contracts implementing the following interface:
interface IOperator { event OperatorSet(address indexed owner, address indexed operator, bool approved); function setOperator(address operator, bool approved) external returns (bool); function isOperator(address owner, address operator) external returns (bool status); }
EIP-6909 and EIP-7540 already implement this interface.
The naming of the arguments is interchangeable, e.g. EIP-6909 uses spender
instead of operator
.
Methods
authorizeOperator
Grants or revokes permissions for operator
to manage Requests on behalf of the msg.sender
, using an EIP-712 signature.
MUST revert if the deadline
has passed.
MUST invalidate the nonce of the signature to prevent message replay.
MUST revert if the signature
is not a valid EIP-712 signature, with the given input parameters.
MUST set the operator status to the approved
value.
MUST log the OperatorSet
event.
MUST return true
.
- name: authorizeOperator type: function stateMutability: nonpayable inputs: - name: owner type: address - name: operator type: address - name: approved type: bool - name: nonce type: bytes32 - name: deadline type: uint256 - name: signature type: bytes outputs: - name: success type: bool
invalidateNonce
Revokes the given nonce
for msg.sender
as the owner
.
- name: invalidateNonce type: function stateMutability: nonpayable inputs: - name: nonce type: bytes32
authorizations
Returns whether the given nonce
has been used for the controller
.
- name: authorizations type: function stateMutability: nonpayable inputs: - name: controller type: address - name: nonce type: bytes32 outputs: - name: used type: bool
DOMAIN_SEPARATOR
Returns the DOMAIN_SEPARATOR
as defined according to EIP-712. The DOMAIN_SEPARATOR
should be unique to the contract and chain to prevent replay attacks from other domains, and satisfy the requirements of EIP-712, but is otherwise unconstrained.
- name: DOMAIN_SEPARATOR type: function stateMutability: nonpayable outputs: - type: bytes32
ERC-165 support
Smart contracts implementing this standard MUST implement the ERC-165 supportsInterface
function.
Contracts MUST return the constant value true
if 0xa9e50872
is passed through the interfaceID
argument.
Rationale
Similarity to ERC-2612
The specification is intentionally designed to closely match ERC-2612. This should simplify new integrations of the standard.
The main difference is using bytes32
vs uint256
, which enables unordered nonces.
Reference Implementation
// This code snippet is incomplete pseudocode used for example only and is no way intended to be used in production or guaranteed to be secure bytes32 public constant AUTHORIZE_OPERATOR_TYPEHASH = keccak256("AuthorizeOperator(address controller,address operator,bool approved,bytes32 nonce,uint256 deadline)"); mapping(address owner => mapping(bytes32 nonce => bool used)) authorizations; function DOMAIN_SEPARATOR() public view returns (bytes32) { // EIP-712 implementation } function isValidSignature(address signer, bytes32 digest, bytes memory signature) internal view returns (bool valid) { // ERC-1271 implementation } function authorizeOperator( address controller, address operator, bool approved, bytes32 nonce, uint256 deadline, bytes memory signature ) external returns (bool success) { require(block.timestamp <= deadline, "ERC7540Vault/expired"); require(controller != address(0), "ERC7540Vault/invalid-controller"); require(!authorizations[controller][nonce], "ERC7540Vault/authorization-used"); authorizations[controller][nonce] = true; bytes32 digest = keccak256( abi.encodePacked( "\x19\x01", DOMAIN_SEPARATOR(), keccak256(abi.encode(AUTHORIZE_OPERATOR_TYPEHASH, controller, operator, approved, nonce, deadline)) ) ); require(SignatureLib.isValidSignature(controller, digest, signature), "ERC7540Vault/invalid-authorization"); isOperator[controller][operator] = approved; emit OperatorSet(controller, operator, approved); success = true; } function invalidateNonce(bytes32 nonce) external { authorizations[msg.sender][nonce] = true; }
Security Considerations
Operators have significant control over users and the signed message can lead to undesired outcomes. The expiration date should be set as short as feasible to reduce the chance of an unused signature leaking at a later point.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all