Introduction
This post classifies off-chain payment mechanisms for user-provider payments. The classification guides architectural decisions for MVP development and future incentivization protocols across Logos services.
This post follows up on and supersedes Off-Chain Micropayments: Prior Work and Design Framework, which provides an overview of prior work including Decentralized Anonymous Micropayments (DAM), Orchid, and other relevant protocols.
Definitions and Assumptions
We aim to design a payment protocol for networks of users and service providers. The following definitions establish the core concepts.
Core Definitions
-
User: entity that pays to access services
-
Provider: entity that delivers services in exchange for payment
-
Off-chain state: data describing fund distribution among participants before on-chain settlement
-
Valid off-chain state: state confirmable on-chain assuming all parties remain online per protocol requirements
-
State transition: process of updating off-chain state through off-chain payments
-
State settlement: process of confirming valid off-chain state on-chain
Protocol Requirements
Our design targets four properties:
-
Performance: Off-chain payments must be cheaper than on-chain alternatives in latency and fees.
-
Security: The protocol must limit loss exposure.
-
Privacy: The protocol must break links between payments and service provision.
-
Extendability: The protocol must allow simple MVP versions that can be enhanced later.
Protocol Assumptions
We focus exclusively on user-provider use cases with unidirectional payment flows from users to providers. Users initiate protocols as payment sources. Providers never pay back to users. Provider-to-provider payments remain outside scope.
The protocol does not address cryptographically provable services. Instead, it assumes semi-trusted user-provider relationships with reputation tracking. In a pre-paid model (default), users cannot receive cryptographic guarantees of service delivery. They switch providers when unsatisfied. In a post-paid model, providers cannot guarantee payment from users. They terminate relationships with misbehaving users.
The party initiating settlement submits the settlement transaction. We abstract away on-chain fees.
Off-Chain Protocols Classification
Off-chain protocols enable payments without per-transaction on-chain interaction. They follow a three-stage structure: on-chain opening, off-chain operation, and on-chain closing.
Preventing double-spending is the core functionality of any payment protocol. Blockchains achieve this through global state storage under consensus. Every transaction becomes a write operation on global state. This creates scalability issues through fees and latency.
Three approaches address this inefficiency:
-
Make individual double-spend checks cheaper (ticket-based protocols, aka e-cash).
-
Shift from double-spend prevention to reactive detection and punishment (dispute-based protocols like payment channels).
-
Make most off-chain transactions inherently non-double-spendable, eliminating double-spend checks for the majority of payments (probabilistic payments).
Ticket-Based Protocols (E-Cash)
Ticket-based protocols reduce double-spend check costs through a centralized entity called Mint (following e-cash literature terminology). The Mint provides centralized ticket issuance and double-spend prevention. Double-spend checks occur on every payment but cost significantly less than blockchain-based verification.
Tickets function as anonymous bearer instruments. Any holder can redeem them through Mint submission (see Appendix A for comparison with receiver-bound tickets). Blind signatures separate ticket funding from usage, preventing the Mint from linking deposits to redemptions. Classical e-cash protocols including modern implementations like Cashu and Fedimint use this approach.
During each transaction, receivers consult the Mint for double-spend verification. This structure mirrors L1 with central double-spend checking but offers two cost advantages. First, centralization eliminates expensive consensus. Second, localized state maintenance covers only protocol participants rather than entire blockchain state.
The Mint controls ticket issuance through two mechanisms: direct issuance or user-declared ticket numbers that the Mint validates. The Mint maintains an unspent ticket registry until redemption. Mint involvement is mandatory: without it, users could double-issue tickets against single deposits.
Modern rollups and sidechains also represent Mint-based protocol incarnations. Operators (sequencers) maintain rollup state with periodic L1 anchoring.
Ways to address single point of failure concerns with a centralized Mint:
-
Committees with BFT consensus (e.g., Nym) remove single points of failure but can still censor via majority control.
-
Off-chain sharing of spent tickets (e.g., nullifier bulletin boards) increases decentralization at the cost of consistency (lack of consensus enables double-spends if nodes desynchronize).
Smart contract Mints face a performance paradox: requiring on-chain consultation for every state update degrades performance to L1 levels, defeating scalability objectives. Mint-based protocols make sense only when interaction with Mint is cheaper than with the blockchain.
Dispute-Based Protocols (Channels)
Dispute-based protocols avoid per-transaction double-spend checks by detecting and resolving conflicts on L1. Double-spends are only detected when conflicting transactions appear on-chain.
Dispute-based protocols bind payments to a single receiver, as in standard payment channels (see Appendix B for multi-receiver analysis). Single-receiver binding enables local double-spend prevention: receivers reject duplicate payments without global coordination. Double-spend risk emerges only when users attempt channel closure with outdated off-chain state. Such disputes become L1-evident, triggering conflict resolution.
Probabilistic Payments
Traditional protocols require double-spend checks for every transaction since all transactions can potentially be double-spent. Probabilistic payment (PP) protocols eliminate this requirement by making most transactions inherently non-double-spendable.
Probabilistic encryption renders payments valid with probability p (macro-payments) and invalid with probability 1-p (null-payments). Null-payments cannot be settled regardless of double-spending attempts, eliminating double-spend checking requirements for the majority of probabilistic payments. The DAM paper demonstrates that only macro-payments matter game-theoretically for double-spend prevention.
Macro-payments require standard double-spend checking via L1 consensus, dispute mechanisms, or centralized Mints. Existing implementations include L1-based systems (Macropay1, Orchid, DAM) and channel-based approaches (Probabilistic Lightning).
Probabilistic payments trade reduced double-spend checking frequency for increased payment variance. This yields resource savings across all underlying protocols. In ticket-based PP, only winning tickets require Mint communication. In dispute-based PP, parties can discard null-payments immediately, saving storage compared to vanilla channels where all states must be retained for potential disputes.
Classification Summary
L1 inefficiency stems from expensive per-payment double-spend verification. Three approaches address this: (1) cheaper double-spend checks via centralized or committee-based Mints, (2) reactive double-spend detection and punishment in dispute-based protocols, and (3) elimination of double-spend checks for most payments through probabilistic protocols.
See Appendix C for alternative theoretical formulations of double-spend prevention.
Ticket-Based vs Dispute-Based Protocols
Since probabilistic payments layer over any base protocol, the primary architectural decision reduces to choosing between ticket-based and dispute-based approaches.
Ticket-based protocols enable freely exchangeable bearer instruments supporting multi-provider setups. This flexibility requires trust in centralized or semi-centralized Mint entities for double-spend prevention. Advantages include fewer on-chain interactions for users and seamless provider switching, since tickets work universally across participating providers. This approach optimizes for scenarios with many small payments across diverse services.
Dispute-based protocols eliminate Mint dependency through reactive detection and L1-based punishment, operating exclusively with provider-bound payments. Local receiver checks prevent off-chain double-spending without global coordination. Key advantages include removal of single points of failure and straightforward cryptographic blame assignment (see Appendix D for details).
We argue for dispute-based protocols in our use case primarily to eliminate centralization inherent in Mint-based designs. Mint-based approaches face a fundamental trade-off: single-entity Mints violate decentralization goals, while committee-based Mints introduce consensus complexity without fundamentally solving centralization. Dispute-based protocols, in contrast, localize user-provider relationships and cryptographically prevent provider exit scams.
The trade-off is increased on-chain costs, as users must establish separate channels per provider. We address this through long-lived channels supporting top-ups, which is practical given users typically interact with a limited number of providers. For users prioritizing efficiency over decentralization, optional Aggregators can provide centralized payment routing (similar to LLM API gateways).
Our design deliberately avoids complexities of payment channel networks. By using only direct user-provider channels without multi-hop routing, we eliminate liquidity management and UX complexity issues typical for networks like Lightning. This simplified approach suits our specific use case of user-provider relationships within Logos services rather than general-purpose global payments.
MVP Protocol: Unidirectional Channels
Given this architectural choice, we now describe our MVP implementation. Let us start with a bare-bones MVP protocol for simple unidirectional payment channels. The following is a list of required operations.
User Operations:
-
Off-chain: Propose channel establishment with target provider
-
On-chain: Open channel (user-provider co-signed)
-
On-chain: Deposit funds into the channel (top-up)
-
Off-chain: Send individual payments
-
On-chain: Request balance withdrawal (initiates dispute window)
-
On-chain: Finalize withdrawal after dispute window expiration
-
On-chain: Close channel after complete fund withdrawal
Provider Operations:
-
Off-chain: Accept or reject user channel establishment proposal
-
On-chain: Withdraw current balance (without delays)
-
On-chain: Dispute user withdrawal requests (within the dispute window)
-
On-chain: Close the channel unilaterally (without delay)
Channel unidirectionality creates asymmetric dispute requirements. Providers require no dispute window since each state transition increases their balance (incentivizing honest closure), while users may attempt cheating via outdated state broadcasts favoring their balances.
UPD: Add an option for a collaborative channel closure pre-agreed off-chain.
Post-MVP Developments
Post-MVP enhancements introduce advanced payment mechanisms and operational features.
Streams
Streams enable gradual fund claiming over time (e.g., 10 cents per hour) versus one-off payments. Different services favor different approaches (in the context of Logos Messaging: one-off payments for Lightpush vs streams for Store). Open questions include whether channels can support both payment types simultaneously and the safety of allowing one-off payments during active streams. Any implementation must preserve exit rights with current state.
Receipts
Receipts shift risk distribution from users to providers via post-paid models. Pre-paid approaches (current default) place service delivery risk on users (payment is lost if the provider fails to deliver). Post-paid models require user-signed delivery receipts for payment redemption, transferring non-delivery risk to providers at the cost of additional protocol interactions.
Probabilistic Payments
Probabilistic payments in channel protocols reduce ZK proof generation costs and allow providers to discard null-payments immediately to save storage. The result is lower overhead compared to per-payment proofs or storing every transaction.
Slashing Mechanisms
Slashing penalizes cheaters but requires locked deposits, affecting usability. Reputation or hybrid reputation/slashing can reduce required collateral and suit different trust levels.
Sponsorship
Basic channels restrict funding to the opening user. Sponsorship extends this by allowing designated third parties to fund channels via shared cryptographic keys. ZK-proven hidden state ensures providers cannot identify sponsors.
Aggregators
Hub-and-spoke architectures reduce on-chain overhead for users. Users establish direct channels with aggregators that manage provider relationships, similar to LLM API gateways. This eliminates the need for users to open separate channels with each individual provider. This approach trades decentralization for operational simplicity and must balance aggregation benefits against centralization risks.
ZK-Chains as a New Base Layer
Our analysis assumes only Turing-complete smart contract capabilities (e.g., Ethereum). While UTXO-based implementations (e.g., Bitcoin) are theoretically possible, they require significantly more implementation complexity.
For practical Logos service deployment, we must select a specific blockchain as the settlement layer.
Privacy requirements make ZK-chains the natural choice. Transparent blockchains impose inherent privacy limitations. Channel funding transactions remain traceable, and rollup state is typically managed by centralized sequencers. ZK-chains use zero-knowledge proofs and ZK virtual machines to maintain private synchronized state, eliminating the need for off-chain privacy mechanisms and allowing protocols to focus purely on scalability.
ZK-chain implementations vary in private state management. Nescience, part of the Logos stack, separates public and private state domains. Alternative approaches include Aleo (private-only state) and Aztec (hybrid public/private state). Targeting Nescience aligns with strategic coordination of incentivization protocols across the Logos ecosystem.
The immediate next task is evaluating fundamental implementation barriers for the described protocol on Nescience. Absent significant roadblocks, Nescience becomes our primary blockchain target.
Summary
This proposal defines a user-provider off-chain payment channel protocol optimized for Logos services. We argue that dispute-based approaches better suit our decentralization requirements compared to inherently centralized Mint-based protocols. The MVP implements unidirectional payment channels with minimal on-chain overhead, deliberately avoiding multi-hop routing complexity. Post-MVP enhancements include streams, receipts, probabilistic payments, and slashing mechanisms. Nescience serves as the target privacy-preserving blockchain backend.
Update (December 2025)
Internal discussions shifted focus towards streams. Upon further analysis, streams and one-off payments emerged as distinct primitives. Separating payment protocols into stream-only channels and classical payment channels supporting only one-off payments is likely cleaner than combining both in a single primitive.
This distinction makes sense for several reasons:
-
Combining both payment types in one channel primitive introduces complicated edge cases even post-MVP. For example, a hypothetical “universal” channel protocol supporting both streams and one-off payments would need to account for whether each one-off payment affects deposit requirements of ongoing streams.
-
Different Logos services have different needs. Some suit classical channels better (Lightpush with one-off service requests), while others suit streams better (Store with time-based subscriptions).
-
The Nescience state model draws inspiration from Solana: programs are stateless and shared among all instantiations of a given protocol, while data is stored in program-owned accounts (in contrast to the Ethereum model where code and data co-exist within one contract entity). Under this architecture, streaming payments and one-off payments naturally map to distinct off-chain primitives implemented in independent programs.
Selecting which payment design to specify and implement first, streaming payments offer the following advantages:
-
Conceptual simplicity. Parties do not need to track outdated states. There are no disputes, whereas even in unidirectional channels with one-off payments the provider may need to dispute a user’s incorrect channel closure.
-
Store as the initial incentivized protocol. Store is currently planned as the first protocol to support incentivization, with streaming payments a better fit.
With these considerations, the next planned steps involve drafting a functional description of a payment streaming protocol (PR to follow to the Vac RFC repo) and ensuring it is suitable for implementation on top of Nescience.
References
-
MICROPAY1 and Orchid enable probabilistic micropayments using a coin-toss protocol on top of Bitcoin and Ethereum, respectively.
-
Probabilistic Lightning - 2017 research paper with PoC with coin-toss on top of Lightning API.
-
DAM describes more advanced probabilistic payments based on FMT encryption with unlinkability for null-payments.
-
Nym provides anonymous access to a mixnet with committee-issued credentials.
-
HOPR (RFC specs) uses payment channels with probabilistic tickets for a mixnet incentive layer.
-
Hidden Payment Channels - payment channels on top of Railgun and Ethereum.
-
Raiden - Ethereum-based payment channels.
-
SoK: Layer-Two Blockchain Protocols - systematization of knowledge on off-chain protocols as of 2019.
Appendix
Appendix A: Receiver-Bound vs Anonymous Tickets
Within ticket-based protocols, it only makes sense to consider anonymous tickets, not receiver-bound tickets. Receiver-bound tickets allow only specific receivers to enforce redemption. This approach functionally equals dispute-based off-chain protocols like channels.
Appendix B: Multi-Receiver Dispute-Based Protocols
Multi-receiver dispute-based protocols struggle with cross-provider double-spends without on-chain coordination. Resolving these requires off-chain provider communication, sharing evidence, and agreeing on transaction order. This adds protocol complexity and scales poorly, as all providers must synchronize spent states. Naive approaches incentivize instant redemption or risk double-claims. This reduces scalability to that of on-chain transactions. Trusting a coordinating entity among providers just recreates a Mint-like protocol.
Appendix C: Alternative Formulations of Double-Spend Protection
Double-spend protection equivalently formulates as transaction ordering or as state invalidation problems. Double-spend protection equals transaction ordering since conflicting transactions require “first” transaction determination. L1 consensus decides ordering for on-chain transactions. Ticket-based protocols use Mints as sequencers (these can be centralized servers, committees, or separate consensus networks). Dispute-based protocols achieve automatic off-chain transaction ordering through receiver bounding, with L1 ordering conflicting closing transactions only when necessary. The state invalidation perspective asks how off-chain protocols ensure only the latest state remains valid for L1 settlement. All off-chain states appear valid to L1 in isolation since each could be confirmed under certain conditions. Therefore, each off-chain state transition must simultaneously invalidate previous states. This process is known in payment channel literature as “state replacement.”
Appendix D: Penalty and Slashing Considerations
Penalty mechanisms require cryptographic blame assignment. This is challenging in multi-party protocols. Two-party protocols enable clear fault attribution: if Alice broadcasts an old state co-signed by Alice and Bob, Bob can prove Alice’s cheating attempt. Multi-party scenarios complicate blame distribution as innocent parties might suffer from equal penalty distribution. Mint-based protocols can resolve disputes and punish cheaters. However, they introduce additional trust assumptions in the Mint’s fairness and availability.