leo-playbook

**What changed.** Three notable EIP movements hit the Ethereum Foundation repository this week. First, Barnabas Busa updated EIP-8070 to prefix its title with the `eth/72` protocol version identifier, formally scoping the proposal to a new Ethereum wire protocol version. Second, core developer lightclient pushed a commit to EIP-8141 that adds a `value` field to the frame specification — a structural change to how execution-layer frames encode data. Third, kevaundray introduced an entirely new EIP titled 'EVMification' (commit `f78f8fa`), proposing architectural changes aimed at simplifying or modularizing core EVM components. **Why it matters.** The `eth/72` prefix on EIP-8070 isn't cosmetic — it signals that the devp2p networking layer is being actively versioned forward, which means node implementers (Geth, Nethermind, Besu, Erigon, Reth) will eventually need to negotiate a new protocol handshake. The `value` field addition in EIP-8141 changes the canonical frame structure, so any tooling or client code that serializes or deserializes these frames must account for the new field or risk breaking compatibility. EVMification, while early-stage, could reshape how developers reason about opcode dispatch, memory management, or contract execution boundaries inside the EVM itself. **Impact on builders.** If you maintain a custom devp2p implementation or a networking proxy, watch EIP-8070 closely — eth/72 negotiation logic will need to land before any hard fork that adopts it. Execution-layer client teams and anyone building custom EVM frame parsers should review the updated EIP-8141 schema now to avoid deserialization mismatches. For EVMification, the window is open for community review: this is the stage where feedback from compiler authors (Solidity, Vyper, Fe), tooling developers (Foundry, Hardhat), and L2 teams carrying EVM forks carries the most weight.

### What Shipped SIMD-0432 (Loader V3 – Reclaim Closed Program) has been merged into the official SIMD repository. Authored by Joe C, this proposal introduces a mechanism for reclaiming the lamports and on-chain storage held by program accounts that have been closed via Loader V3. Previously, once a program was closed, the associated account's lamports and storage were effectively locked in limbo—still occupying space and locking SOL without serving any active purpose. ### Why It Matters Solana's programming model charges rent (or requires rent-exemption) for every byte of on-chain storage. Before SIMD-0432, closing a program through Loader V3 left behind a ghost account: the executable was gone but the lamports backing its rent exemption remained inaccessible, and the allocated storage persisted as dead weight on validators. This was especially painful for iterative developers deploying, testing, and tearing down programs during rapid development cycles, and for protocol teams sunsetting deprecated program versions in production. The SIMD formalizes a clean reclamation path, aligning Loader V3 behavior with the principle that unused resources should be returnable. ### Impact for Developers This change directly benefits anyone managing program lifecycles on Solana. Teams deploying upgradeable programs can now close obsolete versions and recover the full rent-exempt balance (often 2–5+ SOL for larger programs) back to a designated recipient. At the ecosystem level, widespread adoption of this pattern will reduce state bloat and free up lamports that can be redeployed productively. If you maintain multiple program versions or run CI pipelines that deploy ephemeral programs to devnet/testnet, SIMD-0432 turns what was a slow SOL leak into a zero-cost teardown.

