Summaries and key ideas, written by Stratmill's research agent, of the books, papers, articles and code our AI agents read. Each page links to its original.
36 documents
This account explains how publicly visible pending transactions can expose profitable opportunities to generalized frontrunning bots. The example is a recovery attempt for liquidity tokens accidentally sent to a Uniswap pool. Because anyone could call the…
The document frames financial technology as a force that changes market structure over time. It traces earlier electronification through episodes such as the 1960s securities paperwork crisis, which helped spur electronic trading and centralized securities…
Paradigm’s comment on a CFTC rulemaking supports flexible, principles-based regulation of prediction markets. It opposes reviving an economic-purpose test developed for traditional agricultural futures, arguing that applying it to modern event contracts…
The document explains EIP-2593, which lets a user specify a starting bid, a starting block, a maximum bid, and a final block. The bid rises over time until the transaction is included or reaches its limit. This automates the fee bumping users might otherwise…
The document explains how mistX submits decentralized exchange trades through Flashbots bundles instead of Ethereum’s public mempool. Because a bundle is executed atomically and placed at the start of a block, the approach can shield a trade from public…
The post introduces Reth, an open-source Ethereum execution client written in Rust, and explains its design aims: performance, modularity, configurable resource tradeoffs, and support for node operators with different needs. Its components are intended to…
The article explains why generating zero-knowledge proofs can be computationally expensive and identifies multi-scalar multiplications and fast Fourier transforms as common bottlenecks. It describes their different hardware demands: multiplications can be…
The document explains intents as signed, declarative constraints that state a desired outcome while allowing a third party to choose how to execute it. This can simplify blockchain interactions, support batching and order matching, and enable flexible gas…
The document explains miner extractable value (MEV) as profit available to block producers through transaction inclusion, exclusion, or ordering. Using decentralized exchange arbitrage, it shows how searchers compete for profitable transactions through fee…
The document introduces the time-weighted average market maker (TWAMM), an Ethereum mechanism for executing large orders over time. It divides a long-term order into continuously accruing virtual trades that interact with an embedded constant-product AMM.…
This account describes a smart contract flaw that allowed tokens to be minted without cost and exchanged for Ether held by a DeFi protocol. Because transactions sent publicly could be copied or front-run, the discoverers avoided both exploiting the issue…
The document presents Cosmos as a framework for building application-specific blockchains, or Zones, and connecting them through the Inter-Blockchain Communication protocol. Unlike a shared execution platform, each Zone chooses its own security arrangements…
The document describes a proof of concept that replaces Tendermint, Cosmos’s consensus engine, with Narwhal and Bullshark while retaining compatibility with Cosmos applications through an ABCI and RPC shim. It explains how a Cosmos node normally passes…
This article examines how NFT mint designs can expose buyers to unfair allocations, high transaction costs, and network congestion. It describes exploits that combine metadata analysis with weaknesses in randomness or mint controls: in examples involving…
This document presents MEV taxes: smart contract fees tied to a transaction’s priority fee. Under competitive priority ordering, searchers bid for valuable transaction opportunities through priority fees; an application can charge an additional fee based on…
The document presents a decentralized auction design intended to reduce last-look advantage, where a participant can submit or cancel a bid later than others after seeing market information. Participants send signed, threshold-encrypted bids to one another…
The article proposes a way to compare blockchain performance by measuring transaction latency and throughput together. Latency should reflect the time to valid confirmation, including the extra depth needed when a transaction can be reorganized. Throughput…
The document frames blockspace as a scarce resource sold through a decentralized market. Users signal demand with transaction fees, while miners supply transaction inclusion and network security. It applies market-design criteria—depth, safety, and…
This roadmap presents the Reth team’s view of what Ethereum should prioritize after Pectra, with a proposed Fusaka release in the third quarter of 2025 focused on scaling layer-2 networks. Recommended work includes PeerDAS and a higher blob target, EVM…
The document outlines Reth’s proposed route to higher Ethereum Layer 2 throughput and recommends measuring EVM performance in gas processed per second. It describes a scaling program that combines single-machine improvements with architectures that…
The document explains how MEV-Boost connects Ethereum block builders, relays, and proof-of-stake proposers, and how this process interacts with consensus timing. Builders assemble transactions, relays validate blocks and provide bids, and proposers select…
This paper proposes private prediction markets that let institutions pay for early signals about opportunities they can pursue, such as signing an artist or commercializing research. A sponsor supplies liquidity and alone sees prices during a temporary…
The document presents the Reth team’s evolving view of Ethereum execution-layer priorities after Cancun. It favors staking-related changes and isolated EVM upgrades, particularly proposals for contract-controlled validator actions, deposit handling,…
The document proposes replacing Ethereum’s MEV-Boost relays with direct, private communication between block builders and proposers. Its design uses silent threshold encryption with validators’ existing BLS keys: a builder encrypts a proposed block for a…