Christine D. Kim

Fall 2026 to Spring 2027, My Last Hurrah!

Christine D. Kim — Wed, 02 Sep 2026 11:03:00 GMT

Hey everyone,

As we head into the fall, I have important news to share with you: I may wind down this Substack publication starting next spring.

Before I get into why, I want all my subscribers to know that your support for my content has been, and will continue to be, invaluable through the spring. I am so grateful for your support.

Whether you have been reading my work since the beginning or have just joined, don’t take this news as an announcement that I’m leaving immediately. I’m not going anywhere. I still have big plans for this publication this fall, one of which is the recently relaunched Ready for Merge podcast.

But due to Substack’s policies around paid subscriptions, which can’t easily be wound up and wound down, I am giving you all an early heads-up about my emerging plans for next spring so that when I am ready to take a break from writing, it’s a smooth transition.

To this end, readers, please take note of the following:

Subscribers who are on the annual plan:

If you recently renewed your subscription or have a subscription that will expire after spring 2027, thank you for your support!

If between now and next spring you don’t think you got your money’s worth, no worries. I can prorate the cost for the remaining months of your subscription when this publication winds down.

Also, if you forget this information, don’t worry. I will follow up with you via email or another post closer to next spring to remind you about this option.

If you have a renewal coming up, that is, anytime between now and Spring 2027, please carefully consider if you wish to renew at the same rate or switch to a monthly plan.

I strongly recommend switching to a monthly plan, but if you choose to renew on the same annual plan, I cannot stop you, and I will not be actively following up with you about prorating the cost. This is mainly for my accounting sanity!

However, I will remind you in an automated email about my upcoming pause a week or two before your renewal, so you can update your plan accordingly and nothing comes as a surprise to you next spring.

Subscribers who are on the monthly plan

Thank you for subscribing! I will still be publishing on a regular cadence between now and next spring. You are welcome to stay on for that period or move down to a free plan.

Note that, unlike subscribers on an annual plan, monthly subscribers will not receive automated plan renewal reminders. So, I will follow up in a separate post a month or two before I officially start my break, reminding you all to cancel your monthly Substack subscriptions.

Subscribers who are on the free plan

Thank you for reading my content! If at any point you wish to support my work financially before next spring, please be aware that all benefits of being a paid subscriber, except for access to the CDK archives, which will remain a paid subscriber’s perk, will only be available until Spring 2027.

This should now be clear on both the plan offerings page before you sign up for a paid subscription and specified in the welcome email you receive straight after you sign up for a subscription.

Phew.

That was a lot of information, but I hope it is clear and fair to everyone who has supported my work over the years.

If you have any questions or concerns at all about what I’ve outlined above, please do not hesitate to reach out. I would be happy to chat with you.

As for why I’m likely to wind down this publication next spring and what I plan to do next, I’ll share more about that in a separate post. For now, I’m going to pause here. Let this information sink in with you all. Hear any feedback from you. Then I’ll be back with another post on the why, and, of course, in the meantime, you’ll still be receiving your usual weekly Bitcoin and Ethereum development updates from me.

Thank you for bearing with me as I dumped on you the culmination of several weeks of thinking about how to ensure a smooth wind-down for this publication. Substack doesn't make it easy to stop writing once you’ve started, but that’s probably a feature, not a bug, of this platform.

I’ll talk to you all again soon. In the meantime, don’t hesitate to reach out with any questions. Appreciate you all!

Me on Roosevelt Island feeling pumped for the fall!

Yours truly,

Christine D. Kim

The AI Question Bitcoin Core Can't Agree On

Christine D. Kim — Tue, 01 Sep 2026 11:03:06 GMT

Good morning,

Last Thursday, Bitcoin Core developers had a lively discussion about the uses of AI in their project and how to change perceptions that they may be “behind the curve” in leveraging this technology for faster, more secure development.

The discussion highlighted important qualities of Bitcoin that make it distinct from other software projects and significantly harder to answer questions about when there’s no social consensus on the matter.

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

☀️ I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:

Protocol Watch

The side 🍳

The main 🥞

Editor’s note (Updated 09/01/2026): This article was updated to include information about the identity of “Moneyball,” who is Steve Lee, the lead of Spiral, a non-profit R&D lab within Block focused on Bitcoin and AI.

Bitcoin Core developers gathered for their weekly meeting, hosted over IRC in #bitcoin-core-dev, last Thursday, August 27.

The main topic of discussion was growing concerns that Bitcoin Core developers may be “behind the curve” in adopting AI technology to enable faster, more secure development.

The topic was proposed by Steve Lee, also known as “Moneyball,” who claimed:

Several people, including donors have approached me expressing concern that Bitcoin Core devs ‘aren't paranoid enough about AI cyber threats’ and that the Core project isn't sufficiently leveraging AI tools for tasks like assisting issue and PR triage, code review, and test case development.

Ready for Merge Demo Recording w/Murch👾

Fri, 28 Aug 2026 11:00:13 GMT

Hey everyone,

Happy Friday! I hope you all had a good week.

As a friendly reminder, the Ready for Merge podcast returns next week for Season 2, and as a teaser for this upcoming season, I’m releasing a dry-run episode today that I filmed with one of the new recurring hosts of the show, “Murch” from Localhost Research.

This season, I’ll be joined by two recurring show hosts: Murch from Localhost and Nixo Rokish from EthCoordinate, to discuss Bitcoin and Ethereum developments, respectively.

For any of my listeners who aren’t familiar with these two incredible individuals, stay tuned for the kickoff episode next week, where I’ll be going live with Murch and Nixo to discuss their backgrounds in protocol development and share more details on Season 2’s show format.

Here are the full details on how to join next week’s livestream:

When: Wednesday, September 2, at 12:30 pm (ET)

Where: X and YouTube

In the meantime, as a teaser for the season that hopefully gets you excited to tune in to the podcast, check out this recording, which Murch and I filmed together in preparation for a new segment of Ready for Merge that I like to call, “BTC Updates with Murch,” or as Murch likes to call it, “Ready for Merch.” ;)

Yours truly,

Christine D. Kim

Episode Summary

In this dry run recording filmed in preparation for Season 2 of Ready for Merge, Christine D. Kim and Murch from Localhost Research discuss what users can expect from the next major Bitcoin Core release, v32, and the recent removal of Bitcoin’s longest-serving BIP editor, Luke Dashjr, from his role.

This episode was recorded on August 19, 2026.

Timestamps

(0:43) Bitcoin Core v32’s feature freeze deadline

(2:22) Why Bitcoin Core releases are not feature-dependent

(4:59) Major features in Bitcoin Core v32

(13:44) Bitcoin Core v29 to reach end-of-life

(20:34) Why Luke Dashjr’s BIP editing privileges were revoked

(24:57) Cases where Bitcoin Core contributing privileges have been revoked

Show Links

Song Credits

Special thanks to Calios for the music featured in this episode. You can listen to the full track, “Our Lives,” and other songs by Calios on Spotify:

👾 Thank you for tuning in! If you liked today’s show, consider sharing it with a friend who might also enjoy the episode.

💻 If the episode sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your thoughts by leaving a comment.

Frame Transactions SFI’d for Hegota

Christine D. Kim — Fri, 28 Aug 2026 00:01:12 GMT

Good evening,

Today, Ethereum developers decided to Schedule for Inclusion (SFI) one more proposal in Hegota alongside Fork-choice Enforced Inclusion Lists (FOCIL).

It’s the proposal developers weighed earlier this year against simply not shipping any execution-layer-focused headliner feature in Hegota at all.

EIP-8141, Frame Transactions, is now officially on the roadmap for implementation following the Glamsterdam upgrade, but there are a few important caveats about its inclusion that readers should note.

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. Expect another email from me in your inbox tomorrow morning. I have some news to share about next week’s Ready for Merge podcast launch, but it's too much to cram into tonight’s post. So, I’ll talk to you again tomorrow!

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

The window of opportunity for Ethereum developers to ship the Glamsterdam upgrade before the end of the year is narrowing rapidly.

Developers hopeful for a December upgrade

The most recent attempt to activate the upgrade on Glamsterdam Devnet-8 went poorly, delaying the launch of the subsequent test network, Glamsterdam Devnet-9.

Since developers announced their final planned devnet for Glamsterdam in July, the timeline for activating the upgrade on public Ethereum testnets has been pushed back by roughly two months due to bug fixes and the addition of new planned testing milestones.

The consequence, as stressed by EthCoordinate’s Nixo Rokish, who chaired today’s Ethereum developer call, ACDE #244, is less margin for error in the weeks of testing ahead.

She said:

I just wanted to highlight how tight we are on timeline … if we're going to fork by the beginning of December.

As shared last week, the proposed timeline for Glamsterdam is to upgrade the Sepolia and Hoodi testnets on September 28 and October 26, respectively, then allow 30 days’ notice for node operators to upgrade their software for an Ethereum mainnet hard fork sometime in early December.

For this to happen, fingers are still very much crossed for a successful and smooth upgrade activation on Glamsterdam Devnet-9.

Developers SFI Frame for Hegota

On the topic of Hegota, developers reached an important decision on today’s developer call. They agreed to Schedule for Inclusion (SFI) EIP-8141, Frame Transactions.

(Here’s a non-technical explanation of frame transactions by yours truly.)

Now, there are a few major caveats worth mentioning about the decision to SFI Frame.

First, the decision was made in the last three minutes of the call, after a key speaker representing the views of Ethereum Layer-2 projects and application developers, “Chris” from the Base team, left the meeting.

Second, the decision was conditioned on the premise that virtually everything about EIP-8141 may change.

Rokish said:

We can move it to SFI if there’s a strong feeling to do that, as long as the caveat is there that it may change; the EIP number may change; the implementation may significantly change.

Thus, despite the SFI decision, there will still likely be debate about how exactly to implement frame transactions on Ethereum.

However, because of the decision, I don’t expect there to be much more debate on whether frame transactions should be how native account abstraction (AA), think more flexible user accounts, is enabled on Ethereum.

The conversation is progressing toward Frame as the clear winner for client teams to implement in Hegota, pending changes and input on it from Layer-2 teams like Base.

This represents a clear shift from where the conversation was a few days ago, before ACDE #244. Earlier this week, the community was discussing the potential of revising other proposals, specifically EIP-8130, to look more like frame transactions and include it, rather than frame, in Hegota.

Derek Chiang, an Ethereum protocol researcher at EthLabs, wrote an excellent X post on the trade-offs between updating EIP-8141 to be more like EIP-8130 or the reverse, updating EIP-8130 to function more like EIP-8141.

Now, based on the decision from today’s call, it’s clear that Ethereum client teams and protocol developers are leaning strongly towards the former, not the latter.

Bottom line

Today’s decision to SFI Frames in Hegota does not diminish the strong support among application developers for alternative proposals to Frames, like EIP-8130.

It also doesn’t undervalue the clear preferences of Layer-2 development teams like Base and Offchain Labs for EIP-8130 over EIP-8141.

It primarily highlights the fact that nearly all supporters of the alternative proposals to Frames are also strong supporters of working with client teams and Ethereum protocol developers to make Frames work in Hegota.

As “Lumi,” a senior product manager at Offchain Labs, said on X:

We think 8130 deserves genuine consideration in this headliner process, but we are not explicitly asking ACD to adopt it. If ACD converges on a modified 8141 for L1, we will support this effort and reconsider implementing it alongside 8130. What matters most to us: Native AA standards designed with L2s in mind, in compatible ways, so wallets and infra can support them.

Before leaving today’s meeting, Chris from the Base team said:

Moving to the frame model does, you know, cost stuff for us. So this is where we’re just trying to align, and like, you know [figure out] what is the right shape of, like, frames.

Thus, the decision to SFI Frames was an easy one for developers to make on today’s ACDE #244 call. Supporters of Frames were obviously in favor, and more importantly, opponents weren’t strongly opposed either.

Temperature check 🗳️

Prior week’s quiz answer: 7 CL and 6 EL.

What’s going in Bitcoin Core v32

Christine D. Kim — Tue, 25 Aug 2026 11:04:32 GMT

Good morning,

The feature-freeze deadline for the next major Bitcoin Core release, v32, has recently passed. In today’s newsletter, I’m discussing what major features, or as my Ethereum readers might call them, headliners, have made it into the release.

Much of the information I gleaned for today’s post was gleaned from a recent conversation I had with a Bitcoin Core contributor who will be joining me as a recurring guest on the Ready for Merge podcast this upcoming season.

As a friendly reminder, R4M Season 2 kicks off next week. Stay tuned for more details about this and the mystery co-host(s) for the season coming out from yours truly and all R4M podcast channels later this week.

Now, without further ado, let’s get into today’s main story.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

The side 🍳

The main 🥞

The feature freeze deadline for Bitcoin Core v32 passed last Thursday, August 20. Now, developers are focusing on bug fixes and minor optimizations only for the next major version of Bitcoin Core software.

For my Ethereum readers, this milestone in the development process for the Bitcoin Core client is akin to reaching the consensus- and execution-layer specification freeze deadline for Ethereum hard-fork upgrades.

Basically, the feature set for v32 is now final, and this week I want to discuss which “headliners,” or major features, made it into v32.

One of them, regular readers of this newsletter may already be familiar with, as I’ve discussed it on multiple occasions in prior newsletters. It’s PR #35295 (Fetch block input prevouts in parallel during ConnectBlock).

As a refresher, this PR speeds up block validation in Bitcoin Core nodes by up to 3x. It does this by enabling the software to utilize multiple CPU cores in parallel during block validation.

The other two notable features that just made it into v32 by the freeze deadline are:

PR #34628, Replace per-peer transaction rate-limiting with global rate limits
PR #34075, Introduce Mempool-Based Fee Estimation to reduce overestimation

Transaction rate-limiting

PR #34628 is the last in a series of improvements to Bitcoin Core that, as a whole, make nodes more resilient and responsive during sudden surges in transaction activity.

Back in 2023, there was a surge in transaction activity due to high interest in minting and trading tokens like BRC-20s and Ordinals on Bitcoin. The high transaction volume caused low-powered Bitcoin nodes, such as the ones running on Raspberry Pis, to become overwhelmed and stall.

Shortly after this incident, Bitcoin Core developers released several software updates to make nodes more resilient, including doubling the rate at which pending transactions are relayed between nodes.

