{"id":"ERC-5453","name":"Endorsement for ERC-5750 Methods","status":"Last Call","chain":"both","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"approving","name":"Approving & Permissioning","description":"Granting permissions for actions"},{"id":"gas","name":"Gas & Fees","description":"Paying for transactions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"ERC-5453 builds on ERC-5750 to let an opted-in contract method accept endorsement data for a relayed call. It is not a universal permit for every function: the target contract must implement the relevant method and final bytes extraData shape, and execution/atomicity remain contract and relayer behavior.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-5453","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-5453","summary":"ERC-5453 builds on ERC-5750 to let an opted-in contract method accept endorsement data for a relayed call. It is not a universal permit for every function: the target contract must implement the relevant method and final bytes extraData shape, and execution/atomicity remain contract and relayer behavior.","partialDeployment":{"body":"ERC-5453 is Last Call. Treat endorsement support as conditional on the target contract implementing the relevant ERC-5750 method shape and on a relayer accepting the validity and replay rules; verify the deployed method before exposing this flow."},"applicability":{"whenToUse":["A target contract opts into the relevant ERC-5750 endorsement method and final bytes extraData shape.","A relayer can validate validSince/validBy and execute the selected method.","The product can show relayer availability and target-specific replay/cancellation behavior."],"whenToAvoid":["The target contract does not implement the relevant ERC-5750-compatible method with a final bytes extraData parameter.","The relayer cannot validate validity windows or provide a reliable execution path.","The flow needs guaranteed atomic multi-call execution."]},"designerTakeaways":["Show the target contract, method, parameters, validity window, and any extraData the selected integration uses.","Use validSince and validBy from the endorsement data; do not invent a universal validUntil or endorsementNonce API.","Make relayer availability and execution results explicit, and do not promise atomicity unless the target implementation provides it."],"problemsSolved":[{"problem":"Gasless patterns only work for token approvals","oldWay":"ERC-2612 permit for ERC-20, but custom solutions for everything else","newWay":"A contract that opts into the ERC-5750 method shape can accept an endorsed call through a relayer","impact":"critical"},{"problem":"Users need ETH for non-financial interactions","oldWay":"Joining a DAO, voting, updating profile—all need gas","newWay":"Sign endorsement, relayer submits, protocol or user covers gas later","impact":"critical"},{"problem":"Each protocol implements gasless differently","oldWay":"Custom meta-transaction formats per protocol","newWay":"A shared endorsement shape can be displayed by wallets and integrations that support the selected ERC-5750 method.","impact":"high"},{"problem":"Batch operations require multiple signatures","oldWay":"Sign approve, sign stake, sign claim separately","newWay":"A selected integration can collect one endorsement for its supported method and action set","impact":"high"},{"problem":"Endorsements lack expiration and replay protection","oldWay":"Ad-hoc nonce and deadline implementations","newWay":"Endorsement data carries validSince and validBy; replay and cancellation behavior remain target-specific","impact":"medium"}],"uxPatterns":[{"name":"Supported Gasless Action","description":"Gasless action for a target method that accepts ERC-5750 endorsement data.","userFlow":["User starts a supported target action","UI shows action details","Indicates this is gasless","Wallet shows endorsement to sign","Relayer submits on-chain","App shows the target implementation's returned result and membership or state change."]},{"name":"Endorsement Signature Display","description":"Clear wallet prompt showing what user is endorsing","userFlow":["Wallet receives endorsement request","Parses EIP-712 typed data","Shows human-readable action description","Displays contract, function, parameters","Shows validSince/validBy and any target-specific replay or cancellation field","User signs or rejects"]},{"name":"Batch Endorsement Flow","description":"Multiple actions in one signature","userFlow":["User starts onboarding flow","Multiple actions bundled together","Single endorsement signature requested","Relayer submits the selected calls according to the target implementation; show each result","All onboarding steps complete"]},{"name":"Endorsement Status Tracker","description":"Track pending and executed endorsements","userFlow":["User views endorsement history","Sees pending endorsements with expiry","Shows pending endorsements with validSince and validBy","Uses the target integration's cancellation or nonce mechanism when available","Links to transaction details"]}],"uiComponents":[{"name":"EndorsementPreview","description":"Human-readable view of what will be endorsed","states":["loading","parsed","error"],"props":["endorsementData","contract","function","params"]},{"name":"GaslessActionButton","description":"CTA that indicates action is signature-only","states":["ready","signing","submitted","confirmed","error"],"props":["label","onSign","isGasless"]},{"name":"RelayerStatus","description":"Shows relayer availability and estimated execution time","states":["available","busy","offline"],"props":["estimatedTime","relayerName"]},{"name":"ValidityAndReplayState","description":"Shows validSince/validBy and target-specific replay/cancellation state.","states":["current","pending","expired","unsupported"],"props":["validSince","validBy","replayState","onRefresh"]}],"antiPatterns":[{"pattern":"Not showing the actual function being called","why":"Users signing blind endorsements is dangerous","instead":"Parse and display contract address, function name, all parameters","severity":"critical"},{"pattern":"Using non-spec validity fields or implying indefinite authorization","why":"ERC-5453 endorsement data uses validSince and validBy, and the target method defines the remaining execution boundary.","instead":"Render validSince/validBy from the selected integration and state any contract-specific cancellation behavior.","severity":"critical"},{"pattern":"No way to cancel pending endorsements","why":"Users trapped with outstanding authorizations","instead":"Clear nonce increment UI with explanation","severity":"high"},{"pattern":"Using endorsements when regular tx would be simpler","why":"Adds complexity and relayer dependency unnecessarily","instead":"Use endorsements for gasless/sponsored flows, not everything","severity":"medium"},{"pattern":"Hiding relayer details and execution timing","why":"Users confused when endorsed action doesn't happen immediately","instead":"Show relayer status and estimated execution time","severity":"medium"}],"specConstraints":[{"id":"erc5750-method-scope","constraint":"An ERC-5453 endorsement applies only to a compliant ERC-5750 method.","appliesTo":"account-implementation","normativity":"normative","specQuote":"1. Any compliant method of this EIP MUST be a [ERC-5750](./eip-5750.md) compliant method.","specSection":"Specification > Behavior specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#behavior-specification","designImplication":"Label the exact target contract method and do not present an endorsement as a universal permit."},{"id":"endorsement-envelope","constraint":"The caller must supply extraData in the specified GeneralExtensionDataStruct shape.","appliesTo":"account-implementation","normativity":"normative","specQuote":"2. Caller MUST pass in the last parameter `bytes extraData` conforming to Solidity memory-encoded bytes of `GeneralExtensionDataStruct` specified in _Section Interfaces_. The following descriptions are based on when decoding `bytes extraData` into a `GeneralExtensionDataStruct`","specSection":"Specification > Behavior specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#behavior-specification","designImplication":"Show the endorsement envelope and any integration-specific fields in review, while keeping raw encoding secondary to the target action."},{"id":"endorsement-signature","constraint":"An endorsement uses the specified signer address, ECDSA/EIP-712 validity digest, and signature format.","appliesTo":"wallet","normativity":"normative","specQuote":"8. Each `bytes sig` MUST be an ECDSA (secp256k1) signature using private key of signer whose corresponding address is `endorserAddress` signing `validityDigest` which is the hashTypeDataV4 of [EIP-712](./eip-712.md) of hashStruct of `ValidityBound` data structure as follows:","specSection":"Specification > Behavior specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#behavior-specification","designImplication":"Make the signer, typed-data action, target method, and validity window visible before a user approves an endorsement."},{"id":"endorsement-verification","constraint":"An endorsement is valid only when the signer address or ERC-1271 contract validates the digest and signature.","appliesTo":"account-implementation","normativity":"normative","specQuote":"10. Upon validating that `endorserAddress == ecrecover(validityDigest, signature)` or `EIP1271(endorserAddress).isValidSignature(validityDigest, signature) == ERC1271.MAGICVALUE`, the single endorsement MUST be deemed valid.","specSection":"Specification > Behavior specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#behavior-specification","designImplication":"Keep endorsement verification status separate from relayer submission status and show the authority that accepted the signature."},{"id":"endorsement-threshold-option","constraint":"A compliant method MAY impose a threshold for the number of endorsements that must be valid in an ERC5453_TYPE_B payload.","appliesTo":"account-implementation","normativity":"normative","specQuote":"11. Compliant method MAY choose to impose a threshold for a number of endorsements needs to be valid in the same `ERC5453_TYPE_B` kind of `endorsementPayload`.","specSection":"Specification > Behavior specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#behavior-specification","designImplication":"When a Type B flow uses a threshold, show the required and received endorsement counts before signing; do not imply that every listed endorser must approve unless the implementation says so."},{"id":"endorsement-validity-unit","constraint":"Implementers MAY use block numbers or timestamps for the inclusive validSince and validBy bounds, and SHOULD indicate which unit is used.","appliesTo":"account-implementation","normativity":"normative","specQuote":"12. The `validSince` and `validBy` are both inclusive. Implementer MAY choose to use blocknumber or timestamp. Implementors SHOULD find a way to indicate whether `validSince` and `validBy` is blocknumber or timestamp.","specSection":"Specification > Behavior specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#behavior-specification","designImplication":"Expose whether validSince and validBy are block numbers or timestamps, and render inclusive expiry using the matching unit rather than guessing from the raw values."},{"id":"extension-compatibility","constraint":"The extraData extension model remains compatible with ERC-721, ERC-1155, and adaptable wrappers for other standards.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nThe design assumes a `bytes calldata extraData` to maximize the flexibility of future extensions. This assumption is compatible with [ERC-721](eip-721.md), [ERC-1155](eip-1155.md) and many other ERC-track EIPs. Those that aren't, such as [ERC-20](./eip-20.md), can also be updated to support it, such as using a wrapper contract or proxy upgrade.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#backwards-compatibility","designImplication":"Use the target collection/token flow where supported, but explain when a wrapper or upgraded implementation is required."},{"id":"endorsement-replay","constraint":"Public endorsements may be replayed across deployments, contracts, versions, or chain IDs; validity fields only reduce, not eliminate, the risk.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"### Replay Attacks\n\nA 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](#phishing) section.","specSection":"Security Considerations > Replay Attacks","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#replay-attacks","designImplication":"Show chain, target contract, method, nonce, and validity window in signing UI; do not describe an endorsement as one-time or universally replay-safe without implementation evidence."},{"id":"endorsement-phishing","constraint":"Users can be phished into signing an endorsement whose data appears legitimate but targets another application.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"### Phishing\n\nIt'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 may be tricked into signing a smart endorsement for a seemingly legitimate purpose, but the data-to-designed matches the target application","specSection":"Security Considerations > Phishing","specUrl":"https://ercs.ethereum.org/ERCS/erc-5453#phishing","designImplication":"Render the target contract/application context prominently and provide a clear mismatch warning for unfamiliar endorsement requests."}],"keyTakeaways":["ERC-5453 is an endorsement pattern for methods that opt into the ERC-5750 shape.","Show contract, method, parameters, extraData, and validSince/validBy.","Relayer execution and atomicity are implementation-specific.","Feature-detect the target method before presenting a gasless path."],"technicalNotes":"ERC-5453 is built around ERC-5750. A compliant target method accepts the endorsement data and a final bytes extraData parameter; endorsement validity uses validSince and validBy. The ERC does not define a universal arbitrary-function interface, endorsementNonce(), validUntil, or relayer atomicity. Use the selected contract's cancellation and replay rules.","lastUpdated":"2026-09-18","sources":[{"label":"ERC-5453 official specification","url":"https://ercs.ethereum.org/ERCS/erc-5453","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-5453","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-5453","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-5453","markdown":"https://www.eipsfordesigners.com/standards/ERC-5453/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-5453/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-5453","official":"https://ercs.ethereum.org/ERCS/erc-5453","discussion":"https://ethereum-magicians.org/search?q=ERC-5453"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}