Blog

Hi everyone, I’m Jason Cui from imToken Labs. I’m really glad to be here today to talk about how account abstraction unlocks new applications. Today’s talk is divided into four parts. First, I’ll explain what account abstraction actually is. And then, we’ll walk through some exciting new applications unlocked by its three key components — verification, execution, and gas abstraction. So, what exactly is account abstraction? To answer that, let’s take a step back and see what a blockchain account really is. A blockchain account is the interface between the user and the blockchain. It tells us three things: who can use the account — that’s account verification,what the account can do — that’s account execution,and how gas is paid — that’s fee payment. Traditionally, users interact with the blockchain through EOAs. These accounts are quite limited — they rely on a fixed verification method (usually ECDSA signatures), can only be triggered directly by the user to call a single method on a single contract, and always require gas fees to be paid upfront in ETH. But account abstraction changes the game. It allows for programmable verification, supports both self-executed and externally triggered transactions across multiple methods on multiple contracts, and enables fee payment — you can pay before or after execution, and using custom tokens, or even completely free if sponsored. This added flexibility unlocks a wide range of innovative applications. Let’s start by looking at some use cases of Verification Abstraction — it allows us to rethink how we prove ownership of an account. Instead of relying solely on ECDSA private keys, we can now use passkeys, which offer a similar level of security as hardware wallets, but with better user experience and no need to manage seed phrases. We can also imagine accounts being controlled through email. Since email is widely integrated into Web2 services, using it to manage accounts could make onboarding much easier and help bridge the gap between Web2 and Web3. Furthermore, we might even see AI agents have their own accounts — not just making them more decentralized, but turning them into fully independent digital entities that can manage assets and interact with the blockchain by themself. Verification abstraction also enables more flexible permissions. Instead of giving full access all the time, users can now grant limited or temporary access to applications using session keys or sub-accounts. It allows applications to act on behalf of users for certain tasks, without needing approval for every single transaction — which is especially helpful in on-chain games or automated DeFi, where too many prompts would ruin the experience. Another powerful feature is account recovery. Since the verification logic is programmable, developers can build in ways to recover accounts if keys are lost or stolen — something that’s not possible with EOAs. Now let’s look at what Execution Abstraction makes possible. A great example is cross-chain execution. Right now, most cross-chain protocols just move assets around — that’s because EOAs can’t be triggered externally. But with execution abstraction, we can send not just assets but also instructions. Executors can trigger the user’s account on the destination chain and carry out the transaction on behalf of users. Another exciting capability is batch execution. Instead of sending multiple separate transactions—like approving a token and then making a swap—users can bundle those actions into a single transaction. This not only saves gas, but also improves composability and user experience.   Even more exciting is the ability to combine actions across multiple DApps. Today, users are limited to the features offered by DApps. But with Execution Abstraction, they can mix and match functionality from different protocols. This unlocks a whole new market — batch strategy markets — where users can create or adopt batches to execute complex strategies. Now let’s move on to Gas Abstraction. Thanks to gas abstraction, gas fees have become much more flexible. Users can now have their fees sponsored based on who they are—or what they do. Users can also pay gas with stablecoins like USDC, making it much easier for newcomers to get started. Even better, users don’t have to pay gas upfront. With deferred fee payment, the transaction goes through first, and gas is paid afterward. That’s huge for onboarding — new users can just click a link, get their assets, and use them to pay for gas, no ETH required in advance. It also lets users pay gas with tokens received from a swap — so arbitrage traders no longer need ETH to cover fees. Privacy protocols benefit as well. Right now, withdrawing from a privacy pool requires sending ETH to the destination address in advance, which can expose the user. But with gas abstraction, users can withdraw first and then pay fees using part of the withdrawn assets — keeping their identity private. And that brings us to the end of the presentation. I hope this talk has helped clarify what account abstraction is all about — and how it unlocks new applications through verification, execution, and gas abstraction. Thanks so much for listening!

Hello everyone, I’m Nic, a blockchain developer at imToken Labs. Today, I’ll share how to build a safer and more user-friendly AA (Account Abstraction) wallet using ​Validation-Centric Design. Today's talk will be divided into three parts: How are AA wallets built today Validation-Centric Design Technical Challenges and Solutions ​1. How Are AA Wallets Built Today AA wallet, a smart contract wallet implemented through Account Abstraction technology, features core functionalities including: You can use Multi-Sig, Passkey or Email to authorize your transactions You can pay gas fee with USDC/USDT, credit card or even get sponsored You can recover your wallet if key lost or stolen You can authorize third party to perform actions on your behalf However, most AA wallets today follow an ​Account-Centric Design, characterized by: Account holds the user’s assets Account contains the validation logic, payment logic, recovery logic etc. Account is upgradeable (optional) Account is modular (ERC-6900, ERC-7579, etc.) This approach creates friction for users switching between AA wallets. Unlike EOA wallets, where users seamlessly switch wallets via private keys or seed phrases, AA wallets require users to ​create new accounts and ​manually migrate tokens between wallets.  This process is cumbersome, risks asset loss, and degrades user experience. Moreover, while contract upgradability facilitates feature enhancements and updates, it also introduces potential risks. Take the 2024 Ronin Bridge hack as an example—this incident highlighted the security vulnerabilities that upgradable contracts may pose.  At the time, the Ronin Bridge contract defined two initialization functions for v3 and v4. However, only the v4 initialization function was executed, while v3 was overlooked, leading to a contract vulnerability that resulted in a loss of approximately $12 million.   Such mistakes often stem from the complex challenges faced during the version iterations of upgradable contracts. Imagine a scenario where the latest version of a wallet has been upgraded to v2.0.0, but a user, Bob, is still using an outdated version, v0.1.0. How can his wallet be securely upgraded to the latest version?   This requires ensuring that every parameter initialization during the step-by-step upgrade process—from the old version to the final v2.0.0—must be executed accurately. For developers, this presents a significant challenge, as any misstep could lead to severe security vulnerabilities.   This also explains why, even for projects like Ronin Bridge, which are maintained by large teams of professional developers, it remains difficult to completely avoid errors caused by the complexity of upgradable contracts. ​2. Validation-Centric Design The core idea of an AA wallet built with Validation Centric Design is to separate complex functionalities—such as verification logic, payment logic, and upgradability—from the account contract, leaving only the most fundamental functions: asset holding and DApp interaction. By doing so, the account contract is significantly simplified, reducing its complexity and maintenance burden. The other complex functionalities are integrated into AccountEntry, which serves as the "entry point" for the account contract, handling all advanced logic.  Developers can focus on designing the AccountEntry contract, while users remain unaware of its existence and can seamlessly switch between different wallets without transferring assets. This design offers several key advantages: Secure iteration: Developers can deploy new contracts at any time (e.g., upgrading from simple signature verification to multi-signature + biometric authentication) without requiring users to migrate their accounts. Agile development: It supports rapid adaptation to new standards or frameworks, preventing legacy technical debt from hindering progress. Seamless user experience: Users can enjoy new features through the wallet interface without being aware of changes in the underlying contract. However, if the AccountEntry contract is designed to be upgradable and contains vulnerabilities, AA wallets built with Validation-Centric Design may still be vulnerable to attacks. Beyond these advantages, Validation Centric Design also introduces additional features that further enhance both user experience and development flexibility. Multi-Account Management With Validation Centric Design, users can easily manage multiple accounts. Due to the simplicity of account contracts, users can create multiple accounts, switch between them flexibly, and even control multiple accounts within a single transaction.  ​3. Technical Challenges and Solutions ​1. How to pay the gas fee? Since AccountEntry initiates transactions but holds no user funds, paying gas fees requires creative solutions: ​Option 1: Store user funds in the AccountEntry Contract. Drawback: Users must manually fund the contract. ​Option 2: Transfer funds from the Account Contract to the AccountEntry Contract during transactions. Drawback: Violates ERC-4337 rules and some bundlers don’t support  ​Option 3 (imToken’s Approach): Use ​Paymaster to prepay gas fees and later deduct costs from the user’s account. Advantage: Bypasses rule limitations. Challenge: Requires additional contract management and security audits. ​2. Not easy to view on explorer The Account is not the userOp.sender—the AccountEntry is. This makes it difficult for users to see which of their accounts executed a transaction. The same issue applies to Meta Transactions, contract wallets like Safe, and child/sub-accounts.  Current workarounds rely on custom wallet parsing to display user-centric transaction details. Thank you for your listening!

