calum.eth

Blockchain enthusiast, solo staker, software developer and organiser of the Glasgow Ethereum Meetup.

[GrapheneOS @GrapheneOS]

We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.

ARM hardware memory tagging (MTE) is used by GrapheneOS across the entire base OS including the kernel and every standard base OS process. It's only temporarily disabled for a few device-specific processes. It greatly improves protection against nearly all remote exploits and many local exploits.

Pixel 8 launched with hardware MTE support in October 2023. We integrated it into our hardened_malloc project and began using it across the OS later that month. Android and the Pixel OS never started using it by default. Android Advanced Protection Mode in Android 16 enables it for a few processes.

Apple's Memory Integrity Enforcement (MIE) is an always enabled feature on the iPhone 17. It's simply a high quality implementation of MTE using the latest standard extensions. It uses MTE in the most secure mode in the kernel and a large portion of userbase. They did a very good job integrating it.

Apple's MIE and Android 16+ AAPM don't use MTE for user installed apps unless those explicitly opt in. GrapheneOS enables it for more apps automatically and has a toggle for users to opt-in for every user installed app. There's a per-app toggle to opt-out for incompatible apps which is uncommon.

Neither iOS or Android encourage app developers to opt into MTE and other more aggressive security features used in the base OS. Apple's docs warn developers of performance and stability issues. Even Signal doesn't opt-in. Our approach enables forcing using MTE in the standard allocators regardless.

Pixel 11 does have security improvements including moving to post-quantum secure verified boot (ML-DSA) and replacing Samsung Shannon IMS with AOSP IMS. Titan M3 should significantly improve protection against data extraction in Before First Unlock state. It's too bad they ruined it by cutting MTE.

Pixel 11 series is a lot more expensive for an incremental improvement to the CPU, the same underpowered GPU and reduced RAM for the Pro base models. They finally caught up to the last generation of Qualcomm cellular radio. It's overpriced, the upgrades aren't impressive and losing MTE is appalling.

Compared to the Pixel 11, a Snapdragon 8 Elite Gen 5 has ~40% higher single threaded CPU performance, ~80% higher multi threaded performance, over 100% higher GPU performance and a far better cellular radio. It also finally has MTE. The next gen is what will be in the first Motorola with GrapheneOS.

Pixel 9a and earlier (including Nexus devices) were the Android Open Source Project reference devices. Pixel support was removed from AOSP with Android 16. It's now harder to support Pixels than many other devices and massive progress towards open source firmware and driver libraries was discarded.

Compared to the stock Pixel OS, GrapheneOS ships AOSP patches months earlier and Linux kernel patches many months earlier. However, we rely on them for firmware and most driver updates. We also want to move to new kernel branches earlier. These things can be improved with our Motorola partnership.

We strongly recommend against buying Pixel 11 devices. Pixel 8, 9 and 10 have much better overall security for GrapheneOS. Pixel 10 is cheaper with similar hardware and MTE. Pixel 11's Titan M3 should improve BFU security for users without a strong passphrase, but losing MTE craters AFU security.

We haven't determined what to do about this situation. It may be best for us to skip the Pixel 11 series devices. We can shift our focus entirely to the upcoming Motorola devices instead. Pixel 10a was really a 9th gen Pixel, so hopefully the Pixel 11a does the same with 10th gen and includes MTE.

[a16z crypto @a16zcrypto]

Can a sufficiently powerful quantum computer forge the signatures used to authorize Bitcoin and Ethereum transactions? What would it take to upgrade both networks before that happens?

In this new lecture, Stanford cryptographer @danboneh explores why blockchains may turn to signatures built from hash functions. He also presents new research on threshold signing.

The talk ends with the questions Bitcoin still has to answer, including whether post-quantum signatures will require larger blocks, what happens to abandoned coins, and how someone such as Satoshi could prove ownership after Bitcoin’s current signatures have been retired.

