ERCs: the conventions apps and wallets share

An ERC is a standard that lets applications on Ethereum speak the same way. It needs no hard fork: it takes effect when apps and wallets adopt it.

ERC explainers

• ERC-20 Token Standard (Token Standard) — A standard that gives tokens built as smart contracts a common set of functions and events. Wallets and exchanges can handle balance queries, transfers, and delegated withdrawals without writing different code for each token.
• ERC-55 Mixed-case checksum address encoding (Mixed-case checksum address encoding) — It writes the letters a to f of an Ethereum address in a mix of uppercase and lowercase according to a rule, so that wallets and apps can filter out mistyped addresses. The address length stays at 40 characters.
• ERC-137 Ethereum Name Service (ENS) specification (Ethereum Domain Name Service - Specification) — Defines the rules of a naming service that turns human-readable names such as 'vitalik.wallet' into resources such as contract addresses or content hashes. The name stays the same even when the resource changes.
• ERC-162 ENS Initial Hash Registrar (Initial ENS Hash Registrar) — Defines the initial registrar that distributes .eth names of the Ethereum Name Service (ENS) through a sealed-bid auction. The winning bidder locks up ether as collateral and becomes the owner of the name.
• ERC-165 Standard Interface Detection (Standard Interface Detection) — A standard that lets a contract publish which interfaces (sets of functions) it implements, so that other contracts or apps can confirm this with a single call.
• ERC-173 Contract ownership standard (Contract Ownership Standard) — Unifies how to read who owns a smart contract and how to transfer ownership to another address. Wallets and apps can check and manage the owner of any contract in the same way.
• ERC-181 ENS support for reverse resolution of Ethereum addresses (ENS support for reverse resolution of Ethereum addresses) — Specifies how ENS performs reverse resolution, finding a human-readable name from an Ethereum address. Only the owner of the address can register this name, so whoever looks it up can trust it.
• ERC-190 Smart contract packaging standard (Ethereum Smart Contract Packaging Standard) — Defines a common format for bundling smart contract code into packages for distribution and reuse. It lets package managers pin dependencies and verify the bytecode of deployed contracts.
• ERC-191 Signed data standard (Signed Data Standard) — Unifies the prefix of the signed data that a contract verifies with 0x19 and a version byte. This prevents signed data from being disguised as an Ethereum transaction or reused on another wallet.
• ERC-223 Receive notification callback token standard (Token with transaction handling model) — A fungible token standard that notifies a receiving contract of a deposit by calling its tokenReceived function when tokens are sent to it. It makes tokens behave like ether.
• ERC-600 Ethereum Deterministic Wallet Path Allocation (Ethereum purpose allocation for Deterministic Wallets) — In deterministic wallets, which generate many keys from a single seed, this defines the Ethereum-specific key derivation path m/43'/60'/EIP' so that different wallets can generate addresses in the same way.
• ERC-601 Ethereum deterministic wallet hierarchy (Ethereum hierarchy for deterministic wallets) — Defines a key derivation path scheme designed specifically for Ethereum, for deterministic wallets that generate multiple addresses from a single seed. It is a standard that makes all wallets generate addresses by the same rules.
• ERC-681 Transaction request URL format (URL Format for Transaction Requests) — A standard for writing a payment request for ether or ERC-20 tokens as a single URL line beginning with ethereum:. When it is delivered in a QR code or link, the user's wallet app opens with the recipient address and amount pre-filled.
• ERC-721 Non-fungible token (NFT) standard (Non-Fungible Token Standard) — Defines a common way to track and transfer distinguishable assets by owner inside a smart contract. It lets wallets and brokerage and auction apps handle any NFT through the same functions.
• ERC-777 Advanced token standard (hooks and operators) (Token Standard) — A token standard that is compatible with ERC-20, notifies both the sender and the recipient (hooks) when tokens are sent, and lets other addresses (operators) send or burn tokens on a holder's behalf.
• ERC-820 Pseudo-introspection registry (Pseudo-introspection Registry Contract) — Defines a universal registry where any address, whether a contract or a regular account, can register which interfaces it supports and which contract is responsible for implementing them, and anyone can look this up.
• ERC-1046 tokenURI interoperability extension (tokenURI Interoperability) — Adds a tokenURI() function to ERC-20 tokens, returning an address with an image and description as ERC-721 does, and adds an interop field to ERC-20, ERC-721 and ERC-1155 metadata that states the token type, so that wallets read all three standards the same way.
• ERC-1155 Multi-token standard (Multi Token Standard) — A standard that lets a single contract manage several kinds of tokens, such as fungible tokens and NFTs, together and send several tokens in one transaction.
• ERC-1167 Minimal proxy contract (Minimal Proxy Contract) — A standard for cheaply cloning a contract with the same functionality using very small bytecode. A clone forwards every call to a fixed original contract and returns the result unchanged.
• ERC-1185 Storing DNS Records in ENS (Storage of DNS Records in ENS) — A resolver standard for storing and looking up DNS records inside Ethereum Name Service (ENS) contracts. It lets ENS serve as a trustworthy store of DNS information.
• ERC-1191 Adding a Chain ID to Checksummed Addresses (Add chain id to mixed-case checksum address encoding) — Incorporates a network-distinguishing chain ID into the mixed-case checksum calculation of an address, so that software such as wallets can detect an attempt to send to an address generated on a different network.
• ERC-1202 On-chain Voting Interface (Voting Interface) — A common interface for creating a vote with a smart contract, casting ballots, and querying and executing results. It lets anyone participate in voting the same way on any compatible contract and leave the results on chain in a standard format.
• ERC-1271 Contract signature validation standard (Standard Signature Validation Method for Contracts) — Lets a smart contract without a private key report whether a signature made on its behalf is valid. When a signing contract implements the isValidSignature function, any app can verify signatures in the same way.
• ERC-1328 WalletConnect URI format (WalletConnect URI Format) — Defines how to put the information needed to connect an app and a wallet into a single URI line starting with wc:. This URI can be shown as a QR code or a link.
• ERC-1363 Payable Token (Payable Token) — A standard that lets an ERC-20 token transfer or approval immediately run code in the receiving contract within the same transaction.
• ERC-1450 RTA-Controlled Security Token (RTA-Controlled Security Token) — A standard that records securities issued under US securities regulations (Reg CF, D, A) as tokens and allows only the Registered Transfer Agent (RTA) to execute transfers, issuance and burns.
• ERC-1820 Pseudo-introspection registry contract (Pseudo-introspection Registry Contract) — Defines a shared registry where any address, whether a contract or a regular account, can register and look up which interfaces it supports and which contract implements them. The same address is used on every chain.
• ERC-1967 Proxy storage slot standard (Proxy Storage Slots) — A standard that fixes where an upgradeable proxy contract stores the address of the logic contract holding the actual code, the beacon address, and the admin address. Tools such as block explorers can read any proxy in the same way.
• ERC-2098 Compact signature representation format (Compact Signature Representation) — Defines a way to carry an Ethereum signature in 64 bytes instead of 65. Of the signature's three values, yParity is packed into the top bit of the s value, so the signature is expressed with only two values, r and yParityAndS.
• ERC-2135 Consumable token interface (Consumable Interface (Tickets, etc)) — A standard interface that makes ERC-721 and ERC-1155 tokens "consumable" assets and announces when consumption occurs. It is used for digital assets whose effect ends once used, such as concert admission tickets.
• ERC-2266 Atomic Swap based American Call Option (Atomic Swap-based American Call Option Contract Standard) — A standard that implements, as a smart contract, an American Call Option trade in which a premium is exchanged using an Atomic Swap, where two parties swap tokens without a trusted intermediary.
• ERC-2309 ERC-721 Consecutive Transfer Extension (ERC-721 Consecutive Transfer Extension) — An ERC-721 extension standard that lets NFTs with consecutive token IDs be created, moved, or destroyed in bulk while emitting a single event covering one range, instead of emitting a notification for each token.
• ERC-2333 BLS12-381 key generation standard (BLS12-381 Key Generation) — Defines a method for deriving, from a single secret seed, effectively unlimited BLS12-381 keys in a tree structure. The derivation process also produces a quantum-safe emergency backup signing method as a byproduct.
• ERC-2334 BLS key hierarchy path standard (BLS12-381 Deterministic Account Hierarchy) — A path convention that defines which key in the BLS key tree generated by ERC-2333 is used for which purpose. It also defines the withdrawal key and signing key paths for beacon chain validators.
• ERC-2335 BLS12-381 keystore (BLS12-381 Keystore) — A standard for encrypting a BLS12-381 private key with a password and storing it as a single JSON file so it can be safely exchanged between devices.
• ERC-2535 Diamond Multi-Facet Proxy (Diamonds, Multi-Facet Proxy) — Defines a modular contract structure in which multiple facets, pieces of functionality, are attached behind a single contract address, so functionality can be added, replaced, and removed even after deployment. There is effectively no size limit either.
• ERC-2612 Approving token use with a signature (Permit) (Permit Extension for EIP-20 Signed Approvals) — Handles the approval (approve) of EIP-20 token use with a single signature instead of a transaction. The token owner can approve without holding ETH, and the approval and the actual operation can be combined into one.
• ERC-2678 Smart Contract Packaging Standard v3 (Revised Ethereum Smart Contract Packaging Standard (EthPM v3)) — Defines a format that holds a smart contract's source, compiler settings and deployment information in a single JSON document (the package manifest). It lets tools create, install and verify packages in a common format.
• ERC-2771 Meta Transaction Recipient Protocol (Secure Protocol for Native Meta Transactions) — Defines how a contract can receive requests through a forwarder it trusts and determine the original signer, so that accounts without ETH can use the contract through meta transactions in which a third party pays the gas.
• ERC-2981 NFT royalty standard (NFT Royalty Standard) — A standard that lets any marketplace look up, in the same way, how much should be sent to the creator, and to which address, when an NFT is sold or resold.
• ERC-3156 Flash loan standard (Flash Loans) — Defines in one place the functions and execution procedure of a flash loan, in which tokens are borrowed without collateral and repaid within the same transaction. It makes the lending contract and the borrowing contract fit together in the same way even when they are different implementations.
• ERC-3448 Metaproxy standard (MetaProxy Standard) — Standardizes the bytecode of a tiny proxy contract with fixed configuration values (metadata) appended to the end of its code, so the same functionality can be cloned cheaply with different values and tools can easily verify that structure.
• ERC-3475 Abstract Storage Bonds (Abstract Storage Bonds) — A standard that tokenizes obligations with redemption conditions, like bonds, using a two-level ID of class and nonce, and lets redemption conditions and metadata be stored directly onchain in a free-form structure.
• ERC-3525 Semi-fungible token (Semi-Fungible Token) — A semi-fungible token standard that adds a slot and a value to ERC-721-compatible tokens, so that tokens sharing the same slot can have their values split and exchanged.
• ERC-3643 T-REX, the security token standard (T-REX - Token for Regulated EXchanges) — A permissioned token standard that automatically checks on-chain identity and regulatory compliance on every transfer, so that tokens representing regulated assets such as stocks move only among verified investors.
• ERC-3668 CCIP Read: offchain data lookup (CCIP Read—Secure offchain data retrieval) — Defines a common procedure in which a contract signals by an error that the data it needs is offchain, the client fetches the data from a specified server and passes it back to the contract, and the contract verifies it.
• ERC-4337 Account abstraction with an alternative mempool (Account Abstraction Using Alt Mempool) — A standard that lets smart contract accounts send actions under their own validation rules without a regular account (EOA), and lets another party pay the fees on their behalf. It is implemented with a separate mempool and an EntryPoint contract, without changing the consensus layer.
• ERC-4361 Sign-In with Ethereum (SIWE) (Sign-In with Ethereum) — Defines a standard message format and verification procedure for logging in to off-chain services such as websites with an Ethereum account. A session can be created with only a wallet signature, without a central login provider.
• ERC-4400 ERC-721 Consumer Role Extension (EIP-721 Consumable Extension) — Adds a standard interface to ERC-721 NFTs for assigning and querying a consumer address, which uses the token without being its owner. It is the basis for services that separate ownership from use, such as NFT rental and staking.
• ERC-4519 Physical Asset-Linked NFT (Non-Fungible Tokens Tied to Physical Assets) — A standard interface for NFTs bound to physical assets such as Internet of Things (IoT) devices. It lets the asset sign with its own Ethereum address and mutually authenticate with its owner and user, so the link can be verified as genuine.
• ERC-4626 Tokenized Vault Standard (Tokenized Vaults) — Defines a common deposit and withdrawal interface for a vault that accepts a single ERC-20 token and gives back shares in the form of a token. Wallets and apps do not have to write different integration code for each vault.
• ERC-4804 Converting a Web3 URL to an EVM call (Web3 URL to EVM Call Message Translation) — These are the rules for turning a web address such as web3://uniswap.eth/ into a read call to an Ethereum contract. With a human-readable URL like a browser address, you can reach on-chain content directly.
• ERC-4824 DAO common interface (Common Interfaces for DAOs) — An API standard that lets a DAO expose, through a single daoURI, the standardized locations of its name, members, proposals, activity log, and governance documents. Like tokenURI in ERC-721, it lets any tool read DAO information in the same way.
• ERC-4834 Hierarchical domains (Hierarchical Domains) — A minimal name resolution standard that treats a contract itself as a domain and converts human-readable names into addresses. Each level can attach the access control it wants.
• ERC-4906 EIP-721 Metadata Update Extension (EIP-721 Metadata Update Extension) — Defines a standard event that signals when an NFT's metadata (descriptive information such as image and attributes) has changed. External services such as NFT marketplaces can reflect the changed information in time.
• ERC-4907 NFT rental extension (user and expiry) (Rental NFT, an Extension of EIP-721) — Adds a separate "user" role and an expiry time (expires) apart from the NFT's owner. It lets an NFT be lent for a set period without transferring ownership.
• ERC-4910 NFT with built-in royalties (Royalty Bearing NFTs) — Extends the NFT standard (ERC-721) so that the definition, distribution and payment of royalties are all handled onchain. It builds a layered royalty structure linking original works and derivative works, so revenue reaches creators without a central authority.
• ERC-4955 NFT Vendor Metadata Extension (Vendor Metadata Extension for NFTs) — A standard that adds a namespaces field to NFT metadata JSON so that project-specific data (such as 3D model information) can be kept in one place.
• ERC-4973 Account-bound Token (ABT) (Account-bound Tokens) — Defines an interface for issuing, accepting, releasing, and tracking Account-bound Tokens (ABT), which are NFTs that are bound to a single account and cannot be transferred. They are issued only with the signed consent of the recipient, and the recipient can release the binding at any time.
• ERC-5006 Rental NFT User Extension (Rental NFT, NFT User Extension) — Adds a user role, separate from the owner, to ERC-1155 tokens so that a set amount of tokens can be lent for a set period without transferring ownership.
• ERC-5007 Time NFT: ERC-721 Time Extension (Time NFT, ERC-721 Time Extension) — An extension that adds startTime and endTime query functions to ERC-721 NFTs so that a token's validity period can be managed on chain in a standard way.
• ERC-5008 ERC-721 nonce extension (ERC-721 Nonce Extension) — An extension that adds a nonce, a number that changes each time an NFT is transferred, to ERC-721 NFTs. By recording the nonce together with a sale order, orders revived by a wallet move can be filtered out, preventing underpriced sales.
• ERC-5023 Shareable NFT (Shareable Non-Fungible Token) — A standard that lets you issue a copy of an NFT you hold as a new token and hand it out to others. The original stays as it is, and events record who shared what with whom.
• ERC-5114 Soulbound badge (Soulbound Badge) — Creates a badge token that is bound to a specific NFT the moment it is issued and can never be transferred afterward. This lets the history or credentials accumulated by an NFT be preserved as a permanent record.
• ERC-5164 Cross-chain execution standard (Cross-Chain Execution) — Defines a common interface that lets a contract on one chain send a message to a contract on another EVM chain to execute code. It consists of two parts: a dispatcher on the sending side and an executor on the receiving side.
• ERC-5169 Client script URI for tokens (Client Script URI for Token Contracts) — A standard in which a token contract uses the scriptURI() function to report the download address of the official client script dedicated to that token. Wallets and apps can find the script the issuer specified and extend token functionality.
• ERC-5192 Minimal Soulbound NFT (Minimal Soulbound NFTs) — Adds one locked function and two events to an EIP-721 NFT, so that wallets and apps can check in a standard way whether a token is bound to one account and cannot be transferred.
• ERC-5202 Blueprint contract format (Blueprint contract format) — Defines a standard bytecode format for storing deployment code (initcode), which creates contracts, on chain as a "blueprint" contract. The identifier at the front prevents direct execution and lets tools recognize it easily.
• ERC-5216 ERC-1155 quantity specified approval extension (ERC-1155 Allowance Extension) — An extension standard that lets ERC-1155 tokens be approved to a third party per id in a fixed amount. It splits the all-or-nothing approval authority into unit quantities.
• ERC-5219 Contract Resource Requests (Contract Resource Requests) — Defines an interface for requesting resources from a smart contract, much like requesting a web page, and receiving an HTTP-like response with a status code, body and headers. It lets a decentralized app's front end be served on chain without a central server.
• ERC-5247 Smart contract execution proposal interface (Smart Contract Executable Proposal Interface) — A common interface that registers a list of desired contract calls onchain as a proposal, so they can be executed later once approved.
• ERC-5267 EIP-712 Domain Retrieval Standard (Retrieval of EIP-712 domain) — Defines a function through which a contract discloses which fields and values make up its EIP-712 signing domain. Apps and wallets can read it to build the domain separator themselves.
• ERC-5269 Querying supported standards by ERC number (ERC Detection and Discovery) — A detection interface that lets a contract's supported ERC standards be queried using human-readable ERC numbers, and per caller address.
• ERC-5289 Ethereum notarization interface (Ethereum Notary Interface) — A standard that lets a smart contract provide a link pointing to a legal document and record a user's signature history on-chain, adding legal binding force to the use of the contract.
• ERC-5313 Lightweight contract ownership lookup (Light Contract Ownership) — A minimal interface standard that lets you look up the address of the account that owns a contract with a single owner() function.
• ERC-5375 NFT author information and consent standard (NFT Author Information and Consent) — Defines a JSON format that carries, in NFT metadata, a list of author addresses and a signed proof that the author 'consents to be listed as an author'. It lets author information be provided in a standard way even when the person who minted differs from the actual author.
• ERC-5380 ERC-721 entitlement extension (ERC-721 Entitlement Extension) — A standard that lets the owner of an NFT (ERC-721) grant another address the right to use certain attributes of that token without transferring the token.
• ERC-5453 Approving any function with a signature (Endorsement - Permit for Any Functions) — Unlike existing approaches that allow only one specific action to be authorized by signature, this is a common convention that lets any function call within a single transaction be approved by the signature(s) (endorsement) of one or more signers.
• ERC-5484 Consensual Soulbound Token (Consensual Soulbound Tokens) — The standard interface for soulbound tokens, which are NFTs that cannot be transferred to another address. Before minting, the issuer and the recipient agree on who can burn the token, and that authority cannot be changed after minting.
• ERC-5485 Jurisdiction, accreditation, and enforcement declaration interface (Jurisdiction, Accreditation, and Enforcement) — An interface that lets a smart contract declare and expose, in a standard way, the jurisdiction it follows, the accreditation it has received from that jurisdiction, and the channel through which enforcement decisions are delivered to it.
• ERC-5489 NFT Hyperlink Extension (NFT Hyperlink Extension) — An extension standard that lets hyperlinks be attached to NFTs. The NFT owner delegates a link slot to a specific address, that address manages the link address (URI), and the owner can revoke the authority at any time.
• ERC-5496 Multi-privilege management extension for NFTs (Multi-privilege Management NFT Extension) — An EIP-721 extension that lets a single NFT carry multiple privileges, such as voting rights, coupons, or airdrop claim rights, and allows those privileges to be transferred or duplicated and shared separately while NFT ownership itself remains unchanged.
• ERC-5507 Refundable Tokens (Refundable Tokens) — A standard that adds a refund function to the first sale of ERC-20, ERC-721, and ERC-1155 tokens. The sale proceeds are held in escrow until a set point in time, and before then the buyer can return the token and get their ether refunded.
• ERC-5516 Soulbound Multi-Owner Token (Soulbound Multi-owner Tokens) — A standard that lets non-transferable attestation tokens (soulbound tokens) be issued to multiple accounts at once in a single transaction, and lets multiple token types live in the same contract.
• ERC-5521 Referable NFT (rNFT) (Referable NFT) — An extension standard for ERC-721 NFTs that records referring and referred relationships and a creation time, so that citation relationships between NFTs form a directed acyclic graph (DAG) that anyone can query.
• ERC-5528 Refundable Tokens (Refundable Fungible Token) — An extension standard that adds escrow (conditional holding of funds) to ERC-20 token trades, so that if the trade is not completed, the buyer can get the deposited tokens back to the original wallet.
• ERC-5564 Stealth Address (Stealth Addresses) — Lets a sender create a private address that only the recipient can open and send assets to it, without contacting the recipient beforehand. A single notification contract per chain announces that a payment was received.
• ERC-5568 A Signal Standard for Notifying Wallets of Required Actions (Well-Known Format for Required Actions) — A standard by which a smart contract notifies a wallet, in a machine-readable format via defined functions and revert reasons, of actions the user must take first.
• ERC-5570 Digital receipt NFT (Digital Receipt Non-Fungible Tokens) — A standard that turns the digital receipt a seller issues when a customer buys something in a store into an NFT, and puts the receipt contents in JSON format in its metadata.
• ERC-5585 NFT rights delegation standard (ERC-721 NFT Authorization) — An ERC-721 extension standard that separates NFT ownership from commercial usage rights, allowing an owner to delegate specific rights to other users for a set period.
• ERC-5606 Multiverse NFT bundle standard (Multiverse NFTs) — This standard bundles NFTs of the same digital asset, issued separately across different metaverses and games, into a single multiverse NFT that can be owned and traded as one unit or unbundled back into individual tokens.
• ERC-5615 ERC-1155 supply query extension (ERC-1155 Supply Extension) — Standardizes the totalSupply function, which queries the total supply of a given id for ERC-1155 tokens, and the exists function, which checks whether that id exists.
• ERC-5625 NFT metadata decentralized storage information extension (NFT Metadata JSON Schema dStorage Extension) — Adds a dStorage property to the NFT metadata JSON so that it can indicate which decentralized storage, and how, holds the image and other assets the NFT points to.
• ERC-5639 Delegation Registry (Delegation Registry) — A shared registry in which a vault wallet holding assets delegates proof-of-ownership authority to another wallet. A dApp can query this registry to confirm the vault wallet's asset holdings using only the delegate wallet's signature.
• ERC-5646 Token state fingerprint (Token State Fingerprint) — A standard that summarizes the current state of a token whose state can change into a single 32-byte fingerprint. External protocols can check whether the state has changed without knowing the token's internal implementation.
• ERC-5679 Token mint and burn extension standard (Token Minting and Burning) — An extension that adds mint and burn functions to EIP-20, EIP-721, and EIP-1155 tokens in a uniform way. It completes the basic token lifecycle of creating and destroying tokens with standard functions.
• ERC-5725 Transferable vesting NFT (Transferable Vesting NFT) — A standard that turns a vesting contract, in which locked tokens are released gradually over time, into an NFT so that it can be bought, sold, or moved.
• ERC-5732 Common commit interface (Commit Interface) — Defines a common interface containing only the commit function, so that the commit-reveal scheme, in which a choice is first submitted as a hash (commit) and revealed later, can be attached to any contract.
• ERC-5750 A trailing bytes argument for method extension (General Extensibility for Method Behaviors) — A standard that makes the last argument of a function a variable-length byte string (bytes) and establishes that slot as extension space for behavior to be added later.
• ERC-5773 Context-Dependent Multi-Asset Token (Context-Dependent Multi-Asset Tokens) — A standard that attaches multiple assets (files and data) to one NFT, so that the appropriate asset can be shown depending on the environment that opens it, such as an e-book reader, a game, or a marketplace.
• ERC-5805 Delegation-based voting power tracking standard (Voting with delegation) — A standard that lets token holders delegate voting power to another account without transferring the tokens themselves, and lets anyone query the voting power held at a specific point in the past.
• ERC-5982 Role-based access control standard (Role-based Access Control) — Defines a common interface for querying, granting, creating, and deleting smart contract permissions by role. A role is represented as a bytes32 value, and its power is defined as the ability to call specific functions.
• ERC-6059 Parent-governed nestable NFT (Parent-Governed Nestable Non-Fungible Tokens) — A standard that allows an NFT to own other NFTs. Anyone can propose a child token, but the owner of the parent token decides whether to accept it.
• ERC-6065 Real estate token (Real Estate Token) — A standard for putting real-world real estate onto an ERC-721-based NFT. It carries the operating agreement hash, property identification information, debt and foreclosure status, and the administrator address, so that property rights transfer together with the NFT.
• ERC-6066 NFT signature validation standard (Signature Validation Method for NFTs) — Defines a standard function that lets an NFT itself, rather than a regular account or a smart contract, be the subject of a signature, and lets anyone check whether that signature is valid.
• ERC-6093 Common custom error standard for tokens (Custom errors for commonly-used tokens) — Defines a common format for the errors that ERC-20, ERC-721, and ERC-1155 tokens use when they fail. Wallets and apps can interpret the cause of a failure as structured data and show it to the user.
• ERC-6105 Intermediary-Free NFT Trading Protocol (No Intermediary NFT Trading Protocol) — A standard that builds listing and purchase functions into the NFT contract itself, so ERC-721 tokens can be bought and sold without an intermediary marketplace. Creators can implement a wider variety of royalty schemes.
• ERC-6120 Universal token router (Universal Token Router) — A shared, single router contract that lets any token be used in one call, just like ETH. Instead of approving each app separately, you only need to approve this one router.
• ERC-6147 NFT and SBT Guard Extension (Guard of NFT/SBT, an Extension of ERC-721) — An ERC-721 extension standard that adds a time-limited management role called a guard to NFTs and soulbound tokens (SBTs), so the right to use a token while holding it can be separated from the right to transfer it.
• ERC-6150 Hierarchical NFT (Hierarchical NFTs) — An EIP-721 extension standard that creates parent and child relationships between NFTs, so that a filesystem-like tree structure can be managed within a single contract.
• ERC-6220 Equippable Composable Parts NFT (Composable NFTs utilizing Equippable Parts) — An ERC-721 extension standard that lets an NFT select and combine parts predefined in a catalog, and equip or unequip other NFTs in slots. Equipping does not create a new token, and the equipped items are rendered together when the token is queried.
• ERC-6224 Contract dependency registry (Contracts Dependencies Registry) — A management standard that registers the addresses of all smart contracts used by a protocol under names in a single registry, so each contract can fetch the dependency contracts it needs from there. Registered contracts can also be wrapped in a proxy for upgrades.
• ERC-6239 Semantic Soulbound Token (Semantic Soulbound Tokens) — Puts RDF triples, a W3C standard data model, in the metadata of non-transferable tokens (soulbound tokens, SBTs), so that social relationships between accounts and attributes are recorded on-chain in a machine-readable form.
• ERC-6315 Namespaced account abstraction (ERC-2771 Namespaced Account Abstraction) — An extension of ERC-2771 that, when handling meta-transactions such as gas fee sponsorship, gives each forwarder its own separate address space (namespace) so the receiving contract does not need to pre-trust the forwarder.
• ERC-6357 single-contract multicall (Single-contract Multi-delegatecall) — Standardizes a multicall function on smart contracts so that an externally owned account (EOA) can call multiple functions on the same contract in a single transaction, with all of them reverting if any one fails.
• ERC-6358 Cross-chain token state synchronization (Cross-Chain Token States Synchronization) — A standard in which contracts deployed on multiple chains jointly record the same token ledger as if it were a shared copy. Instead of moving tokens to another chain, state is synchronized across all chains.
• ERC-6366 Permission token standard (Permission Token) — A standard that stores the permissions held by an address as bits within a single uint256 number, and allows them to be transferred or delegated like a token. Permission checks are handled quickly using bitwise operations.
• ERC-6372 Contract clock disclosure interface (Contract clock) — An interface that lets a contract expose, via two standard functions, whether it internally measures time by block number or by timestamp.
• ERC-6381 Public NFT emote repository (Public Non-Fungible Token Emote Repository) — A common-good repository contract standard where anyone can leave or withdraw a reaction to any NFT using a Unicode emoji. It is reachable at the same address on every network.
• ERC-6454 Interface for identifying transferable NFTs (Minimal Transferable NFT detection interface) — Defines a minimal standard function that lets you ask the contract directly whether an NFT can currently be transferred. With it, you can create and identify NFTs that are bound to a specific account and cannot be traded.
• ERC-6492 Signature verification for contracts before deployment (Signature Validation for Predeploy Contracts) — Makes it possible to verify signatures created by a contract wallet that has not been deployed yet. When deployment information is appended to the signature, the verifier deploys the contract first if needed and then continues with ERC-1271 verification.
• ERC-6538 Stealth Meta-Address Registry (Stealth Meta-Address Registry) — A single shared registry per chain where stealth meta-addresses are registered on-chain and can be looked up by anyone. This lets senders send assets without revealing the recipient's actual address.
• ERC-6551 Token bound accounts owned by NFTs (Non-fungible Token Bound Accounts) — Gives every NFT a unique smart contract account, allowing the NFT to directly hold assets and interact with apps. There is no need to modify existing NFT contracts.
• ERC-6596 Cultural and Historical Asset Token (CHAT) metadata (Cultural and Historical Asset Token) — Defines a common metadata format for recording the provenance and historical context of cultural and historical assets, such as artworks, artifacts, and rare collectibles, when they are minted as NFTs. This makes it easier to search for and connect scattered collections.
• ERC-6617 Bit-based permission standard (Bit Based Permission) — A standard that represents a single smart contract permission as a single bit of a number. One uint256 can define up to 256 permissions and 2^256 possible roles.
• ERC-6672 Multi-exchangeable NFT (Multi-redeemable NFTs) — An ERC-721 extension standard that lets a single NFT be redeemed multiple times across different scenarios for physical goods or digital benefits, with each redemption recorded on the blockchain.
• ERC-6734 L2 token list standard (L2 Token List) — Defines a common token list (JSON) format that lets the same token be identified without confusion across multiple chains (layer 1, layer 2, sidechains). Lets you tell from the list alone which chain a token was issued on and what its original asset is.
• ERC-6735 Address aliasing between EVM chains (L2 Aliasing of EVM-based Addresses) — Defines an address aliasing method for consistently identifying and converting the addresses of the same asset or account across Ethereum-family chains (L1, L2, sidechains) according to a rule.
• ERC-6808 Key-Bound Fungible Token (Fungible Key Bound Token) — An optional security standard that binds two key wallets to an ERC-20 token so that transfers and approvals happen only under conditions the key wallets have allowed in advance. Even if a wallet is compromised, you can move the assets to safety or reset the settings.
• ERC-6809 Key-Bound NFT standard (Non-Fungible Key Bound Token) — An ERC-721 extension that builds optional security features into the NFT itself. An NFT can be moved only when two separate key wallets authorize the transfer and approval, so assets stay safe even if the holding wallet is compromised.
• ERC-6909 Minimal Multi-Token Interface (Minimal Multi-Token Interface) — A minimal interface that manages multiple tokens by id in a single contract. It removes callbacks and batch transfers from ERC-1155 and uses per-token-id allowance approvals together with full operator approvals.
• ERC-6956 Asset-bound NFT (Asset-bound Non-Fungible Tokens) — By attaching a unique identifier called an anchor to a physical or digital asset and binding it 1:1 with an NFT, and having an oracle prove that it actually holds the asset, the token can be moved without requiring the existing owner's signature.
• ERC-6982 Efficient Default Lock Token (Efficient Default Lockable Tokens) — A standard that adds locking to NFTs (ERC-721) and saves gas by announcing the default lock state once, instead of emitting an event for every token.
• ERC-7007 Verifiable AI-Generated Content Token (Verifiable AI-Generated Content Token) — An ERC-721 extension standard that makes it possible to verify on the blockchain that content created by AI, such as an image or video, was generated by a specific model from a specific input (prompt).
• ERC-7053 Interoperable digital media index (Interoperable Digital Media Indexing) — An indexing standard that attaches a content identifier (CID) derived from the content to each digital media file and records it on-chain through a Commit event, so that the history of the media can be found and verified across multiple contracts and EVM-compatible chains.
• ERC-7066 ERC-721 lock extension (Lockable Extension for ERC-721) — A standard that locks an NFT while it stays in the owner's wallet, blocking only sales and transfers. By designating an address with unlock authority (the locker), it enables financial uses such as lending and rental.
• ERC-7092 Financial bond token standard (Financial Bonds) — A standard for turning bonds issued by companies or institutions into tokens. It uses functions that keep traditional bond terms such as coupon rate, maturity date, and principal, and supports primary issuance, secondary trading, and movement between chains.
• ERC-7144 An ERC-20 token that goes through a validation step (ERC-20 with transaction validation step.) — An extension that holds ERC-20 transfer and approve calls in a pending validation state instead of executing them immediately. Because actual execution requires a separate validation step, tokens do not leave a wallet immediately even if its keys are stolen.
• ERC-7160 NFT Multi-Metadata Extension (ERC-721 Multi-Metadata Extension) — An ERC-721 extension standard that lets a single NFT carry multiple metadata addresses (URIs) and pin one of them as the representative.
• ERC-7201 Namespaced storage layout (Namespaced Storage Layout) — A rule that groups state variables used together into a struct, places it at an independent storage location determined by a hash, and marks that location with a source comment. It avoids storage collisions in upgradeable and modular contracts and lets analysis tools read where data is located.
• ERC-7208 Onchain data container (On-Chain Data Containers) — A standard that separates the storage of asset data from the logic that handles that data into separate contracts. The same data can be exposed through the interfaces of multiple token standards, which makes compatibility between standards easier.
• ERC-7231 Identity Aggregated NFT (Identity-aggregated NFT) — An ERC-721 extension standard that binds multiple Web2 and Web3 account identities to an NFT with the owner's approval and makes that binding verifiable onchain.
• ERC-7291 Purpose Bound Money (PBM) (Purpose bound money) — A standard that wraps digital money such as stablecoins in an ERC-1155 wrapper to create "purpose-bound money" that is released as the original currency only when set conditions are met and it is delivered to a designated merchant.
• ERC-7399 Flash loan standard interface (⚡ Flash Loans ⚡) — Unifies the request, callback, and repayment process for flash loans, which are borrowed and repaid within a single transaction, into one interface. Borrowers can switch between multiple lenders without modifying their code.
• ERC-7401 Parent-governed NFT nesting standard (Parent-Governed Non-Fungible Tokens Nesting) — Standardizes a parent-child nesting relationship, where an NFT owns other NFTs, as an ERC-721 extension. Anyone can propose a child token, but only the owner of the parent token can accept and manage it.
• ERC-7409 Public NFT emote repository (Public Non-Fungible Tokens Emote Repository) — A standard for a shared repository contract that lets anyone leave and revoke reactions to any NFT with Unicode emoji. Reaction records stay onchain, so everyone can query them at the same address.
• ERC-7432 NFT role assignment standard (Non-Fungible Token Roles) — Defines a common way to grant another account a role that expires automatically at a set time, while leaving ownership of the NFT unchanged. It can be used to split the utility of an NFT, as in digital real estate rentals or insurance policies.
• ERC-7439 Anti-scalping tickets (Prevent ticket touting) — A standard that issues concert tickets as NFTs but blocks even the owner from transferring them freely, so tickets can be resold only through authorized sales agents or approved resale platforms.
• ERC-7518 Dynamic compliance security token (Dynamic Compliant Interop Security Token) — A standard that extends ERC-1155 to manage security tokens within a single contract where rights and regulatory rules differ by partition. It provides token locking, address freezing, forced transfer, dividend payment, and signed voucher based compliance checks.
• ERC-7528 Native asset ETH address convention (ETH (Native Asset) Address Convention) — A convention that fixes 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee as the address that denotes ETH wherever ETH is handled like an ERC-20 token. It lets ETH and ERC-20 be recorded in a single event format.
• ERC-7535 Ether-native ERC-4626 vault (Native Asset ERC-4626 Tokenized Vault) — A standard that keeps the ERC-4626 tokenized vault interface intact while letting ether (ETH), Ethereum's native currency, be deposited into and withdrawn from the vault as its underlying asset instead of an ERC-20 token.
• ERC-7540 Asynchronous Tokenized Vault Extension (Asynchronous ERC-4626 Tokenized Vaults) — An extension of ERC-4626 tokenized vaults that adds asynchronous deposits and redemptions. You submit a Request first, and once the vault finishes processing it, you receive the result through the existing ERC-4626 functions.
• ERC-7562 Account abstraction validation scope rules (Account Abstraction Validation Scope Rules) — Defines the restrictions that UserOperation validation code must follow in ERC-4337 account abstraction, to prevent denial of service (DoS) attacks in which a flood of fee-free requests overwhelms bundlers and the public mempool.
• ERC-7575 Multi-asset ERC-4626 vault (Multi-Asset ERC-4626 Vaults) — A vault standard that extends ERC-4626 so that multiple asset entry points can be connected to a single share token. By separating the vault from the share token, it also allows vaults that convert between two external tokens.
• ERC-7578 Real-world asset redemption NFT standard (Physical Asset Redemption) — An ERC-721 extension that places key information such as the issuer, legal owner, storage location and contract terms in a standard format on NFTs backed by real-world assets, so that holders can verify authenticity and prepare for physical redemption.
• ERC-7586 On-chain interest rate swap standard (Interest Rate Swaps) — Enables standardized representation and execution, on a blockchain, of an interest rate swap, a derivative contract that exchanges fixed-rate and floating-rate interest payments.
• ERC-7588 Blob Transaction Metadata Standard (Blob Transactions Metadata JSON Schema) — Defines a way to write information such as the blob's author, description, and file format as JSON in the data field of a blob transaction. Blob lookup services and storage apps can then easily understand the contents of a blob.
• ERC-7627 On-chain secure messaging protocol (Secure Messaging Protocol) — Defines a common interface for end-to-end encryption messaging, where users register a public key on chain and send messages encrypted with the recipient's public key to an address.
• ERC-7628 ERC-721 ownership share extension (ERC-721 Ownership Shares Extension) — An extension standard that attaches an ownership/profit-share quantity to each token of an ERC-721 NFT, allowing that share to be queried, transferred to other tokens or addresses, and approved.
• ERC-7631 Dual-nature token pair (Dual Nature Token Pair) — Defines how to link an ERC-20 token and an ERC-721 token (NFT) as a pair, so that a transfer on one side is reflected on the other, along with a lookup for the link between the two contracts and a setting to skip automatic NFT minting.
• ERC-7634 Transfer-limited NFT (Limited Transfer Count NFT) — An ERC-721 extension standard that sets an upper bound on how many times each NFT can be transferred and blocks further transfers once that count is used up.
• ERC-7656 Contract Linking Service Factory (Generalized Contract-Linked Services) — A shared factory standard that deploys, at a precomputable address, a "linked service" that adds functionality to an existing contract such as an NFT or smart account without changing its original code.
• ERC-7674 ERC-20 temporary approval extension (Temporary Approval Extension for ERC-20) — An extension that adds a temporary approval to ERC-20 tokens, valid only for the duration of a single transaction. Temporary approvals are automatically cleared once the transaction ends, leaving no residual approval.
• ERC-7734 A decentralized identity verification standard (Decentralized Identity Verification (DID)) — A minimal standard that keeps identity information such as names and documents off-chain and puts only the hash of that information on-chain, so that identities can be created, verified, and revoked.
• ERC-7743 Multi-owner NFT (MO-NFT) (Multi-Owner Non-Fungible Tokens (MO-NFT)) — A standard that lets multiple people own a single NFT at the same time. Transferring it keeps the existing owners in place, and a set fee is paid to the provider on every transfer.
• ERC-7744 Code Index (Code Index) — A global index standard that registers and looks up deployed smart contracts by the bytecode hash, the fingerprint of the code, rather than by address. Anyone can look up, verify, and reuse code without anyone's permission.
• ERC-7746 Composable security middleware hooks (Composable Security Middleware Hooks) — Defines a standard interface, ILayer, that lets a smart contract call out to external security layers before and after function execution to delegate validation. It separates security checks from the core logic so they can be composed and swapped.
• ERC-7751 Nested revert error wrapping (Wrapping of bubbled up reverts) — A standard that, when a contract call to another contract fails, wraps the failure in a standard error carrying context about where and why it failed, instead of rethrowing the failure reason as is.
• ERC-7786 Cross-chain messaging gateway (Cross-Chain Messaging Gateway) — A common interface that contracts on different blockchains use to exchange arbitrary data. It lets messages be sent and received in the same way no matter which bridge is used.
• ERC-7812 ZK identity registry (ZK Identity Registry) — Commitments to secret data are stored in a single on-chain registry at a fixed address, so that later, without disclosing the data, their validity and authenticity can be proven via zero-knowledge proofs.
• ERC-7813 Table-based onchain storage (Store, Table-Based Introspectable Storage) — A storage standard that saves smart contract data in tables like a database and emits a standard event whenever it changes, so that offchain services can automatically replicate the state.
• ERC-7818 ERC-20 token with an expiry period (Expirable ERC-20) — An extension standard that attaches an expiry period to an ERC-20 token. Once the set period has passed, the token expires and can no longer be transferred or used.
• ERC-7820 Access Control Registry (Access Control Registry) — A standard that lets a single registry contract register, grant, revoke, and query role-based access permissions for multiple smart contracts.
• ERC-7837 Diffusive token (minted on transfer) (Diffusive Tokens) — A fungible token standard in which sending tokens does not reduce the sender's balance and new tokens are minted to the recipient. Each transfer pays a per-token fee in the native currency such as ETH, and total issuance has a cap.
• ERC-7857 Private Metadata AI Agent NFT (AI Agents NFT with Private Metadata) — A standard for owning private data of an AI agent, such as its model, memory, and character, as an NFT, and for cryptographically verifying that the data was actually and securely handed over when it is transferred.
• ERC-7858 NFTs and SBTs with an Expiry (Expirable NFTs and SBTs) — An ERC-721 extension standard that adds a validity period to NFTs and soulbound tokens (SBTs). When a set block number or time passes, the token becomes expired, which makes it possible to represent time-limited uses such as memberships, tickets, and subscriptions.
• ERC-7878 Bequeathable Contract (Bequeathable Contracts) — A standard interface that lets a token owner set up a will in advance, so that after the owner's death an executor can transfer the tokens to an inheritor following a set waiting period.
• ERC-7893 DeFi Solvency Proof Standard (DeFi Protocol Solvency Proof Mechanism) — A standard interface that lets a DeFi protocol record its assets and liabilities onchain so that anyone can look up and verify, in the same way, how well it can repay its debts (solvency).
• ERC-7908 HD Wallet Path Standard for Treasury Management (HD wallet In Treasury Management) — Defines an HD wallet path that lets a company derive isolated Ethereum accounts for each subsidiary and department from a single master key using fixed rules. It enables unified group management and permission separation between departments at the same time.
• ERC-7913 Signature verifier for addressless keys (Signature Verifiers) — A standard that allows signatures made by keys without an Ethereum address (such as a mobile device's P256 key or an RSA key) to be verified through a shared verifier contract. There is no need to deploy a contract for each key.
• ERC-7930 Interoperable address (Interoperable Addresses) — Defines a format that combines an address and its associated chain information into a single binary value. It can hold addresses from chains other than Ethereum, such as Solana, within the same framework.
• ERC-7943 Universal Real-World Asset Token Interface (uRWA - Universal Real World Asset Interface) — Defines a common interface for real-world asset (RWA) tokens such as securities and real estate. It adds the regulatory compliance features these tokens need, namely transferability checks, asset freezing, and forced transfers, on top of existing token standards such as ERC-20, ERC-721, and ERC-1155.
• ERC-7945 Confidential transfer capable token (Confidential Transactions Supported Token) — A common interface for tokens that hide account balances and transfer amounts as encrypted data. It lets wallets and apps handle amount-concealing tokens without being tied to a specific implementation.
• ERC-7950 Transaction hash notation with a chain ID (Encode chain id with transaction hash) — A notation that combines a chain ID and a transaction hash into a single string. It lets you tell which chain a transaction belongs to from the string alone.
• ERC-7994 Conditionally Released Purpose-Bound Token (Purpose-Bound ERC-20 with Conditional Unlock) — A standard that attaches multiple release conditions, such as time, identity verification, and intended use, to an ERC-20 token transfer, so that the recipient can only claim the tokens once all conditions are met.
• ERC-8001 Agent coordination framework (Agent Coordination Framework) — A framework in which multiple automated programs (agents) agree on a single task without a trusted intermediary. A proposer posts an intent, and it can be executed only when all participants accept it with signatures.
• ERC-8034 Referential NFT Royalty Distribution (Referable NFT Royalties) — A standard that defines how to split royalties among multiple recipients and the referenced original NFTs when NFTs linked by reference relationships (rNFTs) are sold.
• ERC-8042 Diamond Storage (Diamond Storage) — Standardizes the diamond storage pattern that uses the keccak256 hash of a human-readable string as the storage location of a struct. It lets a single contract manage its storage divided into separate regions.
• ERC-8063 Group membership token (Groups - Membership Tokens) — A standard that interprets an ERC-20 token's balance as a group membership level. A balance of zero means non-member, and a balance at or above a set threshold means membership at that tier, allowing tiered membership to be built on top of an existing token as is.
• ERC-8126 AI agent verification (AI Agent Verification) — A standard that checks AI agents registered under ERC-8004 through five specialized verifications covering token, media, code, web and wallet, and provides the results as a 0 to 100 risk score and a zero-knowledge proof.
• ERC-8153 Facet-based diamond (Facet-Based Diamonds) — A standard for diamond contracts, which bundle multiple implementation contracts (facets) behind a single address. Each facet reports its own function list, which makes deployment and upgrades simpler and cheaper.
• ERC-8161 Transferable tokenized vault requests (Transferable Tokenized Vault Requests) — An optional extension that allows deposit and redemption requests pending processing in an asynchronous vault (ERC-7540) to be transferred in whole to another address.
• ERC-8167 Modular Dispatch Proxy (Modular Dispatch Proxies) — A standard for proxy contracts that route function calls to different logic modules according to the first 4-byte selector. It lets tools look up a proxy's function list and the implementation address of each function.
• ERC-8196 AI Agent Authenticated Wallet (AI Agent Authenticated Wallet) — A wallet standard that only executes transactions when there is cryptographic proof that an AI agent complied with policies set by the asset owner. It allows authority to be delegated to an agent without handing over the private key.
• ERC-8325 Asset Anchor Registry (Asset Anchor Registry) — A registry interface that binds a token contract or token ID to an off-chain asset claim record (anchor). It lets anyone query, in a common way, which token is bound to which record and whether that binding is still valid.
• ERC-8326 Document Bundle Hash Anchor Standard (Canonical Document Bundle Anchor) — A standard that sorts multiple off-chain documents according to a fixed rule into a single hash (bundle hash), records it on-chain by subject and role, and preserves a history of supersessions.
• ERC-8327 Directional transfer domain registry (Directional Transfer Domain Registry) — Defines a shared registry interface for querying, for each ordered pair of source domain, destination domain, and asset class, whether a transfer path is currently permitted. Multiple tokens and contracts can share a single path policy.
• ERC-8328 Actor-linked compliance event log (Subject-Linked Compliance Event Log) — Defines an append-only shared log that records regulation-related actions, such as token issuance, freezes, and KYC (know-your-customer) changes, per actor. Records cannot be deleted, and corrections are preserved as a linked history.
• ERC-8329 Subject-linked impact snapshot log (Subject-Linked Impact Snapshot Log) — A standard for recording quantitative impact measurements, such as carbon emissions, employment, or water treatment, on-chain in an append-only manner, tied to a subject, period, unit, and methodology. It preserves correction history and support/dispute attestations without erasing past records.