Bit2 Scalability – Throughput for an Agentic Future

Introduction

As agent-driven interactions scale, payment systems must handle continuous, high-volume transaction flows generated by autonomous systems. From infrastructure usage to data exchange and service coordination, these environments demand networks capable of processing large numbers of small payments quickly, reliably, and in parallel.In this environment, throughput is not just a performance metric—it is a fundamental system property that determines whether a payment network can support real-world applications. A system that cannot sustain high throughput under bursty, concurrent demand will experience congestion, rising fees, unpredictable latency, and ultimately economic failure for small payments. For agentic commerce, where payments are frequent, parallel, and often machine-generated, scalability must be designed as a first-class property.

Maximum Transaction Throughput

A high maximum transactions per second (tps) is critical for any serious payment system because congestion directly becomes a reliability, cost, and product-design problem. As demand approaches the system’s limits, queues grow, fees increase, latency becomes unstable, and microtransactions become uneconomical.

Bit2 approaches this problem differently from traditional designs. Instead of relying on per-payment collateral, routing liquidity, or sequential execution, Bit2 leverages batch time-stamping of commitments combined with client-side validation.

• On Bitcoin, Bit2 can reach approximately 1.6K tps, using single-source batching (multiple outputs per transaction) it can reach 100K payments/second
• On an EVM sidechain, it can reach up to 40K tps, using batching it can reach 2.5M payments/second

These figures assume a high-performance batch time-stamping service implementation that fully exploits the parallelism inherent in the protocol: load balancing across servers, deterministic address-space partitioning, pipelining of commitments, and parallel proof generation. Importantly, these are not optimistic assumptions layered on top of the protocol—they are capabilities the protocol is explicitly designed to enable.

This creates a fundamentally different scaling path compared to other systems:

• Lightning Network: limited by liquidity, routing constraints, channel management, and HTLC limits
• Base: limited by a single sequencer and L1 batch posting bandwidth
• Ark: constrained by server coordination, round structure, and capital deployment
• RGB (non-aggregated): limited by per-transfer validation and lack of shared aggregation infrastructure

Sustained Single-Source Throughput

While global throughput is important, many real-world applications are bottlenecked by how fast a single device can continuously send payments.

A laptop, phone, or embedded controller may need to execute dozens of payments per second during bursts—paying for API calls, sensor data, energy usage, or coordination between agents. In these scenarios, the key question is not whether the network can eventually absorb the load, but whether a single wallet can sustain continuous payment flow without delays.

To make comparisons meaningful, we constrain payment latency to 1 second, limiting the amount of batching a sender can rely on.

We define sustained single-source throughput as the throughput achieved by:

• A single device
• Running one wallet
• Using one processor

Bit2 Performance

Bit2 performs strongly in this setting because it allows:

• A single sender to pay multiple receivers in parallel
• Aggregation of many payments into a single time-stamp commitment
• Minimal interaction with external parties

The sender is therefore primarily limited by local computation and bandwidth, not network coordination.

Estimated performance on a standard home laptop:

• ~100 payments/sec (non-private mode) → bandwidth-limited
• ~10 payments/sec (fully private mode) → computation-limited (e.g., Nova-based recursion)

Comparison with Other Systems

Lightning Network

Lightning is often described as supporting millions of payments per second globally. However, throughput between any two nodes is fundamentally constrained by the max-flow min-cut theorem: the maximum payment rate equals the capacity of the smallest cut separating sender and receiver in the channel graph.

In practice, this limit is further reduced by:

• Channel imbalance over time (shrinking directional liquidity)
• Routing failures and retry overhead
• Channel management complexity

Additionally, current implementations face practical bottlenecks:

• Database write constraints limit throughput to ~40 tps per node
• Each channel supports up to 483 concurrent HTLCs, yielding an upper bound of ~1500 tps per channel under idealized conditions

As a result, Lightning throughput is constrained not only by network structure but also by implementation limits and interaction requirements.

Base (Rollup Model)

Base can offer fast preconfirmations via a centralized sequencer, but single-source throughput is constrained by transaction queue limits:

• Maximum of 80 future nonces
• With ~2-second block times → ~40 tps per sender

Private transactions (e.g., via Railgun) introduce an additional bottleneck:

• SNARK proof generation can take 30+ seconds per transaction

Thus, throughput is limited both by sequencing constraints and proving costs.

Ark

Ark provides a user-friendly model but depends on:

• Server coordination
• Round-based execution
• Capital allocation and refresh cycles

This ties sustained throughput to system coordination and liquidity, rather than purely to sender-side compute.

INTMAX

INTMAX improves throughput by allowing transfers with up to 64 recipients per transaction, increasing batching efficiency. However:

• Each transaction requires a zero-knowledge proof
• Proof generation takes ~15 seconds or more, depending on hardware

As a result, proof generation latency becomes the dominant bottleneck, limiting sustained single-source throughput.

Conclusion

Bit2’s scalability comes from a fundamental architectural choice: decoupling transaction execution from global coordination and capital constraints, and instead relying on client-side validation and massively parallelizable time-stamping.

This allows Bit2 to scale along dimensions that other systems struggle with:

• No dependence on routing liquidity or channel balances
• No reliance on centralized sequencing throughput
• No per-transaction proof requirement in the common case
• Clean parallelism through deterministic partitioning

As agentic commerce emerges, payment systems will need to handle not just high average throughput, but massive concurrency, sustained single-device performance, and predictable execution under load.

Bit2 is designed for exactly that environment: a world where machines transact continuously, independently, and at scale.