00:00 Why blockchains need to prepare for quantum computers
03:05 Why Bitcoin may bet on hash-based signatures
06:25 The “big footgun” in stateful signatures
08:58 A quantum-safe signature that takes one billion hashes
14:13 Inside SLH-DSA’s virtual tree
20:30 How Bitcoin and Ethereum could make the switch
23:48 What happens when a wallet loses its state?
32:47 Can threshold signing survive the quantum transition?
36:39 How to hide lattice cryptography from the blockchain
38:49 Why threshold one-time signatures seem impossible
45:36 How context prevents forged signatures
49:37 The forgotten idea behind Winternitz signatures
54:50 Turning one-time signatures into threshold signatures
1:04:27 Will quantum-safe signatures require bigger Bitcoin blocks?
1:06:26 Abandoned bitcoin and Satoshi’s recovery problem

[Chase Wright (mysticryuujin.eth) @mysticryuujin]

I was unhappy with the current state of Ethereum crawlers, so I vibe coded and open sourced a new one.

https://t.co/27NYUsu6XE

[ansgar.eth @adietrichs]

My thoughts on issuance:
1. the problem is real
2. the direction of the EIP is valid
3. but: changing issuance also has major downsides
4. most importantly: the decision must be with the community

I said a few words on the ACD call on Thursday, and wanted to expand on my thinking - both as Ethlabs co-founder and ACD moderator. In general, being able to have difficult conversations in public has always been a core strength of Ethereum.

1. The problem is real
- Slashing is core to Ethereum’s security. Not all attacks are automatically slashable. E.g. a majority of validators could censor the chain through malicious attesting. It needs to always be credible to slash such attackers. The larger portion of ETH is staked, and the tighter staked ETH is integrated into DeFi, the more credibility of slashing is at risk.
- Worse dilution for stakers: at low stake %, most rewards are real income. At high stake %, most rewards just offset dilution.
- Economies of scale: The competitiveness gap between centralized staking providers and both solo stakers and more decentralized staking providers widens at higher stake rates.
- Narrative confusion around ETH: ETH is a “productive asset” due to protocol revenue (fees & MEV), not staking yield. The staking yield also risks crowding out the emergence of other (productive) yield opportunities for raw ETH.
- Worse dilution for raw ETH holders: In general, harder assets are more attractive. BTC as the only $1T+ digital store-of-value explicitly centers zero long-term supply growth as its value proposition. Counter point: Gold with 1-2% yearly supply growth has a $30T store-of-value market cap.

2. The direction of the EIP is valid
- If one wants to limit the stake rate, the issuance curve needs to bend downwards for high stake %. The EIP is a specific instance of such a curve.
- The EIP also includes a further issuance reduction as a second phase. This introduces minimum viable issuance (MVI) as a secondary, monetary objective of the EIP. I personally think that is reasonable, but these two aspects should be discussed and reasoned about separately.

3. Changing issuance also has major downsides
- The decentralization of the staking set is crucial for Ethereum’s health. Many solo stakers are less economically competitive than large operators. A change that results in a significant drop in staking yield risks having these solo stakers disproportionately leave the staking set.
- Staked ETH is tightly integrated into DeFi today, both directly though LSTs, and through raw ETH lent out for the purpose of staking. Any major reduction in staking yield thus risks disrupting a core part of DeFi. This effect is worse the more rapid and more significant the yield drop is.
- Any change to Ethereum’s monetary policy resets the “monetary policy ossification clock”. Predictability of supply matters for ETH’s attractiveness as store-of-value. So far, changes are only ever towards issuance reduction, but will investors trust that that will hold true forever?
- Ethereum is overall at a pivotal moment. Given the large social cost of any months-long debate on issuance, it is reasonable to argue that this should wait until Ethereum overall is in calm waters, even if it makes a decision at a later time more painful.

4. The decision must be with community
- Most hard fork decisions are made by the allcoredevs (ACD) governance process. Conceptually, this is “delegated authority” by the community to the core devs. This delegation is very effective on most technical topics. For the occasional hard fork decision that is not primarily technical, this setup is however less well suited.
- Issuance in particular is not a technical decision. The decision still needs to be anchored to the ACD process - core devs need to coordinate on what to implement - but the actual decision forming needs to happen on the community level.
- This is easier said than done. The ACD process is flawed but well defined. A “community decision” is much fuzzier and harder to operationalize. Discussion venues like X are important, but also limited. How to have high quality community-wide discussions remains an important challenge to solve.

