Monthly EIP - Jul 2026 (ft. What the Issuance Debate Reveals About Ethereum Governance)

Key Takeaways

• July saw a sharp rise in new EIPs. At the Core layer, many proposals focused on redesigning the foundations of Ethereum to keep consensus, verification, and storage costs manageable as the validator set and state continue to grow, including improvements to attestation propagation, post-quantum verification, state tiering, and the state tree. On the ERC side, discussions centered on standardizing regulatory and RWA-related information, while bridging new smart account architectures with existing module ecosystems.
• Following its June restructuring, the Ethereum Foundation stepped up its engagement with governments and institutions, while pushing forward discussions around faster finality. At the same time, it added a board member known for emphasizing security, privacy, and censorship resistance, signaling a clearer effort to expand institutional adoption without losing sight of Ethereum’s core values.
• Meanwhile, the issuance debate reignited by EIP-8363 has grown into a broader governance question, extending well beyond how staking rewards should be adjusted. It exposed the limits of a system in which monetary policy proposals can advance without a sufficiently robust process for validation and stakeholder input, raising a larger question for an increasingly multipolar Ethereum ecosystem: who should build consensus, and through what process?

Ethereum pioneered the concept of smart contracts by integrating programmability into a distributed ledger architecture, thereby expanding the functional scope of blockchain systems. This design philosophy has been progressively formalized through the Ethereum Improvement Proposal (EIP) process, enabling the network to evolve beyond a simple store of value into an infrastructure capable of supporting real-world businesses and a wide range of use cases. As this evolutionary process continues, broader participation in EIP deliberations—by opinion leaders with heterogeneous perspectives and problem framings—may further enrich the development of a digital-native economic paradigm.

This article presents a high-level examination of EIP trends by reviewing proposals newly accepted into the Draft stage on a monthly basis, alongside proposals that have undergone meaningful status transitions. Through this analysis, we aim to provide builders and business stakeholders with a more structured understanding of the evolving EIP landscape and to offer a conceptual foundation for identifying and developing new value propositions within their respective areas of activity.

The EIP-related data referenced in this article was collected and analyzed using the official GitHub repositories for EIP, ERC, and RIP.

1. This Month's Ethereum Discussion Summary

One of the clearest trends in July’s EIP activity was the sharp increase in new proposals, reaching levels comparable to the beginning of the year, with much of the growth concentrated in Core EIPs. At the consensus layer, proposals included batching multiple validators’ attestations before propagation to reduce network overhead (EIP-8243), as well as separating computationally intensive proof generation into a dedicated aggregator role under post-quantum signature schemes (EIP-8292). At the execution layer, proposals such as state tiering, which introduces additional write costs for long-unused state (EIP-8295 & 8296), and EIP-8297, which restructures the MPT into a binary tree better suited for proofs and state management, were designed with larger state and validity-proof environments in mind. Overall, July’s Core EIPs were less about adding near-term functionality and more about reworking Ethereum’s foundations so that verification, propagation, and storage costs remain manageable as the validator set and state continue to grow.

At the application layer, ERC discussions were particularly active around standards for regulation and real-world assets. ERC-8262 proposes a common interface for communicating compliance results, such as AML checks and risk assessments, through zero-knowledge proofs rather than the underlying data itself. Meanwhile, the series of standards from ERC-8325 through ERC-8330 breaks down information surrounding tokenized real-world assets, including supporting documents, transfer policies, regulatory events, impact metrics, and NAV, into separate functional interfaces. ERC-8286, in turn, introduces a validation interface that allows existing ERC-7579 smart account modules to be reused under EIP-8141’s new frame transaction architecture. In short, while the Core layer focused on reworking Ethereum’s long-term scalability and verification architecture, ERC activity centered on creating more consistent ways to connect the information required by regulated assets and smart accounts.

A number of existing EIPs also advanced in ways that reflected these broader themes. Core proposals such as EIP-7928, which specifies block-level state access information to support parallel execution and state processing, and EIP-7981, which incorporates Access List data size into gas pricing, moved forward. On the ERC side, notable proposals included ERC-1450, which allows registered Transfer Agents to control transfers of security tokens, ERC-1613, which defines a relay-based gas sponsorship model, and ERC-8196, which restricts AI agents to executing transactions within owner-defined policies and verification conditions. With 24 new EIPs introduced and 15 existing proposals advancing at the same time, July was less about a single application trend and more about parallel progress across Core work on state, consensus, and verification, alongside standardization efforts for regulation, assets, and accounts.

Source: Ethereum