From Telecom Standards to Blockchain In today’s globalized world, whether for travel or business, people expect seamless network access across different regions. Unified technical standards enable mobile phones and networks from different providers to work together effortlessly. Despite variations in technical standards or frequency bands, they adhere to common protocols, ensuring global compatibility. The blockchain space, too, requires similar standardization efforts to achieve seamless interoperability. The State of Ethereum: A Fragmented User Experience In 2020, Ethereum co-founder Vitalik Buterin introduced a Rollup-centric roadmap, sparking rapid growth in layer 2 technology. This advancement has significantly lowered transaction fees and increased processing speed, offering a vital solution to Ethereum’s congestion challenges. Think of Ethereum’s mainnet as a busy highway, responsible for transaction security and execution. As traffic increases, congestion becomes inevitable. Layer 2s act like overpasses, expanding capacity to ease congestion while securely settling transactions on the mainnet. However, interoperability between layer 2s remains limited—like overpasses without proper connections, making it difficult for transactions to flow seamlessly. This fragmentation disrupts the user experience and hinders Ethereum’s broader ecosystem growth. Ethereum Layer 2 Ecosystem Map New Technologies for Seamless Connectivity The Ethereum community is driving innovation with solutions like Interop (a cross-chain communication protocol) and the Open Intents Framework, designed to enable seamless interoperability between layer 2s. These technologies allow users to transfer assets across layer 2s within a single wallet and complete transactions in seconds. As a leading wallet in the Ethereum ecosystem, imToken collaborates closely with the community to enhance user experience through technical innovation. At ETHTaipei, imToken invited around 200 blockchain developers to test its Send via Link feature on imToken Web. This feature allows users to create an on-chain red packet without knowing the recipient’s address. They simply deposit tokens and share a link via social platforms like LINE, Twitter, or Telegram. When the recipient clicks the link, a smart contract wallet is instantly generated using a passkey, enabling gas-free, mnemonic-free token claims. Traditionally, entering the Ethereum ecosystem required users to understand mnemonic phrases, creating a high entry barrier. Claiming airdrops or transferring tokens also required ETH for gas fees, posing challenges for users with insufficient balances. imToken Web removes these barriers with gas abstraction, allowing users to claim tokens without paying transaction fees. This dramatically improves accessibility and usability. Additionally, Send via Link transforms token transfers by leveraging social networks rather than requiring wallet addresses—turning tokens into a form of social currency for red packet gifting, community rewards, and beyond. Streamlined Cross-Layer 2 Token Transfers with imToken Web imToken Web greatly simplifies cross-layer 2 token transfers. Users can specify the recipient's network in two ways: Address + Prefix: For example, op.imtoken.eth indicates the corresponding address of  imtoken.eth on Optimism. Manual Selection: After entering imtoken.eth, users can manually select the network for the transfer. Previously, transferring tokens between layer 2s—such as from Arbitrum to Optimism—required using a cross-chain bridge and ensuring the Arbitrum account had ETH to cover gas fees. With imToken Web, users can pay gas fees with any token in their account. During the ETHTaipei event, imToken even covered the gas fees, enabling users to initiate transfers without paying. Plus, users can directly select the recipient’s network on the transfer page, streamlining the process. Next, we’ll continue to build on our technical strengths and innovate on the UI to provide an even smoother user experience. Why Ethereum? Despite facing challenges, Ethereum remains one of the most dominant ecosystems in the blockchain space. Currently, the total value locked (TVL) in the cryptocurrency market stands at approximately $286 billion, with Ethereum (including the mainnet and layer 2 networks) accounting for 60% to 70% of this total. This shows that the majority of tokens in the market are still concentrated on Ethereum. Blockchain TVL Distribution Ethereum’s stablecoins alone have reached $120 billion, representing nearly 54% of the total stablecoin market ($224 billion), with a consistent upward trend. Whether by asset size or user base, Ethereum continues to lead as the largest ecosystem in the blockchain space. We believe this market dominance will unlock significant opportunities for Ethereum. Furthermore, as layer 2 network fees continue to decrease, the use of stablecoins on Ethereum is expected to expand. While there is some fragmentation between Ethereum’s DeFi, DApps, layer 2 networks, and wallets, the integration of cross-chain communication protocols (Interop) can seamlessly connect these components. This integration will enhance ecosystem efficiency, improve user experience, and drive broader adoption. Looking Ahead The goal of technology is to lower barriers, not create them. Through innovations like imToken’s on-chain red packets, gas-free transfers and gas abstraction, we aim to transform blockchain from a tool for tech enthusiasts into an accessible, inclusive financial infrastructure—much like the internet evolved from a niche technology to a universal tool.  When blockchain technology truly integrates into social, payment, and collaborative activities, inclusive finance will move from an ideal to a reality.