As we are getting off the ground at Ethlabs, we are trying to find the right path for how to contribute to both Ethereum and ETH. Issuance is a tricky topic for us: Caspar and I have argued for issuance changes in the past, and for now continue to have conviction in that path. The Ethlabs team as a whole has a wider spectrum of opinions, which has been healthy for internal discourse. And of course, we also see the broad community skepticism on this topic. The ability to have difficult conversations has always been a core strength of Ethereum. Our role in that should be to productively contribute to and engage with such conversations, not to blindly run in one direction. We will iterate to get that balance right, and genuinely appreciate feedback as we do.

[EthCoordinate @EthCoordinate]

Enter: EthCoordinate.

tl;dr: EthCoordinate is a crypto-native organization born inside the EthStaker community, bringing together separate efforts under one umbrella to help with Ethereum governance coordination, support Forkcast, increase stakeholder engagement on proposed or upcoming EIPs and, of course, continue providing software, tooling, and technical support for home stakers.

EthStaker started in 2020 when a loosely connected group of Ethereum enthusiasts joined efforts to speed up the development of the beacon chain. The organization steadily evolved, incorporating as a 501(c)4 nonprofit and taking up initiatives around independent participants of Ethereum's consensus mechanism, aka home stakers.

Throughout the years, it has played a decisive role in coordinating the launch and operation of devnets, testnets, and mainnet hard fork upgrades; facilitating information flows and generally connecting dots that needed connecting.

This year's tectonic organizational changes in the ecosystem have opened up functional gaps in Ethereum coordination. To close these gaps and continue supporting the network, EthStaker's core members are joined by mission-aligned fresh blood to aggregate efforts under one name to produce greater results than operating independently.

EthCoordinate is a natural evolution of EthStaker; as Ethereum mainnet heads to its third radical consensus protocol change at a steady pace, it’s time for EthStaker to recalibrate around what Ethereum’s evolving community needs.

Our mission is to facilitate interaction between stakeholders of the ecosystem to accelerate the adoption of the Ethereum network and to provide continuity for governance operations.

We believe that the Ethereum mainnet is an unparalleled bedrock for the augmentation of humanity's productivity output and that ETH, the asset, is the token that aligns the incentives of all actors involved.

We stand up for our values, combining technical rigor with pragmatism for Ethereum to continue being the most accessible and credibly neutral global blockchain.

The team is 10 long-tenured Ethereum professionals and currently our main work streams are:

⇥ Maintain a high-quality venue for independent stakers to remain engaged and informed
⇥ Facilitate coordination around core protocol development and adjacencies
⇥ Develop and steward Forkcast, the most popular platform to track the research and engineering initiatives around Ethereum's core protocol
⇥ Facilitate research, discussion, and coordination around protocol economics in support of Ethereum's long-term economic health
⇥ Maintain open source tools and documentation used by participants of the consensus set

We're energized for this chapter in Ethereum coordination & our role in it.

[nixo.eth @nixorokish]

okay, i actually love this. @ethvaorg has a vote for node operators to signal whether or not their income should be cut. they have 29 votes w 83k ETH voting no (surprise)

this represents 29 people each making $140k per year in passive income off the inflation of your ETH (1/x)

[calum.eth @calumtomeny]

I just reserved my Cloudflare Wallet tag: https://t.co/esnq9GkpfH.

Reserve yours now at https://t.co/5hHh2jBadg

[Ben Edgington @benjaminion_xyz]

I know it's totally weird for core devs to talk to users, but I've only gone and done it.

Upgrading Finality 2: What the Ecosystem Told Us

Huge thanks to all who participated 🙏

https://t.co/PV1S0xWjGS

[vitalik.eth @VitalikButerin]

Two weeks ago, Ethereum researchers met in Berlin to continue charting the protocol's long-term trajectory, following along discussions with client teams in Svalbard in April.

The updated strawmap is at https://t.co/9e2AQ6rhz6, and I attached a picture of it to this post.

My own high-level takeaways:

* "Lean Ethereum" is not a single one-shot upgrade, it is a collection of improvements that will come online to the Ethereum network over the course of three or four years. But make no mistake, this IS the third major iteration of Ethereum in the same way that the Merge was the second. Almost every major piece of the protocol will be replaced:

