Diegorb1329/eth_magicians_forum huggingface dataset:
Title: EIP_7915__Adaptive_mean_reversion_blob_pricing
Category: EIPs

Author: aelowsson
Date: 2025-03-24T04:33:55.330Z

Discussion topic for EIP-7915; PR.
Abstract
Reworks the excess blob gas update in calc_excess_blob_gas() so that the blob base fee rises relatively more during high gas usage than it falls during low usage whenever the current fee is below the long-run average. This establishes a smoothly adapting, neutral lower bound for the base fee. The exponential moving average (EMA) is computed in the linear domain and stored as a header variable.
Motivation
Demand for blobspace is fee-inelastic, leading to a blob base fee that may fluctuate excessively with minor shifts in aggregate demand. The lower end of the fee range of 1 wei is under current circumstances economically inconsequential, but can be reached after a period of blocks consuming fewer blobs than the target. During increases in demand, the existing fee mechanism requires sustained periods of near-full blocks to re-establish equilibrium. This exacerbates spikiness in resource consumption, which can hamper efficient scaling of throughput. Furthermore, users may intermittently need to compete in a first-price auction for inclusion, degrading UX. The appropriate fee range will inadvertently vary going forward due to changes in the ETH token price and circulating supply, as well as the protocol’s ability to scale throughput. To remain neutral and future-proof, the operational range should be established relative to the long-run average fee, smoothly adjusting equilibrium quantity of blobs consumed. Thus, this EIP introduces a new fee update mechanism that accounts for the long-run average fee when responding to shifts in demand. This allows the protocol to quickly converge to desirable equilibria while also remaining neutral and future-proof.
Figure 12662×1984 262 KB
Figure 1. Response to various blob quantities for the proposed fee mechanism (green), the current mechanism (black), and a threshold mechanism (red). The mechanism smoothly converges to appropriate equilibria when demand shifts, establishing the fee relative to the long-run average base fee (at 4 gwei in this example). The fee adapts faster when converging toward the average from below than when diverging from it.
Title: EIP_7843__SLOT_precompile
Category: EIPs

Author: marchhill
Date: 2024-12-16T08:24:22.281Z

Discussion thread for Add EIP: SLOT precompile by Marchhill · Pull Request #9141 · ethereum/EIPs · GitHub

This EIP proposes to add a new precompile that returns the corresponding slot for the current block.
It is currently possible to calculate the slot number from the block timestamp. However, this requires hardcoding the chain slot length into a smart contract. This would require the contract code to be changed in the event of a future change to slot length. A better approach is for the slot number to be calculated by the execution layer and exposed in a precompile.
This precompile aims to improve support for encrypted mempools. In order to be secure, the validity of encrypted mempool transactions should be tied to the inclusion of all transactions by a proposer in the correct slot. This rule can be enforced by a smart contract using this precompile.

Author: suchapalaver
Date: 2024-12-26T00:43:27.745Z

Sharing a use case for this in support of the discussion: Verifying execution layer data with reference to the Beacon Chain requires calculating the Beacon Chain slot containing the execution layer block in its Execution Payload. The Beacon Chain provides the cryptographic primitives required to prove the inclusion of execution layer data in the canonical history of the chain but the first hurdle is matching an execution layer block to its Beacon Chain counterpart.

Author: ralexstokes
Date: 2025-02-19T23:59:57.593Z

another option here would be to just compute the slot off-chain, pass it in to the smart contract in the calldata, and authenticate with EIP-4788
no new protocol functionality needed

Author: marchhill
Date: 2025-02-20T10:35:49.671Z

Yes this is possible but much more expensive than using the precompile which costs 2 gas. I think it is more likely that people would end up using the hacky way (calculating from timestamp) rather than this more expensive way; ideally we want to make the right way cheap.
Another advantage of this EIP is that it exposes the slot number to the EL. In Nethermind we currently need the slot number for building Shutter blocks, it’s likely other clients will too in future. Rather than calculating from the timestamp in the EL, I think that the CL should serve as the source of truth for the slot number.
Overall this EIP is not making something new possible, but making something that is already possible cleaner and cheaper. It could also save us time down the line if we want to change the slot length.
Title: EIP_7932__Algorithmic_Transaction_Wrapper
Category: EIPs

Author: SirSpudlington
Date: 2025-04-13T11:58:53.423Z

Discussion topic for EIP-7932 GitHub PR
This EIP introduces a new EIP-2718 typed transaction that wraps (contains) another transaction, this EIP nullifies the default signature parameters and appends signature data to the front of the transaction with a selector, this effectively wraps a transaction and swaps out signature data for alternative algorithms and data. It also creates a new precompile to be able to decode these additional signature algorithms.
Update Log

2025-04-12: initial draft PR

External Reviews

2025-04-12: PR Review from jochem-brouwer, link to review
2025-04-13: PR Review from bomanaps, link to review
2025-04-15: PR Review from SamWilsn, link unavailable, please use PR link above.

Outstanding Issues
None as of 2025-04-12.

Author: SamWilsn
Date: 2025-04-15T16:33:50.330Z

EIP-7702 defines a transaction type with nested signatures. You should probably explain how 7702 and this proposal interact.

Author: SamWilsn
Date: 2025-04-15T16:37:45.259Z

I’d extend this proposal with support for patching ecrecover as well. Fixing the outer transaction signature without fixing ecrecover will only solve part of the PQ problem.
One approach that’s been tossed around is to embed a list of tuples in the transaction that contain a mapping from the ecrecover arguments to the real signature/algorithm data. I haven’t thought that through entirely, but hopefully it’s a starting point.

Author: SirSpudlington
Date: 2025-04-15T20:43:02.883Z