This article is compiled from a presentation by Alfred from imToken Labs at ETHTaipei Hello, I am Alfred. Today I will give a talk about the issues of 4337 on L2s. I currently work at imToken Labs as a blockchain developer. You can find more information on my persional website. Or discuss anything with me through the twitter. What Causes the Difference? We often subconsciously assume that the implementation of ERC-4337 should be the same across different EVM-compatible Layer 2s. However, due to protocol differences and certain synchronization challenges, implementing 4337 on L2s is not the same as on Ethereum. Protocol Differences: Variations in EIPs/RIPs, hard forks, opcodes, gas structures, and fee mechanisms. Asynchronous Nature: you cannot simply send one transaction and expect it to affect accounts across all chains simultaneously. Definition of a Multi-Chain Account In the past, this distinction was rarely discussed for EOAs. Even though assets were not inherently synchronized, EOAs shared the same address and private key across all chains, meaning the authorization mechanism was identical. However, contract/AA accounts operate as smart contract wallets. This means that across different chains, the account addresses, authorization methods, and even ownership states may differ, leading to more than just asset fragmentation. Authorization Issues The Challenge of Asynchronicity Ownership Issue Ensuring Cross-Chain Consistency Let’s take the discussion of account further. If we change account ownership (in brief, modifying a variable) on Chain X, how do we ensure that Chain Y updates as well? What happens if transferOwnership() succeeds on one chain but not another? This creates a desynchronization risk in ownership states, leading to several challenges: Changing signature verification mechanisms (e.g., switching to Passkeys or multisig) requires updates on all chains. If a user's control key is lost, how can we recover their account across all chains? These questions highlight the fundamental challenge of managing AA accounts in a multi-chain environment, requiring new solutions for synchronization, security, and key recovery. Solutions Is there any protocol that can automate multi-chain authorization updates or make management easier? Multi-Chain Signing: Signing Once, Executing Across Chains One approach is Multi-Chain Signing, where users sign a single userOp once and broadcast it across multiple chains, eliminating the need to sign individually for each chain. There are currently two main implementation methods: Coinbase’s Approach Directly modifies the userOp signature. Requires a consistent nonce strategy (ensuring nonce increments correctly across all chains). Signature does not include Chain ID, allowing the same signature to work across chains. This method is limited to specific operations (e.g., ownership updates, contract upgrades), and all chains must succeed together—otherwise, nonce desynchronization could occur. Zerodev’s Merkle Tree Approach Groups different chain-specific operations into a Merkle Tree. Combines multiple userOpHash values from different chains into a single Merkle Root. The user signs just once on the Merkle Root, allowing execution across multiple chains. Both methods share a common trait: they bypass the Chain ID restriction during signature verification. Coinbase’s approach ignores Chain ID altogether. Zerodev’s approach includes all possible Chain IDs within the signed Merkle Root. Wallet Provider Support Another solution is to rely on wallet providers to manage multi-chain authorization. Web-based wallets need a database to track the user's current authentication methods per chain: X Chain uses PassKeyX B Chain uses PassKeyB C Chain uses ECDSA This ensures a seamless and secure user experience—users shouldn't have to guess or check an explorer to determine which signature mechanism is in use. Additionally, wallets should provide: Alerts when different chains have inconsistent authorization mechanisms. A one-click sync function to unify authorization methods across all chains. By implementing these solutions, we can reduce complexity and improve the usability of multi-chain AA accounts. Address Issues Why It Matters A moment of silence for Wintermute Having the same address across chains is crucial because it can lead to significant issues: User Experience Degradation From an EOA perspective, users expect their account address to be the same across all EVM-compatible chains. Asset Transfer Risks A sender might unknowingly send funds to a recipient's address on a chain where they don’t have control, leading to potential loss of funds. Cross-Chain Bridges Assumptions Some bridges assume the same address exists on both chains when transferring assets. If users aren’t careful, they may bridge assets to an address they don’t control on another chain. ENS Name Risks Users who register their ENS name on different EVM-compatible chains using the same address might face unintended consequences. ENS assumes that your registered address matches your Ethereum Mainnet address, which may not always be the case on L2s. Caused by Hardforks Differences in contract addresses across chains are primarily due to protocol differences, including: Whether an L2 follows L1 hard forks in a timely manner. Whether an L2 supports all L1 precompiled contracts and EIPs/RIPs. Unique design choices in L2 protocols, such as: zkSync using a different encoding method for CREATE/CREATE2 opcodes, affecting address derivation. Ethereum Mainnet not supporting certain L2-exclusive features, such as RIP-7212 P256 precompiled contract. Why Wasn’t This an Issue Before? Past hard forks, like The Merge (EIP-4399: DIFFICULTY becomes PREVRANDAO), only affected a small subset of contracts, so they were not widely discussed. However, newer changes like PUSH0 impact almost all contracts—making address inconsistency a critical issue today. And The rise of ERC-4337 and smart contract wallets over the past few years has amplified the importance of consistent contract addresses across chains. Some Past and Future Hard Fork Impacts: Shanghai (Shapella) - PUSH0 With the Shanghai upgrade introducing the new PUSH0 opcode, certain chains (such as Arbitrum and Optimism) initially did not support this opcode. Therefore, we need to explicitly specify the EVM version and Solidity compiler version to maintain control over addresses. Our goal is to ensure that the Proxy Factory address remains unchanged. To achieve this, we use: --evm-version paris and --use 0.8.19. This ensures that the PUSH0 opcode is not generated during compilation. Cancun (Dencun) - TSTORE/TLOAD The impact of TSTORE in Cancun may not be as significant as PUSH0, because currently, the Solidity compiler does not allow transient storage to be used as a data storage location in high-level Solidity code. At present, data stored in this location can only be manipulated through inline assembly using the TSTORE and TLOAD opcodes. In the future, once EOF (EVM Object Format) goes live, we will likely encounter similar issues. Solution How can we ensure that the same contract produces identical results across different chains? The simple answer: we must fix both the EVM version and the Solidity version. However, as more hard forks introduce new opcodes, maintaining compatibility will become increasingly complex. For now, we can focus on PUSH0, comparing 0.8.20 vs. 0.8.19 and Shanghai vs. Paris. But once Cancun introduces TSTORE/TLOAD, developers may need the ability to enable PUSH0 but not TSTORE, or disable both. The number of options and decision-making criteria will only grow over time. Open questions: how do we make these choices? Are there any selection methods or decision-making guidelines? Whatever, some key takeaways should be kept in our minds: Do not assume that an account will have the same address across all chains. This should be a fundamental mindset shift. Utilizing ENS can significantly enhance the user experience by providing a more consistent and user-friendly approach to addressing. Fee (PVG) Issues For wallet providers, calculating pre-verification gas on L2 is a challenge because it involves both L2 and L1 data costs, making the setup of PVG difficult. Next, I will explain how to calculate PVG. Recap the PVG The behavior of the Bundler sending userOp to the Entry Point is a regular transaction (a.k.a bundleTransaction), and it is a superset of the Verification Phase and Execution Phase. Specifically, some gas for this action is not defined under the VerificationGasLimit and CallGasLimit. In other words, PreVerificationGas covers all the gas costs that "cannot be checked via changes in gasleft() on-chain." These gas costs are paid by the Bundler. In the image from Tenderly gas profile, you can see how much gas doesn't include within the _validatePrepayment() (Verification Phase) and _executeUserOp() (Execution Phase), it should be covered by bundler. PVG includes the following: The cost of processing a userOp in the EntryPoint contract (bundleTransaction), e.g., 21,000 stipend, as well as additional fees for other operations used in handleOps (expenses outside the Verification Phase or Execution Phase loops). e.g., calldata costs (memory usage/copy in the handleOps function), for example, as the calldata to be processed increases (e.g., from 1 ERC-20 transfer call to 30 calls), Memory Expansion (used by MLOAD/MSTORE like (perWord + 31) / 32) and Intrinsic Gas will also rise. Additional expenses: A fee for prioritizing the bundling of the userOp from the mempool (subsidy). A fee for Bundlers to prioritize their bundleTx with the Block Builder (passed on to the userOp’s sender). Transaction fees on Layer 2 must account for Layer 1 security costs (this is the focus of the current discussion). … The focus of this discussion is not about how much profit Bundlers aim to make. Instead, we will focus on how to reasonably calculate PVG on Layer 2. How to get PVG on L2 TotalCostForBundleTx = L1Cost + L2Cost The total transaction cost that the Bundler needs to pay when submitting a bundleTx on Layer 2 must include both Layer 1 and Layer 2 costs. L1 Cost refers to the security costs of this transaction on Layer 1, which include the Rollup Contract processing fees and calldata storage fees. L2 Cost refers to the processing costs of this transaction on Layer 2 (the bundleTx cost). TotalCostForBundleTx = L1Cost + L2Cost = GasPrice * TotalGasUsed The total transaction cost paid on Layer 2 is expressed as GasPrice and TotalGasUsed. Since the transaction occurs on Layer 2, the GasPrice refers specifically to the Gas Price on Layer 2 (e.g., Optimism). TotalGasUsed = L2GasUsed + L1SecurityFee = L2GasUsed + L1CalldataCost / L2GasPrice TotalGasUsed = L2GasUsed + (L1GasPrice * L1CalldataSize) / L2GasPrice Since we need to account for the L1 cost in the TotalGasUsed, the amount of gas required to cover the L1 cost on L2 is defined as L1CalldataCost / L2GasPrice, which represents the L1SecurityFee in terms of how much gas is consumed from the L2 perspective. Through the earlier algebraic calculations, we can derive the "maximum total gas usage" for a userOp on L2, which is: TotalGasUsed = L2GasUsed + (L1GasPrice * L1CalldataSize) / L2GasPrice. TotalGasUsed = (VerificationGasLimit + CallGasLimit) + (PVG) = L2GasUsed + L1SecurityFee = (VerificationGasLimit + CallGasLimit + PVGForL2) + (PVGForL1) PVG = PVGForL2 + PVGForL1 = PVGForL2 + L1SecurityFee = PVGForL2 + L1CalldataCost / L2GasPrice = PVGForL2 + (L1CalldataPrice * L1CalldataSize) / L2GasPrice The total PVG on L2 is composed of two parts: the "L1 security fee" and the "portion related to handling AA transactions on L2, excluding the Verification and Execution Phases". The former has already been defined as L1SecurityFee (or PVGForL1), and the latter is defined as PVGForL2. Thus, the "complete PVG required for this userOp when sent on L2" is: PVG = PVGForL2 + L1CalldataCost / L2GasPrice. Solution Is there a better or simpler way to calculate PVG? Perhaps we can explore one long-term solution with RIP-7560's builderFee: In RIP-7560, the cross-rollup native AA standard is defined, and in the fields definition of a userOp (or what we call RIP-7560 Transaction), PVG is replaced with builderFee, which specifically refers to the L1 data fee. This approach can help clarify the calculation of PVG. The intrinsic portion of PVG (21000 + every byte of data supplied) is set as the constant AA_BASE_GAS_COST. maxPossibleGasCost = AA_BASE_GAS_COST + validationGasLimit + paymasterValidationGasLimit + callGasLimit + paymasterPostOpGasLimit Due to the complexity of calculating PVG, users may be charged what appear to be unreasonable PVG or gas fees. It is advisable to either set up their own Bundler or establish a business partnership with bundlers to maintain stable product operation and optimal earnings. Contract Accessibility Infra will affect contract logic Most EVM-compatible Layer 2 solutions support all of Ethereum's precompiles, but some, like Scroll, may not fully support certain precompiles due to circuit limitations. P256 Verifier: Before the introduction of RIP-7212, we often relied on Daimo's P256 Verifier, which required the chain we wanted to deploy on to have this verifier. However, with RIP-7212 now in place, we need the chain to support the P256 precompiled directly. Service will not affect contract logic, but may affect produce stable Many services depend on nodes, such as Bundlers, Paymasters, and Relayers. Before actually sending transactions or performing signing, they often simulate actions on the chain. For instance, the widely used Alchemy Bundler is expected to support the P256 Precompiled only by Q2 2025. This means there is a gap of more than six months between the deployment of RIP-7212 on Layer 2 and the estimated time when support for it will be available. 🚢 The Fjord upgrade has shipped to OP Mainnet with RIP-7212 now available on the Superchain. Make sure to update your software to take full advantage of the new features: https://t.co/LM3UHnx53R https://t.co/hfdzMjJ2Au — OP Labs (@OPLabsPBC) July 10, 2024 From a product perspective, when we reach a certain scale and aim to keep up with the latest technologies, it’s best to self-host the Bundler and Paymaster. imo devs still feel a lot of complexity, starting from "which bundler and paymaster combination should I choose"? the dev tooling is OK could be 100x better. — Georgios Konstantopoulos (@gakonst) February 20, 2025 Tool will not affect contract logic, but may affect SDK or scripts logic In addition to service support, we must also pay attention to whether development frameworks and tools support the new features (e.g., Foundry, Slither). There is always a period of transition before and after a hard fork, where ecosystem tools need time to catch up. During this period, deploying contracts to the mainnet, launching products, or upgrading contracts can be risky and inconvenient. It’s better to wait until the tools are stable before going live. For example, we frequently use the Foundry Create2 Factory and MultiCall3 contracts. However, if these contracts are not available on the chain, our deployment or testing scripts may become unusable. Conclusion Today's talk explored the complexities of ERC-4337 on Layer 2, covering issues such as account synchronization, authorization mechanisms, address consistency, and PVG calculations. Here are the key takeaways: Cross-chain accounts require new synchronization and authorization mechanisms Multi-Chain Signing Wallet Provider Support Address divergence is inevitable but manageable Don't assume the address same ENS is a good choice PVG calculation on L2 is more complex than expected RIP-7560 Set up your own bundler The challenges of ERC-4337 on Layer 2 are not just technical—they represent an adaptation process for the entire ecosystem. The future of Account Abstraction on L2 will depend on how infrastructure providers, wallet developers, and Rollup teams collaborate to make it a true standard. Thank you!

