Tuesday, 21 July 2026 · 14:00 UTC
Host: Jesse Chejieh — @jessechejieh:matrix.org (Rank II)
Agenda thread: help-center#19
Recording: Google Drive
The second call of the hosting pilot. The floor went to Josep M Sobrepere for two complementary RFCs: RFC 174, an inclusion-proof request for light clients, and RFC 173, which prevents transaction replay against reaped accounts.
Light client extrinsics-trie inclusion proof request
Josep M Sobrepere presented RFC 174. Today the only way for a light client to confirm that a transaction made it into a block, which it needs in order to know when to stop broadcasting it, is to download the entire block body and check it against the extrinsics root in the header. Because the extrinsics trie uses trie v1, where leaves above a size threshold store hashes rather than payloads, the RFC adds a request between light client and full node that returns the trie’s hashes instead. The client recomputes the extrinsics root from them, checks it against the header, and can then tell which of its tracked transactions were included without fetching any bodies.
Oliver Tale-Yazdi asked whether the request needs multiple modes. Josep explained that it always returns all of the hashes, since a full leaf set is the only way to prove a transaction was not included, and clients commonly track more than one transaction at a time. Carlo Sala supported this: a block cannot fit more than roughly 1,000 extrinsics, so the response stays in the tens of kilobytes at most.
An implementation is already open against polkadot-sdk (#12644). Once the RFC lands, the plan is to expose a dedicated RPC method and update the client libraries on top of it. Nobody objected; the room was aligned on the direction.
Prevent Transaction Replay via CheckCreatedAtHeight
RFC 173 addresses transaction replay. An account that falls below the existential deposit is reaped and its nonce resets to zero, so if the account is later refunded, previously signed transactions can be replayed against it. Josep’s preferred design treats the nonce as a tuple: the explicit auto-incrementing nonce that exists today, plus an implicit value set to the chain height at which the account was created, carried in the signed payload by a new CheckCreatedAtHeight transaction extension. He contrasted this with an earlier, more pragmatic proposal from Oliver Tale-Yazdi (runtimes#248) to initialise a new account’s nonce at the current block height, which does not mathematically eliminate replay but makes it unlikely enough to ignore in practice, at the cost of marginally larger and therefore more expensive transactions for accounts created later.
Oliver probed the migration cost of the tuple approach, since it adds a field for every one of the roughly three million existing accounts; Josep floated reallocating the largely unused bytes of the flags field in the account data to avoid recomputing state, while admitting it is hacky. Oliver also pressed on offline signers, which would have no way to know an account’s created-at height. Josep’s answer was that offline signers are never truly self-sufficient, since they already depend on an online agent for the nonce and the current spec version, so this becomes one more field that tooling must supply. He conceded it would break existing signers, and committed his team to helping developers and signer authors prepare for this and for what is coming with transaction extension version 5. Carlo added that making the new field optional would defeat the purpose, and that the clean design from scratch is a single extension carrying an explicit and an implicit value, which is exactly the tuple.
Closing updates
The floor was open to anything not on the agenda, including PRs needing eyes, and nothing was raised. Two closing notes: the salary migration from USDT to Hollar is complete, and thanks to Alexandre R. Baldé for catching that fellows holding no DOT on Asset Hub would have had their payouts fail silently, because Hollar had not yet been made a sufficient asset there.
Tell us what to change in the feedback form. Next call: Tuesday, 18 August 2026 · agenda thread opens ~2 weeks out.