Christine D. Kim

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:

☀️ 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

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.

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.

BTC Before Light: Issue 44 ☀️

Christine D. Kim — Tue, 16 Jun 2026 11:03:47 GMT

Good morning,

Today, I’m discussing a small improvement to Bitcoin wallet UX that was recently raised on the Bitcoin Development mailing list.

The proposal is an opt-in wallet feature that could make bitcoin self-custody easier for non-English speakers by allowing users to view and input BIP-39 recovery phrases in their native language, while preserving compatibility with the standard English BIP-39 flow.

Even though consensus on larger changes to Bitcoin, such as quantum security, remains elusive, work continues in other ways to make Bitcoin more accessible, usable, and safe for a global audience.

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️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: 22
Closed issues: 35
Milestone progress: 61%

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

🖊️ Meeting Log

An overview of the Bitcoin Core developers meeting that took place last Thursday, June 11, 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:

Open

Bitcoin/bitcoin, Issue #35457—Partial IBD speed regression between 9c150222604478431669b66b2caa0d75e8324d4c and 1ea532e590cdc16b86436a2bc4f92d74082307f9

Closed

Bitcoin-core/meta, Issue #46—Clarifying Moderation Policies for External Behavior

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective status:

Work-in-progress

Bitcoin/bitcoin, PR #35465—coins: compact chainstate regularly after post-IBD flushes

Ready for review

Bitcoin/bitcoin, PR #35295—validation: fetch block input prevouts in parallel during ConnectBlock
Bitcoin/bitcoin, PR #35465—coins: compact chainstate regularly

Merged

Bitcoin-core/bitcoin-core.org, PR #1255—posts: add notice about private broadcast IP leak in 31.0

🌟 PR Spotlight

PR #1255

Category: Bitcoin-core/bitcoin-core.org, the source code for the Bitcoin Core project website.

Title: “posts: add notice about private broadcast IP leak in 31.0”

Author: “andrewtoth”

Status: Merged

Date opened: June 6, 2026

Most recent update: June 11, 2026

What it does: PR #1255 adds a notice to the Bitcoin Core website warning users about a privacy bug in Bitcoin Core 31.0’s new privatebroadcast feature. The notice explains that, under specific network conditions, a transaction broadcast using sendrawtransaction may fall back from a Tor-routed v2 connection to a direct v1 IPv4/IPv6 connection, potentially revealing the sender’s IP address to the receiving peer. A fix is expected in Bitcoin Core 31.1, and the notice gives affected users temporary workarounds.

A more detailed explanation of the bug can be read in this BTC Before Light newsletter.

Why it matters: The bug is not a funds-at-risk issue, but it is important for a narrow set of users who rely on Bitcoin Core v31 to hide their IP address when transacting on Bitcoin.

Last Thursday, developers discussed whether to publicly disclose the bug before a fix is released in Bitcoin Core v31.1. Because the issue had already been discussed publicly at a prior Bitcoin Core developers meeting, developers agreed to publish a formal notice on the Bitcoin Core website and provide temporary workarounds for affected users until the fix is ready.

The discussions about how to properly disclose the bug highlight a recurring tension in open-source software development between transparency and user safety. Because publicly disclosed bugs can be exploited before a fix is available, developers tend to be cautious about discussing and announcing vulnerabilities too early.

In this case, because the bug had already been publicly discussed, it did not put funds at risk, and affected only a limited set of users, developers prioritized alerting users of the privacy risks in v31 as widely as possible ahead of the formal fix.

☁️ 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

A new discussion on the Bitcoin Development mailing list highlights a small but potentially useful effort to make Bitcoin wallets easier to use for non-English speakers.

ACD After Hours: ACDC #180 🌙

Christine D. Kim — Fri, 12 Jun 2026 00:00:55 GMT

Good evening,

Tonight, I’m sharing my takeaways from ETHConf, the first large-scale Ethereum conference hosted by the ETHGlobal team.

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 Consensus (ACDC) #180.

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 client teams are investigating and fixing issues surfaced on the devnet, including a fork-choice bug in Grandine and a peering bug in Prysm.

Glamsterdam API changes

Offchain Labs Prysm client developer James He has opened a PR, Beacon API/PR #608, to update various endpoints in the Beacon API in accordance with Glamsterdam code changes. These endpoints are related to block proposer preferences, such as the fee-recipient and gas-limit endpoints.
Founder of MigaLabs “Leobago” proposed changes to the Beacon API that would make validator deposit and activation states easier for node operators to track. The proposal, Beacon API/PR #618, clarifies pre-activation validator statuses and adds a new deposit_inqueue state for validator deposits that are in the deposit queue but have not yet become validator objects. Comments on the PR are welcome.
Busa proposed Beacon API/PR #606, which would expose more peer-scoring and disconnect-reason data from clients through the Beacon API. The goal is to make it easier for developers to debug client networking issues during devnet testing. Developers agreed to merge the change now while continuing to refine the exact fields added to the API.
The Staked Builder API for Glamsterdam has been finalized and merged.
Busa encouraged client teams to continue working on their implementations for execution-apis/PR #793, a change to the Execution API authored by Geth client developer Marius van der Wijden for supporting SSZ data serialization formats.

Glamsterdam specifications changes

Developers discussed the next steps for deprecating Multiplexer (mplex) in favor of QUIC. These are third-party protocols that the Ethereum consensus layer (CL) relies on for fast and reliable data transfers between nodes. Pending support from the Teku and Nimbus clients, developers agreed to aim for mplex deprecation by the time developers are ready to upgrade public testnets with the Glamsterdam upgrade.
Developers discussed a new EIP proposal, Builder Execution Requests, which would give third-party block builders their own dedicated execution-layer request contracts for deposits and exits. This could remove edge cases associated with Glamsterdam, but it may also add timeline risk for the upgrade. Developers agreed to continue discussing the proposal on next Monday’s All Core Developers Testing ACDT) call.

Hegota EIP Proposals

EF researcher Raul Kripalani presented EIP-8243: Batching Attestations at Source for consideration as part of the Hegota upgrade.
The goal of the proposal is to achieve validator consolidation-like effects so that the protocol can eventually support faster block times.

Announcements

The next ACDC call, scheduled for two weeks from now, is expected to return to a 14:00 UTC / 10:00 a.m. ET timeslot until further notice.
There is a community discussion happening on Ethereum Magicians about the emoji mascot for the Glamsterdam upgrade.

🌕 That’s all for my summary of ACDC #180. 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:

Protocol Watch

🔎 Insights

ETHConf was a three-day Ethereum conference at the Javits Center in New York.

BTC Before Light: Issue 43 ☀️

Christine D. Kim — Wed, 10 Jun 2026 11:01:42 GMT

Good morning,

Today, I’m discussing one of the most highly discussed proposals for improving Bitcoin’s quantum security: BIP 360.

