Diegorb1329/eth_magicians_forum huggingface dataset:
Title: Test_topic_for_test_messages
Category: Uncategorized

Author: veox
Date: 2018-02-18T17:30:29.045Z

I can certainly post, and you can read it.

Author: jamesray1
Date: 2018-02-19T01:49:38.676Z

Oh hai there!
Well I can sign up and log in and post a message with Github Oauth.

Author: jpitts
Date: 2018-02-19T05:31:54.695Z

Yay! I wanted to just yay, but Discourse keeps asking me to say more.

Author: nixxypQCee
Date: 2024-04-23T09:24:31.130Z

Same here, I logged in too with Github Oauth. Cheers!
Title: EIP_7925_eth_sendBlobs_and_eth_getBlobStatus_for_m
Category: Uncategorized

Author: sbacha
Date: 2025-04-01T08:00:03.080Z

EIP-7925: Optional RPC Methods eth_sendBlobs and eth_getBlobsStatus

EIP-7925: Optional RPC Methods eth_sendBlobs and eth_getBlobsStatus
+ Purpose
+ Blobenheimer
+ Specification
- 1. eth_sendBlobs Method
- 2. eth_getBlobsStatus Method
+ TLDR:



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


Purpose
This Ethereum Improvement Proposal (EIP) introduces two new JSON-RPC methods:

eth_sendBlobs – Allows users to submit multiple EIP-4844 Type 3 transactions for the same sender and nonce, letting block-building infrastructure choose the most optimal one.
eth_getBlobsStatus – Enables querying the status of a previously submitted bundle of transactions.

It also introduces a partioned mempool called a sublet, a non-gopssiping pending pool for enabling users of the RPC method to submit multiple transactions of the same nonce. Each sublet represents its own building policy, in an effort to optimize blob inclusion. I am working on refining this part conceputally outside of this EIP, you can

Read more here regarding ‘sublists’ 


Blobenheimer
Blob transaction originators currently are limited in their ability to submit multiple transactions for varying blob transaction composition.

Fixed Submission: Existing eth_sendRawTransaction forces a sender to commit to one transaction per nonce.
Inefficiency: Transactions with more blobs may get excluded, even if a smaller variant could have been included.

eth_sendBlobs method enables senders to submit multiple versions of the same transaction (differing in blob count), and the most suitable one is selected based on network conditions. This prevents the sender from guessing the optimal number of blobs.  Each *subk

The method returns a unique bundleId that represents the submitted transaction set.
The eth_getBlobsStatus method provides visibility into whether the bundle was included in a block, is still pending, or expired.


Question: Can a data structure be leveraged to communicate more information besides simply an opaque UUID?


Specification

1. eth_sendBlobs Method

Input:

txs: Array of hex-encoded signed transactions, all from the same sender and nonce.
maxBlockNumber: (Optional) Expiry block for the bundle.


Output:

bundleId: Unique identifier for the submitted transaction set.
error: If submission fails, an error code is returned.




2. eth_getBlobsStatus Method

Input:

bundleId: Identifier of the submitted bundle.


Output:

Status of the bundle (pending, included, expired, etc.).




TLDR:

Optimized Inclusion: Avoids wasteful exclusions due to blob slot constraints.
Improved Tracking: Provides a standard way to track blob transactions.
Reduces Sender Complexity: No need to manually optimize transaction submissions.


This method is based off of Titan Builders eth_sendBlobs method.
Title: Yellowpaper_correction
Category: Uncategorized

Author: RenanSouza2
Date: 2024-06-10T14:09:59.031Z

Hey everyone, I made this PR in the yellowpaper repository with some small corrections,
https://github.com/ethereum/yellowpaper/pull/909
if anyone has thoughts on it I would like to know
Title: Looking_for_collaboration_on_BITE_Privacy_protocol
Category: Uncategorized

Author: kladkogex
Date: 2025-05-02T15:48:31.221Z

We are launching BITE, a privacy-oriented blockchain that extends the EVM and Solidity with support for encrypted transactions and data.
The test net is roughly scheduled for this summer
We’re looking for DApps interested in collaborating with us to test and explore the protocol.
More details here!



SKALE Network Forum – 2 May 25




BITE : Solving Blockchain Privacy in Four Phases




dApp Developers




hey @kladkogex ! thanks for the amazing insights. how do you think each of the features and functionalities you mentioned will impact on transaction throughput and gas costs? it feels like every phase brings more and more heavy mathematical...
Title: EIP_6914__Reuse_Withdrawn_Validator_Indices
Category: Uncategorized

Author: dapplion
Date: 2023-07-27T16:30:22.691Z

Discussion thread for EIP-6914
https://github.com/ethereum/EIPs/pull/6914

Author: dapplion
Date: 2023-07-27T16:53:10.200Z

I would like to dispute the concern over data complexity to handle AttesterSlashings with pubkeys.
The maximum data increase in blocks due AttesterSlashing using pubkeys instead of indexes (for networks with more than 262144 validators, with 2 AttesterSlashing per block, 2 IndexedAttestations per AttesterSlashing)
(48 - 8) * (validator_count / 32 / 64) * 2 * 2





validator_count
block size increase




