ChainFeeds Research’s latest PRO issue centers on Ethereum’s Hegotá upgrade, Bitcoin protocol developments, BAL pricing under EIP-7999, and several new research papers across Ethereum, cross-chain design, MEV, and Solana.
Ethlabs sets priorities for Hegotá
Ethlabs reviewed the Ethereum Improvement Proposals it sees as worth prioritizing for the Hegotá upgrade and rated them by importance and maturity. Its view is that Hegotá should not try to bundle in a large number of new features at once. Instead, it should concentrate on a handful of issues with the clearest link to Ethereum’s long-term competitiveness: stronger censorship resistance, shorter block confirmation times, native account abstraction, and continued scaling gains for layer 1 and blobs.
Ethlabs places the greatest weight on FOCIL and Quick Slots. FOCIL would have a set of validators jointly provide an inclusion list, reducing the ability of a single block proposer or builder to censor transactions and strengthening neutrality at the protocol layer. Quick Slots aims to shorten the current 12-second slot, giving users faster confirmations while cutting on-chain price lag and the arbitrage room that comes with it, and preparing the way for 6-second or even shorter slots later on.
In Ethlabs’ framing, those two proposals line up with Ethereum’s most direct improvement paths: better censorship resistance and lower latency.
On user experience, Ethlabs backs Native Account Abstraction, with EIP-8141 Frame Transactions singled out as an important piece. The proposal would bring smart-account functionality into the Ethereum protocol itself, allowing accounts to support passkeys, sponsored gas, ERC-20 fee payments, batched transactions, and more flexible signing methods natively. The stated goal is to move Ethereum accounts away from the limits of the traditional externally owned account, or EOA, and closer to the experience of a mainstream internet account.
On scaling, Ethlabs argues the main focus should not be a simple gas-limit increase. It points first to resource-pricing and data-propagation bottlenecks. The issue mentions mechanisms such as a Block Access List and gas repricing so that gas use more accurately reflects the computation, state, and bandwidth costs borne by nodes, creating a safer base for future gas-limit increases and parallel execution.
Bitcoin protocol developments
SegWit commitments for post-quantum witness data
Author sipa examined how Bitcoin might accommodate much larger post-quantum cryptography, or PQC, signatures and public keys if such schemes are adopted at scale. One obvious approach would be to create a separate data area for PQ data, similar to SegWit, but that would bring in a new transaction identifier, new block commitments, and new P2P relay logic. Nodes could end up tracking txid, wtxid, and a new PQ transaction ID at the same time, adding complexity across the protocol and mining stack.
sipa proposes a different route: place the commitment to PQ data directly inside the existing witness for the corresponding input, allowing the current wtxid to keep committing to all data that affects transaction validity. That would let wtxid remain the sole witness transaction identifier and reduce the amount of infrastructure that needs to change.
In the more detailed design, sipa suggests adding a witness data type to each transaction input. Type 0 would represent current SegWit data, type 1 could represent PQ data, and new types could be added later. Different types could have their own P2P transport rules and weight-pricing rules, which would let large post-quantum signatures receive a discount scheme different from ordinary witness data.
For older nodes that do not support a given new witness type, the full data could be folded into a hash commitment and still relayed, preserving backward compatibility. In effect, the proposal would not jam a separate PQ data structure into Bitcoin transactions. It would extend SegWit into a general framework that can support multiple witness types, leaving room for post-quantum signatures while trying to avoid another transaction ID and another round of complex compatibility work.
This section cites Bitcoin Optech Newsletter #419.
Reorg attack risk in LND channel closures
Bastien Teinturier disclosed a vulnerability affecting versions of LND before 0.20.0. According to the summary, after cooperatively closing a Lightning channel, a node would delete its local channel state after waiting for only one on-chain confirmation. If a blockchain reorganization followed, an attacker could rebroadcast an old revoked commitment transaction.
Because the victim node had already forgotten the channel, it could no longer broadcast the penalty transaction. In theory, the attacker could steal all funds in the channel.
rawtr() output descriptor moves toward a formal BIP
Jean Pablo proposed creating a formal BIP for the rawtr() output script descriptor, which Bitcoin Core has supported for years. rawtr() can describe a P2TR output directly from a Taproot output public key, without needing to know the internal key or script tree, and without applying the BIP341 Taproot tweak to that public key again.
The issue says this is especially useful in cases where only the final output key is known and the internal Taproot structure is not.
Ethereum research and progress
Data metering, BAL decomposition, and bundle pricing under EIP-7999
Researcher Fei Wu analyzed how the Block-Level Access List, or BAL, should be measured and priced in the multidimensional fee market proposed under EIP-7999. The central conclusion is that BAL should not be treated as a standalone data resource with its own independent demand, because it is fundamentally a byproduct generated automatically by the protocol during transaction execution and account and storage access.
Using data from February through May 2026, the author estimates that each block generates about 120 kB of runtime BAL on average, equal to about 1.92 million data gas and roughly 47.4% of total data gas. Of that amount, only 11.4% comes directly from state creation, while the remaining 88.6% is driven mainly by execution and state-access activity.
Fei Wu therefore argues that BAL’s data cost should be folded into the price of the execution or state activity that produces it, rather than assigned its own demand curve. Under that structure, a higher data base fee would also raise the cost of transactions that access large amounts of state and generate more BAL, which would then feed back into lower execution demand. The result is a link across execution, state, and data as three resources in the fee market.
Simulation results show limited impact when data fees are low, but a clear reduction in total data demand as the data fee rises. At 5 gwei, for example, the model that includes this feedback reduces data demand by about 12.8% compared with a model that does not. The issue says that provides a basis for setting resource targets and equilibrium fees in later EIP-7999 design work.
Timing the head in Ethereum PoS
Researcher Yolodannn studied head-vote timing in Ethereum proof-of-stake and said proposers can influence the chain head that validators see at attestation time by delaying block publication.
In the head-vote timing game, some honest validators keep voting for the parent block and lose rewards. A more aggressive K-block attack could build up fork-choice weight by withholding blocks across multiple steps and eventually trigger a chain reorganization. Because the protocol has a hard time separating malicious delay from ordinary network delay, the problem is difficult to solve with slashing or similar penalties.
Experiments with Prysm showed that the head-vote timing game can reduce honest validators’ total rewards by about 15.06% on average. To reduce that effect, Yolodannn proposes a distance-weighted head reward. Under that approach, validators who do not vote for the latest head could still receive partial rewards if they voted for a nearby ancestor on the canonical chain.
The proposal does not change HLMD-GHOST or proposer boost. It only adjusts the reward mechanism. In the reported experiments, average losses fell from 15.06% to 4.71%, reducing the impact of timing differences on honest validators’ returns.
BTCP Zero-Bridge cross-chain exchange design
Researcher Hudu yusuf proposed BTCP, short for Behavioral Transaction Continuity Protocol, as a cross-chain exchange mechanism that does not require a bridge. Assets remain on their native chains at all times, are not locked into a cross-chain bridge, and are not turned into wrapped assets.
BTCP uses a cross-chain identity marker called BEO to confirm that addresses on two chains are controlled by the same entity, matches complementary trading intents, and then releases escrowed funds independently on each chain. The author argues that this structure avoids bridge-contract exploits, wrapped-asset depegs, and relay failures by design, while reducing delay from the traditional sequential wait of T_A + T_B to the parallel wait of max(T_A, T_B).
For implementation, BTCP introduces a routing score based on factors including liquidity, gas cost, finality, and cross-chain consistency, and uses what the paper calls diversity-weighted BFT to coordinate releases on the two chains. If consensus fails or times out, funds return to their original owners.
The protocol also includes multiple routing modes, including Netting, Parallel, and Intent Aggregation, to fit different liquidity profiles and trade sizes.
MEV-related highlights
ChainFeeds also excerpted highlights from The MEV Letter #150, a newsletter launched by the Flashbots team with a specific focus on MEV research:
- “FRP-52: Trusted SILOs: Side-channel Isolated Logic Oases” examines side-channel and fault-injection attacks against TEEs and secure chips, and proposes defenses that the summary says can be integrated into ASIC design workflows.
- The paper “Slow and Steady: Preventing MEV with Verifiable Delays” looks at using verifiable delay functions, or VDFs, to resist front-running attacks in distributed ledgers.
- “Calculus running on fumes” analyzes an arbitrage bot running on Arbitrum, covering how it detects liquidity-pool prices, evaluates whether an arbitrage route is profitable, and filters which opportunities are worth executing.
- “ERC-4337 : Final, Not Finishe” revisits how ERC-4337 evolved from an initial smart-account concept into shared infrastructure for sponsored transactions, embedded accounts, and related use cases, and compares the current form of ERC-4337 with the original smart-account vision.
- “A Non-Monetary Argument for the Necessity of Bounded Issuance” argues that a higher ETH staking rate may weaken the deterrent force of slashing and reduce the effectiveness of Ethereum’s broader consensus security guarantees.
- “Correlated Pairs: How AMMs Win the Biggest Markets” sketches a path for AMMs into tokenized financial markets, arguing that AMMs may have a distinct advantage over traditional market makers in asset pairs with highly correlated prices.
- The event “Community Call 4” introduced the operating mechanisms of Fynd, Turbine, and Tycho, and invited Jay Cooper to discuss propAMM data from Titan Builder.
- The livestream “LIVE : The Ethereum EIP-8363 Debate” featured Jérôme de Tychey and Mike Silagadze discussing EIP-8363, a proposal that would adjust ETH’s issuance curve by partially burning validator rewards.
- “All Core Devs - Execution (ACDE) #243” covered the launch of the Platåberget testnet, gas repricing, and several non-headliner proposals in the Hegotá upgrade.
Paper: early prediction of rug-pull memecoins on Solana
The paper “Catching the Rug: Early Prediction of Fraudulent Memecoins on Solana via Machine Learning” is credited to researchers from the Higher School of Economics, Moscow State University, and the Skolkovo Institute of Science and Technology.
The authors studied rug-pull risk in Solana memecoins using data on about 6.4 million tokens collected over seven months. They found that most suspicious tokens show rug-pull characteristics within one hour of launch, with risk driven mainly by liquidity manipulation and market behavior.
The study says machine-learning models such as XGBoost can identify potential rug pulls with reasonable accuracy using only the first five minutes of trading data after a token launch. It also says that combining PumpFun and Raydium data improves the stability of detection.
