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

Author: MilkyTaste
Date: 2024-10-21T22:41:38.992Z

github.com/ethereum/ERCs








Add ERC: Wallet Call Token Capabilities


master ← ScreamingHawk:tx-intents



          opened 10:36PM - 21 Oct 24 UTC




            ScreamingHawk
          



+596
-0






This ERC introduces a mechanism for dapps to provide prerequisites for transacti…ons to smart contract wallets. Wallets can use these prerequisites to make more informed decisions about transaction construction.






Abstract
This ERC addresses the lack of communication channels between the dapp and smart contract wallets. Wallets are tasked with sending transactions on behalf of the user, but dapps craft these transactions. The challenge is that dapps don’t have a way of communicating the prerequisites for these transactions, so wallets can’t fulfill them.
To solve this issue, an additional optional field is included in the transaction request. This field is a list of “requirements” that the wallet has to fulfill for the requested transactions to be considered “ready.”
Wallets can use this list of requirements, alongside their knowledge about the addresses of the user, to decide how to act next. Depending on the availability of funds and the list of requirements, the options could be: send the transaction right away, send the transaction with a prefix that fulfills the requirements, or ask the user to select a path to fulfill the requirements.
Wallets would be tasked with finding all possible paths to fulfill these requirements, while dapps SHOULD NOT attempt to check the requirements themselves, letting the wallet handle scenarios like “low balance” or “low allowance.”

For more information please see the ERC.

Author: MilkyTaste
Date: 2024-11-24T22:23:15.560Z

This ERC has been updated to leverage ERC-5792’s Wallet Call API and now provides additional “capabilities” instead of a new RPC method.

Author: dror
Date: 2025-04-08T18:22:55.615Z

One thing I would add to this ERC is to let the wallet perform the actual approve.
That is, the wallet should add a token.appove(target.amount) at the beginning of the batch, make the calls the application needs and at the end add token.approve(target,0)
With this pattern, the user is no longer “plagued” with dangling approvals.
Title: ERC_7765__Privileged_Non_Fungible_Tokens_Tied_To_R
Category: ERCs

Author: frankmint2024
Date: 2024-09-10T09:16:58.628Z

Here is my PR:

github.com/ethereum/ERCs








Add ERC: Privileged Non-Fungible Tokens Tied To RWA


master ← Mint-Blockchain:master



          opened 03:04AM - 09 Sep 24 UTC




            frankmint2024
          



+338
-0






This EIP defines an interface to carry a real world asset with some privileges t…hat can be exercised by the holder of the corresponding NFT. The EIP standardizes the interface for non-fungible tokens representing real world assets with privileges to be exercised, such as products sold onchain which can be redeemed in the real world.






This EIP defines an interface to carry a real world asset with some privileges that can be exercised by the holder of the corresponding NFT. The EIP standardizes the interface for non-fungible tokens representing real world assets with privileges to be exercised, such as products sold onchain which can be redeemed in the real world.

Author: SEAlien8859
Date: 2024-09-18T10:48:25.256Z

em, glad to see this post, I have seen several rwa businesses recently.

Author: codervake
Date: 2024-09-19T01:00:15.252Z

it there some practical examples to describe the usage scenarios?

Author: victor9248
Date: 2024-09-25T02:06:14.472Z

The new RWA protocol looks good
Title: Add_ERC__On_chain_Autonomous_AI_Agent_Non_fungible
Category: ERCs

Author: 4ever9
Date: 2024-01-18T03:15:50.620Z

Discussion for Add ERC: On-chain Autonomous AI Agent Non-fungible Token by 4ever9 · Pull Request #210 · ethereum/ERCs · GitHub
Title: ERC_7638__Optimized_Calls_Encoding
Category: ERCs

Author: JXRow
Date: 2024-02-27T09:43:42.918Z

https://github.com/ethereum/ERCs/pull/282
This ERC can use like ERC4377, but much simple, and cost less gas
Title: ERC_7700__Cross_chain_Storage_Router_Protocol
Category: ERCs

Author: sshmatrix
Date: 2024-04-30T01:49:40.826Z

The following proposal is a superior version of EIP-5559: Cross-Chain Write Deferral Protocol, aka CCIP-Write, replacing Ethereum L1 storage with L2 chains and cryptographically secure databases with an aim to cut gas costs and further privacy while retaining the secure aspects of on-chain storage. Methods in this document specifically target security and cost-effectiveness of write deferrals in context of databases. The cross-chain data written with these methods can be retrieved by generic EIP-3668-compliant contracts completing the cross-chain data life cycle.
ERC Link: ERC-7700
PR Link: Add ERC: Cross-chain Storage Router Protocol by sshmatrix · Pull Request #404 · ethereum/ERCs · GitHub
Note: This proposal is a standalone ERC, amended from what was originally intended as a PR to EIP-5559
Title: EIP_idea__Context_Dependent_Multi_Asset_and_Multi_
Category: ERCs

Author: haruu8
Date: 2023-12-19T09:48:03.214Z

We are developing a project using ERC1155 and would like to implement the ERC1155 standard with the multimedia output and FT evolution features of ERC5773.
Although ERC5773 is based on ERC721, we believe that multimedia output and evolution features in fungible tokens like ERC1155 are equally in demand and can be applied to various cases.
We want to get valuable feedback from the community.
Abstract
Inspired by the multimedia output and evolution capabilities of NFTs found in ERC5773, we aim to extend the ERC1155 standard.
Motivation
Our motivation aligns closely with that of ERC5773.
Request for Feedback
Do you think this proposal has the potential to be accepted as an EIP and reach Final status? Also, are there any important considerations for submitting an EIP that might not be outlined in the guidelines?