If June’s restructuring was about redefining the role of the Ethereum Foundation (EF), July began to show which priorities the new structure would actually bring to the forefront. The first visible movement came from the newly organized institutional-facing functions. On July 1, the EF’s Global Policy Strategy team published “Ethereum Basics for Governments and Institutions”, presenting Ethereum not as a system controlled by any single company or state, but as neutral digital infrastructure that multiple parties can use together. This suggests that the Institution layer introduced through the June restructuring is beginning to move beyond an organizational distinction and into practical communication and adoption support for governments and institutions.

On the protocol side, discussions around improving finality became more concrete as part of a broader effort to make Ethereum a faster settlement and payment layer. On July 10, the EF Consensus team published findings from a survey of rollups, bridges, payment services, wallets, solvers, oracles, staking providers, and institution-facing teams, examining the practical benefits of reducing finality from its current roughly 13 to 19 minutes. Faster finality was framed not simply as a way for users to receive transaction confirmation sooner, but as a means of reducing the capital costs borne by bridges and solvers, improving application-level risk management, and shortening the period during which the chain remains exposed to certain attacks. At the same time, rather than replacing the existing consensus architecture all at once, the discussion proposed separating fork choice from finality and shortening finality incrementally, bringing long-term consensus reform closer to a realistic upgrade path.

The EF’s organizational identity was also reflected in changes to its board at the end of July. On July 29, pcaversaccio joined the EF board, bringing the board to four members alongside Aya Miyaguchi, Vitalik Buterin, and Patrick Storchenegger. As a co-founder of SEAL 911, pcaversaccio has consistently emphasized Ethereum’s security, privacy, and censorship resistance. The EF has described the board as a form of security council responsible for ensuring that management strategy remains aligned with Ethereum’s core values and for safeguarding the Foundation’s overall direction. Following June’s decision to reduce operating headcount and budget while refocusing the EF on protocol neutrality and self-sovereignty, July showed a clearer attempt to expand institutional outreach while keeping security, privacy, and censorship resistance firmly anchored as institutional priorities.

2. Newly Drafted EIPs

A total of 24 new EIPs were adopted in July, an increase of 14 from the previous month. Most of the new proposals fell into either Core EIPs, which require changes at the network level, or ERCs, which define application-layer standards.

Below, we further classify the EIPs newly adopted as ‘Draft’ and take a closer look at several proposals that warrant particular attention.

2.1 Core / Networking Layer

2.1.1 EIP-8243: Batching Attestations at Source

As Ethereum’s validator set grows, the cost of consensus rises not only because more votes must be processed, but also because those votes must be propagated across the network. With roughly one million active validators participating today, each slot can generate around 31,000 individual attestations. Even when a large staking provider operates multiple validators on the same node, every validator vote must still be propagated as a separate message. If Ethereum is to move toward shorter slots and faster finality, reducing verification costs alone will not be enough; the volume of repetitive consensus messages also needs to fall. EIP-8243 proposes addressing this without reducing the validator count, by allowing multiple validators assigned to the same committee to bundle their attestations at the source and propagate them as a single message.

There is a reason unrestricted aggregation of attestations has not previously been allowed. If anyone could collect publicly available signatures and recombine them into arbitrary subsets, just k votes could potentially be turned into as many as O(2^k) distinct aggregates, creating an avenue for gossip-layer spam. EIP-7251’s validator balance consolidation can also reduce the number of messages, but it depends on validators voluntarily consolidating their balances. EIP-8243 instead leaves the validator structure unchanged and compresses only how votes are represented on the network. In other words, it seeks to achieve network efficiencies similar to consolidation without requiring changes to existing staking configurations.

To make this possible, the proposal introduces WireAttestation = Union[SingleAttestation, BatchAttestation], with selectors 0x00 and 0x01 distinguishing the two formats. Validators that want to be included in a batch first sign a batch_seal over (slot, committee_index, batcher), explicitly authorizing a particular validator to bundle their votes. The batcher then signs the actual batch construction, including aggregation_bits, through a separate batcher_signature. As a result, an attacker cannot simply collect publicly available attestation signatures and insert validators into arbitrary batches, while the batcher can include only validators that have granted prior authorization. The underlying BLS attestation signature format remains unchanged, so the two additional signatures are checked only at the gossip layer and discarded afterward, leaving the on-chain Attestation format and process_attestation unchanged.

The core anti-spam mechanism is based not on the message format itself, but on whether a message contains genuinely new votes. Nodes maintain seen_attesters and seen_batchers for each (slot, committee_index, data_root), and only propagate a BatchAttestation if it includes at least one attester that has not yet been seen. This means that even if many overlapping batches are submitted, subsets that add no new votes are naturally dropped, limiting message amplification to the number of validators an attacker actually controls. If a batcher fails, validators can also fall back to the existing SingleAttestation path. Operators may pre-sign seals for both primary and fallback batchers at the start of an epoch, avoiding additional signature latency on the critical path.

