Introduction to the Orinoco Payment Hub: Part 1
Previous articles have examined payment channels and provided a critical examination of their abilities and frailties. Payment channels provide a combined on-chain and off-chain payment solution; they have a lot of promise but need significant management to be able to fulfil that promise.
To provide a fully-functioning payments system based on Ethereum payment channels, a number of features are required. This is the first of four articles that explores these features and explains how the Orinoco Payment Hub design provides the functionality required to make payment channels a viable general-purpose payment solution.
Channel Management
Channel management requires managing the opening and closing of channels as well as the handling of promises relating to each channel.
The opening and closing of channels occurs on-chain and, as such, can be monitored by an off-chain system such as the Orinoco hub. Such monitoring allows the hub to obtain knowledge of every current channel (sender, recipient, deposit etc.).
The transfer of promises is a different matter. Promises are off-chain i.e. are not made as transactions on the blockchain, and are traditionally shown as being sent directly from the sender to the recipient.

There are two issues with off-chain promises that a managed solution needs to address. The first is the need to provide a mechanism that can transfer the information about the promise from the sender to the recipient. The second is ensuring the recipient is aware of the difference in value between consecutive received promises.
The Orinoco Payment Hub solves the issue of how to deliver promises to recipients by acting as the delivery point for all promises. In turn, the hub provides recipients with the information that they need without needing to keep track of the details of the channel. By sitting between the sender and recipient it simplifies the operation of each.
As stated in previous articles, the value in the promise is the cumulative value of the current promise plus all prior promises on the channel: although the promise numbers are counting up 0.1 Ether, 0.2 Ether, 0.3 Ether, they represent three separate instances promising 0.1 Ether each.
The Orinoco hub manages the channel as shown below:
[Note that in the diagrams below the Ethereum blockchain and the Orinoco hub are conflated. This is purely to keep the diagrams easier to read; commands sent to Ethereum rather than Orinoco are shown in blue.]

Here the additional features of the Orinoco hub in action. First, the sender obtains a confirmation that their promise has been received and validated. Second, the promise presented to the recipient has already been processed and as such the value is an absolute value for that promise. This means that the recipient can act purely on the information provided in the promise rather than needing to retain information about all previous promises and calculate what additional funds the promise represents over those already presented.
The hub is also able to provide additional notifications. The following diagram shows a situation where a payment channel is funded with 0.15 Ether and two situations occur leading to error messages:

The first error occurs when the sender attempts to promise more funds than were deposited in the payment channel when it was open. The second error occurs when the sender attempts to promise on a closed channel. In each situation the sender is made aware of the issue immediately and the recipient has no knowledge of the attempts to pass invalid promises nor any requirement to handle the situation. This makes the experience of using payment channels much easier for both the sender and recipient.
Note that in the above scenario the recipient obtains a “Channel closed” notification. Channel management involves closing the channel at an appropriate time and informing the recipient that they should not expect any further promises on the relevant channel. It also allows the recipient to withdraw their funds.
To recap: channel management allows the sender and recipient to be aware of the real state of the channel and promises relating to it without having to worry about the underlying details of the payment channel implementation. It also provides notifications of events that occur during the lifecycle of the channel. This provides both sender and recipient with a much friendlier and more useful payment channel experience.
Terms Management
All previous examples of payment channels have shown movement of Ether from sender to recipient. However, there has never been any definition of what the recipient provides in return for Ether. Translating from raw Ether values to units of service is a function of the Orinoco Payment Hub known as “terms management”.
In its simplest form the prospective recipient of promises can state simple static terms for their service. For example, an internet service provider might state their bandwidth charge as 0.0001 Ether per 1GB of data. A prospective sender of promises can then check the terms prior to opening the channel and understand fully what they will obtain for their Ether. An example of this scenario is shown below:

Here the recipient sets the terms and the sender requests the terms prior to opening the payment channel. This means that both sides are clear on what a payment of Ether represents. Orinoco also translates the promise to the recipient so that they understand what they should be providing the sender in terms of the service that they provide (in the above case 30GB of data allowance).
It is also possible for terms to be much more sophisticated. For example, a term might be “the average price of 1GB of data allowance as currently provided by the top 5 internet service providers”. Terms could even be based dynamically on a channel-by-channel basis with a negotiation system using smart agents if required.
Terms like the one above allow price changes over the lifetime of a payment channel. As payment channels can be long-lived — surviving over many weeks or even months — it is possible for the price of goods and services within a payment channel to be dynamic and recalculated whenever the sender requests, or whenever a promise is received. Continuing with the above example, if the top 5 internet service providers all reduce their prices then the next time that the sender sends a promise for some Ether to the Orinoco hub the amount of bandwidth they receive will increase. This is shown graphically below:

Here a promise of 0.003 Ether is initially translated in to a promise of 30GB data allowance according to the terms that the recipient set and to which the sender agreed when opening the payment channel. At a later point in time, when the market price for data has decreased, a promise for 0.003 Ether is translated in to a promise of 45GB data allowance. The translation occurs within Orinoco and neither the sender nor the recipient need to be made aware of it, as they have agreed to the dynamic terms before opening the channel (although of course they can find out the current rates if they wish by asking Orinoco).
To recap: terms management allows the recipient to provide terms for their products and/or services and for the sender to agree to the terms prior to opening a payment channel. The cost of products and/or services can be set for the duration of the payment channel or altered dynamically according to the conditions laid out in the terms, allowing payment channels to relate to real-world costs and prices.
The next part of this series will discuss two more features needed in a payment channel solution: currency management and liquidity management.