500,000
39kB


1,000,000
78kB


1,500,000
117kB


2,000,000
156kB



Considering that the network only has to handle this data load for sustained periods of time, in exceptional circumstances it does not sound unreasonable. Experiments motivated for eip4844 have shown that the network is perfectly capable of handling this data load.

Author: dapplion
Date: 2023-11-23T17:50:06.126Z

Wrote some thoughts on the question to adopt the EIP or just use an engineering approach.
TLDR

Is unbounded beacon state growth actually a problem? Long term yes
Can it be solved with engineering solutions (no EIP)? Not entirely
Should we adopt EIP-6914? Maybe, in several years




HackMD



Should we adopt EIP-6914 (re-use indexes)? - HackMD
Beacon chain today experiences unbounded growth. There is no mechanism to prune validators in any circumstance, and new deposits can append validator records in perpetuity. Note that the maximum possible number of active validators is bounded by the...

Author: xrchz
Date: 2024-04-06T07:12:49.460Z

I recognise that you note the ecosystem consideration of breaking the ability to identify validators by index. I just want to add an additional bid for not breaking this, or at least taking the cost into account. Applications relying on one-index-one-validator will, if this EIP is adopted, need to run a migration of their state. This may be costly and error prone especially if they are based on historical/archive data. (This is in addition to the ongoing relative space cost of using pubkeys instead afterwards.)

Author: grogo
Date: 2025-04-23T10:12:00.361Z

@dapplion
Is this EIP still considered? I saw it got marked as stagnant by a bot.
We are now doing some decisions in SSV protocol and we were wondering if you may later break us.
Title: dOrg_DAO_is_recruiting_new_developers
Category: Uncategorized

Author: rihp
Date: 2020-08-14T23:51:20.934Z

Hello fellow magicians,
This is Roberto from dOrg, and we’re happy to see that recently we have received a flood of project opportunities. Right now we’re looking to onboard a new group of agents like you who can fill those spots and help us build the new decentralized future.
Here’s something we’ve prepared so that you know what to expect:
Calling all Crypto freelancers 
Want to get paid by working in a developers DAO?
dOrg is a builders DAO and we have openings for epic projects alongside awesome web3 warriors :merman_tone3:
About dOrg:
dOrg is a collective of crypto native freelancers that join forces to tackle complex web3 projects. dOrg made history in 2019 when it became the first Decentralized Autonomous Organization (DAO) to ever be recognized by law.
If you have…
At least 1 year of proven experience in any of these, you’ll get far with us  :

Solidity
Node
React
Typescript
Rust

Benefits:

Enhanced credibility & support
Competitive compensation
Work whenever, wherever
DAO Stake
Friendly and multicultural team

Questions?
DM a member or join our community channel at Keybase
Next Steps →
Submit an activation proposal to the dOrg DAO.
Successful applicants will receive 100 USDC and the equivalent voting power.
Instructions below 
https://dorg.tech/membrane/

Author: yasirsaeed
Date: 2024-09-10T17:44:03.165Z

Hey, this sounds like an amazing opportunity for freelancers looking to dive deeper into the decentralized space! 
For anyone looking to explore Web3 jobs, roles like these are a fantastic way to get involved. There are also some great resources out there for developers seeking to level up their skills or find more web3-focused projects. If you’re on the lookout for other web3 job opportunities, platforms like Web3 Career are really useful for discovering more openings and trends in the space.
Excited to see what dOrg will build next!
Title: ERC_7815__Swap_Order_Routing_Interface
Category: ERCs

Author: yellow
Date: 2024-11-09T10:50:37.152Z

This ERC proposes a standardized interface for on-chain swap liquidity. It defines methods to calculate price, swap tokens, retrieve trading limits, and query capabilities of liquidity pools.
The standard simplifies access to defi liquidity sources – to improve composability and make routing (solving) easier.
ERC:


github.com


ethereum/ERCs/blob/70e96af4539a39ed2bf564ec3559fb45159ff223/ERCS/erc-7815.md
---
eip: 7815
title: Swap Order Routing Interface
description: An interface to simulate over swap liquidity.
author: Alan Höng (@kayibal), Markus Schmitt (@haikane)
discussions-to: https://ethereum-magicians.org/t/erc-7815-swap-orderrouting-interface/21634
status: Draft
type: Standards Track
category: ERC
created: 2024-11-09
---

## Abstract

This ERC proposes a standardized interface for on-chain swap liquidity. It defines methods to calculate price, swap tokens, retrieve trading limits, and query capabilities of liquidity pools.

The standard aims to simplify access to defi liquidity sources – to improve composability and make routing (solving), MEV capture (searching), and other defi functions easier.

## Motivation





  This file has been truncated. show original
Title: 2nd_Community_Call__ERC1400_Feedback__Discussion__
Category: ERCs

Author: AdamDossa
Date: 2018-09-26T18:19:03.451Z

We would like to have a second community call related to ERC1400 following on from the previous call documented at:



Community Call: ERC1400 Introductions, Feedback, & Questions ERCs


    The team that has submitted ERC1400 has agreed to do a community call to introduce the EIP, gather feedback, and talk through suggestions and questions. 

