Streaming Money Part 1 of 2

by lab10 collective

<update>
A slightly updated and better formatted (but without pics) version of this document can be found on github together with a PoC implementation as Solidity contract: https://github.com/lab10-coop/streem-poc
</update>

Since we can remember, money has been handled discretely, and portioned into distinct amounts. We’re so used to it that – even though terms such as cashflow exist – we hardly ever question that fundamental property of money.

However, the idea of modelling monetary streams as actual flows is not new. An interesting historical example is the MONIAC (Monetary National Income Analogue Computer), built more than 50 years ago by an economist in order to model the national economic processes of the UK. Check out this video for a detailed demonstration.

The MONIAC

 

The MONIAC

The MONIAC was useful for simulating interactions in a financial system. Technology back then was however not ready to model real money flows this way.
Many of our financial transactions are one-off transfers which are perfectly handled with point-in-time, fixed amount, money transfer - as we know it.
Many other transactions however belong to long-running, continuous engagements, such as rent or insurance payments. Usually, such economic relations are reflected by a legal contract – something one-off transactions often don’t require – and involve recurring payments at certain time intervals, most typically monthly.

With digital money, the physical limitations inherent to material money (and be it lightweight paper) have disappeared and the openness of crypto-economic systems has opened up the domain of money for more innovation.

We can now think of money in a less compartmentalized and more fluid way.
The initial seed for this idea came from Andreas Antonopoulos - a central mastermind in the crypto-economic space - who talked about Streaming Money here.
Andreas envisioned off-chain micro-transactions to represent de-facto streams. We will show that a more native on-chain implementation with several advantages over payment-channel based solutions is possible.

Definitions

Before we dive deeper into the concepts of streaming money, it's important to be clear on core definitions first:

Discrete Payment: A point-in-time payment / transfer

Open ended: Timespan with an undefined end (could in theory be infinite)

Continuous Payment: A payment / transfer running for a period of time (can be open ended)

Streem: an instance of a continuous payment

Flowrate: the amount of value per time in a Streem, specified in a Streem unit (see next section)

Open Streem: a Streem which is ongoing

Closed Streem: a Streem which has stopped (flowrate 0) and can't be resumed (however a new Streem defined by the same parameters could be established)

Outgoing Streem: from the perspective of an account, an outgoing Streem is a Streem of which that account is the sender

Incoming Streem: from the perspective of an account, an incoming Streem is a Streem of which that account is the receiver

Multi-Streem: constellation where multiple Streems have the same sender or receiver.

Unit

Just as speed doesn't have the same unit as distance, Streems can't be measured with the same unit as discrete payments.
A streem has a time component, thus the unit for a Streem is the unit of the currency/asset by time. In ARTIS, we use ATS/d, where ATS is the base currency of ARTIS, and d is short for day.

Going forward, we will use day as the default unit for the time component. While a day is not the SI unit for time, we consider it the time unit best suited for the Streem use cases we can currently imagine.

Similarly, a Streem of a hypothetical €-denominated token could have the unit €/d.

Examples for better imagination:

  • Monthly payment of 600€ for renting a flat would correspond to a Streem with a flowrate of approx. 20 €/d
  • Monthly payment of 1934€ (average salary in Austria) would correspond to a Streem with a flowrate of approx. 65 €/d
  • Monthly payment of 10€ as a patron (e.g. on patreon.com) would correspond to a Streem with a flowrate of approx. 0.33 €/d

Note that trying to calculate this exactly highlights the fact that recurring payments with a monthly interval can't be translated to a constant flowrate, because the duration of a month is not constant (can be 28, 29, 30 or 31 days).
The duration of a day isn't perfectly constant either since there's leap seconds, but a leap second happens once every few years and is a much smaller deviation.

Theoretical model