Though there is still pushback against the proposal, discussions are becoming more advanced, as is the work to address some of its biggest tradeoffs.

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. One other interesting discussion happening right now in the Bitcoin developer community that I will likely do a longer post on, but that I want to flag briefly for curious readers, is about creating a Bitcoin LLM that thinks and reasons like the Bitcoin protocol.

The implications of an AI trained on “every BIP, every mailing list thread, every Delving post, every annotated transaction on-chain,” as described by researcher Thomas Suau, for Bitcoin governance are fascinating and full of potential. Can you imagine?

⏱️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: 22
Closed issues: 32
Milestone progress: 59%

Last week’s snapshot showed 19 open issues, 31 closed, and a 62% milestone progress.

🖊️ Meeting Log

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

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective statuses:

Work-in-progress

Bitcoin/bitcoin, PR #35465—coins: compact chainstate regularly after post-IBD flushes

Ready for review

Bitcoin/bitcoin, PR #32427—kernel: Replace leveldb-based BlockTreeDB with flat-file based store
Bitcoin/bitcoin, PR #35182—Replace libevent with our own HTTP and socket-handling implementation
Bitcoin-core/secp256k1, PR #1859—field: force-inline 5x52 mul and sqr

Merged

Bitcoin-core/leveldb-subtree, PR #61—Disable seek compaction

Discussion Topics

QML GUI Working Group (WG) Update: “johnny9dev” shared that there are now four active contributors to the project. A status of all open issues can be found here. The group is still on track to have a version of the wallet interface ready for wider feedback and review by the end of June.

🌟 PR Spotlight

PR #35465

Category: Bitcoin/bitcoin, Bitcoin Core client software used to connect to Bitcoin, the network, validate blocks and transactions, and transact on-chain.

Title: “coins: compact chainstate regularly after post-IBD flushes”

Author: “l0rinc”

Status: Work in progress

Date opened: June 4, 2026

Most recent update: June 9, 2026

What it does: This PR periodically reorganizes Bitcoin Core's chainstate database, which stores information about spendable bitcoins.

The reorganization is intended to compensate for an earlier optimization that disabled a type of automatic database maintenance because it caused excessive rewriting and slowed Initial Block Download (IBD).

In Thursday’s meeting, developers discussed the trigger for the initial chainstate cleanup and potential adjustments to the schedule for periodic cleanups to maximize the PR’s impact on Bitcoin Core nodes running on different settings.

Why it matters: Benchmarking found that the PR does not provide a significant speed boost. Instead, the main benefit is a tidier database that may make better use of a computer's memory and storage resources.

☁️ 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

One of the most contentious proposals right now being discussed in the Bitcoin developer community is BIP-360.

The proposal is part of a broader debate over how Bitcoin should prepare for “Q-day,” the day when cryptographically relevant quantum computers (CRQC) crack elliptic curve cryptography, making Bitcoin addresses vulnerable to theft.

ACD After Hours: ACDE #238 🌙

Christine D. Kim — Fri, 05 Jun 2026 00:01:18 GMT

Good evening,

Last week, I discussed the growing proliferation of centrally coordinated blockchain protocols that often boast higher levels of geographic, software, and jurisdictional diversity than traditional public blockchains like Bitcoin and Ethereum.

This week, I’m extending that discussion to examine what value these increasingly coordinated blockchain systems offer relative to traditional financial services.

Because their diversity is highly coordinated, the resulting decentralization, while potentially substantial, is not necessarily permissionless or credibly neutral. Rather, it depends on a central coordinator and the decisions of a relatively small set of actors.

For blockchains that can enforce rules, intervene in emergencies, and operate in ways similar to traditional companies, albeit with a greater commitment to operational diversity and resilience, an important question emerges: What exactly does the decentralization and open-source nature of these systems provide?

My argument is that even when a public blockchain falls short of credible neutrality, there remains immense value in the operational transparency these protocols can provide.

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. If you’re in NYC, I’ll be hosting another All Protocol Devs happy hour next Wednesday, June 10. It’s an informal gathering for protocol developers, researchers, and enthusiasts interested in Bitcoin, Ethereum, and public blockchain development more broadly. Hope to see you there! RSVP on Luma.

🗒️ Call Minutes

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

Glamsterdam Devnet Updates

Glamsterdam-Devnet-5 was launched today, June 4, with two execution layer (EL) clients and five consensus layer (CL) clients.
Developers confirmed that there will be no EL or CL-specific devnets for Glamsterdam moving forward. EL and CL code changes will be tested together on future devnets.
Developers also agreed to include preliminary versions of all remaining EL-focused Ethereum Improvement Proposals (EIPs) on Glamsterdam-Devnet-6.
Refer to this Google spreadsheet for an overview of the latest testing and inclusion status of Glamsterdam EIPs.

Hegota Proposals

Developers discussed the following EIPs for consideration in the Hegota upgrade:
- EIP-8131: Updates Ethereum's transaction cost rules to properly account for the new smart account features introduced by EIP-7702.
- EIP-8279: Makes sure users pay the correct fees when accessing additional data during transaction execution.
- EIP-7979: Introduces new low-level instructions that could make Ethereum programs more efficient and easier to optimize.
- EIP-8173: Provides a framework for understanding how Ethereum executes programs and how future upgrades could improve scalability.
- EIP-8222: Proposes a new staking protocol that improves privacy by making it harder to link validators to node operators.
- EIP-7851: Allows smart accounts created through EIP-7702 to update themselves without retaining their original private key permissions.
- EIP-8151: Adjusts Ethereum's signature verification mechanism to ensure accounts that permanently disable their old keys are handled correctly.

Announcements

As discussed on ACDC #179, developers will implement PR #793, a change to the Execution API authored by Geth client developer Marius van der Wijden for supporting SSZ data serialization formats.
Developers will be experimenting with a new time for next week’s ACDC meeting. The meeting will be held on Thursday, June 11, at 11:00 UTC/7:00 EDT.

🌕 That’s all for my summary of ACDE #238. 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:

Protocol Watch

🔎 Insights

The case for transparent, if not decentralized, blockchains

Bitcoin’s invention of non-sovereign digital money was groundbreaking, but another equally important innovation was Bitcoin’s transparent ledger.

The BTC holdings of every address and amounts transferred by every transaction could be independently verified by anyone able to run a node.

BTC Before Light: Issue 42 ☀️

Christine D. Kim — Tue, 02 Jun 2026 11:03:40 GMT

Good morning,

Today, I’m discussing three main topics: Strategy’s first bitcoin sale since 2022, key takeaways from a recent Bitcoin Core developer offsite in Barcelona, and a new Layer 2 protocol called Cube that aims to bring trust-minimized smart contracts to Bitcoin.

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️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: 31
Milestone progress: 62%

Last week’s snapshot showed 18 open issues, 29 closed, and a 63% milestone progress.

🖊️ Meeting Log

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

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective statuses:

Work-in-progress

Bitcoin/bitcoin, PR #35295—validation: fetch block input prevouts in parallel during ConnectBlock
Bitcoin/bitcoin, PR #35182—Replace libevent with our own HTTP and socket-handling implementation
Bitcoin/bitcoin, PR #35319—net: use the proxy if overriden when doing v2->v1 reconnections

Ready for review

Bitcoin/bitcoin, PR #32427—kernel: Replace leveldb-based BlockTreeDB with flat-file based store
Bitcoin/bitcoin, PR #35301—Silent Payments: Implement bip352 (take 2)
Bitcoin/bitcoin, PR #35302—Silent Payments: Sending (take 2)

Discussion Topics

Kernel Working Group (WG) Update: “sedited” shared a new branch that separates mempool/policy code from validation and, thus, from the kernel library. Though there are organizational benefits to separating this part of the Bitcoin Core software, developers discussed how there doesn’t appear to be much use for the separation beyond this.
Benchmarking WG Update: Developers discussed the design of an “automated compaction PR” that would help reduce storage usage in a Bitcoin node after an Initial Block Download (IBD). They discussed how much storage could be saved and how frequently these compactions should occur.

🌟 PR Spotlight

PR #35295

Category: Bitcoin/bitcoin, Bitcoin Core client software used to connect to Bitcoin, the network, validate blocks and transactions, and transact on-chain.

Title: “validation: fetch block input prevouts in parallel during ConnectBlock”

Author: “andrewtoth”

Status: Work in progress

Date opened: May 14, 2026

Most recent update: May 31, 2026

What it does: PR #35295 continues earlier work from PR #31132 to speed up one of the most time-consuming parts of Bitcoin block validation. When a Bitcoin node receives a new block, it must verify that every transaction in that block spends valid coins. To do this, the node repeatedly looks up information about previously created transaction outputs, known as “prevouts.”

Today, Bitcoin Core performs many of these lookups sequentially. PR #35295 and PR #31132 propose fetching this data in parallel, allowing the software to utilize multiple CPU cores more effectively during block validation.

Importantly, this does not change Bitcoin’s consensus rules or validation logic. It simply helps Bitcoin Core make better use of modern multi-core processors.

Why it matters: The performance gains from the PR are expected to be significant. Benchmarking cited in the PR shows Initial Block Download speedups ranging from 1.18x to more than 3x faster, depending on hardware, operating system, database cache size, storage type, and thread count. Worst-case block connection time on network-attached storage was also measured at more than 2x faster.

☁️ 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

Strategy sells Bitcoin for the first time since 2022

ACD After Hours: ACDC #179 🌙

Christine D. Kim — Fri, 29 May 2026 01:38:05 GMT

Good evening,

A few weeks ago, I attended the Designing DeFi conference in NYC. It was a two-day gathering of researchers, developers, and builders to discuss the latest designs in decentralized finance (DeFi) and blockchain protocols. I learned a lot from the talks, but, as is the case with most conferences, more from the discussions with attendees and presenters outside of the curated programming.

During one of the conference happy hours, I got into a conversation about issuance reduction, and I found myself saying something along the lines of, “Lido helped Ethereum staking diversity and decentralization. If not for Lido, Ethereum would be more centralized.”

It hit me then that I was essentially arguing for the benefits of centrally coordinated decentralization.

Since that conversation, I’ve started to question my underlying assumptions and more deeply consider whether the decentralization created by the efforts of a small, centralized group is as meaningful as the decentralization that results from protocol rules and incentives.

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 Consensus (ACDC) #179.

Glamsterdam Devnet Updates

Glamsterdam-Devnet-4 is broken. Developers are still investigating the root cause of the network issues.
The Lodestar and Prysm teams reported fixes actively underway for their clients.

General Glamsterdam Discussions

Ethereum Foundation (EF) Researcher Justin Traglia confirmed that the Prysm and Lighthouse clients can now handle validator deposits at a higher block gas limit of 190 million.
Developers agreed to revisit changes to the consensus layer (CL) specifications to allow clients to support validator deposits at even higher block gas limits, upwards of 350 million.
Lighthouse client developer Shane Moore flagged two open pull requests on the Beacon API, PR #580 and PR #10, and requested feedback from client teams.
Developers agreed to implement PR #793, a change to the Execution API for supporting SSZ data serialization formats. As the author of the PR, EF Geth client developer Marius van der Wijden said he would lead implementation efforts for this PR.
EF Developer Operations Engineer and Chair of the ACDC calls, Parithosh Jayanthi, said Builder API testing should be scheduled for the launch of Glamsterdam-Devnet-6, given that Glamsterdam-Devnet-5 is expected to be a re-launch of Glamsterdam-Devnet-4, focused primarily on fixing the issues from Devnet-4.
Jayanthi highlighted a new testing tool from the EF DevOps team, also called EthPandaOps, called disruptoor. It can test client behaviors under network duress, such as an extended chain reorganization.

Hegota Proposals

Lido developer “Greg k” presented Ethereum Improvement Proposal (EIP) 8148 for consideration in the Hegota upgrade.
EIP 8148 would allow validators to set a custom maximum effective balance (maxEB) threshold. This would allow validators to tailor automatic withdrawals of protocol rewards to their maxEB, instead of being forced to use the default threshold of 2,048 ETH.
Developers debated the feature’s anticipated adoption and use. Some argued that the complexity of implementing this EIP outweighs its benefits.

Glamsterdam Scoping

Developers reconfirmed that they are leaning towards removing EIP 8080 from the upgrade and keeping a simplified version of EIP 8061.
They also agreed to keep working towards scheduling EIP 8045 and EIP 7688 for a future devnet until further notice. Regarding EIP 7688 specifically, they agreed to reconsider its inclusion in the Glamsterdam upgrade once the next Glamsterdam devnet is up and running and stable.
Refer to this Google spreadsheet for an overview of the testing and inclusion status of all Glamsterdam EIPs.

Announcements

EF Coordinator Mario Havel announced that the next cohort of the Ethereum Protocol Fellowship will be starting in a few weeks. He asked that client teams share project ideas for the new cohort to work on or assist with.
Developers will be experimenting with a new time for the ACDC meetings to accommodate call participants in Australia. The new time for the next ACDC meeting on Thursday, June 11, will be three hours earlier at 11:00 UTC/7:00 EDT.

🌕 That’s all for my summary of ACDC #179. 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:

Protocol Watch

🔎 Insights

The term “decentralization” is thrown around a lot in discourse about public blockchain development and governance, and it usually means something different each time.

For today’s newsletter, I’m strictly speaking about the decentralization of actors responsible for operating and securing a public blockchain.

On Ethereum, those actors are called validators, and they each stake 32 ETH.

Ethereum staking 101

BTC Before Light: Issue 41 ☀️

Christine D. Kim — Tue, 26 May 2026 11:03:37 GMT

