Diegorb1329/eth_magicians_forum huggingface dataset:
Title: ERC_5023__Shareable_Non_Fungible_Token
Category: ERCs

Author: jpitts
Date: 2023-03-02T19:54:18.803Z

As @yaruno gave a lightning EIP talk about this today, I am posting this to get feedback.


Ethereum Improvement Proposals


ERC-5023: Shareable Non-Fungible Token
An interface for creating value-holding tokens shareable by multiple owners

Author: yaruno
Date: 2023-03-03T00:15:23.284Z

Was great to see you all, and hope to see you also in the ETHDenver  Please leave feedback about the presentation and if our EIP and our project peaked your interested checkout atarca.eu . We’ll have ATARCA Seminar Week - ATARCA on next week online about how digital economies can be governed with anti-rival digital tokens such as sNFTs.

Author: stoicdev0
Date: 2023-03-03T21:38:29.810Z

Nice idea. I was recently thinking about NFTs which are songs and can be duplicated/shared under some conditions and I think this interface it’s the perfect minimal thing you’d need.
Any special reason why you are restricting transfer on the implementation?
Also, I think  you should increment the _currentIndex on the share function.  It’s always nice to have tests included for the reference implementations.
Edit: I just saw this is already final

Author: yaruno
Date: 2023-03-06T02:08:53.173Z

Short answer for restricting use of transfer method was that we wanted to create ‘soulbound’ shareable NFTs in our research project. I agree that tests would be great for refence implementations, though the official EIP/ERC document is a bit restrictive format to include tests.
But to add to that I really like @xinbenlv presentation at ETHDenver about the ERCRefs that should scratch this itch. I’ll try to get our projects reference implementation added to GitHub - ercref/ercref-contracts: ERC Reference Implementations .

Author: yaruno
Date: 2023-03-06T02:11:24.949Z

I’m also adding here a blog post that I wrote a couple of months ago where I reflected our EIP journey. It contains some self-reflection and some advice and links to resources for prospective EIP authors. Maybe it’ll be helpful for someone who stumbles upon this discussion.
https://medium.com/@jarno.marttila/eip-process-reflecting-our-eip-5023-journey-9fc4d53f8a0f

Author: yaruno
Date: 2023-04-30T08:24:36.643Z

In case someone gets interested on the deeper reasoning side of the utility and development of shareable NFTs. Here’s our research paper on development of sNFT called Digital Protocols as Accounting and
Incentivization Mechanisms in AntiRival Systems - Developing a Shareable Non-Fungible Token (sNFT) .
Title: New_ERC__Wallet_Call_Preparation_API
Category: ERCs

Author: lsr
Date: 2025-01-08T19:09:14.641Z

Abstract
This proposal defines complementary JSON-RPC methods to EIP-5792’s wallet_sendCalls. While wallet_sendCalls is used for an app to submit calls to be signed and submitted in a wallet’s interface, the methods in this proposal are for an application to request prepared calls (where “prepared” depends on the wallet implementation) to be signed and submitted by the application itself.
Motivation
With more recent developments in account abstraction and session keys, there is an increasing need for applications to be able to sign and submit operations without switching to a wallet interface (e.g. browser extension). This can be tricky because different account implementations might have different call data encoding, signature formats, etc. To remedy this, we need a way for apps to know how to submit an operation for any account implementation.
See more: Add ERC: Wallet Call Preparation API by lukasrosario · Pull Request #758 · ethereum/ERCs · GitHub

Author: SamWilsn
Date: 2025-01-29T21:18:46.965Z

I’m not familiar enough with user ops, but I just wanted to ask if these endpoints encourage blind signing? Can the wallet server display useful information, or does it just get the hash?
Title: ERC_Proposal__Multiplayer_Onchain_Game
Category: ERCs

Author: rickey
Date: 2023-11-28T10:53:55.357Z

This is a proposal on how to build a multiplayer on-chain game
https://github.com/ethereum/ERCs/pull/130
Title: ERC_7774__Cache_invalidation_in_ERC_5219_mode_Web3
Category: ERCs

Author: nand
Date: 2024-10-03T06:05:04.196Z

Abstract
In the context of the ERC-6860 web3:// standard, this ERC extends the ERC-6944 resolve mode: This standard add mechanisms to alleviate limitations to the use of standard RFC 9111 HTTP caching.
Motivation
Calls to an Ethereum RPC provider are costly: CPU-wise for local nodes, and money-wise for paid external RPC providers. Additionally, external RPC providers are rate-limited, and can quickly lead to the breaking of the loading of web3:// URLs.
Thus, it makes sense to use a caching mechanism to limit RPC calls when possible.
In the ERC-6944 resolve mode, smart contracts can already reply with standard RFC 9111 HTTP caching headers, such as Cache-Control, ETag.
Unfortunately, due to the impossibility of reading request HTTP headers, they cannot act on the If-None-Match and If-Modified-Since cache validation headers. Thus they are limited to the Cache-control: max-age=XX mechanism, and each cache validation request ends up with RPC calls regenerating the whole response.
This ERC defines a mechanism to bypass this limitation by having websites broadcast cache invalidations with smart contract events.
Besides, even if the smart contract could read request HTTP headers, using smart contract events is more efficient as it will eliminate a significant proportion of RPC calls.
ERC pull request


github.com/ethereum/ERCs








