<p>Welcome to our weekly digest, where we unpack the latest in account and chain abstraction, and the broader infrastructure shaping Ethereum.</p> <p><strong>This week:</strong> Ethereum’s native account abstraction effort shifts into a structured multi-proposal phase, new research explores parallel zkEVM execution and higher throughput models, and Etherspot brings seamless gasless UX to Telegram-native crypto applications.</p> <ul> <li>Native Account Abstraction Debate Moves Into a Dedicated Breakout Process</li> <li>Delegated Execution Sharding Explores a Hyper-Parallel zkEVM Path</li> <li>Etherspot Powers Blockgram’s Gasless, Keyless Crypto Experience on Telegram</li> <li>Research Post Proposes Affine Metering for Higher Ethereum Throughput</li> </ul> <p>Please fasten your belts!</p> <h2> Native Account Abstraction Debate Moves Into a Dedicated Breakout Process<a> </a> </h2> <p>Ethereum contributors <a href="https://ethereum-magicians.org/t/native-account-abstraction-1-april-22-2026/28227" rel="noopener noreferrer">held</a> the first dedicated Native Account Abstraction breakout on April 22, shifting the discussion from headliner selection to a broader comparison of competing proposals and implementation paths. The session followed the decision not to make EIP-8141: Frame Transactions a Hegotá headliner, while still keeping account abstraction as an active priority for future fork work. The agenda explicitly covered proposal updates, adoption strategy, mempool design, statelessness and VOPS implications, privacy, and post-quantum security.</p> <p>The discussion showed clear differences in priorities across stakeholders. Wallet developers focused on practical deployment concerns such as efficiency and hardware wallet support, while other participants emphasized post-quantum readiness and reducing centralization around transaction flow. The breakout also reviewed newer proposals alongside Frame Transactions, including EIP-8202: Schemed Transaction, EIP-8223: Contract Payer Transaction, and EIP-8224: Counterfactual Transaction, indicating that Ethereum’s native AA debate is no longer centered on a single design.</p> <p>Frame Transactions remained the most detailed proposal in the room, but the summary makes clear that several major issues are still open. The next work items include aligning with Base, Arbitrum, and OP on performance and cost concerns, defining canonical verifiers, resolving the ERC-20 sponsorship model, and addressing statelessness compatibility questions. In parallel, the authors of EIP-7906 were tasked with building a proof of concept to show how transaction assertions could work both independently and alongside Frame Transactions.</p> <p>The key takeaway is that Ethereum’s account abstraction effort is now moving through a more structured research and coordination phase rather than a single winner-takes-all proposal process. That likely makes near-term progress slower, but it also broadens the path for combining multiple ideas into a native AA design that can satisfy wallets, L2s, privacy use cases, and post-quantum migration requirements.</p> <p><a href="https://www.youtube.com/watch?v=pxWZyZ-exLA" rel="noopener noreferrer"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F126yz37m9rn77mtpy2k3.png" alt="Native Account Abstraction Debate Moves Into a Dedicated Breakout Process" width="800" height="447"></a></p> <h2> Delegated Execution Sharding Explores a Hyper-Parallel zkEVM Path<a> </a> </h2> <p>Ethereum Research contributor Conall O’Reilly <a href="https://ethresear.ch/t/delegated-execution-sharding-des-a-hyper-parallelized-zkevm-for-theoretically-optimal-execution-layer-scalability/24724" rel="noopener noreferrer">proposed</a> Delegated Execution Sharding (DES) as a theoretical execution-layer design that could push Ethereum toward much higher scalability by combining parallel transaction execution with recursive zk-proof aggregation. The post frames DES as an extension of ideas already being explored around Lean, post-quantum priorities, and recursive proof systems, arguing that the same logic used to parallelize validator-signature proving on the consensus side could eventually be adapted for execution as well.</p> <p>The core idea is to split a block’s transactions into separate “execution columns” made up of transactions whose state effects do not collide. Those columns could then be executed in parallel by different committees, with each committee producing zk-proofs for its assigned work. A block proposer would then aggregate those proofs into a higher-level proof covering the full block. In that model, execution would no longer be bottlenecked by a single machine needing to run the entire state transition directly in real time.</p> <p>The post positions this as a way to move beyond today’s scaling limit, where decentralization still depends on any ordinary node being able to re-execute the full chain. DES instead assumes untrusted parallel execution across many nodes, with validity preserved through succinct proofs rather than direct recomputation. The proposal also suggests that future gas pricing could reflect how parallelizable a transaction is, making access to heavily contested state more expensive and encouraging designs that reduce shared-state contention.</p> <h2> Etherspot Powers Blockgram’s Gasless, Keyless Crypto Experience on Telegram<a> </a> </h2> <p>Blockgram <a href="https://x.com/blockgramapp/status/2042874392427008030" rel="noopener noreferrer">has partnered</a> with Etherspot to integrate Account Abstraction into its Telegram-native crypto platform, aiming to remove much of the friction that still makes Web3 difficult for mainstream users. According to <a href="https://etherspot.io/case-studies/blockgram/" rel="noopener noreferrer">the announcement</a>, the integration brings gasless transactions, smart accounts, and transaction batching directly into a chat-based experience on Telegram.</p> <p>The setup is designed to simplify three major pain points in crypto onboarding. First, users no longer need to manage seed phrases or private keys in the traditional way, as Blockgram uses smart contract accounts through Etherspot’s Modular SDK. Second, users can pay gas fees in any ERC-20 token through Etherspot’s Arka Paymaster, removing the need to hold ETH just to get started. Third, Etherspot’s Skandha ERC-4337 Bundler enables multi-step actions to be bundled into a single on-chain transaction, reducing approval friction.</p> <p>Blockgram describes the result as a “gasless, seedless execution terminal” built inside Telegram. The case study positions this as a way to make crypto interactions feel closer to Web2 messaging flows, while still preserving decentralization and self-custody. For users, the stated benefits include one-click approvals, simpler onboarding, and a chat-native way to send, receive, and manage crypto.</p> <p>More broadly, the integration highlights how Account Abstraction infrastructure is being applied to consumer-facing products beyond standard wallets and DeFi interfaces. In this case, Etherspot’s stack is the core layer that allows Blockgram to hide blockchain complexity behind a familiar messaging experience, turning Telegram into a more usable crypto interface for a wider audience.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fdrmphsze5jcq8bvc0rvr.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fdrmphsze5jcq8bvc0rvr.png" alt="Etherspot Powers Blockgram’s Gasless, Keyless Crypto Experience on Telegram" width="800" height="447"></a></p> <h2> Research Post Proposes Affine Metering for Higher Ethereum Throughput<a> </a> </h2> <p>Anders Elowsson <a href="https://ethresear.ch/t/the-case-for-a-variable-ptc-deadline-with-affine-metering-and-a-unified-calldata-price/24708" rel="noopener noreferrer">argues</a> that Ethereum could materially improve execution-layer throughput by combining a variable PTC deadline, a single unified calldata price, and what he calls affine metering. The proposal is designed around ePBS timing constraints: as calldata usage rises, the PTC deadline shifts later, and as calldata usage falls, the unused propagation window is converted into extra execution time. In this model, calldata and execution are no longer treated as loosely connected resources. Instead, they share a direct linear tradeoff inside the slot.</p> <p>The post’s core claim is that this design could let Ethereum use a much larger share of each slot for execution, roughly doubling throughput and the gas limit under the illustrated assumptions. The argument depends on replacing EIP-7976’s split calldata pricing model with a single calldata price, so that calldata is charged in proportion to the propagation burden it creates. That makes the timing model cleaner and avoids the limited scaling gains that come from letting transactions buy some calldata too cheaply.</p> <p>A major criticism of EIP-7976 in the post is that its large price differential creates room for gameability. Transactions heavy in execution could effectively “auction off” their cheaper calldata allowance, while the network still has to deal with the real byte footprint. Under affine metering, every calldata byte is priced consistently, which removes that distortion and simplifies gas accounting.</p> <p>The post also argues that this framework remains compatible with a future multidimensional fee market such as EIP-7999. In that version, calldata could still be treated as its own resource, while the variable PTC deadline would continue to track raw byte consumption or an equivalent constant-multiple unit.</p> <p><strong>Start exploring Account Abstraction with Etherspot!</strong></p> <ul> <li>Learn more about account abstraction <a href="https://etherspot.io/blog/the-key-concepts-behind-erc-4337-account-abstraction/" rel="noopener noreferrer">here</a>.</li> <li>Head to <a href="https://etherspot.fyi/modular-sdk/intro" rel="noopener noreferrer">our docs</a> and read all about Etherspot Modular SDK.</li> <li> <a href="https://etherspot.io/skandha/" rel="noopener noreferrer">Skandha</a> — developer-friendly Typescript ERC4337 Bundler.</li> <li> <a href="https://etherspot.io/arka-paymaster/" rel="noopener noreferrer">Arka</a> — an open-source Paymaster Service for gasless &amp; sponsored transactions.</li> <li>Explore our <a href="https://etherspot.io/transactionkit/" rel="noopener noreferrer">TransactionKit</a>, a React library for fast &amp; simple Web3 development.</li> <li>Follow us on <a href="https://twitter.com/etherspot" rel="noopener noreferrer">X (Twitter)</a> and join our <a href="http://discord.etherspot.io/" rel="noopener noreferrer">Discord</a>.</li> </ul> <p>❓Is your dApp ready for Account Abstraction? Check it out here: <a href="https://eip1271.io/" rel="noopener noreferrer">https://eip1271.io/</a></p> <p><strong>Follow us</strong></p> <p><a href="https://etherspot.io/?utm_source=devto&amp;utm_medium=article&amp;utm_campaign=followus_es" rel="noopener noreferrer">Etherspot Website</a> | <a href="https://twitter.com/etherspot" rel="noopener noreferrer">X</a> | <a href="http://discord.etherspot.io/" rel="noopener noreferrer">Discord</a> | <a href="https://t.me/etherspot" rel="noopener noreferrer">Telegram</a> | <a href="https://github.com/etherspot/etherspot-prime-sdk" rel="noopener noreferrer">Github</a> | <a href="https://developer.etherspot.io/" rel="noopener noreferrer">Developer Portal</a></p>