Good morning,

Today’s newsletter highlights efforts by Bitcoin Core developers to improve privacy on Bitcoin.

First, I discuss work on a Bitcoin Core wallet feature called Silent Payments, which would allow users to share a single reusable payment identifier while still receiving payments through unique, unlinkable on-chain addresses.

Second, I highlight work to fix an edge case in the private broadcast feature introduced in the recent Bitcoin Core v31 release. Private broadcast is designed to obscure a user’s IP address when broadcasting transactions. Developers recently discovered certain fallback behaviors in the feature that may unintentionally expose a user’s IP.

Together, these efforts highlight both the progress and challenges of building meaningful privacy protections into Bitcoin Core.

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️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: 18
Closed issues: 29
Milestone progress: 63%

Last week’s snapshot showed 17 open issues, 26 closed, and a 60% milestone progress.

🖊️ Meeting Log

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

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective statuses:

Draft

Bitcoin/bitcoin, PR #35319—net: use the proxy if overriden when doing v2->v1 reconnections

Work-in-progress

Bitcoin-core/leveldb-subtree, PR #61—Disable seek compaction
Bitcoin/bitcoin, PR #35182—Replace libevent with our own HTTP and socket-handling implementation

Ready for review

Bitcoin/bitcoin, PR #35295—validation: fetch block inputs in parallel during ConnectBlock
Bitcoin/bitcoin, PR #35301—Silent Payments: Implement bip352 (take 2) 🌟
Bitcoin/bitcoin, PR #35302—Silent Payments: Sending (take 2)
Bitcoin-core/asmap-data, PR #48—add 1776960000

Merged

Bitcoin/bitcoin, PR #34342—cli: Replace libevent usage with simple http client

Discussion Topics

Kernel Working Group (WG) Update: “sedited” shared a new release of the rust-bitcoinkernel. rust-bitcoinkernel is a wrapper around libbitcoinkernel, an experimental C++ library exposing Bitcoin Core's block and transaction validation engine.
QML GUI WG Update: “johnny9dev” said the project is on track for feedback from a wider group by the end of June. QML GUI is a new user interface for the Bitcoin Core wallet.

🌟 PR Spotlight

PR #35301

Category: Bitcoin/bitcoin, Bitcoin Core client software used to connect to Bitcoin, the network, validate blocks and transactions, and transact on-chain.

Title: “Silent Payments: Implement bip352 (take 2)”

Author: “Eunovo”

Status: Ready for review

Date opened: May 15, 2026

Most recent update: May 22, 2026

What it does: Silent Payments is a proposed Bitcoin Core wallet feature that would allow users to use a single reusable payment address without sacrificing on-chain privacy. The feature seeks to make Bitcoin payments more user-friendly and private.

Today, Bitcoin users are generally encouraged to generate a new address for every payment because address reuse makes transaction activity easier to trace publicly on-chain. While wallets already automate much of this process, repeatedly generating and sharing new payment addresses can still be cumbersome.

Silent Payments aims to simplify this experience by allowing users to publish a single reusable payment identifier that automatically generates unique destination addresses for every payment received.

To outside observers, the payments appear unrelated on-chain even though they belong to the same recipient.

Why it matters: The proposal is part of a broader multi-year effort to improve privacy within Bitcoin’s existing wallet architecture without requiring consensus changes and while minimizing additional trust assumptions.

Silent Payments was first proposed in 2022 by Bitcoin Core developer Ruben Somsen, and several attempts have since been made to implement the feature in the Bitcoin Core wallet.

However, as I’ll highlight in the next section of this newsletter, privacy features are often difficult to implement in practice. They can contain hidden edge cases and architectural complexities that only emerge through extensive iteration, testing, and real-world review.

☁️ 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

Last Thursday, Bitcoin Core developers discussed a newly discovered edge case in their latest release, Bitcoin Core v31, which introduced the “private broadcast” feature.

Private broadcast is designed to help users privately relay Bitcoin transactions over privacy networks such as Tor or I2P so that peers cannot easily identify the sender’s IP address.

However, developers discovered that under certain networking conditions, the feature may unintentionally do the exact opposite and reveal the sender’s IP address.

The issue with private broadcast

ACD After Hours: ACDE #237 🌙

Christine D. Kim — Fri, 22 May 2026 07:05:43 GMT

Good evening,

This past week, I attended the Designing DeFi conference in NYC, formerly known as TLDR. It’s an annual gathering of researchers, developers, and builders focused on decentralized finance (DeFi) and blockchain protocols.

It was a phenomenal event. The quality of both the research presented and the attendees was exceptionally high. I left the conference with several takeaways, one of which was about the utility of centrally coordinated decentralization.

I’ll have to share my takeaways from the event another week, however, as I’m aware that I should probably first address the elephant in the room. No, not the Ethereum Foundation. The bigger one. Ethereum.

Tonight, I’m sharing a sober reflection on Ethereum, its waning relevance and value, and where I see its future heading.

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) #237.

Glamsterdam Devnet Updates

Ethereum Foundation (EF) Developer Operations Engineer Barnabas Busa said that Glamsterdam-Devnet-4 will launch today, with new execution layer (EL) clients, Nethermind and Ethrex, as well as three consensus layer (CL) clients, Prysm, Lodestar, and Lighthouse.
Testing is underway for the Geth (EL) and Nimbus (CL) clients for inclusion in the Glamsterdam-Devnet-4 launch.

Glamsterdam Code Changes

Developers have finalized a clarification in Ethereum Improvement Proposal (EIP) 7928 to address an edge case involving insufficient gas.
EF Researcher Maria Silva, who has been leading the gas repricing efforts in Glamsterdam, said it is likely the EIP 7904 will no longer be needed. Silva raised the high likelihood that this EIP will be removed after further client benchmarking so that client teams and the broader Ethereum community do not spend additional resources preparing for this change.
Refer to this Google spreadsheet for an overview of the testing and inclusion status of all Glamsterdam EIPs.

Hegota Proposals

EF Researcher Wei Han proposed EIP 8188, state tiering by write age, for inclusion in Hegota. The EIP seeks to address the problem of state growth in the short term without significantly impacting the user experience, before longer-term solutions, such as state expiry, become ready.
Facet Layer-2 Co-founder Tom Lehman proposed EIP 8182, private ETH and ERC-20 transfers, for inclusion in Hegota. This EIP would enshrine a privacy pool application into the core protocol of Ethereum.
EF Researcher Peter Miller proposed EIP 4758, deactivate SELFDESTRUCT, for inclusion in Hegota. Although developers have deemed the SELFDESTRUCT opcode deprecated for several years, there are still a handful of applications on Ethereum that use the opcode. This EIP seeks to create a pathway to wholly deactivate the opcode and prevent its use.

Execution API Feedback