Add ERC: Cache invalidation in ERC-5219 mode Web3 URL


master ← nand2:patch-9



          opened 08:52AM - 23 Sep 24 UTC




            nand2
          



+182
-0






### Abstract

In the context of the [ERC-6860](./eip-6860.md) `web3://` standa…rd, this ERC extends the [ERC-6944](./eip-6944.md) resolve mode: This standard add mechanisms to alleviate limitations to the use of standard [RFC 9111](https://www.rfc-editor.org/rfc/rfc9111) HTTP caching.






I’m still refining a bit, and I’m open to suggestions / ideas 
Thanks!
Title: ERC_7866__Decentralised_Profile_Standard
Category: ERCs

Author: anistark
Date: 2025-01-21T22:32:46.303Z

The Decentralised Profile EIP proposes a decentralised, interoperable, and chain-agnostic standard for user profiles, built on top of Soulbound Tokens (SBTs). Each user profile is uniquely identified by a Decentralised Identifier (DID) in the format did:<chain>:<address> and linked to a unique Profile in the format username@networkslug.soul. It is inspired by current web3 ENS format and web2 email addresses that we use today.
The standard enables users to manage and customise their profiles across multiple chains while providing granular access control for metadata and avatars. Profiles support assigning specific avatars to decentralised applications (dApps) or using a default avatar, with visibility settings (public or private) for enhanced privacy. This allows the further control over one’s profile data and can be customised according to need.


github.com/ethereum/ERCs








Add ERC: Decentralised User Profiles


ethereum:master ← anistark:master



          opened 10:23PM - 21 Jan 25 UTC




            anistark
          



+346
-0






The CyberSoul Profile EIP proposes a decentralised, interoperable, and chain-agn…ostic standard for user profiles, built on top of Soulbound Tokens (SBTs). Each user profile is uniquely identified by a Decentralised Identifier (DID) in the format `did:<chain>:<address>` and linked to a unique CyberSoul Profile (CSP) in the format `username@networkslug.soul`. It is inspired by current web3 ENS format and web2 email addresses that we use today.

The standard enables users to manage and customise their profiles across multiple chains while providing granular access control for metadata and avatars. Profiles support assigning specific avatars to decentralised applications (dApps) or using a default avatar, with visibility settings (`public` or `private`) for enhanced privacy. This allows the further control over one's profile data and can be customised according to need.

Author: anistark
Date: 2025-02-26T21:12:58.300Z

Created a sample hardhat project to showcase the implementation: GitHub - anistark/cybersoul-hardhat
Title: ERC_7627__Secure_Messaging_Protocol
Category: ERCs

Author: bizliaoyuan
Date: 2024-02-18T18:59:51.887Z

https://github.com/ethereum/ERCs/pull/268
Abstract
This proposal implements the capability to securely exchange encrypted messages on-chain. Users can register their public keys and encryption algorithms by registration and subsequently send encrypted messages to other users using their addresses. The interface also includes enumerations for public key algorithms and a structure for user information to support various encryption algorithms and user information management.
Objectives

Provide a standardized interface for implementing messaging systems in smart contracts, including user registration and message sending functionalities.
Enhance flexibility and scalability for messaging systems by defining enumerations for public key algorithms and a structure for user information.
Define events for tracking message sending to enhance the observability and auditability of the contract.
Using a custom sessionId allows messages to be organized into a conversation.

Author: SamWilsn
Date: 2024-07-23T14:17:56.265Z

A few non-editorial related comments:

I raised a similar idea for an on-chain key registry in Pretty good privacy (PGP / GPG) on-chain keyserver. Happy to see someone else exploring the same space!
Using an enumeration for key types might limit the future expandability of the standard. What if a new algorithm comes along?
It might be a good idea to allow users to store one public key per algorithm, instead of just one per user, and further, you might want to allow users to store separate signing/encryption keys for validation vs. encryption.

Author: 0xTraub
Date: 2024-07-28T23:18:22.597Z

SamWilsn:

It might be a good idea to allow users to store one public key per algorithm, instead of just one per user,


I agree, which also means the function sendMessage() and event MessageSent will probably need to specify which algorithm the message was encrypted with (or at least the associated public key) so that the recipient can properly decrypt it. This may also make it easier for indexers and clients to process incoming messages if it’s a lot and to switch which one is used if vulnerabilities or other issues are found.

Author: bizliaoyuan
Date: 2024-08-29T08:24:13.867Z

As you mentioned, having a wallet store only one public key is not a good design. I modified the implementation to allow users to set multiple public keys and specify expiration times.
Title: ERC_7565_Proposal__Perpetual_contract_NFT_for_DeFi
Category: ERCs

Author: HSKim
Date: 2023-11-28T04:36:53.031Z

Discussion thread of ERCs PR
Reference Implementation and test: Repository
Draft: draft
For an academic article, please visit IEEE Xplore.
Abstract
This ERC proposes a mechanism where a person (referred to as the “Asset Owner”) can collateralize NFTs that represent locked deposits or assets, to borrow funds against them. These NFTs represent the right to claim the underlying assets, along with any accrued benefits, after a predefined maturity period
Motivaion
The rapidly evolving landscape of DeFi has introduced various mechanisms for asset locking, offering benefits like interest and voting rights. However, one of the significant challenges in this space is maintaining liquidity while these assets are locked. This ERC addresses this challenge by proposing a method to generate profit from locked assets using ERC-721 and ERC-4907.
In DeFi services, such as Uniswap v3, liquidity providers contribute assets to pools and receive NFTs representing their stake. These NFTs denote the rights to the assets and the associated benefits, but they also lock the assets in the pool, often causing liquidity challenges for the providers. The current practice requires providers to withdraw their assets for urgent liquidity needs, adversely affecting the pool’s liquidity and potentially increasing slippage during asset swaps.
Our proposal allows these NFTs, representing locked assets in liquidity pools, to be used as collateral. This approach enables liquidity providers to gain temporary liquidity without withdrawing their assets, maintaining the pool’s liquidity levels. Furthermore, it extends to a broader range of DeFi services, including lending and trading, where asset locking is prevalent. By allowing the collateralization of locked asset representations through NFTs, our approach aims to provide versatile liquidity solutions across DeFi services, benefitting a diverse user base within the ecosystem.
The concept of perpetual contract NFTs, which we introduce, exploits the idea of perpetual futures contracts in the cryptocurrency derivatives market. These NFTs represent the rights to the perpetual contract and its collateral, enabling them to be used effectively as collateral for DeFi composability. The perpetual contract NFT offers a new form of NFT that enhances the utility of locked assets, providing a significant advantage in DeFi applications by offering liquidity while retaining the benefits of asset locking.
Title: Minimal_Upgradeable_Proxies
Category: ERCs

Author: Vectorized
Date: 2024-08-23T06:13:23.077Z

Latest ERC PR


github.com/ethereum/ERCs








Add ERC: Minimal Upgradeable Proxies


master ← Vectorized:minimal-upgradeable-proxies



          opened 06:28AM - 23 Aug 24 UTC




            Vectorized
          



+514
-0






https://ethereum-magicians.org/t/minimal-upgradeable-proxies/20868






Adoption
https://dune.com/vectorized/erc-7760-proxy-counts
Related Work
An independent work has been done in:



ERC-7229: Minimal upgradable proxy contract EIPs


    Discussion thread for Add EIP: Minimal Upgradable Proxy Contract by xiaobaiskill · Pull Request #7229 · ethereum/EIPs · GitHub 
The Minimal Upgradable Proxy contract is a lightweight contract upgrade pattern designed to save gas costs while providing the ability to upgrade contracts. 
1 Standard Proxy
1.1 evm opcode
In the following EVM code, the PUSH0 instruction (EIP-3855) is used. As of 2023-06-23, the BSC chain does not support EIP-3855 yet. 
# store logic address to slot of proxy contract
P…
  


See: GitHub - xiaobaiskill/minimal-upgradable-proxy
This proposal is based off earlier work by JT Riley:

github.com




GitHub - jtriley2p/minimum-viable-proxy
Contribute to jtriley2p/minimum-viable-proxy development by creating an account on GitHub.






This scope of this proposal includes other variants of minimal ERC-1967 proxies that will benefit from standardization.
Source Code
https://github.com/Vectorized/solady/blob/main/src/utils/LibClone.sol
https://github.com/Vectorized/solady/blob/main/src/utils/ERC1967Factory.sol
Etherscan Automatic Verification
[ ] Transparent (20-byte factory address regular variant)
[ ] Transparent (14-byte factory address regular variant)
[ ] Transparent (20-byte factory address I-variant)
[ ] Transparent (14-byte factory address I-variant)
[x] UUPS (regular variant)
[ ] UUPS (I-variant) 
[x] Beacon Proxy (regular variant)
[ ] Beacon Proxy (I-variant)
Title: RFC__Fixing_Ethereum_UX_with_user_centric_asset_mo
Category: ERCs

Author: peersky
Date: 2024-02-22T18:24:55.929Z

Abstract
Taking a look back on 90s and beyond to pull a parallels between current state of Ethereum and bare-metal programming in Assembly and C back in a day, as well as today in embedded world.
The goal of this is to take the learnings and solve some problems we are seeing in Application layer security, such as highly complex vulnerability management procedures, difficulties to pre-arrange effective emergency response automations, and not least - very high level of stagnation caused by ERC standards track which just doest not allows easily to keep dApps and contracts with the progress we need there.
Referring to the fact that Ethereum Virtual Machine its still only a Machine, Im trying to reason that in traditional programming and computer architecture many security issues of what we see today on application-layer on Ethereum smart contracts are effectively solved and we can learn from there “how”.
My analogy is based on following illustration:

Think of an IoT enabled house. If there is an asset behind the door, which is controlled trough WiFi by chip in a computer, and we can declare, that the one who is able to open the doors is owning an asset. If we also understood section above that any peripheral is just an interface that can be accessed by calling right address on address bus, then we can map this equation out to the fact that from CPU standpoint, an asset ownership is equal to ability to set or unset a byte in some registry on some address of IO bus.

Based on this I’m making conclusions that
a) Assets are not interfaces
b) Secure architecture requires split between asset storage and asset driving interfaces
c) Current asset model is not user centric and is causing not just stagnation and poor ux, but also centralisation risks
d) The model of EVM seems correct for me, it can be competitive with what Move has to offer, but it must build a wrapper to abstract us away from “bare-evm-programming”.
e) ERC versioning is something we need to consider
Full article



