Marco López González

Just dropped a new article about EIP-7702 on @DSecurityES's blog. It brings smart contract-like abilities to EOAs, but also introduces some new security challenges. If you’re into Ethereum, you’ll want to check this out! decentralizedsecurity.es/eip-7702-ether…

We found the same Fiat-Shamir bug in six independent zkVMs. The result: an attacker can bypass the cryptography entirely and prove mathematically impossible statements (like minting $1M out of thin air). Full breakdown ↓

Introducing strawmap, a strawman roadmap by EF Protocol. Believe in something. Believe in an Ethereum strawmap. Who is this for? The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™. What is the strawmap? The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks. What are some of the highlights? The strawmap features five simple north stars, presented as black boxes on the right: → fast L1: fast UX, via short slots and finality in seconds → gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving → teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling → post quantum L1: durable cryptography, via hash-based schemes → private L1: first-class privacy, via shielded ETH transfers What is the origin story? The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism. Why the "strawmap" name? "Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons: 1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process. 2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views. The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes. What is the strawmap time frame? The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules. What do the letters on top represent? The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star"). What do the colors and arrows represent? Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom. Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups. What are headliners? Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively. (L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.) Will the strawmap evolve? Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document. Can I share feedback? Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.

Now, account abstraction. We have been talking about account abstraction ever since early 2016, see the original EIP-86: github.com/ethereum/EIPs/… Now, we finally have EIP-8141 ( eips.ethereum.org/EIPS/eip-8141 ), an omnibus that wraps up and solves every remaining problem that AA was intended to address (plus more). Let's talk again about what it does. The concept, "Frame Transactions", is about as simple as you can get while still being highly general purpose. A transaction is N calls, which can read each other's calldata, and which have the ability to authorize a sender and authorize a gas payer. At the protocol layer, *that's it*. Now, let's see how to use it. First, a "normal transaction from a normal account" (eg. a multisig, or an account with changeable keys, or with a quantum-resistant signature scheme). This would have two frames: * Validation (check the signature, and return using the ACCEPT opcode with flags set to signal approval of sender and of gas payment) * Execution You could have multiple execution frames, atomic operations (eg. approve then spend) become trivial now. If the account does not exist yet, then you prepend another frame, "Deployment", which calls a proxy to create the contract (EIP-7997 ethereum-magicians.org/t/eip-7997-det… is good for this, as it would also let the contract address reliably be consistent across chains). Now, suppose you want to pay gas in RAI. You use a paymaster contract, which is a special-purpose onchain DEX that provides the ETH in real time. The tx frames are: * Deployment [if needed] * Validation (ACCEPT approves sender only, not gas payment) * Paymaster validation (paymaster checks that the immediate next op sends enough RAI to the paymaster and that the final op exists) * Send RAI to the paymaster * Execution [can be multiple] * Paymaster refunds unused RAI, and converts to ETH Basically the same thing that is done in existing sponsored transactions mechanisms, but with no intermediaries required (!!!!). Intermediary minimization is a core principle of non-ugly cypherpunk ethereum: maximize what you can do even if all the world's infrastructure except the ethereum chain itself goes down. Now, privacy protocols. Two strategies here. First, we can have a paymaster contract, which checks for a valid ZK-SNARK and pays for gas if it sees one. Second, we could add 2D nonces (see docs.erc4337.io/core-standards… ), which allow an individual account to function as a privacy protocol, and receive txs in parallel from many users. Basically, the mechanism is extremely flexible, and solves for all the use cases. But is it safe? At the onchain level, yes, obviously so: a tx is only valid to include if it contains a validation frame that returns ACCEPT with the flag to pay gas. The more challenging question is at the mempool level. If a tx contains a first frame which calls into 10000 accounts and rejects if any of them have different values, this cannot be broadcasted safely. But all of the examples above can. There is a similar notion here to "standard transactions" in bitcoin, where the chain itself only enforces a very limited set of rules, but there are more rules at the mempool layer. There are specific rulesets (eg. "validation frame must come before execution frames, and cannot call out to outside contracts") that are known to be safe, but are limited. For paymasters, there has been deep thought about a staking mechanism to limit DoS attacks in a very general-purpose way. Realistically, when 8141 is rolled out, the mempool rules will be very conservative, and there will be a second optional more aggressive mempool. The former will expand over time. For privacy protocol users, this means that we can completely remove "public broadcasters" that are the source of massive UX pain in railgun/PP/TC, and replace them with a general-purpose public mempool. For quantum-resistant signatures, we also have to solve one more problem: efficiency. Here's are posts about the ideas we have for that: firefly.social/post/lens/1gfe… firefly.social/post/x/2027405… AA is also highly complementary with FOCIL: FOCIL ensures rapid inclusion guarantees for transactions, and AA ensures that all of the more complex operations people want to make actually can be made directly as first-class transactions. Another interesting topic is EOA compatibility in 8141. This is being discussed, in principle it is possible, so all accounts incl existing ones can be put into the same framework and gain the ability to do batch operations, transaction sponsorship, etc, all as first-class transactions that fully benefit from FOCIL. Finally, after over a decade of research and refinement of these techniques, this all looks possible to make happen within a year (Hegota fork). firefly.social/post/bsky/qmaj…

