ChainFeeds Research’s latest PRO issue focuses on Ethereum public mempool concurrency, gas sponsorship, and faster execution-payload propagation, while also covering Bitcoin signing devices, privacy tools, MEV, and a new paper on trading-policy auditing.
MATCHA links mempool concurrency to past paid activity
Ethereum researcher soispoke.eth introduced MATCHA, short for Mempool Account Transaction Capacity from Historical Activity, as a way to address a problem created by Frame Transactions and independent nonces: how one sender can safely keep multiple transactions pending in the public mempool at the same time.
EIP-8250’s keyed nonces allow one address to use several independent nonces in parallel. That matters for privacy applications, where many users may share the same address. But removing concurrency limits outright would let an attacker submit a large number of transactions that depend on the same validation state, then invalidate them all with a single state change. The cost to the attacker stays low; the validation and cleanup work pushed onto the network does not.
MATCHA introduces a sender-specific mempool capacity called width. The first transaction does not consume width. Each additional pending transaction does, and width can only accumulate gradually based on the gas that address has actually consumed in finalized blocks. Once an extra transaction enters the mempool, the width it uses is burned permanently. It is not restored if the transaction later becomes invalid, expires, or gets caught in a reorg.
That design ties repeated mempool abuse to real onchain cost. An attacker who wants to keep generating large batches of invalid transactions would first need to rebuild capacity through genuine onchain activity.
The proposal also looks at the risk that a shared address could be clogged by low-fee spam. FOCIL could raise the chance that those transactions get included and actually pay gas. Clients could also raise attack costs with tools such as minimum lifetimes and dynamic priority fees. Even so, the write-up treats those as secondary defenses. Width, together with client-wide resource limits, remains the actual DoS boundary.
In that sense, MATCHA is not simply about allowing more account-level parallelism. It is presented as a Sybil- and DoS-resistance mechanism for a public mempool that may need to support Frame Transactions, privacy accounts, and native account abstraction at the same time.
Bitcoin protocol updates
Open-source signing-device teams move toward shared maintenance
In a piece titled “DIY signing device revolution has only just begun,” SeedSigner developer kdmukai described the first joint developer summit held by the teams behind Specter DIY, SeedSigner, and Krux, three open-source Bitcoin signing-device projects.
The projects differ in hardware choices and product design, but all rely heavily on the embit library created by Stepan Snigirev. As the original author gradually steps back from development, one concrete result of the meeting was a push for the three teams to share responsibility for maintaining embit, moving this piece of core infrastructure away from a single-maintainer model.
The summit also pointed to deeper technical sharing. Specter DIY’s secure bootloader, SeedSigner’s UX experience, and Krux’s work on advanced multisig and inheritance setups could increasingly be absorbed by the other projects. The report says these teams may eventually converge on a common base layer of software and hardware components while still keeping distinct products and interfaces.
Bitcoin Optech Newsletter #422 highlights privacy and client-side scanning
On the Babilonia privacy protocol, Adam Gibson proposed a design that hides CoinJoin as what looks like an ordinary onchain bet. Alice and Bob use adaptor signatures to build a transaction that resembles a random wager and redistributes funds between them. From the outside, the structure looks closer to a normal payment than a conventional CoinJoin. The goal is to weaken the common-input-ownership heuristic without changing the expected value of the assets involved.
On Silent Payments light-client improvements, Rob Segers compared BlindBit Oracle v2 with approaches such as BIP158 Compact Block Filters. The new BlindBit Oracle sends clients the data directly needed for Silent Payments scanning. That raises download volume, but it avoids false positives and removes the need to fetch an entire block after a filter match.
The approach also creates commitments for each block’s tweak set and publishes checkpoints periodically, reducing the risk that a server can deliberately omit data without accountability.
Ethereum research and progress
Segmented broadcasts could cut payload propagation delays
Researcher cskiraly examined how execution payloads could move faster across the P2P network as gas limits rise and slot times fall, in a post titled “Wen fast payload broadcast? Segment, code, push, pull, and everything in between.”
Today, a node typically needs to receive and validate an entire payload before forwarding it. That means every hop adds another full data-transfer delay. With smaller payloads, the issue is muted. It becomes more serious if payloads approach 1 MiB or if slots shrink to 6 seconds or less.
The proposed fix is to split a payload into fixed-size segments and use a Merkle commitment so nodes can verify each segment independently. A node can then forward what it has already received to the next peer without waiting for the full payload download to finish. Propagation becomes pipelined instead of strictly sequential.
In testing, the median full-receipt time for a 1 MiB payload fell from about 4.9 seconds to 0.73 seconds. Repeated data transmission across the network also dropped noticeably.
The report says this becomes even more relevant after ePBS and Gloas, when execution payloads will have their own propagation and confirmation deadlines. In cskiraly’s view, if Ethereum keeps pushing gas limits higher and slot times lower, payload networking will need work in advance. Segmented broadcast could ease the protocol’s dependence on high-speed datacenter-style networking and support future scaling on a more stable footing.
Public-mempool gas sponsorship still needs escrow, bond, or trust
Developer Daniil Ankushin revisited a core account-abstraction question: can a smart contract pay gas on behalf of a user, let the transaction spread through a permissionless public mempool, and do so without requiring the sponsor to lock funds in advance or rely on offchain trust?
His answer is no. The three conditions cannot hold at once. Before a transaction ever lands onchain, nodes already spend CPU and state-read resources to validate it. If the transaction never gets included, those network costs are gone for good. That gives an attacker room to create cheap sponsor identities at scale and flood the mempool with transactions that will never actually pay gas.
Under that framing, any workable gas-sponsorship design must force the attacker to commit some resource that cannot be copied without limit: each submission has to impose a real cost, or the sponsor must pre-lock or hold slashable funds, or the system has to depend on a trusted offchain intermediary. A historical proof that a sponsor once had a balance is not enough, because the same balance can be promised to multiple pending transactions at the same time.
That, the report says, is why proposals such as EIP-8141 need real-time sponsor-balance reservations during the mempool stage. The constraint is not presented as a weakness in one specific account-abstraction design. It is an economic property of permissionless public mempools: if a third party pays on behalf of users, some form of escrow, bond, or trust is needed to stop free consumption of validation resources.
MEV and papers
Flashbots recaps 16 talks from Agentic MEV Day
On MEV, Flashbots compiled 16 talks from Agentic MEV Day. The discussions centered on how AI may participate in MEV, how agent networks might avoid reproducing the speed-race dynamics seen in traditional MEV, and what new forms of MEV may appear in AI systems tied to decentralized training, prediction markets, and model routing.
Paper studies when “not trading” is actually a mistake
The paper “When Is Inaction a Mistake? Continuation-Aware Auditing of PPO Trading Policies,” by authors from the University of Electronic Science and Technology of China and the University of Tokyo, examines whether a reinforcement-learning trading policy’s decision not to trade is a valid choice or a missed profit opportunity.
According to the summary, standard evaluation methods often compare directly against an ideal oracle. That can miss the information the model actually had at the time, as well as the effect of later decisions. The authors propose continuation-aware auditing to account for both information constraints and subsequent policy behavior. They find that many decisions that appear to be mistaken inaction are in fact reasonable, though improved decision rules can still raise overall performance over the long run.
