UniPCH: A Unified Framework for Cross-Chain Payments via Payment Channel Hubs

I. INTRODUCTION

• Cross-chain transfers face heterogeneous transaction rules and execution environments, while public records can reveal payment relationships and frequent on-chain interactions incur latency and fees.These concerns motivate combining interoperability with security, privacy, and efficiency.Source: §I · p. 1

II. RELATED WORK

• Supporting a new ledger model can require a new channel realization, protocol adaptation, and security analysis because existing flows depend on ledger-specific transaction and channel procedures.Some schemes leave ledger-level channel realizations unspecified; BlindHub and XPCH target UTXO ledgers, while EC2P uses separate protocols for transfer directions.Source: §I · p. 2, §II · p. 3

I. INTRODUCTION

• UniPCH separates ledger-specific channel execution from private payment logic, using UniPC interfaces to coordinate heterogeneous channel realizations without interpreting native transactions.The framework provides UTXO and smart-contract account realizations; other environments can be incorporated through conforming realizations.Source: §I · p. 2
• UniPC separates authorization-task evidence from confirmation of the complete candidate channel state, with selective refresh retaining valid evidence and refreshing affected tasks.The framework specifies common update semantics and security requirements for channel realizations.Source: §I · p. 2
• S-RBCS binds conditional authorization across hubs to realization-specific tasks, and the resulting protocol coordinates homogeneous and mixed-ledger paths while preserving security and privacy.The protocol also reduces unnecessary sequential interactions.Source: §I · p. 2
• The authors formalize component and system security and evaluate a Go prototype, reporting competitive efficiency, cost trends for both realizations, and benefits from selective evidence refresh.UniPCH’s shared semantics and interfaces are presented as reusable across heterogeneous ledgers, unlike schemes tied to particular ledger types or transfer directions.Source: §I · p. 2, §II · p. 3

III. PRELIMINARIES

• Blind randomizable signatures, adaptor signatures, re-signing adaptor signatures, and linear-only encryption provide credentials, conditional transfer completion, evidence refresh, and randomized encrypted payment conditions.The paper relies on their stated correctness and security properties, including blindness, unforgeability, witness extractability, and confidentiality under randomization.Source: §III · p. 4
• S-RBCS builds on RBCS to bind condition propagation across hubs to UniPC authorization tasks and refresh the evidence required by each realization.RBCS combines blind randomizable credentials, linear-only-encryption ciphertexts, and re-signing adaptor signatures for linked conditional authorizations.Source: §III · p. 4

A. Environment

• The system assigns each blockchain a local hub and connects hubs through bilateral channels on a common blockchain; a payment path links sender, access hubs, a coordinating hub, and receiver.For a full path with three distinct hubs, the four channels lie on the sender’s chain, two hub channels on the common chain, and the receiver’s chain.Source: A. Environment · p. 4
• Payments execute in ordered phases under synchronized clocks, fixed exchange rates, authenticated confidential internal channels, anonymous sender-receiver communication, and bounded blockchain confirmation delays.Updates to a channel are processed sequentially against its latest installed state.Source: A. Environment · p. 4

B. Our Framework

• UniPC maps candidate updates to native transactions or contract calls, separates task evidence from complete-state confirmation, and installs updates only after required evidence and both confirmation signatures are obtained.Its interfaces coordinate heterogeneous realizations without requiring the upper protocol to interpret native transactions.Source: B. Our Framework · p. 5
• Reserve, Promise, Convert, and Solve move from sender reservations and a credential to receiver-side prepayment, conditional sender prepayments, and ordered claims.Randomizing the credential and encrypted payment condition hides the sender-receiver association; each realization derives its own authorization and refresh tasks.Source: B. Our Framework · p. 5

C. Security

• UniPCH’s security goals require accepted channel states to be valid, fully authorized, jointly confirmed, value-preserving, fresh, and consistent in their terminal outcomes.The system-level goals also require economic atomicity, griefing resistance, and session unlinkability among payments with the same coordinating hub and agreed amount.Source: C. Security · p. 5

