Extending Bit2 with Client-Side Smart Contracts

Introduction

Most people associate smart contracts with blockchains such as Ethereum, where every contract is executed by every validating node. This provides strong consensus guarantees, but it also makes computation expensive, public, and fundamentally limited by the blockchain's throughput.

However, many payment applications do not require global consensus. Spending policies, payment authorizations, recurring payments, subscriptions, escrow agreements, and many conditional transfers involve only the parties participating in the payment. There is little value in forcing the entire network to execute and store these contracts.

Bit2 follows a different philosophy: only information that truly requires global consensus should be published on-chain. Contract execution that affects only the participants of a payment should remain client-side whenever possible. Bit2 extends client-side validation with a lightweight virtual machine that enables programmable payment logic while preserving privacy, scalability, and self-custody.

Programmable Spending Controls

Programmable spending controls are essential for machine-to-machine commerce because autonomous agents operate continuously and may control funds without direct human supervision. Without enforceable constraints, a compromised agent—or even a benign agent interacting with a malicious counterparty—could rapidly drain its entire balance. Attackers may exploit software bugs, manipulate APIs, or craft adversarial interactions that trick an agent into authorizing unintended payments.

Spending policies provide a critical safety layer by limiting the potential damage. Rate limits can cap losses over time, whitelists can restrict payments to trusted counterparties, and human-authorization rules can require manual approval for high-value transactions. In large-scale agent ecosystems, these controls are not optional safeguards—they are fundamental requirements for safely delegating financial autonomy to software while maintaining predictable risk exposure.

Today, most agentic payment systems achieve these guarantees by sandboxing the agent. Agents never receive direct access to wallet private keys. Instead, they communicate through the Model Context Protocol (MCP) with an external wallet service that exposes an MCP endpoint and decides whether to authorize each payment.

For example, Coinbase's AgentKit wallet operates as an independent service with configurable spending limits, per-session budgets, transaction quotas, and hardware-protected keys running inside Trusted Execution Environments (TEEs). Privy Server Wallets follow a similar architecture.

While this model satisfies many enterprise security requirements, it ultimately delegates trust to the wallet provider. It is not a self-sovereign solution. Even when users operate the wallet server themselves, the software generally cannot protect them from their own mistakes or from a compromised operating system that gains access to the signing keys.

Bit2 takes a different approach. Instead of relying on an external authorization service, Bit2 will provide a lightweight virtual machine that allows users to define programmable spending policies directly as part of their wallet logic. These policies become cryptographically enforceable without giving third-party services custody over user funds.

For example, a user could authorize an AI agent to spend at most $50 per hour, only interact with approved merchants, require human approval for transactions exceeding a configurable threshold, or restrict certain tokens to predefined applications.

This naturally complements hardware wallets. Users may safely keep the majority of their assets in cold storage while periodically transferring limited amounts into programmable wallets whose spending capabilities are intrinsically restricted by their own scripts.

Unlike traditional smart contracts, these spending policies do not consume blockchain execution resources. They are evaluated only by the parties involved in the payment, allowing contract complexity to scale with the number of users rather than with the capacity of the underlying blockchain.

Payment Composability

Programmable spending controls naturally extend to a broader concept: payment composability. Payment composability is the ability to embed payments inside conditional workflows whose execution depends on external events, cryptographic proofs, or other payments.

For example, Alice may create and timestamp a transfer containing several alternative recipients for the same funds. The final recipient is determined by evaluating a predefined condition at some point in the future. Alice distributes the transfer proof to all potential recipients, knowing that only one of them will ultimately satisfy the spending conditions.

This mechanism enables atomic protocols without requiring blockchain scripting. As an example, Alice and Bob may atomically swap two assets. Each party first creates a conditional transfer together with a refund path protected by a timeout. The first party chooses the longer timeout to guarantee safety. Each conditional payment references the proof generated by the other party, ensuring that either both transfers succeed or both participants recover their original funds.

More generally, client-side smart contracts allow entire payment protocols to be expressed as exchanges of cryptographic proofs rather than as globally executed smart contracts.

Comparison with Existing Systems

Bit2 is not the first client-side validation protocol to support programmable logic, but its approach differs from existing systems.

RGB supports client-side contract execution and offers expressive scripting capabilities attached to RGB assets. However, RGB contracts primarily describe asset state transitions, whereas Bit2's virtual machine is designed around programmable payment policies and payment authorization.

Ark has introduced ArkadeOS, which explores programmable payment workflows around Ark's service-provider model. However, execution remains closely tied to Ark's server-assisted architecture, whereas Bit2's scripts are intended to remain valid even if Timestamp Service Providers become unavailable.

By contrast, the Lightning Network provides only a limited form of programmability through HTLCs, PTLCs, and timelocks. These primitives are sufficient for payment routing and atomic swaps but cannot express general spending policies, rate limits, authorization rules, or richer application logic.

Conclusion

Client-side validation should not merely replace blockchain consensus for payments—it should also replace it wherever global consensus is unnecessary.

By moving programmable payment logic to the wallet itself, Bit2 enables users to define sophisticated spending policies, automate financial workflows, and compose complex payment protocols without burdening the blockchain or sacrificing privacy.

This reflects a broader design philosophy: blockchains should establish facts that require global agreement, while everything else should remain local. As agentic commerce grows, we expect an increasing fraction of financial logic to execute at the network's edge rather than at its center.

Programmable spending controls are only the first step. As Bit2 evolves, client-side smart contracts will enable increasingly sophisticated payment applications while preserving the scalability, confidentiality, and self-sovereignty that define the protocol.