| Pool | Blocks | Empty w/pending | Empty % | Uncontested offered | Included | Inclusion % |
|---|
| Tag | Eligible obs | Included | Conflict lost | Pure skipped | Skip % |
|---|
| tx | tag | dwell | first_h | incl_h | included by | fee/B | size |
|---|
Within-cell comparison: for each (pool, protocol) pair, compare the tx-intrinsic attributes (size, fee, fee/B, input count, output count, ergoTree bytes, creation_height delta) of INCLUDED vs SKIPPED txs. Every tx attribute matches at 1.00×. The only attribute that differs significantly is block_fill — how many txs the pool included in that block overall.
The within-cell pattern is consistent across protocols: for any (pool, protocol) pair, the INCLUDED set comes from blocks with high block_fill (typically 6–15+ user txs), the SKIPPED set comes from blocks with low block_fill (0–3 user txs). Size, fee, fee/B, num_inputs, num_outputs, ergoTree bytes, and creation_height delta are statistically identical between the two sets. Reproducible via npx tsx src/scripts/cell-compare.ts <pool> <protocol>.
So pools aren't selecting against oracle txs or any specific protocol. The pools with low overall inclusion rate produce a high fraction of empty/near-empty blocks, and oracle txs are collateral damage. When the block has 3+ txs the oracle tx rides along; when it has 0–2, the oracle tx is among the things missed.
Excluding the <30s race-claim excuse, here's how often each pool produces empty blocks WHILE uncontested txs are pending:
| pool | blocks | empty % | empty & !race & pending | avg pending when empty |
|---|
woolypooly's empty blocks have ~2.8 pending txs on average — basically empty mempool, nothing to mine. 2miners' empty blocks have 11+ pending — they're choosing not to mine them.
The pattern matches the classic Bitcoin pool "empty block" strategy: produce a header-only block immediately on seeing a competitor's tip, then add txs if you have time before publishing. The 3 ERG block reward dwarfs total fees, so the rational pool optimizes for "win the reward race" over "earn fees".
See the table above — the empty & !race & pending column ranks pools by how often they ship empty blocks with no race-claim excuse while uncontested mempool txs were available. On the Analysis tab you can sort the per-pool table by Empty % to see the same ranking against block count.
This isn't a fee filter, a validation gap, or a protocol blacklist. It's mining-software policy that prioritizes block-finding latency over inclusion. The fix would be on the pool's side — reduce SPV-style empty-block production, or wait briefly for tx selection before publishing.
If pools filtered by minimum fee_per_byte, included txs would cluster at high fee/B and skipped at low fee/B. The actual ratios:
Several pools (kryptex, woolypooly, kS61iuTf) SKIP txs paying MORE per byte than the ones they include. sigusd_oracle_refresh pays the highest median fee/B of any oracle protocol yet has the lowest inclusion rate. Fee/B is not the discriminator. cannon_q also confirmed there is no fee-filter setting in the standard Ergo node.
Originally sigusd_oracle_refresh looked universally rejected (~15% inclusion, ~80% "pure skip"). After running the retroactive audit (audit-skips.ts) that queries the Ergo node for each apparent skip and checks if its input boxes are spent on-chain, the majority of unresolved txs got reclassified as race losers (the first audit pass reclassified 2,548 of 3,369; subsequent passes catch a smaller delta). Current numbers for sigusd_oracle_refresh: —. So the "universal skip" framing was largely artifact; the real pure-skip rate is the block-construction issue above.
| protocol | n | median fee/B |
|---|