Independent Ethereum developer Mercy Boma Naps-Nkari requested client feedback on an open pull request for changing the fillTransaction field in the execution API.
She also requested feedback on her analysis of the JSON-RPC methods exposed by all EL clients based on the current execution API specifications.

Announcements

ACDE Call Chair Nixo Rokish said there is no closing date for Hegota proposals yet. The date will be announced a few weeks to a month in advance.
She also shared that as May 25 is a public holiday in several countries, the All Core Developers Testing (ACDT) call scheduled on that day may be cancelled. Developers can check Discord for the discussion and final decision on this.

🌕 That’s all for my summary of ACDE #237. 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:

Protocol Watch

🔎 Insights

This week, more individuals announced their departure from the Ethereum Foundation (EF).

Researchers Julian Ma and Carl Beekhuizen both shared on X that they were leaving the organization and seeking new opportunities.

The EF itself has offered little explanation for the recent string of departures, fueling speculation and concerns not only about the Foundation, but about Ethereum more broadly.

On X, some have argued that the recent departures are a healthy sign of new talent and innovation replacing old within the EF. Others see it as evidence of organizational instability, burnout, and weakening leadership at one of Ethereum’s most influential institutions.

Is the EF restructuring good for Ethereum?

Good or bad for the EF, there’s a broader debate about whether the EF restructuring is positive for Ethereum.

Ready for Merge Ep. 30 👾

Wed, 20 May 2026 16:31:33 GMT

Good afternoon,

I’m excited to share the Season 1 finale of the Ready for Merge podcast!

It’s a bi-weekly brief on Bitcoin and Ethereum development. I’m ending the season just like I started it.

I also dive into recent developments with the Clarity Act and why this bill could become one of the most important pieces of legislation yet for blockchain developers in the United States.

If you’ve been enjoying these regular updates and insights on blockchain development through the Ready for Merge podcast and want to stay informed throughout the summer while the show is on break, I encourage you to become a premium subscriber to my Substack if you haven’t already.

Subscribe now

Without further ado, let’s get into today’s brief!

Yours truly,

Christine D. Kim

Episode Summary

Christine D. Kim shares the final bi-weekly brief of Season 1 of the Ready for Merge podcast, recapping the latest developments in Bitcoin and Ethereum protocol development.

She also breaks down the latest developments surrounding the Clarity Act, a major cryptocurrency market-structure bill advancing in the U.S. Senate, highlighting its implications for open-source developers, self-custody rights, and the growing role of decentralization as a legal framework for regulating digital assets.

Finally, Christine shares how listeners can continue to follow major developments in blockchain technology throughout the summer via her newsletters and events.

This episode was recorded on May 19, 2026.

Timestamps

(1:53) Ethereum development updates

(7:55) Bitcoin development updates

(12:07) What is the Clarity Act?

(14:49) Why the Clarity Act matters

(25:05) How to stay up-to-date on blockchain development through the summer

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, please share 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 feedback by leaving a comment.

BTC Before Light: Issue 40 ☀️

Christine D. Kim — Tue, 19 May 2026 11:03:29 GMT

Good morning,

Last Thursday, I attended a Bitdevs meetup in NYC. These are monthly gatherings of Bitcoin protocol developers, researchers, and enthusiasts to discuss the latest developments in Bitcoin.

I always leave these gatherings having learned something new about Bitcoin development, and hope my All Protocol Devs meetups, loosely inspired by Bitdevs, do the same for attendees interested in general blockchain development.

At the most recent Bitdevs meetup, discussions ranged from Lightning network updates to the differences between isogeny-, hash-, and lattice-based quantum-secure cryptographic approaches, to new data analyzing the effectiveness of enabling NAT-PMP by default in the recent v30 release of Bitcoin Core.

Today, I’m diving into the effectiveness of enabling NAT-PMP by default because it highlights something important about open-source protocol development: Even when a feature has a clear theoretical motivation, its real-world impact is not always immediate or easy to measure. There are often far more social, operational, and economic variables at play than theory alone can account for.

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️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: 17
Closed issues: 26
Milestone progress: 60%

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

🖊️ Meeting Log

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

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective statuses:

Work-in-progress

Bitcoin/bitcoin, PR #35182 (Replace libevent with our own HTTP and socket-handling implementation)

Merged

Bitcoin/bitcoin, PR #35156 (dbwrapper: reuse scratch DataStream buffers)

Closed

Bitcoin/bitcoin, PR #31132 (validation: fetch block inputs on parallel threads)

Discussion Topics

Net Split Working Group (WG) Update: The goal of this project is to cleanly separate the two main components of Bitcoin Core’s peer-to-peer networking protocol, the net and net_processing layers, which are responsible for managing internet connections between nodes and protocol-specific messaging, respectively. Project lead “cfields” shared that they will be working on other projects, and that this working group should be removed from the rotation in meeting agendas until further notice.
QML GUI WG Update: There is now a project board for this WG to keep track of all outstanding PRs and issues related to building a new user interface for the Bitcoin Core wallet.
Private Broadcast WG Update: There is a Signal group chat for developers contributing to this project. For more information about the private broadcast feature in Bitcoin Core, refer to this open GitHub issue.

🌟 PR Spotlight

PR #35182

Category: Bitcoin/bitcoin, Bitcoin Core client software used to connect to Bitcoin, the network, and validate blocks and transactions

Description: Replace libevent with our own HTTP and socket-handling implementation

Author: “pinheadmz”

Status: Open, work-in-progress

Date opened: April 20, 2026

Most recent update: May 14, 2026

What it does: The PR removes “libevent,” a third-party software library for managing network connections, from Bitcoin Core’s networking stack and replaces it with Bitcoin Core’s own custom implementation for:

socket handling
event loops
HTTP serving
peer connection management

Why it matters: For years, libevent acted as an important external dependency inside Bitcoin Core. While libevent is widely used and generally considered reliable, relying on third-party software introduces trade-offs. Developers have less direct control over node behavior, debugging can become more difficult, upgrades may introduce compatibility risks, and some security assumptions depend on external maintainers outside the Bitcoin Core project itself.

By bringing this functionality directly into Bitcoin Core, developers can better tailor the networking stack to the software’s exact needs. The change also reflects a broader trend in Bitcoin Core development toward reducing unnecessary dependencies, simplifying the architecture, improving long-term maintainability, and making node behavior more deterministic and easier for developers to reason about.

☁️ 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

In the recent v30 release of Bitcoin Core, developers enabled the -natpmp=1 option by default in hopes of increasing the number of reachable Bitcoin nodes running behind residential internet service providers (ISPs).

In simple terms, the feature helps Bitcoin nodes automatically configure compatible home routers to accept inbound connections from other peers on the network. Historically, home internet setups blocked these incoming connections by default, making residential nodes harder to reach and limiting their usefulness for network connectivity and peer discovery.

The thinking behind the v30 change was relatively straightforward. If more home users could easily accept inbound connections without manually configuring their routers, more residential nodes would come online, strengthening network decentralization and improving peer bootstrapping.