peersky.xyz


Fixing Ethereum UX with user-centric asset model
How do we secure growth for ethereum for the next decades by designing secure, user centric architecture for assets and applications





RFC
This is request for comments. Im am looking for community feedback to incorporate this further.
Title: ERC_404___does_it_exists_
Category: ERCs

Author: robpolak
Date: 2024-02-12T14:23:02.922Z

There have been numerous NFT collections launching as hybrid ERC721 / ERC20 (NFTs that can trade also as ERC20’s), they are launching under the pseudonym ERC-404, however, I cannot find that spec (which is kinda funny “404”).  Curious if there are any existing specs which cover these hybrid tokens?
I found them super interesting, it provides liquidity outside of traditional NFT marketplaces and I could see these collections taking off.
REF: What Is ERC-404? The Experimental Standard Whose First Token Has Rocketed 12,000% in One Week
https://github.com/0xacme/ERC404?ref=bankless.ghost.io

Author: abcoathup
Date: 2024-02-13T01:22:24.120Z

There isn’t an ERC404.
The creators haven’t gone through the ERC process but appeared to use the ERC prefix for marketing purposes.
EIP/RIP/ERC numbering changed to sequential from 7500 and is no longer the PR number.  Numbers are issued by EIP/RIP/ERC editors/associates.
There was a recent draft ERC with Hybrid functionality:  ERC7616: Hybrid Fungible Token
https://github.com/ethereum/ERCs/pull/244/files
Title: ERC_7720__Deferred_Token_Transfer
Category: ERCs