The EIP-7702 problem was solved by adding space for additional signatures after the transaction, I don’t know how practical this would be but it was one of my better solutions. (edit: I also added the NULL algorithm for edge cases where the initial signature is secp256k1 but the others are not)
I also patched ecrecover instead of using a mapping as that seemed a bit too complex, I made any v recovery value v > 0xFF && v <= 0xFFFF trigger the contract to be treated as an Algorithmic. Might still need to work on the name, but for now Algorithmic transaction rolls of the tounge. I am going to introduce a new precompile, with a name similar to sigrecover as the “overload the v value” seemed somewhat hacky and may break some implementations.
Title: EIP_7797__Double_speed_for_hash_tree_root
Category: EIPs

Author: etan-status
Date: 2024-10-23T15:51:22.010Z

Discussion topic for EIP-7797 EIP-7797: Double speed for hash_tree_root
Update Log

2024-10-23: initial draft https://github.com/ethereum/EIPs/pull/8995/files

External Reviews
None as of 2024-10-23.
Outstanding Issues

 2024-10-23: Security analysis
 2024-10-23: Determine all locations where historical hashes are needed
 2024-10-31: Reference test vectors to measure timings across impls

Author: etan-status
Date: 2025-03-31T14:26:13.218Z

EIP-7797 Compress function instead of SHA256 could btw be integrated by re-interpreting the existing SSZ binary tree as a 4-way tree that supplies the current children as elements 0+1 and then supplies second round SHA constant as elements 2+3. That way, historical trees could be transformed without changing the hashes, and newer SSZ types (StableContainer / ProgressiveList) could actually be hashed by combining 4 elements at a time instead of 2 elements. Advantage being that no new proof format is required. One could supply the SHA-256 2nd round constant as additional branches as if it was actually part of the tree, then verify using the compress function.
Title: BITE_Protocol__On_Chain_Decryption_via_Precompiled
Category: EIPs

Author: kladkogex
Date: 2025-04-24T12:01:27.495Z

Hey folks
At SKALE we are developing BITE( Blockchain Integrated Threshold Encryption) where the current PoS validator committee is also a Threshold Encryption committee
In addition to provably eliminating MEV, one compelling direction for BITE is enabling smart contracts to perform on-chain decryption via a precompiled contract.
This would allow Threshold Encryption (TE) to become a native primitive in the EVM, making advanced coordination, privacy, and game-theoretic mechanisms not just possible—but practical.

 Use Case 1: Multiplayer Rock-Paper-Scissors (RPS)
In a 3-player RPS game, each player submits an encrypted move (Rock, Paper, or Scissors). Once all encrypted moves are collected:

The contract calls a decryption precompile to simultaneously decrypt all inputs.
This guarantees a fair reveal—no player can adjust their move after seeing others.


 Use Case 2: Sealed-Bid Auctions
Participants submit encrypted bids on-chain.

After the smart contract collects all submissions, a precompiled decryption function is invoked.
All bids are decrypted at once, enabling a trustless, fair reveal.

This eliminates the need for off-chain reveal phases and complex timeout logic.

 Why a Precompiled Contract?

Security: Deterministic, on-chain decryption avoids front-running and malicious reveals.
Simplicity: Reduces reliance on off-chain coordination or multi-transaction workflows.


bytes plaintext = DecryptPrecompile.decrypt(bytes ciphertext);

The ciphertext would be encrypted using the current TE committee public key and decrypted using the current TE committee
 Impact
If implemented, this would unlock a wide range of privacy-preserving, game-theoretic, and multi-party coordination applications on-chain—many of which are currently impractical due to the lack of synchronous, verifiable secret handling in Solidity.

Would love to hear thoughts on:

Precompile feasibility and gas cost targets
Threshold decryption protocols best suited for this use
Real-world dApps this would enable

Looking forward to feedback from the community!
Title: EIP1185__DNS_resolver_profile_for_ENS
Category: EIPs

Author: mcdee
Date: 2018-10-15T14:52:30.835Z

I’ve created EIP 1185 which describes an ENS resolver profile for ENS.  This allows DNS resolvers to obtain information about ENS, and is used in EthDNS to resolve DNS records in Ethereum transparently.  Comments welcome.
Link to the EIP: https://github.com/ethereum/EIPs/edit/master/EIPS/eip-137.md
Explanation of EthDNS: https://medium.com/@jgm.orinoco/ethdns-an-ethereum-backend-for-the-domain-name-system-d52dabd904b3

Author: sbacha
Date: 2022-09-07T08:38:06.726Z

Hello, is there any interest in reviving this proposed EIP? Am very interested in it!

Author: xinbenlv
Date: 2024-12-25T19:42:06.643Z

Hi Jim,
Thank you for this important ERC.
It took me a while to get to review this. Here is a few comments from my early feedback
Editorial Suggestions

Consider adding in the specification the ERC-165 (supportsInterface), which you already using in ref-impl
Consider making setZonehash/zonehash optional interfaces in the requirement
In Security Consideration, consider mentioning the importance of authorised(node) and its implication if done wrong.
Since CoreDNS ENS Plugin supports these implementation, have you considered mentioning the CoreDNS ENS plugin and its reading side of code in GoLang?

Technical discussions

How do you envision  the DNS TTL being set and handled? Could you ellaborate it in the ref-impl section
Have you considered specific way to supply DNSSEC keys when it has more implications?
Title: EIP_7790__Parameters_to_increase_the_gas_limit
Category: EIPs

Author: Giulio2002
Date: 2024-10-22T16:40:14.030Z

This EIP proposes increasing the gas limit through EIP7783 in the span of 2 years from 30 to 60 million. starting in february 2025.

After 6 months: Gas Limit = 37.5 Mn
After 12 months: Gas Limit = 45 Mn
After 18 months: Gas Limit = 52.5 Mn
After 24 months: Gas Limit = 60 Mn