The significance of EIP-8243 lies in its ability to reduce redundant propagation without imposing a direct cap on validator participation. For example, if the information density of each attestation message were increased fourfold under the same bandwidth budget, Ethereum could potentially explore changes to committee counts, subnet counts, or even epoch length, although none of those parameter changes are specified by the EIP itself. There are tradeoffs, however. Validators included in the same batch may reveal that they are operated by the same entity, while concrete integration with structures such as DVT and LSTs, where key management is distributed across multiple parties, still requires further validation. EIP-8243 is therefore better understood not as a replacement for validator caps or broader consensus redesign, but as a way to compress attestation propagation first, creating additional network headroom for faster consensus in the future.

2.1.2 EIP-8295: State Tiering by Periods & EIP-8296: Fixed-Cutoff State Tiering

Ethereum’s state problem is not simply that data keeps accumulating. Accounts and storage slots that have not changed for years currently coexist in the same storage path as state that is updated every block, yet the gas model barely reflects the difference when either is modified again. From a node’s perspective, retrieving and rewriting long-dormant state may have a very different cost profile from modifying recently active state, but the protocol has historically treated both as ordinary state writes. EIP-8295 and EIP-8296 propose two approaches to divide state into Active and Inactive categories based on when it was last modified, charging a higher cost when long-unused state is written again.

Both proposals build on EIP-8188. EIP-8188 adds last_written_block to accounts and storage slots, recording at the consensus level the block in which each state item was most recently modified, but does not use that information for gas pricing. EIP-8295 and EIP-8296 turn this metadata into an economic signal, making transactions bear additional costs when they reactivate long-unused state. Unlike the warm/cold distinction introduced by EIP-2929, which depends on whether something has already been accessed within a single transaction, Active and Inactive status here is determined by a state item’s write history across many blocks.

EIP-8295 uses a continuously moving definition of inactivity. Block numbers are divided into intervals of PERIOD_LENGTH, and an account or slot becomes Inactive once at least INACTIVE_MIN_AGE periods have passed since its last write. Modifying such state incurs an INACTIVE_ACCOUNT_WRITE_SURCHARGE or INACTIVE_STORAGE_WRITE_SURCHARGE. Once a write occurs, last_written_block is updated to the current block and the state becomes Active again, before eventually returning to Inactive if it remains untouched for long enough. The design therefore creates an economic incentive to limit the size of the Active set, since users who want to preserve cheap future write access would need to pay to refresh state periodically.

EIP-8296 applies the same principle in a much simpler way. The protocol defines a single CUTOFF_BLOCK, and only state with last_written_block < CUTOFF_BLOCK is treated as Inactive, effectively freezing the initial inactive set at the time of activation. This allows clients to place that set into immutable files and distribute it through a shared, state-root-verifiable format, which the specification also recommends. The tradeoff is that once state has been classified as Active after the cutoff, it never becomes Inactive automatically, regardless of how long it remains unused. To move more old state into the inactive tier, a future network upgrade would need to advance the CUTOFF_BLOCK.

The actual gas-charging logic is largely similar across the two proposals. For example, modifying an existing Inactive storage slot through SSTORE may incur surcharges for both the slot itself and the corresponding account leaf whose storageRoot changes. Newly created slots or accounts are exempt, since they instead fall under the state-creation costs defined in EIP-8037. These surcharges are charged as regular gas rather than state gas, and once consumed, they are not refunded even if execution later reverts. Wallets and RPC providers would therefore need to incorporate last_written_block into eth_estimateGas to determine whether a planned write targets Active or Inactive state.

The key distinction between the two EIPs is not whether state should be tiered, but whether the boundary should move automatically over time or be reset manually through protocol upgrades. EIP-8295 can continuously capture newly cold state, but it may encourage unnecessary refresh transactions from users seeking to preserve cheap future writes. EIP-8296 avoids this renewal gaming and simplifies implementation and archiving, but the Active set can continue to grow until the cutoff is moved again.

Neither proposal amounts to state expiry, since Inactive state remains part of the state root and is not deleted. Whether clients actually move that state to slower storage or separate files remains an implementation choice. Both proposals also leave an important caveat unresolved: state that has not been written for a long time is not necessarily rarely read. Moving frequently queried data to a slower storage path based only on write age could introduce new performance or DoS concerns.

2.1.3 EIP-8297: Partitioned Binary Tree