Author: bizliaoyuan
Date: 2024-06-08T19:07:15.595Z

Abstract
The standard enables users to deposit ERC-20 tokens that can be withdrawn by a specified beneficiary at a future timestamp. Each deposit is assigned a unique ID and includes details such as the beneficiary, token type, amount, timestamp, and withdrawal status.
Motivation
Sometimes, we need deferred payments in various scenarios, such as vesting schedules, escrow services, or timed rewards. By providing a secure and reliable mechanism for time-locked token transfers, this contract ensures that tokens are transferred only after a specified timestamp is reached. This facilitates structured and delayed payments, adding an extra layer of security and predictability to token transfers. This mechanism is particularly useful for situations where payments need to be conditional on the passage of time.
https://github.com/ethereum/ERCs/pull/465
Title: ERC_7654__Request_Method_Types
Category: ERCs

Author: rickey
Date: 2024-03-13T02:40:16.800Z

Use a set of request methods to indicate the type of action to take on the contract.
https://github.com/ethereum/ERCs/pull/315
Title: ERC_7829__Data_Asset_NFT
Category: ERCs

Author: roc
Date: 2024-11-29T09:07:03.518Z

The ERC outlines the minimally required interfaces and behavior for Data Asset NFT. It proposes a storage proof mechanism to ensure Data Asset NFT’s integrity, and propose a new role, Reader, to Amplify Data Asset’s value.
PR:

github.com/ethereum/ERCs








Add ERC: Data Asset NFT


master ← memoio:data-asset-nft



          opened 09:51AM - 29 Nov 24 UTC




            rockiecn
          



+136
-0






The ERC outlines the minimally required interfaces and behavior for Data Asset N…FT. It proposes a storage proof mechanism to ensure Data Asset NFT's integrity, and propose a new role, Reader, to Amplify Data Asset's value.

Author: lei335
Date: 2024-11-29T09:14:11.667Z

Data asset NFT… I like this idea! It makes nft more real.
Title: Discussion_on_Pay_with_USSD
Category: ERCs

Author: MASDXI
Date: 2025-01-02T22:53:20.562Z

Discussion topic for Pay with USSD


github.com/Kiwari-Labs/pay-with-ussd


ERC/erc-xxxx.md

main

---
eip: XXXX
title: Pay with USSD
description: Offline payment transactions via USSD.
author: sirawt (@MASDXI), Paramet Kongjaroen (@parametprame), et al.
discussions-to: https://ethereum-magicians.org/t/eip-xxxx/
status: Draft
type: Standards Track
category: ERC
created: yyyy-mm-dd
---

<!-- 
requires: 681
-->

<!-- what's about ERC-4337 and ERC-7702 -->

## Motivation
In scenarios with limited or unreliable internet access, traditional digital payment methods may not be feasible. Unstructured Supplementary Service Data (USSD) provides a vital solution by enabling offline transactions like payments, transfers, and balance inquiries without requiring internet connectivity. Its simplicity and broad compatibility with basic mobile devices and Electronic Draft Capture (EDC) device make USSD an essential tool for mobile payments, particularly in underserved areas, supporting financial inclusion and broader access to digital financial services.




  This file has been truncated. show original





Update Log

2024-01-03: Initiate idea
2025-07-05: Update Historical link

External Reviews

None as of 2024-01-03

Outstanding Issue

None as of 2024-01-03

Summary
Unstructured Supplementary Service Data (USSD) enables offline transactions, supporting payments and transfers without internet connectivity.
Historical link relate to this

kotanipay
crypto-ussd
eazepay
yarapay
s-pesa
Title: ERC_7902__Wallet_Capabilities_for_Account_Abstract
Category: ERCs

Author: alex-forshtat-tbk
Date: 2025-03-11T19:14:12.591Z

Discussion topic for ERC-7902: Wallet Capabilities for Account Abstraction
The capabilities are defined for ERC-5792 defined wallet_sendCalls API.
Draft PR of the proposal is here:

