Security & Trust

EIP-155 adds chain ID to the replay-protected transaction signing path, while preserving the legacy six-field v=27/28 signature path for compatibility. Show the wallet's actual target chain and transaction envelope; a chain ID does not make every signature universally chain-bound.

Stages: Status & Confirmation

ERC-191 defines an envelope for signed data with a version byte and version-specific payload. It prevents a signed message from being parsed as a legacy transaction, but replay resistance and authorization safety still require domain/intent binding and application checks.

Stages: Authentication & Identity, Reading & Understanding

ERC-1271 lets a contract account validate a signature through isValidSignature. It broadens signature verification for protocols that explicitly accept contract signatures; it does not change an ERC-2612 token's required ECDSA permit path or guarantee that every marketplace accepts contract accounts.

Stages: Authentication & Identity

EIP-1344 adds the CHAINID opcode, which returns the configured numeric chain ID to contract code. A contract must compare or bind that value in its own logic; the opcode is not a named-network attestation or automatic replay protection.

Stages: Status & Confirmation

ERC-5267 adds eip712Domain(), a contract interface that publishes the fields and values used by its EIP-712 signing domain. Compatible applications can retrieve and validate the domain before showing a typed-data request; the interface is optional and is not a safety, trust, replay, or wallet-rendering certificate.

Stages: Reading & Understanding, Approving & Permissioning

ERC-5375 adds an authorInfo metadata field for NFT author names, addresses, and optional author-consent proofs. A consent proof shows that a signer agreed to be named as an author; the specification explicitly says that consent is not proof that the signer created the NFT. The metadata is normally off-chain and the signed field subset must be shown.

Stages: Authentication & Identity

ERC-5507 defines refund extensions for ERC-20, ERC-721, and ERC-1155 tokens. This guide focuses on an NFT refund flow. Read the token-specific refund amount and first ineligible block, holdings, and approval requirements. Refund rights are not universally restricted to the original purchaser.

Stages: Asset Management

ERC-5528 defines escrow refund and withdrawal interfaces for token sales; it does not guarantee full refunds or prevent every rug pull. The deployed escrow's conditions, refund rate, eligibility, and caller requirements determine what the user can claim.

Stages: Status & Confirmation, Asset Management

ERC-6147 extends ERC-721 with a guard role and an expiry timestamp that separate holding from transfer authority. While a guard is valid, the owner, approved address, and operators cannot transfer or change the guard; the guard can change or remove itself and can transfer the token through transferAndRemove. It does not define a pending owner request or approval queue.

Stages: Asset Management

ERC-7007 extends ERC-721 with AIGC data and verification interfaces. addAigcData binds prompt, aigcData, and proof to a token, while verify checks the combination through a chosen zkML or opML verifier. Model commitments, prompt confidentiality, proof storage, and creator disclosures depend on the implementation and storage design.

Stages: Specialized Interactions

EIP-7044 makes a correctly signed voluntary exit remain valid across future Ethereum upgrades by fixing its signing domain to Capella. Dencun activated the change on Ethereum mainnet. It simplifies delegated staking operations, but a signed exit is still an authority-bearing artifact: users need to see the validator, signer, fork/domain, custody relationship, and the fact that the signature cannot be revoked by this EIP.

Stages: Approving & Permissioning, Executing Transactions +1

ERC-7439 extends ERC-721 with ticket status, signature, expiry, and role-gated state changes intended to restrict transfers to authorized accounts. Its interface does not define ticket prices, resale caps, fees, reseller addresses, or a universal marketplace router; those policies must be read from the deployed implementation.

Stages: Specialized Interactions

ERC-7820 defines a generic Access Control Registry for registering target contracts, assigning an admin, and granting or revoking arbitrary bytes32 roles for accounts. The target contract gives each role its meaning; ERC-7820 does not define NFT role names, per-token roles, or precedence over ERC-721 approvals.

Stages: Approving & Permissioning

ERC-5496 extends ERC-721 with multiple privileges that can be assigned to users and checked independently of NFT ownership. A privilege has a provider-defined expiry through privilegeExpires, and an optional cloneable extension can copy a privilege; implementations decide assignment authority and the practical access policy.

Stages: Approving & Permissioning