Diving into the data

ACD After Hours: ACDC #178 🌙

Christine D. Kim — Fri, 15 May 2026 00:01:04 GMT

Good evening,

Tonight, instead of focusing on one main story, I’m diving into three developments shaping the Ethereum and broader crypto developer ecosystem right now:

A status update on the Clarity Act, a consequential U.S. bill impacting protocol developers and open-source blockchain development
Leadership changes at the Ethereum Foundation, the leading organization spearheading Ethereum core development
Growing concern about the sustainability of public goods funding for critical Ethereum developer tooling, such as Vyper

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 Consensus (ACDC) #178.

Glamsterdam Devnet Updates

Developers reviewed the scope of Ethereum Improvement Proposals (EIPs) for Glamsterdam-Devnet-4.
They confirmed eth/70 and eth/71 for inclusion in Glamsterdam-Devnet-4. They deferred a decision on eth/72, as the specifications for this proposal have not yet been finalized.
There are two pull requests (PRs) that require review by the execution layer (EL) client teams before inclusion in Glamsterdam-Devnet-4. They are:
- PR #5223, Raise MIN_BUILDER_WITHDRAWABILITY_DELAY to 8192 epochs
- PR #5236, Check gas limit consistency with the target
The final EL-focused Glamsterdam devnet, Bal-Devnet-7, is expected to launch next Monday, May 18. Depending on the devnet’s stability, developers agreed to reassess which EL client branches to test on Glamsterdam-Devnet-4.
Refer to this Google spreadsheet for an overview of the testing and inclusion status of all Glamsterdam EIPs.

Glamsterdam Code Changes

Regarding the proposal to cap validator deposit requests, Ethereum Foundation (EF) Developer Operations Engineer Barnabas Busa acknowledged concerns that the changes may create denial-of-service attack vectors on the EL.
Developers share initial benchmarking results implementing the proposal with the Prysm and Teku clients. They agreed to collect additional analysis from other clients and work on client-level optimizations to enable a deposit cap, rather than going with a deposit queue approach.
For background on the validator deposit requests issue, refer to last week’s ACD After Hours post.
There are two outstanding proposals to add a new data serialization format, SSZ, to the Engine API. While they both do the same thing, one proposes refactoring the Engine API with the SSZ addition. Developers leaned towards Busa’s simpler proposal, but agreed to continue discussing both.

Hegota Proposals

EF P2P Networking Engineer Sukun Tarachandani presented various changes to committee attestation broadcast specifications that would help reduce Ethereum block times from 12 to 8 seconds.
EF zkEVM Researchers Francesco Andreoli and Ignacio Hagopian presented EIP 8025, Optional Execution Proofs, for inclusion in Hegota.

🌕 That’s all for my summary of ACDC #178. 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:

Protocol Watch

🔎 Insights

Clarity Act Clears U.S. Senate Banking Committee Review

Today, the U.S. Senate Banking Committee approved the Digital Asset Market Clarity Act in a 15–9 bipartisan vote and advanced the bill to the full Senate for further review. The vote signals that the legislation still has a viable path to becoming law before the 2026 midterm elections, though additional rounds of negotiation and voting remain.

Ready for Merge Ep. 29 👾

Wed, 13 May 2026 16:31:17 GMT

Good afternoon,

I’ve saved the best for last. I’m running back the final Meet the Devs interview from my original ACD Toolkit mini-series.

This one features Nethermind developer Ben Adams and his story on how he went from being a crypto skeptic to one of the top three contributors to the Nethermind codebase.

It’s another inspiring account of the way the vision and values behind Ethereum motivated a radical career change.

Yours truly,

Christine D. Kim

Episode Summary

Meet Ben, a developer who works full-time on the Ethereum execution layer (EL) client, Nethermind. In just over two years, Ben has become one of the top three contributors to the Nethermind codebase — a remarkable leap for someone who once dismissed cryptocurrencies entirely.

In this interview, Ben recounts how he found his calling working as a full-time Ethereum client developer and the twists and turns in his journey that led him through building online games and contributing to Microsoft’s .NET ecosystem to becoming one of Nethermind’s most prolific contributors.

This interview was recorded on August 13, 2025.

Timestamps

(0:49) Show announcements

(1:23) Ben’s biggest contribution to Ethereum

(19:59) Ben’s view on Ethereum leadership

(31:50) What an average day looks like as a Nethermind developer

(39:38) Rapid fire questions

👾 Thank you for tuning in! If you liked today’s show, please share 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 feedback by leaving a comment.

BTC Before Light: Issue 39 ☀️

Christine D. Kim — Tue, 12 May 2026 11:03:42 GMT

Good morning,

Before we get into today’s topic, a quick reminder that the next All Protocol Devs meetup is this Wednesday.

If you’re a protocol developer, researcher, investor, or simply curious about the evolution of Bitcoin, Ethereum, and blockchain infrastructure more broadly, I’d love to see you there.

The event is designed to bring together people across different blockchain ecosystems for thoughtful, technical conversations on the evolution of public blockchains.

Learn more about Wednesday’s event and how to sign up here.

Now onto tonight’s story.

This Thursday, a consequential crypto policy vote will take place in Washington. The U.S. Senate Banking Committee is expected to vote on the Clarity Act, a sweeping market structure bill designed to reshape how cryptocurrencies, stablecoins, and public blockchain networks are regulated in the United States.

If the bill advances, lawmakers and industry leaders believe there is a narrow but real window for President Donald Trump to sign it into law by July 4. If it stalls, however, the odds of meaningful crypto legislation passing this year — or even before the end of the decade — drop sharply as political attention shifts toward the 2026 midterm elections.

Today, I break down why the Clarity Act matters for protocol developers, what it could change for Bitcoin and Ethereum, and why the debate over this bill is ultimately a debate about whether U.S. law will formally recognize decentralized blockchain networks as legitimate public infrastructure.

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️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: 16
Closed issues: 26
Milestone progress: 61%

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

📧 You’ve Got Mail! (& Other News)

Instead of their usual Thursday meeting over Internet Relay Chat (IRC), Bitcoin Core developers met in person last week for their annual “CoreDev” gathering. Thus, I have no meeting minutes to share this week.

While I await intel on what developers discussed at the CoreDev gathering last week, I’m bringing back an older section of this newsletter, the “You’ve Got Mail!” section, in place of my usual “Meeting Minutes”.

Here’s an overview of other online discussions that happened this past week from the Bitcoin Development Mailing List, Delving Bitcoin, and other Bitcoin discussion forums.