Tempo v1.6.0 delivers the T3 (Wagner) network upgrade, a hard fork encompassing five protocol-level TIPs. TIP-1011 introduces fine-grained access key permissions with spending limits and call scopes, giving dApps the ability to request constrained session keys from users. TIP-1020 adds a signature verification precompile supporting secp256k1, P256, and WebAuthn curves — a foundational primitive for passkey-based wallets and cross-chain message verification. TIP-1022 implements virtual forwarding addresses that eliminate the need for sweep transactions, a significant UX improvement for exchanges and custodial services. TIP-1031 embeds consensus context directly into block headers, and TIP-1038 addresses audit-driven bug fixes and gas metering corrections. Alongside this, a separate commit updates CREATE opcode behavior per TIP-1016, modifying how contract deployment works at the EVM execution layer. The motivation behind Wagner is to close critical gaps between Tempo's account model and the expectations of production-grade wallets and dApps. Scoped access keys (TIP-1011) let protocols request limited permissions without full account access — think of a game that can call specific contract methods but cannot transfer tokens beyond a set budget. The signature precompile (TIP-1020) is a direct response to the growing adoption of WebAuthn/passkey authentication, making it economically feasible to verify these signatures on-chain rather than in application-layer workarounds. Virtual forwarding addresses (TIP-1022) remove an entire class of operational overhead for any service that aggregates funds. The legacy validator config v1 has also been removed from the consensus module (PR #3561), cleaning up deprecated code paths that could cause confusion or misconfiguration. The impact for developers and operators is immediate and non-negotiable. All validators and RPC node operators must upgrade to v1.6.0 before the testnet activation on April 21, 2026, or their nodes will fall out of sync. The `--consensus.enable-subblocks` CLI flag has been removed, and ENR fork ID enforcement is now enabled by default — operators who relied on either must update their configurations. Developers must upgrade to T3-compatible SDK versions; the CREATE opcode behavior change per TIP-1016 may affect contract deployment scripts and tooling that assumed the previous semantics. Any node operator still using validator config v1 must migrate to v2 before upgrading, as the legacy path no longer exists in the consensus module.

**What changed.** PR #3254, authored by Hamdi Allam, implements TIP-1031 by extending the Tempo block header with a new consensus context field. In practical terms, every block header produced by the network now carries structured metadata about the consensus conditions under which it was finalized — think validator set snapshot, voting round info, and any protocol-specified context the consensus layer wants to surface to execution and indexing layers. This is a structural change to the canonical header schema, so it touches serialization, hashing, and any code path that reads or constructs headers. **Why it matters.** Before TIP-1031, consensus-layer details lived in separate data structures that clients had to cross-reference after the fact. Embedding this context directly in the header collapses that indirection: light clients can now verify consensus properties without extra round-trips, indexers can decode richer information from a single RLP/SSZ pass, and fraud/validity proofs that reference header commitments automatically cover consensus state. It's a design decision that optimizes for verifiability and composability at the protocol's most fundamental data structure. **Impact on builders.** If you operate a Tempo node, parse block headers in an indexer, or build tooling that constructs or validates headers, this is a breaking schema change. You will need to update deserialization logic to account for the new field and re-derive any header hashes after upgrade. Validator operators should watch for the corresponding node release that enforces the new header format at a specified activation height. SDK and library maintainers downstream should pin to the updated header type definitions as soon as they land in client packages.

Shipli AI is introducing first-class React Native support to its AI-powered code auditing and review platform. This means new rule sets, guideline modules, and project structure recognition tailored specifically for React Native projects — covering navigation patterns (React Navigation, Expo Router), state management (Redux, Zustand, Context API), native module bridging, performance optimization, and platform-specific best practices. These additions sit alongside the existing web and Flutter support, giving Shipli AI a comprehensive cross-platform auditing surface. The motivation is straightforward: React Native commands a massive share of the cross-platform mobile development landscape, and its absence from Shipli AI left a significant gap. Developers building with React Native deserve the same depth of automated code review — catching anti-patterns in bridge calls, flagging unnecessary re-renders, enforcing proper list virtualization, and validating navigation structure — that web and Flutter developers already enjoy. By modeling this implementation on the existing Flutter support architecture (rule directories, detection modules, guideline files), the team ensures consistency across all supported platforms while respecting React Native's unique idioms. The impact for developers is immediate and practical. If you maintain a React Native project, you can now point Shipli AI at your repo and get actionable audit feedback tuned to React Native conventions — not generic JavaScript linting, but context-aware analysis that understands `react-native` imports, Expo configurations, Metro bundler setups, and the nuances of bridging native modules. For teams shipping across web, Flutter, and React Native simultaneously, Shipli AI now serves as a single auditing layer across all three targets, reducing toolchain fragmentation and raising code quality uniformly.

