1.

Understanding the Challenge: Why BPS Matters

Traditional blockchains face a fundamental problem when attempting to increase their block generation rate: security parameters that work well at one block rate may become inadequate or inefficient at another. For example, a finality depth of 10 blocks might provide sufficient security when blocks are generated every 10 minutes, but the same depth would be completely inadequate if blocks are generated every second.

This creates a critical challenge: how can a network scale its block generation rate while maintaining the same level of security? Simply increasing the block rate without adjusting security parameters would either compromise security (if parameters are too small) or create unnecessary overhead (if parameters are too large).

The Fixed Parameter Problem

In traditional blockchain systems, security parameters are typically fixed. A network might decide that “10 confirmations” represents finality, and this number remains constant regardless of whether blocks are created every 10 minutes or every 10 seconds. This approach has serious limitations:

• Security Degradation: If block time decreases but confirmation depth stays the same, the actual time to finality decreases proportionally. A 10-block confirmation that took 100 minutes at 10-minute blocks would only take 10 seconds at 1-second blocks, potentially compromising security
• Inefficiency: If block time increases but confirmation depth stays the same, users must wait unnecessarily long for confirmations. A 10-block confirmation at 10-minute blocks means 100 minutes of waiting, which is impractical for many use cases
• Inflexibility: Fixed parameters prevent networks from adapting to changing conditions or implementing upgrades that change block rates
• Scalability Limitations: Without adaptive parameters, increasing block rate becomes a security trade-off rather than a pure scaling solution

Kaspa’s BPS system solves this problem by making all critical security parameters proportional to the block generation rate. This ensures that security guarantees remain constant regardless of how fast blocks are created.

2.

What is Blocks Per Second (BPS)?

Blocks Per Second (BPS) is both a measurement of Kaspa’s block generation rate and a configuration system that scales all consensus parameters proportionally. When we say “Kaspa operates at 10 BPS,” we mean that the network creates approximately 10 new blocks every second. But more importantly, BPS serves as the scaling factor that determines how all security parameters are calculated.

BPS as a Measurement

As a measurement, BPS tells us how fast Kaspa’s network is producing blocks. Currently, Kaspa operates at approximately 1 block per second (1 BPS), with plans to scale to 10 blocks per second (10 BPS) and eventually even higher rates. This high block rate is made possible by Kaspa’s GHOSTDAG protocol, which allows parallel blocks to coexist rather than being discarded as orphans.

To put this in perspective:

• Bitcoin: Approximately 0.0017 BPS (1 block every 10 minutes)
• Ethereum (PoW): Approximately 0.2 BPS (1 block every 5 seconds)
• Kaspa (Current): 1 BPS (1 block per second)
• Kaspa (Planned): 10 BPS (10 blocks per second)
• Kaspa (Future): Potentially 32+ BPS with DAGKnight protocol

BPS as a Configuration System

More importantly, BPS serves as Kaspa’s scaling mechanism. When the network operates at a specific BPS rate, all consensus parameters are calculated relative to that rate. This means:

At 1 BPS: If finality depth is set to 10 blocks, finality is achieved after 10 seconds (10 blocks × 1 second per block).

At 10 BPS: If finality depth scales proportionally, it becomes 100 blocks, maintaining the same 10-second finality time (100 blocks × 0.1 seconds per block = 10 seconds).

This proportional scaling ensures that security guarantees remain constant regardless of the block generation rate. The time to finality, the security against attacks, and the network’s resistance to reorganization all remain the same, even as the block rate increases.

3.

Key Consensus Parameters That Scale with BPS

Several critical consensus parameters in Kaspa scale proportionally with the BPS rate. Understanding these parameters and how they scale is essential to understanding how BPS maintains security at any block rate.

3.1.

Finality Depth

Finality depth is the number of blocks that must be added after a transaction’s block before that transaction is considered final and irreversible. In traditional blockchains, finality depth is often fixed (like Bitcoin’s “6 confirmations”), but in Kaspa, it scales with BPS.