github.com/ethereum/ERCs








Add ERC: New Account Abstraction capabilities for ERC-5792


ethereum:master ← eth-infinitism:AA-429-new-aa-capabilities-erc



          opened 03:00PM - 04 Mar 25 UTC




            forshtat
          



+200
-0






When opening a pull request to submit a new EIP, please use the suggested templa…te: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.
Title: ERC_7769__JSON_RPC_for_ERC_4337_Account_Abstractio
Category: ERCs

Author: dror
Date: 2024-09-18T14:42:44.211Z

This ERC describes the JSON-RPC calls used to communicate with ERC-4337 bundler.
It was previously included in ERC-4337 itself, but was extracted into a separate document.
This specification is currently identical to the one previously dedfined in ERC-4337 and does not require any modifications existing bundlers or ERC-4337 deployed contracts.
This is the PR for this new ERC: ERC-4337 extension: New JSON-RPC APIs by forshtat · Pull Request #628 · ethereum/ERCs · GitHub
Title: What_standards_are_out_there_for_issuing_payments_
Category: ERCs

Author: jpitts
Date: 2023-02-23T18:26:32.098Z

Here is a list of some I found, post here if you know of any others.
ERC-2981
Overview: https://www.nftstandards.wtf/Standards/EIP2981+Royalty+Standard
https://eips.ethereum.org/EIPS/eip-2981
ERC-5173

Ethereum Improvement Proposals


ERC-5173: NFT Future Rewards (nFR)
A multigenerational reward mechanism that rewards‌ all ‌owners of non-fungible tokens (NFT).





ERC-1726
https://github.com/ethereum/EIPs/issues/1726

Related articles and discussions




ERC-1155 and ERC-2981 Royalties - where are the standards heading to? ERCs


    Hi, 
I am exploring ERC 721 and 1155 with possible EIP 2981 royalties implementation. 
I would like to have the opinion of more experienced developers to better understand what can be done and where the standards are heading to. 
There are some instances in which a digital assets, let’s say a song from a music album, has the necessity of its unique ID in order to be distinguished from the other songs on the same album. 
At the same time the author does not want the asset to be sold as an individ…
  

https://medium.com/coinmonks/erc-20-tokens-as-dividends-paying-shares-solidity-b95f6c6c52ce
Title: ERC_7649__Bonding_Curve_Embedded_Liquidity_for_ERC
Category: ERCs

Author: vgorin
Date: 2024-03-06T12:51:21.140Z

Bonding Curve-Embedded Liquidity for ERC-721 Non-Fungible Tokens (NFTs)
Standard for embedding liquidity into ERC-721 Non-Fungible Tokens (NFTs) without modifications to ERC-721.
https://github.com/ethereum/ERCs/pull/300

Author: pyrobit
Date: 2024-03-11T04:40:54.125Z

Perhaps Bonding Curve-Embedded Liquidity for refungible NFTs?
Title: ERC_7661_XMF_NFTs__Extended_Multiphase_Fractional_
Category: ERCs

Author: JEflyer
Date: 2024-03-25T02:38:09.567Z

This is the official channel for discussion of the ERC9988 Standard.
Implementation - GitHub - JEflyer/ERC9988: Solving the lot problem for supply chains with Extended Multiphase Fractional NFTs
Title: ERC_7603__Multi_Context_Dependent_Multi_Asset_Toke
Category: ERCs

Author: haruu8
Date: 2024-01-25T02:37:09.845Z

PRs
An ERC-1155 compatible multi-context dependent multi-asset token, referenced from ERC-5773.
I’ve very inspired by ERC-5773 about concept, and implementation, and I wrote the proposal based on it.
Multi-asset compatibility with ERC-1155 is important to enhance interoperability as well as ERC-5773 seeks to develop cross-metaverse and cross-engine standards in ERC721.
Let me know what you think, thank you for your support.

Author: Mani-T
Date: 2024-01-26T02:19:28.359Z

This has the potential to significantly enrich the token landscape on Ethereum. Good job.

Author: stoicdev0
Date: 2024-01-26T14:04:46.005Z

You are fully copying as far as I can see the ERC-5773 implementation without any mention to it on your proposal which does not seem right.
On top of that, since it seems to be exactly the same, have you tried using ERC-5773 on top of an ERC-1155? It might work just as it is with no need for an additional ERC.

Author: haruu8
Date: 2024-01-27T05:41:27.887Z

I apologize for my rudeness. I was indeed affected by ERC-5773 and submitted the EIP with reference to it. Not mentioning ERC-5773 is disrespectful in retrospect, so I added a sentence I’ve inspired in the message in the body of the thread.
I think it’s rewarding to standardize multi-context dependent multi-asset tokens compatible with ERC-1155, not ERC-721. Multi-Context Dependent Multi-Asset Tokens are the crucial standard for implementing cross-metaverse and cross-engine and enhancing interoperability in the Ethereum network.
I’d just develop a combination of ERC1155 and part of a multi-asset feature in ERC5773 if I just developed a smart contract for myself. However, to make the implementation of multi-metaverse and multi-engine, I believe I should listen to the voices of various dApp developers through discussion for standardization and discuss and implement standards that many developers find easy to use.
That’s why I posed new standards of multi-context dependent multi-asset tokens as an ERC-1155 extension.

Author: stoicdev0
Date: 2024-01-27T17:06:30.605Z