- Verification through recursive STARKs, rather than direct re-execution. Recursive STARKs become an enshrined first-class core component of the protocol
- Replacing everything quantum-vulnerable with quantum-safe alternatives
- Consensus: decoupled available chain and finality, one or two-round finality. Theoretically optimal security properties, simpler than today, and faster than today
- Multidimensional gas
- State: not just tree structure, but what *types* of state are available
- Changes to client architecture
...

At the same time, simplification, cleanup and future-proofing. And this will all be done in a way that minimizes disruption to existing application. We've done this before (the Merge), we can do it again.

* H-star (aka Hegota) is probably Ethereum's last thematically "pre-Lean" fork. Starting from I-star, most of everything we do will have a very strong "Lean" feel to it in one way or another.

* Privacy is no longer an afterthought, it is a first class goal. When designing Frames, the mempool, additions to the state tree, we explicitly ask the question "okay, how do quantum-safe, intermediary-free privacy protocol transactions go through this, and what is the overhead?"

* Formal verification of everything for security.

* FV also makes us much more comfortable with canonicalization (having pieces of the protocol that are directly defined as a piece of bytecode expressed in some language). evm-asm is being written in part to become a canonical proof system for the EVM.

* Quantum safety has shifted up a LOT in priority. This adds a lot of work (eg. finalizing a quantum-safe blobs design has become urgent; this work has already been ongoing for months)

* Probably the single most disruptive part of the plan is the changes to state. There is growing consensus around leaving present-day-style "dynamic state" mostly unchanged, but scaling it only a medium amount, and adding new types of state that are more scalability-friendly (eg. no need for builders to sync/store all of it) but more restrictive, and that will scale a large amount.

eg. possible Ethereum in 2030: 2 TB of present-day-style (dynamic) state, and 100 TB of new-style (scalable but restrictive) state

This "new-style" state would work very well for ERC20s, NFTs, many defi use cases, but not eg. highly "central" objects like Uniswap contracts, or onchain order books, or other complex things (which are crucial for Ethereum but which only take up a small percentage of state)

Hence, it will not be *necessary* to rewrite any apps, but it will be *very cost-effective* to eg. rewrite an ERC20 token into a newer design that uses a new type of UTXO storage that is currently being explored, so that it will have >10x lower txfees.

Design of these new state types (current ideas: keyed nonces, ring buffers, UTXOs, statically accessible state, temp state) is an area where we will need a lot of feedback from application developers (incl. privacy-friendly application developers) and probably several rounds of rethinking and iteration.

* In the context of a much larger total state size, we need to figure out the incentive issues around who stores this state and what motivates them to. Even saying "each node stores 1%" is not good enough - why do they store that 1% and why are they willing to serve it? This is being elevated as a first-class research area.

* Ethereum will need to have a "VM" other than EVM in one form or another - at the very least, we need something like leanISA for recursive STARKs - and the gains are large in exposing it to users so that we support programmable privacy and better scalability. Right now, the most likely contenders are leanISA and RISC-V.

My own ideal is that in this world, we adjust the protocol so that the EVM becomes a high-level-language compiler-level feature, and the protocol only "sees" RISC-V / leanISA directly. But this is still far away.

* Gas limit increases, blob increases and slot time decreases will happen many times over the next ~5 years. We expect a large gas limit increase with Glasterdam. Each step of increased scale or decreased slot time is a matter of getting to the point where it is safe to do it, which comes from a combination of client optimization and protocol changes.

Ethereum is CROPS.

Ethereum is scaling.

Ethereum is reinventing itself.

Onward.

[EthStaker 🦇🔊 @ethStaker]

The 2026 EthStaker staking survey results are out!

528 stakers told us how they run their validators and what they are worried about, and we analyzed that across the last 3 years of surveys.

Link to full analysis with charts in the next tweet and more in thread. ↓

[Matthew @ismiMatthew]

We’re launching @Ethereuminsti to accelerate institutional adoption of @Ethereum.

Learning about Ethereum was life changing for me, like it was for a lot of you reading this.

What drew me in then is the same thing bringing institutions to Ethereum today: a credibly neutral base layer and all that makes possible. And what it unlocks is the part that still excites me, finance with fewer middlemen, more access, better products, and real ownership for end users.

Institutional adoption is happening now, and where it lands decides what finance looks like for the future.

Joining the Ethereum Foundation last year to help build its enterprise function was the most direct way I'd found to work on exactly that. Now we continue that work at a far greater scale, and a lot more vocally. I’m delighted to be joined by two exceptional friends and colleagues in @davwals and @mariuslsmith.