Author: abcoathup
Date: 2023-12-19T23:35:20.025Z

haruu8:

Do you think this proposal has the potential to be accepted as an EIP and reach Final status? Also, are there any important considerations for submitting an EIP that might not be outlined in the guidelines?


ERCs aren’t for product promotion.  Find some other projects doing similar where standardizing would make sense.
Check out the following guide:
https://medium.com/ethereum-magicians/comprehensive-guide-on-writing-and-submitting-an-eip-9474163771f0

Author: haruu8
Date: 2023-12-20T05:11:17.381Z

Thank you for your comment.
I understood ERCs aren’t for product promotion, but I didn’t recognize that finding other projects doing similar things is important to proceed on Final.
I’ll submit the proposal for this idea after researching some projects.

Author: abcoathup
Date: 2023-12-21T00:32:00.983Z

haruu8:

I understood ERCs aren’t for product promotion, but I didn’t recognize that finding other projects doing similar things is important to proceed on Final.


Having multiple independent implementations isn’t a requirement, it is just recommended.  An ERC will be far more useful & stronger if multiple projects need it & work out the issues for using it.




Discussion of Guideline for advancing EIP status: A Straw-man Proposal Process Improvement


    Currently in EIP-1, except of Core EIPs there is no much mentioning criteria for allowing publication of a draft EIP or advancing an EIP’s status to final. This raises concern from some EIP contributors about quality, worthiness and whether there are sufficient interest or whether sufficient level of consensus has been reached. 
In the interest of starting a discussion, I am creating this (probably dumb and full of flaws) proposal for criteria for advancing statuses of an EIP. Please see it as a…
Title: ERC_7758__Transfer_With_Authorization
Category: ERCs

Author: dongri
Date: 2024-08-22T11:51:59.421Z

github.com/ethereum/ERCs








Add ERC: Transfer With Authorization


master ← dongri:erc-transfer-with-authorization



          opened 01:18AM - 21 Aug 24 UTC




            dongri
          



+530
-0






Ref: https://github.com/ethereum/ERCs/pull/504

Author: radek
Date: 2024-08-25T07:09:58.962Z

Hi, ERC-2612 is mentioned and compared.
Could you please elaborate the improvement over ERC-3009?

Author: dongri
Date: 2024-08-25T07:30:57.562Z

github.com/ethereum/ERCs








Update ERC-3009: Move to Draft


master ← dongri:fix-erc-3009-sample-code



          opened 08:37AM - 22 Jun 24 UTC




            dongri
          



+3
-3






There is an error in signature verification with the current sample code.
```
…EIP3009: invalid signature
```

It is necessary to change the order of `bytes32(chainId)` and `address(this)` to comply with `keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)")`.







I think you can understand the background by looking at the differences and comments in this PR.

Author: radek
Date: 2024-09-03T09:26:30.249Z

ah, so is is the correction of the example code of 3009, i.e. no change in the standard as such.
@abcoathup why this has a new ERC number?

Author: abcoathup
Date: 2024-09-04T02:48:53.729Z

radek:

@abcoathup why this has a new ERC number?


The change needed the authors approval, otherwise a new EIP (with a new number) needed to be created (which is what happened).  As per @SamWilsn:

github.com/ethereum/ERCs








Update ERC-3009: Move to Draft


master ← dongri:fix-erc-3009-sample-code



          opened 08:37AM - 22 Jun 24 UTC




            dongri
          



+3
-3






There is an error in signature verification with the current sample code.
```
…EIP3009: invalid signature
```

It is necessary to change the order of `bytes32(chainId)` and `address(this)` to comply with `keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)")`.

Author: radek
Date: 2024-09-04T09:52:35.810Z

Thanks for clarification. IMHO the outcome is the duplicity of the standard, where 3009 is already used (at least USDC).

Author: SamWilsn
Date: 2024-09-10T17:22:00.403Z

Duplicating it isn’t really a huge problem. If a 3009-like interface is already used in production, the relevant standard should be finalized. Doesn’t really matter if the number is 3009 or 7758.
When you feel it is ready, please open pull requests to move 7758 through Review, Last Call, and Final.

Author: dongri
Date: 2024-09-10T20:34:16.435Z

github.com/ethereum/ERCs








Update ERC-7758: Move to Review


master ← dongri:erc-7758-review



          opened 08:33PM - 10 Sep 24 UTC




            dongri
          



+1
-1






https://ethereum-magicians.org/t/erc-7758-transfer-with-authorization/20859/7
C…hange status to review







open pull request
Title: ERC_7652__EIP_721_Guarantee_Extension
Category: ERCs

Author: bl2
Date: 2024-03-20T18:06:57.267Z

Hi Magicians，We would like to propose an extension for EIP-721.
Abstract
This specification defines functions outlining a guarantor role for instance of EIP-721. The guarantee interface implements the user-set valuation and guarantee share for a given NFT (token ID), as well as the guarantee rights enjoyed and obligations assumed during subsequent transactions. An implementation enables the user to read or set the current guarantee value for a given NFT (token ID), and also realizes the distribution of guarantee interest and the performance of guarantee obligations. It sends the standardized events when the status changes. This proposal relies on and extends the existing EIP-721.
Motivation
NFT (token ID) commonly face the issue of insufficient market liquidity: the main reason being the lack of transparency in NFT pricing, making it difficult for users to cash out after trading and purchasing NFT (token ID).With the introduction of the guarantor role, different guarantor groups can offer various price guarantees for NFT (token ID), establishing a multi-faceted price evaluation system for NFT (token ID).After purchasing an NFT (token ID), users can return it to the guarantor at any time at the highest guaranteed price to protect their interests.Additionally, after fulfilling their guarantee obligations, the guarantor can also request subsequent guarantors to provide guarantee obligations.When an NFT (token ID) is owned by the guarantor, and since the guarantor can be a DAO organization, this expansion allows the NFT (token ID) to continue operating as a DAO, thus further enhancing the social or community recognition of the NFT (token ID).
Specification
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.Every contract compliant to the EIP721Guarantee MUST implement the IEIP721Guarantee guarantee interface.The guarantee extension  is OPTIONAL for EIP-721 contracts.
EIP Page (the PR ):

