A step-by-step walkthrough of 8 transactions through the old mempool, cluster mempool with CSS, and cluster mempool with SFL — showing where the approaches align and where their policy/computation behavior differs.
Here are 8 unconfirmed transactions that form a single connected cluster. The sizes and fees are intentionally stylized to make the policy differences easy to see.
Presenter takeaway: Start by grounding the audience in the graph and the totals: 8 txs, 21,550 vB, 33,400 sats.
| Tx | Fee (sats) | Size (vB) | Feerate (s/vB) | Spends from | Role |
|---|---|---|---|---|---|
| A | 500 | 250 | 2.0 | — | Root parent, low fee |
| B | 400 | 200 | 2.0 | — | Independent root |
| C | 6,000 | 200 | 30.0 | A | High-fee child of A |
| D | 10,000 | 200 | 50.0 | A | Very high-fee child of A |
| E | 200 | 10,000 | 0.02 | A | Huge low-fee child (bloat) |
| F | 300 | 10,000 | 0.03 | E | Another huge low-fee tx |
| G | 15,000 | 200 | 75.0 | B, D | Premium tx, spends B and D |
| H | 1,000 | 500 | 2.0 | C | Modest child of C |
Transaction G is a premium 75 sat/vB tx, but it depends on two parents — B (independent root) and D (which depends on A). Meanwhile, someone has attached massive low-fee txs E and F as children of A, dragging down A's descendant feerate. This is a realistic pattern: a value path (A→D→G) polluted by a bloat path (A→E→F). How does each approach handle it?
Total cluster: 8 txs, 21,550 vB, 33,400 sats. Let's assume there's only space for about 1,250 vB in the next block (to force interesting choices). Which transactions get included?
The pre-v31 mempool uses two separate orderings. Let's compute both and see where they diverge.
Presenter takeaway: Mining and eviction both look reasonable locally, but they optimize different metrics and can send conflicting signals.
Now let's see what cluster mempool does. First, it identifies the connected component as a single cluster and attempts to find the optimal linearization using the CSS/LIMO algorithm.
Presenter takeaway: CSS can find the right ordering here, but does so with search that can become expensive on harder clusters.
SFL starts from a different place. Instead of searching through candidate subsets, it maintains a spanning forest of active dependency edges and iteratively merges or splits chunks.
Presenter takeaway: SFL reaches the same ordering here via local updates, which is why it scales better as clusters evolve.
Given a block with only ~1,250 vB of space, all three approaches include the same template here; the differences are in ranking coherence and computation:
Presenter takeaway: In this toy case, throughput is equal (31,900 sats), but cluster mempool provides one consistent policy view for mining and eviction.
The old mempool's eviction logic scores A using all descendants, including 20kvB of low-fee bloat (E+F): (500+6000+10000+200+300+15000+1000) / (250+200+200+10000+10000+200+500) = 1.55 sat/vB. In this exact graph, eviction still removes E+F first (0.025 sat/vB), which is sensible. But the key issue remains: mining and eviction evaluate value differently, so transaction importance can look contradictory depending on direction.
CSS finds the same optimal answer as SFL for this cluster. The difference shows up in the computational path. CSS's branch-and-bound search explores candidate subsets exponentially. For this 8-tx cluster it's fine — but with clusters up to 64 txs, especially those with many cross-dependencies, CSS can hit its iteration limit and return a suboptimal linearization. In 2023 simulations, some clusters caused 9ms of CPU per incoming transaction.
SFL arrives at the optimal answer through a series of simple, local merge/split operations on the spanning forest. Each step is O(cluster-size) work. It's incremental: if a new transaction arrives and changes the cluster, SFL starts from the previous (nearly-optimal) state and typically needs only a few operations to re-optimise. CSS would need to re-search from scratch. This is why SFL is replacing CSS in PR #32545.
Chunk 1: A + B + D + G → 850 vB, 25,900 sats = 30.5 s/vB
Chunk 2: C → 200 vB, 6,000 sats = 30.0 s/vB
Chunk 3: H → 500 vB, 1,000 sats = 2.0 s/vB
Chunk 4: E + F → 20,000 vB, 500 sats = 0.025 s/vB
Monotonically decreasing feerate ✓ — low-fee bloat ends up in the final chunk