Thank you to @BitMNR, @Sharplink, @ethereumJoseph, and the many allies backing us.

If this resonates, come build with us: [email protected]

If you're an institution or team and we're not already in touch, DM me or reach out: [email protected]

[Ethereum Institutional @ethereuminsti]

1/ Announcing Ethereum Institutional

An independent non-profit dedicated to accelerating the institutional adoption of Ethereum, its L2s, applications and overall ecosystem.

[Ethlabs @ethlabs_org]

Here's to a multi-node Ethereum.

[Aerugo @aerugoettinea]

1. Intro

Vitalik recently wrote about where the EF should go; Aya added a note to explain how we got here, and why. I’ll write about the execution.

We now have enough clarity to stop treating “what is the EF for?” as an open-ended question. Our mandate is clear: The EF exists to ensure Ethereum is, becomes, and remains real permissionless infrastructure for self-sovereignty: censorship (and capture) resistant, free and open source, private, and secure; and capable of supporting sovereignty-preserving coordination at scales where trusted institutions hitherto have been unavoidable.

The following are my thoughts on some of the points that follow from the mandate and how we are translating it to action. But first, a short reminder about

2. What the EF is not for

We are not here to optimize for EF importance, corpo/pol appeal, or ecosystem popularity. We are also not here to please short-term speculators, prop up TBTF neo-SIFIs, market every app on Ethereum, help anyone look good to their crypto or investor friends, or provide on-demand entertainment for dinner parties and private retreats.

3. What the EF is for: Eliminating weaknesses

We are here to defensively strengthen places where Ethereum is, or can still become, extractive, totalizing, or vulnerable to cartel or state capture, or authoritarian tools of surveillance or coercion.

We will base our actions on a full examination of what Ethereum is and can be at the protocol layer (what is actually running as “Ethereum”), the access layer (what users use to interact with the protocol), the user layer (the end-users who need and will need Ethereum), and the institutional layer (the intermediated paths that scale self-sovereign usage).

The EF exists to harden every surface of Ethereum, including those where Ethereum can remain formally permissionless while becoming practically captured. Some obvious surfaces are the transaction pipeline, staking and network security, access layer standards and interfaces, self-sovereignty norms, privacy expectations, institutional adoption patterns, and social layer governance processes. The primary concerns are similar across most of them: does the status quo and its future trajectory minimize trusted dependencies, minimize points of leverage and capture vectors, make user privacy the default, preserve exit, and make trust assumptions legible?

The work starts with the EF itself. We are moving compensation and major financial relationships toward ETH and mandate-compliant Ethereum-native stables, with exceptions where positive law or unavoidable operational constraints require exceptions. Rather than a purity ritual or instruction for people to take unmanaged personal risk, it is robustness, alignment, and product pressure. If the EF’s work is to make Ethereum usable as infrastructure for self-sovereignty, everyone at the EF will increasingly live inside the constraints of the system the EF exists to improve: wallet UX, volatility, accounting, privacy gaps, payment friction, stablecoin trust assumptions, recovery, dependency risk, etc. If we can’t use these tools ourselves, it is unrealistic to expect others to. Ethereum is already mature; those who do not depend on the user-facing stack have no business trying to shape its future, at any layer.

The transaction pipeline is next. Preventing toxic MEV capture is core EF work, not a peripheral market-structure concern. Transaction supply, ordering, inclusion, block construction, propagation, and settlement are part of Ethereum’s neutrality boundary. Some MEV may persist as an adversarial phenomenon the protocol contains, but it must be absolutely minimized and, for that to be possible, we must guard against the acquisition of unwarranted influence by its beneficiaries.

If credibly neutral execution is subverted by privileged orderflow, cartelized builders, trusted relays, opaque routing, or validators outsourcing into a narrow supply chain, Ethereum will look permissionless while users experience it as intermediated at the moment value moves. EF protocol work will therefore prioritize lower barriers to block building and validation, stronger inclusion guarantees, reduced extraction opacity, competitive transaction pipelines, user-facing legibility of trust assumptions, and more aggressively exploring the open orderflow solution space.

