Source: https://docs.lisk.io/docs/the-lisk-prot ... munication
this section contains the explanation of "Broadhas Consensus
", and states the following...
Broadhash consensus serves a vital function for the Lisk network in order to prevent forks. In the DPoS system, delegates are assigned slots based on timestamp and will attempt to forge a block when the system designates that delegate slot as ready. Broadhash consensus ensures that a majority of available peers agree that it is acceptable to forge.
Broadhash is established as an aggregated rolling hash of the past five blocks present in the database. All peers with the same blocks will produce the same broadhash and propagate that information via the system headers described in section 8.1.
Yes, to answer your question, it is a timing situation but ultimately Broadhash Consensus sounds as a pre-check before a bundle of transactions are put up for the delegates to secure/confirm. so it functions as a mechanism to say "Hey Lisk nodes! is this block safe to be added to the chain" (If I understand it correctly) and once a suitable amount of peers give the thumbs-up, the block is then broadcasted to the network for verification.
Hopefully this helps.