Bit2 Premise and Architectural Principles

What properties must a payment network have to support agentic commerce?

From this question we derived a core premise and a set of architectural principles that would guide every design decision. These principles are not mathematical theorems or objective measurements. Rather, they are engineering convictions based on decades of combined experience in payment systems, distributed systems, cryptography, and high-performance computing.

Architectural principles are useful because they allow us to reject entire classes of solutions before investing years of development effort. A principle acts as a compass: when a design choice violates a principle, we know we are moving away from the original goal.

While simple to state, each principle carries enormous weight in the final design. Over time, extensive research, simulations, prototypes, and performance evaluations have only strengthened our confidence in them.

In this article we present the premise and architectural principles behind Bit2.

The Premise

Agentic commerce requires cheap, scalable, low-latency, deterministic, irreversible, private, policy-restricted, invoice-linked, multi-token transfers producing cryptographic receipts over a decentralized network.

From this premise we derived the following architectural principles.

Architectural Principles

Scalability

Scalability is achieved through timestamping aggregated commitments—a paradigm known as Client-Side Validation—not by expanding a blockchain's capacity to transmit, store, and verify ever-growing numbers of transactions, nor by pruning or trimming the blockchain. In our view, scalability should come primarily from reducing the amount of information that must be globally replicated, rather than increasing the amount of hardware required to participate in the network. The premise of low cost, determinism and the need for cryptographic receipts rule out Payment Channel Networks as the primary scalability layer: unidirectional payments channels can still be useful, but on top of a highly scalable network that can host billions of channels.

Bitcoin Anchor

The payment network anchor should be Bitcoin, as the most decentralized monetary network in existence.

Native Support for Stablecoins

The payment network should support stablecoins as first-class citizens.

Account-Based Ledger

The ledger should be account-based rather than UTXO-based.

Confidentiality

Transaction content must be fully confidential at the sender's discretion. The only metadata that may be exposed is transaction-frequency metadata associated with the sender, and only to a timestamping service provider—not to any other party.

Delegated Proving

Most of the proving burden should be shifted to third-party services, such as timestamping services, reducing the computational burden on clients. None of this delegation should affect transaction privacy.

Optional Sender-Side Proving

Zero-knowledge proving on the sender side should be optional. The protocol should remain secure even when the sender performs almost no computation, although privacy may be reduced.

Use-Case Agnostic Timestamping

Timestamping services must remain completely agnostic regarding the use case of the data being timestamped.

Extensibility

The design should be extensible to support Payment Channel Networks (PCNs), locally enforced smart contracts, and sophisticated authorization policies implemented through scripting engines or virtual machines.

Self-Custody

Users should retain full control over their Bit2 funds and their ability to transact, even if all timestamping services disappear.

L1 Efficiency

The system should minimize L1 storage and computation costs.

No Data Availability Layer

The system should not require a separate data availability layer. It should rely on the smallest amount of data that can be consumed by the L1.

Communication Model

Sender-receiver communication should be succinct, preferably one-way and asynchronous, while still supporting direct peer-to-peer delivery.

Timestamping Work Independence

The work performed by one timestamping service provider should be independent of the commitment frequency or timestamping volume of any other provider. No race conditions between providers should occur.

Pre-Confirmation Support

The system should support credible, low-latency pre-confirmations backed by economic guarantees.

Details

We now describe how each principle can be achieved in practice. Throughout this article, we refer to protocol participants as the sender, receiver, and Timestamp Service Provider (TSP).

Scalability

Scalability is primarily achieved by timestamping multiple Bit2 transactions within a single Bitcoin or L1 transaction.

To truly support agentic commerce, a Bit2 transaction should be compressed by at least a factor of 100 relative to a standard Bitcoin transaction. Additional scalability should be achieved through batching: packing many outputs representing distinct transfers into a single transaction. Importantly, batching must not weaken the privacy guarantees of individual payments.

This is arguably the strongest principle in the entire design, as it immediately rules out approaches based on creating ever-faster blockchains such as Tempo, Injective, or Base.

Bitcoin Anchor

The payment network anchor should be Bitcoin because it has demonstrated seventeen years of resistance to capture.

For the same reason, Bit2 should inherit settlement assurances from Bitcoin, support Bitcoin as a native asset, contribute to Bitcoin's usefulness as a payment network, and remain aligned with Bitcoin's original vision of peer-to-peer electronic cash that protects individual liberties.

This does not imply that Bit2 should support only Bitcoin.

Native Support for Stablecoins

Agents currently prefer transacting in stablecoins.

Therefore, the network should support stablecoins as first-class assets, together with whatever external compliance tools are necessary to satisfy issuer requirements. Ignoring stablecoins would mean ignoring the dominant medium of exchange currently used in on-chain commerce.

Account-Based Ledger

The design should be account-based rather than UTXO-based.

The primary reason is scalability. A UTXO must be referenced by a relatively large identifier that can only be compressed to a limited extent. By contrast, a 4-byte account identifier supports more than four billion active accounts.

