Hopr

Hopr Relay States Before Payment Reconciliation

Hopr separates relay work from final payment: a valid packet carries a signed ticket, a matching downstream acknowledgement proves successful forwarding, and only a winning acknowledged ticket can reach redemption. Tracking those transitions prevents operators from treating a stored ticket, a relay proof, and an on-chain balance update as the same event.

The timeline begins before packet creation, passes through ticket commitment and acknowledgement, and then branches to a losing result, accepted redemption, or channel closure. Each boundary has different evidence and a different stop condition.

Key takeaway: Relay work becomes a reconciled payment only after acknowledgement, a winning-ticket check, accepted redemption, and a matching channel-state update.

Packets, Proofs, and Payment Records

The packet, its attached ticket, and the payment channel describe separate parts of one relay service. The packet carries application data, the ticket commits economic value, and the channel limits what can later be claimed.

Before a packet leaves, the relevant outgoing channel must be OPEN, point in the required payment direction, use the current epoch, and hold enough balance for the proposed ticket. Packet construction also binds the ticket to a channel identifier, an index, a winning probability, and a Proof of Relay challenge. If the necessary open channel is absent, a multi-hop ticket for that edge cannot be created.

The committed state begins when the sender signs the completed ticket and attaches it to the packet. Commitment does not mean the relay has earned payment. It records a conditional obligation whose challenge can be solved only after the next node processes the packet and returns the right acknowledgement material.

These working labels help operators read the timeline, but they do not replace protocol types. A verified ticket has passed issuer and field checks. An unacknowledged ticket is the pending record held after forwarding. An acknowledged ticket contains the response needed for the winning test.

What Changes When a Relay Forwards a Packet?

Forwarding moves the incoming ticket from validation into a pending proof state. The relay checks its signature, channel relationship, epoch, amount, available balance, and Proof of Relay hint. It then stores the verified ticket as unacknowledged, creates a replacement ticket for the next relay, and forwards the transformed packet. If a required downstream channel is not OPEN, forwarding stops.

The next node sends an acknowledgement back to the previous relay. A successful acknowledgement carries the secret needed to finish that relay's ticket challenge. Failed packet processing also produces a random acknowledgement, so the mere arrival of an acknowledgement cannot establish success. The relay must validate the signature, derive the expected hint, locate the stored ticket, and reconstruct the challenge response.

Acknowledgement Before Winning Status

Acknowledgement completes the relay proof, not the payment. A matching response changes the stored record from unacknowledged to acknowledged and proves the relevant downstream forwarding step. The node then derives the material used to test whether the ticket wins. Acknowledged, winning, redeemable, and redeemed are therefore separate states. Collapsing them into one paid label hides the point where a valid relay receives no claimable ticket.

When Does a Ticket Become Redeemable?

A ticket becomes redeemable after acknowledgement, derivation of the domain-bound VRF data used for a claim, and a successful winning test. The relay combines its own secret with the valid downstream acknowledgement, derives the ticket response, and computes the verifiable random function data tied to the redeemer and execution domain.

An acknowledged ticket is winning only when its derived luck value falls below the winning probability encoded in that ticket. A losing ticket still records completed relay work, but it carries no amount the relay can claim. This probabilistic split lets many off-chain tickets represent relay activity without turning every packet into a blockchain transaction.

Redeemable status is still not settlement. The claim must pass the ticket signature, channel identifier, epoch, index, challenge response, winning proof, and balance checks. The matching channel must exist and must not be CLOSED. Any mismatch leaves the channel unchanged, even when the local ticket record had already been classified as winning.

Channel State Versus Ticket State

Channel state controls whether new obligations or existing claims can use a particular payment direction. The protocol defines OPEN, PENDING_TO_CLOSE, and CLOSED states. Each channel also carries a balance, ticket index, and epoch, all of which redemption uses to reject stale or inapplicable tickets.

An OPEN channel supports new multi-hop tickets and valid claims. PENDING_TO_CLOSE blocks the source from using the channel for new relay traffic while preserving a notice period for the destination to claim pending rewards. CLOSED ends further channel operations and makes unclaimed tickets unusable against that channel.

Ticket state answers a different question: how far has one relay obligation progressed? A signed ticket can become verified, unacknowledged, acknowledged, winning, redeemable, and finally redeemed. Some transitions occur entirely off-chain. Only accepted redemption changes the economic fields in global channel state.

The two timelines meet at strict boundaries. Ticket epoch must equal channel epoch, the claim index cannot trail the channel ticket index, and the channel needs enough balance for the amount. This is why a locally valid proof can coexist with an ineligible claim. The cryptography may establish relay work while later channel state prevents payment.

Payment Reconciliation Across State Boundaries

Reconciliation occurs when a valid winning-ticket redemption changes the authoritative channel record. Successful redemption decreases the channel balance by the ticket amount. It also moves the channel ticket index to the redeemed ticket's index plus its index offset. Together, those changes show the claim affected channel accounting rather than remaining a local expectation.

A submitted claim does not provide that evidence by itself. Submission can fail validation or wait without producing the required state change. Compare the accepted redemption with the resulting balance, ticket index, and epoch before marking payment reconciled. If an index advances beyond an older ticket, that older claim may no longer satisfy the redemption rule even if its relay proof remains valid.

Which Evidence Confirms the Relay Cycle Is Complete?

Completion depends on the branch the ticket takes. A losing acknowledged ticket ends without a channel debit. A winning ticket remains economically pending until an accepted redemption updates its channel or closure makes the ticket unclaimable. The following checks separate a finished relay proof from a reconciled payment:

• Confirm the channel identifier, direction, epoch, and status match the ticket before forwarding.
• Store the ticket as unacknowledged only after its issuer, signature, amount, and challenge pass validation.
• Mark relay proof completed only after a signed acknowledgement matches the stored hint and reconstructs the challenge.
• Stop payment processing for a valid losing ticket because it has no claimable amount.
• Mark a winning ticket reconciled only after redemption decreases the balance and advances the ticket index.

Open full-size image

Packet forwarding indicates an attempted service, acknowledgement establishes the relay proof, the winning test determines claimability, and the channel update establishes payment. If one boundary lacks evidence, keep every later state unconfirmed rather than inferring it from an earlier event.

Closing the Channel Without Losing Claimable Work

Channel closure ends the channel's payment lifecycle. When the source initiates closure, the channel enters PENDING_TO_CLOSE. New relay use stops, but the destination can still claim eligible rewards during the notice period. The closing timestamp and applicable notice rule determine the remaining claim window.

The notice period is measured from shared block timestamps, so a local wall-clock estimate is not authoritative. Pending winning tickets need review before the period expires. The destination can also close a non-closed channel unilaterally, but any unclaimed rewards become unavailable after that transition.

CLOSED is the exited state: the balance resets to zero, the epoch advances, and no later reward claim can use the former channel state. An old ticket may remain in local storage, yet its epoch and closed channel make it ineligible. The next decision is whether any acknowledged winning tickets remain claimable before initiating or finalizing closure.