We didn’t expect this. 👀 During Ethereum Builders Live, @jchaskin22 & @griffgreen talked about @EIPsInsight while reviewing 100+ projects from @thedaofund QF round on @Giveth. #Ethereum #EIPs #QuadraticFunding #Giveth #EthereumGovernance #PublicGoods

Connecting Ethereum with Enterprise. 🌐 Check out this post by @poojaranjan19 sharing her experience in the room with @EntEthAlliance - bridging Ethereum’s protocol development with enterprise understanding and adoption.

ETHShala Weekly 📚 September recap: features explored, Ethereum concepts simplified, colleges invited & learner progress celebrated. What should ETHShala teach in October? Reply with one topic.

Reminder: you can now sync an ethereum node within half a day and with aggressive settings the space it takes up on disk can be under half a terabyte. EIP-4444 and hard work by client teams on optimizing snap sync has improved things *a lot*. Glamsterdam will improve the sync situation further still (eg. Nimbus's new sync protocol uses it)

Glamsterdam will bring snap sync to the next level. With snap v2, the Block-level Access List, which is basically a state diff, is used to replace the traditional healing phase. The result, it becomes faster and simpler to sync a node. Clients are ready with Glamsterdam. Snycing has never been that smooth.

Ethereum’s protocol process is open, but for enterprises, following EIPs, ACD calls, devnets & upgrade stages can still be difficult to translate into action. In her latest piece, @PoojaRanjan19 shares her experience bringing Ethereum’s protocol process into the enterprise room through @EntEthAlliance’s Ethereum Intelligence, shaped through discussions with @RedoudouM. #Ethereum #EIPs #EnterpriseEthereum #ProtocolGovernance #Web3

Really cool work, @RedoudouM 🙌 Translating Ethereum's technical changes into product impact for financial institutions is genuinely valuable. Thanks for the kind mention 🙏

⚡ Glamsterdam is getting closer, while Hegota scope keeps moving. AllCoreDevs Execution #246: → Sepolia Glamsterdam is set for October 6, with client releases due by September 29. → 200M gas limit will be signaled for the Sepolia fork, with the limit able to trend upward post-fork through the normal 1/1024 voting mechanism. → EIP-7979 and EIP-8163 are now CFI’d for Hegota, alongside EIP-7906, 8250, 8272, 7668, 8253, 3298 and 8131. → EIP-8304 is DFI’d for Hegota, while EIP-8368 and EIP-8372 remain PFI pending at least 30 days of mainnet Glamsterdam data. → EIP-8131 + the BAL byte-floor EIP will move forward as a bundle. 🔗 eipsinsight.com/calls/acde/2… #Ethereum #ACDE #Glamsterdam #Hegota

EIPs, network upgrades, and devnets move fast, but how do enterprises figure out what actually impacts their stack? I wrote about taking Ethereum’s protocol process into the enterprise room with @EntEthAlliance, shaped through discussions with @RedoudouM, and why bridging this communication gap matters for both developers and institutions. 📖 Read the full story on @ether_world: etherworld.co/taking-ethereu… #Ethereum #Enterprise #Blockchain #TechLeadership #EEA #EIP #ERC

Ethereum Matrix intelligence.entethalliance.… in the continuity of the great work of @EIPsInsight this is a tool to translate Ethereum technical changes into products impacts for financial institutions. Send that to product managers.

⚡ Native Account Abstraction is getting closer to its first DevNet. Native AA #005: → frames-devnet-0 is targeting launch after September 22, pending EthPandaOps availability. → Max verified gas is now set to 500K, up from the 100K default, to support more complex testing scenarios. → The ethrex testnet has been running for 14 days, with Geth, ethrex, and Nethermind validating and ~400 Frame Transactions from 21 senders. → The group is also working through JSON-RPC support for Frame Transactions, including gas estimation, transaction filling, and simulation. 🔗 eipsinsight.com/calls/aa/005 #Ethereum #AccountAbstraction #Frames #EIPs

Ethereum Standards Weekly #8 breaks down the latest EIP status changes, new proposals, editor activity & upgrade related movements shaping the protocol. Catch up on the standards layer in one read 👇 #Ethereum #EIPs #EIPsInsight #Web3 eipsinsight.com/resources/bl…

Weekly Roundup From 60M to 200M: simulating Glamsterdam’s fee market 🔗 ethresear.ch/t/25957 3 comment(s) this week Mempool Account Transaction Capacity from Historical Activity (MATCHA) 🔗 ethresear.ch/t/25949 3 comment(s) this week Wen fast payload broadcast? Segment, code, push, pull, and everything in between 🔗 ethresear.ch/t/25913 2 comment(s) this week Atomic ZK-Proof-Gated Settlement for x402 Agent Payments: A Measured Reference Design 🔗 ethresear.ch/t/25660 2 comment(s) this week Cryptographic canaries and backups 🔗 ethresear.ch/t/1235 1 comment(s) this week Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter 🔗 ethresear.ch/t/25856 1 comment(s) this week Staking rewards as venture capital, governed by futarchy 🔗 ethresear.ch/t/26030 1 comment(s) this week Bounding Collusion in Capital Allocation DAOs via Subjective Human Oracles 🔗 ethresear.ch/t/25459 1 comment(s) this week How Hegotá can influence the state roadmap 🔗 ethresear.ch/t/25895 1 comment(s) this week EIP-8411: what segmented payload diffusion is made of 🔗 ethresear.ch/t/26025 1 comment(s) this week When Data Binds Execution: Dynamic Simulation of EIP-7999’s Multidimensional Fee Market 🔗 ethresear.ch/t/26018 1 comment(s) this week Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers 🔗 ethresear.ch/t/26003 1 comment(s) this week Scaling Ethereum with recursive STARKs and the Trustless Log Index 🔗 ethresear.ch/t/26002 1 comment(s) this week Public-mempool gas sponsorship needs escrow, a bond, or trust 🔗 ethresear.ch/t/25995 1 comment(s) this week The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient 🔗 ethresear.ch/t/23395 1 comment(s) this week Lean4 SSZ library: formally verified and easy to use 🔗 ethresear.ch/t/25988 1 comment(s) this week

The encrypted mempool working group met this week to discuss one of the biggest open questions in LUCID EIP design: the optionality problem. A thread 👇🧵

New post on Eth Research! Towards Encrypted Mempools from Threshold IBE without Batching By: - GottfriedHerold 🔗 ethresear.ch/t/26040 Highlights: - Design sketch for an Ethereum encrypted mempool that relies on threshold Identity-Based Encryption (TIBE) but explicitly drops the usual ‘batch decryption’ requirement, expanding the set of potentially usable threshold schemes. - Core mechanism: users first post a small on-chain ‘ticket’ (with a hiding commitment to the real transaction) that pins execution to a known future block; only after the ticket is included do they publish the encrypted transaction, using the ticket blockhash as the IBE identity to bind it to a specific fork and mitigate reorg replay issues. - A three-block pipeline enforces builder non-optionality: B[n] includes tickets; PTC votes on whether each encrypted tx was seen by a deadline; B[n+1] commits an `etx_seen` bitfield constrained by PTC votes; only then are decryption key shares released, and B[n+2] includes the reconstructed key and executes decrypted transactions top-of-block in ticket order (fixed two-block delay). - The extra consensus round (the `etx_seen` commitment) is intentional: it prevents any builder from making include/exclude decisions after learning decrypted contents, at the cost of latency and added protocol complexity. - The post emphasizes pragmatic failure handling (missed slots, reorgs, committee refusing/offline) and proposes a circuit breaker to preserve Ethereum’s dynamic availability by disabling the encrypted mempool and refunding reserved gas during prolonged decryption/key-release failure; major open problem remains finding a threshold IBE meeting all requirements, especially post-quantum security. ELI5: Imagine you want to send a secret message (a transaction) so nobody can peek at it and copy/cheat before it happens. This post suggests a way to do that on Ethereum by using: (1) a “ticket” you put on-chain first that reserves a future spot for your secret message, (2) a committee that later helps unlock the secret, but only after everyone agrees the secret message was actually shared with the network, and (3) a rule that the secret message is tied to a specific block’s fingerprint (blockhash), so if the chain rewinds (reorg), the secret message becomes invalid. The key trick is to avoid needing ‘batch decryption’ cryptography by making each transaction’s decryption identity depend on the already-known blockhash where the ticket landed, so the committee doesn’t need to agree on a whole set of ciphertexts at decryption time.

🔐 What happens to your ETH if quantum computing breaks ECDSA overnight, before the migration is done? PQTS is building the recovery path, and it's now running on a real Ledger. PQ Transaction Signatures #015: → The emergency mitigation takes shape: lift the weak ECDSA step to a quantum-resistant scheme via a ZK proof of your key-derivation pre-image, then let account abstraction carry on-chain authority. No user action needed before the break. → zkBoo now runs fully on a Ledger Flex, and the latest FLOC lifter reached a 12-second proving time with a 1.2 MB proof. → daisugi.fyi:3000 is now the permanent PQTS testnet, with STARK-based signature aggregation up next. → SPHINCS+ verification runs through a zkSNARK verifier, with software, hardware, and MPC signing paths all hitting the same on-chain verifier. → A formalization paper on SPHINCS+ signing security and pre-computation is expected in the next few weeks. 🔗 eipsinsight.com/calls/pqts/0… #Ethereum #PQTS #PostQuantum #ZKProofs

🔐 Who gets to hold the keys to Ethereum's encrypted mempool? Validators might soon vote on it. Encrypt The Mempool #10: → Validators may soon allowlist trusted key publishers by vote, through an execution-layer contract where an address needs 50% of total effective balance to be accepted (delegation included). → Top-of-block ordering would prioritize allowlisted publishers, lowering market-entry barriers while letting newcomers earn before they hit the 50% threshold. → Threshold encryption and post-quantum requirements are parked until the crypto matures - the focus is now Lucid's optionality problem, with a key publisher revealing keys after commit. → Cadence moves to monthly, and Jannik is opening a PR to EIP-8184 to fold in the allowlist mechanism. 🔗 eipsinsight.com/calls/etm/10 #Ethereum #EncryptTheMempool #Lucid #MEV @drakefjustin @weboftrees @encryptmempool

🧭 The EIP process might be getting a whole new kind of role. EIPIP #130: → Editors are backing a new EIP Coordinator role for the social, author-mentoring side of the process, distinct from editors and unable to allocate EIP numbers. Final call pending one comment. → Two Calls for Input cleared to merge: Unicode Technical Standards and a new Associate EIP Editors tier to grow review capacity. → contributing.md tightened: active EIP PRs now need two editor approvals, and no force-merges. → Calls for Input stay in the EIPIP repo, keeping EIP and ERC governance in one place instead of fracturing across repos. 🔗 eipsinsight.com/calls/eipip/… #Ethereum #EIPs #EIPIP #Governance @poojaranjan19 @jochem_brouwer @lightclients @_SamWilsn_

Onchain security is everyone’s problem and nobody’s job. ETHSecurity Initiatives is how we are changing that. Propose the work. Fund the work. Build the work. initiatives.thedao.fund/

New post on Eth Research! Scaling Ethereum with recursive STARKs and the Trustless Log Index By: - zsfelfoldi 🔗 ethresear.ch/t/26002 Highlights: - Post-quantum (PQ) cryptography will likely increase signature sizes, making “recursive STARK transaction pre-authorization” (EIP-8288) an attractive path because it can dramatically reduce effective on-chain verification costs for signatures and other witness data. - If EIP-8288-style cheap ZK verification becomes available, statelessly verifiable witness data gets much cheaper on-chain—including proofs for log queries built on the Trustless Log Index (EIP-8304)—making log-index-based designs far more viable. - The Trustless Log Index can serve as shared infrastructure for trustless chain indexing and cross-chain/cross-shard message filtering; application-specific indexers can become cheaper by proving only relevant logs since a checkpoint instead of processing full block receipts. - EIP-8304 uses a hybrid model: small, recent index tables are maintained in-protocol for low-latency access to the chain head, while larger historical merges can be proven/updated asynchronously with ZKPs—balancing freshness guarantees with incentive alignment. - Log index tables have lower write cost than the state tree (per-block sorting + hashing, with efficient asynchronous merges), and logs can act as an alternative storage model (time-series tuples) that can represent sets/lists without key-collision issues—potentially helping statelessness, state expiry, and simplifying sharded execution patterns. ELI5: Ethereum needs to handle more activity without making the blockchain too expensive. This article suggests using very efficient cryptographic proofs (recursive STARKs) so transactions can prove they’re valid with less on-chain cost—especially important if future post-quantum signatures get big. It also proposes an on-chain “phone book” for event logs (the Trustless Log Index) so you can quickly and trustlessly find past events/messages. That makes it easier to build trustless indexers, do cross-chain/shard messaging, and even store some kinds of contract data as an append-only history (logs) instead of constantly rewriting a big key/value database (the state tree).