How It Works: Finality depth represents a time-based security guarantee. If Kaspa wants to ensure that transactions are final after 10 seconds, the finality depth must scale with block rate:

• At 1 BPS: Finality depth of 10 blocks = 10 seconds to finality
• At 10 BPS: Finality depth of 100 blocks = 10 seconds to finality (100 blocks × 0.1 seconds)
• At 32 BPS: Finality depth of 320 blocks = 10 seconds to finality (320 blocks × 0.03125 seconds)

This ensures that regardless of how fast blocks are created, the time required for a transaction to achieve finality remains constant. Users always know that after a specific amount of time (measured in seconds, not blocks), their transactions are secure.

Why This Matters: Fixed finality depths would create security vulnerabilities at higher block rates. If finality depth stayed at 10 blocks regardless of BPS, finality time would drop from 10 seconds (at 1 BPS) to just 1 second (at 10 BPS), potentially compromising security against deep reorganizations.

3.2.

Merge Depth

Merge depth is a critical parameter in Kaspa’s blockDAG structure that determines how far back in the DAG the network looks when determining which blocks are part of the consensus order. In a blockDAG, multiple blocks can reference the same parent blocks, creating a graph structure. Merge depth helps determine how this graph is ordered and which blocks are considered “merged” into the consensus.

How It Works: Merge depth scales proportionally with BPS to maintain consistent security properties. As block rate increases, the DAG structure becomes more complex (more blocks per unit of time), so merge depth must increase proportionally to maintain the same level of security and ordering guarantees.

At higher BPS rates, there are more blocks in any given time window, which means the DAG has more parallel branches and more complex relationships between blocks. A proportional increase in merge depth ensures that the network can properly order and merge all these blocks while maintaining security.

Why This Matters: If merge depth didn’t scale with BPS, the network might not properly order blocks at higher rates, leading to potential consensus issues or security vulnerabilities. Proportional scaling ensures that the blockDAG structure remains secure and properly ordered regardless of block generation rate.

3.3.

GHOSTDAG K Parameter

The GHOSTDAG K parameter is one of the most important security parameters in Kaspa’s consensus mechanism. K determines the size of the “K-set” - the set of blocks that are considered when determining consensus order. A larger K means the network considers more blocks when making consensus decisions, which generally increases security but also increases computational requirements.

How It Works: The K parameter scales with BPS to maintain consistent security levels. As more blocks are created per second, the network needs to consider proportionally more blocks to maintain the same security guarantees:

• At 1 BPS: K might be set to a value that considers blocks from the last 10 seconds
• At 10 BPS: K scales proportionally to consider blocks from the same 10-second window, but now that window contains 10× more blocks
• The security guarantee (time-based) remains constant, but the number of blocks considered increases

This proportional scaling ensures that GHOSTDAG’s security properties remain constant. The network maintains the same resistance to attacks, the same level of decentralization, and the same consensus guarantees, regardless of block rate.

Why This Matters: The K parameter is fundamental to GHOSTDAG’s security. If K didn’t scale with BPS, the network would become more vulnerable to certain types of attacks at higher block rates, or it would become unnecessarily conservative (and slow) at lower block rates. Proportional scaling maintains optimal security at all block rates.

4.

How BPS Scaling Works

BPS scaling works by making all time-based security parameters proportional to the block generation rate. The fundamental principle is simple: if blocks are created X times faster, then all block-count-based parameters must be X times larger to maintain the same time-based security guarantees.

The Scaling Formula

While the exact implementation details are complex, the core scaling principle can be understood as:

Scaled Parameter = Base Parameter × BPS Rate

For example, if a parameter is designed to provide 10 seconds of security at 1 BPS:

