Layer-Top P2P State Channels

• Layer-top P2P state channels are off-chain overlays that enable rapid state evolution with blockchain-backed correctness, combining aspects of payment channels, replicated state machines, and cross-chain protocols.
• They separate operational execution from base-layer enforcement, using mechanisms like unanimous signatures, TEE-assisted certification, and relay-based synchronization for secure dispute resolution.
• Their design trade-offs involve scalability and performance versus infrastructural complexity, requiring additional layers such as Kafka or secure hardware to optimize off-chain interactions.

Searching arXiv for the cited papers and closely related work on layer-top peer-to-peer state channels. arXiv search query: (&&&^^^^1Process Channels1^^^^&&&) OR Parsec state channel Internet of Value arXiv search query: (Stiehle et al., 2023) OR "^^^^^^^^1Process Channels1^^^^^^^^" blockchain state channels arXiv search query: (Negka et al., 2023) OR ORIGAMI flexible state channels design public blockchain systems arXiv search query: (Liao et al., 2021) OR Speedster TEE-assisted state channel system arXiv search query: (Liu et al., 2024) OR FairRelay payment channel networks arXiv search query: (Liang et al., 2024) OR Interpipe cross-chain state channel recursive synchronization Layer-top peer-to-peer state channels are off-chain execution overlays in which participants exchange signed state updates while a blockchain remains the settlement, escrow, and adjudication substrate. In the literature surveyed here, this model appears as payment channels, generalized replicated state machines, process-enactment overlays, hierarchical multiparty channels, TEE-assisted certified channels, and cross-chain channels. The common architectural pattern is establishment on a base layer, off-chain state evolution, and on-chain fallback under non-cooperation, but the concrete realization ranges from routed bilateral channels and unanimous-signature multiparty protocols to certified channels backed by TEEs and relay-assisted cross-chain synchronization (&&&^^^^1Process Channels1^^^^&&&, Stiehle et al., 2023, Negka et al., 2023, Liao et al., 2021, Liang et al., 2024).

1. Architectural position in the blockchain stack

The defining architectural property of a top-layer state channel system is the separation between operational execution and base-layer enforcement. In Parsec, Ethereum is used for smart contracts, escrow-like control, scheduled settlement, unscheduled settlement, and disputed settlement, while invoices, signed invoices, streaming transaction propagation, sequencing, state maintenance, balance calculation, replication, and routing/interlocking functionality are kept off-chain (&&&^^^^1Process Channels1^^^^&&&). ^^^^^^^^1Process Channels1^^^^^^^^ makes the same separation explicit by describing state channels as “an overlay network on top of a blockchain,” with channel triggers and process-aware information systems carrying normal execution off-chain and the blockchain handling channel setup, disputes, and finalization (Stiehle et al., 2023).

This architectural split is not limited to balances. ^^^^^^^^1Process Channels1^^^^^^^^ models a state channel as an off-chain replicated state machine with state PRESERVED_PLACEHOLDER_^^^^1Process Channels1^^^^, transition function $step$, and commands $cmd_{i+1}$, but the off-chain state is a process-control state derived from a compiled interaction Petri net rather than a payment allocation. ORIGAMI extends the same idea to recursive multiparty composition, with a base protocol, group protocols, and app protocols, so that application-specific state channels can be built on top of other state-channel-like protocols after a single on-chain onboarding transaction (Stiehle et al., 2023, Negka et al., 2023).

The surveyed literature therefore treats “Layer-2” or “top-layer” less as a narrow taxonomy than as an operational criterion: the blockchain anchors correctness and recoverability, but ordinary interaction proceeds elsewhere. This suggests that layer-top P2P state channels are best understood as overlay state machines with blockchain adjudication, rather than as a single payment-specific primitive.

2. State evolution, coordination, and settlement semantics