A. State and Operations

• UniPC represents channel state with spendable balances and active items, and admissible operations update that state while preserving the conservation invariant.Items represent locked funds or conditional prepayments; claimed or refunded items are removed and cannot be consumed again.Source: A. State and Operations · p. 6

V. UNIPC

• A ledger realization may add native fields, but must preserve UniPC’s operation effects and invariant so the upper-layer protocol can use the same six operations across realizations.Fig. 3 depicts the state transitions and authorization lifecycle used to install a selected candidate.Source: A. State and Operations · p. 6, Figure 3 · p. 6

Authorization and State Installation

• A candidate update is prepared from the current state, operation, and inputs, producing a candidate state and the complete set of tasks required to authorize it.The realization derives the tasks, including all participant authorizations required by its native encoding.Source: B. Authorization and State Installation · p. 7
• Existing verified evidence is retained for tasks that remain valid, while new evidence is collected for tasks requiring refresh before completion checks all tasks.The retained and refreshed evidence together form the evidence set used to determine whether the candidate is fully authorized.Source: B. Authorization and State Installation · p. 7
• Both participants confirm the candidate state only after its task evidence is complete, and installation requires verification of both confirmation signatures.If required evidence or either signature is unavailable, Abort preserves the preceding record.Source: B. Authorization and State Installation · p. 7
• A secure realization must provide transition correctness, authorization security, state freshness, and settlement consistency.These properties require admissible installed updates, valid task evidence and bilateral state confirmation, protection against obsolete terminal states, and no conflicting claim and refund outcomes.Source: B. Authorization and State Installation · p. 7

UTXO Realization

• The UTXO realization encodes channel balances and active items in a commitment transaction, with descendant transactions implementing permitted terminal actions.Transfer outputs support claim and timelocked refund paths; replacing the commitment changes claim-transaction messages, so all active transfer tasks require refreshed evidence.Source: C. Realizations · pp. 7–8
• Under unforgeability assumptions and correct, timely UTXO-ledger validation, the UTXO realization satisfies UniPC’s security definition.The shared transfer output prevents claim and refund branches from both settling, while revocation and stale-state handling prevent obsolete commitments from replacing the latest jointly confirmed balances.Source: C. Realizations · p. 8

Account Realization

• The account realization stores deposits in a channel contract and maintains jointly authorized states off-chain, with the contract processing signed states for on-chain settlement.Its state digest binds the channel identifier, version, balances, and complete active-item set; unchanged transfer tasks can be retained when another item is updated.Source: C. Realizations · p. 8
• Under collision resistance, signature unforgeability, and correct, timely contract execution, the account realization satisfies UniPC’s security definition.For stable identifiers, an update normally refreshes only a newly created transfer task rather than all existing transfer evidence.Source: C. Realizations · pp. 8–9

A. Payment Path and UniPC Invocation

• UniPCH executes payments in epochs over paths connecting sender and receiver access hubs through a coordinating hub, omitting edges when a role coincides with that hub.When both endpoint hubs equal the coordinating hub, the path reduces to a single-hub payment.Source: A. Payment Path and UniPC Invocation · p. 9

B. S-RBCS

• S-RBCS binds anonymous credentials and randomized conditions to UniPC tasks, selectively refreshing affected evidence across the linked authorizations.Its Reserve, Promise, Convert, and Solve procedures reserve the sending path, prepare the receiving path, convert reservations, and complete linked authorizations.Source: B. S-RBCS · pp. 9–10
• Near operations connect an endpoint directly to the coordinating hub, while Far operations reach it through an access hub; each existing edge uses the corresponding UniPC operations.Which authorization tasks need refresh depends on the channel realization: UTXO transaction replacement can affect tasks, whereas stable account identifiers normally add only a new transfer task.Source: B. S-RBCS · p. 9
• S-RBCS security comprises correctness, task unforgeability, unlockability, and blindness, with the construction proven under its stated cryptographic assumptions.The theorem’s assumptions include hardness of OMDL, collision resistance of H, and specified properties of the signature, encryption, authorization, and zero-knowledge components.Source: B. S-RBCS · pp. 9–10