If Ethereum is to move toward a validity-proof-oriented verification model, execution itself is only part of the problem. It also matters how efficiently the state read and written during execution can be proven. The current Merkle Patricia Trie (MPT) combines hexadecimal branching, RLP encoding, Keccak hashing, and a nested structure in which each account tree contains another storage tree, increasing both proof size and computation. Contract code presents another challenge, since proving access to only a few bytes may still require providing the entire code body. EIP-8297 approaches this bottleneck not as a simple hash-function replacement, but as a broader redesign of how Ethereum state is arranged and committed.

The proposal merges the existing account and storage trees into a single binary tree, while still preserving logical locality rather than mixing all state indiscriminately. The first byte of each key acts as a zone identifier: 0x00 represents account headers, 0x01 contract code, and 0xFF storage, while the remaining ranges are reserved for future state types. This allows Ethereum to maintain one common state tree while grouping data that may need to be proven or managed together, such as storage and code associated with a particular account. Structurally, this could also make it easier for future designs such as state expiry or partial statelessness to operate on account- or state-type-specific regions independently.

The tree itself is also simplified to make proofs more efficient. Nodes are limited to LeafNode and BranchNode, committed as H(LEAF_TAG || key || value) and H(BRANCH_TAG || prefix || left_hash || right_hash) respectively. Binary branching requires only one sibling hash per level, reducing witness size for a state set of comparable scale, while long shared paths are compressed into BranchNode.prefix to avoid chains of redundant single-child nodes. The design also removes RLP and leaves room for a proof-friendly hash function, although BLAKE3 in the current reference implementation is only provisional and the final hash function remains undecided.

State placement is designed around actual access patterns. Frequently accessed fields such as nonce, balance, code size, and the first 64 storage slots are grouped under the same account header stem, while the remaining storage is placed in a separate storage zone using a structure such as 0xFF || H(address) || H(address || tree_index) || sub_index. Contract code is split into 31-byte chunks so that individual portions can be proven without revealing the entire code body, and it is stored by code_hash rather than address, allowing many contracts with identical bytecode to share the same underlying code data. For clients, this could unify caching, synchronization, and witness generation around a single key-value tree while reducing unnecessary branch openings and duplicate code storage.

The significance of EIP-8297 is not that it immediately reduces state size or completes stateless Ethereum, but that it reorganizes state into a form that is easier to prove, synchronize, and eventually expire. EVM operations such as SLOAD and SSTORE, as well as Solidity’s storage interface, remain unchanged, so application code does not need to be rewritten. However, because the state root and proof format would change, clients and contracts that directly verify MPT proofs would need to support the new structure. Migration from the existing MPT is handled separately by EIP-8347, while the final hash function is also still open. Even so, EIP-8297 can be seen as an attempt to create a common state-tree foundation on which validity proofs, state expiry, and partial statelessness can all evolve.

2.1.4 Other(s)

• EIP-8219: Checked Arithmetic Opcodes
• EIP-8282: Builder Execution Requests
• EIP-8298: SETCODEFROM Code Reuse Instruction
• EIP-8310: Post-Quantum Keystore for Stateful Keys
• EIP-8311: Increase Calldata Floor Cost to 96
• EIP-8333: Align Checkpoint with Epoch Boundary Block
• EIP-8337: Validated EVM Code

2.2 Data / Messaging / Transaction

2.2.1 EIP-8292: Post-Quantum Attestation Aggregators

One of the hardest parts of Ethereum’s post-quantum transition is not simply choosing a new signature algorithm, but redesigning how votes from hundreds of thousands of validators can still be compressed into a manageable amount of block data. Today, BLS signatures allow signatures from many validators to be aggregated into a single 96-byte signature. The XMSS-family hash-based signatures assumed by EIP-8292 do not have this property. Individual signatures are also much larger, at roughly 1.17 KiB each, so including them directly would cause both data and verification costs to scale with validator participation. A post-quantum consensus design therefore needs to reconsider the attestation-processing architecture that currently relies heavily on BLS aggregation.

EIP-8292 proposes compressing not the signatures themselves, but the fact that they are all valid, into a single succinct proof. Generating such a proof, however, is substantially more computationally expensive than the relatively lightweight elliptic-curve operations performed by today’s BLS aggregators. Making proof generation a universal validator duty could force home stakers to operate significantly more powerful hardware or make it difficult to meet slot timing constraints. EIP-8292 therefore separates proof generation from both ordinary validation and block proposal, introducing a dedicated aggregator role that high-capacity nodes can opt into.

The process begins with validators propagating signed attestations across gossip subnets divided into SUBNET_COMMITTEES. Aggregators subscribe to one or more subnets, collect signatures over the same attestation message, and perform leaf aggregation through leanVM, producing a proof that those signatures are valid. Where necessary, multiple partial proofs can then be combined recursively. The final step of combining proofs over different attestation messages into a block-level proof remains the proposer’s responsibility, with the current specification limiting each block to MAX_ATTESTATIONS_DATA = 8 distinct messages. The proposal therefore does more than add another node that gathers signatures; it divides the post-quantum aggregation pipeline into separate stages from signatures, to proofs, to a block-level proof.

