# ERC-5453: Endorsement for ERC-5750 Methods

Source: https://www.eipsfordesigners.com/standards/ERC-5453
Agent brief: https://www.eipsfordesigners.com/standards/ERC-5453/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-5453
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Last Call |
| Chain | both |
| Category | Transaction Friction |
| Journey stages | Approving & Permissioning |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-5453 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-5453 |

## UX Impact

ERC-5453 is an endorsement protocol for target methods that adopt ERC-5750's final bytes extraData shape. validSince/validBy, relayer execution, cancellation/replay, and atomicity depend on target/integration; it is not a universal any-function permit.

## 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.

## For Designers

- 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.

## Applicability

### When to Use

- 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.

### When to Avoid

- 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.

## Problems It Solves

### Gasless patterns only work for token approvals

Impact: critical

Old way: ERC-2612 permit for ERC-20, but custom solutions for everything else

New way: A contract that opts into the ERC-5750 method shape can accept an endorsed call through a relayer

### Users need ETH for non-financial interactions

Impact: critical

Old way: Joining a DAO, voting, updating profile—all need gas

New way: Sign endorsement, relayer submits, protocol or user covers gas later

### Each protocol implements gasless differently

Impact: high

Old way: Custom meta-transaction formats per protocol

New way: A shared endorsement shape can be displayed by wallets and integrations that support the selected ERC-5750 method.

### Batch operations require multiple signatures

Impact: high

Old way: Sign approve, sign stake, sign claim separately

New way: A selected integration can collect one endorsement for its supported method and action set

### Endorsements lack expiration and replay protection

Impact: medium

Old way: Ad-hoc nonce and deadline implementations

New way: Endorsement data carries validSince and validBy; replay and cancellation behavior remain target-specific

## Anti-Patterns

### Not showing the actual function being called

Severity: critical

Users signing blind endorsements is dangerous

Instead: Parse and display contract address, function name, all parameters

### Using non-spec validity fields or implying indefinite authorization

Severity: critical

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.

### No way to cancel pending endorsements

Severity: high

Users trapped with outstanding authorizations

Instead: Clear nonce increment UI with explanation

### Using endorsements when regular tx would be simpler

Severity: medium

Adds complexity and relayer dependency unnecessarily

Instead: Use endorsements for gasless/sponsored flows, not everything

### Hiding relayer details and execution timing

Severity: medium

Users confused when endorsed action doesn't happen immediately

Instead: Show relayer status and estimated execution time

## UI Components

### EndorsementPreview

Human-readable view of what will be endorsed
States: loading, parsed, error
Props: endorsementData, contract, function, params

### GaslessActionButton

CTA that indicates action is signature-only
States: ready, signing, submitted, confirmed, error
Props: label, onSign, isGasless

### RelayerStatus

Shows relayer availability and estimated execution time
States: available, busy, offline
Props: estimatedTime, relayerName

### ValidityAndReplayState

Shows validSince/validBy and target-specific replay/cancellation state.
States: current, pending, expired, unsupported
Props: validSince, validBy, replayState, onRefresh

## Key Takeaways

- 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.

## UX Patterns

### Supported Gasless Action

Gasless action for a target method that accepts ERC-5750 endorsement data.

User flow:

- 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.

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

### Endorsement Signature Display

Clear wallet prompt showing what user is endorsing

User flow:

- 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

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

### Batch Endorsement Flow

Multiple actions in one signature

User flow:

- 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

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

### Endorsement Status Tracker

Track pending and executed endorsements

User flow:

- 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

Mockup registry key: `concept/permit-approval` (React UI on the live standard page).

## Technical Notes

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.