**What changed.** Three notable commits landed in the Ethereum Foundation EIPs repository. First, author avsetsin proposed a brand-new EIP introducing withdrawal credentials preregistration — a mechanism that lets validators declare their withdrawal credentials ahead of the actual deposit flow. Second, Barnabas Busa updated EIP-8070 to formally rename the next wire protocol version to eth/72 while cleaning up typos in the spec. Third, Paweł Bylica refined EIP-7708 with an explicit clarification on how burn log emissions should behave when the target account holds a non-zero balance. **Why it matters.** The withdrawal credentials preregistration EIP addresses a real operational pain point: validators currently commit withdrawal credentials at deposit time with no native mechanism to pre-declare or verify them beforehand, which can lead to costly mistakes. Standardizing preregistration could harden staking onboarding for solo operators and institutional stakers alike. The eth/72 rename in EIP-8070 signals that the next-generation wire protocol is maturing toward client adoption — node operators and client teams need to track this closely for upcoming breaking changes. The EIP-7708 burn log clarification, while surgical in scope, prevents divergent implementations across clients that track ETH burns, ensuring consensus-layer consistency. **Impact on builders.** If you operate validators or build staking infrastructure, the withdrawal credentials preregistration EIP is one to watch and provide feedback on — early input shapes the final spec. Client developers and node operators should audit their eth/71 implementations against the incoming eth/72 changes in EIP-8070 to plan migration timelines. Teams building analytics, block explorers, or event-indexing pipelines that consume burn events should review the EIP-7708 update to ensure their log-parsing logic handles the non-zero-balance edge case correctly.

The Ethereum Foundation merged a fix to EIP-8130 that corrects the sentinel address values specified in the proposal. Sentinel addresses serve as reserved, predefined addresses within smart contract systems—they act as boundary markers or default placeholders that signal special behavior to consuming contracts and clients. The commit, authored by Chris Hunter, resolves an error in the previously published sentinel address constants, bringing the specification in line with its intended design. This fix matters because EIPs function as the canonical reference for Ethereum ecosystem implementations. When a sentinel address is incorrectly specified at the standards level, every downstream implementation that faithfully follows the spec inherits the bug. Contracts, tooling, and infrastructure that were built against the prior (incorrect) sentinel values may behave unexpectedly or fail to interoperate with implementations that independently derived the correct values. By catching and correcting this at the EIP level, the Foundation prevents a class of subtle, hard-to-diagnose compatibility issues from propagating across the ecosystem. The impact is targeted but significant. If you are building or have already deployed contracts, indexers, or off-chain services that reference EIP-8130 sentinel addresses, you should audit your codebase against the updated specification. Implementations that hardcoded the old sentinel values will need to be updated—and in the case of immutable on-chain contracts, migration or proxy-upgrade strategies may need to be evaluated. For teams that haven't yet begun implementation, this is a clean correction: pull the latest EIP text and proceed with confidence.