• At 1 BPS: Parameter = 10 blocks (10 blocks × 1 second = 10 seconds)
• At 10 BPS: Parameter = 100 blocks (100 blocks × 0.1 seconds = 10 seconds)
• At 32 BPS: Parameter = 320 blocks (320 blocks × 0.03125 seconds = 10 seconds)

This ensures that the time-based security guarantee (10 seconds) remains constant regardless of block rate.

Automatic Parameter Adjustment

Kaspa’s BPS system automatically adjusts all consensus parameters when the network’s block rate changes. This happens through the network’s consensus mechanism, which continuously monitors the actual block generation rate and adjusts parameters accordingly.

This automatic adjustment is crucial because:

• No Manual Intervention Required: The network adapts automatically as block rate changes, whether due to network upgrades, mining difficulty adjustments, or natural network variations
• Consistent Security: Security parameters always match the current block rate, ensuring optimal security at all times
• Smooth Transitions: When the network upgrades to higher BPS rates, parameters adjust smoothly without requiring hard forks or manual reconfiguration
• Network Resilience: If block rate temporarily decreases (due to network conditions), parameters adjust accordingly, maintaining appropriate security levels

Time-Based vs Block-Based Security

The key insight behind BPS scaling is that security should be measured in time, not in blocks. A “10-block confirmation” means something completely different at 1 BPS (10 seconds) versus 10 BPS (1 second). By scaling parameters proportionally, Kaspa ensures that security is always measured in consistent time units.

This time-based approach to security is more intuitive for users and applications. Instead of thinking “I need 10 confirmations” (which could mean 10 seconds or 100 seconds depending on block rate), users can think “I need 10 seconds of finality” (which remains constant regardless of BPS).

5.

The Transition from 1 BPS to 10 BPS

Kaspa’s network has been designed to scale from its initial 1 block per second rate to 10 blocks per second, with the BPS system ensuring a smooth and secure transition. This 10× increase in block generation rate represents a significant milestone in Kaspa’s evolution and demonstrates the power of proportional parameter scaling.

Current State: 1 Block Per Second

Currently, Kaspa operates at approximately 1 block per second. At this rate, the network already demonstrates significant advantages over traditional blockchains:

• Fast Confirmations: Transactions are confirmed within seconds rather than minutes
• High Throughput: The blockDAG structure allows multiple blocks per second without orphaned blocks
• Low Latency: Users experience near-instant transaction visibility and quick finality
• Proven Security: The network has maintained security and stability at 1 BPS, demonstrating the effectiveness of the BPS scaling system

Even at 1 BPS, Kaspa processes transactions 600 times faster than Bitcoin (which creates blocks every 10 minutes) and 5 times faster than Ethereum’s proof-of-work system (which created blocks every 5 seconds).

The Path to 10 Blocks Per Second

The transition to 10 BPS involves several coordinated changes:

• Network Upgrade: The Kaspa network will implement upgrades that enable 10× block generation rate
• Automatic Parameter Scaling: All consensus parameters (finality depth, merge depth, GHOSTDAG K) will automatically scale by a factor of 10
• Mining Adjustments: Mining difficulty will adjust to maintain the target block rate
• Network Optimization: Block propagation and validation will be optimized to handle the increased throughput

Throughout this transition, the BPS system ensures that security parameters scale proportionally. Finality depth, merge depth, and GHOSTDAG K will all increase by a factor of 10, maintaining the same time-based security guarantees.

Benefits of 10 BPS

Operating at 10 blocks per second will provide significant benefits:

• 10× Transaction Throughput: The network can process 10 times more transactions per second
• Faster Finality: While time-based security remains the same, the increased block rate means more granular confirmation updates
• Better User Experience: Users will see confirmations update more frequently, providing better feedback
• Reduced Congestion: With 10× more blocks, transaction backlogs become less likely even during high-activity periods
• Maintained Security: All security guarantees remain constant due to proportional parameter scaling

Importantly, these benefits come without sacrificing security. The BPS system ensures that all security parameters scale appropriately, maintaining the same level of protection against attacks, reorganizations, and consensus failures.

