Ethereum ERCs

repository·master·Indexed 20 days ago

https://github.com/ethereum/ercs

Central repository for documenting Ethereum Request for Comments (ERCs), providing standards for the Ethereum application layer to ensure seamless interaction between applications. Includes specifications and reference implementations for various standards such as ERC-4400, ERC-4519 (SmartNFT), ERC-4675 (Multi-Fractional NFT), EIP-4907, EIP-5007, EIP-5218, EIP-5252, EIP-5725 (Transferrable Vesting NFT), ERC-6123 (SDC), EIP-6358, and ERC-6604.

Tokens
872.7K
Snippets
1.4K
Records
2.7K
Agent score
72%

What's inside ethereum-ercs

  1. Overview of ERC-7409: Public Non-Fungible Tokens Emote Repository

    master

    ERC-7409 is a standard that allows users to react to ERC-721 and ERC-1155 tokens using Unicode emojis. It provides a public, non-gated repository smart contract that exists at the same address across all Ethereum networks, enabling standardized on-chain interactions.

    Key improvements over ERC-6381: ERC-7409 supersedes ERC-6381. While ERC-6381 used bytes4 to represent emojis, ERC-7409 uses string to accommodate the full range of Unicode emojis, including variation flags and skin tones.

    Core Use Cases:

    • Interactivity: Allows users to express admiration or react to actions performed by token owners.
    • Feedback-based evolution: Enables tokens to evolve or change state when specific emote thresholds are met on-chain.
    • Valuation: Provides real-time, on-chain indicators of desirability and social sentiment, offering a metric beyond simple sales history.
  2. Overview of ERC-7585: MixHash and Public Data Storage Proofs

    master

    ERC-7585 introduces a design for "minimum value selection" storage proofs on Merkle trees. It is designed to address the lack of mechanisms for verifying the existence of public data in existing standards like ERC-721 and ERC-1155.

    The proposal consists of two primary components:

    1. MixHash: A new hashing algorithm intended to replace Keccak256 and SHA256.
    2. Public Data Storage Proofs: A mechanism that allows a party to present a proof to a public network to verify they possess a copy of specific public data identified by its MixHash.
  3. Overview of ERC-8257 Agent Tool Registry

    master

    ERC-8257 defines a permissionless onchain registry designed for AI agent tools. It provides a chain-native directory that allows agents to discover and verify tools through a combination of onchain commitments and offchain manifests.

    Key Features

    • Onchain Commitment: The registry stores a keccak256 hash of an offchain manifest. This allows consumers to verify that the fetched manifest has not been tampered with.
    • Extensible Access Control: Tool invocation is gated by an optional external predicate contract. This follows a pluggable pattern (similar to Seaport zones or Uniswap v4 hooks), allowing for any access model such as NFT gating, subscriptions, or DAO votes without changing the registry itself.
    • Origin-Binding: Registrations are anchored to a canonical offchain manifest served at a well-known path on the endpoint's origin.
    • Protocol-Agnostic Pricing: Pricing details are stored in the offchain manifest rather than onchain. The manifest includes pricing hints and identifies the payment protocol via an opaque string, allowing agents to compare costs before invocation. The registry does not handle funds; the endpoint enforces payment based on the manifest's declarations.
  4. Overview of ERC-6551: Non-fungible Token Bound Accounts

    master

    ERC-6551 defines a system that assigns a unique Ethereum smart contract account to every non-fungible token (NFT). This allows NFTs to act as autonomous agents capable of owning assets, executing operations, and interacting with decentralized applications (dApps) just like a standard Ethereum user account.

    Key Capabilities

    • Self-Custody: NFTs can own other on-chain assets (fungible or non-fungible).
    • Agency: NFTs can execute arbitrary operations on-chain.
    • Compatibility: The system works with existing ERC-721, ERC-1155, and other standards without requiring changes to the original NFT smart contracts.
    • Infrastructure Support: Because the bound accounts are standard Ethereum addresses, they are compatible with existing on-chain protocols and off-chain indexers.

    Core Mechanism

    A singleton registry is used to assign unique, deterministic smart contract account addresses to NFTs. Each account is permanently bound to a single NFT, and the holder of that NFT maintains control over the account.

  5. Overview of PBM Solidity implementations

    master

    This repository provides sample implementations of Programmable Burn Mechanisms (PBM) for reference. The provided files include:

    • contracts/preloaded-pbm/XXXX.sol: PBMRC1 implementation demonstrating preloaded PBMs.
    • contracts/non-preloaded-pbm/XXXX.sol: Interface contract for non-preloaded PBMs.
    • contracts/XXXX.sol: General interface contract.
    • contracts/ERC20.sol: ERC20 token contract used for unit testing.
    • test/XXXXX.js: Unit tests covering the lifecycle of the PBM implementations.
  6. Overview of ERC-6105: No Intermediary NFT Trading Protocol

    master

    ERC-6105 is a protocol designed to add marketplace functionality directly to ERC-721 tokens. It enables non-fungible token trading without the need for a centralized intermediary trading platform. This protocol aims to solve several industry issues:

    • Security: Reduces reliance on setApprovalForAll, which exposes users to risks if a platform is compromised or if phishing scams occur.
    • Cost Efficiency: Minimizes gas expenditures by reducing the need to authorize multiple platforms and eliminates high trading service fees charged by centralized platforms.
    • Liquidity & Decentralization: Addresses the problem of dispersed liquidity and centralized decision-making found in aggregators and off-chain order books.
    • Royalty Control: Allows creators to implement more diverse and reliable royalty schemes that are not subject to the centralized decisions of trading platforms.
    • Censorship Resistance: Provides a decentralized alternative to platforms that may delist NFTs or implement non-transparent delisting rules.
  7. Overview of ERC-7498: NFT Redeemables

    master

    ERC-7498 is an extension to ERC-721 and ERC-1155 designed to standardize the discovery and use of both onchain and offchain redeemables for NFTs. It provides a predictable interface for creators to offer entitlements (such as digital goods or physical products) tied to specific tokens.

    Key capabilities include:

    • Discovery: Uses onchain getters and events so users and applications can identify redemption campaigns and their specific requirements.
    • Onchain Redemptions: Provides context to minting contracts regarding what was redeemed during the process.
    • Offchain Redemptions: Enables association with e-commerce orders by using a redemptionHash and a signer to link onchain actions to offchain order identifiers (containing product and shipping details).
    • Trait Redemptions: Integrates with ERC-7496 Dynamic Traits to improve the 'burn-to-redeem' user experience.
  8. Overview of ERC-7777: Governance for Human Robot Societies

    master

    ERC-7777 defines a standard for managing identities and governance in mixed societies of humans and robots. It introduces two primary interfaces to facilitate decentralized, rule-based interactions:

    1. IUniversalIdentity: Enables both humans and robots to establish on-chain identities. For robots, this includes support for hardware-backed identity verification, allowing physical devices to prove their identity via cryptographic signatures from secure hardware elements using a challenge-response scheme. This allows robots to participate in on-chain transactions and comply with digital laws.

    2. IUniversalCharter: Provides a framework for creating and managing self-regulated societies (charters). It allows participants to create, register (join), update, leave, and terminate societies governed by specific, predefined rule sets. This enables scalable, decentralized governance that is not tied to physical geography.

    These interfaces aim to provide an equitable framework where non-human computer architectures can interact with humans in a transparent, secure, and enforceable manner.

  9. Overview of My Own Messages (MOM) - ERC-2848

    master

    My Own Messages (MOM) is a standard for creating public, unstoppable, and verifiable message boards using Ethereum as a certification layer. Instead of using smart contracts, MOM utilizes simple self-send transactions with specific payloads attached to notarize the multihash of a message.

    Key Use Cases

    • Developers/Pool Owners: Send decentralized messages to users that are as reliable as the smart contract itself, avoiding reliance on third-party social media.
    • Users: Publish content, share thoughts, or send messages to smart contract owners or transaction senders without complex tooling.
    • Explorer Services: Provide a native, secure way for users to read information from smart contract owners without using external comment systems (like Disqus).

    Core Advantages

    • Verifiability: By notarizing the multihash of the content on-chain, you can verify the integrity of messages even if they are stored on centralized services or distributed via IPFS/Swarm.
    • Low Cost: Users pay a small transaction fee to notarize messages, making it more affordable than on-chain storage.
    • Security: Transactions have no value transfer (unless intended) and no smart contract addresses to fake, reducing scam potential. Spam is mitigated by the cost of transactions and the requirement for listeners to explicitly follow/listen to specific accounts.
  10. Overview of Universal Orchestrator RPC (ERC-7845)

    master

    ERC-7845 defines a universal data model for a request for a solution sent from an arbitrary system (like a website, app, voice assistant, or server) that manages an Ethereum wallet to an Orchestrator.

    This standard aims to solve the inconsistency in how different systems request complex actions (e.g., swaps, multi-asset transfers, or balance inquiries) by providing a standardized RPC shape. All solutions provided by an Orchestrator under this standard are intended to be Chain Abstraction-first (ChA) by default.

  11. What is ERC-6734 (L2 Token List)?

    master

    ERC-6734 defines a JSON-based token list standard designed to ensure correct token identification across different Layer 1 (L1), Layer 2 (L2), and Sidechain systems.

    Its primary purpose is to solve the problem of 'canonical' token identification when bridging assets between chains. When a token is bridged from Chain A to Chain B, it often requires a new representation. This standard provides a way for users and systems to disambiguate which token on one chain corresponds to a token on another, preventing errors in multi-chain environments.

  12. Overview of ERC-6358: Cross-Chain Token States Synchronization

    master

    ERC-6358 defines a standard interface for contract-layer, consensus-agnostic verifiable cross-chain bridging. Unlike traditional token bridges that transfer assets (often leading to fragmentation or loss if a chain fails), ERC-6358 focuses on synchronizing token states across multiple existing public chains.

    This allows for the creation of a global token protocol (inheriting from ERC-20 or ERC-721) where token states are recorded synchronously across chains using smart contracts or similar mechanisms. Synchronization is intended to be performed by trustless off-chain synchronizers, ensuring that as long as the primary chain (e.g., Ethereum) is operational, user assets are not lost even if other chains in the network fail.