An ERC describes conventions applications can agree to implement. A Core EIP instead concerns protocol rules that require a network upgrade. Ethereum's proposal process gives documents stages including Draft, Review and Final; those labels describe the document's maturity. They do not certify a deployed contract, its operator or its investment prospects. The standards in this reading should therefore be evaluated at two levels: what the text asks for, and what a particular contract actually does.

ERC-165 lets a contract report which interface identifiers it supports. This is useful when a marketplace or wallet needs to recognize a capability before calling it. The response remains a declaration by software. A dishonest contract can claim a capability, and a compliant interface can sit above dangerous administration. Treat detection as a routing tool rather than a safety verdict. Successful communication is the first question in an integration, followed by behavior, permissions and failure handling.

ERC-20, created in November 2015 and now Final, standardizes balances, transfers and delegated spending. A spender can move an owner's tokens within an allowance through transferFrom. A wallet can display many assets without inventing a separate integration for each issuer. Name, symbol and decimals are optional metadata, however. A ticker is not a unique identity, and the familiar interface does not prescribe an issuance policy, backing, redemption promise or business model.

OpenZeppelin's implementation documentation shows how much variation remains around that familiar surface. SafeERC20 accommodates tokens whose transfer functions return false or omit a return value. Separate extensions add features such as pausing, caps or voting. These are implementation choices with different consequences. A token whose interface looks ordinary may still restrict transfers or give an administrator special powers. Integration libraries help callers handle known variations; they cannot make every arbitrary token economically sound or remove authority from its contract.

ERC-2612 adds permit, a signed approval containing an owner, spender, amount, deadline and nonce. Another actor can submit the signature, reducing the need for a separate owner-funded approval transaction. The approval still creates spending authority. A pleasant signing screen or absence of an immediate gas charge does not make it harmless. The specification discusses replay domains, expired signatures and front-running. Readers should distinguish signing permission from sending tokens, because the permission may be exercised later by its authorized recipient.

ERC-721 is Final and identifies distinguishable items by a contract address and token ID on a chain. It tracks ownership and provides transfers and operator approvals. An approved operator can act across the owner's collection, which makes marketplace interaction convenient and broad permissions consequential. Safe transfer checks whether a contract recipient implements the expected receiver interface. These mechanisms describe the token record. They do not automatically transfer copyright, guarantee the availability of an image or prove the seller owns an associated physical object.

ERC-4906 addresses a quieter problem: applications cache collectible metadata, then fail to notice it changed. The Final extension provides events announcing changes for an item or a range of items, allowing platforms to refresh their view. A reveal collection or evolving game item can use that signal without a bespoke event integration. This improves discovery of changes; it does not make the metadata immutable. The important ownership question remains who can change the underlying content and under what authority.

ERC-1155, created in June 2018 and Final, supports multiple token types within one contract. One identifier can represent many interchangeable units, while another represents a scarce item. Batch balance queries and transfers suit inventories containing different items. The receiver callback checks contract recipients, and transfer events provide the record applications follow. This is useful for game assets and editions, but it does not decide whether a receiving game recognizes the item or implements its behavior.

The original discussion of proposed ERC-7603 makes the larger metaverse ambition visible. Its author wanted different media contexts for multi-asset tokens and argued that developers should coordinate across engines. Other participants asked how the proposal differed from existing machinery, and the author acknowledged that differences had not yet been established. That exchange is evidence of an interoperability aspiration and a technical challenge. It is not evidence that arbitrary games can already import each other's objects, economies or rules.

Final ERC-6909 offers a deliberately smaller multi-token interface. It removes mandatory receiver callbacks and batch operations, leaving implementations to choose additional behavior. Permissions combine allowances for an individual token ID with operators able to act across the owner's inventory. Its authors argue that a smaller common surface leaves room for implementation tradeoffs. This is an alternative design rather than full compatibility with every ERC-1155 consumer.

An integration must recognize the actual interface and approval model before assuming an inventory transfer has familiar receiver checks.

ERC-4626 is a Final interface for vault shares over a single underlying ERC-20 asset. It distinguishes depositing an amount of assets from minting an amount of shares, and withdrawing assets from redeeming shares. Conversion and preview methods help applications reason about those quantities. Standardizing the interface reduces custom adapters. It leaves the investment strategy, accounting details and operating controls to the implementation. A share token can represent exposure to a vault; the standard does not promise appreciation or immediate access under every circumstance.

OpenZeppelin's vault guide illustrates how rounding and donations can threaten a poorly protected vault, particularly around its early deposits. An attacker can manipulate the assets-to-shares relationship so a later depositor receives too few shares. The guide explains mitigation using virtual assets and shares and a precision offset. This is a technical design analysis, not a claim that every vault has been exploited. Before treating a standard badge as reassurance, inspect the implementation, its rounding behavior, its minimum outcomes and the controls surrounding deposits.