Since launching the new account management in imToken 2.15, we have enhanced efficiency and convenience by expanding account types and features. imToken 2.16.1 adds support for Dogecoin and Osmosis accounts, improves account activity, and introduces a new "Token" button for easy access to token features. This update is as follows👇👇👇 🎉Support for Dogecoin and Osmosis accounts 📝Enhanced account activity for quick access to on-chain activities 💰New "Token Function" button for one-click exploration of token features 🛡️Improved risk control system to ensure token security Other Updates- Optimized token management features- Added native staking information to token detail pages 🥳Gas-Free Transfers on BSC - Limited Time Offer Support for Dogecoin and Osmosis Accounts imToken 2.16.1 adds support for Dogecoin and Osmosis accounts. To add an account, simply go to the "Manage wallets" page, click "Add," and select Dogecoin or Osmosis from the list. For bulk account addition, click the three dots in the upper right corner of the account and select "Advanced." As a key part of the Cosmos ecosystem, Osmosis serves as an on-chain liquidity hub via the IBC protocol. With IBC support and Cosmos Kit integration, imToken enables seamless transfers between Cosmos and Osmosis, paving the way for future support of more Cosmos applications and DApps, including the upcoming Babylon Chain. imToken is dedicated to enhancing support for the Cosmos ecosystem by continuously expanding cross-chain interaction and token management capabilities to improve your overall experience. 🔺Steps to add a Dogecoin account Enhanced Account Activity for Quick Access to On-Chain Activities The latest version of imToken optimizes account activity. Simply click "Activity" to quickly access your account activity page and view transaction details. It allows users to easily see key information like transaction type, time, amount, and status, enhancing token management efficiency. Additionally, clicking on any transaction takes you to the transaction details page, where you can view information such as the network and gas fees, and you can also directly navigate to a blockchain explorer for more on-chain data. 🔺Steps to view Polygon account activity New "Token Function" Button for One-Click Exploration of Token Features imToken introduces the "Token Function" button for easy access to token features like buying and trading. Users can also access various DApps directly through this button. Simply click on any token in your account, find the "Token Function" button, and select your desired action for efficient management. Note: The "Token Function" button is not yet available for Ethereum, Arbitrum, and EOS accounts, but support will be added soon. 🔺Steps to use the “Token Function” button Improved Risk Control System to Ensure Token Security imToken 2.16.1 introduces risk address indicators on the activity and transaction details pages, making it easy to identify potentially risky transactions. This enhancement keeps users informed about transaction security and helps reduce token loss. Risk addresses entered during a transaction will be highlighted in red with a warning message, and even completed transactions will show the risk indicator in the records. Other Updates Optimized token management features imToken upgrades token management for Tron, Cosmos, Layer 2, and EVM accounts. Simply click “+” on the wallet page to quickly add tokens by name or contract address. You can view all tokens, adjust the display order, or remove unwanted tokens. EVM accounts also support custom token management for added flexibility. Added native staking information to token details pages The token details pages for ATOM, KSM, DOT, CKB, and others now feature native staking information. For example, ATOM holders can view their balance, staking status, and rewards by clicking "ATOM." Note: Native staking requires users to lock their tokens for a specific period, during which they cannot use these tokens. Gas-Free Transfers on BSC – Limited Time Offer imToken 2.16.1 supports gas-free transfers on the BNB Smart Chain network. From now until January 5, 2025, 11:00 PM (UTC+8), imToken users can enjoy free transfers of stablecoins (FDUSD, USDT, USDC) via their BSC accounts. Each user can make up to 2 free transfers per day for each stablecoin, with a minimum transfer amount of $0.1. Click here for more details. How to Update  Android users: You can download from the official website https://token.im or your favorite App Store (Google Play). iOS users: You can download from the App Store. If you encounter any problem during the process, you can email the subject "Download" to support@token.im to get the latest version of the imToken App. Always Backup Your Keys Before upgrading, please ensure you backup all your wallet identities properly. Write your mnemonic phrase on a piece of metal or paper, and store it in a safe place. Please refrain from sharing your private key, mnemonic phrase, or keystore with anyone! If you find potential hacking activities in imToken, kindly email us at hack@token.im to prevent more people from being deceived. Finally, remember to visit our Help Center at https://support.token.im/hc/en-us for more detailed information about imToken. Download imToken: Google Play | Apple App Store Follow us: Twitter | Support | token.im