Despite this shared architectural pattern, the mechanics of state evolution vary substantially across systems. Parsec uses signed off-chain transactions represented in an append-only event stream, with hash pointers and cryptographic signatures linking events; balances are updated incrementally, and settlement may occur periodically by modulo $m$ of the incremental transaction sequence number, after checkpoint_timeout, on unscheduled request, or in disputed form by submitting signed transactions since the last settlement (&&&^^^^1Process Channels1^^^^&&&). Its appendix defines Invoice(invoiceAddress, price, currency, invoiceType = "") and SignedInvoice(invoiceID, invoiceSignature, supplierAddress, buyerPublicKey, buyerAddress, currency, price, channel = DEFAULT_CHANNEL, hashPointerToPrevious), with ALLOWED_CURRENCIES = {"ETH", "BTC"}.

^^^^^^^^1Process Channels1^^^^^^^^ instead uses unanimous signed state transitions. The authorized initiator for the next task constructs $step_i$, increments the sequence number $i$, signs the proposal, and multicasts it. Other participants verify initiator authorization and local conformance, return $sig_{i,s}$, and install $newState_i$ only after all signatures have been collected and broadcast. The latest unanimously signed transition is the canonical off-chain committed state, and disputes submit a later signed transition $step_j$ with $i<j$ to the on-chain contract during the dispute window (Stiehle et al., 2023).

ORIGAMI introduces a different coordination mechanism for multiparty channels. Its state is represented as

$step$^^^^1Process Channels1^^^^

and progression from $step$1 to $step$2 requires $step$3. Multiple participants may propose updates concurrently, but only the proposal endorsed by the per-round header can gather the remaining signatures. The update field is typed and supports opening, closing, editing, add-user, and remove-user operations. Child channels are committed in the parent channel through an RSA accumulator rather than by explicit enumeration (Negka et al., 2023).

FairRelay specializes conditional settlement still further. It assumes a payment channel functionality $step$4 supporting lock(v, sid, cid, amt, \phi) and unlock(tx, w, s), and introduces the Enforceable Accumulative Hashed TimeLock Contract (Enforceable A-HTLC). Standard HTLCs are extended to multi-secret conditions $step$5, so that upstream unlocks depend on accumulated downstream secrets. In multipath mode, a synchronizer secret $step$6, lock receipts, and an on-chain enforcement challenge coordinate cross-path atomicity (Liu et al., 2024).

Speedster changes the state semantics more radically by replacing dispute-heavy signed-state replacement with TEE-maintained certified execution. A bilateral channel identifier is

$step$7

state transitions are executed inside enclaves as

$step$8

and updates are authenticated with symmetric encryption rather than public-key signatures: $step$9 Claims are exported to chain after channels are frozen, rather than adjudicated through a stale-state challenge game (Liao et al., 2021).

Interpipe preserves more conventional penalty-based channel logic but distributes settlement across two chains. Opening uses a jointly initiated transaction synchronization procedure, off-chain updates remain bilateral and signed, unilateral close uses a timeout $cmd_{i+1}$^^^^1Process Channels1^^^^, and stale publication is answered with a punishment transaction $cmd_{i+1}$1. What is novel is not the update rule itself but the cross-chain synchronization substrate that makes each chain verify the other’s channel-relevant state (Liang et al., 2024).

3. Peer-to-peer organization, overlays, and network structure

“Peer-to-peer” does not denote a single communication pattern in this literature. Some systems are direct bilateral overlays; some are multiparty overlays; some are service-assisted; some are relay-assisted. The following comparison captures the main architectural variants.

System	Layer-top organization	Distinctive mechanism
Parsec	Infrastructure layer on top of Ethereum	Apache Kafka, Kafka Streams, event sourcing
^^^^^^^^1Process Channels1^^^^^^^^	Multiparty overlay of channel triggers	BPMN-to-channel compilation, unanimous signatures
ORIGAMI	Recursive base/group/app channel hierarchy	Dynamic groups, unordered communication, header
Speedster	Direct certified channels over enclave accounts	TEE attestation, account-based shared collateral
FairRelay	Payment-channel application for P2P content delivery	Enforceable A-HTLC, lock receipts, synchronizer secret
Interpipe	Bilateral channel over relay-mediated cross-chain sync	Recursive state synchronization, JITS/UITS

