Table of Contents
- Key Takeaways
- 1. Author’s Note
- 2. Newly Drafted EIPs
- 2.1 Networking Layer
- 2.2 Data / Messaging / Transaction
- 2.3 Account / Contract / Token Standards / Wallet
- 2.4 Application
- 3. Progression of Existing EIPs
- 3.1 Networking Layer
- 3.2 Messaging / Transaction
- 3.3 Account & Contract & Token Standards & Wallet
- 4. “Food for Thought” — Spotlight on the Institutional ETH Yield Pipeline
Researcher
Related Projects
Key Takeaways
In January, the EIP landscape exhibited a broadly distributed pattern of newly proposed and status-upgraded ERCs, with notable concentration in token extensions, contract architecture improvements, and messaging-related standards. This pattern appears to reflect the combined effects of increasing institutional attention and capital inflows, alongside a recovery in developer momentum following the Fusaka upgrade in December.
At the network layer, EIPs directly associated with the Fusaka upgrade demonstrated tangible progress, whereas rollup improvement proposals (RIPs) showed comparatively limited movement during the same period.
In parallel, as Ethereum continues to be repositioned as a more institution-compatible infrastructure, a particularly salient trend is the growing set of initiatives aimed at constructing institutional-grade onchain yield pipelines, with staking increasingly serving as the primary entry point.
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. Author’s Note
The EIP landscape in January indicates that Ethereum is simultaneously pursuing an expansion of its functional scope and a phase of infrastructure consolidation. Newly drafted and status-upgraded EIPs were relatively evenly distributed across token extension standards, contract architecture improvements, and messaging-related ERCs. This pattern can be interpreted as reflecting a confluence of sustained institutional interest and capital inflows observed over recent months, together with a recovery in development activity following the Fusaka upgrade in December.
From an infrastructure perspective, status advancements were particularly pronounced among EIPs directly associated with the Fusaka upgrade. In contrast, the rollup improvement proposal (RIP) domain exhibited little observable change during the same period. This divergence suggests that, in the near term, development resources are being preferentially allocated toward Layer 1 stabilization and foundational refinement rather than toward rollup-centric standardization efforts.
Meanwhile, in parallel with broader AI-driven trends, discussions around agent-related standards—centered on ERC-8004*, which recently completed its mainnet launch—have emerged as a noteworthy development. These efforts signal Ethereum’s ongoing evolution toward serving as a coordination layer capable of handling identity, authority, and interaction for agent-centric autonomous systems on-chain. As such, they are likely to exert meaningful influence on the future direction of application design and standards development.
*ERC-8004 (Trustless Agents): A framework for representing agents as on-chain entities equipped with standardized identities, reputation, and verification mechanisms.
2. Newly Drafted EIPs
In January, a total of 24 EIPs were newly accepted into the Draft stage, marking an increase of 14 proposals compared to the previous month. Among these, ERCs accounted for the majority, indicating that recent development activity has been largely concentrated around application-facing standards.
Below, we further categorize the newly drafted EIPs by domain and highlight proposals that merit closer examination.
2.1 Networking Layer
2.1.1 EIP-8141: Frame Transaction
Ethereum’s existing transaction model is built around a fixed ECDSA signature scheme and externally owned accounts (EOAs). This design choice was well suited to the network’s early emphasis on simplicity and security. Over time, however, it has become increasingly restrictive as Ethereum has sought to support more flexible validation logic, a wider range of signature schemes, and, eventually, new cryptographic primitives such as post-quantum signatures. As authentication requirements and execution conditions grow more complex, a transaction model centered on a single signature and a single account begins to show its limits.
Several proposals—most notably those under the umbrella of account abstraction—have attempted to address these constraints. ERC-4337, for example, introduced smart contract accounts that allow signature verification and gas payment logic to be customized. However, the transaction layer itself remained unchanged, still assuming an ECDSA-based entry point. As a result, alternative validation schemes could only be handled indirectly inside smart contracts, leaving the protocol, mempool, and block builders largely unaware of the underlying logic.
EIP-7702 moves partway toward resolving this by allowing EOAs to temporarily delegate execution to smart contract code on a per-transaction basis, improving UX and reducing migration friction. Still, the transaction format and validation assumptions remain fundamentally tied to ECDSA. Taken together, these efforts show that while account abstraction has made meaningful progress at the functional level, the transaction model itself has remained largely intact.
EIP-8141 (Frame Transactions) takes a more structural approach. Rather than incrementally extending the existing format, it introduces a new transaction model in which validation, execution, and gas payment are represented as independent “frames.” In this design, a transaction is interpreted not as a single signed object, but as a composition of multiple frames whose combined logic determines validity and execution.
The key idea behind frame transactions is programmability and composability at the transaction level. By decoupling transactions from a single-account, single-signature assumption, EIP-8141 enables the network to process different validation and execution frames either sequentially or conditionally. This makes it possible to define wallet UX, authentication models, and gas sponsorship mechanisms directly within the transaction structure itself, rather than relying on indirect patterns implemented at higher layers.
The technical rationale becomes more evident when viewed through the lens of standardization. While proposals such as EIP-2718 previously enabled the extension of transaction types themselves, flexibility in signature schemes and validation logic remained fundamentally constrained. EIP-8141 addresses this limitation by allowing mempool policies, builder-side transaction acceptance criteria, and paymaster structures to be expressed at the level of individual frames. In doing so, it offers a more extensible approach in which the protocol is no longer anchored to a single signature scheme, but can instead support multiple validation models in parallel.
As a consequence, EIP-8141 is likely to exert influence across a broad range of domains, including mempool policy design, MEV dynamics, and the transaction economy more generally. By making the conditions under which transactions enter the mempool and are ultimately included in blocks more explicit, frame transactions create room to reshape order flow and the associated incentive structures. Looking further ahead, particularly in the context of a post-quantum threat model, this framing also provides a structural foundation for allowing new cryptographic schemes to coexist with ECDSA, or for enabling a gradual transition across multiple schemes without imposing abrupt protocol-level breaks.
From this perspective, EIP-8141 should be understood as more than a short-term UX-oriented improvement. Rather, it represents a foundational initiative aimed at enabling Ethereum to evolve over the long term while preserving both scalability and security.
2.1.2 EIP-8125: Temporary Contract Storage
Source: EIP-8125
For years, Ethereum has faced structural pressure stemming from the continuous accumulation of persistent state, creating challenges across scalability, decentralization, and long-term maintenance costs. In practice, a large portion of smart contract storage slots are written once and rarely, if ever, read again. Nevertheless, these slots remain permanently embedded in the global state, increasing node operating costs, prolonging sync times, and degrading execution efficiency over time. These dynamics have motivated a series of protocol-level discussions and proposals—including stateless clients, state expiry, and Verkle trees—each aimed at reducing the burden of state storage and proof generation.
EIP-8125 is one such proposal that directly addresses the problem of unbounded state growth by introducing a more nuanced storage model. Whereas the existing SSTORE / SLOAD mechanism assumes permanent persistence by default, EIP-8125 proposes the notion of bounded-lifetime storage, namely a temporary storage space whose contents remain valid only for a limited period. This allows data that does not require long-term persistence—such as values referenced across a small number of transactions, session-like data, or cache-style intermediate states—to avoid being unnecessarily committed to Ethereum’s long-term state.
Concretely, EIP-8125 defines two new EVM opcodes - TMPSTORE(key, value) writes a value into a contract’s temporary storage, while TMPLOAD(key) retrieves it. This temporary storage is retained for a protocol-defined duration (TEMP_STORAGE_PERIOD) and is then automatically cleared. By cycling through two period slots, the design guarantees predictable semantics in which data persists for at least one period and at most two periods. In this sense, temporary storage occupies an intermediate position: unlike transient storage (EIP-1153), which disappears at the end of a transaction, it does not vanish immediately; yet, unlike permanent storage, it is not retained indefinitely.
Importantly, EIP-8125 does not directly alter the structure of the state trie itself. Instead, it functions as one component within a broader roadmap focused on constraining state growth. By providing an explicit storage tier for temporary data at the protocol level, developers are encouraged to make more deliberate choices about what truly belongs in permanent storage. Over time, this can enable application architectures that are inherently more state-efficient and better aligned with the long-term sustainability of the network. While the underlying issue of storage being economically underpriced remains unresolved, EIP-8125 nonetheless represents a meaningful step in reinforcing Ethereum’s broader direction toward mitigating state bloat.
2.1.3 EIP-8115: Batch priority fees at end of block
Since the introduction of EIP-1559, Ethereum’s fee mechanism has been designed around a dynamic supply–demand model that separates the base fee from the priority fee. Under the current execution model, however, priority fees are credited to the recipient account immediately as each transaction is executed, rather than being settled at the block level.
While this approach is straightforward, it introduces several technical constraints. Crediting priority fees on a per-transaction basis complicates parallel execution, increases state dependencies on both the mempool and the recipient account, and makes accurate fee accounting more difficult. In effect, the continuous, transaction-by-transaction updating of priority fee balances becomes a bottleneck as Ethereum seeks higher throughput and clearer accounting semantics.
EIP-8115 proposes a different execution model to address these limitations. Instead of settling priority fees incrementally, the proposal introduces a batching mechanism in which all priority fees accrued within a block are aggregated and settled only after all transactions in that block have finished executing. Under this design, the fee recipient is updated once at the final stage of block processing, rather than repeatedly during transaction execution.
This change has several practical implications. By decoupling transaction execution from immediate fee settlement, the proposal makes parallel execution more tractable and reduces reliance on the recipient account’s intermediate balance or solvency during execution. As a result, execution traces become easier to reason about, accounting accuracy improves, and overall fee settlement efficiency is enhanced. At the same time, mempools and block builders can more consistently predict when and how priority fees are realized, while fee recipients gain greater certainty around the availability and usability of earned fees starting from the subsequent block.
Taken together, EIP-8115 is likely to influence a broad range of infrastructure components, including parallel execution strategies, MEV pipelines, block builder architectures, and execution-layer optimization approaches. Although it may require builders to adjust aspects of their infrastructure or liquidity management practices, the proposal represents a meaningful step toward a more efficient and transparent fee settlement model as Ethereum continues to evolve.
2.1.4 Others
2.2 Data / Messaging / Transaction
2.2.1 EIP-8123: RPC Method for Transaction Gas Limit Cap
EIP-8123 defines a new JSON-RPC method, eth_txGasLimitCap, which allows nodes to directly expose the maximum transaction gas limit (tx.gas) permitted by the network. The proposal aims to standardize how this upper bound can be queried, rather than inferred indirectly.
Previously, determining the effective transaction gas limit required observing failed transactions or inspecting client source code. As a result, wallets, SDKs, bundlers, and other tooling were forced to rely on non-deterministic heuristics or external assumptions when estimating gas limits. Although protocol-level transaction gas caps—such as those introduced by EIP-7825—have been deployed, the absence of an official query interface meant that uncertainty around gas limits persisted, both for tool developers and for end users.
EIP-8123 is intended to bridge this gap by providing developers and wallet designers with a clear and reliable mechanism to retrieve the current gas limit cap, including caps that may vary across environments or change following protocol upgrades.
With this standard in place, wallets, SDKs, and other RPC-based services can surface accurate gas limit information without relying on prior simulation or guesswork. This directly improves the robustness of transaction construction logic and enhances overall user experience. Importantly, the method is designed to return not only caps derived from protocol-level rules such as EIP-7825, but also policy-based limits configured by individual networks*. As a result, interoperability and predictability across chains can be meaningfully improved. Wallets are less likely to submit transactions that exceed network limits and fail unnecessarily, while clients gain a standardized way to make their gas policies explicit.
*For example, Arbitrum and Polygon enforce a gas limit cap of 32,000,000 rather than the default value of 2²⁴.
2.2.2 Others
2.3 Account / Contract / Token Standards / Wallet
2.3.1 ERC-8092: Associated Accounts
Most modern IT services operate either as multi-functional platforms or as tightly interconnected systems that generate synergetic value through integration. As a result, users have grown accustomed to environments in which multiple services are seamlessly linked under a single identity. This structural shift has not only improved usability and convenience, but has also strengthened trust, operational efficiency, and scalability across digital ecosystems.
Smart contract platforms, in principle, offer similar potential. By bringing real-world value and assets into a programmable digital environment, they function as IT infrastructure capable of supporting a wide range of application use cases. In practice, however, significant barriers remain at the level of user experience and adoption - complex account management, siloed identities, and fragmented context across applications continue to limit broader and more cohesive onchain activity.
To be sure, Ethereum’s infrastructure has matured rapidly over the past several years. Beyond scalability improvements, abstraction layers—most notably account abstraction—have substantially improved wallet UX and reduced the cognitive burden associated with gas management and signature schemes. Yet a more fundamental limitation persists. Ethereum still lacks a standardized way to represent multiple addresses used by a single individual or organization as a coherent identity, or to cryptographically prove their association onchain. As a result, users are forced to manage multiple accounts in isolation, while external observers have no reliable means of determining whether those accounts belong to the same entity, constraining the design of more expressive and integrated applications.
ERC-8092 emerges directly from this problem space. The proposal defines a mechanism through which relationships between accounts can be publicly declared, verified, and—when necessary—revoked onchain, using public-key–based cryptographic signature payloads. In doing so, it enables explicit representation of account associations without relying on centralized intermediaries. Importantly, this is not merely about “linking multiple addresses,” but about “allowing individuals or organizations to define and manage the scope of accounts that collectively represent them”.
Source: ERC-8092
At the core of this design is the AssociatedAccountRecord data structure, which explicitly encodes the relationship between two accounts onchain.
The initiating account and the approving account are stored using the ERC-7930 binary address format, alongside timestamps that define the validity period of the association. Optional fields such as interfaceId and data further allow the relationship to be scoped to a specific interface, use case, or additional contextual metadata, making the structure adaptable across a wide range of application scenarios.
The introduction of this model unlocks a broad set of potential use cases - these include multi-chain identity systems, DAO governance structures, institutional wallet architectures, permission management across multi-application environments, and scenarios that require a careful balance between compliance and privacy.
2.3.2 Others
2.4 Application
2.4.1 ERC-8034: Referable NFT Royalties
One of the earliest reasons smart contract platforms attracted widespread attention was their ability to project real-world value directly into a digital environment through authenticity and transparency. This potential was first explored most actively in the NFT space, where creators and intellectual property could be represented onchain, and royalty structures could, at least in theory, be reimagined.
Within this context, ERC-2981 introduced a standardized interface for querying royalty recipients and amounts during NFT sales, prompting adoption by major NFT marketplaces. However, ERC-2981 ultimately remained a narrowly scoped solution. It answered the question of “who should be paid, and how much,” but did little to capture the broader and more nuanced contexts that royalties often imply.
At its core, ERC-2981 assumes a one-dimensional calculation model: given a (tokenId, salePrice) pair, it returns a single (receiver, royaltyAmount). This design leaves no room to account for the nature of a transaction or the relational context surrounding it. As a result, more expressive royalty schemes—such as multi-recipient splits, time-varying royalty rates, or differentiated royalties across secondary, tertiary, and subsequent sales—cannot be represented at the standard level. Moreover, the actual enforcement of royalties is left entirely to marketplace implementations and policies, creating a paradox in which a core revenue mechanism for onchain assets ultimately depends on offchain trust.
Against this backdrop, a growing line of thinking has emerged that reframes NFTs not as isolated tokens, but as elements within a broader network of relationships. In particular, the concept of Referable NFTs (rNFTs), introduced by ERC-5521, makes these relationships explicit by recording references between NFTs onchain using a directed acyclic graph (DAG) structure. By distinguishing between referring NFTs and referred NFTs, and by incorporating time-based indicators at creation, the model allows flows of creation, derivation, and collaboration to be traced. In this framing, NFTs evolve from simple ownership objects into participants in a lineage of creative contribution.
Source: ERC-8034
Building on this rNFT foundation, ERC-8034 proposes a more expressive and comprehensive royalty mechanism that operates directly over DAG-structured relationships. Rather than assigning royalties to a single recipient, the standard enables royalty distribution across multiple parties—including both base NFTs and their referenced counterparts—while also providing controls over how royalties propagate through the graph.
Notably, ERC-8034 is designed independently of ERC-2981 and is oriented toward a different abstraction layer. It provides the groundwork for explicitly declaring and verifying, onchain, that multiple addresses may collectively represent an individual, an organization, or a collaborative entity. By extending the unit of royalties, rewards, and attribution from individual addresses or single transactions to an entire relationship graph, the standard aims to support a more cooperative and equitable onchain economic model—one in which contribution and value creation are recognized across interconnected creative networks.
2.4.2 Others
3. Progression of Existing EIPs
During January, excluding the 24 EIPs newly accepted into the Draft stage, a total of 27 existing EIPs experienced status changes. Among these, 19 proposals advanced to subsequent stages on the path toward finalization—namely Final, Last Call, Review, or Draft—indicating continued forward momentum across several areas of the protocol and standards stack.
By contrast, seven proposals did not progress to the next stage. Five EIPs transitioned into a Stagnant state (i.e., EIP-5920, EIP-7612, EIP-7793, EIP-7886, and EIP-7958). In addition, two proposals moved backward from the Review stage to Draft (i.e., ERC-7828 and ERC-8004), while one proposal—RIP-0—was removed entirely.
The EIPs that made meaningful progress this month were largely concentrated in two categories: EIPs directly related to the Fusaka upgrade*, and ERCs implemented at the application and standard layer.
Among EIPs (among non-ERC proposals), several are particularly noteworthy. These include EIP-7708, which introduces automatic logging for all ETH transfers—across transactions, CALL, and SELFDESTRUCT—to improve traceability of ETH movements. Also of note are EIP-7823, which caps the input size of the MODEXP precompile at 8,192 bits to improve safety and predictability, and EIP-7883, which recalibrates the gas costs associated with that operation. Additional progress was observed in EIP-7910, which defines a new JSON-RPC method (eth_config) for exposing node configuration information, as well as EIP-7951, which introduces a precompile for efficient verification of secp256r1 elliptic-curve–based ECDSA signatures at the protocol level.
On the ERC side, several proposals stand out. These include ERC-5516, which defines a Soulbound multi-owner token standard designed to support issuance to multiple owners while maintaining structured ownership relationships; ERC-7674, an extension standard that enables transaction-scoped temporary approvals for ERC-20 tokens, improving both security and gas efficiency; and ERC-7943, a generalized RWA interface standard aimed at enhancing onchain interoperability by standardizing compliance and control mechanisms for real-world asset tokens. Also noteworthy is ERC-7994, which introduces a “Purpose-Bound” token model in which ERC-20 tokens can only be used once predefined programmable conditions are satisfied.
*For reference, a total of twelve EIPs are directly associated with the Fusaka upgrade: EIP-7642, EIP-7823, EIP-7825, EIP-7883, EIP-7892, EIP-7910, EIP-7917, EIP-7918, EIP-7934, EIP-7935, EIP-7939, and EIP-7951.
Additional EIPs of interest are listed below.
3.1 Networking Layer
3.2 Messaging / Transaction
3.3 Account & Contract & Token Standards & Wallet
4. “Food for Thought” — Spotlight on the Institutional ETH Yield Pipeline
2025 marked a clear inflection point in institutional interest in blockchain infrastructure. Among the various networks, Ethereum has attracted disproportionate attention, being re-evaluated as the only legacy infrastructure that simultaneously satisfies two critical properties: a track record of uninterrupted network operation since launch, and the highest degree of decentralization at scale.
In particular, changes discussed under the Hegota track following the Fusaka upgrade in December have focused less on introducing new features and more on refining the stability, usability, and operational efficiency of the existing protocol. For institutions—where predictability and risk management are paramount—this shift is a compelling signal. Ethereum, in this sense, is transitioning away from an experimental platform and toward a more orderly, institution-compatible infrastructure on which regulated capital can confidently build.
Alongside this evolution, experimentation around real-world asset (RWA) tokenization on Ethereum has accelerated. Since early 2025, several RWA-related standards—including ERC-7518, ERC-7943, and ERC-8106—have advanced in discussion or seen status upgrades. Together, these developments suggest that Ethereum is systematically laying the rails required to accommodate real-world and financial assets onchain. From an institutional perspective, this reframes ETH not merely as a crypto-native asset, but as a foundational layer for settlement, collateralization, and asset management within an emerging onchain capital market. As a result, holding ETH becomes a strategic allocation, and the subsequent question naturally shifts to how that ETH can be deployed to generate sustainable returns.
One of the most direct answers to this question is ETH staking. Recent movements across Ethereum’s roadmap and EIP landscape increasingly emphasize making the staking lifecycle more programmable, while simultaneously improving operational efficiency for large participants without compromising decentralization.
Proposals such as EIP-7251, which introduces validator consolidation, reduce the operational overhead associated with managing validators in discrete 32 ETH units, thereby creating a more institution-friendly operating environment. Similarly, EIP-7002 expands the design space for exit and withdrawal strategies at the execution-layer level, enabling more precise control over liquidity and risk. In parallel, the growing adoption of Distributed Validator Technology (DVT) reflects a broader effort to decouple slashing and downtime risk from single operators, and to standardize operational risk across distributed setups*.
On top of this staking infrastructure, also liquid staking tokens (LSTs) have evolved well beyond their original role as simple staking receipts. Today, they function as some of the most important forms of productive collateral across DeFi. When major protocols such as Aave describe stETH and wstETH as collateral that continues to accrue staking rewards while being deployed, they are effectively recognizing a new capital unit—one that combines ETH exposure with a baseline yield. Building on this foundation, protocols such as Pendle, Morpho, and vault architectures based on ERC-4626 further decompose and recombine ETH-based returns, introducing layers that curate risk and transform staking yield into a programmable financial primitive.
Taken together, the progression from “ETH staking to LSTs and onward to (LST-based) DeFi vaults” is rapidly converging into a coherent onchain yield supply chain. Within this framework, the core competitive dimension is no longer headline APR, but rather where risk is assumed, and who is responsible for structuring, pricing, and operating it. As more ecosystem players experiment with and extend this pipeline, ETH increasingly resembles not just a crypto asset, but a core rail of an internet-native capital market—one that integrates baseline onchain yield, standardized collateral, financial product design, and a growing risk management and operations layer**.
*As a representative example, SSV—one of the leading networks providing DVT—has recently announced the introduction of $SSV staking. This initiative aims to align validators, operators, and token holders around ETH-denominated incentives, reinforcing a more sustainable revenue–cost structure for Ethereum’s extended infrastructure. In doing so, it is expected to indirectly support and expand demand for ETH staking.
**In the same vein, Lido’s recently introduced Lido V3 stVaults initiative deserves particular attention. Designed as a modular vault framework, stVaults enables institutions and protocols to construct customized staking configurations by combining validator composition, fee structures, and risk management criteria with a range of DeFi strategies—including lending, leverage, and delta-neutral positioning. In effect, stVaults represents a concrete attempt to complete an institution-ready yield pipeline built directly on top of Ethereum staking.
Source: https://v3.lido.fi/