Olaoluwa Osuntokun, CTO of Lightning Labs, discusses low-hanging fruit for making the Bitcoin protocol quantum-safe. Osuntokun highlights that while most discussions about post-quantum Bitcoin focus on protecting wallets and signatures, Bitcoin’s encrypted network traffic is also vulnerable to attack. The piece walks through different design options for upgrading Bitcoin’s networking layer. More broadly, it highlights that preparing Bitcoin for a post-quantum world will likely happen incrementally, with networking upgrades serving as a lower-risk testing ground before tackling far more difficult consensus-level changes. (Bitcoin Development Mailing List)
Bitcoin Core contributor “0xB10C” explores whether Bitcoin nodes running behind home internet routers could connect directly to one another using a networking technique called “TCP hole punching.” The idea is still highly experimental, but developers are discussing whether this approach could improve connectivity for home users without requiring centralized infrastructure. (Delving Bitcoin)
Bitcoin Core contributor “instagibbs” explains in a new blog post how Bitcoin developers spent nearly a decade patching and redesigning Bitcoin Core’s transaction relay system to support Lightning and other Bitcoin Layer 2 protocols. The piece highlights a common pattern in open-source protocol development: When a problem is too difficult to solve directly, developers either temporarily constrain the problem or build entirely new infrastructure until a cleaner long-term solution becomes possible. (Spiral Substack)

☁️ 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

This Thursday, the U.S. Senate Banking Committee will vote on the Clarity Act and a series of proposed amendments attached to the bill.

ACD After Hours: ACDE #236 🌙

Christine D. Kim — Fri, 08 May 2026 00:01:28 GMT

Good evening,

Tonight, I’m diving into EIP 8254, a proposal to cap validator deposit requests per block on the execution layer. It’s a new EIP for consideration in Glamsterdam.

It was proposed after the Ethereum Foundation (EF) developer operations team, EthPandaOps, demonstrated that sufficiently large blocks, exceeding a 193 million block gas limit, would break constraints on the consensus layer.

The issue traces back to EIP 6110, an upgrade that dramatically improved Ethereum’s validator deposit processing system but also embedded a hard consensus-layer limit that developers did not anticipate one day needing to exceed.

Hindsight is always 20/20, but there are ways developers could improve their foresight.

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. I’ll be discussing EIP 8254 and the other important takeaways from the Ethereum Soldogn Interop event with the EthPandaOps teams at the next All Protocol Devs meetup, happening next Wednesday, April 13.

🗒️ Call Minutes

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

Glamsterdam Devnet Updates

Last week, during the Soldogn Interop, developers tested client implementations of the Glamsterdam upgrade across several devnets: Glamsterdam-Devnet-0, 1, 2, and Bal-Devnet-6.
Notably, Glamsterdam-Devnet-2 features a new Ethereum Improvement Proposal (EIP), EIP 8061, which increases the validator exit and consolidation churn. This is the only other consensus layer (CL) focused change in Glamsterdam that developers have started testing on a devnet aside from EIP 7732, also known as enshrined proposer builder separation (ePBS).
During the Soldogn Interop, developers agreed to simplify EIP 8045, another CL-focused change in Glamsterdam, and remove EIP 8080 from the scope of the upgrade. There are now only two CL-focused changes for inclusion on a Glamsterdam devnet remaining: EIP 8045 and EIP 7688.
On the execution layer (EL) side, developers are continuing to test a handful of code changes in isolation from CL changes on Bal-Devnet-6. Ethereum Foundation (EF) Developer Operations Engineer Stefan Starflinger said developers will launch one more EL-focused devnet, Bal-Devnet-7, before migrating all testing efforts over to the shared Glamsterdam devnets.
Refer to this Google spreadsheet for an overview of the testing and inclusion status of all Glamsterdam EIPs.

Scheduled for Inclusion Discussion

EF Protocol Support Lead and ACDE Call Co-Chair Nixo Rokish shared a new proposed definition for labelling EIPs as scheduled for inclusion (SFI’d).
EF Protocol Prototyping Lead Toni Wahrstätter raised concerns that the definition does not help developers prioritize which EIPs to include for testing on devnets.
EF Testing Engineer “spencer-tb” has opened a pull request on GitHub to formally update the status of nine Glamsterdam EIPs to SFI in accordance with the new proposed definition.

Glamsterdam Code Changes

In line with the new engine_getblobsv4 API method, developers have updated the description and design of EIP 8070, a non-consensus-breaking change for improving node bandwidth consumption.
Developers have not reached a consensus on the appropriate EL client behavior during a deep chain reorganization. Developers agreed to conduct further testing and simulation with clients before reaching a decision.
Developers also discussed how to work around the CL cap on validator deposits and withdrawals, which may be exceeded if they follow through with their planned increase of the block gas limit to 200 million gas post-Glamsterdam. One proposal is to cap deposits on the EL so that even at higher block gas limits, the CL cap cannot be exceeded.
Developers agreed to include EIP 8246, remove SELFDESTRUCT burn, in Glamsterdam to fix a minor edge case related to a deprecated opcode. This would help simplify and remove longstanding tech debt in the protocol.
Developers discussed ways to prevent the use of the deprecated opcode, SELFDESTRUCT, in the future. They agreed it is too late in the Glamsterdam development process to consider them for the upgrade, as such methods would require more time for planning and communication, especially with users and smart contract developers.

Hegota Proposals

Developers discussed three proposals for consideration in Hegota, the upgrade scheduled after Glamsterdam. They were: EIP 7709, EIP 8253, and account abstraction.

Miscellaneous

Ethereum developer Mercy Boma Naps Nkari requested feedback from client teams on an execution API change removing methods no longer used since Ethereum’s Merge upgrade in 2022.

🌕 That’s all for my summary of ACDE #236. 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:

Protocol Watch

🔎 Insights

Last week, a group of over 100 Ethereum protocol developers and researchers met up in Longyearbyen, Svalbard. The gathering, called the Soldogn Interop, was hosted by the Ethereum Foundation (EF).

In the Foundation’s recap of the week, they announced that meaningful progress had been made on the Glamsterdam upgrade.

Specifically, developers agreed they could more than triple transaction throughput post-Glamsterdam by increasing the block gas limit from 60 million gas to 200 million gas.

“By Friday, the three threads converged on the headline number for the week: a credible 200M post-Glamsterdam gas limit floor. This significant increase is possible because ePBS structures the slot to give execution more time, BAL optimizations give clients the throughput headroom under that structure, and 8037 ensures the higher gas limit doesn't translate into runaway state growth.”

The credibility of this 200 million gas figure was immediately thrown into question after developers who attended the interop insisted the estimate was too conservative and the likely increase would be much higher than 200 million.

Prysm client developer “Potuz,” who is leading development on one of the main scaling improvements in Glamsterdam, EIP 7732, said on X:

Nethermind client developer Ben Adams echoed this sentiment, saying:

@materkel 200M gas limit is the floor target; which implies higher 😉","username":"ben_a_adams","name":"Ben {chmark} Adams ⟠","profile_image_url":"https://pbs.substack.com/profile_images/1282411238602006529/l4lHaQHE_normal.jpg","date":"2026-05-02T14:55:55.000Z","photos":[],"quoted_tweet":{},"reply_count":1,"retweet_count":0,"like_count":10,"impression_count":901,"expanded_url":null,"video_url":null,"belowTheFold":true}" data-component-name="Twitter2ToDOM">