Note that accounts can be single-use if desired. By emptying an account after each transfer, the account model can emulate many properties of the UTXO model.

Confidentiality

If a sender chooses to keep a transaction confidential, no party should learn anything about the payment except for the receiver who learns the token used, the amount transferred, the linked invoice, and the date or time at which the payment became confirmed on-chain.

For the first network release, we tolerate exposing the sender's pseudonym (account identifier) during timestamping events, but nothing about the underlying timestamped data.

This metadata leakage is relatively limited. Similar forms of metadata leakage exist in privacy-oriented systems such as Liquid or Railgun. Most privacy systems protect transaction-graph privacy while still leaking timing information, activity patterns, or network-level metadata.

Nevertheless, Bit2 requires a mechanism to ensure that this information is visible only to the sender's chosen TSP, allowing future protocol versions to further reduce metadata leakage.

Delegated Proving

Client-side proving should remain lightweight.

Proof generation should not require an uncontrolled super-polylogarithmic number of proof aggregations or recursive proof compositions. In particular, proving costs should not grow linearly with blockchain age, the number of assets held by a user, or the activity of unrelated users.

Ideally, each transfer should require only a constant number of proof recursions.

Whenever possible, proving should be limited to SHA-256 hashing, Poseidon hashing, and a small number of Schnorr signatures. Merkle proof verification is acceptable because it scales logarithmically.

Optional Sender-Side Proving

The sender should generate zero-knowledge proofs only when additional unlinkability is desired.

Otherwise, the sender may rely entirely on proofs generated by the TSP. The protocol remains secure, though potentially more traceable.

Use-Case Agnostic Timestamping

The TSP should see only commitments (hash digests), never their contents.

The service should not need to understand accounts, transactions, balances, or transferred amounts. A TSP should be nothing more than a generic commitment service and should not become a financial intermediary.

Clients should be free to pay for timestamping services using any payment mechanism, whether internal or external to Bit2.

Extensibility

The system should support future extensions such as payment channel networks interconnected through HTLCs.

In particular, it should support timelocks, sequence-number-based transaction replacement, and hashlocks.

Self-Custody

At no point should a user permanently lose the ability to access or spend funds.

Funds must never become trapped in a state where they can neither be spent nor recovered if the protocol is followed correctly.

This guarantee must not be replaced by economic penalties imposed on TSPs. Even large slashing penalties are not an adequate substitute for preserving access to user funds.

L1 Efficiency

The TSP should publish the smallest possible amount of information on L1.

Under realistic payment loads, Bit2 should consume no more than five bytes of L1 space per transaction.

Likewise, Bit2 should avoid large, fee-intensive smart-contract verification workloads on the L1 except when processing unilateral exits. Complex logic should remain isolated within bridge infrastructure.

No Data Availability Layer

Users should not be forced to depend on external data availability systems.

The only required external infrastructure should be Bitcoin itself.

Every additional infrastructure dependency introduces new trust assumptions, operational risks, and attack surfaces.

Communication Model

The amount of data exchanged between sender and receiver should remain small—ideally below 0.5 MB per transfer.

This enables efficient operation even on mobile devices and allows payments to complete within a 500-millisecond target under typical 5G upload speeds.

Communication should ideally be asynchronous and one-way. However, up to four network round trips may be tolerated if necessary.

Timestamping Work Independence

To enable healthy competition between TSPs, the workload of one provider should not depend on the activity of another.

TSPs should remain operationally independent, with costs influenced only by their own activity and unavoidable L1 congestion.

No race conditions between TSPs should be allowed.

Pre-Confirmation Support

To achieve low-latency payments, TSPs should provide credible assurances that a sender's commitment will be included in the next on-chain timestamping event.

For example, on Bitcoin, a sender might receive a pre-confirmation within 500 milliseconds even though the corresponding commitment transaction is expected to appear approximately ten minutes later.

The sender should be able to construct the transfer proof locally using TSP assurances and deliver it directly to the receiver. The receiver should not need to interact with the TSP and should remain free either to accept the pre-confirmation or wait for on-chain confirmation.

While TSPs may provide service guarantees, their liability should remain limited to the timestamping service itself and not extend to the underlying financial transaction.

Conclusion

Bit2 was not designed by starting with a blockchain and searching for a use case. It was designed by starting with a use case—agentic commerce—and working backwards to determine what properties a payment system must possess to support it.

Each architectural principle exists because we believe it eliminates an entire class of future bottlenecks, trust assumptions, privacy failures, or scalability limitations.

Some of these principles may appear restrictive. In practice, they have been liberating. They allowed us to discard countless architectures early and focus our efforts on a design that remains scalable, private, self-custodial, and efficient.

The true test of an architecture is not whether it performs well today, but whether it continues to perform well after ten years of growth, adversarial pressure, and changing requirements. These principles are our attempt to ensure that Bit2 remains relevant not only for the first generation of users, but for the first generation of autonomous economic agents.