I did not see any difference in what you propose. Can you let me know what is different?
Did you try using it as it is for a 1155?

Author: haruu8
Date: 2024-01-29T12:22:02.396Z

Currently, there are no differences. Also, I have not yet attempted to do so for actual use. I believe that ERC5773 should be used as a reference for multimedia data management, but we would like to discuss with developers who use ERC1155 on a regular basis and make changes to this proposal if necessary. I would like to discuss this with various developers and proceed with standardization based on ERC5773.

Author: SamWilsn
Date: 2024-05-15T20:30:27.639Z

Have you looked at EIP-4955 by any chance? Vaguely similar idea.
Title: ERC_7764__Buyer_Seller_Negotiable_Pricing
Category: ERCs

Author: S7iter
Date: 2024-09-06T05:35:35.055Z

PR:

github.com/ethereum/ERCs








Add ERC: Buyer-Seller Negotiable Pricing


master ← admi-n:master



          opened 08:36AM - 05 Sep 24 UTC




            admi-n
          



+136
-0






This proposal introduces a new smart contract mechanism that allows buyers and s…ellers to freely negotiate and determine transaction prices on the Ethereum network. A new trading mode is added, where goods can be negotiated rather than only priced. This mechanism allows the seller to set an initial price, and the buyer can propose a new price through negotiation with the seller. Ultimately, both parties can reach an agreement and complete the transaction.

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.






This proposal introduces a new smart contract mechanism that allows buyers and sellers to freely negotiate and determine transaction prices on the Ethereum network. A new trading mode is added, where goods can be negotiated rather than only priced. This mechanism allows the seller to set an initial price, and the buyer can propose a new price through negotiation with the seller. Ultimately, both parties can reach an agreement and complete the transaction.
Title: ERC_7653__Named_NFTs__ERC_721_extension_
Category: ERCs

Author: xinbenlv
Date: 2024-02-07T19:00:07.753Z

Summary
ERC-721 and ERC-1155 uses uint256 tokenId, this standard extend them with string name.
Motivation
For Marketplaces, Explorers, Wallets, DeFi and dApps to better display and operate NFTs that comes with a name.
Specification
interface IERCNamedNFT {
  function safeTransferFromByName(string memory _tokenName, address from, address to, bytes calldata);
  function approveByName(address _approved, string memory _tokenName) external payable;
  function idToName(uint256 _tokenId) external view returns (string);
  function nameToId(string memory _tokenName) external returns (uint256);
  function getApprovedByName(string memory _tokenName) external view returns (address);
}

Security Considerations

Contract developer shall declare normalization mechanism

Author: xinbenlv
Date: 2024-02-22T18:19:15.466Z

Moving forward with draft
Title: ERC_7582__Modular_Accounts_with_Delegated_Validati
Category: ERCs

Author: nerderlyne
Date: 2023-12-25T12:33:07.917Z

A proposal for efficiently adding (nonce-encoded) plugin functionality to ERC4337 (modular accounts) without requiring any new interface by leveraging the existing Entry Point accounting structure:


github.com/ethereum/ERCs








Add ERC: Modular Accounts with Delegated Validation


master ← nerderlyne:master



          opened 12:30PM - 25 Dec 23 UTC




            nerderlyne
          



+218
-0






Discussion Link -> 
https://ethereum-magicians.org/t/erc-7582-modular-accounts-…with-delegated-validation/17640






base-flow1185×1196 30.5 KB

Author: nerderlyne
Date: 2024-06-29T09:02:57.603Z

Just published a package convenience for working with ERC7582 nonce extraction (the validator encoded in nonce is what receives the validateUserOp and validates return): GitHub - nerderlyne/eip-7582-utils: helpers
A reference ERC7582 account: https://eips.ethereum.org/assets/eip-7582/MADVAccount.sol
Can install directly via npm install eip-7582-utils viem
ERC7582 has now progressed to draft stage. Please provide any comments or requests before we finalize. Thanks!
Title: Subdomain_for_ERCs_website_
Category: ERCs

Author: PaulRBerg
Date: 2024-05-14T14:16:51.572Z

ERCs have recently been extracted out of the EIPs repository, and moved to a separate repo:
https://github.com/ethereum/ERCs
But from what I can tell, ERCs are still hosted on the same website:


Ethereum Improvement Proposals


Home | Ethereum Improvement Proposals
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, such as core protocol specifications.





Are there any plans to create an ercs.ethereum.org subdomain?

Author: abcoathup
Date: 2024-05-16T04:40:40.676Z

ERC subdomain just has ERCs.  Don’t know if there are further plans.

Ethereum Improvement Proposals


ERC | Ethereum Improvement Proposals
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, such as core protocol specifications.
Title: ERC_7725__Exponential_Curves
Category: ERCs

Author: ownerlessinc
Date: 2024-05-30T17:20:01.236Z

Hello 
I’ve been looking into on-chain exponential curves for a while to assist in a reputation project that aims to decrease the soul-bounded governance power as time passes. Similar projects such as ENS have implemented this to decay the premium on expired names.
ERC-7725
But every single project that strives to use exponential curves ends up using different formulas. Thus I’ve found myself developing a standard that everyone can use to easily manage exponential curves on-chain.
EXPCurves on GitHub
This smart contract implements an advanced exponential curve formula designed to handle various time-based events such as token vesting, game mechanics, unlock schedules, and other timestamp-dependent actions. The core functionality is driven by an exponential curve formula that allows for smooth, nonlinear transitions over time, providing a more sophisticated and flexible approach compared to linear models.
function expcurve(
    uint32 currentTimeframe,
    uint32 initialTimeframe,
    uint32 finalTimeframe,
    int16 curvature,
    bool ascending
  ) public pure virtual returns (int256);