When: Monday, Sept 17th, 7AM PDT world time
Where: Google Meet https://meet.google.com/zpf-whhr-kfm

Here is the agenda / notes document, please add yourself if you plan to attend, and add your questions there: ETHMagicians Community Call: ERC1400 - HackMD 
The introduction thread is here: 


Thanks Adam Dossa @AdamDossa, Pablo Ruiz @pabloruiz…


When: Tuesday, October 2nd, 11AM EST world time check
Call Details: Zoom
Join from PC, Mac, Linux, iOS or Android: Launch Meeting - Zoom
Or iPhone one-tap :
US: +16465588656,963516600#  or +16699006833,963516600#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656  or +1 669 900 6833
Meeting ID: 963 516 600
International numbers available: Zoom International Dial-in Numbers - Zoom
Topics to discuss:

summary of main discussion points so far
should the standard insist on backwards compatibility with ERC20 / ERC777
which parts of the standard should be split out as separate ERC’s
initial set of ERC 1066 codes

Here is the agenda / notes document, please add yourself if you plan to attend, and add any items you’d like to discuss to the agenda: https://hackmd.io/lovcN0QXRpevkHSHrVFlYA
The introduction thread is here:
 ERC-1400 and ERC-1410 - Security Token and Partially Fungible Token EIPs
Please DO mention the questions you want to ask here in this thread as well as putting them into the notes call doc.

Author: milkeg
Date: 2018-10-01T22:50:47.989Z

@AdamDossa Will this session be recorded? Would like to attend but it’s happening overnight in Asia
Title: Send_Transaction_Conditional_RPC_API
Category: ERCs

Author: dror
Date: 2024-10-27T18:57:56.336Z

This EIP proposes a new JSON-RPC API method eth_sendRawTransactionConditional for block builders and sequencers,
enhancing transaction integration by allowing users to express preconditions for transaction inclusion.
This method aims to improve efficiency by reducing the need for transaction simulation,
thereby improving the computational efficiency of transaction ordering.

github.com/ethereum/ERCs








Add ERC: Conditional send transaction RPC


master ← eth-infinitism:AA-456-send-transaction-conditional-eip7702



          opened 02:05PM - 22 Oct 24 UTC




            forshtat
          



+158
-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.

Author: hellohanchen
Date: 2024-11-03T08:52:43.429Z

What would happen if the RPC provider cheats  users?

Author: dror
Date: 2024-11-05T14:09:14.692Z

This API can be used by users, not only services.
It is equivalent to “flashbots” private API.
The difference is that the service provider has a light check to know if the transaction might fail, and thus is not required to perform full tracing.
Once a transaction pass the validation, the provider should fully trace it. In case the transaction fails, it should drop it - and probably throttle down the caller, since this caller “lied”, by submitting a TX that reverts even if its preconditions are met.
Title: ERC_7838__Instruction_Specific_Address__ISA_
Category: ERCs

Author: ss-sonic
Date: 2024-12-10T22:23:00.717Z

The Instruction Specific Address (ISA) standard introduces a mechanism for approval-less interactions with decentralised applications (DApps) through dynamically generated single-use contract addresses. This standard enables seamless and secure DApp interactions without requiring wallet connections, approvals, or plugin dependencies, enhancing usability, security, and accessibility.
PR:

github.com/ethereum/ERCs








Add ERC: Instruction Specific Address


master ← router-protocol:master



          opened 06:58PM - 10 Dec 24 UTC




            ss-sonic
          



+454
-0






**ERC-7838: Instruction Specific Address (ISA)**

The Instruction Specific Add…ress (ISA) standard introduces a mechanism for approval-less interactions with decentralized applications (DApps) through dynamically generated single-use contract addresses. This standard enables seamless and secure DApp interactions without requiring wallet connections, approvals, or plugin dependencies, enhancing usability, security, and accessibility.

Author: wjmelements
Date: 2024-12-11T11:50:19.814Z

// Emit event for failed transaction

If you’re reverting, the event won’t persist.

Author: ss-sonic
Date: 2024-12-11T12:59:27.974Z

The transaction does not revert in the processCallOps function itself. Instead, it gracefully handles the failed call and explicitly emits the ExecutionFailed event.
Since the emit statement is outside the reverted call’s context, it is part of the main transaction’s execution and will be recorded in the transaction logs.

Author: wjmelements
Date: 2024-12-12T15:12:35.595Z

if (!success) {
            // Emit event for failed transaction
            // Revert with the original error data
            assembly {
                let ptr := mload(0x40)
                let size := returndatasize()
                returndatacopy(ptr, 0, size)
                revert(ptr, size)
            }
        }

that comment appears in a block that reverts.

Author: ss-sonic
Date: 2024-12-12T16:18:08.060Z

True, need to handle this properly. These are just examples of philosophy that ERC is trying to expand on, but point noted.

Author: chaandflower
Date: 2024-12-16T12:45:53.761Z

Could ISAs render traditional wallet-based UX paradigms obsolete, what new UX standards might emerge as a result?

Author: radek
Date: 2024-12-17T15:28:18.636Z

Self-Destruction:


After execution or refund, the ISA self-destructs to free resources and ensure it cannot be reused.



    selfdestruct(payable(refundRecipient));


I assume it is in conflict with the roadmap wrt selfdestruct.

Author: ip11
Date: 2024-12-17T15:41:34.565Z

does ERC-7838 ensure ISAs can’t be reused if selfdestruct is removed?

Author: ss-sonic
Date: 2024-12-19T17:23:44.640Z

The ISA does not rely on selfdestruct. It uses it for gas refunds during contract creation, but it would still function without it, though it would result in slightly higher gas fees for the relayer.
Title: Where_can_I_find_the_current_ERC_4337_EntryPoint_c
Category: ERCs

Author: reselbob
Date: 2024-02-26T20:00:50.497Z

Trying to find the current ERC-4337 EntryPoint contract in force. Thanks in advance.

Author: ulerdogan
Date: 2024-02-26T20:39:40.160Z

Latest update from the team here
Title: ERC__TBA__Contract_Metadata____merged_w__ERC_7572
Category: ERCs

Author: xinbenlv
Date: 2024-02-03T04:28:50.535Z

Abstract
A standard for exposing an interface describing a contract, main goal is to achieve backward compatibility and drive adoption and forward extension
Specification
interface ERC-DESC {
  contractURI() public view returns(string);
}

// A subset of 
// https://schema.org/Thing and 
// https://docs.opensea.io/docs/contract-level-metadata
{
  "name": "<contract name>",
  "description": "<contract description>",
  "image": "<imageURL>"
}

Rationale

compatible with Schema.org which are used by major search engines’ indexing and OpenGraph, good for SEOs and future adoption
compatible with OpenSea, good for crypto adoption.

Author: ryanio
Date: 2024-02-05T19:49:05.544Z

We have already proposed ERC-7572: Contract-level metadata via `contractURI()`, looks like your proposal is similar/the same, if you have any suggestions please feel free to comment in that thread.

Author: xinbenlv
Date: 2024-02-13T14:03:17.969Z

Hi @ryanio, thanks for bringing to my attention for ERC-7572. That sounds good. Happy to converge to yours if we share the same goal and same design philosophy.
Everyone reading this ERC proposal, please join discussion here ERC-7572: Contract-level metadata via contractURI()
Title: Enhancing_ERC20_Token_Visualisation__Direct_Image_
Category: ERCs

Author: njrapidinnovation
Date: 2023-06-05T09:30:22.243Z

Issues in Current Image Retrieval and Storage Process:


Centralization: Reliance on centralized servers or platforms for image storage introduces vulnerabilities and single points of failure.


Trust: Users must trust that the displayed image is authentic, as it can be manipulated or substituted when hosted externally.


Update Coordination: Updating the image requires coordination with multiple third-party services, which can be time-consuming and prone to errors.


Cost: Maintaining centralized image storage infrastructure can be expensive for token creators, especially for smaller projects or individuals.


Benefits of Storing Images in Smart Contracts:


Transparency and Decentralization: Storing images on the blockchain ensures transparency and decentralization, promoting trust and accountability.


Enhanced Security: Images stored on the blockchain are resistant to tampering, ensuring the integrity of the token’s image representation.


Cost-effectiveness: Storing images in smart contracts eliminates the need for centralized servers, reducing infrastructure costs.


Flexibility and Ease of Update: Smart contracts allow for easy image updates, saving time, resources, and ensuring consistency across platforms.


Improved Accessibility: Storing images in smart contracts enables inclusion of accessibility features, making the token more inclusive for users with disabilities.


Resource Savings:


Infrastructure Costs: Storing images in smart contracts eliminates hosting and maintenance expenses associated with centralized servers.


Development Effort: Integrating with external image storage services is unnecessary, saving development time and effort.


Coordination Efforts: Updating images in smart contracts eliminates the need for individual coordination with multiple third-party services.


Security Measures: Storing images on the blockchain reduces the need for additional security measures, saving resources.


In summary, storing images directly in smart contracts provides cost savings, transparency, security, flexibility, and accessibility advantages over the current image retrieval and storage process.
Details

A method to set the SVG image in string format.
A method to get the SVG image url in string format.

I took inspiration from generateNftSvgByTokenId method in On-chain-svg-nft-tickets
Title: ERC721_reserve_and_mint
Category: ERCs

Author: mattyh
Date: 2022-02-28T09:44:21.289Z

Hi can someone point me in the right direction to learn the code to reserve amount of nfts erc721 and then mint them .
Thanks
Title: ERC_7832__Sustainable_collaborative_NFT_collection
Category: ERCs

Author: gfLobo
Date: 2024-12-13T22:01:19.876Z

Abstract

This EIP proposes a standard for creating economically sustainable NFT governance for collections built on collaborative models based on ERC-721. It introduces dynamic minting fees, role-based access control, and a donation-based engagement model to enhance creator-community interactions. These mechanisms aim to balance scarcity, incentivize meaningful participation, and ensure sustainable growth for both creators and contributors.
The model defines “economically sustainable” as tokens whose minting value, creator subscription fees, and token quantity within each progressive discount cycle can only be adjusted once every 30 days from the last update by an ADMIN user. These mechanisms prevent excessive administrative modifications that could disrupt market stability, ensuring consistent price discovery and maintaining participant confidence. By aligning incentives and fostering predictability, the model creates a robust framework for engagement and value creation.