This comparison shows that a layer-top P2P state channel need not be a purely direct wallet-to-wallet mesh. Parsec explicitly relies on Kafka clusters, topics, partitions, Parsec jobs, and control topics; ^^^^^^^^1Process Channels1^^^^^^^^ relies on deployed triggers and a channel contract; ORIGAMI uses recursive subgrouping rather than a flat graph; Interpipe depends on relay-node groups and a relay chain. By contrast, Speedster is explicitly framed as a “Fully Decentralized Channel Network” intended to avoid intermediated routing by making direct channel creation cheap and by reusing one enclave-protected account across many channels (&&&^^^^1Process Channels1^^^^&&&, Stiehle et al., 2023, Negka et al., 2023, Liao et al., 2021, Liang et al., 2024).

Where channels compose into routed networks, topology becomes a first-order issue. The Lightning Network study models LN as a weighted undirected graph $cmd_{i+1}$2 with capacity-weighted edges and reports, for a 2^^^^1Process Channels11^^^^9-^^^^1Process Channels11^^^^-^^^^1Process Channels1^^^^3 snapshot, $cmd_{i+1}$3 nodes, $cmd_{i+1}$4 payment channels, mean shortest path $cmd_{i+1}$5, degree assortativity $cmd_{i+1}$6, and empirical percolation thresholds $cmd_{i+1}$7, $cmd_{i+1}$8, and $cmd_{i+1}$9. The same study argues that LN is robust against random failures but vulnerable to targeted attacks, with only about 14–16% of carefully chosen node removals sufficient to collapse the giant component (Seres et al., 2019).

The game-theoretic literature reaches a structurally related conclusion from a different angle. In the network creation model of payment channels, player cost is

$m$^^^^1Process Channels1^^^^

and the social optimum is a complete graph for $m$1, a star graph for $m$2, and a path graph for $m$3. For weights the paper regards as appropriate for payment networks, the star is both socially optimal and a Nash equilibrium, yielding a price of stability of one. This suggests that hub formation is not merely an implementation accident but an equilibrium consequence of channel-opening cost, intermediation value, and path-cost minimization (Avarikioti et al., 2019).

4. Security, correctness, and dispute handling

The security model of layer-top P2P state channels is heterogeneous. Parsec relies on digital signatures, hash pointers, Ethereum smart contracts, and Hashed Timelock integration, but it does not provide a formal adversary model, theorem statements, or proofs of liveness or safety. Its protections against repeated messages and out-of-order delivery are operational rather than theorem-backed, notably the sliding array of the latest $m$4 transactions used to reconstruct exact order from hash pointers (&&&^^^^1Process Channels1^^^^&&&).

^^^^^^^^1Process Channels1^^^^^^^^ is more explicit about assumptions. It requires blockchain reliability, at least one honest participant, explicit role-binding, participant availability, and security of the generated off-chain protocol. Its guarantee table states integrity, immutability, non-repudiation, transparency, and equal rights under conditions such as storage of proof and access to the channel, while also noting that stalling is a non-attributable fault. Safety and liveness are inherited from the state-channel literature under those assumptions, but the resulting transparency and equal-rights guarantees are confined to channel membership rather than to universal public visibility (Stiehle et al., 2023).

FairRelay provides the strongest formal treatment among the surveyed systems. It proves in the UC framework that the Enforceable A-HTLC protocol $m$5 UC-realizes the ideal functionality $m$6, under static corruptions and access to authenticated channels, a global clock, a ledger, a payment channel functionality, and a Judge Contract. Its guarantees are fairness for provider, customer, and relayers, confidentiality against corrupted relayers when provider and customer are honest, and enforceability of secret revelation or compensation in stalled multipath settlement (Liu et al., 2024).