Author: wjmelements
Date: 2024-10-24T10:13:26.947Z

We don’t need an EIP to raise the gas limit. The gas limit is dynamic. Each block votes the limit up or down. It’s at 30m right now because of consensus.

Author: Giulio2002
Date: 2024-10-24T19:12:02.830Z

It’s an informational proposal so - it is still valid

Author: SamWilsn
Date: 2024-12-18T19:09:34.347Z

I’d suggest merging this with EIP-7783: Add Controlled Gas Limit Increase Strategy and withdrawing it.
The newly combined proposal could be considered Standards Track / Core (from EIP-1):

changes that are not necessarily consensus critical but may be relevant to “core dev” discussions

I’d also be fine with Informational, especially if another Editor suggested that category.
Title: EIP_7666__EVM_ify_the_identity_precompile
Category: EIPs

Author: vbuterin
Date: 2024-03-31T04:41:28.078Z

Remove the identity precompile at 0x04. At the start of executing the block in which this change activates, put into that contract a short piece of EVM code that has the same functionality.
https://github.com/ethereum/EIPs/pull/8366

Author: jochem-brouwer
Date: 2025-01-17T21:44:22.800Z

Gas costs are slightly different, though gas repricings have been done in the Ethereum ecosystem several times before and their effects are well understood.

I think “gas costs are slightly different” is a bit of a shortcut here. The identity precompile has linear gas costs, while the proposed bytecode is definitely quadratic since it dumps the calldata in memory. So, for larger inputs, the gas cost is definitely different and also scales differently.
EIP-3855: PUSH0 instruction (PUSH0) should be added to required EIPs, otherwise the bytecode will run into INVALID opcodes.

Starting from and including that block, IDENTITY_PRECOMPILE_ADDRESS should no longer be treated as a precompile.

Interesting point, this removes it from the “always warm addresses” for EIP-2929 gas accounting. Also, EIP-7702 accounts pointed to this precompile, should now thus run the bytecode instead of treating it as an account with no code.

Author: jochem-brouwer
Date: 2025-04-20T16:21:25.462Z

Can this mini-update for correctness be merged? @vbuterin Update EIP-7666: Add required PUSH0 EIP by jochem-brouwer · Pull Request #9165 · ethereum/EIPs · GitHub
Title: EIP_7934__Add_bytesize_limit_to_blocks
Category: EIPs

Author: Giulio2002
Date: 2025-04-17T21:43:49.059Z

This proposal introduces a protocol-level cap on the maximum RLP-encoded execution block size to 10 megabytes (MB), which includes a margin of 512 KB to account for beacon block sizes.
Motivation
Currently, Ethereum does not enforce a strict upper limit on the encoded size of blocks. This lack of constraint can result in:

Network Instability: Extremely large blocks slow down propagation and increase the risk of temporary forks and reorgs.
DoS Risks: Malicious actors could generate exceptionally large blocks to disrupt network performance.

Additionally, blocks exceeding 10 MB are not propagated by the consensus layer’s (CL) gossip protocol, potentially causing network fragmentation or denial-of-service (DoS) conditions.
By imposing a protocol-level limit on the RLP-encoded block size, Ethereum can ensure enhanced resilience against targeted attacks on block validation times. Adding an additional margin of 512 KB explicitly accommodates beacon block sizes, ensuring compatibility across network components.

Author: wjmelements
Date: 2025-04-18T17:54:34.036Z

I’m generally opposed to separate caps for separate resources as it complicates block building. We already have gas metering to constrain resource usage on every dimension. Large blocks with little execution aren’t especially worse than small ones with lots of execution; they both tax the network in different ways. The block gas limit already sets a size cap on blocks, and it can be increased without a hard fork. Your proposal would require a hard fork for future increases, which could give Ethereum the same ossification problem Bitcoin has right now. We will never know for sure if the last hard fork was the last ever.



 Giulio2002:

blocks exceeding 10 MB are not propagated by the consensus layer’s (CL) gossip protocol, potentially causing network fragmentation or denial-of-service (DoS) conditions.


Why don’t you fix this problem instead?

Author: SirSpudlington
Date: 2025-04-18T21:58:42.151Z

Looking at Etherscan the highest block size ever was about 300 KiB, would there really need to be a 10MB limit? It seems like gas is already a soft-limit by itself and I don’t know whether a hard limit would be practical.



 Giulio2002:

DoS Risks: Malicious actors could generate exceptionally large blocks to disrupt network performance.


How would this be possible? With current calldata costs the upper bound to a blocks size is ~6MiB AFAIK. Either a malicious actor would have to include valid transactions from others, which is not malicious, or spend a significant amount of ETH to pay for these large transactions.
Title: EIP_1776___ERC20DAO___Extend_any_DAO_framework_for
Category: EIPs

Author: j0xhn
Date: 2022-01-23T06:11:52.081Z

Minimum viable DAOs for easy integration into various governance models that encourages a “Bring Your Own Governance” mentality.  The basic understanding being that we empower an admin to legally enact updates to token balances and NFT information as agreed upon by DAO.
This can be extended in many ways across other DAO models and adopts a set of naming patterns to extend systems default functions with their admin equivalents by appending “_admin” to all functions - in essence creating a “getter/setter” pattern that any other governance standard can integrate with.


github.com


DAOhaus/EIPs/blob/master/EIPS/eip-1776.md
---
eip: 1776 
title: Legal Governance Token Standard
description: Requires that a contract has an "owner", and that this owner has access to applicable functions so that it may easily enact the will of the DAO both on and off chain in any jurisdiction.
author: John D Storey (@j0xhn)
status: Draft 
discussions-to: https://ethereum-magicians.org/t/eip-1776-erc20dao-extend-any-dao-framework-for-compliance-with-local-legal-jurisdictions
type: Standards Track
category: ERC
created: 2022-02-20
requires: 20 / 173
---

