Asset Management

ERC-2981 standardizes an NFT royalty query. An implementing contract can return a percentage-based amount and royalty recipient through royaltyInfo(); a sale venue may query and honor that information, but marketplace adoption and payment enforcement vary.

Category: NFT Capabilities

ERC-3475 models financial obligations with balances keyed by class, nonce, and amount. A single contract can represent configurable bond series and metadata; an NFT wrapper or secondary market is an application layer rather than the core token model.

Category: DeFi Patterns

ERC-3643 provides identity and compliance checks for ordinary token transfers; mint and forcedTransfer use distinct privileged paths and burn has its own rules. Read the deployed identity and compliance modules instead of assuming every operation uses the same gate.

Category: Identity & Privacy

ERC-4626 standardizes tokenized vault interfaces. Deposit an underlying asset and receive shares representing a claim on the vault; share-to-asset value and yield depend on the deployed strategy. Different protocols can expose the same deposit, withdraw, share, and asset methods without guaranteeing positive returns.

Category: DeFi Patterns

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-4910 connects NFTs to royalty accounts and subaccounts, supporting hierarchical splits, direct payment processing, listings, and payouts. It does not define a separate royalty bearer token or a general transferable-rights interface; any such asset is an implementation extension.

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-5007 adds start and end timestamp fields to NFTs. Consuming contracts can use those fields for subscriptions, season passes, or time-limited memberships; enforcement, boundary rules, and renewal remain 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-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

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.

Category: Security & Trust

NFTs can reference other NFTs — creating a directed graph of relationships (remixes, derivatives, citations).

Category: NFT Capabilities

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.

Category: Security & Trust

ERC-5725 turns vesting schedules into transferable NFTs. Your employee token grant, investor allocation, or airdrop vesting becomes a transferable position; a marketplace can offer a sale at a discount when the deployed position and application support it.

Category: DeFi Patterns

ERC-6105 defines a direct NFT listing and purchase path through listItem, delistItem, and buyItem. A deployment may avoid relying on an intermediary trading platform, but the standard does not guarantee zero contract, application, royalty, gas, or other fees; show the target implementation's actual terms.

Category: NFT Capabilities

EIP-6110 moves Ethereum validator-deposit processing into execution-layer block data and consensus-layer execution requests. After Pectra activation, a staking product can track a deposit from the deposit-contract event through execution inclusion, consensus processing, pending balance, and validator activation; a successful deposit transaction alone does not mean the validator is active.

Category: DeFi Patterns

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.

Category: Security & Trust

Filesystem-like hierarchical NFTs — tokens have parent/child relationships like folders and files.

Category: NFT Capabilities

ERC-6220 standardizes on-chain equipment for NFTs through slots, Catalog compatibility, and fixed or equippable part metadata. A compatible renderer may compose the parts, but visual changes, composed-image generation, marketplace support, and cross-platform display remain collection and client policy.

Category: NFT Capabilities

Tokens can be non-transferable (soulbound) or have transfer restrictions — verifiable on-chain.

Category: NFT Capabilities

EIP-7002 supplies the execution-layer request path for validator exits and withdrawals. Under Electra's integrated processing, a request whose source address matches a validator's 0x01 or 0x02 execution withdrawal credential can request a full exit with amount=0; a positive amount requests a partial withdrawal only for a 0x02 compounding credential when effective balance is at least 32 ETH and balance exceeds 32 ETH plus pending partial withdrawals. Ethereum activated the path in Pectra; requests enter an execution-layer queue, pay a dynamic request fee, and are then processed by the consensus layer.

Category: DeFi Patterns

NFTs can be locked in the owner's wallet. While locked, ERC-721 approval and transfer are restricted, with an exception when the caller is both the approved address and the locker; other application utility is implementation-specific.

Category: NFT Capabilities

Users hold traditional financial bonds on-chain with familiar terms — ISIN, coupon rate, maturity date, denomination, principal.

Category: DeFi Patterns

EIP-7251 raises Ethereum's validator maximum effective balance to 2048 ETH while keeping the 32 ETH minimum activation balance. Validators with a 0x02 compounding withdrawal credential can earn rewards above 32 ETH, top up in flexible amounts, and participate in consolidation flows; the credential, validator state, queues, and network activation determine which controls are available.

Category: DeFi Patterns

ERC-7401 is the Final successor to ERC-6059 for parent-governed NFT nesting. It preserves the nesting model while correcting the interface identifier; compatible collections can expose accepted and pending children, and products should verify the target implementation before promising transfer or extraction behavior.

Category: NFT Capabilities

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

ERC-7535 is a native-asset override of ERC-4626. A compatible vault can accept native ETH through payable deposit or mint calls without a separate WETH wrapping step; support, gas cost, fees, and withdrawal output remain deployment- and network-specific.

Category: DeFi Patterns

ERC-7540 adds optional asynchronous deposit and/or redemption flows to ERC-4626 vaults. A deployed vault can keep one side synchronous while requests on the other side settle later, which helps real-world-asset, illiquid, and delayed-settlement strategies expose their timing clearly.

Category: DeFi Patterns

ERC-7575 groups asset-specific ERC-4626 entry-point vaults that issue a common share token. Users can choose among the deployed group members, such as an ETH or USDC entry point, while the application presents their shared share asset and each entry point's own rates and limits.

Category: DeFi Patterns

NFTs can have a maximum count for native ERC-721 transfers. After the cap is reached, the implementation chooses the resulting state; locking, burning, or another action is not mandated by ERC-7634.

Category: NFT Capabilities

ERC-7818 adds expiration timestamps to ERC-20 token batches. Applications can show when each batch expires and apply the deployed contract's transfer and spending rules; FIFO selection and burn/recycle behavior are optional implementation choices.

Category: DeFi Patterns

ERC-7858 reports block-based or time-based expiration for NFTs and SBTs. Utility consumers must enforce the reported expiry; ownership and ordinary transfer behavior remain governed by the token implementation.

Category: NFT Capabilities

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-7994 defines purpose-bound money through a binding that names a recipient, amount, unlock conditions, and optional expiry. Merchant, KYC, category, receipt, and spending-limit behavior comes from the condition implementations selected by the issuer; the standard does not provide a universal merchant directory or transfer pre-check.

Category: DeFi Patterns

ERC-2266 defines an HTLC-based American Call Option for peer-to-peer token exchanges. It coordinates initiator and participant assets, a premium, separate timelocks, and redeem/refund calls; settlement and refund availability depend on the option state and the relevant deadlines.

Category: DeFi Patterns

ERC-5114 defines an immutable soulbound badge binding to a specific NFT and content-addressable badge metadata. It does not define an issuer registry, revocation function, identity verification, or validity status; show those as separate issuer or application policy when present.

Category: Identity & Privacy

ERC-6551 defines a registry that computes deterministic token-bound account addresses for NFTs and can deploy them as smart-contract accounts. A deployed or counterfactual account can hold assets, but each NFT may have multiple accounts across implementations, registries, chains, and salts; sale contents must be rechecked at settlement.

Category: NFT Capabilities