Bitcoin, Ethereum and XRPL all spent today editing specifications that had already shipped

Victoria Shinder25 September 2026, 09:052 min read

Three ecosystems, three repositories, and the same category of change in all of them today: a written specification being corrected by what was built from it.

BIP-138 is the cleanest example. A merged pull request changes the recipient set of the wallet-account backup scheme from the keys in the descriptor or wallet policy to the distinct public keys across all descriptor and policy sets and all content items in the payload. That is a different derivation. Backups produced under the previous reading do not reproduce under the new one, and the reason for the change is that a payload turned out to contain more than the original wording contemplated.

EIP-8298 removes the word "runtime-only" from its description of SETCODEFROM, and the commit title says the rest: allow it in initcode, require the source to be an account with existing deployed code. Implementation work established that the restriction was in the wrong place, and the proposal moved.

The XRPL Standards repository has five open changes doing this explicitly — XLS-86 and XLS-78 synced to their reference implementations, XLS-65 vault conditions updated twice, XLS-0085 changing a documented error code from tecFROZEN to tecLOCKED to match what the network actually returns, XLS-102 pinning a byte order.

What it means

The optimistic reading is that all three are doing this in public. A discrepancy between a published table and a running network is a real hazard for integrators, and the only thing worse than finding one is finding it in a repository that does not record the correction.

The practical one is more pointed. In each of these three cases, for as long as the change is open, the authority is the implementation and not the document — and integration code is almost always written against the document. The XLS-0085 error code is the sharpest illustration: a client that branches on tecFROZEN handles a case the network never produces, and it will pass every test written from the same source. For anyone building against a draft standard today, the useful habit is to diff the spec against observed behaviour before trusting either, and to treat "merged" rather than "published" as the point where a table becomes safe to hard-code.