PR #34628 is another relay improvement that implements a new global queue for pending transactions. In the words of PR author AJ Towns, the new global queue has several benefits.

AJ Towns wrote in a Delving Bitcoin post:

[PR #34628]:
should keep your CPU available for validating blocks and transactions, not use it all up for resorting the same set of txs for each peer
should cope cleanly with large backlogs of transactions
should smooth out large transaction bursts, focusing on relaying the txs in the top of the mempool (per cluster mempool rules, of course)
introduces a new bandwidth ratelimit that should prevent excessive numbers of large transactions that never confirm from blowing out your VPS’s monthly limit, even if you have a couple of hundred peers to relay those txs to

Mempool-based fee estimation

The other major feature included in Bitcoin Core v32 that just made it in by the freeze deadline is PR #34075 (Introduce Mempool-Based Fee Estimation to reduce overestimation).

Like transaction rate limiting, it targets node behavior during periods of high transaction activity — in this case, fee estimation. Bitcoin Core currently estimates fees based on the history of recently confirmed blocks and transactions moving through the mempool.

It considers which fee rates have been confirmed in prior blocks and how fast. However, it does not consider the length of the queue of pending transactions in the mempool, in other words, how full the mempool is, which can cause estimations to fall out of date when the backlog of transactions in the mempool is high.

The new estimator incorporates information from the current mempool contents to lower estimates when appropriate and before the mempool backlog is fully cleared, thereby eliminating scenarios where the software may overestimate fees and cause users to pay more to send a transaction on Bitcoin than necessary.

This is a feature that most block explorers and dedicated fee estimation tools have already implemented years ago. PR #34075’s version is more conservative than existing ones out there by design, but for users who still rely on their own Core node for fee estimates, it is a long-overdue improvement.

Bottom line

In summary, Bitcoin v32 will introduce faster node synchronization, improved transaction relaying, and more accurate fee estimations.

It is on track for a final release this October, and with the release, there will also be a few announcements regarding the deprecation of major version v29 and related minor versions.

Industry stakeholders who run their own Bitcoin nodes are encouraged to upgrade to the latest software version when it becomes available to take advantage of optimizations and improvements to Bitcoin Core that developers continue to push out like clockwork, even whilst the Bitcoin protocol remains unchanged.

These releases, which introduce no network-wide protocol changes, may still offer meaningful improvements to users’ day-to-day operations of their Bitcoin nodes.

Knowledge check 🗳️

Prior week’s answer: A tax on spending dormant coins

The Hegota tier rankings that matter most

Christine D. Kim — Fri, 21 Aug 2026 00:00:46 GMT

Good evening,

Today, Ethereum developers discussed dates for activating Glamsterdam on public testnets, starting with Sepolia, the most widely used Ethereum testnet by application developers.

However, these dates are still tentative, as developers have yet to activate Glamsterdam on a short-lived testnet successfully.

Below is my latest on what industry stakeholders need to know about the status of Ethereum development and protocol decision-making.

Yours truly,

Christine D. Kim

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

On Glamsterdam progress, I have good news and bad news.

Bad news first. We still have yet to see a successful version of the Glamsterdam upgrade on test networks.

Developers had launched their 9th Glamsterdam testnet, Glamsterdam-devnet-8, last week.

Called “devnet” because most of these networks were private and called “8” because the networks were numbered starting from zero, in case you were wondering. You know me, I’m an over explainer. Anyways, this is besides the point.

The Glamsterdam upgrade on Devnet-8 caused the network to lose finality, think reduced network security and stability, after close to half of the validator set failed to process staked builder deposits.

Ethereum Foundation Developer Operations Engineer Barnabas Busa said on the latest All Core Developers (ACD) call, ACDC #185:

Major issue was that some clients [had a] bad implementation of caching builder deposits to process them during the fork transition. So, we saw this with Lighthouse, Prysm, and Teku. They all struggled to process the first slot right after we activated [Glamsterdam], because we had about 16,000 builder deposits queued up.

Client teams reported on the call that the issue has already been fixed in their implementations.

However, due to the instability of Devnet-8 through the upgrade activation, the setup of application developers and other network stakeholders that had joined the devnet to test their infrastructure were disrupted.

Dmitry Gusakov, Head of Engineer at Lido, Ethereum’s largest liquid staking service by total ETH under management, requested a re-do of the upgrade on another testnet before developers begin upgrading public Ethereum testnets.

Ethereum Foundation Developer Operations Engineer Parithosh Jayanthi, who was also chairing this week’s developer meeting, assured Gusakov that he and other development teams will get another opportunity to test their setups on next week’s non-finality testnet.

Fingers crossed, this one goes over smoothly. If it does, it’ll be the first and taken as the green light for developers to move on to upgrading Ethereum’s public testnets.

Developers talk dates for public testnet upgrades

Speaking of public testnet upgrades, the good news is that developers remain optimistic about the timeline for these.

Jayanthi proposed on ACDC #185 a tentative upgrade schedule that would activate Glamsterdam on Sepolia on Monday, September 28 and then on Hoodi on Monday, October 26.

Gusakov pushed back on these dates, requesting more time for application developers to prepare for public testnet upgrades, which Jayanthi was agreeable to. Thus, the actual upgrade schedule may place the first public testnet upgrade on Sepolia sometime in early October, rather than late September.

In either case, developers are getting close to finalizing Glamsterdam and have already thrown out a few proposed dates for the public testnet upgrades.

The Hegota tier rankings that matter most

On progress for the Hegota upgrade, developers have closed the window for proposing features. As I shared last week, developers are now evaluating a list of roughly 66 Ethereum Improvement Proposals (EIPs) and selecting a subset of these to include in Hegota.

This time around, developers are leaning heavily on Forkcast, a website for tracking Ethereum upgrades, to rank their preferences on Hegota EIPs.

If you haven’t seen Forkcast’s ranking tool already, here’s what it look like:

Forkcast Hegota Tier Maker

Essentially, developers can drag and drop the EIPs they would like to see in Hegota on the Forkcast rankings card by priority, “S” being the highest priority to “C” being the lowest priority and “DFI” being proposals that shouldn’t even be considered for inclusion, but rather “declined for inclusion” in the upgrade.

Already, several Ethereum community members have ranked their preferences and shared screenshots of their rankings on X and other forums. EthLabs shared theirs last week, along with a blog post explaining their rationale for the selection.

While everyone is welcome and encouraged to share their Hegota rankings, including non-protocol developers in the community, the decision-making for which EIPs make into the upgrade will be based primarily on the rankings of the clients teams.

Jayanthi said on the call:

The way we would want to start is go with the obvious DFI and obvious CFI options, so if every client team agrees on an EIP or disagrees on an EIP, let's get that out of the way first. And once that's done, I think we start the long tail of, actually going through rough consensus and coming up with what the EIPs were actually going to SFI in the end.

Now, Jayanthi isn’t saying that the opinions of non-client teams are pointless in the process. The views of teams like EthLabs and others in the community who do not directly build Ethereum client software do matter, but the final vote will rest with the seven consensus layer clients and five execution layer clients, six if you count Ethrex, whose job it is to actually code, test, and release the features included in Hegota.

No matter what stakeholders want, if the client teams don’t build it, there is no upgrade.

To this end, stakeholders in the community who have strong opinion about what should be included in Hegota should primarily voice their rankings to client teams in order for their views to be heard in the governance process. That, or build your own Ethereum client and earn your seat at the table to directly influence protocol development.

Bottom line

The rough consensus formed by client teams is the driving force that shapes the scope of Ethereum upgrades, which is why a diversity of client teams is a particularly important line of defense against protocol capture.

Convincing one or two clients teams about your views on the Hegota rankings or building your own client and having a direct vote on the ACD calls does not translate to an immediate victory, i.e., control over Ethereum.

There are more than a dozen different teams building Ethereum. The rough consensus formed between all of these teams is what drives Ethereum development forward, and nothing less.

Knowledge check 🗳️

Prior week’s answer: 200 million.

What's best for Bitcoin

Christine D. Kim — Tue, 18 Aug 2026 11:03:09 GMT

Good morning,

It’s turning out to be the summer for protocol issuance debates. Just as the Ethereum community is getting over the throes of another heated debate on reducing issuance, the Bitcoin community is belatedly responding to the remarks shared by a prominent Bitcoin developer, Peter Todd, who earlier this summer raised the idea of extending Bitcoin’s issuance schedule.

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

The side 🍳

The main 🥞

In July, bitcoin++, a Bitcoin developers-focused conference series, organized an event in Toronto, Canada, themed on “consensus.” It was a three-day conference where speakers and attendees were invited to delve into topics related to how consensus is, or is not, formed on Bitcoin.

There were talks on soft-fork mechanisms, upgrade activation paths, covenant proposals, and more. One of the talks was given by Peter Todd, a prominent Bitcoin developer and an early contributor to Bitcoin Core in 2012.

Leaning into the theme of the conference, Todd gave his talk on the thorny subject of changing consensus on Bitcoin’s issuance policies. A ballsy move, as I’m sure my Ethereum readers can understand right now.

His talk didn’t immediately stir the community's ire, mainly because the only people who had heard it were the hundred or so in the audience.

But this past Friday, August 14, conference organizers published Todd’s talk online, and now, several weeks after the conference, the community is getting a chance to respond, and no surprise to anyone, but especially my readers who are also watching the issuance debates unfold in Ethereum, the responses have been mostly hysterical and sensationalist.

Tail emissions and demurrage

Before getting into the online response, I want to provide some context on what was actually discussed at the Bitcoin++ conference in Toronto regarding changes to Bitcoin’s issuance policy.

In his 30-minute presentation, which includes a constructive question-and-answer period, Todd explains that, for miners to be incentivized in the long term to produce blocks, the financial incentive cannot depend solely on volatile transaction fees. They must be compensated with either tail emissions, that is, a constant block reward after the block subsidy ends, or demurrage, an additional fee for spending idle or dormant coins, which could act as a type of inflation tax on all BTC holders.

Todd presented the latter, demurrage, as the more plausible option on Bitcoin because it can be implemented as a backward-compatible change, unlike the former, which would necessitate a backward-incompatible change to Bitcoin’s monetary policy and thus require a hard fork to activate.

Todd admitted he’s not entirely sure what demurrage fee would be appropriate and sufficient to incentivize mining in the long-run. But he said he is convinced that any additional source of income for miners is better for the protocol’s security than relying exclusively on transaction fees once the block subsidy runs out.

Based on the line of questioning he received from the audience immediately following the talk, people were skeptical of his views and challenged whether there weren’t other ways to compensate miners without touching issuance.

Bitcoin’s immune response

Since the presentation was posted online on Friday, many have characterized Todd’s remarks as an “attack” on Bitcoin and a serious affront to the values of scarcity and hard money the protocol stands for.

Here’s what Giacomo Zucco, the President of Plan B Network, Bitcoin’s “educational layer,” had to say on Todd’s talk:

@btcplusplus @peterktodd If this unthinkably obscene madness was ever to be enforced by any relevant economy, it would mean the market is so irrecoverably retarded I would have no choice to sell all and join Bdash (to be more precise: I would actually pivot to physical gold and survivalism, but I'll","username":"giacomozucco","name":"Giacomo Zucco (Bear Market Edition)","profile_image_url":"https://pbs.substack.com/profile_images/2089332896477700096/_wEPBMOs_normal.jpg","date":"2026-08-14T16:22:56.000Z","photos":[],"quoted_tweet":{},"reply_count":23,"retweet_count":6,"like_count":179,"impression_count":5928,"expanded_url":null,"video_url":null,"video_preview_media_key":null,"belowTheFold":true}" data-component-name="Twitter2ToDOM">

Zucco’s comment above has about three times as many likes as the original post sharing Todd’s video by Bitcoin++ organizers.

The top comments on YouTube are even more charged and riddled with profanities and obscene language against Todd.

Bitcoin reporters like the former editor-in-chief of CoinDesk, Pete Rizzo, posted sensationalist headlines about Todd’s talk, exaggerating the urgency and weight of the remarks that were shared.

#BITCOIN SHOULD ELIMINATE THE 21,000,000 SUPPLY LIMIT \n\n\"IF BTC HAD TAIL EMISSIONS TO BEGIN WITH, NO ONE WOULD CARE\"\n\n\"ECONOMICALLY, IT'S SIMILAR TO GOLD\"\n\n\"WE HAVE THIS TYPE OF SYSTEM THAT SEEMS TO WORK, BUT WE KEEP MARCHING TO A KIND ","username":"pete_rizzo_","name":"The Bitcoin Historian","profile_image_url":"https://pbs.substack.com/profile_images/2011439030156836864/-z_VFH_H_normal.jpg","date":"2026-08-16T18:24:23.000Z","photos":[{"img_url":"https://substackcdn.com/image/fetch/$s_!m-PG!,w_1028,c_limit,f_auto,q_auto:best,fl_progressive:steep/l_play_button_usfui2,w_88,e_colorize:0/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F__ss-rehost__tw-video-preview-13_2088942900843569152.jpg","link_url":"https://t.co/l6HJFnVkjT"}],"quoted_tweet":{},"reply_count":549,"retweet_count":74,"like_count":336,"impression_count":232126,"expanded_url":null,"video_url":"https://video.twimg.com/amplify_video/2088942900843569152/vid/avc1/854x480/tXvYfCtKBWxWR_mm.mp4","video_preview_media_key":"13_2088942900843569152","belowTheFold":true}" data-component-name="Twitter2ToDOM">

To be clear, Todd did not “just” say Bitcoin developers should eliminate the protocol’s hard supply cap. He said it several weeks ago as part of a broader conversation on all of the controversial aspects of changing the broad consensus in Bitcoin.

Further, Todd is no longer an active contributor to Bitcoin Core, and his ideas do not reflect what Core developers think about Bitcoin's long-term issuance policies. As highlighted by the questions Todd received during his talk by developers at the Bitcoin++ conference, as well as from some who asked questions afterward online, the sentiment among the broader developer community remains divided on changes to issuance.

Bottom line

It’s clear from both the in-person and online responses to Todd’s presentation that tail emissions are not the answer to Bitcoin’s long-term security budget problem, nor is a demurrage tax on dormant coins.

Both proposals give up properties about Bitcoin that many protocol stakeholders treat as non-negotiable, and, more importantly, neither has anything close to the consensus it would need to successfully activate on Bitcoin.

However, the responses that treat Todd as out of line for even broaching the subject of changing issuance are an ostrich, head-in-the-sand move. Bitcoin’s long-term security budget is a real concern. As Todd put it in his presentation:

The Bitcoin subsidy going down is a scary phase change. We have this system that seems to work, and we keep marching towards a type of system that we don’t know works. We don’t have examples of that type of system working.

The reality is Bitcoin’s block subsidy is going to zero. Transaction fees have not grown to replace it, and no proof-of-work chain has ever run on fees alone, so nobody knows exactly what happens next.

No amount of yelling online changes these facts. The sooner the community can face them without retreating into fear and engage in constructive dialogue about what potential solutions stakeholders could broadly support, the better.

Knowledge check 🗳️

Prior week’s answer: 5

What's best for Ethereum

Christine D. Kim — Fri, 14 Aug 2026 03:16:29 GMT

Good evening,

Tonight, I’m sharing updates on Glamsterdam and Hegota, the two next immediate Ethereum upgrades coming up later this year and sometime in 2027, respectively.

On Glamsterdam, developers have converged on a final block gas limit increase target of 200 million gas. They have also launched a short-lived public testnet for the upgrade called Plataberget. Below, I discuss the significance of these updates and recent developments in the planning for the Hegota upgrade.

A note to subscribers: As most of you already know, I’m back from my two-week vacation. I had a lovely time up in Alaska, journeying through many beautiful parks and sites. I was also lucky to see one of the state’s most famous humpback whales, Flame!

Now, enough whale watching, let’s get into what I’m watching in Ethereum.

Yours truly,

Christine D. Kim

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

First, a couple of important updates on Glamsterdam.

Developers are still on track to start upgrading public test networks in September.

In my prior ACD After Hours post, I shared that developers were planning to launch one final developer-focused test network (also called devnet), followed by a short-lived public testnet and a non-finality testnet before upgrading public testnets.

They officially launched their final devnet, Glamsterdam Devnet-8, today, August 13. And rather than launch another dedicated public testnet shortly after this devnet, developers have designed Devnet-8 so that anyone can join the network.

Given the major changes to the block-building process featured in Glamsterdam, third-party block builders, in particular, are encouraged to start testing their infrastructure now against the new protocol specifications.

Instructions on how to join Devnet-8 are featured on Forkcast.

Developers confirmed a block gas limit increase of 200 million gas shortly following Glamsterdam activation on mainnet.

Back in May, developers aimed to more than triple Ethereum’s block size through Glamsterdam.

This week, they confirmed the final numbers for Glamsterdam’s gas repricing proposals, which seek to better optimize network resource usage. Based on these numbers, developers could also confirm that they can indeed safely increase network throughput after the Glamsterdam upgrade from 60 million to 200 million gas without posing a risk to the setups of existing node operators.

In anticipation of this increase, Ethereum Foundation’s Barnabas Busa recommended the inclusion of an optional EIP, EIP 8261, in Glamsterdam that would enable clients to set an automated gas limit schedule and incrementally raise the block gas limit following Glamsterdam activation on Ethereum mainnet.

Developers confirmed tighter history expiry limits will become the default in client software.

Alongside plans to increase the block gas limit, developers agreed to implement stricter default history expiry settings in client software.

The default in most clients today is to store historical block data up to the Merge upgrade, which happened back in September 2022.

However, now that the rate of history growth is expected to more than triple due to the upcoming block gas limit increase, node operators will need to prune larger volumes of history to continue operating on their existing hardware without issues.

On the latest developer call, ACDE #243, developers discussed setting the rolling history expiry default to five or six months.

Hegota PFI’d EIPs list now final

Regarding Hegota, the deadline for EIP submissions has passed, and developers can now begin the arduous task of determining which of these submissions to prioritize for implementation after Glamsterdam.

As a reminder, there is one EIP that developers have already agreed to include in Hegota and have started work on: EIP-7805, fork-choice-enforced inclusion lists. For a refresher on this EIP, refer to this post.

There are currently 37 EIPs proposed for inclusion in the Hegota meta EIP. 17 additional ones were newly proposed on the latest ACD call. So, in total, developers are working through a list of roughly 50 proposals and trying to create a shortlist to prioritize in Hegota.

Nixo Rokish, who chaired ACDE #243, said that execution layer (EL) client teams should come prepared to present and debate their ideal shortlist for Hegota by the ACDE call on September 10. It is likely that consensus layer (CL) client teams will work towards a similar deadline.

While client teams' preferences are the most influential in the upgrade scope decision-making process and therefore the most important to watch in the coming weeks, they are not the only factor.

What’s best for Ethereum

Two EIPs proposed for Hegota have sparked intense controversy in the Ethereum community.

First is EIP-8363, tapered issuance burn, which would introduce a dynamic burn of Ethereum’s issuance rewards. For a refresher on the arguments for and against lowering issuance, refer to this prior post.

Then there is EIP-8141, frame transactions, which introduces a new transaction type that allows user-controlled Ethereum accounts to verify transactions and pay fees using arbitrary logic defined in smart contract code. It’s designed to make Ethereum more user-friendly today and more adaptable to post-quantum (PQ) cryptography in the future.

In general, both are more supported amongst protocol-focused researchers, developers, and client teams than amongst application developers and users.

On ACDE #243, nearly all client teams expressed their support for EIP-8141. However, vocal opposition from representatives of Base and Offchain Labs, two prominent Layer-2 protocol teams, made it difficult for developers to affirm it in its current form in Hegota.

Instead, they agreed to a breakout call to work out their differences in opinion and possibly adjust the EIP to make it more palatable to Layer-2 teams.

In both conversations about EIP-8363 and EIP-8141, there is a conflict between what many protocol researchers and client teams believe is best for the Ethereum protocol and what application developers believe is best for it.

Speaking in favor of EIP-8141, Geth client developer “Lightclient” said on ACDE #243:

At the end of the day, like, we need to do what is best on L1, and I want it to be something that is supported across L2s, and I want to do what we need in frame so that people are happy, but at the end of the day, everyone’s gonna be a bit unhappy. You know, that’s just the way that controversial EIPs end up, and so we need to be ready for that.

However, from the perspective of Layer-2 developers like “Chris” from the Base team, who proposed EIP-8130 as an alternative to EIP-8141, their views on frame transactions genuinely reflect what they believe is in Ethereum's best interest.

Chris responded to Lightclient saying:

I genuinely believe [EIP] 8130 can satisfy the same long-term goals [of Ethereum] in a way that is ultimately more performant and doesn’t make compromises that are hard to come back from.

Bottom line

Ethereum is not purely a technical project. If it were, the developers closest to the protocol would have the final, most informed say on what is best for it, and today’s client tally would have settled the question of EIP-8141’s inclusion in Hegota outright.

But Ethereum is a community at its core. Protocol rules are determined first and foremost by social consensus. The views of one stakeholder group do not unilaterally define what is good or best for the protocol. Only the collective can.

Thus, setting technical arguments aside for a moment, the existence of intense disagreement over a proposal may itself be strong grounds to reject it for inclusion in an upgrade.

Knowledge check 🗳️

Luke Dashjr, Bitcoin's longest-serving BIP editor, is out

Christine D. Kim — Tue, 11 Aug 2026 11:00:58 GMT

Good morning,

Today, I’m discussing the removal of Bitcoin’s longest-serving BIP editor, Luke Dashjr, after ten years of service. It’s an unprecedented event for the Bitcoin developer community. I explain who and what prompted this action in the main story below.

Regarding Bitcoin Core development, the main update is that, as anticipated, the BIP-110 soft fork did not impact Core users or the Bitcoin protocol. More on what Core developers are focusing on for their next major release, v32, and what users can expect from the upcoming release further below in today’s newsletter.

As a note to subscribers, I had a lovely time vacationing up in Alaska over the past two weeks. Thank you for your patience while I was away. I’m back now, so you can expect my updates on Bitcoin and Ethereum development in your inboxes on their regular cadence starting this week.

While I don’t have any souvenirs to send you from my trip, here’s a photo I took of the beautiful Bryn Mawr Glacier.

As you can tell, I didn’t have much opportunity on my vacation to touch grass, but I did touch ice- glacier ice- and it was very cool. ;)

Now, let’s get into our main story for today.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

The side 🍳

The main 🥞

On Monday, August 10, Bitcoin’s longest-serving Bitcoin Improvement Proposal (BIP) editor, Luke Dashjr, was forcefully removed from his role after 10 years of service.

The motion

The removal was initiated a day after Mark “Murch” Erhardt, cofounder of Localhost Research and long-time Bitcoin Core contributor, emailed the Bitcoin Development Mailing List with a motion to formally remove Dashjr from the position of BIP editor.

Excluding Dashjr, there are now five individuals who have merge access to the BIP GitHub repository, the main repository for tracking proposals to change Bitcoin Core code. Murch is one of them. He was added in 2024, along with four others, to help clear a backlog of BIP editing work that had grown to more than 130 open pull requests (PRs).

When proposing the expansion of BIP editors, Ava Chow, a Bitcoin Core maintainer who works at Blockstream, described what the new editors would do in the following way:

These people would have the same permissions and responsibilities that Luke has, i.e. can assign BIP numbers, merge PRs adding new BIPs, merge PRs to fix existing BIPs, and all other responsibilities as described in BIP 2.

The 2024 expansion of the BIPs editor group to six total editors markedly improved BIP activity, which I covered in more detail in BTC Before Light Issue #00.

Up until his removal, Dashjr was the longstanding editor in the group. He has been editing BIPs since 2016, and he maintained the BIPs repository alone for a long stretch between 2016 and 2021.

The recent motion, which was approved on Monday, to remove him was prompted by his involvement in the failed BIP-110 soft fork that stalled last week with only 2.53% miner support.

Murch also cited a lack of work and communication as grounds for removal. He wrote that since the additional editors began serving in April 2024, Dashjr has left fewer than 1% of the editor comments in the repository.

On communication, Murch wrote:

Communication between Luke and other BIP Editors had already broken down last year, following a discussion about his attempt to side-step the process by prematurely assigning a BIP number out of band.

The response

The motion to remove Dashjr from his role as BIP editor generated wide support from the Bitcoin developer community, which is why it was approved promptly after it was created.

Unsurprisingly, Dashjr responded to the motion himself, refuting it and claiming accusations of his negligent behavior are false:

These are false accusations. I have followed the BIP process consistently for years. Your novice opinions alone do not establish new processes. You are the one who stopped communicating, not I. You are the one who should be removed.

Others in the community were quick to voice their support for Murch's motion. The individuals who publicly supported the motion were: Olaoluwa Osuntokun, chief technology officer (CTO) of Lightning Labs and a fellow BIP editor; Matt Corallo, a Bitcoin Core contributor at Spiral; Jameson Lopp, co-founder and chief security officer of Casa; Jonas Nick, a Bitcoin researcher at Blockstream; Antoine Poinsot, a Bitcoin Core contributor at Chaincode Labs; among others.

Poinsot responded in the email thread saying that the removal of Dashjr as BIP editor was “long overdue.”

The concern

One concern raised about Murch’s motion was that there is no formal governance process for removing someone against their will. Lopp, who supported the motion, wrote:

This is unprecedented because there is, to my knowledge, no formal governance structure or policy around management of BIP Editors.

Antoine Riard, an independent Bitcoin developer who has on multiple occasions been temporarily removed from both the Bitcoin and Lightning GitHub organizations for repeated harassment against other contributors, said that while it would be ideal for Dashjr to remove himself from the BIP editors list, in lieu of voluntary action, the developer community should make other provisions to ensure that the forceful removal of Dashjr happens on “bright lines,” i.e., clear guidelines.

Riard recommended formalities such as requiring every current BIP editor to publicly state their position on this motion with reasoning, and giving Dashjr at least two weeks to defend his position.

Riard also proposed amending the BIP editorial process document, BIP-3, to explicitly ban behavior exhibited by Dashjr in recent months. Riard wrote:

I would strongly suggest to amend the BIP-3 document to underscore that editors have an explicit duty of neutrality, and that under this duty they should not engage in the promotion of contentious fork, even under one of their other hats.

The fallout

Despite Lopp and Riard’s concerns about the novelty of forcibly removing a BIP editor from their role, Dashjr's privileges as BIP editor were officially revoked as of yesterday, August 10.

Following the removal, a motion to close BIP-110 and signal the proposal’s failure to garner sufficient support from the Bitcoin community for activation was approved by the other BIP editors shortly thereafter.

Then, also on the same day, August 10, Dashjr announced that he is taking a sabbatical from his position as Chairman and CTO of OCEAN, a Bitcoin mining pool, to focus on “open-source projects to support Bitcoin.” It is unclear what exactly Dashjr plans to focus on as it relates to Bitcoin, but some sources say that he is planning a hard fork of the protocol:

Bottom line

In the grand scheme of Bitcoin development, the removal of an inactive BIP editor is pretty minor, as is the approval to close out a BIP that has already failed to gain meaningful support from Bitcoin stakeholders.

Both pull requests, PR 2248, which removes Dashjr from BIP-3's list of editors, and PR 2245, which updates BIP-110’s status from Complete to Closed, are formalities that simply reaffirm what has already been evident from the events of the past few months.

They underscore the fact that Luke Dashjr is no longer a contributor to Bitcoin development that others take seriously or trust to offer meaningful contributions, nor is BIP-110 a proposal that the Bitcoin community supports in any meaningful capacity.

Most in the community already knew this, but in an open-source project like Bitcoin, a merged pull request is about as far as developers can go in making something official.

Knowledge check 🗳️

Post-Quantum EIPs for Hegota

Christine D. Kim — Sat, 25 Jul 2026 00:01:46 GMT

Good evening,

Tonight, I’m discussing Ethereum’s post-quantum readiness. Yesterday, developers discussed a proposal to update how randomness is generated so that a cryptographically relevant quantum computer (CRQC) could not predict or manipulate the process.

Regarding the Glamsterdam development, the launch of Devnet-7 revealed several issues and bugs in clients, indicating a high risk of delays to the upgrade timeline I shared last week. Before diving into the main topic of today’s newsletter, I’ll share a quick update on Glamsterdam progress.

A note to subscribers: I’ll be taking a short break from newsletter writing starting next week. I’ll be back August 13 with a fresh new update on all things Ethereum development and governance.

Let’s get into it.

Yours truly,

Christine D. Kim

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

Yesterday, July 23, Ethereum developers gathered for their weekly coordination call, the All Core Developers (ACD) call, and discussed progress on the Glamsterdam and Hegota upgrades.

On Glamsterdam

Developers launched their penultimate developer-focused test network (devnet) last Tuesday, July 14. So far, testing has revealed several issues and bugs in clients that developers are working to fix.

The lack of a stable devnet may cause developers to delay next steps for moving on with testing on Ethereum public testnets.

For now, they have agreed to proceed with the launch of the final Glamsterdam devnet, Devnet-8, sometime in the first week of August. Then, they plan to launch two more testnets: a short-lived public testnet for application developers and a non-finality testnet to see how the protocol behaves under extreme conditions, before moving to upgrade public testnets.

Ethereum Foundation (EF) Developer Operations Engineer Parithosh Jayanthi said the rough target is to start upgrading public testnets by September. He said:

Timeline-wise, we’re still looking at DevNet 8 early August. We would want at least one public-ish DevNet, and a non-finality DevNet, both ideally in August, and that should still allow us to potentially have the first [public testnet upgrade] in September.

On Hegota

On the same call, developers also discussed planning for the upgrade after Glamsterdam called Hegota.

Currently, Hegota is in a planning stage, where developers are proposing different Ethereum Improvement Proposals (EIPs) for consideration in the upgrade. The deadline for Hegota EIP submissions is August 6, after which developers will begin finalizing upgrade scope.

So far, developers have confirmed only one EIP for inclusion in Hegota: EIP-7805, Fork-choice-enforced Inclusion Lists (FOCIL).

On the latest ACD call, they discussed a few other EIPs for Hegota, one of which aimed to improve Ethereum’s post-quantum readiness.

Hash-Chain RANDAO

Co-authored by four Ethereum Foundation researchers, Kevaundray Wedderburn, Benedikt Wagner, Tom Wambsgans, and Justin Drake, EIP-8321 seeks to update the part of the Ethereum protocol that generates randomness.

Randomness is used for many functions on Ethereum, but key among these is to randomly select which validators get to propose future blocks and group other validators into committees for other responsibilities such as block attestations.

The way Ethereum generates randomness in a secure and decentralized manner is through a commit-reveal scheme known as Random Decentralized Autonomous Organization (RANDAO). It currently relies on Boneh–Lynn–Shacham (BLS) digital signatures to work. However, this cryptography, such as the elliptic curve digital signature algorithm (ECDSA) used by Ethereum to secure accounts, is considered vulnerable to quantum attacks.

Thus, EIP-8321 proposes a hash-based RANDAO scheme that would remove the need to use BLS signatures to source randomness on-chain. Hash functions like SHA-256 are believed to be secure against quantum computers, so, in short, this proposal swaps out the quantum-vulnerable part of Ethereum’s randomness system for a quantum-resistant one.

Concerns about EIP-8321

In addition to concerns about the overhead that a hash-based RANDAO system would add to validator operations, developers raised concerns about the proposal's maturity.

The proposal does not completely remove validators’ reliance on BLS cryptography. It only addresses its use for RANDAO, and leaves the other ways BLS keys and signatures are still used by validators for their daily operations untouched.

“Potuz,” a Prysm client developer at Offchain Labs, said:

This particular change, changing RANDAO, seems random. … If anyways, we’re gonna keep BLS on the validator keys, the shuffling is still going to be vulnerable. So it doesn’t matter what we do with RANDAO, the validator still can be cracked. So, it seems to me that we’re going to fix RANDAO making it post-quantum resistant, but anyways, the only usage of it is not going to be, safe, so it seems a bit premature.

In response, Wedderburn, one of the authors of the proposal, acknowledged that the EIP does not address all the ways validator operations become unsafe due to their reliance on BLS in the event of a quantum attack; it addresses only one. However, if developers agree that post-quantum readiness should be done iteratively, then the EIP should still be considered as one iterative piece of the broader plan that can be completed in the Hegota upgrade. He said:

I think this is the open question as to whether we should do iterative changes to [post quantum], or if we should try to do it all at once. Yeah, this is a question that it’d be good to get more feedback on it to see how people are thinking about this.

Due to the complexity of Ethereum’s codebase, an iterative strategy is likely the only way that Ethereum can safely prepare for “Q-Day,” the day that cryptographically relevant quantum computers (CRQCs) become a reality, as there are several components of the protocol that currently rely on cryptography that CRQCs could theoretically break.

Knowing this, Matthew Keil, a Lodestar client developer at ChainSafe Systems, recommended alignment first on the broader post-quantum roadmap, which could then inform how developers can best start chipping away at the iterative process of making Ethereum Q-Day ready.

Keil said:

It might make sense to memorialize the strawmap, or whatever the post-quantum vision is from a broader perspective, and that way it can [help] how we kind of finalize and narrow down the iterative components for each iteration. … Do we want to start thinking more broadly about what PQ looks like as a broad perspective, as an ecosystem? And then, using that as an approved, quote-unquote, roadmap, that we can all kind of march to.

Developers agreed to continue discussing EIP-8321 and the broader post-quantum roadmap on Discord.

Bottom line

The discussion on EIP-8321 highlighted a major gap in Ethereum’s post-quantum readiness, and that is the existence of a shared development roadmap to guide decision-making about which code changes should come first.

While developers may have immediate, technically sound measures to prepare for Q-Day, such as EIP-8321, they currently lack consensus on the overarching roadmap to guide decision-making on the relative sequencing and urgency of post-quantum-related EIPs.

Further, while developers may share a high-level development roadmap of Ethereum, the strawmap, it lacks specificity, detail, and sufficient consensus to offer developers the clarity they need to make decisions on the incremental steps needed to prepare for Q-Day.

Thus, until developers align on the broader Q-Day roadmap, they are likely to have difficulty placing and prioritizing narrowly scoped post-quantum changes, such as EIP-8321, in forthcoming upgrades.

Knowledge check 🗳️

The case for a Bitcoin LLM

Christine D. Kim — Wed, 22 Jul 2026 11:05:26 GMT

Good morning,

Today, I’m returning to a topic I briefly flagged last month about an effort to build an artificial intelligence (AI) model that reasons about the Bitcoin protocol. Below, I discuss the idea in more detail, its motivations, and how the community discourse is shaping around it.

Regarding Bitcoin Core development, this discussion is happening primarily on Delving Bitcoin, outside of discussions about Core development, as nothing proposed would require changes to Bitcoin or its reference implementation. For updates on Core, refer to the linked posts at the bottom of today’s newsletter.

As a note to subscribers, I’m going on a two-week holiday starting next week, July 27, so this newsletter will go on a short break. I’ll be back August 11 with a fresh new update on all things Bitcoin development and governance.

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

The side 🍳

The main 🥞

Last month, Thomas Suau, an artificial intelligence (AI) solutions architect based in France, posted on Delving Bitcoin about the creation of a language model (LLM) that can “genuinely think in Bitcoin.”

His initial observation was that information about Bitcoin, its development and usage, is rich and publicly available. Yet no AI model has been built to reason specifically about the protocol. The closest attempt, a model called Satoshi-7B released in 2024, was trained on Bitcoin culture and Austrian economics rather than protocol mechanics.

Seven weeks and eighteen replies later, Suau’s post has become something more concrete than a project pitch. Developers have substantially expanded Suau’s list of source material, offered new design constraints and considerations, and ideated benchmarks to test the reliability of a Bitcoin-native LLM in execution.

The motivation

As Suau explains in his initial post, a Bitcoin LLM could serve various purposes and stakeholders within the Bitcoin ecosystem.

Script reasoning: Every bitcoin is locked by a small program specifying the conditions under which it can be spent. Given one of these programs in raw form, the model should identify the type of construction, explain who can spend it and under what conditions, and flag anything unusual or risky.
Script recommendation: When a user describes a custody arrangement for their bitcoin in plain language, for example, “a two-of-three multi-signature key setup, with a recovery path that opens after six months,” the model should be able to build a correct construction for this arrangement and accurately explain its tradeoffs against other constructions.
UTXO graph traversal: Bitcoin has no account balances like Ethereum; instead, it uses discrete coins traceable to the transactions that created them. The model should be able to audit the creation and movement of each coin and provide high-level insights into usage patterns for informing chain tooling and services, not surveillance.
Protocol Q&A: Finally, the model should be able to answer questions about consensus rules and transaction formats, citing documentation such as Bitcoin Improvement Proposals (BIPs) that define them, as well as historical discourse that has shaped rough consensus on them.

In summary, the primary motivation for building a Bitcoin LLM is two-fold. First, it could serve as a tool to help users understand how to transact safely and self-custody their coins on Bitcoin. Secondly, it could serve as a resource for protocol developers to gain deeper insights into how Bitcoin is used and to clarify prior design choices, helping guide future decisions.

Source material

Now, the first design consideration in building an LLM for any of these purposes is the source material on which the LLM would be trained.

In his original post, Suau referenced BIPs, the Bitcoin Developer mailing list, the Delving Bitcoin forum archives, Bitcoin Core source code and functional tests, and on-chain transaction data as initial source material.

One user “sudocarlos” added the Bitcoin Stack Exchange and Bitcoin Optech as additional reference material.

“L0rinc,” who is also an active contributor to the Bitcoin Core codebase, added pull request review discussions, core developer transcripts, and technical books, such as Learn Me a Bitcoin.

Another user, “AdamISZ,” mentioned the Bitcoin Internet Relay Chat (IRC) logs, some of which have been archived as early as 2010.

Considering the extensive source materials for a Bitcoin LLM, a key design constraint highlighted by contributors such as l0rinc and later acknowledged by Suau was that the model should be trained not to seek answers directly, but rather to present arguments along with their sources.

L0rinc wrote:

There often is not a central “truth” here, but different experts arguing for different tradeoffs. … ideally a Bitcoin-native LLM would not just try to produce the answer, but preserve which expert argued what, in what context, and what assumptions or compromises each side is making.

Fine-tuning vs. special tooling

Another key design consideration that developers discussed in the thread was the methodology for building the model’s specialized knowledge on Bitcoin.

Suau’s initial proposal was to take an existing open-source model and further train it on Bitcoin-related material. This approach in training specialized LLMs is called “fine-tuning.”

Several developers who chimed in on Suau’s post argued against this methodology, instead advocating for techniques that do not require special training but rather special tooling that any open-source model can use to produce informed answers about the Bitcoin protocol.

One of these techniques is called Retrieval-Augmented Generation (RAG), which has the model search a curated library of outside sources and answer from what it finds, rather than from its own training. For example, in the context of a Bitcoin LLM, the model would first search a curated collection of Bitcoin documents, pull the relevant pages, and then generate a response.

About the advantages of RAG, David Gumberg, another active contributor to Bitcoin Core, wrote:

I expect that the corpus of Bitcoin related text is relatively small compared to the corpuses that frontier models are trained on … domain specific finetuning is rarely worth the time and effort compared to building something general like RAG that you can just plug the latest frontier model into.

Another advantage of this approach is that new documents can be iteratively added to the library, and the model can always pinpoint which documents it pulled from to generate its answers.

Breno Brito is a machine learning engineer who worked on the first Bitcoin-trained LLM, Satoshi-7B, in 2023. Brito explained that while Satoshi-7B was fine-tuned, the main reason was due to the poor ability of all LLMs at the time to follow instructions.

Brito explained:

The main reason we were building Satoshi-7B and other fine tuned models was because the models were really bad at instruction following. That’s not the case anymore. Most of what you said above should be done via skills (with scripts doing the deterministic parts inside a skill folder).

In other words, Brito suggests that models have improved significantly over the last few years at following instructions, such that specialized knowledge mostly no longer needs to be fine-tuned or trained into a model. Instead, Brito explained, this knowledge can be packaged as “skills,” bundles of written instructions paired with scripts that an AI agent can load to perform specific tasks.

Brito is currently building an open-source library of these called Freedom Skills, covering Bitcoin, Nostr, related privacy tools, and other freedom technologies.

Benchmarking

In addition to the source material and methodology for training a Bitcoin LLM, developers have also discussed the appropriate benchmarks for evaluating different models.

Alex Waltz, a Bitcoin researcher and filmmaker, suggested a standardized knowledge test on Bitcoin protocol trivia that could assess which models are more accurate than others.

Waltz recommended questions like:

1. Give all the examples where consensus rules were grandfathered in.
2. Was SegWit a block increase?
3. Were the following events hard or soft forks and why? Bitcoin releases 0.3.5 ; 0.8.0 ; 0.15.0 ; BIP30, SegWit?

Suau proposed something more formal, such as a public evaluation set of 200 tasks with programmatically verifiable answers. The tasks, such as script parsing and descriptor compilation, would be split equally to test the model's abilities against the four main objectives.

Suau wrote:

Anyone can then test their preferred approach: frontier model plus search index, frontier model plus node tools, fine-tuned 7B, or any combination. … Happy to draft the benchmark structure if there is interest.

Bottom line

Much like the Bitcoin protocol itself, the development of a Bitcoin LLM is benefiting from community input and involvement.

From crowdsourced input on the right source material to the firsthand experience of other developers working on similar ideas to public benchmarks for the best model, Suau’s post about Bitcoin LLMs has sparked significant interest and discussion within the Bitcoin developer community.

While developers are coalescing on a comprehensive suite of source material for a potential Bitcoin LLM, as well as a methodology for training it on this specialized knowledge, there are still several open questions about such a model, such as the model size, reasoning about rough consensus, and design tradeoffs related to the model’s performance vs accessibility for users.

Thus, while the design for a Bitcoin LLM is by no means settled, the consensus that has already formed around the rough blueprint and motivation for such a tool appears promising.

Knowledge check 🗳️

Glamsterdam Nears Final Devnet Launch

Christine D. Kim — Fri, 17 Jul 2026 00:00:49 GMT

Good evening,

Tonight, I’m discussing updates on the readiness of the Glamsterdam upgrade from the two most recent All Core Developers (ACD) calls, ACDE #241 and ACDT #87.

At a high level, developers have confirmed that their next devnet, Glamsterdam-Devnet-8, will likely be the last before public testnet upgrades. While it’s still too early to say with confidence when Glamsterdam will be ready for mainnet, Ethereum stakeholders, especially application developers, are encouraged to start preparing for the upgrade now.

Let’s get into it.

Yours truly,

Christine D. Kim

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

On today’s All Core Developers (ACD) call, developers confirmed that the next devnet launch, Glamsterdam-Devnet-8, will likely be the last of its kind before developers move on to upgrading public Ethereum testnets.

Public testnet upgrades are the final milestones in development before an upgrade is considered ready for activation on Ethereum mainnet. There are two public testnets, Sepolia and Hoodi, which developers have said they ideally want to schedule at least two weeks apart to allow sufficient time for testing on these networks.

Given the chaotic state of the most recent Glamsterdam-Devnet-7 launch, developers will likely spend the rest of this month ironing out kinks in client software and conducting one more practice run on Devnet-8 before scheduling the first public testnet upgrade potentially sometime in August.

Glamsterdam timeline estimations

Once scheduled, the public testnets will take at least one month to upgrade, and thereafter, developers ideally want to schedule the mainnet upgrade at least 30 days after the final public testnet upgrade.

So, optimistically speaking, Glamsterdam could be ready for mainnet by late September or October. However, it is too early to say with confidence when Glamsterdam will be ready for mainnet activation, given ongoing client debugging and development work on last-minute additions to the upgrade, such as EIPs 7688 and 8282.

The forthcoming launch of Devnet-8 will be an important indicator of Glamsterdam's readiness for mainnet activation. A date for the final devnet launch has not yet been decided, but based on prior devnet launch timelines, it will likely occur sometime over the next two weeks.

A tentative timeline for Glamsterdam based on the Ethereum protocol process document and the current testing status of Glamsterdam-Devnet-7:

July 14, Glamsterdam-Devnet-7 launch (completed)
July 28, Glamsterdam-Devnet-8 launch (tentative)
August 11, Finalization of client testnet releases for public testnet launches (tentative)
August 25, Sepolia testnet upgrade (tentative)
September 8, Hoodi testnet upgrade (tentative)
October 8, Ethereum mainnet upgrade (tentative)

What the ecosystem needs to know

As developers continue to work on stable versions of Glamsterdam ready for public testnet deployments, the broader Ethereum ecosystem is encouraged to begin preparing for another network-wide upgrade.

First, application developers are encouraged to begin testing their code alongside Glamsterdam code changes on Devnet-7. As discussed on today’s ACD call, there will be no separate short-lived testnet, like Mekong, created specifically for application testing. Applications can test on Devnet-7 now and on Sepolia and Hoodi once these public testnets have been upgraded.

Second, protocol developers are testing a 300 million block gas limit on Devnet-7, which is higher than what was initially anticipated for Glamsterdam when developers did their benchmarking analysis back in May. If testing goes smoothly on Devnet-7 and Devnet-8, Glamsterdam may result in a 4x scalability boost to Ethereum.

The final numbers for the block gas limit are still subject to change, but if testing goes according to plan, Glamsterdam may end up unlocking the highest increase in block size the network has ever seen.

For an overview of all the finalized features in the Glamsterdam upgrade, refer to this Google spreadsheet.

Temp check 🗳️

What to expect when Bitcoin forks next month

Christine D. Kim — Tue, 14 Jul 2026 11:02:26 GMT

Good morning,

Today, I’m discussing two network-wide upgrades, also called “forks,” scheduled for activation on Bitcoin over the next two months. Below, I explain what Bitcoin users can expect from both the eCash hard fork and the BIP-110 soft fork, which are expected to activate in August and September, respectively.

Regarding Bitcoin Core development, neither of these forks is expected to affect Core or the broader Bitcoin network, as the changes introduced by these upgrades lack broad community support. For additional updates on Core, refer to the linked posts at the bottom of today’s newsletter.

As a reminder to subscribers, the visibility of my posts has changed. Free subscribers will now receive full posts in their inboxes a few days after publication, while paid subscribers will get early access to my insights.

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

The side 🍳

The main 🥞

Over the next two months, Bitcoin is expected to undergo two network-wide upgrades, also called “forks.”

Upgrades that restrict Bitcoin’s ruleset so that older versions of Bitcoin software can still validate new blocks are called “soft” forks, while upgrades that expand the protocol’s ruleset and introduce new functionalities that prior versions of Bitcoin software cannot support are called “hard” forks.

Between August and September, Bitcoin will undergo both a hard fork and a soft fork. However, due to the lack of broad consensus for the protocol changes introduced by either of these forks, it is unlikely that either will succeed in changing Bitcoin. Both network-wide upgrades will likely result in an extended chain split and two new competing versions of the Bitcoin protocol.

The Ohm soft fork

Earlier this year, a pseudonymous Bitcoin developer using the screen name “Dathan Ohm” published a fork of the Bitcoin Core client that would temporarily limit the size of data fields, such as OP_RETURN, to curb non-financial use cases on Bitcoin.

The client name is tagged on GitHub as UASF BIP-110, which stands for User-Activated Soft Fork Bitcoin Improvement Proposal-110.

BIP-110 is Ohm's proposal that defines the technical specifications for limiting Bitcoin’s data fields at the consensus level.

UASF describes the high-level process for activating BIP-110, with or without support from Bitcoin miners.

Up until block height 961,632, which is expected to be mined around August 7, miners can signal their readiness for BIP-110 activation by adjusting their Core node settings to adopt BIP-110 consensus rules or by running alternative client versions that already support BIP-110.

If 55% of miners collectively signal support for BIP-110 by early August, then the features of BIP-110 will automatically activate in the software of supporting miners about two weeks after this minimum threshold is reached.

If the 55% threshold is not reached by block height 961,632, then the miners that have signaled their support for BIP-110 will begin rejecting blocks from miners who have not signaled their support. Then, starting at block height 965,664, expected around September 1, miners supporting BIP-110 will begin enforcing the proposal’s new consensus rules.

As of writing, only 1% of Bitcoin miners have signaled support for Ohm’s soft fork.

Thus, the Bitcoin ecosystem is now preparing for roughly 1% of these miners to split off and form their own chain starting early next month.

What this means for Bitcoin users

As a chain with an estimated 1% of mining support, it’s unlikely that many exchanges or wallets will support this Bitcoin fork when it splits off next month. Thus, for most users, nothing will change. When the Ohm fork is created, BTC held in self-custodied Bitcoin Core wallets, as well as in most other cryptocurrency wallets and exchanges, will be unaffected.

However, for the minority of users who are self-custodying their BTC using customized software supporting the Ohm fork or are custodying their BTC on a platform that will support this fork, they will now see two versions of Bitcoin, one that rejects blocks over certain data limits and the other that continues to validate and build upon them.

The version of Bitcoin that rejects blocks according to BIP-110 consensus rules is unlikely to attract economic value or significance due to its lack of community support and tooling. However, for users who still wish to support this minority fork of Bitcoin and care about the BTC holdings they have replicated on it, there are a few important considerations to keep in mind as August approaches.

What this means for Ohm fork users

In addition to concerns about the security and network stability of the Ohm fork due to its lack of miner support, there is the concern that transactions users create on the Ohm fork may be replayed on Bitcoin, and vice versa.

While UASF BIP-110 will operate under more restrictive consensus rules for data storage than the Bitcoin protocol itself, it will uphold the same ruleset for transaction validity. Thus, transactions validated on the Ohm fork can be replayed and validated on Bitcoin, provided they do not violate the consensus rules for data storage on either chain.

This means Ohm-fork users should be careful when constructing transactions, so that transactions intended for only one chain can't be replayed on the other. This can be done by deliberately including a feature that the other chain's rules reject, such as an oversized OP_RETURN, or by referencing a block hash that exists only on one chain after the split — either way, making the transaction inherently invalid on the chain it wasn't meant for.

The eCash hard fork

Alongside the Ohm soft fork in August, there will also be a hard fork of Bitcoin called the eCash hard fork.

Unlike UASF BIP-110, the eCash fork is not intended to restrict Bitcoin’s ruleset but rather to expand it to support new functionality, specifically drivechains.

Drivechains are a type of layered scaling solution for Bitcoin defined by Bitcoin Improvement Proposals (BIPs) 300 and 301 that seeks to enhance the protocol’s programmability and scalability. It was designed by Paul Sztorc, the creator of the first blockchain-based prediction market, Truthcoin, and the founder and CEO of Layer Two Labs.

After developing the idea of drivechains for over a decade, Sztorc has started a new project, eCash, which will spawn a new version of Bitcoin that activates BIPs 300 and 301, as well as the following code changes:

Blocksize Reduction - Reduce blocksize by 10x – ie, from 4 MB to 400 KB.
Difficulty Reset – A one-time “special difficulty adjustment” down to the minimum difficulty on the fork date.
Satoshi Half-Airdrop – Half of Satoshi’s “patoshi” coins (about 550k of 1.1 M) will be allocated to eCash investors and supporters.
Transaction Replay Control – ECash transactions will have an optional extra byte such that transaction IDs can be distinct from Bitcoin transactions, and thus, allow users to opt in/out of transaction replay
Network differentiation – Superficial changes to differentiate the eCash network from Bitcoin, e.g., the name, seed node IPs.

eCash is designed to be a hard fork of Bitcoin that will activate the above changes starting from block height 963,648, expected around August 21. (Technically, only the last four features of eCash listed above are backward-incompatible, that is, requiring a hard fork of Bitcoin. BIP 300, 301, and a blocksize reduction can be activated through a soft fork of Bitcoin.)

Unlike UASF BIP-110, the protocol will launch with its own separate ticker, ECX, and developer tooling from Bitcoin. (As a side note, there is another blockchain protocol with the same name as this project that is already listed on certain exchanges. Its ticker is XEC, and it is unrelated to Sztorc’s eCash project.)

What to expect

The impact of the eCash hard fork on Bitcoin users is expected to be similar to that of the UASF BIP-110 soft fork, given the project’s limited support amongst Bitcoin developers, exchanges, and wallets.

Thus, for most users, nothing will change. When the eCash fork is created, BTC held in self-custodied Bitcoin Core wallets, as well as in most other cryptocurrency wallets and exchanges, will be unaffected.

However, for the minority of users interested in supporting eCash and concerned about the value of their replicated BTC holdings on this forked chain, there are fewer considerations to note than for Ohm fork supporters.

As a fork that will be differentiated from Bitcoin from the start, eCash has built-in replay protection for its users. Further, there are network adjustments to account for the drop in mining participation that will occur at the time of the fork, which are intended to help stabilize the network from its genesis.

Bottom line

In summary, the key dates and block heights for the Ohm soft fork and the eCash hard fork are:

Block height 961,632 (~August 7): Mandatory UASF BIP-110 miner signaling period kicks off, and signaling miners begin rejecting blocks from non-signaling miners
Block height 963,648 (~August 21): eCash hard fork activation
Block height 963,648 (~September 1): BIP-110 soft fork activation

Both forks lack broad support from key Bitcoin stakeholders, such as major exchanges, miners, developers, and end users, which is why the changes they introduce to Bitcoin are unlikely to meaningfully impact the Bitcoin protocol.

Instead, it is anticipated that both forks will result in competing variants of Bitcoin, which only a minority of users who support the modifications in these versions will observe.

Knowledge check 🗳️

Rebranding Lean Ethereum

Christine D. Kim — Fri, 10 Jul 2026 00:00:54 GMT

Good evening,

Tonight, I’m discussing the status of the lean Ethereum project in light of the Ethereum Foundation Protocol team's updated strawmap proposal.

On Glamsterdam development, there are no major updates in tonight’s newsletter. For the latest ACD call summary, refer to the linked call notes at the bottom of the newsletter.

As a note to readers, the visibility of my posts has changed. Free subscribers will now receive full posts in their inboxes a few days after publication, while premium subscribers will get early access to my insights. Also, the two-month summer special offer is still ongoing. You can try a premium Substack subscription for free until August 31 with this offer code.

Let’s get into it.

Yours truly,

Christine D. Kim

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

On Saturday, July 4, Vitalik Buterin, co-founder of Ethereum and a board member of the Ethereum Foundation (EF), shared an updated version of the strawmap.

The strawmap is a loose development roadmap outlining the major upgrades Foundation developers envision for Ethereum over the next three to four years. It was initially unveiled by the EF Protocol team in February and recently updated after an in-person gathering of Ethereum researchers in Berlin.

Compared to the one from February, the latest version of the strawmap:

Consensus layer (CL): Schedules a change to issuance between 2027 and 2028 in the I-star hard fork that was not there before
Data availability (DA): Pushes back blob capacity increases and other blob-related features, such as blob streaming, so that they occur later in the roadmap than before
Execution layer (EL): Fewer thinking face emojis, which illustrate greater certainty and consensus among Ethereum researchers on the EL-focused upgrades that will take precedence over the next three to four years

Overall, the strawmap appears simpler, more organized, and more concrete than the one from February. The new strawmap also prioritizes improvements to Ethereum Layer-1 over Ethereum’s Layer-2 ecosystem, which tracks with Buterin’s earlier posts about pivoting away from the rollup-centric roadmap.

However, as a reminder, the strawmap, as with any multi-year roadmap released by the EF, is subject to change and ongoing iteration. As stated on the strawmap website:

An “official” roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process.

All priorities and upgrades featured in the strawmap, except those explicitly labeled as “SFI” for the Glamsterdam upgrade, still require approval through the Ethereum governance process. This includes changes like EL headliners like FRAME and, of course, CL features like snail issuance.

The strawmap is a document created and maintained by one “node,” to use Buterin’s language, among many nodes that influence which features actually get built and implemented in the Ethereum protocol.

In prior years, the Foundation’s say in Ethereum’s research and development was the main source of truth and authority. However, due to its recent downsizing and restructuring, there is a greater likelihood that the EF Protocol’s view of Ethereum’s roadmap may no longer be the only view that matters to Ethereum’s development, and the opinions of other stakeholders, such as the newly founded EthLabs, could present views that oppose or change elements of the strawmap moving forward.

Redefining ‘lean Ethereum’

Aside from changes to the strawmap itself, Buterin’s comments on the updated strawmap, shared on X, were notable for affirming certain changes to the development of lean Ethereum.

As background, in 2024, EF Researcher Justin Drake unveiled the Beam Chain at Devcon, a biannual Ethereum conference organized by the EF. Drake described the Beam Chain as the next iteration of Ethereum’s CL, also called the Beacon Chain.

It would be quantum-secure with faster blocks and native zero-knowledge virtual machines (zkVMs). Drake said the specifications for the Beam Chain are already being worked on by multiple independent teams of developers.

Due to trademark issues with the name “beam,” the beam chain was later rebranded to “lean Ethereum.” Recurring calls were created on the Ethereum protocol meetings calendar to coordinate research and development for the lean project.

Over the last few years, work on lean has become sprawling, encompassing several parallel initiatives related to Ethereum’s quantum migration, fast finality, and zkVMs. Despite fanfare about lean specifications and client implementations already being tested on devnets, the work remains highly exploratory and experimental.

It is becoming less of a major upgrade to Ethereum and more of a catch-all phrase that references all the strawmap's north-star goals.

Buterin acknowledged this shift as one of the most important takeaways from the updated strawmap. Buterin said:

"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 …

Rather than lean Ethereum replacing the Beacon Chain, the research for lean Ethereum, which is really research into fast finality, quantum-resistance, and long-term Layer-1 scaling, will be merged piecemeal into the existing Beacon Chain.

This has wide-ranging implications for the lean consensus layer clients such as Ream, Zeam, and Qlean. They will likely no longer be designed as standalone clients to replace existing CL clients as originally thought. Their work, if any of it proves useful, will likely be folded into existing CL clients like Lighthouse and Prysm.

Further, it’s clear now that lean Ethereum is no longer pointing towards a standalone upgrade. It is looking ahead to several upgrades that together aim to make Ethereum a more performant protocol, leaving no aspect of the codebase untouched.

Finally, because lean Ethereum no longer represents a clean departure from existing Ethereum specifications, it is more likely to add to, rather than reduce, the protocol’s technical debt and complexity.

When first unveiling the idea for lean, then called beam, in 2024, Drake said on stage at Devcon:

With the benefit of hindsight, we now know what the mistakes we made with the Beacon Chain are, and we have a bunch of technical debt that is extremely sticky and tends to pile on over time and maybe now we have an opportunity to clear this technical debt.

As a project now envisioned to add more features to Ethereum piecemeal rather than overhaul several aspects of it with a single large upgrade, lean Ethereum is likely to increase the protocol’s technical debt over time before it ever reduces debt. One of the final pieces of the strawmap scheduled for 2029 and beyond is summarized on a card titled “tech debt reset”.

As with the initial ideation of the Merge upgrade, developers envisioned it as a clean migration to a new protocol. However, to minimize disruptions to applications and ensure backward compatibility, they ultimately decided to merge new code into the old. Developers are converging again on a similar plan with lean Ethereum: Add first, subtract later.

Bottom line

The new strawmap features minor changes and cleanups to the outlook for Ethereum development over the next three to four years. It is important to note that the strawmap is still subject to more change and iteration, especially as governance for the Hegota and other forthcoming forks proceeds.

The most important takeaway from the updated strawmap is Buterin’s remarks on what they mean for lean Ethereum.

As Buterin remarked, lean Ethereum is not a one-shot upgrade to the CL. It is a series of several upgrades that will leave no stone unturned in the protocol. Thus, lean Ethereum as the actualization of the strawmap is unlikely to reduce tech debt or ossify parts of Ethereum, as originally anticipated. Instead, it may add to the protocol’s burgeoning complexity, making each iterative upgrade more difficult and riskier to pursue.

Temp check 🗳️

Hashes, Lattices, and the Shape of Bitcoin’s Quantum Defense

Christine D. Kim — Tue, 07 Jul 2026 11:02:26 GMT

Good morning,

Today, I’m discussing the latest debate over Bitcoin’s post-quantum signature options, specifically hash-based signatures vs. lattice-based signatures.

Hash-based signatures are among the leading options, but evidence is mounting in favor of lattice-based signatures as a long-term, or even complementary, option because they better preserve advanced Bitcoin wallet functionality, such as multisignatures, threshold signatures, hierarchical deterministic wallets, and other complex constructions.

The discussion is quite technical and dense, and it doesn't offer immediate takeaways regarding Bitcoin's value or narrative. So, for those wanting just a quick, high-level update on Bitcoin development, I am highlighting up front that there’s nothing urgent to report this week. Bitcoin developers are plugging away, continuing work on the next major Core release, quantum, and other protocol priorities.

But if you're interested and have the time this morning to delve into the technical weeds of the debate on post-quantum secure signature schemes, read on!

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

The starter 🍳

The main 🥞

In May, the Blockstream research team published a blog post discussing the four broad types of post-quantum signature schemes: hash-based, lattice-based, code-based, and isogeny-based cryptography.

Hash-based signatures rely on hash functions, which turn data into fixed-length outputs that are easy to verify but hard to reverse.

Lattice-based signatures rely on hard mathematical problems involving lattices, or infinite grids of points. Patterns or connections on the grid are difficult to decipher without knowledge of the secret information about these pathways.

Code-based signatures are built from error-correcting codes, the same broad field of math used to recover corrupted data.

Isogeny-based signatures rely on special relationships, called isogenies, between elliptic curves. Their security comes from the difficulty of finding the hidden path between two related elliptic curves without secret information.

Each of these four categories represents a distinct mathematical approach to constructing digital signatures that are believed to be quantum-secure.

Of these, hash-based signatures are among the most widely discussed options for Bitcoin.

Pseudonymous Bitcoin developer “conduition” expanded on the main reasons why Bitcoin developers are looking into hash-based signatures in a response on the Bitcoin Developers Mailing List.

Conduition wrote:

Hash based signatures are incredibly conservative. They rely on strictly weaker assumptions than what we already depend on for other things. No other family of signatures can claim this property, and for something as inflexible-yet-sensitive as Bitcoin, conservativism is appealing.

However, the Blockstream post from May was written to encourage developers to take lattice-based solutions more seriously because of their “algebraic flexibility,” which could support more advanced Bitcoin wallet functionality, such as multisignatures, threshold signing, and other constructions.

As the post explains:

This means lattices potentially open the door for advanced modifications like post-quantum multisignatures, zero-knowledge proofs, and confidential assets.

The main pushback

The main pushback against lattice-based signatures, compared with hash-based ones, is that the former are generally considered riskier to implement on Bitcoin.

Bitcoin already relies heavily on hash functions across the protocol, including in mining, transaction IDs, Merkle trees, and address construction. Thus, a hash-based signature scheme would rely on cryptographic assumptions that Bitcoin already uses today, whereas lattice-based schemes would introduce new assumptions and more experimental constructions into the protocol.

In an email thread discussing lattice vs hash-based schemes, Conduition wrote:

Lattice threshold and key-rerandomization schemes will likely improve from where they are now, but until proven otherwise we should make choices about consensus based on what we have, not what we hope we will have someday.

That said, Conduition added that hash-based schemes do not preclude research and development of other schemes for consideration as a long-term replacement for or in addition to hash-based schemes.

Keeping options open

Given the promising potential of non-hash-based signature schemes, developers are actively discussing ways to address their safety concerns.

One option under discussion is to implement lattice-based signatures in a hybrid manner that couples them with existing Bitcoin signature schemes, such as Schnorr signatures (i.e, BIP-340). The idea is that the lattice-based signature would provide post-quantum security, while the Schnorr component could provide additional protection against cryptographic weaknesses or implementation bugs in the newer lattice-based scheme.

In a Delving Bitcoin post discussing hybrid post-quantum signature schemes, Bitcoin Core developer Pieter Wuille, also known as “sipa”, wrote:

Longer term, if schemes based on other more novel assumptions were added (like lattices or isogenies) I think it would be entirely reasonable to consider them only in a hybrid form,

Speaking to the potential for a hybrid lattice-based signature scheme, Kvanta5, a post-quantum blockchain development team, noted that for their protocol, which relies exclusively on ML-DSA-87, a lattice-based signature scheme, the additional Schnorr-related overhead in a hybrid signature construction is likely to be marginal compared with the already large post-quantum signature data.

In response to the Delving post on hybrid signature schemes, they wrote:

This is consistent with sipa’s observation that the [post quantum] blob is “the dominant element” — the Schnorr R (32 bytes) is essentially rounding error at this scale. Whether that argues for or against hybridization probably depends on your threat model, but in terms of block space budgeting, the [post quantum] signature is the entire conversation.

Bottom line

Despite their experimental nature and the open questions about how to safely integrate them into Bitcoin, the body of relevant research and literature on lattice-based signature schemes is growing quickly.

While hash-based signatures remain the most conservative option, lattice-based schemes are emerging as strong long-term candidates for preserving advanced Bitcoin wallet functionality in a post‑quantum era.

Temp check 🗳️

Why Ethereum Institutional faces the same fate as Etherealize

Christine D. Kim — Fri, 03 Jul 2026 00:00:34 GMT

Good evening,

Tonight, I’m discussing the newly announced nonprofit, Ethereum Institutional, which is backed by the same two funders of EthLabs, Bitmine and Sharplink.

Ethereum Institutional is a nonprofit focused on accelerating Ethereum’s institutional adoption.

For longtime readers of my newsletter, this mission statement should ring a bell, as it’s oddly similar to that of another institution-focused Ethereum organization, Etherealize.

Below, I explain why these two organizations differ yet are likely to face the same challenges in pursuing their missions.

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. As a reminder to readers, the visibility of my posts has changed. Free subscribers will now receive full posts in their inboxes a few days after publication, while premium subscribers will get early access to my insights.

As a reminder, the two-month summer special offer is still available. You can try a free premium subscription to my Substack until August 31 using this offer code.

🌕 To read the full newsletter, make sure you are signed up for a free or premium subscription. Free subscribers will receive today’s full post in their inboxes next week. Premium subscribers can read it in full now. Become a subscriber:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

The shot 🥛

The chaser 🍪

The year is 2026, and Ethereum, after more than a decade of development and evolution, is still a protocol largely stewarded by a single organization, the Ethereum Foundation (EF).

However, as I discussed last week, this may be starting to change. Finally.

The EF announced in a blog post last Tuesday that it is downsizing and intentionally creating space for other stakeholders to take the helm in stewarding Ethereum's evolution.

So far, Bitmine and Sharplink, the two largest ETH treasuries in the world, and the companies with the most capital on the line to see Ethereum succeed, have stepped up in a big way to back Ethereum.

Last Monday, Bitmine and Sharplink announced the creation of a new non-profit research and development (R&D) organization, EthLabs, led by former EF researchers and developers.

EthLabs is the first serious attempt to diversify Ethereum core protocol R&D away from the Foundation and start a new hub for this activity.

If successful, EthLabs and others like it could prove that the Foundation's efforts, though valuable, aren’t what make or break Ethereum’s value—a highly contested truth about the protocol's decentralization and maturity that stakeholders can finally prove in practice, not in theory.

That’s the ambitious and value-add vision behind EthLabs.

This week, Bitmine and Sharplink announced the creation of a second non-profit organization, Ethereum Institutional.

Unlike EthLabs, the vision behind Ethereum Institutional is unclear, given the myriad of teams just like it that already exist and have a spotty track record of success.

Ethereum Institutional vs. Etherealize

Publicly unveiled on Monday, July 1, Ethereum Institutional is a non-profit focused on accelerating the institutional adoption of Ethereum, its Layer-2 protocols, applications, and the overall ecosystem.

As stated on their website:

Ethereum Institutional is the front door to institutions. It leads engagement, education, and coordination, ensuring Ethereum is consistently represented in high-stakes institutional decision-making. It builds trusted relationships with banks, asset managers, and public institutions, translates Ethereum's value proposition into institutional terms, and surfaces real-world requirements.

The mission is awfully similar to that of Etherealize, another organization launched early last year with backing from the EF to accelerate the institutional adoption of Ethereum.

When Etherealize launched, the company stated on X:

Introducing Etherealize, an institutional marketing and product arm for the Ethereum ecosystem. Our goal? To accelerate adoption by bringing institutions to Ethereum: the digital economy of tomorrow. First, Etherealize is a hub for content - for TradFi, for ETF issuers, and for the broader public to learn about the Ethereum economy. Ethereum is ambitious - it’s the operating system for the global economy. We’ll help spread Ethereum’s potential.

The main difference between Ethereum Institutional and Etherealize is that Etherealize is a for-profit entity focused on developing revenue-generating products for institutions.

Realizing the problem with Etherealize

It’s been nearly a year since Etherealize launched, and the organization has yet to announce or unveil any products built for institutions on Ethereum. While the company has certainly fulfilled its mandate as a hub for content on why institutions should build on Ethereum, it’s unclear what Etherealize is actually building.

Early in the company’s evolution, it was speculated that Etherealize would build institution-focused Layer-2 infrastructure, but whether that is still in the works remains unclear, especially after Vitalik Buterin’s statements back in February that Layer-2s are not extensions of Ethereum, nor will they be the way the protocol scales in the long term.

Alongside Ethereum Institutional and Etherealize, the EF has also stated that it will continue to focus on showcasing Ethereum and its potential to institutions, even as the organization downsizes. In last week’s blog post announcing their latest restructuring efforts, the EF wrote:

We believe that many enterprises, governments, and nonprofits will realize that their incentives favor serving users in ways that strengthen self-sovereignty .... In addition to direct engagement, the institutional cluster will pursue these ends by helping to establish and thoughtfully communicate best practices, standards, reference architectures, and educational materials for institutional adoption.

This means there is now a mix of non-profit, for-profit, and non-profit-sponsored-by-for-profit businesses, all directing resources toward marketing Ethereum to the institutional audience.

However, as has been the case for Etherealize since its launch, it’s unclear what use cases or products these teams are marketing Ethereum for.

In search of the institutional use case for Ethereum

The current mission statement of Ethereum Institutional, which still seeks to market Layer-2s to institutions, and the fact that new Layer-2 protocols like Robinhood Chain are still being actively developed on Ethereum suggest that Layer-2s are the leading drivers of Ethereum’s institutional adoption.

However, the vision behind Layer-2s from a protocol perspective has shifted dramatically over the last year.

It is now widely recognized by the community that Layer-2s, at least in their current designs, are not value-additive to Ethereum. They’re value-extracting. Further, the technical and financial motivation for building them remains largely experimental, with few examples of success.

Their value accrual back to Ethereum has also proven to be marginal, and developers have since pivoted to focus the next immediate upgrade, Glamsterdam, almost entirely on scaling Layer-1 Ethereum and driving usage back to Layer-1.

But, without Layer-2s, it is unclear what use cases or infrastructure institutions should then use Ethereum for.

Bottom line

Launching a new institution-focused Ethereum organization before Ethereum has a clear institutional use case is like putting the cart before the horse.

It is difficult to see how groups such as Ethereum Institutional, Etherealize, and the EF's Institutional cluster can succeed if Ethereum’s value proposition is not well-defined or supported by live protocols demonstrating that value.

Thus, these organizations will likely serve a different role for the time being as communication funnels, relaying potential institutional needs for Ethereum back to core development teams, such as EthLabs and the EF Protocol cluster.

This is a critical and necessary role that may result in meaningful changes to the Ethereum protocol, its value, and its development roadmap. However, it is not their stated role to market and educate institutions about Ethereum.

It’s the role of seeking out an institutional use case for Ethereum.

Important work, no doubt. Just one that does not presume the use case is already there or built.

Find the answer to this question in my write-up above!

All Core Developers Execution #240 call summary and transcript (Forkcast)
New Hegota EIPs proposed since last Thursday’s ACD call:
Deadline for Hegota Ethereum Improvement Proposal submissions is August 6 (X, Nixo Rokish)
ENS founder, Nick Johnson, under scrutiny for taking unilateral control over DAO funds and operations (The Defiant)

🙂 Thank you for reading! What did you think of today’s issue? Please share your feedback by leaving a comment.

Addressing Bitcoin’s block subsidy problem

Christine D. Kim — Tue, 30 Jun 2026 11:02:48 GMT

Good morning,

Today, I’m discussing Bitcoin’s block subsidy problem and highlighting parallels with the ongoing debate over reducing issuance on Ethereum.

Neither debate is likely to result in near-term protocol changes due to their lack of urgency, but if and when the need arises, it is worth considering what developers are likely to do about the block subsidy problem and the issuance reduction question.

On the Bitcoin side, my prediction is nothing, at least on the protocol level. Below, I explain why.

But first, I have a few Substack updates.

For readers who did not read last week’s ACD After Hours post, note that development summaries will now appear further down in the newsletter, after the main insights section.

Going forward, I am relying more on AI-powered tools, including Forkcast and the Bitcoin Orange Dev Suite, to help with summaries, whilst I focus my writing on analysis and insights.

I’m also changing the visibility of my posts starting this week. Instead of keeping insights permanently paywalled, posts will now be temporarily paywalled. Premium subscribers will get immediate access when posts are published. Free subscribers will be able to read the full version one week later.

My goal is to broaden access to my work for the wider subscriber audience, especially now that these newsletters will be more insight-driven.

Previously, summaries were free, and insights were paywalled. With the new format, the full post will be available to premium subscribers first, then opened to all subscribers after one week.

Feedback on these changes and your reading experience on my Substack are welcome. Thank you to all my subscribers for your readership.

Now, let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

Addressing Bitcoin’s block subsidy problem

On Tuesday, June 23, a pseudonymous user “show1225” posted a discussion thread on Delving Bitcoin about Bitcoin’s block subsidy problem.

The block subsidy problem is the concern that, over time, Bitcoin miners may not have enough revenue to keep securing the network once newly issued bitcoin becomes a smaller and smaller part of their compensation.

Today, miners earn 3.125 BTC, plus transaction fees, for every valid block they mine. Roughly every four years, this subsidy is cut in half. This process, known as the halving, is central to Bitcoin’s fixed monetary policy. It is the reason Bitcoin’s supply, under the current protocol design, will never exceed 21 million coins.

Today, miners are paid primarily through newly issued BTC. In the long run, as the subsidy fades, miners are expected to rely increasingly on transaction fees, but, as Show 1225 and others have noted in the past, fees are volatile, and periods of high fee revenue are short-lived, making them an unreliable replacement for the predictable block subsidy.

Source: bitinfocharts.com

Show 1225 proposes introducing a perpetual “tail emission” of 0.25 BTC per block, beginning around the year 2040, when the block subsidy is scheduled to fall below that level. The proposal would pair this new static subsidy with an EIP-1559-style fee model, in which a base fee is burned, and miners receive priority tips, thereby reducing fee volatility.

In short, the proposal would break Bitcoin’s 21 million supply cap in order to create a more predictable long-term security budget for miners.

While this is one of many proposals over the years that have tried to address Bitcoin’s diminishing subsidy, the latest discussion sparked by Show 1225’s proposal is notable for highlighting important parallels with the discussion of issuance changes in the Ethereum community right now.

The similarities are striking

In both cases, the root concern is that the monetary policies of Bitcoin and Ethereum may not be sustainable over the long term for securing these protocols. Over time, the financial incentives for securing Bitcoin and Ethereum may lead to suboptimal outcomes: in the case of Bitcoin, a loss of miners and hashrate; and in the case of Ethereum, over-issuance of ETH and the dominance of liquid staking protocols (LSTs).

None of these concerns is particularly new. They seem to resurface like clockwork every few years in the Bitcoin and Ethereum community, especially during market downturns, when BTC and ETH prices are underperforming.

These monetary policy debates depend on assumptions about the minimum viable level of security. And, in both cases, it is difficult to pinpoint with any certainty what this value should be, as it is based on a subjective understanding of the fair, long-term market price for BTC and ETH.

Jameson Lopp, the co-founder and CTO of Casa, posting as “statoshi,” made this point in the Delving thread. He wrote:

One of the fundamental reasons I think most schemes to address decreasing block subsidies are non-starters is because there is no way for Bitcoin as a system to know its own value. Some say that this is a “fiat approach” but fiat is merely one way to measure value because it’s a unit of account. Point being, it’s very hard to algorithmically change the revenue afforded to miners if you are targeting a given level of thermodynamic security that’s measured in any standard unit of account.

Given the uncertainty in determining a fair value for Bitcoin or Ethereum, it is difficult to determine the minimum viable level of security required to protect this value.

Another similarity between Bitcoin and Ethereum is that the coordination cost of changing monetary policy is high.

For many Bitcoiners, the idea of breaking the 21 million supply cap is a non-starter, as Bitcoin’s finite supply is not just a technical parameter but an invariant of the protocol that is core to the technology’s value proposition.

Pieter Wuille, a prolific Bitcoin Core developer, posting under “sipa,” wrote in the Delving thread:

I consider this a complete non-starter. Not because tail inflation is inherently a bad idea. It may well be better, but we don’t know. The right place to try this is in another currency, where it can compete fairly.

In other words, if you break the 21 million supply cap, the protocol is no longer Bitcoin. It’s something else entirely.

Another prolific Bitcoin Core developer by the name of Anthony Towns added that there’s no real urgency on the issue of the diminishing block subsidy, as its value in USD terms has only increased through several consequential halvings.

Source: Anthony Towns, Delving Bitcoin

Thus, concerns about the block subsidy running out are still largely theoretical. In practice, Bitcoin operates with a significant, if not excessive, level of hashpower, and the market value of the block subsidy, despite multiple halvings, continues to grow.

Fred Thiel, CEO of Marathon Digital Holdings, the world's largest Bitcoin mining company, stated in a recent interview that Bitcoin is over-secured. He said:

You’ve got way too much mining going on compared to what is required to secure the bitcoin blockchain which makes it super secure. The Bitcoin blockchain could certainly lose some mining capacity and would still be just as secure as it is.

Bitcoin could do with fewer miners and still be fine from a security perspective. This reality captures why many stakeholders are not motivated to change Bitcoin’s monetary policy today.

The case is similar on the Ethereum side.

The concern about over-issuance is real, but it largely rests on what could happen if staking participation continues to rise and LSTs or custodial staking providers become more dominant.

While this is an important issue to monitor, it is not yet clear that Ethereum is facing a security crisis because of its current issuance curve.

Without a clear and immediate problem, the default response in both communities is to wait, gather more data, and focus on more urgent protocol work that has broader community support and consensus.

The most likely outcomes

While the issues surrounding the security budget of Ethereum and Bitcoin lack urgency today, this may not always be the case in the future, and these discussions, whilst not likely to result in any near-term protocol changes, do help to clarify the possible responses in the event that the security-budget question does become more urgent in Bitcoin or Ethereum.

On the Bitcoin side, a useful comment by "Choirzooh” in the Delving thread separated the possible responses into three broad categories:

A change to issuance, e.g., Show1225’s proposal
A change to the fee market and/or block size, e.g., ‘Goldiblocks’
A diversification of miner revenue sources, e.g., merged mining

For reasons stipulated by Wuille, the first option, though it is the most direct and simplest way to address a potential problem in Bitcoin’s security, is the least feasible because it would violate Bitcoin’s fixed-supply commitment.

The second option is also unlikely because Bitcoin’s development culture is generally averse to changes to the core consensus protocol, even if they don’t necessarily break the 21-million supply invariant.

This is a key difference between how Bitcoin developers would handle a problem in their security budget and how Ethereum developers would handle one. There are no “sacred cows” in the Ethereum codebase. Every technical parameter is subject to change according to the consensus of developers and the broader Ethereum community of stakeholders.

For Ethereum, the most likely option is 1 or 2.

For Bitcoin, the most likely option in my view is 3.

The third option includes various ways to pay miners outside Bitcoin’s issuance schedule and transaction fees. This could be merged mining, energy-market revenue, AI or high-performance computing infrastructure, grid services, or other external business lines that make mining profitable without changing Bitcoin’s monetary policy.

This option seems the most realistic because it does not require changing Bitcoin consensus rules and it’s already happening. The largest Bitcoin miners in the world are moving away from Bitcoin mining as a standalone business and moving towards diversification into other energy and compute businesses.

As the subsidy declines, miners will likely increasingly need to monetize cheap, stranded, or otherwise wasted energy. They will also need to operate across multiple compute markets, including Bitcoin mining, AI inference, high-performance computing, and grid-balancing services.

Thiel described this future as a world where Bitcoin mining becomes a way to “monetize electrons.” In his view, energy companies with excess wind or solar power have an incentive to use Bitcoin mining to turn otherwise wasted energy into revenue.

He said in a recent interview:

The security budget [issue] is essentially managed by the fact that people are using Bitcoin mining simply as a way to monetize electrons. … And I think what you’re going to see long term, and certainly this is in Mara’s kind of vision is that as we begin building and operating more inference AI type data centers, inference AI workloads are very varied, not unlike power demand on the grid. And we've developed technology that allows us to mirror [that] load.

Long-term, there may not be any more Bitcoin miners, in the sense of businesses and individuals generating electricity purely to mine Bitcoin.

Rather, mining will likely become one flexible workload among several, subsidized by energy producers, data center operators, and other businesses seeking to monetize excess power.

In this scenario, Bitcoin’s long-term security budget will be supported by the economics of energy and compute markets happening primarily outside the protocol.

Bottom line

There are many parallels in the debates happening right now in Bitcoin and Ethereum about protocol issuance. These debates are highly controversial and unlikely to result in any near-term changes, as they lack urgency and broad community consensus.

However, if and when the security budget of either of these protocols becomes an immediate issue, the solution for Ethereum will likely look very different from that for Bitcoin.

Whilst an issuance change on Ethereum would be a matter of tweaking a few technical parameters, an issuance change on Bitcoin would break an invariant core of the protocol's value proposition.

Thus, for Bitcoin, the most realistic solution is one already being tested by Bitcoin miners, who are diversifying their revenue streams so that Bitcoin’s declining subsidy and declining mining profitability are offset in the long term by other energy-intensive activities, such as AI workloads.

Bitcoin Core v32 release schedule (GitHub)
Binaries for Bitcoin Core version v31.1rc1 are now available for testing and review (Bitcoin Developers Mailing List)
Transcript of last Thursday’s, June 25, Bitcoin Core Developers meeting (Erisian)
Summary of Bitcoin Core development activity from the past week (This Week in Bitcoin)
An interesting thought experiment for using Bitcoin and zero-knowledge proofs to verify AI outputs. (Bitcoin Developers Mailing List)
A proposal to introduce emergency switches for new quantum-resistant Bitcoin address types that would disable old cryptography automatically or through a hashrate majority if a quantum attack is detected on the network. (Bitcoin Developers Mailing List)

As part of Summer of Bitcoin, a global online internship program focused on Bitcoin open-source development and design, Joris Strakeljahn built a new dashboard for tracking changes in Bitcoin’s network-mapping data over time.

One chart in the dashboard highlights the concentration of reachable Bitcoin nodes operated through large hosting providers. In the latest snapshot, the dashboard shows 8,743 reachable Bitcoin nodes, with an estimated 24% operated through Hetzner, OVH SAS, Amazon, AT&T, and Contabo, the five largest providers in the snapshot.

Source: ASmap Dashboard

🙏 Thank you for reading. If you liked today’s issue, consider sharing it with a friend who might also enjoy the content.

💥If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.

What a small EF means for Ethereum

Christine D. Kim — Fri, 26 Jun 2026 01:04:25 GMT

Good evening,

The cat’s out of the bag.

We finally know what has been going on at the Ethereum Foundation for the last few months. They’ve been cutting one-fifth of their workforce. We also now know why both Tom Lee and Joe Lubin were unfazed by the Foundation’s downsizing. They are backing a new Foundation called EthLabs.

While all of this is generally positive news for the Ethereum ecosystem, it’s not really news that helps the longer-term picture for Ethereum’s value.

Below, I explain why.

And based on the feedback I’ve been receiving from readers, many of you will be happy to see that I explain why directly below, without first diving into some of my dryer content summarizing Ethereum development.

Starting this week, I’ll be relying exclusively on Forkcast to give you the summary of the latest All Core Developers (ACD) call. You’ll find a link to it further down below in tonight’s newsletter.

Without further ado, let’s get into it.

Yours truly,

Christine D. Kim

🌕 To read the full newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

What a small EF means for Ethereum

After months of little to no communication about the slew of employees leaving the organization, the Ethereum Foundation (EF) finally announced on Tuesday that these departures have been part of “a months-long process of reorganization” to reduce spending and narrow the organization’s focus.

In a blog post, the EF shared that over the past few months, they have let go of 54 employees, cutting down the organization’s headcount by 20%.

Vitalik Buterin, Board Member of the EF and co-founder of Ethereum, added that the organization’s annual operating budget will be reduced by 40% this year as part of an earlier announced shift toward an endowment model, where the Foundation gradually reduces annual spending from roughly 15% of its remaining treasury to closer to 5% over time.

A smaller EF, not necessarily a narrower EF

It’s clear now that the reorganization and recent departures at the EF have been motivated by efforts to lower costs and extend the Foundation’s runway.

However, the details of the reorganization do not indicate any changes in the Foundation’s focus or mission. The Foundation remains committed to stewarding all of Ethereum, from the core protocol layer up.

In their blog post on Tuesday, the Foundation said remaining staff, roughly 170 employees, have been reorganized across five domains of work:

BTC Before Light: Issue 45 ☀️

Christine D. Kim — Tue, 23 Jun 2026 11:03:04 GMT

Good morning,

Today, I’m excited to share a new tool for tracking Bitcoin development and governance called the Orange Dev Suite.

The tool is not mine. I recently learned about it, looked into it, and think it is worth highlighting.

As my readers should already know, I am a huge fan of tools that make Bitcoin development and governance easier for more people to follow. It’s why I do what I do, and why I built the BTC Toolkit last year.

This new tool I’ll discuss below comes pretty close to what I envisioned for the BTC Toolkit 2.0, which is why I’m excited to share it with you today.

Now, for any of my readers wondering how I think about the role of my coverage alongside tools like the Orange Dev Suite, I view these tools as complementary to my independent coverage.

Yes, there is some overlap, but this kind of overlap is long overdue and creates opportunities for specialization in Bitcoin development analysis that otherwise didn’t exist. In short, it takes a village to cover Bitcoin development and governance, so all contributions are welcome!

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. For all my free subscribers, please take advantage of my summer special, which gives you access to all my paid posts for a trial period of two months. The offer expires August 31! Happy reading~

⏱️Core Release Schedule

First, a quick overview of Bitcoin Core’s software release schedule and the status of the next major release:

Latest Stable Major Release: Bitcoin Core 31.0

Release Date: April 20, 2026

Upcoming Major Release: Bitcoin Core 32.0

Target Release Date: October 10, 2026
Open issues: 19
Closed issues: 43
Milestone progress: 69%

Last week’s snapshot showed 22 open issues, 35 closed, and a 61% milestone progress.

🖊️ Meeting Log

An overview of the Bitcoin Core developers meeting that took place last Thursday, June 18, 2026, sourced from Internet Relay Chat (IRC) logs recorded by Chaincode Labs.

Issues

Descriptions of bugs and areas for improvement in Bitcoin Core and their respective status:

None raised during last Thursday’s meeting.

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective status:

Ready for review

Bitcoin/bitcoin, PR #35215—coins: use jumboblock SipHash-1-3 for hashing CCoinsMap keys
Bitcoin/bitcoin, PR #35295—validation: fetch block input prevouts in parallel during ConnectBlock

Merged

Bitcoin-core/secp256k1, PR #1859—field: force-inline 5x52 mul and sqr
Bitcoin/bitcoin, PR #35465—coins: compact chainstate regularly
Bitcoin/bitcoin, PR #34636—node: allocate index caches proportional to usage patterns

Discussion Topics

Purple Karrot “Serialization” blog post: Serialization is the process of converting data, like a Bitcoin transaction or block, into an exact byte format that can be stored, sent, and verified by other computers. Bitcoin Core contributor “Purple Karrot” details in this blog post the motivation and design for making Bitcoin’s serialization code more explicit, lighter-weight, and safer.
QML GUI Working Group (WG) update: The WG is developing a newer, more modern interface for Bitcoin Core. Bitcoin Core already includes an optional wallet and graphical interface, and the QML effort is an experimental rewrite/fork of that GUI using Qt’s QML framework. During this Thursday’s meeting, “Johnny9dev” said the QML GUI project is nearing the point where people outside the working group can start testing it. There are currently four PRs under review, and once those are finished, the team expects to start sharing preview builds.
Introducing bitcoind-gunix: Bitcoin Core contributor “b10c” shared an experimental side project called bitcoind-gunix that successfully reproduces the official Bitcoin Core v31.0 release using Nix instead of Guix. In other words, the project can rebuild all of the official release files — including binaries, tarballs, debug files, and signing artifacts — and produce outputs that match the official Guix-built release byte-for-byte.
Bitcoin Improvement Proposal (BIP) repository summer cleaning: Bitcoin Core contributor “Murch” asked BIP authors to review their draft BIPs on GitHub and open a PR if they think any should be closed or advanced to a different status.

🌟 PR Spotlight

PR #34636

Category: Bitcoin/bitcoin, the reference implementation for Bitcoin Core full nodes, which enables users to directly connect to the Bitcoin peer-to-peer network and download and validate blocks and transactions. The implementation also includes an optional wallet and graphical user interface.

Title: “node: allocate index caches proportional to usage patterns”

Author: “svanstaa”

Status: Merged

Date opened: February 20, 2026

Most recent update: June 18, 2026

What it does: This PR changes how Bitcoin Core allocates cache space to optional indexes. An index is a lookup tool that helps Bitcoin Core nodes find data more quickly, such as information about transactions or blocks. This PR makes the allocation more explicit by assigning cache space based on how frequently the indexes are typically used.

Why it matters: Cache is memory set aside to make repeated data lookups faster. In theory, allocating it more intentionally can make Bitcoin Core’s resource usage cleaner and easier to reason about.

However, as noted by Bitcoin Core contributor “sipa” during last Thursday’s meeting, his recent findings suggest this PR may not be necessary after further analysis of one of Bitcoin Core’s internal databases, LevelDB, and its resource limits.

☁️ That’s all for my summary of Bitcoin Core development. Continue reading for my insights. To read the rest of the newsletter, make sure you are signed up for a premium subscription:

Subscribe now

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

Protocol Watch

🧭 Insights

When it comes to understanding the value of open-source blockchain protocols, there is no better place to start than with the development process itself.

As I have shared in the ACD and BTC Toolkit series, understanding the people, forums, and processes through which public blockchains are developed is the best way to track how these technologies and their value evolve over time.

This is one of the unique strengths of tracking any open-source technology. Value is not determined behind closed doors and then shipped out to users in new product releases. You can watch development happen in real time. You can see the conversations shaping the technology, the disagreements that slow or redirect work, and the priorities that emerge when long-time code maintainers leave, and new ones take over.

This matters especially for Bitcoin, a multi-billion-dollar protocol that is rapidly gaining institutional adoption and government attention. Bitcoin has no CEO and no formal roadmap. Its development is governed by a loose, open-source process that can be difficult to follow without knowing who the contributors are, where they are talking, and what they are most focused on doing or changing about Bitcoin.

That is why I am excited to share a new resource for tracking Bitcoin development and governance called the Orange Dev Suite, created by Bitcoin Data Labs.

(Disclaimer: I did not build this tool and have no affiliation with it. I have spoken with the founder of Bitcoin Data Labs, Saurabh Kumar, but I did not receive payment, promotion, or anything else in exchange for writing about Bitcoin Data Labs. As with all my writing on this Substack, my views are independent.)

Introducing the Orange Dev Suite

ACD After Hours: ACDE #239 🌙

Christine D. Kim — Fri, 19 Jun 2026 00:00:54 GMT

Good evening,

Tonight, I’m discussing several top-of-mind topics in Ethereum protocol development.

First, I dig into the actual status of the Glamsterdam upgrade. Despite recent headlines suggesting the upgrade has entered its “final stage,” that characterization is obviously wrong to anyone who has been following its development.

Glamsterdam is making meaningful progress, but it is still in active implementation, testing, and scope refinement. My read is that developers are roughly 60% of the way there, and I explain why below.

Second, I cover an important new discussion regarding the introduction of EIP-8282, a proposal that developers have now agreed is technically necessary for Glamsterdam but could meaningfully delay the upgrade timeline.

Finally, I address Hsiao-Wei Wang’s departure from the Ethereum Foundation and what it signals about the EF’s ongoing restructuring, its narrower role in the ecosystem, and the broader question of who will step up to fund and coordinate Ethereum protocol development going forward.

Let’s get into it.

Yours truly,

Christine D. Kim

🗒️ Call Minutes

First, a quick summary of the latest Ethereum developer call, All Core Developers Execution (ACDE) #239.

Glamsterdam devnet updates

Developers are continuing to test the Glamsterdam upgrade on Glamsterdam-Devnet-5. A full list of code changes and features being tested on the devnet is listed here.
Ethereum Foundation (EF) Developer Operations Engineer Barnabas Busa said the Prysm client team is investigating and fixing issues surfaced on the devnet. Most other client teams are preparing for the launch of Glamsterdam-Devnet-6, which is tentatively scheduled to launch mid-next week.

Glamsterdam specifications changes

Developers agreed to include Ethereum Improvement Proposal (EIP) 8282, Builder Execution Requests, in Glamsterdam.
- As discussed on last Thursday’s call, this proposal would give third-party block builders their own dedicated execution-layer (EL) request contracts for deposits and exits. This removes edge cases associated with bundling builders and validators into the same queue.
- Although developers did not mention it on this Thursday’s call, they highlighted on Monday during the All Core Developers Testing (ACDT) call that adding this EIP may delay the upgrade by up to three months.
- Developers discussed on ACDT #83 potentially activating the EL-side of the upgrade, dubbed Amsterdam, earlier and separately from the consensus layer upgrade, dubbed Gloas.
Developers agreed to add an optional networking EIP, EIP 8189, to Glamsterdam. This proposal builds on EIP-7928, Block-Level Access Lists (BALs), and enables a BAL-based state-healing process in nodes during snap sync, enabling faster chain recovery during periods of network instability.
Developers debated a potential change to EIP-7928 that would restructure how stack overflow checks are handled in BALs to address edge cases. Half of the client teams leaned towards no changes, as the edge case is rather small and unlikely to be exploited. The other half leaned towards a redesign proposed by Dragan Rakita, a Reth client developer at Paradigm.
- Developers agreed to reach a decision over the next few days so that any changes can be incorporated into testing on Glamsterdam-Devnet-6. A discussion thread for this issue has been opened on Discord.
EF Researcher Maria Silva shared updates on the Glamsterdam gas repricing EIPs. She confirmed that no gas cost repricing will be needed in Glamsterdam to reach the target throughput of 100 million gas per second. Thus, EIP-7904, which was a placeholder for general gas-cost repricing, has now been updated to an informational EIP that will not affect any protocol or client code.
- Silva also mentioned various changes to other gas repricing EIPs, including EIPs 8037, 8038, and 2780, that will be included for testing on Glamsterdam-Devnet-6.

Hegota EIP Proposals

The following EIPs were proposed for inclusion in Hegota:
- EIP 8304 (Trustless log & transaction index)—This EIP provides a simplified design for a trust-minimized framework to verify event logs and transaction data without relying on third-party indexing protocols or infrastructure providers.
- EIP 2488 (Deprecate the CALLCODE opcode)—This EIP disables an old, mostly unused Ethereum instruction, reducing unnecessary complexity for client developers while accepting a small risk of breaking ancient contracts that still rely on it.
- EIP 7645 (Alias ORIGIN to SENDER)—This EIP seeks to simplify two Ethereum instructions, ORIGIN and SENDER, for improving smart contract security and enabling future upgrades supporting native account abstraction.

Announcements

Client teams participating in Glamsterdam-Devnet-6 testing must include two new system contracts in their code to support the new addition of EIP-8282. Details for the system contracts and other specifications for Devnet-6 can be found here.
There is a 3 ETH bounty posted on Poidh for feedback on two Ethereum encrypted mempool proposals, EIP 8105 and 8184.
There is a community discussion happening on Ethereum Magicians about the emoji mascot for the Glamsterdam upgrade.

🌕 That’s all for my summary of ACDE #239. Continue reading for my insights on Ethereum development and governance. To read the rest of the newsletter, make sure you are signed up for a premium subscription:

Subscribe now

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:

Protocol Watch

🔎 Insights

Glamsterdam Is Not in Its “Final Stage” Yet

On Tuesday, CoinDesk published an article headlined “Ethereum’s biggest protocol overhaul in years moves into its final development stage.” It prompted several other news outlets, including The Defiant and Unchained, to publish similar articles the following day with a similar headline.

As someone who has been tracking Glamsterdam development weekly, I found the framing surprising.

Christine D. Kim

Fall 2026 to Spring 2027, My Last Hurrah!

The AI Question Bitcoin Core Can't Agree On

The side 🍳

The main 🥞

Ready for Merge Demo Recording w/Murch👾

Episode Summary

Timestamps

Show Links

Song Credits

Frame Transactions SFI’d for Hegota

The shot 🥛

The chaser 🍪

Developers hopeful for a December upgrade

Developers SFI Frame for Hegota

Bottom line

Temperature check 🗳️

Further reading 🛋️

What’s going in Bitcoin Core v32

The side 🍳

The main 🥞

Transaction rate-limiting

Mempool-based fee estimation

Bottom line

Knowledge check 🗳️

Further reading 🛋️

The Hegota tier rankings that matter most

The shot 🥛

The chaser 🍪

Developers talk dates for public testnet upgrades

The Hegota tier rankings that matter most

Bottom line

Knowledge check 🗳️

Further reading 🛋️

What's best for Bitcoin

The side 🍳

The main 🥞

Tail emissions and demurrage

Bitcoin’s immune response

Bottom line

Knowledge check 🗳️

Further reading 🛋️

What's best for Ethereum

The shot 🥛

The chaser 🍪

Hegota PFI’d EIPs list now final

What’s best for Ethereum

Bottom line

Knowledge check 🗳️

Further reading 🛋️

Luke Dashjr, Bitcoin's longest-serving BIP editor, is out

The side 🍳

The main 🥞

The motion

The response

The concern

The fallout

Bottom line

Knowledge check 🗳️

Further reading 🛋️

Post-Quantum EIPs for Hegota

The shot 🥛

The chaser 🍪

On Glamsterdam

On Hegota

Hash-Chain RANDAO

Concerns about EIP-8321

Bottom line

Knowledge check 🗳️

Further reading 🛋️

The case for a Bitcoin LLM

The side 🍳

The main 🥞

The motivation

Source material

Fine-tuning vs. special tooling

Benchmarking

Bottom line

Knowledge check 🗳️

Further reading 🛋️