Author: bl2
Date: 2024-03-27T04:28:00.445Z

The document here ERC-721 Guarantee Extension
Title: ERC_7721__Lockable_Extension_for_ERC1155
Category: ERCs

Author: piyushchittara
Date: 2024-06-09T08:41:27.933Z

This feature enables a multiverse of NFT liquidity options like peer-to-peer escrow-less rentals, loans, buy now pay later, staking, etc. Inspired by ERC7066 locking on ERC721, this proposal enables locking on ERC1155.
Complying with the need for enhanced security and control over tokenized assets, this extension enables token owners to lock individual NFTs with tokenId, ensuring that only approved users can withdraw predetermined amounts of locked tokens. Thus, offering a safer approach by allowing token owners to specify approved token IDs (setApprovalForId) to set an amount for withdrawal along with the default function of (setApprovalForAll)
EIP
ERC Pull Request
Please let us know your thoughts on this proposal and if our motivation seems useful!
Title: ERC_7841__Cross_chain_Message_Format_and_Mailbox
Category: ERCs

Author: ellie
Date: 2024-12-12T15:45:34.039Z

This ERC proposes a mailbox API and message format for sending and receiving data between L2s. It is intentionally designed to be general, providing a foundational standard for building application-specific messaging protocols.  This ERC is analogous to the Internet Protocol; it focuses on a format for sending and receiving messages, but leaves everything else up to higher-level protocols.
This ERC has similar motivations as ERC-7786. Both standards offer general cross-chain interfaces, but differ in how messages are represented and stored on chain.  It may make sense to combine this ERC with ERC-7786 or vice versa.
ERC PR

Author: kalmanL
Date: 2025-01-16T10:11:56.874Z

Hey I have a question regarding sessionId. As I understand the purpose of this is to allow the singing of txs on multiple chains in parallel ( before the txs are submitted), and the different txs can trigger the interop on multiple chains.
Would it not be easier to add some other access management scheme, e.g. add an ExecutionAddress/EntryPoint that can trigger the interop txs? The only problem then would be paying for gas, but that is simpler and can also be solved

Author: philippecamacho
Date: 2025-01-20T16:01:48.142Z

Hey! Thank you for your question.
You are right regarding the sessionId value. Its purpose it to enable contracts deployed on different chains to coordinate by fetching the right messages from the Mailbox.

Would it not be easier to add some other access management scheme, e.g. add an ExecutionAddress/EntryPoint that can trigger the interop txs? The only problem then would be paying for gas, but that is simpler and can also be solved

This standard aims at capturing communication protocols where application contracts proactively fetch information from the Mailbox. We call this communication model PULL (the application pulls from the Mailbox). What you are proposing makes all the sense, yet it corresponds to the PUSH model where the Mailbox calls a function on the destination chain contract. This communication model is the most common in practice and there are already a number of standards for it, such as ERC 7786.
Title: ERC_7484__Registry_Adapters_for_Smart_Accounts
Category: ERCs

Author: kopykat
Date: 2023-08-14T17:00:32.932Z

This EIP proposes a standardised registry adapter for modular smart accounts. The adapter allows the account to query and verify security attestations about a module through an attestation registry. The adapter is responsible for querying the registry and correctly handling the return values.
After having started a dialogue with many of the teams working on modular accounts and/or modules and having received useful feedback on the module registry reference implementation, we have now taken the next step of formalising what we have been working on as a public proposal. The goal of this is increasing the scope and visibility of discussion, receiving more feedback and, ultimately, coming to a consensus about this approach to modular account security.
One major point of discussion that I would like to highlight out of the box is around the tradeoffs of proposing a singleton registry (for more details see the Rationale section of the EIP) and whether this ERC should be more or less restrictive on alternative registries.
Finally, note that this proposal is still in draft and will likely change significantly with input from the community.
https://github.com/ethereum/EIPs/pull/7484

Author: hangleang
Date: 2023-09-20T06:50:36.659Z

Not sure if we can reuse ethereum attestation service: https://easscan.org/ for schema and attestation parts of the architecture, which anyone could attest on-chain and off-chain.

Author: kopykat
Date: 2023-09-20T11:40:14.357Z

Yes, our reference implementation Registry took a lot of inspiration from EAS but made some specific modifications for this use case: GitHub - rhinestonewtf/registry

Author: hangleang
Date: 2023-09-21T02:44:31.131Z

Okay, got it. I just saw the mentioned in FAQ - module registry.
Is there any other way we can leverage EAS and build on top of the existing infrastructure?

Author: kopykat
Date: 2023-09-22T13:17:08.628Z

I’m not sure if there’s much more that could be beneficial. We could directly use the EAS contracts, but this would come with some compromises.
For example, the reference implementation registry has been designed with the idea that attestations are on made a specific module record, which leads to some benefits, such as being able to easily fetch all attestations on a specific module on-chain.
Would love to hear whether you have any ideas for using existing infra even further

