Skip to content
Blockchain LabBlockchain LabTHE VENTURE STUDIO

LibraryScaling2017Design paperCorpus record

Perun: Virtual Payment Hubs over Cryptocurrencies

Perun. Stefan Dziembowski, Lisa Eckey, Sebastian Faust and Daniel Malinowski.

Lightning routes each payment through the intermediaries. Perun asks those intermediaries to set up a virtual channel and then step out of the individual payments. The paper gives the construction for one hub, on a chain that can run the contracts.

Perun builds a virtual payment channel through one hub. The hub helps open it, then individual payments do not touch the hub or the chain. Disputes return to contracts on a chain that can express them. The formal result is one intermediary, not a global routing network.
Evidence
Primary paper
Re-measured
No
Assumptions
4
Records linked
4

Code

Source, repository, and what is actually hosted

  • ePrint 2017/635https://eprint.iacr.org/2017/635
  • The source URL is not a GitHub repository. No code remote is invented.
  • Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
  • Add to a reading list

01 Claim ledger

What the paper is allowed to say

Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.

  1. Claim 01 · Paper model

    Virtual, not routed

    A Lightning-style hop updates every channel on the path for every payment. A Perun virtual channel lets the two ends exchange payments on their own after setup.

  2. Claim 02 · Paper model

    The hub is real at the edges

    The hub has ledger channels with each user. The virtual channel's funds are carved out of those. The hub is not gone. It is absent from the hot path.

  3. Claim 03 · Paper model

    Disputes need a rich chain

    The security proof assumes smart contracts that can referee the channel. The paper is not a Bitcoin-script construction.

  4. Claim 04 · Paper model

    One hub is the theorem

    Composing many hubs into a network is described as the direction, not as a proof in this version.

02 Three cuts

Observation, model, falsifier

A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.

  1. 01 Virtual, not routed

    Observation

    What the study says

    A Lightning-style hop updates every channel on the path for every payment. A Perun virtual channel lets the two ends exchange payments on their own after setup.

    Model

    What has to hold

    Virtual-channel capacity was actually locked. An unfunded virtual channel is an IOU outside the paper.

    Falsifier

    What would retire it

    Does a normal payment require the hub to be online?

  2. 02 The hub is real at the edges

    Observation

    What the study says

    The hub has ledger channels with each user. The virtual channel's funds are carved out of those. The hub is not gone. It is absent from the hot path.

    Model

    What has to hold

    Virtual-channel capacity was actually locked. An unfunded virtual channel is an IOU outside the paper.

    Falsifier

    What would retire it

    Which chain holds the dispute contract?

  3. 03 Disputes need a rich chain

    Observation

    What the study says

    The security proof assumes smart contracts that can referee the channel. The paper is not a Bitcoin-script construction.

    Model

    What has to hold

    The underlying chain executes the contracts the construction uses.

    Falsifier

    What would retire it

    Which chain holds the dispute contract?

  4. 04 One hub is the theorem

    Observation

    What the study says

    Composing many hubs into a network is described as the direction, not as a proof in this version.

    Model

    What has to hold

    The adversary model is the one in the proofs, which includes a malicious hub. Read which theorem covers which party.

    Falsifier

    What would retire it

    Is the result proved for one hub or for a network?

03 Sequence

One action, as an operating tape

  1. 01Each user opens a ledger channel with the hub on the underlying chain.
  2. 02The three parties agree to a virtual channel with a capacity and a timeout.
  3. 03The two users update that virtual channel off-chain for each payment.
  4. 04They close cooperatively, and the hub's ledger channels absorb the net.
  5. 05If someone cheats or disappears, the contracts on the ledger are the enforcement path, inside the timeout.

04 Load-bearing

The argument, and where a pitch drops it

  1. Idle hubs are the point

    The cut

    The efficiency claim is that the intermediary does not wake up for every micropayment. A design that still pings the hub per payment has not used the virtual channel. It has used a route.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    A hub that disappears still forces a dispute. Virtual does not mean unsupervised.

  2. One honest period at dispute time

    The cut

    Off-chain systems are only as good as the dispute. A user who cannot post the dispute transaction in time loses the theorem's protection. The paper does not remove the need to watch.

    Why it carries weight

    If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.

    Where it is dropped

    This is not the Lightning paper and it does not run on Bitcoin's script as written. The model assumes richer contracts.

05 Register

What has to be true

  • Model · Not re-measured

    The underlying chain executes the contracts the construction uses.

  • Model · Not re-measured

    The hub and the users can be forced to settle before timeouts.

  • Model · Not re-measured

    Virtual-channel capacity was actually locked. An unfunded virtual channel is an IOU outside the paper.

  • Cryptography · Not re-measured

    The adversary model is the one in the proofs, which includes a malicious hub. Read which theorem covers which party.

06 Divergence

What happened after the paper

Perun is the citation for virtual channels through a hub, next to Lightning and Sprites. A payment system that says 'we are like Lightning but the hub is offline' is pointing at this idea, and still owes the dispute contract.

A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.

07 Pre-mortem

What to check before you use the idea

  5. 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.

08 Anatomy

The paper, in the order a builder needs

The problem it names

A routed payment makes every intermediate node update its channels for every transfer. That costs liveness and attention from the hub. A virtual channel should let the two ends pay each other until they disagree or they close.

What the design proposes

  • Two users each have a ledger channel with a hub.
  • They and the hub open a virtual channel whose funding sits in those ledger channels.
  • Payments inside the virtual channel are off-chain between the two users. The hub is not in the loop for each one.

How the mechanism is specified

  • If everyone is honest, the hub learns that the virtual channel exists and then does not touch each payment.
  • If someone misbehaves, the contracts on the underlying chain are the dispute path. The paper needs a chain that can express those contracts.
  • The formal result is for one intermediary. A network of hubs is left as the obvious next composition, not as a theorem in this version.

What this page does not treat as proven

  • This is not the Lightning paper and it does not run on Bitcoin's script as written. The model assumes richer contracts.
  • A hub that disappears still forces a dispute. Virtual does not mean unsupervised.
  • The paper does not establish the security of any later commercial hub.

Why the desk still reads it

Ask who must be online for a single payment. In Lightning, the route. In this paper, the two ends, until something goes wrong. Then ask which chain the dispute contract actually lives on.

09 Lexicon

Terms, opened into the record

Virtual channel
An off-chain channel between two users, funded through a hub, that the hub does not update on every payment.
Ledger channel
The on-chain channel between a user and the hub, from which the virtual channel's funds are drawn.

10 Repository

Every linked record on this page

Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.