## Abstract
While there will be many DAO token standards and patterns to come, this will allow each one to be connected with a trusted third party -- for example a laywer to carry out the will of the DAO -- without requiring all to have the same underlying governance structure. Empowering a sort of "Bring Your Own Governance" mentality.

## Motivation
Introducing this legal link is a crucial component for the governance of real world assets.  When paired with local jurisdictions will give the ability of a DAO to do real world actions such as list an item for sale, coordinate transportation or handle other "in-person" tasks on behalf of the digital DAO.

## Specification




  This file has been truncated. show original

Author: thxdao
Date: 2025-04-09T15:01:09.717Z

love to learn more about this concept!
Title: System_level_transactions_and_bypassing_EVM_execut
Category: EIPs

Author: OlivierBBB
Date: 2025-04-13T16:03:53.116Z

AFAICT there are currently two system transaction EIPs

EIP-4788: Beacon block root in the EVM (Cancun)
EIP-2935: Serve historical block hashes from state (Prague, as of https://notes.ethereum.org/@ethpandaops/pectra-devnet-6)

Both feature a note about how execution clients may bypass EVM execution. From the Block processing section of EIP 2935:

Note: Alternatively clients can choose to directly write to the storage of the contract but EVM calling the contract remains preferred. Refer to the rationale for more info.

and from the Block processing section of EIP 4788:

Clients may decide to omit an explicit EVM call and directly set the storage values. Note: While this is a valid optimization for Ethereum mainnet, it could be problematic on non-mainnet situations in case a different contract is used.

It is of note that the set of authors of these two EIPs are disjoint.

I have some related questions:

Is there an explicitly spelled out expectation that with future system level transactions EIPs clients should also be able to bypass EVM execution, as they are currently ?
Is there an explicitly spelled out expectation that future system future level transactions should also be executed before (standard) transaction processing ?

I would also be curious to find out if there are more system level transaction EIPs in the works besides the two I cite. Thank you.
Title: _wallet_sendCalls__Capability__Flow_Control
Category: EIPs

Author: SamWilsn
Date: 2025-01-22T19:09:00.171Z

Discussion topic for EIP-XXXX 
Update Log

2025-01-22: initial draft Add EIP: Flow Control Wallet Call Capability by SamWilsn · Pull Request #9259 · ethereum/EIPs · GitHub
Title: EIP_7886__Delayed_Execution
Category: EIPs

Author: Nerolation
Date: 2025-02-18T10:20:55.428Z

Discussion topic for EIP-7886: Delayed Execution
Update Log


2025-02-04: EELS Specs implementation.
2025-02-05: Ethresearch Post on Delayed Execution.
2025-02-18: Initial draft


External Reviews
TBD
Outstanding Issues
None as of 2025-02-18.
Title: EIP_7840__Add_blob_schedule_to_execution_client_co
Category: EIPs

Author: matt
Date: 2024-12-12T15:18:34.268Z

Adds a new object to the EL genesis chain config:
of the shape:
"blobSchedule": {
  "prague": { "target": 6, "max": 9 },
  "osaka":   { "target": 12, "max": 16},
  ...
}



github.com/ethereum/EIPs








Add EIP: Add blob schedule to EL config files


master ← lightclient:blob-config



          opened 03:17PM - 12 Dec 24 UTC




            lightclient
          



+69
-0






Adds a new object to the EL genesis chain config:

of the shape:

```json
"…blobSchedule": {
  "prague": { "target": 6, "max": 9 },
  "osaka":   { "target": 12, "max": 16},
  ...
}
```

Author: jochem-brouwer
Date: 2025-01-06T17:15:08.856Z

Is the genesis chain config specified anywhere? I don’t think it is standardized anywhere but most clients need to import the same config, so I guess this naturally evolves to some kind of standard config file?
Maybe it would be a good idea to specify these genesis / chain spec files somewhere (if this is not yet done) then additions to this config file can then be added to this specification.

Author: matt
Date: 2025-01-06T17:26:39.011Z

it isn’t defined officially anywhere AFAIK.

Author: jochem-brouwer
Date: 2025-01-06T23:24:03.733Z

I think we should spec it out. What would be a good location for this spec?

Author: matt
Date: 2025-01-07T13:57:10.634Z

It’s tough because EIPs aren’t the best suited for specs that are change regularly. We’ve gotten around this for the RPC by creating execution-specs repo. I think something like genesis-specs might be the right way. I would probably check with the ethpandaops team as they are kinda the premiere genesis creator / consumer.

Author: jochem-brouwer
Date: 2025-01-09T22:07:57.021Z

Cool, I was thinking along the same lines, something like execution-apis or execution-specs comes close but does not feel like the right place. I agree that a new repo like genesis-specs would be the “right” place for this. I’ll contact ethpandaops sometime in the near future about this.

Author: rjl493456442
Date: 2025-01-24T07:25:03.271Z

Is there any specific reason to define this in the chain configuration instead of hardcoding it?
The EIP states:

Ensure there is a way to dynamically adjust the target and max blob counts per block.

However, in practice, these constants are only updated during hard forks. Coordinating a constant change without a hard fork via the configuration file is extremely challenging.
Probably we want to define different parameters for different networks?

Author: matt
Date: 2025-01-24T13:45:00.073Z

In particular, we want the ability to test different blob counts on test networks. If we hard code it, it’s quite difficult to try different configurations across clients.
Title: EIP_7885___Precompile_for_NTT_operations
Category: EIPs

Author: rdubois-crypto
Date: 2025-02-18T14:16:06.222Z

Discussion topic for EIP-9374
Abstract
Implement a generic polynomial NTT precompile to speed-up all lattices post quantum signature candidates and Starks settlement.
Post quantum threat is one of the concern regarding Ethereum security. Lattices candidates are
seen as potential replacement for ECDSA. This precompile enables efficient implementation of those candidates without having to fix the choice too early. It also reduce gas cost for STARK settlement.
Update Log

2025-02-18: initial draft 
2025-02-18: ethereum research post : NTT as PostQuantum and Starks settlements helper precompile - Ethereum Research

External Reviews
Outstanding Issues
None as of 2025-02-18
Title: EIP_7935__Set_default_gas_limit_to_XX0M
Category: EIPs

Author: sophia
Date: 2025-04-23T17:04:59.753Z

EL client devs should test higher gas limits, recommend a new one that is safe, and update their default configs to use this value with their Fusaka releases.


github.com/ethereum/EIPs








Add gas limit increase EIP


master ← Sophia-Gold:gas-limit-testing



          opened 04:03AM - 23 Apr 25 UTC




            Sophia-Gold
          



+40
-0






EIP to recommend a new gas limit by the time Fusaka is released and update EL de…fault configs.

Author: MicahZoltu
Date: 2025-05-04T09:31:44.271Z

This EIP needs an actual gas limit proposal set before it can be usefully discussed.  At the moment it is basically just a placeholder saying “we should do something” without actually specifying what should be done.
The discussion is wildly different if this proposal is suggesting changing the default to 36M vs 1B and without an actual gas limit proposal everyone will just be straw manning each other and productive conversation will be extremely difficult.

Author: MicahZoltu
Date: 2025-05-08T08:19:01.098Z

This EIP should include mention of the effects that increased block sizes will have on all users of Ethereum, not only validators/builders.  I believe RPC nodes handle the vast majority of the work that Ethereum clients do, and they are arguably the most important nodes on the network as it is what roots trust of the system on end-users, yet this EIP nor most of the discussion around gas limit increases talks at all about how gas limit increases will affect those nodes.  Archive nodes should also be discussed and analyzed as well.
Title: IDEA__Supply_cap___dynamic_block_reward_based_on_a
Category: EIPs

Author: SoundMoney
Date: 2022-08-07T23:06:29.028Z

There is a lot of excitement around the “ultra sound money” meme, the idea that Ethereum might become deflationary after the issuance reduction that will coincide with the merge (aka the “triple halvening”). Based on my research, Ethereum will be deflationary if gas prices stay at or below 7 gwei.
While I understand the excitement, I believe that Ethereum would be a better form of money if it had a predictable (net) issuance like Bitcoin. Personally I’d prefer holding a currency with an absolute supply cap over a currency that will probably have a net negative issuance but that does not have an explicit supply cap. In other words, I’d prefer holding an asset that is definitely not inflationary over an asset that will probably be deflationary. The fact that only 21 million Bitcoin can ever exist is an incredibly strong meme. In my opinion, the most sound money would have an issuance of zero, neither negative, nor positive. Moreover, it is difficult to denominate debt in a currency with negative expected issuance.
I propose the following:

Reduce issuance to 0
Compensate miners using the current EIP-1559 burns (I’ll refer to them as base fees), in addition to priority fees
Stabilize the block reward by allocating base fees to a base fee reserve, and assign 1/N of the reserve to the validators of the block

Example:
N = 1000 (this could also be much larger to smoothen out base fee rewards even more)
Assume base fee reserve is 2000 ETH at block T
Block T+1:
Total base fees in that block: 2
Validator base fee rewards: (2000 + 2)/1000 = 2.002
New base fee reserve: 2000 + 2 - 2.002 = 1999.998
Block T+2:
Total base fees in that block: 3
Validator base fee rewards: (1999.998 + 3)/1000 = 2.003
New base fee reserve: 1999.998 + 3 - 2.003 = 2000.995
Block T+3:
Total base fees in that block: 0
Validator base fee rewards: 2000.995/1000 = 2.001
New base fee reserve: 2000.995 - 2.001 = 1998.994
I would probably also allocate slashing penalties to honest validators, but I left those out for now to keep the proposal simple.
Would love to hear your thoughts on the general idea of a supply cap and this mechanism.

Author: phi1
Date: 2024-12-27T23:00:11.637Z

I love this because I had a similar thought and wondered if anyone had started this idea yet.
In a nutshell…

Create a Max Supply of either where we’re at at the moment (roughly 120M Ether) or 126M Ether, which is equal to 6x Bitcoins 21M.
Reward the validators with all of the fees, so nothing is burnt.
Title: EIP_7928__Block_Level_Access_Lists
Category: EIPs

Author: Nerolation
Date: 2025-04-01T10:22:06.019Z

Discussion topic for EIP-7928: https://github.com/ethereum/EIPs/pull/9580
Update Log

2025-04-01: Initial Commit
2025-04-22: Discord Channel
2025-04-23: Design Space Exploration

External Reviews
TBD
Outstanding Issues
TBD

Author: dajuguan
Date: 2025-04-17T16:09:52.272Z

We ran some initial benchmarks using a block-level access list (providing only account addresses and storage keys, without balance diffs or post-execution write values) on Geth. After introducing BAL, Geth’s live sync performance improved by approximately 30%.

Author: wjmelements
Date: 2025-04-24T15:54:39.148Z

I wish the Specification wasn’t entirely code.

The BAL MUST be complete and accurate. It MUST NOT contain too few entries (missing accesses) or too many entries (spurious accesses).

The access list should be complete, but this may be impossible because of PREVRANDAO.
I like this spec a lot. It should also deprecate transaction-level access lists and remove the warm/cold distinction.

Author: jochem-brouwer
Date: 2025-04-24T21:52:18.383Z

Is the code used for this experiment available somewhere? Would love to see it!

Author: jochem-brouwer
Date: 2025-04-24T21:55:54.431Z

Why “The access list should be complete”? Why not “The access list must be complete”?
The BAL should be generated during block building. The verifier should then re-run the block and then verify that the BAL is complete (nothing misses, and there is nothing added which is not accessed).
Note that the contents of the BAL do not influence execution paths, so the EVM execution itself has no knowledge of the BAL. This is possible with tx-level access lists and in particular the divergence in gas costs if a slot/address is warm or cold, which could yield situations where it is impossible to generate a complete access list (which is also why eth_createAccessList has a retry-limit, because otherwise you could find yourself in an infinite loop  )

Author: wjmelements
Date: 2025-04-24T22:07:26.996Z

jochem-brouwer:

Why “The access list should be complete”? Why not “The access list must be complete”?


I thought must was impossible because I misremembered PREVRANDAO. It’s less random (and useful) than I remembered.

Author: dajuguan
Date: 2025-04-26T09:33:55.349Z

yeah, we will publish a full post on the code, core ideas and basic benchmarks next week
Title: EIP_7912__Pragmatic_expansion_of_stack_manipulatio
Category: EIPs

Author: matt
Date: 2025-04-24T16:53:43.417Z

PR: Add EIP: Pragmatic expansion of stack manipulation tools by lightclient · Pull Request #9501 · ethereum/EIPs · GitHub
Add SWAP17-SWAP24, DUP17 - DUP24, SWAPN, DUPN, and EXCHANGE
instructions. The arbitrary depth operations must be preceded by PUSH1 instructions defining operands.

Author: wjmelements
Date: 2025-04-24T17:01:05.335Z

The argument X must be provided by a PUSH2 operation immediately preceding the EXCHANGE instruction


This argument must be provided by a PUSH1 operation immediately preceding the SWAPN and DUPN instructions.

Why not just read from the stack and exceptional-halt if the param is too large?

Author: matt
Date: 2025-04-24T17:12:16.883Z

Why not just read from the stack and exceptional-halt if the param is too large?

You do read them from the stack, but this simplifies static analysis i) by ensuring the operand is available directly before the instruction and ii) avoiding dynamic stack manipulation by using values from calldata or storage as the operand.