Author: hangleang
Date: 2023-10-01T16:58:28.046Z

I’m not sure if this talk is helpful or not to gain insight from Bankless episode - EAS. In this talk, guests speaker mention about attestation can be done via smart contract, which mean any smart account can be able to do attest on any modules, but not sure whether it supports ERC1271 or not, that you mention in the FAQ.
Title: ERC_7855_Fungible_Token_with_gas_rebates
Category: ERCs

Author: theBigRevolution
Date: 2024-12-28T19:17:07.241Z

Discussion topic for ERC-7855 <link to ERC>
Update Log

2024-01-01: initial draft <link to pull request>

External Reviews
Sam Wilson @SamWilsn updated erc-7849 to erc-7855
Outstanding Issues
None as of 2025-01-06.

Author: wjmelements
Date: 2025-01-06T22:25:04.877Z

Since you’re extending ERC20 you don’t have to re-specify ERC20 in your ERC.

Author: theBigRevolution
Date: 2025-01-12T17:37:05.438Z

For informational purposes, I thought it was important to note it.

Author: wjmelements
Date: 2025-01-14T00:21:32.706Z

It clutters your proposal with redundant information. It’s not informationally beneficial because it’s redundant. It’s redundant because the dependency is linked at the top. Your proposal doesn’t need to explain ERC20. ERC20 can explain ERC20.

Author: wjmelements
Date: 2025-01-14T23:06:38.434Z

I built gas refunds into TrueUSD when I was at TrustToken. The scheme used the SSTORE refund, setting 1’s to 0’s. This mostly doesn’t work anymore because the refund cap was reduced from half to 20%.
Some disadvantages to your proposal:

emits an event; this costs gas
one rebate per user; tracking this costs gas and makes every transfer worse, adding 20000+ gas
rebate amount ambiguously defined as 25%
requires ether transfer; this adds 9000 gas

Normally a token transfer uses 15k to 30k gas, so adding 29k+ will make it around 50% worse.
In summary your token will add more than 25% to the transfer gas to rebate less than 25% of the transfer gas. This is a bad mechanism, though it could still have marketing advantages.
Since your rebate percentage is so close to the theoretical limit imposed by eip-3529, you could consider using the SSTORE refund, but I suspect that this will also rarely be cost-effective due to relatively stable gas prices.
Title: ERC_7785__Onchain_registration_of_chain_identifier
Category: ERCs

Author: SamWilsn
Date: 2024-10-08T18:47:56.771Z

github.com/ethereum/ERCs








Add ERC: Onchain registration of chain identifiers


master ← yuliyaalexiev:master



          opened 01:16AM - 09 Oct 24 UTC




            yuliyaalexiev
          



+108
-0






This ERC proposes deriving chain identifiers by hashing their chain name (along …with other relevant information) and using ENS to map chain names to these identifiers, replacing the centralized list currently maintained on GitHub.

Author: yuliyaalexiev
Date: 2024-10-09T02:17:50.179Z

Moved the PR to the ERCs repo - please update to …/ethereum/ERCs/pull/669

Author: abcoathup
Date: 2024-10-09T04:12:03.973Z

github.com/ethereum/ERCs








Add ERC: Onchain registration of chain identifiers


master ← yuliyaalexiev:master



          opened 01:16AM - 09 Oct 24 UTC




            yuliyaalexiev
          



+108
-0






This ERC proposes deriving chain identifiers by hashing their chain name (along …with other relevant information) and using ENS to map chain names to these identifiers, replacing the centralized list currently maintained on GitHub.

Author: 0xMims
Date: 2025-02-05T17:05:41.795Z

Just curious if there are any updates to this EIP? Will this be added as a draft to the EIP website?

Author: u59149403
Date: 2025-04-20T00:21:32.553Z

ERC-7785 says:

We propose to extend the size of identifiers to 32 bytes

According to EIP-2294: Explicit bound to Chain ID size , safe size of chain id is 31 (sic!) bytes. From that EIP:

(1, 2^31 - 1): “Safe Range”, the higher bound is decided by Javascript number

Author: SamWilsn
Date: 2025-04-28T21:36:36.996Z

ERC-7785 may or may not be adopted. It’s just a proposal currently.
Title: ERC_165_Versioning_To_Avoid_Irreparable_Errors
Category: ERCs

Author: sullof
Date: 2023-12-21T19:34:59.866Z

I’d like to highlight an issue with the current method of supporting ERC-165 interfaces, which focuses solely on the Final version and disregards any intermediate versions.
When a promising new proposal emerges, many projects adopt it, even if it’s in the Review phase or sometimes even a Draft. This is due to the expectation that the proposal will eventually be finalized without significant changes. A case in point is ERC-6551, which, although still in the Review stage, has been implemented by numerous projects. A concern arises when such a proposal undergoes modifications before finalization, leading to a different interface ID. This makes it impossible to verify if a smart contract supports the intended interface.
Those who adopted the initial version might end up aligned with an incorrect interface ID, potentially leading to irreparable errors. Introducing some form of versioning could resolve this by enabling the verification of the specific interface version supported, thus ensuring accurate information retrieval.
Several possible solutions exist for this issue. A straightforward approach would be to include the previous version in the final specification. For instance, the final interface could retain the name IERCxxx, while the earlier version could be named IERCxxxv1.
Alternatively, a new ERC could be introduced, such as:
interface IERCzzz {
  // returns the version for a specific interface
  function interfaceVersion(bytes4 interfaceId) external view returns (uint256) {}
}