Inspired by the way Blockchains work, we can model the distribution of money across accounts - let's name it state(t0) - at any given point in time as a set of tuples <account, amount>.
Transactions for discrete payments (abbrev. as D-TX) update the state by moving funds between accounts. Such a D-TX can be expressed as the tuple <timestamp, sender, receiver, amount>.
After such a transaction induced state change, we have a new state state(t1) which is defined by an updated set of tuples <account, amount>.
Allowing only valid transactions (e.g. no account becoming negative, total supply unchanged) is the responsibility of the transaction execution layer (that is, the implementing Blockchain protocol or contract).

A continuous transaction (abbrev. as C-TX) is similar to a D-TX. But instead of an amount which is moved atomically, it specifies a flowrate. The tuple describing the transition becomes thus <timestamp, sender, receiver, flowrate>.

Such a system can be modelled as a directed graph.
There's an initial state where each account with non-zero balance is modelled as a graph node, with the balance as node weight. Every D-TX updates the weights, it may also add or remove nodes (by moving funds to an account not previously in the system or moving all funds out of an account). Every C-TX is represented in the graph as an edge pointing from the sender to the receiver of the Streem, with the flowrate being the weight of the edge.

A key difference between a system with D-TXs only and one with C-TXs too is that in the latter case state(t) can't change only at points in time at which transactions occur, but at any time. In a way, it is converted from a discrete into a continuous function with the current time becoming a dominant parameter.

On a Blockchain

Blockchain based money is typically positive money. In such a system, Streems cannot be allowed to cause a negative balance at the sender account. This implies that Streems can become underfunded (partial or full stop of flow). The consequences are:

  • the behaviour of Streems in an underfunded state needs to be explicitly defined
  • computing account balances becomes more difficult / expensive

Time based

The core property of Streems is their time dimension.
We leverage the availability of timestamps secured by the consensus protocol in every block of the chain and construct a kind of transaction-less, continuous state transition on top of it.
Simply put, every change of the current time can implicitly change the balance of accounts. Instead of just being a function of the current storage state, the balance becomes a function of current storage state and current time.

Because of this design, the accuracy is limited by the timestamp specific consensus rules.

Granularity could in theory be unlimited (down to milliseconds or even smaller), but in ARTIS, it is limited to seconds because that's the unit also used by the block timestamps and because for the envisioned use cases more granularity doesn't add any value.

Streems which don't have their start and end time pre-specified, but implicitly set by the execution time of the transactions for opening and closing them, have time granularity limited further to the blocktime.

Underfunded Streems

A Streem becomes underfunded when the sender runs out of funds.
Since the Streem receiver's balance depends on that Streem, the lack of funds of the sender propagates to the receiver. In case the receiver has an outgoing Streem herself, it can propagate even further.
A fundamental property of Streems is that their flowrate isn't guaranteed by default. Streems with guaranteed flowrate could be implemented by not allowing them to be open ended and requiring the sender to have sufficient deposit which is locked while the Streem is open. However allowing Streems without guaranteed flowrate gives more flexibility and adds advantages:

  • the runtime doesn't need to be known and/or specified when a Streem is opened
  • relaxed liquidity requirements. Most importantly, that enables the use case of an incoming Streem feeding an outgoing Streem

In ARTIS, Streems can remain open even if they become underfunded. If at a later point in time the sender account becomes solvent again, the underfunded Streem will not only continue flowing, but the outstanding amount is immediately compensated.
A single Streem is always unidirectional: that means, if at a given point in time t0 an amount a0 has flown from the sender to the receiver, there can never be a point in time t1 with t1 > t0 where the a1 < a0.
In other words, while the flowrate isn't guaranteed, funds transferred through a Streem are just as guaranteed as funds transferred through a discrete payment.

If Multi-Streems are allowed, there's different possible strategies for how a lack of funds of a sender with multiple outgoing Streems can be handled, some examples being:

  • all of their flowrates are reduced proportionally (the default implementation in ARTIS)
  • some Streems may be flagged as auto-close if underfunded
  • priority classes define which Streems are affected first (similar to creditor rankings in case of default)
  • older Streems have priority (first come, first served)

ARTIS will initially implement only the first strategy. If demand for more strategies arises (depending on use cases), more strategies can be implemented.

 

To continue to part 2 of this article, click here.

Go back