6.

Why Proportional Scaling Is Essential

Proportional scaling of consensus parameters with block rate is not just a convenience feature—it’s essential for maintaining security and performance at any block generation rate. Without proportional scaling, increasing block rate would either compromise security or create unnecessary inefficiencies.

Security Without Compromise

The most important reason for proportional scaling is security. Security in proof-of-work systems is fundamentally time-based. A 51% attack, for example, requires controlling the network for a certain amount of time, not a certain number of blocks. If security parameters don’t scale with block rate, the time required for attacks decreases proportionally.

Consider what would happen if finality depth stayed at 10 blocks regardless of BPS:

• At 1 BPS: 10 blocks = 10 seconds of security (reasonable)
• At 10 BPS: 10 blocks = 1 second of security (insufficient)
• At 100 BPS: 10 blocks = 0.1 seconds of security (dangerously low)

Without proportional scaling, increasing block rate would directly compromise security. The BPS system prevents this by ensuring that time-based security guarantees remain constant.

Efficiency and Performance

Proportional scaling also ensures efficiency. If parameters were too large for the current block rate, the network would be unnecessarily conservative, requiring more confirmations than necessary and slowing down the user experience. If parameters were too small, security would be compromised.

By scaling parameters proportionally, Kaspa ensures that:

• Security is Optimal: Parameters are exactly the right size for the current block rate, providing maximum security without unnecessary overhead
• Performance is Optimal: The network doesn't require more confirmations than necessary, ensuring fast finality
• Resources are Used Efficiently: Computational resources are allocated appropriately for the current network state
• User Experience is Consistent: Users always know how long to wait for finality, regardless of block rate

Future-Proof Design

Proportional scaling makes Kaspa future-proof. As the network evolves and implements higher block rates (potentially 32 BPS, 100 BPS, or even higher with DAGKnight), the BPS system ensures that security parameters automatically adjust. This eliminates the need for manual reconfiguration or security compromises when scaling.

This future-proof design is particularly important given Kaspa’s roadmap, which includes:

• Scaling to 10 BPS in the near term
• Potential scaling to 32 BPS with current technology
• Scaling to 100+ BPS with the DAGKnight protocol upgrade
• Continuous optimization and improvement of block generation rates

At each stage, the BPS system ensures that security and performance remain optimal without requiring fundamental changes to the consensus mechanism.

7.

BPS and Network Security

The relationship between BPS and network security is fundamental to understanding Kaspa’s architecture. The BPS system doesn’t just enable scaling—it ensures that security remains robust at any block generation rate.

Maintaining Attack Resistance

Many attacks on proof-of-work networks are time-based rather than block-based. For example:

• 51% Attacks: Require controlling the network's hashrate for a certain duration, not a certain number of blocks
• Reorganization Attacks: Attempt to rewrite history by mining an alternative chain, which requires time to build
• Double-Spending: Requires maintaining a longer chain for a certain period before revealing it

By scaling security parameters proportionally with BPS, Kaspa ensures that the time required for these attacks remains constant. A 51% attack that would require 10 minutes of network control at 1 BPS still requires 10 minutes at 10 BPS, even though 10× more blocks are created during that time.

GHOSTDAG Security at Scale

GHOSTDAG’s security properties depend on the K parameter, which determines how many blocks are considered when making consensus decisions. If K doesn’t scale with BPS, the protocol’s security guarantees degrade at higher block rates.

The BPS system ensures that K scales proportionally, maintaining GHOSTDAG’s security properties:

• Consistent K-Set Size: The K-set always considers blocks from the same time window, regardless of block rate
• Maintained Decentralization: Proportional K scaling prevents larger miners from gaining disproportionate advantages at higher block rates
• Attack Resistance: The time and computational requirements for attacks remain constant
• Consensus Stability: The network maintains stable consensus ordering even as block rate increases