Discussion for: Add ERC: Sustainable NFT Collections by gfLobo · Pull Request #752 · ethereum/ERCs

Author: SamWilsn
Date: 2025-01-17T18:20:59.159Z

You define the updateTerms function as only being callable by admin users. I’d argue that it is unnecessary to define functions only callable by admins because the admin of a contract will know how to interact with the contract specifically. Other standards, like ERC-20 and ERC-721 intentionally don’t define mint and burn functions because they are unique to each contract. Updating a contract’s terms seems like a similar kind of action.
Same kind of reasoning for mint, burn, pause, etc.

Author: gfLobo
Date: 2025-01-20T04:55:10.281Z

This EIP addresses a specific and different use of collaborative NFTs, where multiple creators can interact and contribute to a collection. This model introduces collaborative governance, with dynamic rules regarding minting fees, participation, and contract updates.
This distinction is essential because, in collaborative projects, it is crucial to ensure the stability and integrity of the system. Functions such as updateTerms, mint, burn, and pause need to be tightly controlled to avoid arbitrary changes and ensure that the participation of all involved is conducted transparently and fairly.
Title: ERC_7552__Draft___Decentralized_Embedding_Registry
Category: ERCs

Author: cryptitalk
Date: 2023-11-02T23:13:44.525Z

Discussion context:


github.com/ethereum/ERCs








Add ERC: Decentralized Embedding Registry


master ← cryptitalk:erc-draft-embedding_registry



          opened 11:12PM - 02 Nov 23 UTC




            cryptitalk
          



+79
-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.

Author: haydar
Date: 2023-11-12T21:36:16.213Z

I’m here soon to be perfect

Author: Vados
Date: 2023-11-12T22:13:54.081Z

Perfect good ideal nft

Author: Vados
Date: 2023-11-12T22:38:41.082Z

cool perfecto

Author: Vados
Date: 2023-11-13T05:45:13.083Z

ERC 7552 – Heading towards freedom Good

Author: Dikun89
Date: 2023-11-13T20:15:39.071Z

Awesome this project

Author: shayano
Date: 2023-11-14T14:07:05.058Z

yes brother me too <3
Title: ERC_7564__Contract_wallet_management_NTF
Category: ERCs

Author: wenzhenxiang
Date: 2023-11-20T17:15:44.336Z

A proposal to manage NFT 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, NFT asset management, functional expansion of NFT transactions, etc.
The proposal aims to achieve the following goals:


Assets are allocated and managed by the wallet itself or plugins. such as approve , which are configured by the user’s contract wallet, rather than controlled by the NFT asset contract, to avoid some existing ERC-721 contract risks.


Add the nftTransfer function, the transaction initiated by the non-smart wallet itself or will verify the approves.


The user wallet itself supports approve. Add nftApprove,  nftGetApproved, Used to approve specify one asset under the nft contract.


add nftSetApprovalForOneAll, nftIsApprovedForOneAll, Used to approve specify all assets under the nft contract.


add nftSetApprovalForAllAll, nftIsApprovedForAllAll, Used approve for assets under all nft contracts.


The users can choose to add hook function before and after their nftTransfer to increase the user’s more playability


The user can choose to implement the nftReceive function
Title: ERC_7854__Verification_independent_Cross_Chain_Mes
Category: ERCs

Author: nambrot
Date: 2024-12-30T16:27:07.695Z

Official discussion thread for ERC7854: Verification-independent Cross-Chain Messaging Standard. It proposes an API for sending messages across chains to enable interoperability in the greater Ethereum ecosystem (but is flexible enough to encompass alternate VMs). It specifically is capable of sending messages via arbitrary transport and verifying them via diverse mechanisms. At the same time, it aims to provide enough standardization with a modular relaying mechanism to provide a consistent developer experience. As such, it allows for a clean separation of high level abstractions to be built by “application developers” like cross-chain tokens and account abstraction, while allowing for innovation at the verification and transport layer.
Title: ERC_7766__Signature_Aggregation_for_Account_Abstra
Category: ERCs

Author: alex-forshtat-tbk
Date: 2024-09-18T12:30:12.180Z

The core ERC-4337 previously included the specification for signature aggregation.
However, as this feature is not required for the functioning of the Account Abstraction, it is being extracted from the core ERC-4337 into a standalone specification.
This specification is currently identical to the one previously implemented in ERC-4337 and does not require any modifications to the deployed ERC-4337 contracts.
However, being a standalone proposal, “ERC-7766: Signature Aggregation” will continue evolving separately from ERC-4337 on its own timeline.
This is the PR to create the new ERC:

github.com/ethereum/ERCs








Add ERC: Signature Aggregation for ERC-4337


master ← eth-infinitism:AA-427-extract-aggregation-create-new



          opened 02:42PM - 10 Sep 24 UTC




            forshtat
          



+142
-0






We're extracting the signature aggregator outside of ERC-4337, so we want first …to create a new ERC. 
PR for the new ERC is here: https://github.com/ethereum/ERCs/pull/627