Speedster also gives a UC-style claim, but under a changed trust model. It assumes a global TEE attestation functionality $m$7, blockchain functionality $m$8, IND-CCA security of $m$9, and EU-CMA security of $step_i$^^^^1Process Channels1^^^^. Safety against stale-state publication follows from enclave-maintained monotone state and claim generation after freezing, not from a challenge-response dispute window. This removes standard stale-state races but replaces them with reliance on enclave integrity, attestation infrastructure, and resistance to rollback and side-channel attacks (Liao et al., 2021).

Interpipe’s security analysis is more informal. It claims consistency and resistance, assumes corruption fraction $step_i$1, and argues that state proofs $step_i$2, accumulator membership witnesses, and relay-mediated synchronization prevent inconsistent cross-chain recording and resist interruption of cross-chain synchronization. However, it does not provide a formal state-channel realization theorem, and timeout engineering around $step_i$3, synchronization rounds, and proof-generation delay remains underspecified (Liang et al., 2024).

ORIGAMI formalizes selected aspects, particularly the add-participant functionality $step_i$4, membership validity, balance security, and consensus on update. Its dispute design distinguishes header inactivity and member inactivity, and it explicitly aims to continue channel progress after unresolved inactivity by penalizing and excluding the unresponsive participant rather than terminating the whole channel. At the same time, it acknowledges that timers and practical connectivity requirements remain unresolved system-wide concerns (Negka et al., 2023).

5. Scalability, costs, and operational tradeoffs

Scalability claims in this area are best read system by system. Parsec claims that Apache Kafka can scale payment operations to “trillions of operations per day” and that payments are near-instant, low-fee, scalable, and privacy-sustainable, but the paper provides no benchmark tables, no throughput measurements, no latency distributions, and no head-to-head experiments versus Lightning or Raiden. Its performance argument is therefore architectural rather than empirical (&&&^^^^1Process Channels1^^^^&&&).

^^^^^^^^1Process Channels1^^^^^^^^ gives concrete gas measurements. For the Supply Chain benchmark, baseline deployment is $step_i$5 gas and baseline average execution per case is $step_i$6, while Leafhopper deployment is $step_i$7, best-case execution is $step_i$8, average execution in the bad case is $step_i$9, average execution in the worst case is $i$^^^^1Process Channels1^^^^, and on-chain task cost during dispute is $i$1. For Incident Management, the corresponding Leafhopper figures are deployment $i$2, best-case execution $i$3, bad-case average $i$4, worst-case average $i$5, and on-chain task cost during dispute $i$6. The paper states that deployment cost is amortized after 3 best-case runs, after 4 cases at a 2^^^^1Process Channels1^^^^% dispute rate, and that less than one best-case run can amortize one worst-case run (Stiehle et al., 2023).

FairRelay reports zero on-chain cost in optimistic scenarios and constant dispute costs independent of network complexity. The highlighted figures are 24,9^^^^1Process Channels1^^^^2 gas for a relayer’s Response and 29^^^^1Process Channels1^^^^,797 gas for a customer’s PoME, with a 1^^^^1Process Channels1^^^^-hop relay path incurring less than 1.5% additional overhead compared to pure data transmission. Judge Contract operations include Enforce at 267,325 gas and PoMM at 35,429 gas, while the protocol comparison reports 3 rounds and optimistic/pessimistic on-chain operations of $i$7 (Liu et al., 2024).

Speedster reports the most aggressive performance numbers, but under TEE assumptions. On two Azure SGX VMs it achieves payment throughput of $i$8 tps versus Lightning’s $i$9 tps, with about $sig_{i,s}$^^^^1Process Channels1^^^^ ms latency versus about $sig_{i,s}$1 ms, an improvement of $sig_{i,s}$2. The abstract also claims about $sig_{i,s}$3 throughput improvement and 97% less on-chain data with a comparable network scale; the 97% figure is tied to amortizing one deposit and one claim over at least 11 channels, yielding average on-chain transactions per channel of $sig_{i,s}$4 (Liao et al., 2021).