The smart contract provides a function called expcurve that calculates the curve’s decay value at a given timestamp based on the initial timestamp, final timestamp, curvature, and curve direction (ascending or descending). The function returns the curve value as a percentage (0-100) in the form of a fixed-point number with 18 decimal places.
We can create up to 4 types of curves or even keep a straight line. You can play around with the curvature (k) to determine the steepness of the curve.
You can also fork this spreadsheet and play with the formula and the resulting charts.
I’m currently writing the EIP but I would like to know if this contribution was previously developed to avoid duplicated work, otherwise, let me hear what you think and what I should’ve done differently!
ascending_with_positive_curvature600×371 11.1 KB
descending_with_negative_curvature600×371 11 KB
Title: ERC_7580__Inter_dapp_tracking_inferface
Category: ERCs

Author: wartstone
Date: 2023-12-26T08:53:21.826Z

Discussion for  Add ERC: Inter dapp tracking inferface by wartstone · Pull Request #165 · ethereum/ERCs · GitHub .
This proposal aims to establish an inter-dapp tracking standard inferface for dapp interactions and support for more complicated business logics.

Author: wartstone
Date: 2023-12-26T09:05:54.443Z

Imaging we have two roles here: promotion/ads business role and projects role who adopted the promotion service. And project contracts implemented the interface listed in the erc.
Currently the routine would go something like this:

projects get a seed id (hash) from promotion side
before the target promotion action starts, project contracts called the interface ‘onTrackStart(id, contract_address, function_hash)’
after the target promotion action ends, project contracts called the inferface ‘onTrackEnd(id, contract_address, function_hash)’
promotion contract collect the project action info and distribute the rewards back to projects

any interesting idea are welcome

Author: wartstone
Date: 2024-01-18T09:57:38.028Z

We’re ready to publish an example usage contract next if there’s no problems. could be exciting
Title: ERC_7806__Minimal_intent_centric_EOA_smart_account
Category: ERCs

Author: hellohanchen
Date: 2024-11-03T08:15:46.414Z

I am drafting a new ERC that defines interfaces for intent-centric EOA smart account under EIP-7702.
Abstract
This proposal defines interfaces to build intent-centric smart accounts under EIP-7702, allowing EOA account owners to define their intents of a transaction and let relayers (solvers) to validate and execute the requests.
For detailed spec and rationales, please refer to the ERC pull request:

github.com/ethereum/ERCs








Add ERC: Minimal intent-centric EOA smart account


master ← hellohanchen:erc-intent-7702



          opened 07:19PM - 03 Nov 24 UTC




            hellohanchen
          



+456
-0






When opening a pull request to submit a new EIP, please use the suggested templa…te: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.






Backwards Compatibility
This EIP shares the same backwards compatibility issue as EIP-7702. This EIP is not compatible with ERC-7521.
Security Considerations
This is mainly controlled by the standard and account implementation to make sure the account is safe. Solver needs to responsible for its own security when executing intents.
More discussion needed.

Author: abcoathup
Date: 2024-11-04T02:14:01.854Z

Suggest just posting a link to the ERC PR and perhaps the abstract rather than copy/pasting.

Author: hellohanchen
Date: 2024-11-04T07:32:36.773Z

Thanks for the advice, I’ve edited the post to include abstract, motivation and some discussion topics only.

Author: hellohanchen
Date: 2025-02-13T04:30:40.504Z

The PR is reworked and updated with an example.

Author: hellohanchen
Date: 2025-04-29T06:38:34.249Z

The ERC is officially in DRAFT state!


Ethereum Improvement Proposals


ERC-7806: Minimal intent-centric EOA smart account
Extensible intent-centric EOA smart account interface design to support batch execution, gas sponsorship and more other functionalities.





Please review the spec if you are interested. We are open to any feature requests, feedbacks, ideas.
Title: ERC_7715__Grant_Permissions_from_Wallets
Category: ERCs

Author: pedrouid
Date: 2024-05-24T15:57:23.431Z

Adds JSON-RPC method for requesting permissions from a wallet
https://github.com/ethereum/ERCs/pull/436/

Author: xinbenlv
Date: 2024-06-12T12:59:38.865Z

In the context of this ERC, How does wallet identify a DApp and ensure it was still the same DApp? It seems to me there are some implied assumptions that i might not know and probably better spell out.
If the assumption is that DApp maintains a secure connection with wallet, that shall be spelled out and investigated I think. For example, a hardware wallet could be connected to an offline DApp that only signs TX signature and be distributed in less common ways

Author: jayk
Date: 2025-01-21T16:28:49.358Z

Is there still active work on this proposal? One question I have: this standard defines an expiry for the session end time, but I’m thinking providing an additional constraint on the start time would be useful. Similar to how we have validAfter and validUntil in ERC-4337. Thoughts?

Author: lukaisailovic
Date: 2025-01-22T12:54:44.706Z

