ChainFeeds Research used PRO issue #154 to spotlight a set of research topics spanning Bitcoin protocol work, Ethereum governance-related discussion, newer technical proposals, and recent academic papers.
Ethereum fee market research after Glamsterdam
One of the main items in the report is Fei Wu’s study of how Ethereum’s fee market could change after the Glamsterdam upgrade. In the framework discussed in the piece, EIP-8037 and EIP-7999 would move gas accounting away from a single pricing model and toward separate pricing for execution, data, and state creation.
Using historical gas-change data, Fei Wu built demand curves for the different resource types, measured how sensitive each one is to price changes, and simulated fee equilibrium under the Glamsterdam mechanism.
The study finds clear differences in elasticity across resource classes. Execution is the least price-sensitive, data falls in the middle, and state creation is the most sensitive to price changes. Under the new charging rules, the same onchain activity would produce more metered gas, with the biggest increase showing up in state creation.
The model also shows that under lower gas limits, execution and data would still determine the base fee. Once block capacity rises past a certain point, though, state creation could become the bottleneck and take over as the main driver of fee changes.
Fei Wu argues that a resource-level demand model gives a more accurate way to estimate price moves and capacity effects in a multi-dimensional gas market. The report says this could offer a data foundation for future fully independent resource-pricing systems such as EIP-7999. It also notes a limitation: the sharp rise in state demand in high-capacity settings depends on model extrapolation, and the real outcome would depend on whether demand for state creation keeps growing.
Bitcoin protocol updates
HTLC timeout design without mempool monitoring
The Bitcoin section covers work by community member josh on the security risks created when Lightning Network HTLCs rely on local mempool monitoring for preimages. The proposal explored in the report is a new HTLC design that does not depend on the free-relay assumption.
Josh proposes changing Bitcoin consensus rules so that specific bits in nSequence enforce a minimum nLockTime, together with optional OP_CSV and OP_LOCKTIME changes. The idea is to monitor HTLCs through confirmed onchain state instead of a node’s local mempool.
According to the report, that approach lowers the operating assumptions placed on Lightning nodes, improves security for low-bandwidth nodes and nodes without mempool access, and avoids risks tied to replacement-cycle attacks. The tradeoff is explicit: HTLC duration, fees, and liquidity costs would all rise. Even so, the study says the design could remove the need for preimage monitoring, improve routing-node reliability, and provide a workable path for safer HTLC forwarding without mempool dependence.
The report cites Bitcoin Optech Newsletter #417 for this item.
staletip proposal for stale-block visibility
The newsletter also reviews a proposal on expired chain-tip forwarding. At present, Bitcoin’s stale block rate is hard to monitor accurately because once the main chain wins, blocks on losing forks usually stop propagating. That leaves the network without complete data.
The report says changes in stale-block rate can reflect network delay, validation bottlenecks, network partition, or selfish mining. To improve visibility, Ram and w0xlt proposed a new P2P message type called staletip. It would let nodes broadcast information about recently invalidated forks to peers, including fork height, related block headers, and whether the node is willing to provide block data.
The mechanism would be enabled through node negotiation. Its purpose is to make stale-block conditions easier to observe across the network and improve monitoring and fault analysis for Bitcoin.
Ethereum research and development
Questioning two assumptions in PoS and oracle design
Community member Hudu Yusuf presented two security analyses that challenge common assumptions in blockchain consensus and oracle design. The two assumptions identified in the report are that stake weight is equivalent to effective consensus weight, and that continuous oracle output is preferable to temporary silence.
For proof-of-stake systems, Hudu Yusuf introduces the idea of coordination collapse. The argument is that systems leaning too heavily on raw stake totals may ignore behavioral correlation among validators. Highly aligned validator behavior, in this framework, can mean the group contributes less real security than its visible stake would suggest.
To address that, the proposal introduces DW-BFT, or diversity-weighted BFT, which adjusts voting power according to validator behavioral independence and reduces the influence of highly correlated validator groups on consensus outcomes.
On the oracle side, the paper examines the risks of always publishing data. In cases of price manipulation or abnormal inputs, the report says incorrect data can be more damaging than temporarily missing data. That leads to a structured silence model, where an oracle can enter a recognizable paused state when it cannot guarantee data reliability, instead of being forced to publish data that attackers may exploit.
The research outlines two optimization directions: adding behavior-diversity-based weighting at the blockchain consensus layer to improve resistance to validator concentration and coordinated attacks, and treating no data output as a valid state in DeFi oracle design to improve protocol safety under uncertainty and data attacks.
Arcanum targets source-code privacy at the compiler layer
The issue also includes Arcanum, a compiler-layer proposal from community member Sidistr aimed at code privacy. The goal is to keep source code itself hidden while preserving executable and verifiable behavior.
Sidistr’s argument is that existing zero-knowledge tools mainly address whether a program was executed correctly. Arcanum focuses on a different question: whether the logic of the program itself can remain permanently hidden.
The design follows a roadmap from trusted hardware to zero-knowledge systems. In the first stage, it uses TEEs such as Intel SGX, AMD SEV, and ARM TrustZone to seal compiled code inside hardware-isolated environments, so even the server operator cannot read the source. In the second stage, once ZK compilers mature, the code would be converted into STARK-based arithmetic circuits, replacing hardware trust with cryptographic guarantees that keep the source invisible.
The report distinguishes this approach from tools such as zkLLVM, RISC Zero, and SP1, which focus on proving execution correctness. Arcanum is framed instead around confidentiality of the code itself.
Paper on contentious Bitcoin soft forks
The paper section features Quantifying Bitcoin Network Resilience Through Critical Scenario Discovery: A Dual-Layer Framework for Discovering Contentious Fork Conditions in Decentralized Consensus from researchers at Old Dominion University.
The study examines which factors determine whether a contentious Bitcoin soft fork leads to a smooth upgrade or a prolonged chain split. It simulates a large number of scenarios and analyzes economic support ratios, mining-pool positions, hash-power distribution, and the difficulty adjustment mechanism.
The reported result is that the decisive factor is not hash-power advantage on its own, but the degree of economic support behind competing chains. Hash power and economic adoption, the paper says, each shape the consensus outcome in different ways.