In this case, when a standard supports more versions, we could verify if it supports both IERCxxx and IERCzzz and call interfaceVersion. This would enable determination of which version of the interface is supported. It’s important that ERCxxx lists the versions it supports.
A potential challenge arises when the first version of the interface is the only one, thereby lacking explicit versioning. To address this, we could assume that, by default, the version is 0.0.1. Hence, the function would return 0.0.1 in such cases. Under this system, if there are no changes throughout the development process, the final version (1.0.0) would be considered equivalent to 0.0.1. However, if there are changes during development, each intermediate version would be assigned a unique number to reflect those alterations.
Regarding the interfaceVersion function, using uint256 as the result type is indeed more efficient for handling within a smart contract. The versioning could be straightforward, where a version like 1.2.3 would be encoded as 1002003. Alternatively, each part of the version (MAJOR.MINOR.PATCH) could be considered as a bytes8 segment and encoded as:
uint semver = MAJOR << 16 | MINOR << 8 | PATCH;

What are your thoughts on these suggestions?
Title: ERC_7513__Smart_NFT___A_Component_for_Intent_Centr
Category: ERCs

Author: MJ_Tseng
Date: 2023-09-06T10:52:50.427Z

Smart NFT is the fusion of Smart Contract and NFT. An NFT with the logic of a Smart Contract can be executed, enabling on-chain interactions. Transitioning from an NFT to a Smart NFT is akin to going from a regular landline telephone to a smartphone, opening up broader and more intelligent possibilities for NFTs.
EIP: ERCs/ERCS/erc-7513.md at erc-7513 · TsengMJ/ERCs · GitHub
PR: Add ERC: Smart NFT - A Component for Intent-Centric by TsengMJ · Pull Request #73 · ethereum/ERCs · GitHub

Author: 0xmu
Date: 2023-09-25T06:51:32.841Z

Love this idea to explore the function modularization through NFT.
When you mention Intent Abstraction, are you referring that the solver to fetch and concatenate appropriate modules with high security and execute them?
(and maybe whats the relationship of this idea and 6551?)

Author: MJ_Tseng
Date: 2023-09-26T02:05:33.514Z

Yes, we believe that complex interaction processes can be abstracted into reusable functional modules. This is the foundation for efficient and secure implementation in an intent-centric manner.
While we are all NFT-bound, what EIP-6551 achieves is providing an associated contract address for NFTs to store assets. On the other hand, this EIP aims to package code that can perform specific functions into NFTs. Before this, there wasn’t a secure on-chain way to trade code or transfer contract permissions. With this EIP, it’s possible to achieve this through NFTs on any NFT marketplace.

Author: cleanunicorn
Date: 2023-12-19T05:12:11.039Z

I recently wrote a detailed study on Intents.
This is for those who seek a thorough understanding of the reasons for and against the proposal.
https://www.edenblock.com/post/the-next-blockchain-bull-run-user-intents-paving-the-way-for-mass-adoption
Title: ERC_7813__Store__Table_Based_Introspectable_Storag
Category: ERCs

Author: alvarius
Date: 2024-11-08T16:51:21.134Z

This standard introduces a flexible on-chain storage pattern that organizes data into structured tables with schemas, similar to a traditional database. This approach allows new tables to be added at runtime without impacting existing contracts, thereby simplifying upgrades and extensions. By providing a unified interface for data access, the standard enables any contract or off-chain service to read stored data without the need for custom getter functions. Additionally, by standardizing event emissions for state changes it enables automatic, schema-aware indexing.
PR:
https://github.com/ethereum/ERCs/pull/711
Title: Nonce_minter_bot_for_ERC20Mintable_open_source_wal
Category: ERCs

Author: vaumoney
Date: 2022-11-29T17:09:14.017Z

eip-nonce_minter_bot.md using eip-template.md
Here is my prior draft
Abstract
Isn’t a ‘bot’ a program with a GUI? Using a nonce scope, a unique ERC20Mintable contract forges wei. Can the load balanced nodes of Ethereum wei facilities suspend mintability to additional RPC contracts? I want to make an open source nonce minter bot for wallet supply key recovery. The nonce scope is permitted if the host is set, perhaps with consensus to change services.
Motivation
I’ve been concerned with lost passwords in my traditional app development, so I often apply phone number logins. Identification provision authentication requires a unique caller to mint in an assertively open source environment.
Specification (RFC 2119 and RFC 8174 syntax and semantics technical specification)



Rationale



Backwards Compatibility



Test Cases



Reference Implementation (optional)



Security Considerations



Copyright
Copyright and related rights waived via CC0.Preformatted text

Author: vaumoney
Date: 2022-12-06T16:50:53.304Z

How can we be sure the Authority service (i.e. droplet) is deploying to the --nat=extip, GitHub.com/nickcarducci/nonce-minter-bot?

This enode can then be included in your genesis.json file and will be used by other nodes to sync to the blockchain and other stuff.

I’m not sure this is content addressable unless Digital Ocean open sources this code all the way upstream…

Simply embed this button and associated link in your README.md files in GitHub repos, or web pages, and let us handle the app deployment process.
Title: EIP__Social_Recovery_Interface
Category: ERCs

Author: odysseus0
Date: 2023-05-30T08:32:12.962Z

I would like to share with you a new ERC proposal that aims to standardize the interface for social recovery processes within smart contract accounts:
https://github.com/ethereum/EIPs/pull/7093
The main idea of this proposal is to separate the identity verification and policy verification procedures from the recovery process, allowing users to customize their recovery policies and choose different types of guardians, such as friends, family members, NFTs, SBTs, or even off-chain identities. The proposal also supports multiple recovery mechanisms and eliminates single points of failure.
I believe this proposal can benefit the Ethereum community by providing a common standard for social recovery processes, enabling interoperability and composability among different smart contract accounts and applications.
I would appreciate your feedback and suggestions on this proposal. Please let me know what you think about the design, implementation, security, and usability aspects of this standard. Thank you for your time and attention.