Author: Arvolear
Date: 2025-04-26T11:37:08.754Z

We really need this more than the entire EOF. Even though the Solidity compiler might have fixed its “stack-too-deep” errors by putting local variables into memory.

Author: benaadams
Date: 2025-04-27T01:37:41.226Z

Why burn 17 opcodes for the fixed values and add 2 dynamic ones for same gas that do the same thing?
Also the 4 dynamic opcodes have 34 byte code look backs so 3 gas seems very low?

Author: matt
Date: 2025-04-27T23:30:56.118Z

I think we have ample opcodes left and stack-too-deep is a common issue. The static N versions relieve some pressure efficiently while the dynamic N versions support much deeper stack manipulation at a slightly higher cost.
Yeah 3 has could be too low, will have to see how expensive the look back ends up being. Could also consider doing look after.

Author: matt
Date: 2025-05-05T17:17:43.855Z

@benaadams btw I added a note in the EIP, but I remembered why the dynamic opcodes are actually not that expensive. You just need to look at pc-2 and see if it is a valid jump destination. If so, we know it executed since there couldn’t be any other operation in between. Another way to do this is just store an interpreter flag is_last_op_push1 and only set it when a PUSH1 is executed and unset after.
Title: EIP_XXXX__Increase_Gas_Utilization_Target
Category: EIPs

