ChainFeeds’ latest PRO issue rounds up recent work across Bitcoin protocol development, Ethereum research and governance, MEV, and new academic papers. The main items include a fresh encrypted mempool design, discussion around EIP-8141 Frame Transactions, a Lightning-based approach to a "Bitcoin dollar," and a paper on reconstructing cross-chain transaction correspondences.
A new encrypted mempool approach built around threshold IBE
Ethereum Foundation researcher Gottfried Herold outlined a new way to think about encrypted mempools, with the stated goal of lowering the cryptographic demands placed on threshold encryption.
An encrypted mempool is meant to keep transactions hidden after they enter the mempool and reveal their contents only once inclusion in a block is determined, preventing searchers from seeing them early and front-running them. Existing approaches often rely on batch threshold decryption, but Herold argues that no cryptographic system currently offers all of the desired properties at once: high efficiency, low bandwidth use, committee rotation, and post-quantum security.
His proposal removes the batch decryption requirement and instead combines threshold identity-based encryption, or threshold IBE, with a ticket mechanism similar to FOCIL.
The flow spans three blocks. A user first submits a ticket. After that ticket is included in B[n], the user sends the actual encrypted transaction, or etx, using the block hash of B[n] as the encryption identity id. Because the block hash is already fixed at that point, the user does not need to know in advance which encrypted transactions will appear later, and the committee does not need to reach consensus over a batch of ciphertexts.
Next, the PTC in ePBS checks whether it saw the corresponding etx in time, and B[n+1] records the result in etx_seen. Only after the transaction is confirmed as seen does the threshold committee release the decryption key for that block identity. Then B[n+2] executes the decrypted transactions at the top of the block in ticket order.
Using a block hash instead of a slot number has another effect: the encrypted transaction becomes tied to a specific fork, so if a reorg happens, the original encrypted transaction becomes invalid.
Herold treats the extra consensus round as a central part of the design. Builders know which encrypted transactions are eligible for later blocks before those transactions are decrypted, which means they cannot decide to include or exclude them based on the contents at the last minute. The aim is to reduce the discretion builders gain from encrypted order flow.
The trade-off is a fixed execution delay of two blocks, plus the need to handle edge cases such as deep reorgs and a decryption committee that stops releasing keys. The design also includes a circuit breaker that shuts down the encrypted mempool if decryption cannot proceed normally, so Ethereum’s dynamic liveness is not affected.
The article also notes a major limitation: there is still no threshold IBE scheme that satisfies the proposal’s requirements, especially the post-quantum security requirement. In that sense, the work is framed less as a protocol specification ready for deployment and more as an attempt to redefine what cryptographic tools an encrypted mempool actually needs.
Bitcoin protocol updates: stable channels and a "Bitcoin dollar"
On the Bitcoin side, BTCPay Server founder Nicolas Dorier explored a way to create a "Bitcoin dollar" through the Lightning Network.
Under that model, users would still hold BTC inside Lightning channels, but by continuously adjusting the expected balances between the two sides, they could keep the value of their position pegged to the U.S. dollar or another asset. Unlike stablecoins such as USDT, this setup does not involve an issuer creating a dollar-denominated liability. Instead, it uses BTC and the way risk is allocated between channel counterparties to maintain the target value.
In theory, the same structure could also be used to track stocks, asset baskets, or even derivatives, and could be used directly for cross-currency Lightning payments.
The article says the model still faces unresolved issues, including unsettled funds, price oracles, limited liquidity, and the possibility that users terminate the peg relationship when price moves in their favor. It also notes that DLCs could be considered in the future to reduce part of that risk.
The core argument is that Lightning may serve not only as a BTC transport network, but also as a non-custodial settlement layer for assets and derivatives.
Highlights from Bitcoin Optech Newsletter #423
- Mining pool vardiff adjustment: if a miner’s hash rate drops suddenly and a pool only retargets difficulty after receiving a share, the miner can remain stuck at an excessively high difficulty for a long period. The proposed fix is to lower difficulty proactively after a period with no shares.
- Utreexo initial sync optimization: a new approach uses spent UTXO data from SwiftSync to skip outputs that have already been spent during initial block download, largely removing the large amount of deletion-proof data Utreexo would otherwise need and reducing sync overhead.
- Unspendable Taproot internal key: a new BIP draft seeks to standardize a Taproot internal key with no known private key, allowing Taproot addresses that use only the script path to be generated in a uniform way across wallets and implementations.
Ethereum research: Frame Transactions and gas payment in shielded pools
In the Ethereum research section, lightclient reviewed the development of account abstraction and argued that repeatedly adding new transaction types, or relying on complex alt-mempool designs, does not scale well. The preferred direction in that piece is EIP-8141 and its Frame Transaction model.
Frame Transactions split a transaction into multiple programmable execution stages while preserving protocol-level visibility into the transaction structure. The article presents that as a way to support key rotation, gas sponsorship, separation between sender and payer, privacy pools, and programmable validation within one general framework.
Rather than designing a new transaction type for every new feature, Frame is described as a set of reusable building blocks. New capabilities could be added by composing frames and, where needed, introducing a small number of EVM opcodes or standard contracts.
The article goes on to show how Frame could support transaction expiry, privacy-pool withdrawals, transaction outcome assertions, full account balance transfers, and signature aggregation without changing the outer transaction format.
Signature aggregation receives particular attention because post-quantum signatures may reach several kilobytes in size, making aggregation important for controlling on-chain costs. The conclusion in that piece is that Frame may not be the final EVM upgrade, but it could become the last transaction type Ethereum accounts need, with most future transaction features built on top of it.
Another item comes from community member atoranzo, who is trying to remove relayer dependence from EVM shielded pools. In the EVM, gas must be paid by a transparent account with a balance. If users broadcast their own withdrawals, they may reveal their identity; if they rely on relayers, the system can drift toward centralization.
atoranzo’s proposal makes privacy notes alternate between two roles. When one user broadcasts their own transaction, they must also pay for and broadcast another user’s transaction. After that, their own note switches into the role of waiting for someone else to broadcast it. The idea is to encode mutual gas sponsorship directly into the protocol rules, without adding a separate relayer market, token, or points system.
Simulation results cited in the article show gas overhead at about 1.01x that of a normal transaction in steady state, with a median waiting time of about seven blocks. The proposal does not solve builder censorship or expand the anonymity set, and for now it exists only as a specification and simulation rather than an implementation.
Community member K1-R1 also proposed RawVentures, a concept that would automatically route part of ETH staking rewards into an on-chain venture capital fund while leaving the staked principal untouched.
In the example described, a user could direct half of their staking rewards to buy shares in a Venture Vault, and holders would then use prediction markets to decide which projects receive investment. Participants would have to stake their own fund shares on their judgments, and later project performance would determine which forecasters gain or lose shares, creating a form of long-term investment reputation.
K1-R1 estimates that if just 1% of Ethereum’s annual staking rewards entered the system, it could generate about 10,800 ETH in investment capital each year. The article adds that key mechanisms, including the prediction market structure and investment selection rules, are still at an early design stage.
MEV research roundup from Flashbots
Flashbots launched a newsletter focused on MEV research, and The MEV Letter #153 includes several notable items.
- “Frames are all you need” looks at how Frame Transactions could support transaction expiry, Privacy Pool, transaction assertions, account sweeping, and signature aggregation without adding more transaction types.
- “Mempool Account Transaction Capacity from Historical Activity (MATCHA)” proposes a local mempool admission policy that allows one account to submit multiple Frame Transactions while using historical account activity to cap capacity and reduce DoS risk.
- “From 60M to 200M: simulating Glamsterdam’s fee market” simulates how base fee and block utilization would change if gas repricing in Glamsterdam were followed by a gradual increase in the gas limit from 60M to 200M.
- “Wen fast payload broadcast? Segment, code, push, pull, and everything in between” studies whether execution payloads can be split into smaller independently verifiable pieces and propagated through push and pull methods to support larger blocks and shorter slots.
- “Commit-Boost after ePBS” examines how builder payments, bid selection, and validator configuration may change after ePBS goes live, and what role off-protocol components such as relays and Commit-Boost may still play.
- Podcast: “Credible Commitments: Ethereum & The Case For Fast Slots” features Barnabé Monnot discussing Ethlabs and its work on Quick Slots, FCR, and L1-L2 interoperability.
Paper spotlight: reconstructing cross-chain transaction correspondences
The paper titled Bridging the Opacity: Evidence-Backed Cross-Chain Transaction Correspondence Reconstruction Across Heterogeneous Blockchains studies how to recover links between cross-chain transactions when internal bridge data is unavailable.
The authors are from Sun Yat-sen University, The Hong Kong Polytechnic University, and Zhejiang University. Their system, XSplicer, analyzes protocol documentation and on-chain transaction features to match fund flows across heterogeneous chains including EVM networks, Bitcoin, and Solana.
According to the article, experiments showed an overall recovery rate of 92.5%. The system also reconstructed historical Multichain transactions and part of the cross-chain transfer path tied to funds stolen from Bybit.
That paper is one of the featured research items in this PRO issue.