imToken unveils imToken Web, offering a seamless Web3 experience at the Web3 Coffee Carnival during Devcon 7. This initiative aims to integrate crypto into daily life, bridging the gap between blockchain technology and real-world use. Since the start of 2024, the Ethereum community has become increasingly aware that, while the underlying infrastructure is well-developed and a variety of rollup solutions are emerging to tackle the scalability issue, there remains a shortage of practical, consumer-facing applications. At EDCON 2024, Vitalik stated that while Ethereum focused on theory over the past decade, the focus for the next decade would shift toward building impactful, real-world applications. With the regulatory environment expected to improve, the ecosystem now needs to prioritize creating consumer applications that bridge the gap between Web3 and Web2, from liquidity integration to the development of new use cases. At Devcon 7, the community's growing sense of momentum and creativity around consumer applications is evident. So, what would a better user experience look like? Our answer is “Token-centric design” and here’s why: Tokens carry both information and value across the network. They embody the intrinsic value of blockchain utilities as well as digital assets. It’s intuitive to think—and true—that the most direct interactions, as well as the most direct value extraction, occur through tokens. Ethereum ushered in the era of smart contracts, transforming traditional tokens into dynamic, programmable assets. These tokens now go beyond simple value transfer and storage, becoming a novel type of data that evolves continuously, offering possibilities that extend well beyond the realm of text, images, and multimedia. Given their complex and dynamic nature, there is a need for precise, real-time information to detail their states and values—information that is best connected and displayed directly from the token's perspective. As tokens emerge as a new and effective means of storing, transferring, and growing value, it's essential to clearly articulate information about the token itself and the outcomes it can generate. imToken refers to this as "Token Function," which essentially defines what a token can do and the specific outcomes it delivers. This concept promotes an intent-based approach and makes token-centric design a logical evolution for navigating the complex, multi-chain, multi-state nature of tokens. Currently, accessing Web3 often means downloading and creating a wallet, which can be a barrier for newcomers. With imToken's token-centric approach, users start with tokens, seamlessly create accounts using AA (Account Abstraction) technology, and continue interacting with, managing, and operating tokens throughout the journey. A New Frontier: imToken Web Start your token journey! Explore tokens at imToken Web (https://web.token.im) and experience our new token-centric design. Note: imToken Web is currently in beta, offering users a preview of the token-centric experience. As the product is still undergoing rapid iteration, it may contain bugs or vulnerabilities. Please use with caution. imToken welcomes your feedback as we collectively explore the future of tokens.

imToken Web Beta is Now Live! Try it out here 👉https://web.token.im. In 2024, fifteen years after Bitcoin’s inception, the crypto landscape exploded, with tens of thousands of tokens now in circulation. While some may fade away, imToken believes the true era of tokenization is just beginning. Tokens are becoming as essential as money, electricity, and the internet, seamlessly integrating into daily life. imToken is building a streamlined, accessible platform to bring clarity to the world of tokens—empowering users with essential information and seamless access to the token economy anytime, anywhere. Our vision is a world where everyone, regardless of age or region, can easily participate in the token economy and enjoy its freedom and convenience. What is imToken Web? imToken Web is a non-custodial, web-based app designed for easy token exploration, featuring quick account creation and passkey sign-in. Enjoy full control without needing a private key or mnemonic backup, allowing seamless access to diverse token functions anytime, directly from your browser. Key Features: No Download Required: Unlike traditional token management apps, imToken Web operates directly in your browser—no downloads or complex sign-ups required—ensuring a streamlined user experience. AA Account Support: imToken Web allows the creation and recovery of AA (Account Abstraction) accounts, combining the benefits of EOA and smart contract accounts, and eliminating the need for seed phrase backups. Passkey-Based Account Creation: Set up accounts with locally stored passkeys, protected by biometrics, enhancing security against phishing and other common attacks. Paymaster Contract Support: With imToken Paymaster, pay gas fees using alternative tokens, like ERC-20 tokens, instead of the chain’s native token. Comprehensive Token Exploration: The token discovery page lets you explore token prices, security info, and more without needing to hold any tokens. Click on any token to view details, transfer, receive, and exchange with ease. imToken Web Beta version includes essential functions like explore, claim, send, receive, swap, plus Paymaster and account recovery, with more features coming soon. How to Use imToken Web Open browser and visit https://web.token.im Create or log in with a passkey (currently supporting Arbitrum and Optimism networks) Once your account is set up, click on any token to view details and perform actions like transfer, receive, and exchange If you’d like to explore more token features, go to the homepage through the menu bar to view various token categories, access detailed information, and click on "Token Function" for additional actions. Devcon7 & imToken Web Devcon7 is happening in Bangkok, Thailand from November 12 to 15, 2024! 🎉 imToken hosts a series of exciting events throughout the week. Join us at Web3 Coffee Carnival to experience imToken Web, claim free tokens, and enter our lucky draw! You can also click here to participate in the online event and win rewards. Discover more details here: 📢imToken Devcon7 Event Announcement Note: imToken Web is currently in beta, offering users an early experience of this token-centric platform. As the product is still evolving, it may contain bugs or vulnerabilities. Please use with caution, and we welcome any feedback. Thank you for your support!

Since launching the new account management model, imToken has continuously optimized account and token management for a smoother Web3 experience. In version 2.16.4, imToken introduces further enhancements for Ethereum and Arbitrum accounts, including the Token Function — a unified hub for managing tokens — and improved account records for greater transaction clarity, making asset management more streamlined and efficient. Ethereum & Arbitrum Account Updates: 💰 Token Function – One-Click Exploration of Token Features 📝 Enhanced Account Activity for Quick Access to On-Chain Insights Token Function: One-Click Exploration of Token Features imToken 2.16.4 introduces the Token Function for Ethereum and Arbitrum accounts—an all-in-one hub for seamless token management. Easily buy, trade, transfer across chains, manage approvals, and interact with DApps in one place. Just tap any token in your account, hit the Token Function button, and choose your action for streamlined control. 🔺Steps to use the “Token Function” button Enhanced Account Activity for Quick Access to On-Chain Insights The latest imToken update improves Ethereum and Arbitrum account records. Tap “Activity” to quickly access your transaction history, including type, time, amount, and status at a glance.Select any transaction to view detailed info like network, gas fees, and instantly jump to a blockchain explorer for deeper on-chain data. 🔺Steps to view Ethereum account activity Other Updates imToken 2.16.4 also introduces UI enhancements for a smoother wallet experience. The filter feature on account and token history pages has been temporarily removed as we redesign it for improved usability—it’ll be back in a future update. How to Update Android users: You can download from the official website https://token.im or your favorite App Store (Google Play). iOS users: You can download from the App Store. If you encounter any problem during the process, you can email the subject "Download" to support@token.im to get the latest version of the imToken App. Always Backup Your Keys Before upgrading, please ensure you backup all your wallet identities properly. Write your mnemonic phrase on a piece of metal or paper, and store it in a safe place. Please refrain from sharing your private key, mnemonic phrase, or keystore with anyone! If you find potential hacking activities in imToken, kindly email us at hack@token.im to prevent more people from being deceived. Finally, remember to visit our Help Center at https://support.token.im/hc/en-us for more detailed information about imToken. Download imToken: Google Play | Apple App Store Follow us: Twitter | Support | token.im

The Pectra hard fork is scheduled for deployment on the mainnet in March 2025. Pectra includes 11 EIPs: EIP-2537: Precompile for BLS12–381 curve operations EIP-2935: Save historical block hashes in state EIP-6110: Supply validator deposits on chain EIP-7002: Execution layer triggerable exits EIP-7251: Increase the MAX_EFFECTIVE_BALANCE EIP-7549: Move committee index outside Attestation EIP-7623: Increase calldata cost EIP-7685: General purpose execution layer requests EIP-7691: Blob throughput increase EIP-7702: Set EOA account code EIP-7840: Add blob schedule to EL config files The following sections group related EIPs for clarity, rather than numerical order. Prerequisites Ethereum is divided into two layers: ​Consensus Layer (CL): Manages network consensus and block validation. ​Execution Layer (EL): Handles transaction execution and smart contracts. Staking-related EIPs: EIP-6110: Supply validator deposits on chain Simplifies the staking process and reduces waiting time. Users participate in staking by depositing 32 ETH into a ​Deposit Contract on the Execution Layer (EL), which is recorded via event logs. Consensus Layer (CL) nodes then parse these event logs from the EL blocks to detect and register staking activities, allowing users to become validators. However, CL validators must first reach consensus on ​which specific EL block's deposit data to parse. Without this agreement, discrepancies may arise (e.g., some validators might see 5 new deposits, while others see only 3). To resolve this, CL validators vote on ​which EL block (referred to as eth1data) to reference, ensuring all validators observe the same EL block. Original Design Constraints: To prevent chain splits caused by critical EL errors, eth1data references EL blocks that are ​~10+ hours old. This ensures CL developers have sufficient time to react to major issues. However, this introduces a ​minimum 10+ hour delay for staking activations. CL block 10,900,000 references EL block 21,683,339 (10 hours older) Post-EIP-6110 Improvements Deposit data from the Deposit Contract is ​directly embedded into EL blocks. Since CL blocks inherently include EL blocks (distinct from eth1data), CL validators no longer need to coordinate on "which EL block to reference." Once a CL block is finalized (achieving >2/3 validator votes), all validators inherently trust the ​same EL block data. Result: Staking activations occur ​around ~13 minutes (time for EL blocks to finalize). CL clients can ​remove complex logic previously used to process deposit events. EIP-7002: Execution layer triggerable exits Enhances the process for validators exiting or withdrawing stakes and rewards. When a user participates in staking, they require two keys: ​Validator Key: Used for validator duties (e.g., block proposals, attestations). ​Withdrawal Credential: Specifies the address where staked funds and rewards are sent upon exit. Current Risks: ​Lost Validator Key: Cannot perform validator duties or initiate exits. Penalties accumulate until the validator is forcibly exited (due to low balance). ​Lost Withdrawal Credential: Permanent loss of all staked funds and rewards. ​Third-Party Staking Services (e.g., Lido): Users retain Withdrawal Credentials, but Validator Keys are controlled by the service provider. Providers can threaten users with ransom demands by withholding exit approvals. ​Post-EIP-7002 Improvements Users can now trigger exits or withdrawals directly via the ​Withdraw Contract (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) using their Withdrawal Credential, bypassing third-party control. Key Features: ​Parameters: validator_pubkey: The validator’s public key. amount: The withdrawal amount (partial or full exit). ​Authorization: The Withdrawal Credential must match the validator’s registered credential. ​Fee Mechanism: Transaction fees (in ETH) scale with ​the number of pending withdrawal requests currently queued in the network. ​For Contracts: Query the Withdraw Contract for real-time fee estimates before submitting requests. For EOAs: Overpay fees (no refunds) to ensure transaction success. Benefits: Eliminates reliance on third-party services for exits. Enables self-custody validators to recover funds even if the Validator Key is lost. Note: If your Withdrawal Credential is still in BLS public key format, remember to switch it to the EL address format. EIP-7251: Increase the MAX_EFFECTIVE_BALANCE Reduces validator count and enables auto-compounding by raising the staking cap. ​Current Limitations: Validators must stake ​exactly 32 ETH (the current MAX_EFFECTIVE_BALANCE). Large stakers (e.g., 1,024 ETH) must run ​32 separate validators, increasing network load. Over ​1 million validators exist today, straining the CL’s state data and P2P layer: Each slot (12 seconds) requires transmitting and aggregating ​tens of thousands of validator signatures. Post-EIP-7251 Improvements ​Lower Bound: MIN_ACTIVATION_BALANCE remains ​32 ETH. ​Upper Bound: MAX_EFFECTIVE_BALANCE increases to ​2,048 ETH. Validators can stake ​any amount between 32–2,048 ETH. Auto-Compounding: Rewards automatically compound without manual withdrawals. ​Validator Consolidation: Existing validators can merge stakes ​without exiting and re-entering. Use the ​Consolidation Contract (0x00431F263cE400f4455c2dCf564e53007Ca4bbBb): Triggered via the validator’s Withdrawal Credential. Request Parameters: source_pubkey: Validator key of the source validator (to be merged). target_pubkey: Validator key of the target validator (receiving the merged stake). Requirements: The Withdrawal Credential ​must belong to the source validator. Fee Mechanism: Transaction fees (in ETH) scale with ​the number of pending consolidation requests in the network. ​For Contracts: Query the Consolidation Contract for real-time fee estimates. ​For EOAs: Overpay fees (no refunds) to ensure transaction success. Note: BLS-formatted Withdrawal Credentials must be converted to ​Execution Layer (EL) address format. EIP-7685: General purpose execution layer requests Establishes a formal EL→CL communication channel for users and staking services. ​Purpose: Enables direct requests from the Execution Layer (EL) to the Consensus Layer (CL). Enhances decentralization for staking services (e.g., Lido): Users no longer need to trust third-party providers to execute actions like exits (EIP-7002) or consolidations (EIP-7251). Requests are initiated via ​EL smart contracts and embedded in EL blocks. ​Mechanism: Requests are written into EL blocks and parsed by CL nodes. Request Types eliminate the need for custom parsing logic on the CL. ​Integration with Other EIPs: EIP-7685 defines the framework for the following request types: Request Type EIP Contract Address Description 0 EIP-6110 0x00000000219ab540356cbb839cbe05303d7705fa Deposit Requests 1 EIP-7002 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA Withdrawal/Exit Requests 2 EIP-7251 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb Stake Consolidation Requests User experience improvement EIPs: EIP-7702: Set EOA account code Enables EOAs to morph into smart contract accounts, significantly improving user experience. ​EOA Limitations: ​Private Key Dependency: Requires secure storage of private keys/mnemonic phrases, raising onboarding barriers. ​Single-Operation Transactions: Complex interactions (e.g., Uniswap swaps) require multiple sequential transactions. ​No Granular Permissions: Users must manually sign every operation. No Recovery Mechanisms: Loss of private keys/mnemonics results in permanent asset loss. ​Smart Contract Account Advantages: ​Keyless Onboarding: Use secure hardware (e.g., TPM) or email-based authentication instead of private keys. ​Batch Operations: Execute multiple actions in a single transaction. ​Granular Permissions Control: Delegate partial account control with constraints (e.g., spending limits, allowed contracts). Recovery Options: Safeguard assets even if private keys/phones/emails are lost. ​EIP-7702  Users sign a ​morphing message with their EOA private key, containing: ​chain_id: Prevents cross-chain replay attacks. Use 0 to enable morphing across all chains. contract_address: Target contract address (e.g., Safe). Use address(0) to revert to EOA. nonce: Prevents signature replay (invalidates old signatures after nonce increments). ​Critical Considerations: ​1. EOA Private Key PersistenceEven if a user’s EOA morphs into a smart contract, they can still use their account in the original EOA manner. For example, if your EOA morphs into a Safe contract, you can: Use the Safe interface and follow Safe transaction workflows. Continue sending transactions by signing with your original EOA wallet. However, this also means the ​account’s security remains tied to the private key. The EOA’s private key is still the sole safeguard for the account, and its compromise would jeopardize the entire account, regardless of its morphed state. 2. Security Remains EOA-BasedEven if a user’s EOA morphs into a multi-signature (multi-sig) contract, ​the account’s security remains entirely dependent on the EOA’s private key. Retaining the private key or mnemonic phrase does not elevate the account’s security to that of a true multi-sig. Users must still securely manage their private keys or mnemonics, as the account’s safety fundamentally hinges on them. 3. EOA Storage PersistenceWhen an EOA morphs into a contract and writes data to its storage, ​the data persists unless explicitly deleted. This means that even if the EOA morphs into another contract or reverts to its original state, the storage data remains intact. Developers must ensure that their contracts do not inadvertently read outdated data from previous morphing cycles. For guidance, refer to ERC-7201 4. EIP-7702 Lacks Built-in Initialization Typically, smart contract accounts require an ​initialization step during deployment to register the owner’s information (e.g., public key or address). This prevents frontrunning attacks that could hijack account ownership. Initialization is usually handled by a ​Factory contract that performs both deployment and setup. However, EIP-7702 enables ​direct morphing without a Factory contract. This creates a ​frontrunning risk: attackers could intercept a user’s morphing signature, submit it first, and initialize the account under their control. To mitigate this, developers should implement safeguards, such as ​verifying the EOA’s signature during initialization. This ensures that even if the request is frontrun, the attacker cannot forge the EOA’s signature to complete the initialization. 5. Wallet Security Warnings Wallets must ​intercept and warn users about suspicious morphing requests. For example, if a malicious DApp prompts a user to sign a morphing transaction, the wallet should block the request and alert the user. If users unknowingly sign malicious morphing transactions, their assets could be ​instantly drained. ​Example Implementations ​Modified Safe ​Ithaca Account DApp related EIPs: EIP-2537: Precompiles for BLS12-381 curve operations Lowers costs for BLS-curve-based zero-knowledge proof applications. EIP-2537 introduces several precompiled contracts to provide cost-efficient BLS curve operations, making it more feasible to develop zero-knowledge proof applications based on the BLS curve. EIP-2935: Save historical block hashes in state Allows developers/nodes to read past block hashes directly from system contract storage. To prove the contents of a past block—for example, in an Optimistic Rollup fraud challenge requiring proof that a transaction existed in block 9000 (1,000 blocks prior)—a challenger cannot simply assert its existence. Instead, they must ​sequentially verify the chain backward, one block at a time, from the latest block (e.g., block 10,000) to the target block (block 9000). ​Example: Start with block 10,000’s hash. Prove block 10,000 links to its parent block 9,999. Repeat this process backward until reaching block 9,000. Finally, prove transaction X exists in block 9,000’s content. △ Every block points to a parent block, allowing proof of any block in history by following the chain backward. source Post-EIP-2935 Improvements The system contract (deployed at 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC) maintains a rolling window of the ​most recent 8,192 block hashes in its storage. Here’s how it works: ​Automatic Updates: When a new block is added (e.g., block N), the system contract overwrites the ​oldest stored hash (from block N-8192) with the hash of the ​newly added block (N). This creates a circular buffer where only the latest 8,192 block hashes are retained. ​Fraud Proof Optimization ​Case 1: Proving a Block Within 8,192 History To prove the hash of block 9,000 (1,000 blocks before block 10,000): ​Direct Reference: Since block 9,000 is within the 8,192-block window of block 10,000, its hash is stored in the system contract’s storage at the state of block 10,000. The challenger can directly reference the storage slot corresponding to block 9,000 to retrieve its hash. ​Case 2: Proving a Block Beyond 8,192 History To prove the hash of block 1,000 (9,000 blocks before block 10,000): Step 1: Find the Closest Stored Hash Calculate the oldest block hash stored at block 10,000: 10,000 - 8,192 = 1,808. The system contract at block 10,000 stores hashes from block 1,808 to block 10,000. ​Step 2: Prove Block 1,808’s Hash Verify the hash of block 1,808 using the system contract’s storage at block 10,000. Step 3: Prove Block 1,000’s Hash Since block 1,000’s hash is stored in the system contract’s storage at block 1,808. Retrieve block 1,000’s hash directly from this storage. ​Stateless Client Support This paves the way for ​stateless clients: Light nodes no longer need to store all historical block headers. When historical data is required, proofs can be requested on-demand using the fraud-proof mechanism described above. EIP-7623: Increasing calldata cost ​EIP-7623: Raising Calldata Costs to Enable Safer Increases in Block Gas Limits and Blob Capacity ​Background With the increasing demand for data publication by Rollups, ​EIP-4844 introduced blobs, enabling Rollups to publish data at significantly lower costs. Since then, the Ethereum community has advocated for ​increasing blob counts and ​raising block gas limits to accommodate higher throughput. However, these upgrades risk amplifying network strain and spam attack efficiency unless data publication costs are adjusted. △ An increasing number of validators are expressing support for raising the Block Gas Limit.  source EIP-7623 increases calldata costs by 2.5x to mitigate risks while enabling scalability improvements: ​Original Calldata Pricing: Zero byte: ​4 gas Non-zero byte: ​16 gas ​Post-EIP-7623 Pricing: Zero byte: ​10 gas Non-zero byte: ​40 gas ​Impact on Attack Efficiency: ​Pre-EIP-7623: A block filled entirely with non-zero calldata: At ​30M gas limit: 30,000,000 / 16 = 1,875,000 bytes ≈ 1.79 MB. At ​40M gas limit: 40,000,000 / 16 = 2,500,000 bytes ≈ 2.38 MB. Average block size: ~100 KB. ​Post-EIP-7623: Attackers’ maximum data capacity drops: At ​30M gas limit: 30,000,000 / 40 = 750,000 bytes ≈ 0.72 MB. At ​40M gas limit: 40,000,000 / 40 = 1,000,000 bytes ≈ 0.95 MB. This reduction in spam efficiency allows safer increases to block gas limits and blob counts. ​Dual Gas Calculation to Protect Regular Users To avoid unintended impacts on non-data-publishing users, transactions are priced using ​two parallel calculations, with the ​higher value applied: ​Legacy Calculation: Calldata priced at original rates (4 gas/zero byte, 16 gas/non-zero byte) + execution/deployment gas. ​New Calculation: Calldata priced at new rates (10 gas/zero byte, 40 gas/non-zero byte), ​excluding execution/deployment gas. ​Why Regular Users Are Unaffected: For typical transactions (e.g., token swaps), most gas is consumed by ​execution logic (e.g., contract interactions), not calldata. The new calldata costs (even at 2.5x) rarely exceed execution costs under the dual calculation, leaving regular users unaffected. The ​most affected will be ​small-scale Rollups. Since blobs have ​fixed sizes and costs, they are inefficient for small data batches, making calldata a more cost-effective option for these Rollups. However, after EIP-7623, calldata costs will increase by ​2.5x, significantly raising expenses for small Rollups. As a result, they may need to: ​Switch to blobs despite their inefficiency for small data. ​Collaborate with others to share a single blob and split the costs. EIP-7691: Blob throughput increase Increases the number of Blobs, providing more data publishing capacity for Rollups. EIP-7691 raises the Blob count from "Target: 3 Blobs, Maximum: 6 Blobs" to "Target: 6 Blobs, Maximum: 9 Blobs", expanding the available space for Rollup data publication. Note: There are still some design adjustments needed for the Blob fee market, such as improving the speed of fee adjustments and raising the minimum fee, but these issues are not within the scope of this EIP. Miscellaneous EIP EIP-7549: Move committee index outside Attestation Adjusts validator voting content for easier aggregation and reduced p2p network pressure. ​Current Mechanism: Validators are randomly assigned to ​committees each epoch and vote on blocks. Votes within the same committee can be ​aggregated, reducing the volume of data transmitted over the p2p network. However, each vote includes the ​committee index (i.e., which committee the validator belongs to), preventing aggregation of votes from ​different committees—even if they vote on the same block. ​Improvements: The ​committee index is moved outside the attestation content. Votes from different committees can now be ​aggregated if they share the same content (e.g., voting for the same block). This further reduces the volume of attestation data transmitted over the p2p network, alleviating network pressure. EIP-7840: Add blob schedule to EL config files Simplifies blob parameter access for EL nodes by creating a dedicated configuration file. ​Current Limitations: Blob-related parameters are stored in ​CL nodes. EL nodes occasionally need these parameters (e.g., for eth_feeHistory RPC calls), requiring them to query CL nodes. ​Improvements: A ​configuration file for blob-related parameters is added to the EL layer. EL nodes can now directly access these parameters from the config file, eliminating the need to query CL nodes. Related Readings: https://pectra.wtf https://x.com/binji_x/status/1874422557992263720 https://www.galaxy.com/insights/research/pectra-upgrade-and-other-eth-catalysts/ https://gaslimit.pics/ https://x.com/spire_labs/status/1881445292815597913