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:
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.
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
bytes32publicconstantAUTHORIZE_OPERATOR_TYPEHASH=keccak256("AuthorizeOperator(address controller,address operator,bool approved,bytes32 nonce,uint256 deadline)");mapping(addressowner=>mapping(bytes32nonce=>boolused))authorizations;functionDOMAIN_SEPARATOR()publicviewreturns(bytes32){// EIP-712 implementation
}functionisValidSignature(addresssigner,bytes32digest,bytesmemorysignature)internalviewreturns(boolvalid){// ERC-1271 implementation
}functionauthorizeOperator(addresscontroller,addressoperator,boolapproved,bytes32nonce,uint256deadline,bytesmemorysignature)externalreturns(boolsuccess){require(block.timestamp<=deadline,"ERC7540Vault/expired");require(controller!=address(0),"ERC7540Vault/invalid-controller");require(!authorizations[controller][nonce],"ERC7540Vault/authorization-used");authorizations[controller][nonce]=true;bytes32digest=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;emitOperatorSet(controller,operator,approved);success=true;}functioninvalidateNonce(bytes32nonce)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.