Finality and Irreversibility

Finality—the point at which transactions become irreversible—is a critical security property. The BPS system ensures that finality time remains constant regardless of block rate, providing users with consistent security guarantees.

This is particularly important for:

• Merchants: Who need to know when they can safely consider a payment final
• Exchanges: Who need consistent finality times for deposit confirmations
• DeFi Applications: Which require predictable finality for smart contract execution
• Users: Who want to know when their transactions are truly secure

By maintaining constant finality time through proportional scaling, Kaspa provides predictable security that applications and users can rely on, regardless of the network’s current block generation rate.

8.

Future BPS Increases and Network Evolution

Kaspa’s BPS system is designed to support continuous scaling as the network evolves. The current path from 1 BPS to 10 BPS is just the beginning. Kaspa’s roadmap includes even higher block rates, and the BPS system ensures that security and performance remain optimal at every stage.

Near-Term: 10 Blocks Per Second

The immediate goal is scaling to 10 blocks per second, which represents a 10× increase from the current rate. This upgrade will demonstrate the BPS system’s effectiveness at maintaining security while dramatically increasing throughput.

At 10 BPS, Kaspa will be able to:

• Process 10× more transactions per second
• Provide faster confirmation updates (10 blocks per second instead of 1)
• Handle higher transaction volumes without congestion
• Maintain the same security guarantees as 1 BPS through proportional parameter scaling

Medium-Term: 32 Blocks Per Second

With further optimizations, Kaspa aims to reach 32 blocks per second. This would represent another significant scaling milestone, bringing Kaspa’s throughput to levels that can compete with or exceed many high-performance blockchain networks.

At 32 BPS, all consensus parameters would scale proportionally. Finality depth, merge depth, and GHOSTDAG K would all increase by a factor of 32 from the 1 BPS baseline, maintaining consistent time-based security guarantees.

Long-Term: DAGKnight and 100+ BPS

The DAGKnight protocol upgrade, currently in development, aims to enable even higher block rates—potentially 100 blocks per second or more. DAGKnight represents an evolution of GHOSTDAG that maintains security while enabling unprecedented scalability.

The BPS system is designed to work seamlessly with DAGKnight. As block rates increase to 100+ BPS, all parameters will continue to scale proportionally, ensuring that:

• Security remains robust at extremely high block rates
• Finality times remain predictable and consistent
• Network performance scales linearly with block rate
• The system can adapt to future increases without fundamental redesign

Continuous Evolution

The BPS system enables Kaspa to evolve continuously without compromising security. As the network implements optimizations, protocol upgrades, and new technologies, block rates can increase while the BPS system ensures that security parameters always match the current network state.

This evolutionary capability is one of Kaspa’s key advantages. Unlike networks with fixed parameters that require hard forks to change, Kaspa can scale organically as technology and network conditions evolve.

Conclusion

Blocks Per Second (BPS) Configuration is a fundamental innovation that enables Kaspa to scale block generation rate while maintaining consistent security guarantees. By making all consensus parameters proportional to block rate, the BPS system ensures that security is measured in time (which remains constant) rather than blocks (which change with block rate).

This proportional scaling mechanism is essential for Kaspa’s ability to scale from 1 block per second to 10 blocks per second, and potentially to 32, 100, or even higher rates in the future. At every stage, the BPS system ensures that finality depth, merge depth, GHOSTDAG K, and other critical parameters scale appropriately, maintaining optimal security and performance.

Understanding BPS is crucial for understanding how Kaspa achieves its unique combination of speed, security, and scalability. Unlike traditional blockchains that face a trade-off between these properties, Kaspa’s BPS system enables all three simultaneously, making it possible for the network to scale horizontally without compromising the security principles that make proof-of-work systems robust.

As Kaspa continues to evolve and implement higher block rates, the BPS system will continue to ensure that security and performance remain optimal, enabling the network to support real-world applications that require both high throughput and strong security guarantees.