ERC-5453: Endorsement - Permit for Any Functions
A general protocol for approving function calls in the same transaction rely on ERC-5750.
Abstract
This EIP establish a general protocol for permitting approving function calls in the same transaction rely on ERC-5750.
Unlike a few prior art (ERC-2612 for ERC-20, ERC-4494
for ERC-721 that
usually only permit for a single behavior (transfer
for ERC-20 and safeTransferFrom
for ERC-721) and a single approver in two transactions (first a permit(...)
TX, then a transfer
-like TX), this EIP provides a way to permit arbitrary behaviors and aggregating multiple approvals from arbitrary number of approvers in the same transaction, allowing for Multi-Sig or Threshold Signing behavior.
Motivation
- Support permit(approval) alongside a function call.
- Support a second approval from another user.
- Support pay-for-by another user
- Support multi-sig
- Support persons acting in concert by endorsements
- Support accumulated voting
- Support off-line signatures
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.
Interfaces
The interfaces and structure referenced here are as followed
See IERC5453.sol
.
Behavior specification
As specified in ERC-5750 General Extensibility for Method Behaviors, any compliant method that has an bytes extraData
as its
last method designated for extending behaviors can conform to ERC-5453 as the way to indicate a permit from certain user.
- Any compliant method of this EIP MUST be a ERC-5750 compliant method.
- Caller MUST pass in the last parameter
bytes extraData
conforming a solidity memory encoded layout bytes ofGeneralExtensionDataStruct
specified in Section Interfaces. The following descriptions are based on when decodingbytes extraData
into aGeneralExtensionDataStruct
- In the
GeneralExtensionDataStruct
-decodedextraData
, caller MUST set the value ofGeneralExtensionDataStruct.erc5453MagicWord
to be thekeccak256("ERC5453-ENDORSEMENT")
. - Caller MUST set the value of
GeneralExtensionDataStruct.erc5453Type
to be one of the supported values.
-
When the value of
GeneralExtensionDataStruct.erc5453Type
is set to beERC5453_TYPE_A
,GeneralExtensionDataStruct.endorsementPayload
MUST be abi encoded bytes of aSingleEndorsementData
. -
When the value of
GeneralExtensionDataStruct.erc5453Type
is set to beERC5453_TYPE_B
,GeneralExtensionDataStruct.endorsementPayload
MUST be abi encoded bytes ofSingleEndorsementData[]
(a dynamic array). -
Each
SingleEndorsementData
MUST have aaddress endorserAddress;
and a 65-bytesbytes sig
signature. -
Each
bytes sig
MUST be an ECDSA (secp256k1) signature using private key of signer whose corresponding address isendorserAddress
signingvalidityDigest
which is the a hashTypeDataV4 of EIP-712 of hashStruct ofValidityBound
data structure as followed:
- The
functionParamStructHash
MUST be computed as followed
whereas
_functionStructure
MUST be computed asfunction methodName(type1 param1, type2 param2, ...)
._functionParamPacked
MUST be computed asenc(param1) || enco(param2) ...
-
Upon validating that
endorserAddress == ecrecover(validityDigest, signature)
orEIP1271(endorserAddress).isValidSignature(validityDigest, signature) == ERC1271.MAGICVALUE
, the single endorsement MUST be deemed valid. -
Compliant method MAY choose to impose a threshold for a number of endorsements needs to be valid in the same
ERC5453_TYPE_B
kind ofendorsementPayload
. -
The
validSince
andvalidBy
are both inclusive. Implementer MAY choose to use blocknumber or timestamp. Implementor SHOULD find away to indicate whethervalidSince
andvalidBy
is blocknumber or timestamp.
Rationale
-
We chose to have both
ERC5453_TYPE_A
(single-endorsement) andERC5453_TYPE_B
(multiple-endorsements, same nonce for entire contract) so we could balance a wider range of use cases. E.g. the same use cases of ERC-2612 andERC-4494
can be supported byERC5453_TYPE_A
. And threshold approvals can be done viaERC5453_TYPE_B
. More complicated approval types can also be extended by defining newERC5453_TYPE_?
-
We chose to include both
validSince
andvalidBy
to allow maximum flexibility in expiration. This can be also be supported by EVM natively at if adoptedERC-5081
butERC-5081
will not be adopted anytime soon, we choose to add these two numbers in our protocol to allow smart contract level support.
Backwards Compatibility
The design assumes a bytes calldata extraData
to maximize the flexibility of future extensions. This assumption is compatible with ERC-721, ERC-1155 and many other ERC-track EIPs. Those that aren't, such as ERC-20, can also be updated to support it, such as using a wrapper contract or proxy upgrade.
Reference Implementation
In addition to the specified algorithm for validating endorser signatures, we also present the following reference implementations.
See AERC5453.sol
Reference Implementation of EndorsableERC721
Here is a reference implementation of EndorsableERC721
that achieves similar behavior of ERC-4494
.
Reference Implementation of ThresholdMultiSigForwarder
Here is a reference implementation of ThresholdMultiSigForwarder that achieves similar behavior of multi-sig threshold approval remote contract call like a Gnosis-Safe wallet.
See ThresholdMultiSigForwarder.sol
Security Considerations
Replay Attacks
A replay attack is a type of attack on cryptography authentication. In a narrow sense, it usually refers to a type of attack that circumvents the cryptographically signature verification by reusing an existing signature for a message being signed again. Any implementations relying on this EIP must realize that all smart endorsements described here are cryptographic signatures that are public and can be obtained by anyone. They must foresee the possibility of a replay of the transactions not only at the exact deployment of the same smart contract, but also other deployments of similar smart contracts, or of a version of the same contract on another chainId
, or any other similar attack surfaces. The nonce
, validSince
, and validBy
fields are meant to restrict the surface of attack but might not fully eliminate the risk of all such attacks, e.g. see the Phishing section.
Phishing
It's worth pointing out a special form of replay attack by phishing. An adversary can design another smart contract in a way that the user be tricked into signing a smart endorsement for a seemingly legitimate purpose, but the data-to-designed matches the target application
Copyright
Copyright and related rights waived via CC0.