Feb 20, 2026

I split the application logic from the fee querying, so that the database code for the fee estimation is now independent (just fee collection) and about 100 lines. That's parallelized over blocks, and can be radically optimized within each block (and for individual block queries, parallelized by tx). The application logic becomes a server class, initialized and updated using a vector of fee vectors (blocks -> txs -> fees). This allows for parallel fee collection by block, which is optimal for the initialization. The cache is then just member state of the class. The factoring makes testing significantly easier and simplifies the logic. Small impact on performance by prob not even noticeable. This is because the population query is parallel but the computation is independent. The computation can be made parallel as well, but setting it up twice is additional overhead, and may not even be worth it. I've left the atomics in so I can compare it. But with sequential computation the atomics can be dropped. That is a bit simplifying, and a also enables dynamic sizing for the buckets if we wanted to do that. I also verified that the Core implementation is fixed buckets. Also updated the logic to allow for < 1 sat per byte fee rate, which was easy. Unlike Core, we don't rely on a populated vector to tell us the bucket values, since that's just nanosecond math. Not worth the additional complexity and giant lookup table. Also we don't operate in a multiple of 1000 (sats per 1000 bytes) because it's all floating point to start with, and there's ridiculous precision in a double. So we just compute in sat per vbyte, and set the min/max at compile (presently). To emit in per kvb units (e.g. for compat APIs, we obviously just divide it out).