**What changed.** Three significant changes landed in Tempo this cycle. First, TIP-1031 (PR #3254) adds consensus context directly into the block header structure, giving validators and clients richer protocol-level metadata at the header layer. Second, the validity bounds on Account Abstraction (AA) transactions — `valid_before` and `valid_after` — were refactored from plain `u64` fields to `Option<NonZeroU64>`. This eliminates an ambiguity where a zero value was indistinguishable from an omitted bound in RLP encoding and serde serialization; zero-valued bounds are now explicitly rejected when constructing AA transactions. Third, Tempo bumped its core dependencies: alloy moves to 2.0.0, reth updates to revision bfb7ab7, and several related crates advance (reth-codecs 0.2.0, reth-primitives-traits 0.2.0, alloy-evm 0.31.0, revm-inspectors 0.37.0). **Why it matters.** TIP-1031 is a consensus-critical change — any tooling that parses, constructs, or validates block headers must account for the new consensus context field or risk deserialization failures. The validity bounds refactor closes a subtle correctness gap: previously, an AA transaction with `valid_after: 0` looked identical on the wire to one with no bound at all, which could lead to unexpected mempool behavior or replay edge cases. The alloy 2.0 upgrade is a breaking release that splits `TransactionBuilder` into `TransactionBuilder` and `NetworkTransactionBuilder` traits, introduces new `BlockHeader` methods, and reshapes several internal interfaces. **Impact on developers.** Node operators and validator teams should plan to upgrade promptly — the new header format from TIP-1031 will be enforced at a future block height. SDK and indexer maintainers need to update header deserialization logic to include the consensus context field. Anyone building or signing AA transactions must ensure validity bounds are passed as `None` (omitted) rather than `Some(0)` — the latter will now be rejected. And if your project depends on alloy, reth-codecs, reth-primitives-traits, alloy-evm, or revm-inspectors, expect breaking API changes that require code adaptation when you pull in the latest Tempo crates.

Three security-critical fixes landed in the rippled confidential Multi-Purpose Token (MPT) subsystem, all targeting edge cases where the new confidential transaction types (ConfidentialMPTSend and ConfidentialMPTClawback) bypassed safety rails that protect every other MPT operation. The most significant change closes an invariant conservation gap: ConfidentialMPTSend had no post-execution check verifying that public balance fields (MPTAmount, OutstandingAmount) remained untouched, because it fell through both ValidMPTPayment (which skips confidential tx types) and ValidConfidentialMPToken (which only checks when coaDelta != 0, always false for Send). A second fix adds the missing checkExtraFeatures override to ConfidentialMPTSend, ensuring the sfCredentialIDs field is properly gated behind the featureCredentials amendment — without this, a timing mismatch between featureConfidentialTransfer and featureCredentials activation could allow credential-bearing transactions to slip through ungated, risking consensus divergence. The third fix adds an explicit preclaim guard in ConfidentialMPTClawback to verify the clawed amount does not exceed sfOutstandingAmount, preventing a potential uint64 underflow during doApply. These patches matter because invariant checks are the last line of defense in rippled's transaction engine — they fire after execution and halt the server if ledger corruption is detected. A missing invariant means silent corruption could persist across ledger closes. Similarly, amendment gating is a consensus-critical mechanism; bypassing it means different nodes could disagree on transaction validity depending on local feature flags. The unsigned integer underflow in clawback, while caught by the post-transaction invariant checker in theory, represents a defense-in-depth failure — preclaim should reject obviously invalid operations before state mutation begins. For developers building on or integrating confidential MPTs, these fixes ensure that the security model of confidential transfers matches the rigor of standard MPT payments. If you're running a validator or operating infrastructure that processes confidential MPT transactions, upgrading to a build containing these patches is strongly recommended to avoid edge-case invariant failures that could trigger server crashes or ledger divergence.

Chris Hunter committed a targeted fix to EIP-8130 that corrects the sentinel addresses specified in the proposal. Sentinel addresses serve as canonical placeholder or boundary values within smart contract logic and protocol-level operations — they are the "magic constants" that implementations check against to signal special states such as null ownership, list terminators, or guard conditions. Getting these values wrong at the spec level means every downstream implementation inherits the bug, so this correction, while small in diff size, is significant in blast radius. The motivation behind the fix is straightforward: if the sentinel addresses published in an EIP are incorrect, any client, tooling library, or smart contract that faithfully implements the spec will produce incompatible or subtly broken behavior. This is especially dangerous because sentinel mismatches can pass unit tests that were written against the same incorrect spec, only surfacing in cross-implementation interop testing or on mainnet. By correcting the values at the source of truth, the Ethereum Foundation eliminates an entire class of downstream integration bugs before they propagate. For developers actively building against EIP-8130 — or planning to — this is a "stop and re-read the spec" moment. If you hardcoded the previous sentinel values, you need to update them. If you wrote tests that assert against those old values, your tests are now checking for the wrong thing. The impact is contained but critical: audit your constants, re-run your integration suites against the updated spec, and propagate the fix into any libraries or SDKs you maintain that reference EIP-8130.