C. Payment Protocol

• The protocol uses Reserve, Promise, Convert, and Solve to coordinate channel operations across a payment path that may mix UTXO and account realizations.In the example, cS,HS uses a UTXO UniPC, while cHR,R and channels between hubs use account UniPCs.Source: C. Payment Protocol · p. 10
• Reserve jointly confirms sender-side escrows before the sender derives a credential and sends it to the receiver.The hubs verify commitment and adjacent reservation evidence along the path before returning a blind-signature response.Source: C. Payment Protocol · p. 10
• Promise uses the credential to install receiver-side transfers, which are jointly confirmed before the receiver sends its response to the sender.The coordinating hub checks that the credential is unused, then creates a condition and proof for the transfer path.Source: C. Payment Protocol · p. 10
• Convert replaces sender escrows with transfers conditioned on Y2, while receiver transfers remain conditioned on Y0.Each candidate is authorized, confirmed, and installed through its own Apply; endpoint randomizers remain hidden from intermediate access hubs.Source: C. Payment Protocol · p. 11
• Solve propagates the extracted witness through claims on the sender and receiver paths, completing settlement across the channels.Hub roles determine which claim operations are used, and completed transfer signatures are checked against stored tasks before installation.Source: C. Payment Protocol · p. 11

D. Failure Handling

• During cooperative failure recovery, participants submit the latest jointly confirmed state before its refund deadline so it can become enforceable on the ledger.Unconverted escrows and transfers whose witnesses have not appeared use their respective refund operations after their deadlines.Source: D. Failure Handling · p. 11
• The UTXO realization uses commitment transactions, timelocked item scripts, and mechanisms such as revocation keys for terminal actions; the account realization uses sequence numbers and a challenge period.In the account realization, a jointly signed higher-version state supersedes a lower-version state.Source: D. Failure Handling · p. 11

VII. SECURITY ANALYSIS

• Theorem 4 establishes local UniPC security across polynomially many sessions when every channel realization on each payment path satisfies Definition 1.The proof applies a union bound over path edges and sessions.Source: §VII · p. 11
• Theorem 5 establishes griefing resistance against malicious receivers when senders and an honest coordinating hub follow the protocol and ΠBRS is unforgeable.An honest hub’s receiver prepayment must be backed by a distinct Reserve session with jointly confirmed sender reservations.Source: §VII · p. 11
• Theorem 6 establishes economic atomicity when channels satisfy local security, S-RBCS meets its stated clauses, the four phases follow their prescribed order, and claim timing satisfies condition (25).An honest endpoint either completes its transfer or recovers locked funds; an honest intermediate hub’s claimed outgoing item is backed by an incoming item of the agreed value.Source: §VII · pp. 11–12
• Claims proceed in a deadline order that leaves time for state submission, witness handling, message delivery, and ledger confirmation between successive claims.If propagation stops, an honest payer can enforce the latest state and recover an unclaimed escrow or transfer through its refund operation.Source: D. Failure Handling · p. 11, §VII · p. 12
• UniPCH satisfies session unlinkability if S-RBCS satisfies blindness, within the anonymity set determined by L.The definition makes the epoch, coordinating hub, and payment amount public, while hiding endpoint-channel messages.Source: §VII · pp. 11–12

S-RBCS.

• UniPCH satisfies session unlinkability by reduction to S-RBCS blindness, connecting larger anonymity sets through pairwise swaps.The blindness view includes credential issuance, randomized ciphertext-statement pairs, adjacent task evidence, and public-ledger observations.Source: S-RBCS · p. 12

VIII. EXPERIMENTS

