Write the assumption down: rippled, Ethereum and Solana each made an unstated rule explicit

Victoria Shinder06 October 2026, 22:432 min read

Three small changes merged on 6 October, on three different chains, share a pattern that is easy to miss because none of them changes what users can do today.

rippled #8152. A review of the lending code found a transfer that skipped a transferability check. The state it worried about turned out to be unreachable, but only because issuance flags are never cleared, and that was true only because one function happened to add flags and never remove them. The fix did not patch the lending code; it made "issuance flags are never cleared" an invariant the ledger enforces.

EIP-8298. The draft introduces an instruction that lets an account adopt another account's code. Its new mempool section says what nodes should assume about code that might change: ban the instruction during validation, treat contracts containing it as mutable, and cap how many pending transactions can depend on one contract's code.

SIMD-0464. A four-line amendment states that two reward-collector accounts may be the same account, or the vote account itself, and that checks apply per index. Before, an implementer had to guess.

The common thread. In each case the risk was not a bug that existed but an assumption that nobody had written down, so nothing would stop a future change from breaking it. Consensus software is unusually exposed to this: two clients that read an unwritten rule differently disagree about which transactions are valid, and a later feature can quietly depend on something no one promised.

For readers who follow protocol development. Changes like these rarely make headlines, and they should not be read as signs of trouble; none of the three fixes an exploited flaw. They are signs of review working: someone asked what had to be true for the code to be safe, and then made sure it stays true.