This separation matters because proof generation time, rather than proof size alone, is likely to become the practical operational bottleneck. Current benchmarks cited by the proposal suggest that a proof aggregating 1,000 signatures is around 227 KiB and does not grow dramatically with the number of votes, but proof generation takes around 11 seconds on two cores versus roughly 2.6 seconds on 16 cores. EIP-8292 therefore avoids introducing a stake threshold for ordinary aggregator eligibility, allowing any node with sufficient resources to opt in, while recommending a super-aggregator role for sufficiently large stakers that can cover all subnets. Regular validators and proposers only need to verify the resulting succinct proofs, preventing the heavy computation of a post-quantum transition from being imposed equally on the entire validator set.

This does not eliminate the cost of post-quantum consensus so much as concentrate it in a specialized role. Because aggregators sit on the critical path between attestations and finality, proving could become concentrated among a small number of high-performance operators, and failures or censorship by those operators could harm liveness. The current specification also does not define a dedicated protocol incentive to compensate for the additional compute burden. In addition, the soundness of leanVM proofs becomes a new consensus security assumption, while specific hardware requirements and some post-quantum parameters remain unsettled. Even so, EIP-8292 offers an important preview of how Ethereum’s infrastructure could evolve under post-quantum cryptography: instead of forcing expensive proving onto every validator, it separates costly proof generation from cheap verification in an effort to keep ordinary validator participation accessible.

2.2.2 Other(s)

• EIP-8289: Multi-block Access List Warming
• EIP-8304: Trustless log and transaction index

2.3 Account / Contract / Token Standard / Wallet

2.3.1 ERC-8286: Modular Accounts for Frame Transactions

Smart accounts can separate functions such as signature validation and transaction execution into external modules, allowing each account to combine the functionality it needs. ERC-7579 standardizes how such modules can be installed and used across different smart account implementations. However, EIP-8141 introduces a new account abstraction model in which a transaction is divided into multiple frames responsible for validation and execution, rather than following the ERC-4337 model. This means the way existing validators connect to an account also needs to change. ERC-8286 introduces a validation interface tailored to frame transactions, allowing the existing ERC-7579 module ecosystem to carry over into the EIP-8141 architecture.

ERC-8286 therefore does not primarily introduce a new type of module. Instead, it defines how existing modules can be used to validate transactions under EIP-8141. Module installation and removal, as well as checking which modules an account supports, continue to follow ERC-7579. The proposal adds validateFrame as a frame-transaction counterpart to validateUserOp. ERC-7579 assigns existing validators module type 1, while ERC-8286 assigns the new frame validator type 11, and a single module may support both. A multisig or passkey validator, for example, could implement validateUserOp under ERC-4337 and validateFrame under EIP-8141 while reusing the same underlying authentication logic.

validateFrame does more than determine whether a transaction is valid. If validation succeeds, it also determines what authority the account is willing to grant. Its approvalMode return value indicates whether the transaction may pay gas (0x1), execute on behalf of the account (0x2), or do both (0x3). The account then checks this result before granting the corresponding authority through EIP-8141’s APPROVE instruction. The validator cannot grant arbitrary permissions, since it cannot exceed the scope originally permitted by each VERIFY frame, and the final APPROVE call is made by the account rather than the validator. The smart account therefore retains the final decision over what permissions are actually opened.

A particularly important distinction lies between the two execution paths supported by EIP-8141. A DEFAULT frame behaves more like a conventional smart account, routing execution through the account contract’s execute function, which lets the account re-check targets, call structure, and other conditions immediately before execution. A SENDER frame instead allows the protocol to call the destination contract directly while using the account address as the sender. Once execution authority has been granted, smart account code does not intervene between individual calls. Conditions such as whether multiple calls must be atomic, which destinations are allowed, how much value may be transferred, or what calldata may be used therefore need to be checked in advance during validation through mechanisms such as FRAMEPARAM and FRAMEDATALOAD.

The practical value of ERC-8286 is that even if EIP-8141 introduces a new underlying account abstraction model, the existing smart account module ecosystem does not have to be rebuilt from scratch. Over time, ERC-7579 could evolve into a common module standard independent of any single account abstraction implementation, with thin validation interfaces added for environments such as ERC-4337 or EIP-8141. The tradeoff is that EIP-8141’s SENDER frame does not re-check each call once APPROVE_EXECUTION has been granted. A poorly designed validator could therefore approve targets, values, or calldata that should have remained restricted.