@jayk Its being actively worked on. Do you think validAfter should be at the top level request? IMO Its more fitting in the specific permission like this:
 permissions: [
          {
            type: 'native-token-transfer',
            data: {
                allowance: '0x1DCD6500',
                validAfter: 1737550474
            }
          }
        ],

Author: jayk
Date: 2025-01-22T21:37:09.116Z

Thanks for the response! Curious - what would be the use case for being able to specify different validAfters for different permissions? Would we also want to specify different validUntils for each as well then?
In the context of session keys, it seems simpler to think about a valid range at the key level, during which all of the permissions it has been granted is valid. Put another way, this would be equivalent to having time range be an additional permission which must be checked for each action. This is how Alchemy and ZeroDev do it today, with TimeRangeModule and TimestampPolicy, respectively.

Author: lukaisailovic
Date: 2025-01-26T09:57:53.293Z

If you check out the 7715 spec, currently we have RateLimitPermission for example in the spec. I think ZeroDev and Alchemy would map their permissions to a top level ones.
validUntil is the expiry and validAfter can be modeled as a separate permission.

Author: glitch-txs
Date: 2025-02-19T06:41:40.685Z

Given the fact that crypto assets are usually very volatile, would there be a way to update the permissions on the go?
Title: ERC_7662__AI_Agent_NFTs
Category: ERCs

Author: marleymarl
Date: 2024-03-26T22:40:40.991Z

Abstract
This proposal introduces a standard for AI agent NFTs. In order for AI Agents to be created and traded as NFTs it doesn’t make sense to put the prompts in the token metadata, therefore it requires a standard custom struct. It also needs doesn’t make sense to store the prompts directly onchain as they can be quite large, therefore this standard proposes they be stored as decentralized storage URLs. This standard also proposes two options on how this data should be made private to the owner of the NFT, with the favored implementation option being encrypting the data using custom contract parameters for decryption that decrypt only to the owner of the NFT.
Motivation
The creation and trading of AI Agent NFTs are a natural fit and offer the potential for an entirely new onchain market. This requires some custom data to be embedded in the NFT through a custom struct and this needs to be standardized so that any marketplace or AI Agent management product, among others, know how to create and parse AI Agent NFTs.
This is discussion for the PR: Add ERC: AI Agent NFTs by marleymarl · Pull Request #348 · ethereum/ERCs · GitHub
Title: ERC_7624__Dynamic_Identity_Binding_Soulbound_Token
Category: ERCs

Author: Auph
Date: 2024-02-14T16:10:56.753Z

Discussion for Add ERC: Dynamic Identity Binding Soulbound Tokens
The proposal outlines the introduces a mechanism for dynamic identity binding to enhance the security and continuity of users’ identities in the context of Soulbound tokens, and addresses the current limitation where Soulbound tokens are static and irrevocable, making it challenging for users to recover their identity in case of wallet compromise. The proposed solution allows users to re-identify themselves with a new wallet address while preserving the integrity of their Soulbound identity.

Author: nicholasnokia
Date: 2024-02-15T13:09:32.879Z

Yes, sounds good. use chatgpt for more words
Title: New_ERC__Wallet_Call_Simulation_API
Category: ERCs

Author: jxom
Date: 2025-02-11T01:41:32.832Z

This ERC proposes a new JSON-RPC method for simulating the execution of calls on a Wallet. The method is designed to be used by Wallets to simulate the execution of calls before sending them to the network, allowing for gas estimation, log extraction, and call validation.
Applications are reliant on JSON-RPC communication to Wallets in order to execute actions (ie. wallet_sendCalls and/or eth_sendTransaction). A seemingly core functionality for “offline” Applications (Servers, etc) is the ability to simulate if an action will succeed or fail and/or estimate the total fee and/or calculate balance changes, prior to signing and broadcasting to the network.


github.com/ethereum/ERCs








Add ERC: Wallet Call Simulation API


ethereum:master ← jxom:jxom/simulate-calls



          opened 12:36AM - 11 Feb 25 UTC




            jxom
          



+223
-0
Title: ERC_7204__Contract_wallet_management_token
Category: ERCs

Author: wenzhenxiang
Date: 2023-06-20T18:56:47.566Z

A proposal to manage fungible tokens by the user’s smart contract wallet, which provides a new way to manage assets, utilizes the programmability of the smart contract wallet, and also provides more playability.
EOA wallet has no state and code storage, and the smart contract wallet is different.
AA is a direction of the smart contract wallet, which works around abstract accounts.
The smart contract wallet allows the user’s own account to have state and code, bringing programmability to the wallet. We think there are more directions to expand. For example, token asset management, functional expansion of token transactions, etc.
The proposal aims to achieve the following goals:

Assets are allocated and managed by the wallet itself, such as approve and allowance, which are configured by the user’s contract wallet, rather than controlled by the token asset contract, to avoid some existing ERC-20 contract risks.
Add the simpletokenTransfer function, the transaction initiated by the non-smart wallet itself or  will verify the allowance amount
Add simpletokenApprove, simpletokenAllowance, simpletokenApproveForAll, simpletokenIsApproveForAll functions. The user wallet itself supports approve and provides approve
for single token assets and all token assets( simpletoken is forward compatible with ERC-20).
user wallet can choose batch approve and batch transfer.
Users can choose to add hook function before and after their simpletokenTransfer to increase the user’s more playability
The user can choose to implement the simpletokenReceive function