Author: bumblefudge
Date: 2024-04-02T04:51:38.487Z

this is super interesting! do you know if anyone has implemented this and benchmarked/studied it on a testnet or anything?

Author: Amxx
Date: 2025-03-05T13:07:19.964Z

This ERC contains invalid solidity code (public functions in interfaces, missing location for non-value args, typos for types and variables …) that shoukld be fixed.
Additionally, it requires IRecoveryAccount to provide EIP-712 related getters. I’d suggest removing them in favor of ERC-5267.

Author: Amxx
Date: 2025-03-05T13:08:57.892Z

I would also suggest to prefix all interfaces with the ERC number to avoid any confusion with other ERCs

IPermissionVerifier → IERC7093PermissionVerifier
IRecoveryPolicyVerifier → IERC7093RecoveryPolicyVerifier
IRecoveryAccount → IERC7093RecoveryAccount

Author: Amxx
Date: 2025-03-05T13:20:29.612Z

The ERC mentions
EXECUTE_RECOVERY_TYPEHASH = keccak256("StartRecovery(address configIndex, bytes newOwners, uint256 nonce)")

Usually, the name of the variable should match the name of the typed data struct. So it should either be START_RECOVERY_TYPEHASH or "ExecuteRecovery(address ...

Author: Amxx
Date: 2025-03-05T14:18:42.868Z

I’m currious why the getRecoveryStatus(address policyVerifier) is taking an address as a parameter.

can multiple recovery happen in parallele for the same account (using different configIndex) ?
can multiple RecoveryConfigArg (configIndex) use the same policyVerifier ?

Overall, this ERC feels way under-specified.

Author: Amxx
Date: 2025-03-05T16:53:41.225Z

In struct ThresholdConfig, lockPeriod is using a signed value (int48). I guess this is a mistake.
In IPermissionVerifier, should the isValidPermission functions be view ? Is there any reason for them to be non-payable ?
Title: ERC_7695__Ownership_Delegation_and_Context_for_ERC
Category: ERCs

Author: ducthotran2010
Date: 2024-04-19T08:28:17.758Z

Hi Magicians,
I’m from the Axie community, currently, we’re currently grappling with scalability issues and want to encourage financial dApps for Axies without changing ownership due to lots of infrastructure and rewarding systems built on top of the ERC721 Axie standard.
Therefore I would like to propose an extension for ERC-721 tokens to facilitate a broader range of dApps (involving renting, delegating actions, and collateral systems). This proposal is to enhance NFT ownership without transferring to any contracts to perform renting or delegating actions. Furthermore, these extensions aim to support the integration of ERC-721 tokens into collateral systems in different and complex contexts.
Please read more at ERCs/ERCS/erc-7695.md at erc · ducthotran2010/ERCs · GitHub
https://github.com/ethereum/ERCs/pull/391

Author: nvnamsss
Date: 2024-04-24T03:49:13.937Z

This proposal has the potential to improve the quality of life. Based on the current interface specification, the asset owner has no permission to cancel the right of ownership?

Author: ducthotran2010
Date: 2024-04-25T06:32:51.677Z

If I understand correctly, you might wonder why the NFT owner does not have permission to cancel the delegation once his/her NFT is delegated to someone.
Technically if owners have permission to cancel delegations, it seems like an approval for operators to control NFTs for owners, which was already introduced in the ERC-721 standard before (via approve or setApprovalForAll).
The ownership delegation can help with the mechanism which temporarily transfers the ownership rights from owners to delegatees until the agreement expires. This will:

Provide us with a solid commitment between owners and delegatees.
And enable the development of other dApps that can leverage this type of commitment.

E.g. Collateral contracts cannot built on top of ERC-721 without forcing to lock tokens in the contracts because using approval method seems ineffective since the owner can revoke approval at any moment. These contracts may find the mechanism to be a useful alternative.
Title: ERC_7868__Verifiable_Cross_Rollup_Links
Category: ERCs

Author: shakeshack
Date: 2025-01-27T21:01:10.229Z

Cross rollup traffic should ultimately be secured by the L1. EIP-7868 propoose a standard around how different rollup frameworks can identify cross rollup dependencies enabling settlement time validation of cross rollup txs.
The end goal is to make both the L1 and its L2s one homogenous economic zone security wise.


github.com/ethereum/ERCs








Add ERC: Verifiable Cross Rollup Links


ethereum:master ← polymerdao:bo/xrollup-links



          opened 01:08AM - 24 Jan 25 UTC




            notbdu
          



+117
-0






This ERC proposes a specification for verifiable cross rollup links to enable se…ttlement time verification of cross rollup transactions across different rollup frameworks.

The goal is to enable rollups of any framework to join a cluster and have cross rollup communication within that cluster secured by the L1.
Title: ERC_7737__Custom_data_access_model
Category: ERCs

Author: 1999321
Date: 2024-06-19T06:21:09.846Z

The custom data access model uses solidity’s delegate mode to obtain the contract’s data read permissions. Corresponding reading logic can be developed through any third-party contract to obtain the desired data form. This model can save gas costs when it requires multiple accesses to the memory of a contract to obtain the final data form. It can even embed the required data processing logic directly into the agent contract, which is equivalent to native execution of data. Access and compute without making external calls.
Title: AllERCDevs_S2E2_next_Tuesday
Category: ERCs