• The evaluation compares phase running time and bandwidth with A2L+, P2C2T, and XPCH, and varies network delay and system parameters.The evaluated parameters include blockchain count, users per blockchain, and payments per user.Source: §VIII · pp. 12–13, A. Experimental Setup · p. 13

A. Experimental Setup

• The Go prototype implements UTXO and account realizations, with all compared schemes run in the same experimental environment.The default deployment uses six blockchains, 50 users per blockchain, and five payments per user; the compared schemes use the same payment set.Source: A. Experimental Setup · p. 13

B. Comparison Experiment

• EF reduces running time by 25.7% relative to XPCH-F and 27.2% relative to BF, while selective refresh cuts runtime by 2.0% on Near and 28.5% on Far versus FR.All tested UniPCH configurations are faster than the comparison schemes; A2L+ has the lowest runtime but cannot execute multiple payments within the same epoch.Source: Table II · p. 13, B. Comparison Experiment · p. 13
• EF uses 52.5% less bandwidth than XPCH-F and 62.8% less than BF; selective refresh cuts bandwidth by 7.1% on Near and 63.3% on Far versus FR.A2L+ uses 20.03 KB, while P2C2T requires 161.2 KB; BN and EN use 9.0% more bandwidth than XPCH-N, and BF uses 27.4% more than XPCH-F.Source: Table II · p. 13, B. Comparison Experiment · p. 13
• UniPCH-E generates 95.2% fewer adaptor pre-signatures per payment than UniPCH-B, and selective refresh reduces the count by 95.4% relative to UniPCH-FR-E.UniPCH-B and UniPCH-E use the same endpoint channel realizations; E reuses evidence on channels between hubs.Source: Table III · p. 13, B. Comparison Experiment · p. 13

C. Evaluation of Network Delay

• Under emulated delay, BN and EN reduce runtime by 14.8% and 14.7% versus XPCH-N, while BF and EF reduce it by 8.5% and 16.6% versus XPCH-F.The experiment uses 200 ms delay and 250 Mbit/s bandwidth; common update flow reduces message exchanges, while UTXO evidence refresh makes BF's reduction smaller than EF's.Source: Table IV · p. 13, C. Evaluation of Network Delay · pp. 13–14

D. Parameter Sensitivity

• As blockchains increase from four to eight, BN, EN, and EF vary little, while BF runtime falls from 1.156 s to 0.951 s and bandwidth from 155.6 KB to 100.7 KB.Increasing users per blockchain from 10 to 50 or payments per user from one to five raises BF to 1.048 s and 119.2 KB; more active transfers on shared UTXO channels increase evidence generation and verification work.Source: Figure 5 · p. 14, D. Parameter Sensitivity · p. 14

IX. DISCUSSION

• UTXO updates require O(k) adaptor pre-signatures, whereas the account realization retains unchanged evidence and generates O(1) per operation.The discussion also notes that n hubs maintain n(n −1)/2 overlay channels while each payment uses at most four channels; shared channels process updates sequentially and reserve liquidity for pending payments.Source: §IX · p. 14
• A new hub and its users can join from the next epoch after establishing funded UniPC channels and publishing the hub's LOE and BRS public keys.The hub also establishes funded UniPC channels with existing hubs between epochs.Source: §IX · p. 14

X. CONCLUSION

• UniPCH separates channel execution on individual ledgers from cross-chain payment logic, and experiments show selective evidence refresh reduces computation and communication costs.The conclusion also reports local UniPC security, griefing resistance, economic atomicity, and session unlinkability within an epoch.Source: §X · p. 14

A. UniPC Security

• The UniPC failure events cover inadmissible or non-conserving installed states, invalid task evidence or confirmation, obsolete terminal states, and conflicting claim/refund outcomes.An installed record must have complete task evidence and valid confirmation; retained evidence must remain associated with its original complete task tuple.Source: A. UniPC Security · p. 16
• UniPC security requires transition correctness, authorization security, state freshness, and settlement consistency for a conforming realization.The experiment assumes an honest participant follows the realization, authenticated messages cannot be forged, and the ledger validates prescribed actions within the assumed delay bound.Source: A. UniPC Security · pp. 15–16

