Streaming Money Part 2 of 2

by lab10 collective

Welcome back to the second and final part of our discussion on Streaming Money. If you haven't read part 1 yet, you can find it here.

Here, we will discuss the advantages of Streems over discrete payments and over Payment Channels, the computation method and the functionality of basic Streems. Finally, we'll provide an outlook on this topic from our point of view.


Advantages over discrete payments

Nowadays, use cases for continuous payments are handled with recurring discrete payments.
While this obviously works to some extent, there's some significant drawbacks which become visible when having an alternative.

In general, the emulation with discrete payments causes significant cost overhead. Obviously it results in more transactions (regardless if taking place on a Blockchain or in a traditional payment network), but there's also more subtle issues. One of them is that it not only causes direct transaction costs, but also indirect ones, e.g. resulting from dependent accounting operations triggered by every payment transaction.

Transaction costs create a boundary between what can be done and what cannot be done. Only moving that boundary will make examples for what could not be done visible, because sooner or later somebody will find out and just do it.

One not-so-obvious drawback of the emulation with recurring payments is increased risk.
While the act of a discrete payment by itself often implies a legally binding agreement between the parties involved, payments for continuous services mostly require auxiliary legal agreements in the form of written contracts. An important reason for this is that with discrete payments in intervals (e.g. monthly), usually one party needs to bear the risk of being disadvantaged, e.g. a supplier not getting paid after a month of service delivery or a consumer not having a promised service delivered as promised after paying upfront.

Bearing that risk may become less of an issue with the advancing of time, because after repeated rounds of non-violation of an informal agreement from both sides, some level of trust can be established.
It does however create a major hurdle for new economic relations between untrusted parties where neither is willing to bear the unilateral risk initially, to be established. It also limits the capability to offer services across legal boundaries and can be a hurdle even without such boundaries, because creating, communicating and enforcing a legal agreement is a task typically requiring expensive legal services which not every entity or project can afford.

Truly continuous payments may make simple, low-overhead implicit agreements possible for more business cases, for example for low-priced online services where entry barriers caused by the transaction (registration procedure, legal agreement, setup of payments) are often more of a detractor for potential customers than the actual monetary cost.

A noteworthy side-effect of that could be better privacy preservation. One could imagine online subscriptions which don't require any more exchange of personal data than buying a paper newspaper at a random kiosk.

Advantages over Payment Channels

Streaming money can be emulated with Payment Channels by creating and sending transactions with small amounts with high frequency.
A demonstration for this can be seen in this tech demo of Raiden, a payment channel implementation for Ethereum.

While such an implementation may make sense for some use cases, a native, on-chain implementation of Streaming Money has some properties which can be of significant advantage for various use cases:

  • doesn't require additional infrastructure (payment channel software, network, machines handling the transactions with always-on requirement)
  • the sender doesn't require a hot wallet (while transactions for the payment channel could be generated in advance in order to avoid this requirement, this would just switch the risk to that of having the signed transactions stolen - a kind of hot-wallet storing signed transactions instead of keys)
  • doesn't require locked funds

All of those seem significant advantages, with the last one probably being the most important one because it can fundamentally change the liquidity properties and requirements of the system - which is probably the property making the difference between emulated and real streaming.


If unrestricted, an implementation of Streems would run into an issue of unbound computation cost.

If an account can have both incoming and outgoing Streems, graphs with a large number of connected nodes could be constructed, meaning that calculating the balance could require a lot of recursive balance calculations (the balance of the sender of an incoming Streem). Such graphs could also have circuits which need to be detected in order to avoid endless loops.
With multi-Streem allowed, graphs with nested circuits which are more difficult to handle would also become possible.

While we believe that support for unrestricted Streems could be implemented anyway by designing economic costs such that they avoid the graph to become too expensive to compute (similar to how Ethereum works around the halting problem with the gas model), ARTIS will initially implement support for Streems restricted such that there's guaranteed bounds to the computational cost: Basic Streems

Note that with computation cost, we primarily refer to computations which need to be done by the Blockchain. The balance of an account can be calculated by a single Blockchain node at any time, based on the synced state data.
It is when transactions requiring knowledge of an account's balance are made that the computation cost of calculating the balance becomes an issue.
We could imagine a system where expensive computation of the graph is done off-chain and secured with a mechanism similar e.g. to the one described by the TrueBit Whitepaper and will continue research on that topic in parallel to rolling out more conventional implementations.

Basic Streems

The goal to have bounded computation cost is achieved by defining three account categories:

  • Concentrator
  • Deconcentrator
  • Open (default)


A concentrator account can have an unlimited number of concurrent incoming Streems and no outgoing Streems.
Flowrate, opening and closing time of individual incoming Streems can be independent of each other.

Calculation of the account balance has complexity O(n) with n being the number of open Streems.
Since no outgoing Streems are allowed, only the account owner can be affected by the balance calculation becoming expensive.


A deconcentrator account can have no incoming Streems and an unlimited number of outgoing Streems.
Flowrate, opening and closing time of individual outgoing Streems can be independent of each other.

If a deconcentrator runs out of funds, all outgoing Streems are affected proportionally to their flowrate. Since there's no incoming Streems, the balance of individual outgoing Streems can be calculated inexpensively at any time based on incremental aggregate snapshots updated whenever an outgoing Streem is opened or closed.


An Open Account can have up to open_max_in (concrete number to be determined empirically) incoming Streems from deconcentrators and up to open_max_out outgoing Streems to concentrators.
It cannot have incoming Streems from or outgoing Streems to other open accounts.
That way, it's possible to have accounts with Streem-based cashflows - that is, open incoming and outgoing Streems at the same time.

open_max_[in|out] are to be chosen such that even in a worst case scenario the transaction cost doesn't become unbearable.



When modeling such a system as directed graph where Streems between two accounts represent the edges between two nodes, arbitrarily large sub-graphs can be created.
Despite this, no circuits are possible and there's no danger of unbounded recursion.
In order to calculate the balance of any given node with n incoming Streems, the number of nodes to be visited is limited:

  • for concentrators: to n * open_max_in
  • for deconcentrators: to 0 (no incoming Streems allowed)
  • for open accounts: to open_max_in

This shows how the limitation open_max_in allows us to keep complexity at O(n) without compromising usefulness for many of the envisioned use cases.

As already noted, the only possible expensive case is with concentrators - even here it's just O(n) (the limitation of number of Streems for open accounts avoids this to become O(n^2)).
The only limitation that causes is that it may lead to concentrator accounts not being able to transfer all their funds (especially those from Streems still open) in a single discrete transaction. For concentrator use cases, there's a choice between going along with that limitation or limiting the number of incoming Streems by using multiple concentrator accounts instead of a single one. We may also mitigate that with some kind of snapshot calculations.


While Basic Streems are good for getting started and for figuring out what people want to use them for, they are pretty restrictive.

We believe that unrestricted Streems can be implemented, probably by employing a system of dynamic transaction fees which are also time based (basically streaming fees) and which could continuously adapt to the state of the relevant sub-graph. The basic problem to be solved is to avoid the dependency graph of a Streem to become too complex - regardless if caused by a malicious actor trying to create such a situation on purpose or by the popularity of Streems.

The natural solution in a Blockchain context thus seems to be a cost model which reflects the computation costs as closely as possible - not too dissimilar to Ethereum's gas model.

This topic needs further research and will also be influenced by the ways we see Streems being used.


Head over to github for a PoC implementation as Solidity contract:

Go back