Author: storm
Date: 2025-02-10T16:38:07.787Z

Link to EIP
Update Log

2025-02-10: initial draft

External Reviews
None as of 2025-02-10.
Outstanding Issues
None as of 2025-02-10.

Author: storm
Date: 2025-02-10T16:38:48.514Z

space reserved for future faq

Author: storm
Date: 2025-02-10T16:51:37.485Z

the EIP uses the gold double slope curve shown below
image1118×1097 85.9 KB
this EIP maintains the base fee update range to stay within [-12.5%, +12.5%] per block. this range isn’t necessarily optimal, but this EIP aims to change as few aspects of EIP-1559 as possible while still adjusting the gas target
there are other ways the update rule could be changed while still maintaining the range, such as the blue offset curve in the diagram

Author: benaadams
Date: 2025-02-10T19:17:46.810Z

Makes it completely off balance?
Especially the blue line; where gasprice can easily lose 12.5%; but can only gain 12.5% at 100% full. So gas price would end up at 0
Need to at least return to the curve; say an S-curve
image1018×1000 121 KB
So it has some chance of gaining back what it lost (though even then am not sure; as it will precipitously drop but only slowly rise if that is unbalanced)
Otherwise ∑ f(x) < 1 and it will inevitably end up at zero

Author: benaadams
Date: 2025-02-10T19:38:33.256Z

Gas price changes should also be based on an EMA rather than last block alone; so it changes sensibly rather than whipsawing after blocksizes of those with private order flow and those without private orderflow

Author: wjmelements
Date: 2025-02-11T04:55:28.482Z

I think what you really want is a higher gas limit, or perhaps lower gas prices.
The point of having a lower utilization than the block gas limit is to allow elasticity while keeping the same average. This leads to predictable gas prices via the base fee mechanism. You should read eip-1559, particularly its motivation.
Before eip-1559, the gas utilization was 100% of the block gas limit. Very rarely would blocks be less than full, but it was difficult to predict the gas price you would need for a transaction to confirm, because you would have to outbid the top margin of the mempool.
If you increase the target utilization, the gas limit would have to be lower. You’d be changing 2x elasticity to 4/3x and the gas price would become more volatile.
I think it would be better to lower the gas utilization target, as it would provide more flexibility under congestion. If the target utilization was 25%, the elasticity would be 4x, a number I supported when 1559 was originally being debated.
Title: EIP_7883__ModExp_Gas_Cost_Increase
Category: EIPs