None of this is simple. A good solution in one place can aggravate problems elsewhere. FOCIL is good for censorship resistance, but it may introduce more cross-block MEV. While ePBS solves the relayer trust problem, we must make sure that its implementation does not inadvertently obstruct long-term solutions to even larger problems. It would be unacceptable, for example, if ePBS enshrining the builder economy ends up making it harder to reduce reliance on the private orderflow that has emptied out the public mempool. Encrypted mempools may not only reduce pre-execution transparency and pending orderflow visibility, but also shift competitive advantage to new privileged actors, including specialized hardware operators in some designs, while adding protocol complexity.

In order to avoid wasting time playing whack-a-mole, we must commit to solving the extraction problem at a whole system scale. Doing so will require creativity, courage, and the understanding that failure to solve this problem is unacceptable. If we fail, we will have left in place an unnecessary barrier to institutional adoption, but, more importantly, we will also have surrendered a core part of the promise of Ethereum - the replacement of extractive middlemen with permissionless, credibly neutral infrastructure and competitive markets. That must not happen.

MEV is likely to be the next major front in the cypherpunk war. We must set ourselves up to win here.

Privacy is just as fundamental. A public ledger without serious privacy defaults is a surveillance substrate with settlement guarantees. That is not an acceptable end state for the world computer. Unconditional privacy will be readily available across Ethereum, with programmability on top for selective disclosure, proofs, auditability, compliance logic, reputation, governance, identity, and other constraints chosen by users and their communities. The temporal order matters: unconditional privacy must exist first, opt-in constraints come second.

It is also important to avoid forcing users to assemble a fragile stack of special wallets, RPCs, bridges, apps, compliance providers, and operational habits to attain privacy. Deep privacy must be more secure than this. Privacy is a condition for Ethereum’s viability as freedom-respecting coordination infrastructure and as such must be robust.

Staking must be treated as protocol infrastructure risk. Staking is not merely a yield product, and liquid staking is not merely an app-layer market. If stake, liquidity, validator access, DeFi collateral, and governance influence concentrate around a small set of issuers or operators, Ethereum’s security layer becomes vulnerable to capture through capture of the economic layer around it. EF will support research, specifications, and designs that keep staking permissionless, private where possible, plural in operation, and resistant to intermediaries becoming permanent control points.

The access interfaces are where users access either the protocol directly or through intermediated defaults. The primary problem to solve here is not getting Ethereum into more rooms directly, but making its users, both end users and institutions, more self-sovereign and less susceptible to coercion, and avoiding normalization of soft coercion in exchange for reach. EF will not help Ethereum become more acceptable by sanding off the properties that make it uniquely valuable. Ethereum does not need to become another permissioned settlement backend with better branding. It needs to show, in production, that self-sovereign coordination at scale is possible.

Across Ethereum, the EF’s defensive work seeks to ensure that Ethereum is infrastructure people can still use when counterparties fail, platforms censor, governments overreach, intermediaries extract, and coordination problems become infeasible for trusted systems to handle. A core part of that is to make that infrastructure secure and robust against capture at every layer wherever capture opportunities can hide.

4. What the EF is also for: Seizing opportunities

Shoring up the fundamentals is not enough. Ethereum’s potential is still largely unrealized, but that does not mean that the path ahead is going to be straight. Opportunities must be seized when the time is right. At this moment in time, a number are visible, including:

* Ethereum becoming the first quantum-resistant global infrastructure. Ethereum researchers will lead the post-quantum cryptographic migration before the threat becomes urgent, not after it becomes a governance emergency. That means hardening Ethereum’s cryptographic foundations while there is still time to design carefully. The same applies to other long-horizon risks, where waiting for market demand means waiting until the window for principled design has already closed.

* Verifiably self-sovereign stack, from soup to nuts, whether local or remote, with no censorship or extraction openings: browsers, wallets, intents, broadcasts, orderflow, inclusion, block construction, proposal, proving, exit, and recovery. Minimal MEV, and zero toxic MEV entrenchment, either in or around the protocol. No execution layer that is formally permissionless but practically gatekept by privileged supply chains. If there’s a funnel towards an extractive private lane, there’s other options that keep the game live. The goal is not only to prevent extraction or capture, but to make credibly neutral execution competitive enough that serious users prefer it.

