Agentic Payments Must Not Require Liveness

The next generation of digital payments must not only be fast and scalable—it must also be compatible with long-term secure storage. Hardware wallets have become the standard for safeguarding high-value assets, precisely because they allow keys to remain offline for extended periods. However, many modern payment systems implicitly assume that wallets remain online, responsive, and continuously monitoring the network. This creates a fundamental tension between usability, security, and long-term storage.

The Liveness Problem

A key obstacle to hardware-wallet compatibility is liveness: the requirement that a wallet must react within a bounded time to external events, often originating from the blockchain or a coordinating service.

In systems with liveness requirements, failing to act in time can result in partial or total loss of funds. This assumption is incompatible with hardware wallets, which are typically stored offline for weeks, months, or even years.

Liveness Requirements in Existing Systems

• The Lightning Network requires periodic monitoring of the blockchain. Users must detect unilateral channel closures and respond within a dispute window. If they fail to do so, a counterparty can broadcast an outdated state and claim funds. While watchtowers mitigate this risk, they introduce additional trust, complexity, and operational overhead.
• Ark also imposes a form of liveness. Users must periodically interact with the Ark server to migrate funds into new virtual UTXO trees. If the user remains offline for too long, they risk losing access or being forced into more complex recovery paths.
• Rollups occupy an intermediate position. Users can keep funds in a hardware wallet, but they must remain aware of exit windows. If the sequencer halts permanently, users have a limited time to submit exit transactions on L1. Missing this window can lead to funds being locked or delayed indefinitely.

Client-Side Validation: Removing Liveness

Client-side validated payment systems—such as Bit2—take a fundamentally different approach. Instead of requiring users to monitor the system continuously, they shift validation responsibilities to the transaction participants themselves.

This architectural choice eliminates the need for periodic liveness:

• No requirement to monitor the blockchain for adversarial actions
• No requirement to stay connected to a server
• No bounded reaction windows that threaten funds

A user can safely store funds in a hardware wallet, disconnect it completely, and return at any time without risk of losing funds due to inactivity.

The Real Requirement: Data Availability, Not Liveness

Client-side validation replaces liveness with a different requirement: state availability.

To spend funds, the user must possess their local transaction history or a compressed proof of it. If this data is lost, the funds become unspendable—even if the user still holds the private keys.

This shifts the problem from “being online at the right time” to “preserving the right data.”

Importantly, this requirement aligns much better with hardware wallets and cold storage:

• Data can be backed up asynchronously, without time pressure
• Backups can be encrypted and replicated across multiple locations
• No adversary can exploit temporary inactivity

In practice, wallet software can automatically create encrypted backups of the client-side state and store them in cloud services or personal storage. These backups are only updated when the user transacts, not while funds remain idle.

Cold Storage Compatibility

This distinction is crucial. With client-side validation:

• A user can move funds to cold storage (paper wallet or hardware wallet) and remain offline indefinitely
• There is no need to delegate monitoring to third parties
• There is no penalty for inactivity

The only operational requirement is to preserve the latest valid state before going offline. Once stored, the system behaves like a traditional self-custodial asset, but without the surveillance and data-availability costs of on-chain systems.

Conclusion

Hardware wallets are designed for long-term, offline security. Payment systems that require continuous liveness fundamentally conflict with this model, introducing risks that are difficult to mitigate without additional trust or complexity.

Client-side validation, as exemplified by Bit2, resolves this tension by eliminating time-critical dependencies. It replaces fragile liveness assumptions with robust data-availability requirements that can be satisfied through simple, asynchronous backups.

As agentic commerce evolves—where machines transact continuously but humans safeguard capital—the ability to combine always-online payments with always-offline security becomes essential. Client-side validated systems uniquely enable this combination, making them the natural foundation for hardware-wallet-friendly payment networks.