B. S-RBCS Security

• S-RBCS correctness requires valid randomized credentials, common witnesses in ciphertext-statement pairs, valid retained or refreshed task evidence, and witness extraction from adapted signatures.The scheme's syntax comprises Setup, Reserve, Promise, Convert, and Solve.Source: B. S-RBCS Security · p. 16
• S-RBCS unlockability tests witness recovery from completed signatures, blindness tests sender-receiver matching against hub-visible transcripts, and task unforgeability tests fresh messages and excess completed authorizations.The blindness view includes credential and task-evidence information visible to hubs and public-ledger observations, but hides messages on the anonymous endpoint channel.Source: B. S-RBCS Security · pp. 16–17

A. UTXO Realization

• The proof establishes UTXO transition correctness and authorization security by having participants validate candidate commitments and refreshed evidence before signing or installing a state.Changing a commitment changes the outpoint used by carried claim transactions, so no task evidence is retained in that update.Source: A. UTXO Realization · p. 17
• The UTXO realization provides state freshness because revocation material lets the counterparty spend an obsolete commitment's revocable output before its timelocked settlement branch.This argument assumes the blockchain confirms the revocation spend within the stated delay bound.Source: A. UTXO Realization · p. 17
• Claim and refund transactions spend the same commitment output through alternative script branches, so ledger validation prevents both conflicting outcomes from being accepted.Source: A. UTXO Realization · p. 17

APPENDIX B PROOFS OF UNIPC REALIZATION SECURITY

• Together, Lemmas 2–5 make all four UniPC security advantages negligible for the UTXO realization under Theorem 1's assumptions.Source: A. UTXO Realization · p. 17

B. Account Realization

• Account transition correctness follows because the state digest binds the channel, version, balances, and active-item set, while participants check the candidate and value conservation before signing.Installing an invalid state would require a confirmation-signature forgery or a collision binding the digest to different state contents.Source: B. Account Realization · p. 17
• Account authorization security checks evidence against each complete task tuple, retaining it only for unchanged transfers and requiring valid evidence for every required task before confirmation.New transfers receive new tasks and evidence, while removing a transfer removes its task.Source: B. Account Realization · p. 17
• The contract's version rule prevents an older record from becoming final when an honest participant submits the latest jointly confirmed state within the challenge period.Source: B. Account Realization · pp. 17–18
• A successful claim or refund removes the item from the contract's finalized active set, preventing a later terminal action on that item.Lemmas 6–9 establish that the account realization satisfies all four UniPC security properties.Source: B. Account Realization · p. 18

• Π∗ S-RBCS correctness follows from valid retained or refreshed evidence, valid signatures after adaptation, and witness extraction from evidence and completed signatures.Source: Appendix C · p. 18
• Task unforgeability reduces fresh-message challenges to AS or RAS unforgeability and conditional-completion challenges to OMDL hardness.The reduction records authorized messages and bounds its discrete-log queries by the number of independent authorizations.Source: Appendix C · p. 18
• Unlockability follows because a valid completed signature reveals the challenge witness, contradicting witness extractability if that witness cannot be recovered.For linked tasks, the witness relations in Equation (23) let an honest sender derive the adjacent values using nonzero randomizers.Source: Appendix C · p. 19
• Blindness follows because credential reassociation and proof simulation are indistinguishable, while condition-pair reassignment preserves its distribution in the LOE model.The resulting real transcripts for the two endpoint matchings are computationally indistinguishable.Source: Appendix C · p. 19
• The four preceding lemmas establish correctness, task unforgeability, unlockability, and blindness, so Π∗ S-RBCS is secure.Source: Appendix C · p. 19