Interpipe shows the opposite profile: off-chain updates are relatively close to intra-chain state channels, but lifecycle operations become slow. Its reported latencies are 12.5 min for opening, 1^^^^1Process Channels1^^^^5 ms for updating, 13.4 min for JITS closing, 29.5 min for UITS closing, and 36.9 min for disputing, versus 3.6 min, 62 ms, 3.7 min, 3.7 min, and 5.5 min for the intra-chain baseline. The paper therefore supports the narrow claim that a cross-chain state channel can be nearly as efficient as an intra-chain state channel for updates, not for opening, closing, or dispute (Liang et al., 2024).

Across the literature, a common tradeoff appears. High off-chain efficiency usually comes with stronger assumptions or more infrastructure: Kafka clusters in Parsec, generated triggers and role-binding in ^^^^^^^^1Process Channels1^^^^^^^^, TEEs in Speedster, relay-chain synchronization and recursive SNARKs in Interpipe, or application-specific Judge Contracts and synchrony in FairRelay. This suggests that scalability in layer-top P2P state channels is often obtained by shifting complexity away from the base chain, not by eliminating it.

6. Limits, misconceptions, and research directions

A recurrent misconception is that “P2P” implies purely direct bilateral message exchange and nothing more. The surveyed papers do not support that narrow reading. Parsec is mediated by a distributed event log and stream-processing substrate; ^^^^^^^^1Process Channels1^^^^^^^^ relies on triggers, choreography compilation, and a channel contract; ORIGAMI relies on a recursive hierarchy of base, group, and app protocols; Interpipe relies on relay groups and a relay chain. Only some systems, notably Speedster, explicitly try to eliminate intermediated routing altogether (&&&^^^^1Process Channels1^^^^&&&, Stiehle et al., 2023, Negka et al., 2023, Liao et al., 2021, Liang et al., 2024).

A second misconception is that state channels are synonymous with payment channels. The literature here spans payment allocation, workflow state, process-control state, content-delivery fee-secret exchange, generalized app channels, and cross-chain channel state. ^^^^^^^^1Process Channels1^^^^^^^^ shows that the off-chain state may be “where the process instance currently is and which task may validly occur next,” ORIGAMI treats app protocols as arbitrary state-channel-compatible applications, and FairRelay treats channel conditions as programmable witnesses over multi-secret locks rather than simple one-preimage HTLCs (Stiehle et al., 2023, Negka et al., 2023, Liu et al., 2024).

A third misconception is that off-chain execution removes online requirements and disputes. ORIGAMI explicitly says timers remain a requirement and names built-in connectivity support as future work. ^^^^^^^^1Process Channels1^^^^^^^^ requires participants to remain available and to watch for stale-state disputes. FairRelay requires active monitoring by provider, customer, and relayers in the absence of watchtowers. Interpipe still needs online observation of stale unilateral close and timely UITS-based punishment. The practical availability burden is therefore reduced only in some designs, not abolished (Negka et al., 2023, Stiehle et al., 2023, Liu et al., 2024, Liang et al., 2024).

The research directions identified in the papers are correspondingly diverse. ^^^^^^^^1Process Channels1^^^^^^^^ proposes optimizing latency and confidentiality, better dispute phases, dynamic role assignment, and confidentiality-preserving disputes via zero-knowledge proofs. FairRelay identifies eliminating on-chain deposits, improving fault tolerance beyond the “all relay paths must succeed” design, and addressing front-running attacks on deposits. ORIGAMI points to a built-in mechanism that bypasses the constant connectivity requirement and to a more extensive security analysis of the full design. Interpipe leaves timeout engineering, contract-level realization, and more rigorous formalization open. Speedster suggests that committee-based TEE replication could address node failure, but that extension is outside the base protocol (Stiehle et al., 2023, Liu et al., 2024, Negka et al., 2023, Liang et al., 2024, Liao et al., 2021).

Taken together, the literature presents layer-top P2P state channels not as a single protocol family but as a broad design space for moving authoritative state evolution off-chain while preserving blockchain-backed recoverability. The unifying idea is stable across the surveyed work; the unresolved questions concern how much infrastructure, synchrony, trust, collateral flexibility, routing structure, and application specificity a given deployment is willing to accept.