I was helping a non-techie friend with his Spanish startup. My go-to was Cloudflare Workers; I deployed the app there. In the middle of frantic weekend testing, it goes dark and founders freak out. I can’t figure out what’s going on: status is green, DNS is fine, curl works for me. After 20min my brain surfaces the memory about La Liga censorship. I search and land on hayahora.futbol (“is football on now?”). It displays a massive YES. Literally the entirety country cannot access websites hosted on Cloudflare or Vercel every time there’s a football match (which, being Spain, is quite frequently). Ironically, the court order only blocks at the ISP DNS resolver level, so the fix is within a few clicks: switch to something like 1.1.1.1, NextDNS, etc. Obscure enough for the average María to not know, simple enough for pirates to circumvent. That, or a VPN. Spanish authorities are incredibly tech illiterate and hostile to innovation. Same country that blocked IPFS in 2017. Conclusion: if you’re gonna censor, at least do it (a) right and (b) overtly for people to know and react. Now I have to migrate their whole deployment out of Cloudflare. Luckily my bestie Claude Code can do the dirty work together with its MCP frens.

A smart contract got drained for $26.5 million because of an integer overflow. The contract was written in Solidity 0.6.10. It had been live since 2021. If you're learning Solidity right now, this is the most important exploit to understand. 🧵

This feels like a good time to share Eth protocol expert: an agentic RAG system grounded in a large corpus of EIPs, specs, forum posts, arXiv papers, and client codebases. Still early days. Started as a fun holiday hack, but it shows promise. Repo below with instructions to self-host. Get involved!

Introducing SolidityGuard.org — an advanced @ethereum @solidity_lang /EVM security auditor open sourced and for free. 104 vulnerability patterns. 8 tool integrations. 100% detection on DeFiVulnLabs + @paradigm CTF benchmarks. Try it free: solidityguard.org

The best way to learn how something works is to build it yourself. So I rebuilt OpenClaw from the ground up, starting from a 20-line Telegram bot and ending with a Mini Openclaw in 400 lines. I learned a lot and it was a lot of fun! Here's the tutorial so you can do it too:

The Ethereum Foundation Academic Secretariat Team is sponsoring the 2026 PhD Fellowship Program. The program provides PhD students working on research critical to Ethereum’s long-term evolution with a 1 year fellowship. Proposals due April 1st. esp.ethereum.foundation/rounds/phdfp26

Great work!

Today marks an inflection in the Ethereum Foundation's long-term quantum strategy. We've formed a new Post Quantum (PQ) team, led by the brilliant Thomas Coratger (@tcoratger). Joining him is Emile, one of the world-class talents behind leanVM. leanVM is the cryptographic cornerstone of our entire post-quantum strategy. After years of quiet R&D, EF management has officially declared PQ security a top strategic priority. Our journey began in 2019, with the "Eth3.0 Quantum Security" presentation at StarkWare Sessions. Since 2024, PQ has been central to the @leanEthereum vision. The pace of PQ engineering breakthroughs since then has been nothing short of phenomenal. It's now 2026, timelines are accelerating. Time to go full PQ: → PQ ACD: Antonio Sanso (@asanso) kicks off a bi-weekly All Core Devs PQ transactions breakout call next month. These sessions focus on user-facing security, covering dedicated precompiles, account abstraction, and longer-term transaction signature aggregation with leanVM. → PQ foundations: Today we are announcing a $1M Poseidon Prize to harden the Poseidon hash function. We are betting big on hash-based cryptography to enjoy the strongest and leanest cryptographic foundations. Check out our other $1M PQ initiative, the Proximity Prize. → PQ devnets: Multi-client PQ consensus devnets are live! Shoutout to pioneers @zeamETH, @ReamLabs, @PierTwo_com, @geanclient, @ethlambda_lean, as well as established consensus teams Lighthouse, Grandine, and soon Prysm. This incredible teamwork is coordinated by @corcoranwill via weekly PQ interop calls. → PQ workshops: Building on last year's PQ workshop in Cambridge (see photo), the EF is hosting another 3-day PQ event in October. Top experts from around the world will convene. In addition, a PQ day is set for March 29 in Cannes just ahead of EthCC. → PQ FV and AI: Last week Alex Hicks (@alexanderlhicks) ran a specialised maths AI for 8 hours, at a $200 cost. It one-shotted a formal proof one of the hardest lemmas in the foundations of hash-based snarks. Mind-blowing. Applied cryptography will never be the same. → PQ roadmap: A comprehensive breakdown of the EF's proposed PQ strategy will be shared soon™ on pq[.]ethereum[.]org. The roadmap targets a full transition in coming years with zero loss of funds and zero downtime. Stay tuned :) → PQ education: The ZKPodcast (@zeroknowledgefm) is producing a 6-part video series on Ethereum's PQ strategy. EF Enterprise Acceleration is also preparing material for enterprises and nation-states. Finally, Ethereum is now represented on the PQ advisory board that Coinbase announced yesterday. Believe in something. Believe in PQ security.