Contrary to the commentary on X, developers expressed concerns at the latest All Core Developers Execution (ACDE) call about exceeding a block gas limit of 193 million gas.

EF Developer Operations Engineer Barnabas Busa said:

“We could safely do 190, but, as soon as we go over 193, we are gonna have issues.”

Thus, despite the initial fanfare about a 200m block gas limit in Glamsterdam, it’s unclear what the final value will be and how soon an increase of this magnitude could be reached on mainnet.

The biggest blocker to bigger blocks

Ready for Merge Ep. 28 👾

Wed, 06 May 2026 16:30:54 GMT

Good afternoon,

This week’s Ready for Merge podcast episode is a short and sweet overview of the highlights in blockchain protocol news and developments over the past two weeks.

This may be the shortest episode I’ve recorded yet, only 15 minutes!

In it, I cover the main updates from an in-person gathering last week of Ethereum protocol developers and researchers. I also cover the disclosure of a high-severity bug in Bitcoin Core v28 and older software versions.

Finally, I dive into recent commentary on the maturation of public blockchain protocols and applications, and what really differentiates them from traditional financial applications.

Next week, I’ll be sharing my final Meet the Devs interview from my premium Substack series, the ACD Toolkit, which features an hour-long conversation with Ethereum client developer Ben Adams, who works on the Nethermind execution layer client.

Premium subscribers get early access to this interview, which they can find here:

For everyone else, stay tuned for the public release of my interview with Ben coming out next Wednesday!

Yours truly,

Christine D. Kim

Episode Summary

In this episode of Ready for Merge, Christine D. Kim shares updates from the Soldøgn Interop, a week-long gathering of Ethereum protocol developers and researchers organized by the Ethereum Foundation. She also highlights a newly disclosed high-severity bug impacting outdated versions of Bitcoin Core. She then unpacks the ongoing fallout from the KelpDAO hack and DeFi United recovery efforts. The episode closes by questioning whether crypto products like strkBTC and stablecoins truly deliver on the promise of private, permissionless money.

This episode was recorded on May 5, 2026.

Timestamps

(0:54) Show announcements

(1:29) Soldøgn Interop takeaways

(3:12) High severity bug in Bitcoin Core v28

(6:02) DeFi United fund recovery efforts

(10:50) What type of privacy strkBTC enables

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, please share 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 feedback by leaving a comment.

BTC Before Light: Issue 38 ☀️

Christine D. Kim — Tue, 05 May 2026 11:02:42 GMT

Good morning,

Next week, Starknet is launching a new Bitcoin-backed token called strkBTC. It’s marketed as a privacy solution for Bitcoin that makes no compromises on the guarantees that Bitcoin, the protocol, offers users.

Today, I’m unpacking all of the compromises in strkBTC and the Starknet Privacy Pool that enable private transfers.

Similar to how I highlighted the similarities between DeFi United and a bank bailout, strkBTC is another case study into how DeFi activity, specifically wrapped token services, in this case, is again, not that dissimilar from traditional financial services.

So, without further ado, here’s another round of a game I’m now starting to call “Protocol or financial service provider?”

Let’s get into it.

Yours truly,

Christine D. Kim

⏱️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: 15
Closed issues: 24
Milestone progress: 61%

Last week’s snapshot showed 16 open issues, 22 closed, and a milestone progress of 57%.

🖊️ Meeting Log

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

Pull Requests (PRs)

Proposed code changes to Bitcoin Core and their respective statuses:

Work-in-progress

Bitcoin-core/GUI-QML, PR #561 (Implement Addresses list in Settings screen)
Bitcoin-core/GUI-QML, PR #556 (qml: Hide wallet change outputs in activity list)
Bitcoin-core/GUI-QML, PR #554 (Implement Replace-By-Fee speed-up support in the wallet)
Bitcoin-core/GUI-QML, PR #559 (Activity search filter)
Bitcoin-core/GUI-QML, PR #558 (Add MiniBlockClock to the Navigation Bar)
Bitcoin-core/GUI-QML, PR #557 (Add PSBT import review flow)
Bitcoin-core/GUI-QML, PR #553 (Receive requests page)
Bitcoin/bitcoin, PR #35182 (Replace libevent with our own HTTP and socket-handling implementation)

Ready for review

Bitcoin/bitcoin, PR #31132 (validation: fetch block inputs on parallel threads)

Discussion Topics

Kernel Working Group Update: The Kernel project aims to separate Bitcoin’s core consensus logic from the rest of the Bitcoin Core software and make it easier for external applications to interface with consensus-critical code. Bitcoin Core contributor “sedited” shared that they are migrating the project away from an automated bindings generator toward handwritten bindings, which reduces external dependencies required to interface with the Kernel from non-C languages. The working group is also actively seeking review on a few open PRs tracked on their project board.
No IRC Meeting Next Week: Meeting chair “abubakarsadiq” announced that there will be no IRC meeting this Thursday due to an in-person “CoreDev” gathering.

🌟 PR Spotlight

PR #557

Category: Bitcoin-core/GUI-QML, Bitcoin Core’s graphical user interface wallet

Description: Add PSBT import review flow

Author: “johnny9”

Status: Open, work-in-progress

Date opened: April 25, 2026

Most recent update: April 26, 2026

What it does: This PR adds a review step in the wallet when importing a Partially Signed Bitcoin Transaction (PSBT). If the wallet can fully sign the transaction, it is routed to a Send Review screen, where users can inspect details (inputs, outputs, fees) before finalizing. PSBTs that require signatures the wallet cannot provide (e.g., multisig setups) are flagged on the interface as not supported yet. Support for multisig wallet setups will be deferred for future design work.

Why it matters: This is a small UX improvement to the Bitcoin Core wallet with an outsized impact. PSBTs are commonly used in setups involving hardware wallets or air-gapped signing. Adding a review screen reduces the risk of blindly signing malicious or incorrect transactions. Most dedicated Bitcoin wallets already include clear transaction review flows. This PR moves Bitcoin Core closer to that baseline, which is important for broader usability. The change also helps reinforce the best practice of verifying transaction details before signing, rather than treating signing as a blind action.

☁️ 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

On Tuesday, May 12, Starknet is launching a new BTC-backed token called strkBTC.

In a blog post explaining the token, Starknet wrote:

Today, Starknet introduces strkBTC: an asset designed to bring privacy to Bitcoin, without compromising the principles that made Bitcoin trustworthy in the first place.

Contrary to the description, the design of strkBTC contradicts almost all the principles that make Bitcoin trustworthy. It also raises questions about the real difference between token issuers like Starknet and traditional financial service providers such as banks and centralized exchanges.