Approving & Permissioning

ERC-20 defines a common interface for fungible token balances, transfers, and approvals. A client can integrate a token through these functions, but metadata methods, return values, fee behavior, and compatibility depend on the deployed contract.

Category: DeFi Patterns

ERC-721 defines non-fungible tokens (NFTs). Unlike ERC-20 where every token is identical, each ERC-721 token has a unique ID. This enables digital art, collectibles, game items, membership passes, and anything where each item is distinct. It specifies ownership, transfers, approvals, and an optional metadata extension — the foundation of the NFT ecosystem.

Category: NFT Capabilities

ERC-777 is a token standard with sender and recipient hooks plus operator permissions. It can support hook-aware transfers and operator-managed sends, but those semantics are different from ERC-1363 payable callbacks and ERC-4337 account-abstraction infrastructure. Treat adoption, integration, and hook reentrancy risk as separate design and security questions.

Category: Transaction Friction

EIP-2255 standardizes wallet_getPermissions and wallet_requestPermissions so a wallet can expose a permission model and caveats for a dApp. It supports progressive consent when the selected wallet implements the requested permission methods; it does not require a revocation RPC, expiry field, or common management UI.

Category: Onboarding & Access

ERC-2612 adds an optional permit(owner, spender, value, deadline, v, r, s) path to an ERC-20 token. A signed permit can set an allowance without an approval transaction; an integrating router or relayer may combine that permit with an action, but the permit deadline only limits submission of the signature and does not expire the resulting allowance.

Category: Transaction Friction

ERC-4400 records a consumer identity for an NFT without changing ownership. The consumer is not automatically an owner, operator, or approved transfer address; the consuming app defines which actions, if any, that role permits.

Category: Gaming & Composability

ERC-4907 adds rental functionality to NFTs. The owner can rent out their NFT to a "user" for a set time period. The renter gets usage rights without ownership. When the rental expires, usage rights automatically revert. Perfect for game items, virtual land, or any NFT with utility that can be temporarily shared.

Category: NFT Capabilities

ERC-5006 defines ERC-1155 user records with an owner, user, tokenId, amount, and expiry, plus usable and frozen balance views. It does not by itself specify escrow, custody movement, expiry cleanup, rental pricing, or a marketplace; those behaviors must be checked against the target implementation. The pinned reference implementation uses escrow and an authorized deleteUserRecord path, which is implementation-specific.

Category: NFT Capabilities

ERC-5192 defines a minimal soulbound interface in which locked(tokenId) reports whether an ERC-721 token is currently non-transferable. A compliant implementation can emit Locked and Unlocked, so “soulbound” should be shown as non-transferable while locked rather than as a universal forever guarantee.

Category: Identity & Privacy

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.

Category: Security & Trust

ERC-5484 extends ERC-721 for soulbound tokens whose burn authorization is agreed before issuance. The issuer presents metadata and burnAuth, obtains the receiver's signature off-chain, then issues the token; after issuance burnAuth is immutable and transfer remains disabled. The interface has no pending accept/decline token state.

Category: Identity & Privacy

Streamlined multi-token with granular per-token-type approvals and no mandatory callbacks — simpler than ERC-1155.

Category: NFT Capabilities

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.

Category: Security & Trust

ERC-7432 defines NFT role records with recipients, expiration, revocation policy, custom data, approval, and lock/unlock behavior. It does not define a role marketplace, price, purchase flow, or escrow; those are optional application layers over a verified role policy.

Category: NFT Capabilities

EIP-7702 lets an existing externally owned account delegate execution to contract code while keeping its address. Delegation persists until replaced or cleared and gives the code unrestricted account access. The wallet must audit the code; applications must not request authorization signatures. Batching, sponsorship, and scoped app permissions depend on compatible wallet implementations.

Category: Transaction Friction

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.

Category: Security & Trust

ERC-7943 defines uRWA interfaces for transfer eligibility, frozen balances, and privileged enforcement actions across ERC-20, ERC-721, ERC-1155, and ERC-6909 assets. Concrete implementations such as CMTA's CMTAT-ACE integration expose these controls, but the standard does not define a universal compliance policy, legal reason, authority, or wallet UI; applications must feature-detect the base and uRWA interfaces and show the actual contract policy.

Category: Physical & Real World

ERC-5008 is the ERC-721 Nonce Extension. It exposes nonce(tokenId), and an implementation updates that nonce when a transfer or other relevant state change invalidates pending orders. It provides a stale-order and replay-protection signal; it does not define permit(), signatures, listing approval, an EIP-712 domain, or gasless NFT transfers.

Category: Transaction Friction

ERC-5216 adds per-token-ID allowances to ERC-1155 contracts that implement the extension. A user can authorize an operator for a quantity of one token ID while keeping other IDs outside that allowance. It coexists with ERC-1155's broader setApprovalForAll operator permission, so the UI must show which mechanism the deployed collection supports and which scope the user is granting.

Category: Transaction Friction

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.

Category: Transaction Friction

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.

Category: Security & Trust

ERC-7715 requests execution permissions for a designated account. A wallet or account implementation may return a bounded permission, but the standard does not itself create a session key; supported rule types, the returned scope, and revocation behavior are integration-specific.

Category: Transaction Friction

ERC-7730 defines JSON descriptors and context rules that compatible clients can use to format calldata, EIP-712 messages, and UserOperations into readable summaries. Descriptor distribution, registry curation, client support, and source trust remain separate; a descriptor match does not prove that an action or publisher is safe.

Category: Comprehension & Display

EIP-7702 is opt-in code delegation for EOAs on Monad. While delegated, a transaction that reduces the EOA's balance below the applicable reserve threshold reverts, subject to the documented max-gas-fee allowance. The current reserve parameter is 10 MON, not a required deposit; sponsored low-balance calls can work when the balance is unchanged or increased. Delegated accounts cannot use the emptying exception.

Category: Transaction Friction