We just published a first-pass survey on PQ migration paths for Ethereum EOAs, with a focus on breakages (ecrecover/permit/tx.origin, L2 drift, MEV). Would love pointers to related work + teams working on this 🤠

Smart Contract - Learning Resources (@blok_cap) 🟩 Beginner Track • Rareskills – Basics of Solidity → rareskills.io/learn-solidity • Cyfrin – Blockchain Basics → updraft.cyfrin.io/courses/blockc… • Cyfrin – Smart Contract Development → updraft.cyfrin.io/courses/solidi… • Rareskills – Solidity Style Guide → rareskills.io/post/solidity-… • Rareskills – Solidity Beginner Mistakes → rareskills.io/post/solidity-… • Cyfrin – Foundry Fundamentals → updraft.cyfrin.io/courses/foundry • Rareskills – Foundry Testing (Solidity) → rareskills.io/post/foundry-t… • Rareskills – Solidity Events → rareskills.io/post/ethereum-… • Rareskills – ERC 4626 → rareskills.io/post/erc4626 🟦 Intermediate Track • Cyfrin – Advanced Foundry → updraft.cyfrin.io/courses/advanc… • Rareskills – Invariant Testing (Solidity) → rareskills.io/post/invariant… • ConsenSys – Solidity Best Practices → consensysdiligence.github.io/smart-contract… • Rareskills – Function Selectors → rareskills.io/post/function-… • EOAs, CREATE & CREATE2 → rareskills.io/post/ethereum-… • Rareskills – Solidity Staticcall → rareskills.io/post/solidity-… • Rareskills – Low Level Call → rareskills.io/post/low-level… 🟥 Advanced Track • Rareskills – Proxy Patterns → rareskills.io/proxy-patterns • Cyfrin – Smart Contract Security → updraft.cyfrin.io/courses/securi… • Rareskills – Gas Optimization → rareskills.io/post/gas-optim… • Rareskills – Smart Contract Security → rareskills.io/post/smart-con… • Rareskills – Diamond Proxy → rareskills.io/post/diamond-p… • Github – Awesome Diamonds → github.com/mudgen/awesome… • Ethereum – Mastering Ethereum → github.com/ethereumbook/e…

What is the 'R1 Curve'? Learn about one of the elements pushing Ethereum user experience forward. The R1 Curve was part of the Fusaka upgrade that went live December 3rd.

New piece on @DSecurityES blog about Fusaka, @ethereum next upgrade: PeerDAS, blobspace, L1 limits and passkeys. Trying to scale L1+L2 without giving up decentralization. Curious to hear thoughts from protocol/client folks 👉 decentralizedsecurity.es/inside-fusaka-…

🦓 Fusaka is live! Ethereum latest upgrade is here and it's so cool. Let's break it down. 🧵👇

BuidlGuidl Capture The Flag. Thursday. 2 PM. 6000 USD in prizes, plus swag.

🌐 Capture The Flag ⛳️ 🗓️ Today! BuidlGuild Yellow Pavilion 📱 But first, MiniApp Morning!!!

🚀 SUI MOVE WORKSHOP — Aprende a programar en la blockchain de SUI 🗓️ Fechas: 29 y 30 de octubre 🇺🇸 Idioma: Inglés 🕠 Horario: 17:30h – 20:30h 📍 Lugar: Link by UMA (Edificio Green Ray) 💸 Precio: Gratuito ⚓ Imprescindible la inscripción Link: luma.com/ltofrkrk