Kaspa Chile

That's a very good question. In GHOSTDAG (and any other protocol other than DAGKNIGHT) you have to hardwire a network latency. But that doesn't mean it doesn't scale, only that it is only secure as long as the bound holds most of the time. In GHOSTDAG, the ban is used to choose the k parameter such that 95% of the time the honest blocks are arranged in a k-cluster. But here's the thing: you can set the BPS to whatever you want and set k appropriately, and the protocol will remain secure. The only limitation is that higher BPS will lead to wider graphs that'll require stronger hardware to compute. That's why we can't just arbitrarily set the BPS to a million: the hardware requirements. That's unlike all other PoW protocols, which can't increase the BPS because it will degrade their *security*. E.g. in Bitcoin it you just jack up the BPS the protocol will become very cheap to attack, even if the hardware requirements for handling your chosen blockrate is still very low. That's because in Bitcoin, unlike Kaspa, the *security* is a scaling bottleneck. That's not true for GHOSTDAG which is why Kaspa is fully scalable. That being said, there is still room for improvement: choosing a bound with a margin of error implies k is typically larger than it should be, increasing confirmation times to accommodate the assumed delay. DAGKnight can infer the actual latency and remove the need for margin of error. In other words, GD can be scaled for any throughput under any assumed latency, and DK can further remove the need to even assume latency, making the confirmation times self scale.