Apr 6, 2026

It will require that the subscription performs the costly computation against block state. This requires sorting all unique parent txs of all confirmed inputs/outputs hitting an address by their height and order within the block, and combining all of those tx hashes into a sha256 midstate. Because this becomes stateful, cumulative, and not reversible, a reorg impacting the address requires it to be rebuilt. The midstate for each subscribed address can then be updated with confirmations. Since a different sort is used for unconfirmed txs, these cannot be accumulated and must instead be recalculated in full for each notification. Since tx pooling would not result in additional indexation of the same spend upon confirmation, and thus address index is not indexed by confirmation status, this implies independent tracking of pooled txs impacting a subscribed address, so that the this status field can be computed (hash combined with the confirmed midstate)

The only mempool consistency requirement is that we provide the same transactions upon request as have been hashed into the status.

So there's that as well. For reasonable numbers of spends for a given address (like 1000), just performing the full computation on each notification isn't so bad. And I suspect that Electrum servers don't actually support large address notifications. But it's not worth doing if it's going to be broken. The above non-pool implementation is simple enough, and the performance hit for large addresses will only be encountered by the initial subscription (and notification following address reorg) - similar in cost to a full history or balance query. Adding the pool behavior will require either accumulating unconfirmed tx surrogate keys in each address subscription map, or querying for it dynamically against the unconfirmed tx metadata graph. There's no requirement to pull up old unconfirmed txs that have been stored, just as with the graph. We can pull them up at graph init if we want, but ignoring them causes no harm.