In this sense, ERC-8286 is less about adding new smart account functionality and more about defining a cleaner boundary between a new account abstraction architecture and the module ecosystem already built on top of existing standards.

2.3.2 Other(s)

2.4 Application

2.4.1 ERC-8262: Zero-Knowledge Compliance Oracle

Efforts to reconcile privacy with regulatory compliance have often involved compromising one side of the equation. Hiding transaction data makes it harder for regulators or financial institutions to verify AML or sanctions screening, while mechanisms such as view keys ultimately preserve compliance by allowing the underlying data to be disclosed later. Privacy Pools have introduced ways to prove that funds are not associated with a particular sanctions set, but that alone does not establish whether a user satisfies jurisdiction-specific risk thresholds or transaction-pattern requirements. ERC-8262 addresses this gap by proposing a common interface for communicating compliance outcomes through zero-knowledge proofs rather than revealing the underlying data.

The core idea is for users to generate proofs locally showing that they satisfy a given rule, without submitting transaction amounts, counterparties, or individual screening results. ERC-8262 does not bundle every requirement into one universal proof. Instead, it defines nine circuit types covering Compliance, Risk Score, Pattern, Credential Attestation, Membership, Non-membership, and several provider-signed variants. COMPLIANCE (0x01), for example, takes risk signals and weights from up to eight providers as private inputs, calculates a weighted risk score, and reveals only whether it falls below the threshold for a particular jurisdiction through meets_threshold. PATTERN (0x03), by contrast, keeps the values and timing of up to 16 transactions private while proving the outcome of checks for patterns such as structuring, velocity, or round-amount behavior.

Once a proof is generated, IERC8262Verifier.verifyProof() routes it to the verification contract associated with the relevant proof type, and a successful result is recorded in the oracle as a ComplianceAttestation. The attestation stores fields such as the subject address, jurisdiction, proof type, validity period, verifier, and providerSetHash. Applications can then call checkCompliance(address, jurisdictionId) to determine whether a valid compliance proof currently exists. Every proof also binds the public submitter input to msg.sender, while proofHash = keccak256(abi.encodePacked(proof, proofType, block.chainid, address(this))) ties the proof to both the chain and the oracle contract, preventing the same proof from being replayed across different deployment environments. The broader goal is to let applications consume verifiable compliance outcomes through a common interface without directly handling users’ underlying compliance data.

A zero-knowledge proof, however, does not automatically guarantee that the screening inputs themselves are trustworthy. In the base COMPLIANCE (0x01) and RISK_SCORE (0x02) modes, the signals[] array is supplied as the user’s private witness. The circuit therefore proves only that the submitted inputs satisfy the defined threshold, not that those signals were actually issued by a legitimate AML provider. To address this, COMPLIANCE_SIGNED (0x07) and RISK_SCORE_SIGNED (0x08) verify a registered provider’s secp256k1 signature inside the circuit, while COMPLIANCE_MULTI_SIGNED (0x09) can require signatures from at least threshold_m out of as many as five independent providers. The security model therefore depends not just on the ZK system itself, but also on which proof types, providers, and thresholds an application chooses to trust. The specification explicitly distinguishes these trust levels as self-attested, provider-attested, and credential-attested.

ERC-8262 is therefore better understood not as a way to “make privacy compliant,” but as an attempt to turn compliance outputs that are currently implemented separately by each service into composable, on-chain proofs. Proofs have a default TTL of 24 hours, while expired records remain available through getHistoricalProof(), allowing an application to demonstrate retrospectively that a valid screening result existed at the time of a transaction. This could support forms of proof-of-innocence, but several issues remain, including provider collusion, incorrect inputs, compromised administrator permissions, and the exposure of proof submissions in the mempool. Whether regulators will ultimately recognize such ZK proofs as valid compliance evidence is also a matter that no technical standard can determine on its own.

2.4.2 ERC-8325 & ERC-8326 & ERC-8327 & ERC-8328 & ERC-8329 & ERC-8330

When tokenizing off-chain assets such as real estate, private credit, or funds, the harder problem is often not issuing the token itself, but making the information around that token readable and verifiable across different systems. Details such as what the token represents, which documents support the claim, where it may be transferred, which regulatory actions have occurred, how the asset is performing, and what it is currently worth are often scattered across token-specific contracts, external registries, and off-chain databases. ERC-8325 through ERC-8330 take a modular approach to this problem, dividing these functions across six independent interfaces rather than trying to solve everything through a single monolithic token standard. Their focus is not on redefining token behavior, but on creating a common framework through which provenance, status, policy, and reporting data around off-chain assets can be queried.

