ChainFeeds Research’s PRO issue #153 surveys current work across Bitcoin protocol development, Ethereum governance and research, MEV, and recent academic papers. The issue highlights a proposed Gloas circuit breaker design, proprietary AMMs, a state-synchronization approach aimed at removing part of the oracle extractable value window, and a security warning covering several Coldcard hardware signers.
Gloas circuit breaker design narrows builder dependence in stages
Ethereum researcher Potuz has proposed a more fine-grained circuit breaker for Gloas payload markets. The idea is not to fall back straight to validator self-build whenever something breaks. Instead, the mechanism shrinks builder dependence step by step based on the source of failure and the trust level of builders, with the goal of keeping block production live while preserving as much builder-market competition as possible.
Under the design, nodes maintain builder allowlists and blocklists. Bids from blocklisted builders are rejected. Builders deemed trustworthy can still serve as a preferred fallback source even after a global circuit breaker is triggered. Potuz groups builders into anonymous participants on P2P channels, direct builders that are not sufficiently trusted, and trusted direct builders that carry reputation and commercial constraints. In attack or failure scenarios, trusted builders are treated as a more reasonable intermediate downgrade layer than switching immediately to self-build.
The proposal targets three main cases. The first is when a builder or relay wins an auction but fails to deliver a payload, something the report describes as an important historical source of missing payloads. In that case, the relevant builder or relay should be isolated quickly. The second is when a client bug prevents normal block production. Potuz argues that such failures should not be blamed on builders by default, and that the circuit breaker should focus on whether a beacon block that has already reached consensus successfully obtains a payload. The third is an attack in which untrusted builders flood the network with invalid winning bids. Nodes would first stop accepting P2P bids and rely only on trusted builders. If that layer cannot restore service, the fallback becomes self-build.
For builder management, Potuz suggests progressive penalties. A single failure could trigger a short blocklist period, repeated consecutive failures could escalate to a long-term ban, and failure counters could reset if a builder resumes normal payload delivery over a defined period. The system would also watch the number of banned builders to judge whether a broader systemic fault is underway. If several untrusted builders are banned, nodes can still move to trusted builders. Only when many builders fail at once would the design move to self-build.
The stated value of the approach is that a single builder failure could be contained to very few blocks, while larger attacks are pushed into a trusted-builder fallback layer, avoiding coarse missed-slot rules that unnecessarily force the whole builder market to exit.
Bitcoin protocol updates
Coldcard warning covers weak seed generation on several devices
The issue says multiple Coldcard hardware signers were affected by a random number generator flaw that could produce seed phrases with insufficient randomness. That raises the risk that the seeds could be brute-forced or accidentally collide, putting funds at risk.
The affected range includes Mk3 firmware versions 4.0.1 through 4.1.9, as well as Mk4, Mk5, and Q devices, including Edge versions, prior to patched releases. For Mk4, Mk5, and Q, the generated seed phrases reportedly had only about 72 bits of entropy, versus an expected 128 bits. The report stresses that updating firmware alone does not repair old seeds. Users need to generate a new secure wallet and move funds.
An exception applies where users entered enough independent private dice rolls during seed creation via Add Dice Rolls. More than 50 rolls can provide at least 128 bits of entropy, and more than 99 rolls roughly 256 bits, according to the report. If the number of rolls is uncertain, the dice record was exposed, or the count was below 50, migration is still recommended. A strong and unique BIP-39 passphrase can add one layer of protection, but a device PIN does not solve a low-entropy seed problem.
The report recommends first upgrading to the relevant patched firmware, then generating and verifying a new seed phrase, backups, wallet fingerprint, and receiving addresses. It suggests sending a small test amount first, moving the full balance only after confirmation, and retaining old backups until the migration is complete. Users are also urged to verify addresses and backups carefully during the process.
Bitcoin Optech #416 details two Core Lightning denial-of-service bugs
Bitcoin Optech Newsletter #416 disclosed two vulnerabilities in Core Lightning that could exhaust node memory and crash a node. Both were tied to communication between the gossipd and connectd modules.
The first bug allowed an attacker to send a large number of messages and make an internal message queue grow without bound. The fix set a cap of 500,000 messages and drops anything beyond that. The second bug allowed memory to be consumed continuously by forging many short channel IDs, or SCIDs. The project fixed that issue by improving garbage collection.
zkPoH proof-of-concept aims to prove holdings of at least 1 BTC
fabohax proposed a zkPoH, or zero-knowledge proof of holdings, prototype. It lets a user prove that the total value of UTXOs they control is at least 1 BTC without revealing which UTXOs they are, the balance of each one, or other onchain details. The setup uses a UTXO snapshot, a Merkle tree, and a Noir zero-knowledge proving circuit to verify the aggregate amount.
Ethereum research and development
PropAMM sits between traditional AMMs and RFQ systems
Ethereum Foundation researchers Mike Neuder and Maryam Bahrani describe proprietary AMMs, or PropAMMs, as a model that sits between conventional AMMs and request-for-quote systems.
In the report’s framing, traditional AMMs leave liquidity providers passively taking flow, exposing them to LVR, while users may also face sandwiching. RFQ systems let professional market makers offer customized offchain quotes, often producing better pricing, but the matching logic and liquidity are less transparent and they lack onchain composability. Aggregators route between AMMs, RFQ venues, and other liquidity sources to seek the best execution.
The key feature of a PropAMM is that market makers actively and frequently update pricing parameters in an onchain contract, while the swap itself is still executed onchain by smart contracts. That preserves onchain settlement and composability while allowing professional firms to manage capital with pricing closer to real-time markets.
The report points to Solana as an example where this model can work because quote-update transactions are cheap and blocks are short. Market makers can keep refreshing state while paying relatively high unit compute-resource fees, and aggregators such as Jupiter can route order flow toward pools that show good quoting and execution performance.
That design, though, depends on block producers being willing to prioritize quote updates. A purely profit-maximizing proposer may instead censor updates and auction off the right to arbitrage stale prices at the end of the slot. Ethereum’s proposer-builder separation strengthens that incentive because builders tend to maximize total block value. The report says builders including Titan and Quasar currently help market makers preserve updates through private arrangements, but that ties better execution to a small set of trusted builders and may deepen block-building concentration. Mike Neuder and Maryam Bahrani argue that FOCIL can only mitigate part of the issue. A more complete answer would be same-slot, top-of-block censorship resistance or protocol-level application-controlled execution.
Jay Kim models a way to remove part of the OEV window
Oraclizer CPTO Jay Kim discusses a mechanism-level path to eliminate part of oracle extractable value, or OEV. He frames the problem as one of structure and timing. Oracle price updates onchain are discrete events. Once a new price is visible, liquidations, rebalancing actions, and other price-dependent actions usually happen in later independent transactions. That creates an internal frontrunning window in which the update is visible but its consequences are not yet committed.
Kim separates two related risks. One is the pre-update window in which attackers can predict an update from thresholds or heartbeat patterns. The other is a cross-domain window caused when the same fact reaches different chains at different times. Standard OEV auctions may sell the right to capture that value and return proceeds to a protocol, but they leave the window in place and do not cover prediction before an update or cross-chain signaling gaps.
His alternative is not to redistribute the window. It is to bind a state update and specified consequences into one cross-domain atomic state transition. The update, the lock, and the writes across all related chains must either succeed together or all revert. In his Isabelle/HOL model, that means there is no reachable state where the new state is public while the bound actions remain uncommitted. There is no standalone update event that can be backrun, and no future update that can be predicted and consumed independently.
The scope is narrower than a blanket solution. The elimination applies only to timing value created by the update structure for actions included in the binding. It does not remove prior knowledge of the underlying real-world fact, does not cover consumers left outside synchronization, and does not rule out risks that reappear at system boundaries. The report also notes that the model does not prove a real deployment will automatically inherit the same properties. Partial synchronization, update frequency and cost, and residual extraction at composability boundaries remain open questions.
Native randomness with looser guarantees for game flows
acheron, a developer on Asphodel and Prologue, outlined a more pragmatic randomness path for onchain games, one that accepts weaker safety guarantees. Prologue’s minting, training, and PvP flows need to finish within one to two blocks, so they cannot tolerate the wait implied by EIP-4399 guidance for higher-value applications, which suggests commit-and-reveal around four epochs in advance. As a result, acheron uses Ethereum’s native prevrandao or RANDAO as the randomness source instead of an external VRF, and adds player- or server-supplied commit-reveal secrets in adversarial multi-party flows.
A key piece is EIP-2935, which stores historical block hashes in the state layer. A caller submits the RLP header for the target block, the contract verifies authenticity through the header hash, and then reads the mixHash as the random seed. That extends a direct read window from only the current block to about 8,191 blocks, or roughly 27 hours, with a cost of about 15,000 gas. The report says this addresses the production problem of having to settle exactly in a given block, not the cryptographic strength of the randomness itself.
The main tradeoff is proposer withholding bias. After seeing the outcome generated by a random value they contributed, a proposer can give up the block reward and let the next proposer try again. The cost of a single bias attempt is roughly the size of the block reward. If an attacker controls k consecutive slots, they can choose from 2^k candidate outcomes, with value growing faster than cost. The report says the tactic may become more economical than paying for repeated rerolls only at around seven consecutive slots, while the frequency with which large stakers obtain that kind of run remains low. The conclusion is not that the setup is risk-free. It is that the economic risk boundary may be acceptable for low-value, experience-sensitive game features. More complex attacks, including selfish mixing and RANDAO forks, remain under study.
Selected items from MEV research
ChainFeeds also excerpts several entries from Flashbots’ research-focused newsletter, The MEV Letter #148.
- Uniform-Loss Automated Market Making for Prediction Markets, by Ciamac C. Moallemi, Dan Robinson, and Brian Zhu, examines a uniform-LVR AMM design for binary prediction markets and proposes a mechanism that makes liquidity-provider losses more even across prices while controlling their time distribution.
- Who should write the rules of block building? BuilderNet as a policy test case, by Mikołaj Barczentewicz, studies how BuilderNet can use TEEs to enforce public block-building rules, including proofs, refunds, priority updates, and regulatory implications.
- Reveal, Correct, Then Pay: Encrypted Mempools and Perpetual Funding Security, by Benjamin Marsh, looks at how encrypted mempools may worsen perpetual funding-rate manipulation through delayed arbitrage and price adjustment, and proposes funding rules that account for decryption timing.
- How ePBS Changes Builder Selection, by Terence Tsao, explains how ePBS brings builder selection into the protocol through native bids, builder-specific preferences, and authenticated requests.
- Lean Ethereum: the biggest overhaul of Ethereum since The Merge, by OAK Research, outlines a three-layer protocol overhaul in Lean Ethereum and the L1 Strawmap, replacing BLS, KZG, and repeated execution with hash-based proofs across consensus, data, and execution.
- The podcast The Manipulation of 5min BTC Price on Polymarket, from Indexed Podcast with Ruizhe Jia, discusses the paper Settlement Manipulation in Prediction Markets and the risk that traders could influence the underlying price to manipulate settlement in very short-duration oracle-settled prediction markets.
- The podcast Can Ethlabs Make Ethereum The Root Of Global Finance?, from The Milk Road Show with Ansgar Dietrichs, Barnabé Monnot, and Julian Ma, covers Ethlabs’ mission to drive the next phase of Ethereum adoption through core R&D, new infrastructure, and product work.
- The video All Core Devs - Consensus (ACDC) #183, July 23 2026, hosted by parithosh, covers Glamsterdam devnet progress, follow-up work, and non-headline EIPs in Hegotá. The agenda was published by nixo.eth, with notes by Yash Kamal Chaturvedi.
Paper says transaction simulation can itself become a phishing vector
In the paper section, ChainFeeds highlights Blockchain Transaction Simulation Phishing by authors from Stevens Institute of Technology, Rutgers University, The Hong Kong Polytechnic University, and Singapore Management University.
The paper argues that wallet transaction simulation can itself become a phishing surface. Attackers can make the simulated result appear harmless or profitable, then rely on changes in onchain state so that the real execution follows a fund-stealing path instead. The authors also present a bytecode-level detection system called SimGuard. According to the report, it identified more than 4,000 related contracts, more than 5,700 victims, and about $3.48 million in losses across Ethereum, BSC, Avalanche, and Polygon. The paper says wallets need stronger defenses against the gap between simulation and execution.
The issue was published by ChainFeeds Research under the byline 0xNatalie on Aug. 3, 2026.