This is the PR to remove the Signature Aggregation specification from ERC-4337:

github.com/ethereum/ERCs








Update ERC-4337: Extract aggregation to a separate ERC


master ← eth-infinitism:AA-427-extract-aggregation-remove



          opened 02:50PM - 10 Sep 24 UTC




            forshtat
          



+13
-77






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_7772__Partial_Gas_Sponsorship_Interface
Category: ERCs

Author: lucaslim
Date: 2024-09-20T05:04:46.425Z

Discussion topic for EIP-7772 https://github.com/ethereum/ERCs/pull/649
This proposal defines the necessary interface that decentralized applications (dApps) must implement to sponsor a portion of the required gas for user operations utilizing a Paymaster that supports this standard. The proposal also provides a suggested code implementation that Paymasters can include in their current implementation to support dApp sponsorship. Partial sponsorship between more than one dApps may also be achieved through this proposal.

Author: VGabriel45
Date: 2024-09-30T17:33:59.336Z

This could indeed open up exciting possibilities for tokenomics, such as offering gas discounts based on token holdings or other criteria.
Given that this ERC works alongside ERC-4337, how does the gas efficiency of transactions using this partial sponsorship method compare to standard ERC-4337 implementations? Are there any estimates on the potential gas savings for users or additional costs for dApps when implementing this sponsorship model?

Author: dror
Date: 2024-10-01T10:56:40.964Z

Commented on the ERC.
The problems I see is that there is full trust between the paymaster and those sponsors: that is, a sponsor is tied to a specific paymaster, and the paymaster must have a “whitelist” of audited sponsors, otherwise, each of them is vulnerable to attacks - either denial of service attacks or actual funds steal.
In general, a paymaster must be very careful on external code it executes. The validation rules (ERC-7562) are there to prevent an attack by paymaster on the system (on bundlers). By calling external contracts, the paymaster exposes itself to other contracts that might breach those rules - and thus get the paymaster itself blamed for the failures.
Title: ERC__Antitoken___Representing_debt_in_a_token
Category: ERCs

Author: hazae41
Date: 2021-04-10T16:43:15.804Z

Simple Summary
Representing debt in a token. Like an ERC-20 but with receive instead of transfer. Thus, the token has a negative value: the less you have, the better.
Abstract
Imagine a anti-currency blockchain where, instead of signing the sending, you sign the receival.
You cannot send the currency to an address, you can only receive it from the given address.
Thus, the incentive is to spend it, nobody wants it, the currency has a negative value.
This ERC uses a smart contract to emulate an anti-currency on the Ethereum ecosystem.
Motivation
An antitoken can be used to represent debt, bad reputation, or anything negative in relation to its owner.
The incentive is to spend it and to have a balance of zero.
Technical specification and reference implementation
See Pull request #3476
Your feedback is appreciated 
Q/A
What prevents me from receiving the token on a random address I own?
This operation would be visible on the blockchain.
Also, the contract MAY only allow transfers to known addresses.
Title: ERC_7816__Schnorr_Signatures_for_EVM_Applications
Category: ERCs

Author: merkleplant
Date: 2024-11-09T15:44:11.391Z

Discussion topic for ERC-7816: Add ERC: Schnorr Signatures for EVM Applications by pmerkleplant · Pull Request #713 · ethereum/ERCs · GitHub
Update Log

2024-11-09: Initial draft
2024-12-12: Updated title and sections order to conform to ERC guidelines

External Reviews
None as of 2024-11-09.
Outstanding Issues

 2024-11-09: Provide test cases

Author: merkleplant
Date: 2024-11-09T15:48:24.356Z

For some more background information, see GitHub - verklegarden/schnorr-on-evm: A Schnorr Signature Scheme for EVM Applications.

Author: StackOverflowExcept1
Date: 2024-11-10T15:59:44.206Z

I experimented a bit with applications of this ERC, FROST from Zcash Foundation and ROAST. I managed to write very cheap threshold signature. It only costs ~4200 gas to verify threshold signature t of n onchain, plus ~2100 gas for calldata. See repository for more information: GitHub - StackOverflowExcept1on/frost-secp256k1-evm: Cheap threshold signature scheme for EVM. I also made PR at Zcash Foundation that adds an efficient cipher suite for EVM: feat: add `frost-secp256k1-evm` crate by StackOverflowExcept1on · Pull Request #749 · ZcashFoundation/frost · GitHub. Based on audited cryptography from Zcash Foundation, I was also able to build an implementation of ROAST protocol (FROST protocol that is suitable for signing messages in asynchronous networks): GitHub - StackOverflowExcept1on/roast: Rust implementation of ROAST (Robust Asynchronous Schnorr Threshold Signatures) with cryptography by Zcash Foundation. The only downside of these Schnorr-based threshold signatures is that FROST is an interactive protocol. But these signatures are very cheap to use them in decentralized applications that are governed by an honest majority.
Title: Delegator_Extension_That_Enables_ERC721_to_be_loan
Category: ERCs

Author: AFKDAO
Date: 2022-01-04T19:08:42.689Z