ERC-8325 and ERC-8326 deal primarily with the provenance of assets and documents. ERC-8325 derives an anchorId = keccak256(abi.encode(legalHash, evidenceHash)) from legalHash and evidenceHash, then links that anchor to a specific token contract or token ID, making it possible to verify in both directions which registry associated a particular asset claim with which token. ERC-8326 goes a level deeper by arranging contracts, certificates, and other supporting materials in a deterministic order, combining their hashes into a single bundleHash, and preserving a history of replacement bundles for each (subjectId, role). Neither standard proves that a document is genuine or that the token holder has an enforceable legal claim. What they do provide is a common way to track which materials were used as the basis for a registered relationship and how those materials changed over time.

ERC-8327 separates transfer eligibility into its own policy layer. Its core unit is (sourceDomain, destinationDomain, assetClass), where a domain can represent not only a country but also a regulated exchange, corporate network, DAO, or any other logical jurisdiction defined by the application. Permission from A to B and permission from B to A are configured independently. If multiple tokens belong to the same asset class, applications can therefore query a common isRoutePermitted() policy rather than duplicating the same transfer logic in every token contract, with support for both immediate revocation and delayed revocation. The registry itself does not determine which domain an address belongs to or enforce the transfer. A token or transfer controller must first resolve the relevant domains and asset class, then apply the registry’s result within the actual transfer path.

ERC-8328 focuses on maintaining an auditable history of regulatory and operational events rather than overwriting them with a single current state. Events such as issuance, redemption, freezes, KYC status changes, regulatory holds, and forced transfers are recorded as append-only entries under each subjectId. The standard distinguishes between the actor that actually records the event, the authority cited as the basis for the action, the relevant counterparties, and supporting evidence hashes. Incorrect records are not deleted or modified. Instead, a new correction entry is added through correctsIndex and correctedByIndex, preserving both the latest effective record and the history of what was previously reported. Importantly, this is not a compliance decision engine. What appears on-chain remains a claim recorded by an authorized recorder, and the standard does not guarantee that the action itself was legally valid or factually correct.

ERC-8329 and ERC-8330 extend the same record-oriented model to quantitative information, but for different types of data. ERC-8329 links impact indicators such as carbon emissions, renewable energy output, or employment figures to (subjectId, indicatorId, [periodStart, periodEnd)), storing value, decimals, unit, methodology, and correction history so that disclosures form a time series rather than a single latest figure. ERC-8330 targets assets such as funds, private credit, and real estate, where periodic valuation matters more than continuous market pricing. It creates a NAV stream for each (subjectId, currency), separates the economic valuation time in valuationTimestamp from the on-chain publication time in publishedAt, and allows applications to determine whether the data has become stale. An optional interface also defines lower-median aggregation when multiple providers submit NAV values for the same timestamp, but the standard still does not calculate NAV itself or guarantee that the reported figure represents an executable trading or redemption price.

Taken together, the common direction across these six ERCs is to standardize the information required to operate off-chain assets rather than embedding all regulatory logic directly into a single token contract. An issuer could use ERC-8325 to link an asset to a token, ERC-8326 to organize supporting documents, and ERC-8327 to define permissible transfer routes, while regulatory events, non-financial metrics, and NAV are maintained separately through ERC-8328, ERC-8329, and ERC-8330.

This could allow wallets, custodians, exchanges, and audit systems to retrieve relevant data through common interfaces instead of relying on each issuer’s proprietary API. It does not, however, eliminate the underlying trust problem. Decisions over which registries, recorders, and NAV providers to trust, whether supporting documents and measurement methodologies are valid, and how conflicting claims across chains or registries should be handled remain matters for individual implementations and institutional infrastructure. These proposals therefore do not attempt to guarantee the underlying reality or credibility of an RWA on-chain. Rather, they seek to standardize how information about the asset is registered, what evidence it refers to, and how that information changes over time.

2.4.3 Other(s)

• ERC-8143: Smart Credential Resolution Interface
• ERC-8320: Regulated Asset Claim

3. Progression of Existing EIPs

In addition to the 24 newly adopted EIPs, 16 existing proposals changed status during July. Fifteen advanced toward eventual adoption, moving into stages such as “Final”, “Last Call”, “Review”, or “Draft”, while one proposal, EIP-2542, moved to “Withdrawn”.

Among the ERCs that advanced, several are particularly noteworthy. ERC-1450 defines a standard under which registered Transfer Agents control the issuance, burning, and transfer of security tokens to enforce regulatory compliance. ERC-1613 proposes a decentralized Gas Station Network (GSN) in which relay nodes pay gas on behalf of users and dApps reimburse them. ERC-8161 allows pending deposit and redemption requests in ERC-7540-based tokenized vaults to be transferred to another account. ERC-8196, meanwhile, defines a wallet standard that allows AI agents to execute transactions only within policies and verification conditions specified by the asset owner.