Asynchronous vaults require another layer. Final ERC-7540 introduces request states so a deposit or redemption can be pending before it becomes claimable. The interface acknowledges that some assets cannot be settled in the same transaction. Its linked development discussion includes Maple implementation experience alongside objections about estimates, locked shares and liquidity during stressed withdrawals. A request is therefore different from cash already available to withdraw. The duration, cancellation policy and accounting at fulfillment matter to the practical meaning of the claim.

Final ERC-7535 adapts the vault interface to native assets such as Ether. Deposits and mints are payable, and the accounting input is the value sent with the call rather than an ERC-20 transfer approval. The specification explicitly separates native Ether from wrapped Ether vaults. This matters to both users and integrators: similar function names can conceal different funding behavior. Its security discussion highlights accounting and external-call risks. Supporting the familiar vault interface does not remove the need to inspect the underlying asset and payment path.

Final ERC-2981 exposes a royalty recipient and amount for a given sale price. It does not make every transfer collect a fee: moving an item between one's own wallets need not be a sale. Marketplaces choose whether to honor the information and arrange payment. A creator's requested percentage and revenue actually received remain separate observations, especially across venues with different policies.

The originating GitHub discussion proposed creator income from repeated resale and considered how marketplaces would fetch, pay and record royalties. Its early interface and suggested flow differ from the final minimal convention. That is a useful historical lesson: an initial design expresses an economic hope, then negotiation narrows the software agreement. The discussion documents contributors trying to support artists. It does not bind every exchange, prove a buyer accepted a license or establish guaranteed future revenue for a collection.

Final ERC-4907 adds a user role and expiration to an ERC-721 item. The owner can grant temporary use without giving the user transfer authority. A game could consult that role to decide who may use an item for a period. This is an on-chain permissions model, not a complete rental business. Applications still decide what use means, how rent is collected and what happens when their service ends. A contract's expiry field cannot force an unrelated application to recognize the user's rights.

Ronan Sandford's July 2022 lease discussion proposed a registry for rental agreements rather than modifying every collectible contract. He argued it could accommodate existing items and more flexible owner-user agreements, and explicitly compared it with ERC-4907. The difference exposes a real design choice: extending the item itself or recording permissions in another system. Neither approach eliminates integration work. Readers assessing a rental product should ask which registry or token method the actual application checks, rather than assume one standard covers all arrangements.

Final ERC-3525 combines a unique ID, a grouping called a slot and a quantitative value. Values can move between compatible tokens while the token itself retains an identifiable record. Its authors describe financial positions and other structured assets as possible uses. That is a richer model than choosing simply between a coin and a collectible. The grouping rules and surrounding contract still determine what the value represents. Two positions sharing a slot are not automatically equivalent legal obligations or equally liquid investments.

Final ERC-5192 provides a minimal way to detect a locked, non-transferable collectible. Final ERC-5484 adds a more opinionated model in which issuer and recipient agree in advance on who may burn the credential. These designs support the community's interest in reputation and membership that cannot simply be purchased from another owner. Their existence also raises practical questions about unwanted credentials, privacy and recovery. A non-transferable record does not make its issuer truthful, and different burning rules have different consequences for the person represented.

Final ERC-223 requires a receiving contract callback so incompatible recipients reject tokens rather than silently accepting an unusable balance. Final ERC-1363 instead adds transfer-and-call and approve-and-call behavior around an ERC-20 interface. Both address the awkwardness of coordinating payment with another action. The callback introduces a conversation with receiving software. Whether the receiver behaves safely becomes part of the transaction design, and applications need to understand precisely which path they support rather than assume all token transfers are interchangeable.

Final ERC-777 offers operators and sending and receiving hooks, with an ERC-1820 registry used to discover implementations. Its ambition is a more expressive token interaction model. Hooks mean execution can pass to other code during what an integrator imagined was a simple movement of balances. The specification's security discussion makes reentrancy and hook behavior relevant to implementers. A more capable standard is therefore a different engineering tradeoff, rather than a universally safer replacement that automatically fixes every earlier token integration.

Final ERC-1046 extends metadata discovery across token types and includes explicit warnings about fetching arbitrary URLs. This connects token standards to the ordinary security of the applications displaying them. A polished logo and a readable description can come from mutable external content. The metadata tells a client how to present an asset; it cannot authenticate every claim in that presentation. Readers should inspect contract identity, provenance and update permissions when the visual presentation carries much of the project's credibility.

Final ERC-173 defines how software can discover a contract owner and transfer that ownership. It gives interfaces a familiar way to display one administrative relationship. It does not reveal every role, upgrade mechanism or privilege a complex asset may contain. The practical research task is to follow control through the specific code and governance configuration. A common interface helps organize that investigation, while conclusions about backing, profits or censorship resistance require evidence beyond the presence of a standard function.