Hi there.
ERC721 is widely used in blockchain games. I think it’s good to NFTized game accounts and game equipment so that users can own their own assets. However, I don’t think it’s a good experience for every player to buy an NFT before playing the game. Sometimes we just want to try the game. Under such circumstances, if we can borrow NFT to play the game in a safe and convenient way, the experience will be much better.
In order to solve this problem, I thought of a method, that is, add a delegator extension to ERC721. Specifically, like the following code.
mapping(uint256 => address) private _delegators;
function setDelegator(address delegator, uint256 tokenId)
If I want to borrow an NFT from you, you just set me as the delegator of your NFT. It’s safe for you to do it, cause I don’t have any permission to transfer or approve your NFT.
What a delegator can do is defined by the game developers, or the utility NFT developers. If developers are willing to adopt this extension, they need to add the identification and processing of the delegator in the code.
I will develop specific implementations and examples in the next. I would also like to get feedback from everyone

Author: Daniel-K-Ivanov
Date: 2022-02-07T10:56:29.218Z

Hi AFKDAO,
I am glad that you have noticed the same need for explicit role for NFTs to address renting of ERC721s. Your proposal seems very similar to what I have described and has been merged as EIP4400.
You can add your comments/thoughts in the Discussion section here and lets see whether the proposed EIP4400 fulfils your needs:



ERC-4400: ERC-721 Consumer Extension Tokens


Abstract
This specification defines standard functions outlining a consumer role for instance(s) 
of ERC-721. An implementation allows reading the current consumer for a 
given NFT (tokenId) along with a standardized event for when an consumer has changed. The proposal depends on and 
extends the existing ERC-721. 

Motivation
Many ERC-721 contracts introduce their own custom role that grants permissions 
for utilising/consuming a given NFT instance. The need for that role stems from the fact t…
  

I will update the EIP in the coming days with the new feedback that we have received from the community.
Title: ERC_7655__ERC_5189_operation_receipts
Category: ERCs

Author: naivesheep
Date: 2024-03-13T15:46:06.377Z

This ERC is intended to address the issue of obtaining operation receipts in ERC-5189, which is an application layer account abstraction proposal that maintains compatibility with existing smart contract wallets.
https://github.com/ethereum/ERCs/pull/318
Title: ERC_721__safeTransferFrom_function__Modification_i
Category: ERCs

Author: serCorp
Date: 2021-12-06T09:03:50.358Z

Hi all,
Concerning the ERC721.sol safeTransferFrom function, I propose to move the code line and invert the require by the call to transferFrom:
Current code:
function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public {
transferFrom(from, to, tokenId);
require(_checkOnERC721Received(from, to, tokenId, data), “ERC721: transfer to non ERC721Receiver implementer”);
}
I propose:
function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public {
require(_checkOnERC721Received(from, to, tokenId, data), “ERC721: transfer to non ERC721Receiver implementer”);
transferFrom(from, to, tokenId);**
}
In my point of view, the require must be always before the call to any function that should be called if the require is confirmed.
Thanks!
Sergio
Title: ERC_7694__Solana_Storage_Router
Category: ERCs

Author: sshmatrix
Date: 2024-04-18T15:35:10.725Z

This standard is an extension to EIP-7700 introducing storage router for Solana. EIP-7700 introduces three external routers for deferring storage to L1, L2s and databases. This document extends that specification by introducing a fourth storage router targeting Solana as the storage provider.
Solana is a cheap L1 solution that is fairly popular among Ethereum community and is widely supported alongside Ethereum by almost all wallet providers. There are several chain-agnostic protocols on Ethereum which could benefit from direct access to Solana blockspace; ENS is one such example where it can serve users of Solana via its chain-agnostic properties while also using Solana’s own native storage. This development will surely encourage more cross-chain functionalities between Ethereum and Solana at core.
ERC Link: ERCs/ERCS/erc-7694.md at solanaHandler · namesys-eth/ERCs · GitHub
Happy to hear comments & feedback.

Author: SamWilsn
Date: 2024-10-01T14:46:58.794Z

Hey! I have a non-editorial related question about your proposal. ERC-3668 includes a section on Gateway Response Data Validation. Should ERC-7694 include an algorithm/method/standard approach for doing data validation against the Solana blockchain? Something like a Solana lightclient in the EVM perhaps?
Title: ERC_7821__Minimal_Batch_Executor_Interface
Category: ERCs

Author: Vectorized
Date: 2024-11-21T00:37:54.307Z

Motivation
With the advent of EIP-7702, it is possible for Externally Owned Account (EOA) to perform atomic batched executions.
We anticipate that there will be multiple EIP-7702 delegation accounts from multiple vendors. To enable frontends to be able to detect and prepare a batched transaction that works across multiple vendors, we will need a standardized interface for batched executions.
In the absence of such a standard, the vendors may choose to create their own proprietary implementations, causing ecosystem fragmentation.
This standard propose a minimal batch execution interface that is easily implementable, extensible, and performant. It also includes a signalling function for tell frontends that the account supports the standard.
Reference Implementation
A optimized implementation is available in Solady.
The ERC proposal has a more readable implementation.

Author: wjmelements
Date: 2024-11-21T02:26:40.465Z

Vectorized:

This standard propose a minimal batch execution interface that is easily implementable, extensible, and performant.


Actually, concatenation is the most extensible and performant batch ABI.

Author: ernestognw
Date: 2024-12-29T23:18:44.158Z

Hi @Vectorized,
I like the minimal approach of the ERC, and I believe it can be a default minimal batch execution interface not only for EOAs via ERC-7702 but also for other ERC-4337 accounts.
For example, a simple ERC-4337 account may implement ERC-7821 instead of the IAccountExecute interface. I see it was recently changed to allow msg.sender to be the entrypoint, which is great.
Some concrete feedback

ERC-7579 dropped the requirement for ERC-165 so I don’t think ERC-7821 needs to be explicit about it
The standard is not clear whether replacing address(0) with address(this) is mandatory. I would say it’s a “MAY” but feel free to correct me.

Opening a PR with this feedback if you think makes sense

Author: chaitanyapotti
Date: 2025-01-06T23:34:52.354Z

Created a small PR #829 to fix reference implementation

Author: mcoso
Date: 2025-02-03T18:53:59.319Z

added a PR to match the Call struct to the ERC-7579 Execution struct PR
Title: ERC_7622__Pre_Authorized_Service_Payment_Protocol
Category: ERCs

Author: bizliaoyuan
Date: 2024-02-10T12:54:19.192Z

https://github.com/ethereum/ERCs/pull/252
Abstract
This proposal introduces a protocol for implementing pre-authorization capabilities in ERC-20 token payments, while simultaneously facilitating the aggregation of token funds. Users deposit ERC-20 tokens into the contract, acquiring a total authorized balance that can be distributed to various service providers for expenditure. The protocol empowers users to pre-authorize specific service providers to deduct funds up to a predetermined limit, ensuring seamless and secure transactions. Additionally, users retain the ability to withdraw unutilized authorized balances, modify, or revoke authorizations for specific service providers as needed. Through this framework, the protocol enhances the efficiency, security, and flexibility of ERC-20 token payments within decentralized applications.
Motivation
In the current Ethereum ecosystem, users encounter the inconvenience of needing to manually confirm each transaction when transferring funds to third parties. This becomes particularly cumbersome for services necessitating frequent micro-payments. Additionally, in certain DApps, there’s a desire to obtain user fund authorizations without relying on ERC-20’s approve method. This reluctance stems from the fact that approve does not involve placing funds in a trusted third-party entity.
To address this concern, there’s a proposal to introduce a third-party contract capable of receiving and managing authorized funds. These third-party entities could include reputable organizations, such as charities or authoritative institutions. By channeling authorized funds into a dedicated pool, these entities could generate charitable returns or facilitate community benefits.
Furthermore, there’s potential to implement governance mechanisms, such as DAO governance or transparent public oversight, for managing the list of authorized service providers. This would enhance trust and transparency, allowing users to dynamically manage their authorizations while ensuring the integrity of the service provider ecosystem. Through these enhancements, the proposed Pre-Authorized Service Payment Protocol not only streamlines transaction processes but also fosters trust, transparency, and community engagement within the Ethereum ecosystem.
Specification
The protocol specifies the following key functionalities:

registerServiceProvider(address serviceProvider): Allows service providers to register themselves.
deregisterServiceProvider(address serviceProvider): Allows service providers to deregister themselves.
authorizeServiceProvider(address serviceProvider, uint256 amount): Allows users to pre-authorize a specified amount of tokens to a service provider.
revokeAuthorization(address serviceProvider): Allows users to revoke the pre-authorization given to a service provider.
deductFunds(address user, uint256 amount): Enables service providers to deduct funds from a user’s account based on the authorization.
Title: ERC_7798__Tap_to_Pay
Category: ERCs

Author: amhed
Date: 2024-10-29T17:11:31.419Z

This ERC defines a standard for contactless payment transactions that can allow for interoperable customer to merchant onchain payments, regardless of the wallets the customer and merchant are using.
Comprised of three parts:

A new Ethereum Provider JavaScript API method called requestContactlessPayment
An agreement on the payload for data exchange between the parties
An optional mechanism for relaying large JSON payloads using a backend relayer



github.com/ethereum/ERCs








Add ERC: Tap to Pay


master ← amhed:erc-taptopay



          opened 01:51AM - 26 Oct 24 UTC




            amhed
          



+200
-0






See https://hackmd.io/VyxIMlk1SvCOpBpS6a_2uA?both for initial commentary on the …standard

Author: hellohanchen
Date: 2024-11-04T08:05:39.839Z

How is this compatible with account abstraction?

Author: amhed
Date: 2024-11-04T14:45:30.067Z

This would just be a mechanism for signaling the intent of paying over NFC, the signing or account format is irrelevant for this specific standard

Author: radek
Date: 2024-11-06T22:32:52.397Z

How do you pass the intention reference and further reconcile the payment with that intention?
We have created ERC-7699 for the ERC20 for that, but welcome any other suggestions.
Title: ERC_7714__Simple_Permissions_Checks
Category: ERCs

Author: jeroen
Date: 2024-07-08T08:39:10.621Z

Discussion for  Add ERC: Simple Permissions Checks #435