Among the non-ERC proposals, notable examples include EIP-7708, which automatically generates ERC-20 Transfer-compatible logs for all ETH transfers to make ETH movements easier to track consistently. EIP-7928 specifies accounts, storage, and state changes accessed within a block through a Block-Level Access List, supporting parallel execution and state processing. EIP-7981 charges gas for the size of Access List data to prevent users from bypassing calldata floor-cost rules. EIP-7997, meanwhile, standardizes a shared CREATE2 factory so that contracts can be deployed to the same address across multiple EVM chains.

Other proposals worth noting include the following.

3.1 Core / Networking Layer

• EIP-7778: Block Gas Accounting without Refunds
• EIP-7904: Compute Gas Cost Analysis
• EIP-7954: Increase Maximum Contract Size
• EIP-7976: Increase Calldata Floor Cost
• EIP-8015: Remove `deposit` and `eth1data` fields

3.2 Data / Messaging / Transaction

• EIP-8182: Private ETH and ERC-20 Transfers

3.3 Account / Contract / Token Standard / Wallet

• None

3.4 Application

• ERC-5516: Soulbound Multi-owner Tokens

4. What the Issuance Debate Reveals About Ethereum Governance

Source: pintail.xyz

The recent proposal of EIP-8363: Tapered Issuance Burn (TIB) has reignited debate across the Ethereum ecosystem over issuance policy. EIP-8363 responds to the rapid growth of staking by proposing that an increasing portion of validator rewards be burned as the staking ratio rises, eventually reducing net yield to zero beyond a certain threshold.

The concern behind the proposal is worth discussing. Ethereum’s current issuance curve has no upper-end mechanism to slow staking growth. The problem is that a concrete reduction mechanism was proposed before the community had reached any meaningful agreement on Ethereum’s appropriate security budget or the future role of validators, and without sufficient prior discussion among directly affected stakeholders such as stakers, infrastructure providers, DeFi protocols, and institutions. The more important question raised by the debate is therefore not simply whether issuance should be reduced, but who should be able to change Ethereum’s monetary policy, and through what process.

Issuance policy has also become increasingly difficult to determine through protocol economics alone. Demand for staking is shaped not only by reward rates, but also by regulation, taxation, liquidity, custody infrastructure, and institutional asset-management practices across different jurisdictions. The same reduction in rewards can affect solo stakers and large staking providers very differently. Staking yields are also deeply connected to DeFi lending, leverage, and other financial products, so changes in policy do not remain confined to the validator market. Research models and estimates are an essential starting point, but moving directly from those models to protocol policy without testing them against real-world stakeholder incentives and external conditions is increasingly difficult to justify.

The broader problem is that Ethereum does not have a clearly defined decision-making structure for reconciling these differences. Historically, Ethereum has avoided formal governing bodies and token voting, relying instead on loose consensus among researchers, EIP authors, client teams, core developers, and the wider community through open discussion. Avoiding the concentration of decision-making power in a single organization or capital base is an important strength. Yet for issues such as monetary policy, where a broad range of interests are directly affected, there is no clear standard for whose input should be sought, at what stage, or how much agreement should be required before a proposal moves forward. The fact that TIB was submitted just two days before the Hegotá PFI discussion, prompting controversy not only over its substance but also over the process itself, illustrates this gap.

As Ethereum governance becomes increasingly multipolar, the more important task may be to broaden participation in the process of validating policy rather than creating a new centralized decision-maker. Researchers can develop long-term security and economic models, while validators, infrastructure providers, applications, and institutions test how those assumptions interact with actual market structure and regulatory conditions. Core developers, in turn, can assess implementation feasibility while also asking whether the proposal has been exposed to sufficient debate. This does not mean giving larger operators more formal decision-making power. A more realistic approach is to make each group’s expertise and incentives explicit, then allow them to challenge one another’s assumptions and conclusions before any single constituency’s interests translate directly into protocol policy.

Such a process would inevitably make Ethereum’s already slow decision-making even slower. But in a more multipolar environment, where the EF plays a smaller role and research organizations, client teams, infrastructure providers, applications, and institutions all have stronger voices, how consensus is reached may matter more than reaching it quickly. Full agreement among every stakeholder is neither realistic nor necessary. At a minimum, however, the assumptions behind a proposed policy, the groups consulted, and the real-world variables considered should be made sufficiently transparent. If the issuance debate ultimately pushes Ethereum to define this process more clearly, today’s governance gap could become the starting point for a consensus model better suited to an increasingly multipolar ecosystem.