Author: xinbenlv
Date: 2024-03-29T22:54:46.172Z

The upcoming session highlights 
- Seaport v1.6 and hooks architecture shared by @z0age from @OpenSea
- ERC-7529 DNS over HTTPS for contract discovery, and eTLD+1 Association @TtheBC01
- and ERC-7529 and ERC-5169 (Client Script URI) by @Victor928. 
We are glad to have @optimizoor (#Solady lead dev), @ricmoo (author of #EthersJS), @gnidan (driver of @ethdebug, formerly lead maintainer of @trufflesuite), @frangio_ (formerly lead smart contract developer of @OpenZeppelin) planning to join and help review or discuss. (and we welcome more)

See more details

tweet: https://twitter.com/ZainanZhou/status/1773839981888622681
github issue: (Future) 2024-04-02 (E2S2) AllERCDevs Agenda Thursday (Asia/US friendly time) · Issue #19 · ercref/AllERCDevs · GitHub

Feel free to share with your builder friends / team or community or whoever cares about open interoperability
Title: ERC_7121__SoulBounds_Interface
Category: ERCs

Author: llleo
Date: 2023-06-02T14:58:23.615Z

The SoulBounds EIP proposes a standard interface, called SoulBounds, that extends the ERC-1155 token standard to support the representation and management of soulbound assets on the Ethereum network. Soulbound assets are unique digital items that are permanently bound to a specific user or address, preventing transferability to other addresses.

Author: abcoathup
Date: 2023-06-02T23:06:38.064Z

https://github.com/ethereum/EIPs/pull/7121/files

Author: SamWilsn
Date: 2023-10-24T20:10:54.645Z

Regarding the soulbind and soulunbind functions, other token standards omit functions which are only likely to be called by the deployer of the contract. For example, ERC-1155 does not specify a mint or burn function. I’d recommend not including the soulbind and soulunbind functions because they aren’t likely to be used by most people interacting with the contract. Further, some contracts may not even support unbinding tokens, so that function will be entirely useless for them.

Author: SamWilsn
Date: 2023-10-24T20:12:07.626Z

Bit of bikeshedding, but have you considered soulOf as an alternative to soulboundOf?
Title: ERC_7561__Simple_NFT
Category: ERCs

Author: wenzhenxiang
Date: 2023-11-20T11:04:53.870Z

ERC721 are Ethereum-based standard NFT that can be traded and transferred on the Ethereum network. But the essence of ERC721 is based on the EOA wallet design. EOA wallet has no state and code storage, and the smart contract wallet is different.
Almost all ERCs related to NFT are adding functions, our opinion is the opposite, we think the NFT contract should be simpler, more functions are taken care of by the smart contract wallet.
Our proposal is to design a simpler NFT asset based on the smart contract wallet,
It aims to achieve the following goals:

Keep the NFT contract simple, only need to be responsible for the transaction function
approve functions are not managed by the NFT contract , approve and getApproved should be configured at the user level instead of controlled by the nft contract, increasing the user’s more playability , while avoiding part of the ERC-721 contract risk.
Remove the safeTransferFrom function, and a better way to call the other party’s nft assets is to access the other party’s own contract instead of directly accessing the nft asset contract.
Forward compatibility with ERC-721 means that all nft can be compatible with this proposal.

Examples
Judges whether the receiving address is safe (ERC-721, safeTransferForm),
ERC-721 Consecutive Transfer Extension(ERC-2309),
No Intermediary NFT Trading Protoco(ERC-6105),
authorizes the distribution of the user’s own assets (ERC-721, approve, allowance) and many proposals based on ERC-721 extension
The above work should be handled by the user’s smart contract wallet or wallet pulgin, rather than the nft contract itself.
this EIP is forward compatible with ERC-721.
Title: New_ERC__Hybrid_Governance_Document_Management__HG
Category: ERCs

Author: thxdao
Date: 2025-04-09T15:33:01.344Z

A proposal for Hybrid governance document management for on-chain organizations built upon off-chain legal frameworks.


github.com/ethereum/EIPs








Add EIP:Hybrid Governance Documents  Management


master ← Borderless-company:hgdm



          opened 03:27PM - 09 Apr 25 UTC




            cardene777
          



+1136
-0






This is a draft ERC proposing Hybrid Governance Documents Management (HGDM).

…ERC Number: To be assigned by an editor.
Discussion Link: TODO create conversation in ethereum magicians with this ERC

## Summary

Hybrid governance document management for on-chain organizations built upon off-chain legal frameworks.
Requesting review from ERC editors. Thanks!

Author: thxdao
Date: 2025-05-09T12:43:39.436Z

Closed EIP and resubmitted as an ERC.


github.com/ethereum/ERCs








ERC-7931: Hybrid Governance Documents Management


master ← Borderless-company:hgdm



          opened 12:21PM - 17 Apr 25 UTC




            cardene777
          



+1143
-0






This is a draft ERC proposing Hybrid Governance Documents Management (HGDM).

…I have been assigned a number for the following EIP:

https://github.com/ethereum/EIPs/pull/9616

## Summary

Hybrid governance document management for on-chain organizations built upon off-chain legal frameworks.
Requesting review from ERC editors. Thanks!
Title: ERC_7616__the_hybrid_fungible_token
Category: ERCs

Author: fomo-protocol
Date: 2024-02-07T15:15:34.529Z

This is the discussion thread for: ERC-7616
This proposal introduces a hybrid fungible token standard that merges the ERC-20 token’s fungibility with the unique identification capabilities of ERC-721 tokens. New ERC introduced a way to manage both ERC-20 and ERC-721 tokens in 1 contract.
The motivation behind this EIP is to address the limitations of current token standards by combining the best aspects of ERC-20 and ERC-721, enhancing liquidity, and simplifying the control over token fractionalization and reassembly. This hybrid approach seeks to streamline the integration of DeFi and NFT utilities, leveraging existing infrastructure for faster adoption and minimal disruption to current applications.

Author: xinbenlv
Date: 2024-03-03T06:00:48.562Z

Hi, thank you for contributing an ERC draft. Before I can merge this ERC, the proposal actually breaks ERC-20 and ERC-721. They are not ERC-20 and ERC-721 compliant. Can you verify was it intentional and clarify in the backward compatibility?

Author: fomo-protocol
Date: 2024-03-03T08:40:41.161Z

Yes, the deviation from full ERC-20 and ERC-721 compliance in our ERC draft is intentional.
Our goal is to align as closely as possible with the ERC-20 and ERC-721 standards. However, achieving complete compliance is not feasible without compromising the innovative aspects of our proposal. We’re focusing on minimizing disruptions to ensure that users experience minimal inconvenience. As more applications begin to adopt the ERC7616 standard, we anticipate a smoother integration across the ecosystem.
For instance, regarding the Transfer event, we have opted to adhere to the ERC-721 standard rather than the ERC-20 standard. This decision was made because most NFT marketplaces depend on this event for accurate balance displays. As a result, ERC-20 transfers may not display correctly until applications update their systems to be ERC7616 compliant.
Similarly, for the balanceOf function, we’ve chosen to follow the ERC-20 standard over the ERC-721 standard. This approach is due to the reliance of most decentralized exchanges (DEXs) on this method for displaying ERC-20 token balances.
These decisions are part of our strategy to ensure that ERC7616 offers a balanced and less disruptive integration into the current ecosystem, acknowledging the need for backward compatibility adjustments.
Title: EIP_7704__Soul_Resonance_Token
Category: ERCs

Author: Mike_0x1024
Date: 2024-05-20T14:39:24.855Z

Introduction:
SRT(Soul Resonance Token), introduces a novel token protocol. Much like SBT, SRT lacks support for transfer methods, prohibiting users from moving SRT assets between different accounts. What sets SRT apart is its utilization of the mint() and burn() methods via the Bonding Curve mechanism, facilitating pricing and trading functionalities for SRT. Consequently, SRT represents an asset type that is non-transferable yet tradable. By merging the features of SBT’s soul binding and the tradability of traditional ERC20 assets, SRT effectively closes the gap between SBT and conventional ERC20 tokens.
Characteristics:

Non-transferable:

The inability to transfer SRT tokens ensures that they remain securely bound to the account where they were originally minted or acquired.

Tradable:

Despite being non-transferable, SRT tokens are still tradable. This means that they can be bought and sold on decentralized exchanges (DEXs) or other platforms that support trading of SRT tokens. The trading functionality allows users to exchange SRT tokens for other assets or currencies within the ecosystem in a unique way.

Customizable Market Curve:

SRT implements a customizable market curve through the Bonding Curve mechanism. This curve determines the pricing and supply dynamics of SRT tokens based on the amount of tokens in circulation. By customizing the market curve, developers can tailor the token economics of SRT to suit specific use cases or objectives.
https://github.com/ethereum/ERCs/pull/414

Author: jhfnetboy
Date: 2024-05-26T03:48:43.791Z

If you want to buy or sell SRT, you must transfer into or out of your account.
or transfer SRT with a holding account?
Title: Proposal_for_a_New_ERC__Token_Transfer_Validation
Category: ERCs

Author: nathanglb
Date: 2024-04-02T19:59:38.232Z

ERC20/ERC721/ERC1155 are all token standards that have existed for many years.  The battle over creator royalties has been ongoing for some time now, and Limit Break has built an extension to these standards that allow creators to put custom controls in place for transfers.  The extension, known as Creator Token Standards (or ERC721C) is quickly becoming the standard of record for creators that wish to enforce royalties on their collections, or perhaps to build other cool gamified features for tokens.
To date, Magic Eden and OpenSea marketplaces have recently adopted use of ERC721C standards for creator earnings/royalty enforcement.  There are many creators who want to adopt ERC721C, so now seems to be an appropriate time to start formalizing an ERC that standardizes this extension to the core token standards for creators who wish to use it.

Author: ryley-o
Date: 2024-04-09T16:42:10.855Z

I agree that formalizing the standard would be very appropriate, as the current name of ERC721C is misleading. The extension created by Limit Break did not go through the ERC review process, and the extension fundamentally changes the ownership model of the tokens on those contracts (single token owner now becomes joint ownership between entity controlling the transfer validation logic and token owner).
Giving the community a peer-reviewed ERC that includes all risks and highlights different changes is important and will provide a place for consumer education.
I would also encourage this community to consider options beyond the current Limit Break implementation, as I personally do not feel comfortable with the long-term security implications of admin-controlled whitelists on my tokens.

Author: LB-mitch
Date: 2024-04-09T18:34:57.895Z

It’s important to note that the LB implementation of the creator token standards only requires that a contract have a transfer validator - this can come in any form such as a whitelist, blacklist, authorizer model, and more.
Limit Break does provide a canonical validator, but this can be changed at any time.

Author: ryley-o
Date: 2024-04-09T19:39:15.273Z

Good call - an important distinction and updated my post above to indicate joint ownership between the entity controlling the transfer validation logic and token owner. Because the transfer validation is configurable, the entity controlling that configuration could be a contract owner, or a hard-coded allowlist owner, etc.