Author: benaadams
Date: 2025-02-12T18:31:06.960Z

Discussion topic for https://eips.ethereum.org/EIPS/eip-7883

Author: wjmelements
Date: 2025-02-13T00:01:36.306Z

That link is 404 Not Found

Author: shemnon
Date: 2025-02-13T00:28:03.304Z

PR - Add EIP: ModExp Gas Cost Increase by marcindsobczak · Pull Request #9356 · ethereum/EIPs · GitHub
The link will work one day.

Author: jochem-brouwer
Date: 2025-05-10T05:59:49.236Z

For transparency of this EIP (and process), where can we find the benchmarks such that it can be reproduced that the precompile is underpriced and we thus need a raise?
Title: Max_Blob_flags_for_local_builders
Category: EIPs

Author: kevaundray
Date: 2025-01-30T20:00:16.251Z

Discussion topic for EIP-XXXX
Update Log

2025-01-30: initial draft Add EIP: Enable local block builders to configure the max amount of blobs to include by kevaundray · Pull Request #9296 · ethereum/EIPs · GitHub
Title: Auto_Review_Bot_Failing_on_PR__930____no_artifacts
Category: EIPs

Author: nitin312
Date: 2025-04-11T08:32:33.109Z

Hi maintainers,​
I’m working on PR #930 in the ethereum/ERCs repository. After submitting a follow-up comment to request a review, the Auto Review Bot was triggered but failed almost immediately with the following error:​

Error: no artifacts found​

The GitHub Actions log shows that the auto-review-bot.yml ran for just a few seconds before failing. No artifacts were created, and it seems like the job didn’t have the necessary inputs to proceed.​
Has anyone encountered this issue before? Could it be related to a misconfiguration or recent GitHub workflow updates? Any guidance on how to proceed or who to tag would be appreciated!​
Thanks in advance for your time and assistance.​
Best regards,​ Nitin Bhagat (@nitin312)​
Title: EIP_7636__Extension_of_EIP_778_for__client__ENR_En
Category: EIPs

Author: JKinc
Date: 2025-03-18T21:24:25.177Z

It has been one year since I authored EIP-7636, since then it has been implemented in two consensus clients, Lighthouse and Grandine.
Since the previous ethereum magicians post got little attention, I have decided to make this follow-up post to gauge community sentiment on this EIP, as I have seen conflicting opinions both justified with facts.


Ethereum Improvement Proposals


EIP-7636: Extension of EIP-778 for "client" ENR Entry
Add additional ENR entry to specify client information such as name and version number.
Title: ERC_7412__On_Demand_Off_chain_Data_Retrieval
Category: EIPs

Author: noahlitvin
Date: 2023-08-03T17:14:30.851Z

Discussion thread for https://github.com/ethereum/EIPs/pull/7412
We’re working on SIP-329 for Synthetix and thought it might be a good time to formalize a standard here that could also be applicable to cross-chain reads (or any other oracle data). We should be able to implement this standard with Pyth for price feeds right away and we’re in touch with other oracle providers about developing a cross-chain read solution that can also conform to this standard.
We’re very interested in feedback on this from the broader Ethereum community as we get into implementation. Thank you!

Author: noahlitvin
Date: 2023-08-14T16:41:00.344Z