* Making ETH normal digital cash: a private, dignity-respecting, debasement-resistant and surveillance-resistant medium of exchange and store of value, as well as the native asset of private computation and private coordination for both humans and their agents. If Ethereum can make private economic life and private institutional life possible without routing users back through the friction and potential abuse of custodians, surveillance vendors, or permissioned ledgers with softer branding, as well as provide a venue for secure and competitive machine economics, the value unlocks will be immense.

* Personal wallets with personal AI agents that users can actually own and run on their own personal computers. Not your keys, not your coins; not your model, not your mind. As agents become interfaces for more economic and social action, the question of who owns the wallet, the model, the memory, the policy, and the signing authority becomes an existential question about sovereignty instead of UX details - we are all users above any other roles, and no one at EF will forget this.

* Institutional and enterprise use cases where Ethereum wins by not disappearing into an invisible backend, gatekept by intermediaries or terrible UX, and by not compromising into a compliant fintech rail with web3 branding. Rather, we will win through proving that credibly neutral infrastructure can handle disintermediated coordination so competitively that trusted intermediaries have to meet Ethereum users on Ethereum’s terms.

* Security-preserving scaling. L2s and related infrastructure will be able to meet institutional-level needs without accepting dependencies on closed operators, opaque sequencing, custodial UX, or upgrade committees that users cannot realistically exit. Scale is not throughput alone. Scale is the guaranteed availability of self-sovereignty under real load.

We are ensuring Ethereum remains the hardest bedrock for settlement, local and worldwide; and beyond that, a civilizational ledger and execution substrate to stand the test of time. When future civilizations speak of the infrastructure they inherited from the Antiquity of the Information Age, their first example should be Ethereum.

Ethereum will outlast all of us. More than enough people watching understand this. Many wondered why it needed saying at all, but it did. If you don't believe us or don't get it, we don't have time to try to convince you, sorry.

5. Addressing departures

There has been a lot of online speculation about departures from EF, both before and after the mandate. Some people resigned, others were terminated. Some departures were about strategy, some about role fit, some about normal institutional change, and some simply about people deciding that their best work for Ethereum should happen somewhere else. We will not litigate individual personnel matters on Twitter. That is the default because it is better for EF, better for the people involved, and better for Ethereum. People who contributed through EF deserve dignity on the way out. They do not deserve to have their employment history turned into factional content.

Where possible, we have let people describe their departures in their own words as a matter of courtesy, and not concession. If public claims materially mislead people about EF’s direction, decision-making, or mandate, we may correct the record at the level of policy, process, and institutional facts. We still will not turn personal files into public spectacle.

Ethereum is permissionless. People may disagree, criticize, compete, fork, and build elsewhere. We intend to keep exits dignified and expect others to do the same. It will suffice to say that we are thankful for what all contributors have built; we will continue to do work Ethereum needs.

6. Addressing EF spinouts

Some work should and will leave the EF in the months to come. We hope and expect this process to result in some excellent work being done in service of scaling self-sovereign adoption, but we also must take care lest it becomes an abdication of responsibility or an excuse for undisciplined spending. Some work is not mandate-compatible and should not be carried forward with EF funds or EF endorsement, either inside or outside the Foundation.

The efforts carried out by the spinouts will vary widely. Some efforts will leave EF because another org would be a better home for them; others will leave because markets should decide on their worth. Some will leave because they are not compatible with the direction set out in the mandate; others because they are useful but not EF work.

Just as a spinout is not automatically good because it reduces EF headcount, former EF affiliation is not a claim on EF funding. The question we ask when deciding on funding is not “did this come from the EF?” But, rather the questions that should be asked about all external funding:

“Is this work mandate-critical? Would the EF do this work internally if it had the organizational and financial capacity? Is there no better natural home? Can the external party execute without increasing capture risk, private extraction, opacity, or dependence? Does supporting it reduce Ethereum’s dependence on the EF over time, without prematurely transferring resources and legitimacy to new organizations and thereby risking operational failure or mission drift?”

EF funding for work being done externally can be appropriate when it is a capacity solution for mandate work - work the EF should responsibly want done; work that protects CROPS; work that advances self-sovereignty and scales it; essential work that no actor can or will reliably do without EF funding; and work that can be scoped, reviewed, and held accountable without creating a permanent dependency.

