The download window purposely does not constrain either the validator or the confirmer, and the validator does not constraint the confirmer. However with all having work, naively the highest priority threads should generally exhaust first. But this makes certain assumptions about thread scheduling. The proactor work queues are managed by BOOST ASIO. There is the network pool (download and eventing), validator queue (validation dispatch and validation), and the confirmation queue. c++ is performing the confirmability fan-out (internal to each block), and is starting from the highest priority single thread. Once that thread loops through all blocks, fanning out for each, ASIO takes over to notify it again. And there are almost always confirmation messages in this stranded (ordered) queue. But I suspect that this one highest priority thread is not able to keep pace with 64 high priority validation threads (and 16 normal priority download threads).