We’ve built a functional reference implementation with a test here: GitHub - Synthetixio/erc7412: Reference implementation for [EIP-7412](https://eips.ethereum.org/EIPS/eip-7412)

Author: noahlitvin
Date: 2025-03-17T15:24:36.811Z

We’ve made a small update to the content of the ERC and created this microsite with more information at erc7412 [dot] github [dot] io (unable to post links)
Title: EIP_7692__EVM_Object_Format__EOF__Meta
Category: EIPs

Author: pdobacz
Date: 2024-04-16T22:00:00.000Z

Discussion thread for Add EIP: EVM Object Format (EOFv1) Meta by pdobacz · Pull Request #8448 · ethereum/EIPs · GitHub, which is only a list of EOF EIPs
Title: EIP_7910___Eth_config_JSON_RPC_Method
Category: EIPs

Author: shemnon
Date: 2025-03-18T16:38:11.756Z

Discussion topic for EIP-7910
Update Log

2025-03-18: initial draft PR#9493

External Reviews

twitter post Besu intends to adopt.

Outstanding Issues
None as of 2025-03-18

Author: lu-pinto
Date: 2025-03-27T14:20:56.098Z

This could be useful for checking configs at runtime in clients remotely. Can optional fields be included or is it strict to the fields stated in the EIP?

Author: shemnon
Date: 2025-03-27T18:28:01.772Z

I could see user provided extensions by adding flags to the rpc call, but there needs to be an EIP and only EIP fields response to the no-args call.
Title: About_the_EIPs_category
Category: EIPs

Author: jpitts
Date: 2018-02-17T03:07:04.947Z

Discussions about specific EIPs (improvement propsals), and general proposals which may become EIPs. If applicable, specify the EIP issue # in the topic title.
Title: EIP_4762__Statelessness_gas_cost_changes
Category: EIPs

Author: dankrad
Date: 2022-03-25T20:38:45.900Z

github.com/ethereum/EIPs








EIP-4762: Statelessness gas cost changes


master ← dankrad:verkle-gas-cost



          opened 09:31PM - 03 Feb 22 UTC




            dankrad
          



+308
-0






This EIP introduces changes in the gas schedule to reflect the costs of creating… a witness. It requires clients to update their database layout to match this, so as to avoid potential DoS attacks.

Author: Zoltan
Date: 2024-09-18T19:20:26.588Z

Those gas charges will be valid for accessing EOF data section too?

Author: ihagopian
Date: 2024-10-05T20:30:15.187Z

Some weeks ago, I drafted changes around 4762 (and other EIPs) regarding EOF.

github.com/jsign/EIPs








Verkle EOF draft


master ← jsign/vkt-eof



          opened 08:45PM - 02 Sep 24 UTC




            jsign
          



+58
-26






_[Note: this is a tentative PR to get feedback before creating the real PR]_
_[…Note: I'm quite heavy in commenting just to explain rationale. I won't create so many PR comments in the eventual final PR]_

This PR changes EIP-6800, EIP-4762, and EIP-7748 to consider EOF.

I make minimal changes to fix the spec to avoid bloating the PR. We can reorganize/refactor the EIPs in the future -- I avoid doing that in this PR to reduce the review footprint.

I think it will be helpful for reviewers to have the following references to inspect new EOF instructions:
- https://eips.ethereum.org/EIPS/eip-3540: EOFv1 container
- https://eips.ethereum.org/EIPS/eip-4200: RJUMP, RJUMPI, RJUMPV
- https://eips.ethereum.org/EIPS/eip-4750: CALLF, RETF
- https://eips.ethereum.org/EIPS/eip-6206: JUMPF
- https://eips.ethereum.org/EIPS/eip-7480: DATALOAD, DATALOADN, DATASIZE, DATACOPY
- https://eips.ethereum.org/EIPS/eip-663: SWAPN, DUPN, EXCHANGE
- https://eips.ethereum.org/EIPS/eip-7620: EOFCREATE and RETURNCONTRACT
- https://eips.ethereum.org/EIPS/eip-7069: EXTCALL, EXTDELEGATECALL, EXTSTATICCALL, RETURNDATALOAD

Author: gballet
Date: 2025-01-30T09:02:16.731Z

they will, as the data section will be stored in the tree and appear in the witnesses
Title: Get_started_here_
Category: General

Author: nicocsgy
Date: 2024-08-02T11:19:11.535Z

Hello  Welcome to the Ethereum Magicians forum  
Ethereum Magicians is a forum for the crypto community to have a place where anyone can join, create topic and discuss mainly about EIPs and technical difficulties of Ethereum ecosystem. Or in another words “Ethereum Magicians forum is a place on the internet where your voice will be heard and your contributions to the Ethereum will matter”. Ethereum Magicians is a group of individuals working and contributing to the Ethereum.
What to do on a forum?

Read and discuss about Ethereum
Create topic
Form a working group
Share prototype, code, graph and ask for feedback
Attend discussions and in-person meetings

First time on Ethereum Magicians forum?
If you’re the first time on the Ethereum Magicians forum, please check out our New Member Guide where are explained terms that we are using on this forum and will give you a lot of answers to questions regarding this forum and Ethereum Magicians in general.
History of Ethereum Magicians
Fellowship of Ethereum Magicians (FEM) was founded to solve problem of offline and online coordination in Ethereum. We started an open forum with a focus on improving Ethereum without unwanted noise (that social media like Twitter and Reddit provides). FEM is Fellowship of individuals with a common goal - Improve Ethereum.
If you’re interested in reading more of the history of FEM, read this Medium article from @pet3rpan
Feel free to introduce yourself in the Introduction thread
Read more about Ethereum Magicians
Ethereum Core Maintainers Medium article - explaining the difference between Ethereum Magicians, Ethereum Cat Herders and AllCore Devs
 Feel free to share Ethereum Magicians posts on social media and tag us @EthMagicians 
Message by @jpitts

Author: cryptochamp
Date: 2025-05-01T06:31:59.442Z

EIP-8879: potentials
Title: Interest_in_a_Chain_Specific_Transaction_Hashes_EI
Category: Web

Author: bumblefudge
Date: 2024-09-06T13:26:46.803Z

[Continuing the discussion from Chain-specific addresses]
@vid mentioned in the post above that a addressing standard for transaction hashes which includes the chain it’s on would be helpful.  I answered above that there is a draft “CAIP” (chain-agnostic IP, using the CASA chain-specification URI format) which might be useful to revive for cross-VM use-cases, or just useful to copy-paste into a simpler EVM-only EIP achieving the same ends.  Comment if you’ve been looking for such a thing or would be interested in prototyping/coauthoring an EIP and/or a CAIP on the subject!
Title: Detecting_a_transaction_that_was_speed_up
Category: Web

Author: ligi
Date: 2022-08-23T16:34:05.777Z

What is the best practice to handle the following case:

an app initiates a transaction and gets the tx hash.
on the backend it waits for this tx hash to confirm

now in the case the user speeds up a transaction - the tx hash changes and step 2 will never finish.
What is now the best practice to detect the altered transaction? Ideally the wallet would tell the dapp about the alteration - but AFAIK there is no such mechanism (yet). Otherwise what is a good way/best practice here? Searching through all transactions to find the replacement tx sounds like a lot of waste.
Maybe I am missing something here - or should we bootstrap a mechanism that the wallet can tell the dapp about alterations?
Title: An_opt_in_off_chain_protocol_to_pre_validate_trans
Category: Web

Author: rubi
Date: 2021-03-10T23:47:29.354Z

This is just about wallets UX. Check-sums are nice, but at the end of the day, a lot of people “make a small transaction, just to see it’s working”, before making a really huge one. A lot can go somewhat wrong on the first transaction between two wallets (picking the wrong network, an unsophisticated malware changing the address on clipboard, copying the wrong address on the first place, etc.)
It could be nice if this is replaced by some off-chain protocol that publish the transaction as a notification on the other end, so the person(s) doing it can validate, before submitting.
I’m not getting into implementations details because it doesn’t matter. I’d love to hear community  opinion 
Of course it’s optional, may be turned off by default.