Such funding is not appropriate when it is a lazy continuity payment, a friendship payment, a reputational hedge, a way to avoid making a hard decision, or a way to support work that is not compatible with the mandate.

EF has finite funds, finite legitimacy, and a specific mandate. We will spend all three as if they matter. When we say “EF is one of many nodes”, we mean that we intend to be one of many nodes working to keep self-sovereignty and its scaling the North Star, and working to keep CROPS the undisplaceable first-class properties of the network. We don’t mean that we will support orgs or projects with different priorities. Diversity that leads to ecosystem resilience, coordination cost right-sizing, and better decision-making is good. Diversity that leads to mission drift is not.

We are not neutral on the direction Ethereum takes. CROPS are not just things we “believe in”, they are characteristics we understand must be thoughtfully prioritized at every fork for Ethereum to realize its potential. We are partisans for and builders of something of such incredible neutrality that it will fundamentally reshape the world we live in; we wish to work with everyone committed to this shared purpose.

[Ethlabs @ethlabs_org]

Announcing Ethlabs: a non-profit R&D lab for Ethereum and ETH

Our mission is to make Ethereum the settlement layer of the global economy.

The internet became global because shared protocols created a common language between networks. Private systems remained useful, but bounded. Finance is approaching a similar moment. As value, assets, and markets become digital, the world needs shared settlement infrastructure.

Ethereum is uniquely positioned to become that shared base layer, the neutral foundation on which users, institutions, and agents can transact without intermediation.

What we believe:

• We believe credible neutrality matters. Ten years of uptime and the lowest counterparty risk. Ground that cannot be pulled away by any one country, institution, company, or person.

• We believe ETH matters. The most valuable, programmable store of value. A decade of broad distribution, deep liquidity in onchain markets, and maximally trustless asset on Ethereum.

• We believe DeFi matters. Markets, liquidity, credit, exchange, and coordination, open to anyone.

• We believe adoption matters. Principles do not change the world until people benefit from them.

We sit between two worlds: real usage from the builders at the frontier, and the protocol that has to support it. We work with users, applications, wallets, L2s, infrastructure teams, institutions, ETH holders, core devs and researchers, then turn what they actually need into protocol work, shared standards, infrastructure, and shipped products.

Ethlabs is independent but Ethereum is a shared project. We are one node in a much larger network of stewards. This is the multi-node future.

We have spent the better part of the past decade contributing to Ethereum core research and development.

We are opinionated and transparent. We move with urgency, learn in public, and course-correct when we’re wrong.

We are building a lean, talent-dense team for people who want to do the most important work of their careers: [email protected]

[jasperthefriendlyghost.eth @drjasper_eth]

1/ The @ethlabs_org announcement has generated a massive reaction across Ethereum - I've collected some highlights in this thread.

Welcome ETHLabs!
👇

[Etherealize @Etherealize_io]

https://t.co/Ri0Tew0Dkc

[Péter Szilágyi @peter_szilagyi]

The scary part about Anthorpic's Fable nerf is not that it refuses to answer biology or cryptography. It's that it foreshadows what's coming. A world where a couple companies decide what you can and cannot do. They're building a new ruling class and you're not in it...

[marilyn100x.eth @marilyn100x]

Glamsterdam has ten EIPs included(confirmed) that are shipping together, each fixing a different issue and touches every layer of @ethereum

> EIP-7732 ePBS: Block builders enter the protocol, validators stop depending on off-chain relays.
> EIP-7928 BALs: Transactions execute in parallel, blocks process significantly faster.
> EIP-7708: Every ETH transfer now emits a log, giving ETH the same trackability ERC-20 tokens have always had.
> EIP-7778: Gas refunds are removed, making block gas accounting predictable and consistent.
> EIP-7843: Smart contracts can read the current slot number natively.
> EIP-7954: Contracts can store more logic without hitting size limits.
> EIP-7976: Calldata floor cost increases to reduce worst-case block size.
> EIP-7981: Access list costs increase to reflect actual resource usage.
> EIP-8024: New stack opcodes resolve the stack too deep compiler issue in Solidity.
> EIP-8037 & EIP-8038: State creation and state access get repriced to slow chain growth.

Ten fixes. One fork.

[prestonvanloon.eth @preston_vanloon]

Ethereum is the only network with 100% uptime