Liquid Supply Medium Exchange: Continuous Transactions, Token Streaming and Digital Twins — PART 1

Exchanging Value in the Physical and Digital World, Continuously and Simultaneously


As machines are developing into intelligent autonomous machines, they drive their own buying choices. We must accept them as a new customer group with basic needs and change how products and services are designed, defined, communicated, priced and presented to them. Machines will develop their own ways (protocols) to communicate and discover services they need and exchange physical and digital value among each other. These new infrastructures and protocols might be built upon a combination of blockchain and AI/ML technology [1].

Maslow Pyramid for Human and Machine Needs

Examples of basic physiological machine needs are energy, heating/cooling, consumable physical supplies, connectivity including data streams, (external) computing power and ongoing services. Many of these physiological needs are fulfilled by a liquid stream of a supply medium: electricity, gas or liquid fluid, usage based connectivity, real time data streams, time-based access to a physical service, a digital API or digital asset or usage based insurance services. A machine is giving either another supply medium or digital assets back in return for such a supply medium. This type of a continuous transaction among at least two or more machines is called a Liquid Supply Medium Exchange.

The concept of Liquid Supply Medium exchange can also be applied for human-machine transactions — think entertainment media stream streaming or usage based service — and hybrids teams of humans and machines.

This first part describes discrete blockchain payment methods including Ethereum or zCash and introduces some selected blockchain technology options such as Ethereum Raiden or µRaiden payment channels, Bitcoin lightning payment channels, or IOTA flash channels by using the practical example of Electric Vehicle (EV) Charging: Exchange of electric power and crypto-currency tokens between a charging pole and a vehicle.

We think that EV Charging is a typical use case as initial implementations of blockchain EV charging infrastructures have already been implemented including a Pan-European CV charging network over the last months by innogy SE and Motionwerk GmbH [2], [3], [4], [5]. This use case concept can be easily transferred to other examples as well.

In the second part of this article we describe an alternative approach to the blockchain payment channels by using digital asset transactions in blockchain databases (BigchainDB) and hybrid solutions in combination with payment channels. In addition we will introduce a new transaction type for digital twins of machines.

Liquid Supply Medium Exchange

In today’s world fiat currencies, or cash, are the most liquid assets, because they can be “sold” for goods and services instantly with no loss of value. There is no wait for a suitable buyer of the cash. There is no trade-off between speed and value. It can be used immediately to perform economic actions like buying, selling, or paying debt, meeting immediate wants and needs. [6]

Today, digital and physical transfers are done via financial services involving banks by using fiat currencies. This (liquid) fiat money transfer system does not support Liquid Supply Medium Exchange in an effective way. There are always intermediaries and discrete processing steps required. The system is neither flexible nor (cost-)efficient enough — think of complex core baking and corporate ERP systems— nor protects the privacy of the parties involved in both, the new digital and the new machine economy.

In the new world where machines are continuously transacting physical and digital values a peer-to-peer (P2P) token streaming system is required. The adoption of today’s discrete payment methods and Third Party Intermediary (TPI) Services will not work to automate micro-transactions among billions of machines (and with humans).

Continuous Liquid Supply Medium Exchange and P2P Token Streaming

In a simple case a physical or digital value is exchanged between two machines while a digital token of value is transferred simultaneously. This liquid supply medium exchange requires a continuous payment method.

Typical requirements of a continuous payment method are:

  1. Transaction Privacy
  2. Direct counterparty transactions among entities that have never met before (no need for ERP master or contract data systems)
  3. Plug-and-Play for simple, fast and fair value exchange method
  4. Eliminated or marginalized credit risks
  5. (Almost) zero transaction costs
  6. Scalable Transaction Layer
  7. Proven cryptographic primitives and protocols
  8. Partition-tolerant, off-line machine-to-machine transaction method
  9. Automated service discovery
As of today, there is no scalable (peer-to-peer) payment method for either physical or digital continuous transactions. There will be very soon a huge demand for and working implementations of such a payment method.

The Electric Vehicle Charging Example

One of the easiest to understand examples of a Liquid Supply Medium Exchange is the Electric Vehicle Charging use case.

In today’s world back-end systems are authenticating users, controlling the energy exchange, getting meter data from a charging pole and performing a financial transaction while involving financial services and roaming providers.

In the new machine world these back-end systems and processes will not exist any more. A pole and a vehicle with a crypto wallet are simply doing a direct counterparty physical and financial transaction at the same time that is executed on a decentral, privacy-preserving peer-to-peer infrastructure.

Discrete Payment Methods with Blockchain

We are now discussing a charging transaction between an electric vehicle (or its driver) and a charging pole. We assume that we can trust the charging pole (or its data oracle) that the meter reading data inside the EV charging pole are not tampered with. The public charging poles are registered on a public blockchain listing its service and reputation. This listing can be seen as a very basic form for Service Discovery.

Existing reference implementations via blockchains are using for example Ethereum smart contracts [3], [4]. With these smart contracts discrete payments methods are adopted by using escrow payments and a neutral smart contract business logic to release the escrow payment to the charging pole and the vehicle after the physical charging process is finished (or the escrow balance is zero).

The escrow payment release is calculated based on validated smart meter energy data that is delivered by a data oracle into the smart contract. Transactions credit risks for the charging pole and the vehicle are mitigated by the neutral smart contract business logic.

High-level Ethereum Smart Contract Transaction for EV Charing

In current practical implementations, connecting entire charging infrastructures, individual charging poles are aggregated on a gateway level and the gateway is connected to the blockchain. For the time being, in this retrofitting case the infrastructure is trusted form the pole to the gateway.

A variety of blockchain tokens can be used including native crypto currencies such as BTC or ETH or asset-backed ERC 20 tokes such as Crypto USD/EUR/RMB (linked to bank escrow via a payment gateway) or tokenized physical assets or ICO tokens.

Discrete Payment Method with TEEs for Off-chain Smart Contract Business Logic and zCash Shielded Transactions

One extremely important aspect for transactions is transaction privacy [7] [8]. We pretty much like the concepts using of modern cryptography for privacy-preserving coins such as zCash or Monero. We now focus on zCash and its underlying zero-knowledge proof cryptography.

An alternative approach to the above described on-chain smart contracts is the of use trusted execution environments (TEE) and the deployment of smart contract business logic in the TEE. A TEE is registered on the blockchain and gets its own zCash wallet to store escrow payments. The off-chain business logic is then releasing the escrow payment to the two parties based on authenticated oracle data from the charging pole about the value of the physical transaction.

In an early zCash concept discussion options for this privacy-enabled escrow mechanism using zk-SNARKS were identified [9].

It should be understood that it is possible to add Zcash-style privacy to any blockchain. In fact, Zcash itself is effectively a Bitcoin-style blockchain with the zero-knowledge security layer (ZSL) added. Transparent transactions take place on the Bitcoin layer and shielded transactions take place on the ZSL layer.

So, people are starting to add ZSL to Ethereum, and thereby benefit from its full Solidity smart contract capabilities. Ethereum and Zcash communities are doing research in this directions. However, for the purpose of the post we will focus a practical approach for privacy-enabled machine transactions. We think it would be simpler (right now) to replace the blockchain escrow wallet by an off-chain Trusted Execution Environment (TEE) with a pre-compiled contract that the parties can call via the blockchain.

In the EV charging transaction example, the vehicle (or the driver) want to charge her battery while not disclosing the identities. The public charging pole is registered on a public blockchain listing its service.

Option 1) Transparent Escrow

The Driver must unshield the deposit funds to place them in TEE escrow. This will reveal to a third party observer that (a) a charging interaction is taking place, and (b) how much has been deposited in escrow. It will also be apparent to a third party observer if an escrow timeout occurs. However, the identities of the Driver and Pole are protected (the payments from the Escrow Address that split the deposit between the Driver and the Pole will be shielded).

Option 2) Shielded Escrow

All funds transfers will be shielded, and no information regarding the charging interaction will be available to a third party observer. Implementing the Shielded Escrow is not yet possible because this option requires making changes to the cryptographic circuit in the Zcash source code.


  • Further considerations and limitations regarding zCash and an alternative implementation with the HAWK protocol are laid out in the ADDENDUM.
  • Teechain, a combination of TEEs and payment channels, is also a compelling concept for secure and scalable payment channels which is briefly laid out in the ADDENDUM as well.

P2P Token Streaming Payment with Blockchains

In general, a smart contract discrete payment method is complex, not yet scalable and requires payment of gas fees to public chain networks.

P2P Token Streaming

An alternative solution is to use P2P token streaming instead of discrete escrow payments.

Example of a Liquid Supply Medium Exchange with P2P Token Streaming

In the P2P token streaming one of the entities starts to stream either one micro-energy package or micro-token asset which is released by a module in one of the entities. A measuring module in the other entity (e.g. meter reading or token wallet account balance query) is confirming the inflow and releasing a micro-energy package or a micro token respectively. A control unit in at least one of the entities synchronizes energy and token streams.

The same unit might synchronize the streams with other external factors such as control signals from grid control systems or dynamic pricing data from local power markets. This approach takes availability, volatility and price of (renewable) energy in power grids into consideration. Depending on the situation and the transaction agreement with the vehicle the control unit might reverse the token streams and feed energy back into the grid in case of constrained local energy supply.

With the synchronization of the energy and token streams the credit risks is dependent on the micro-energy package or micro-token value which is released first. This “Plug-and-Play” approach results in infinitesimal small credit risk or a marginalization of the credit risk.

We all might understand that the CV Charging Examples can be generalized to other continuous payment examples inducing for instance time-based access to physical or digital assets or real time data streams.

There are different options how to establish a P2P Token Streaming for Liquid Supply Medium Exchange with existing blockchain technology.

Token Streaming via State and Payment Channels using Ethereum: Raiden network and µRaiden

One continuous payment method requirement for a Liquid Supply Medium Exchange is scalability. In case of a public blockchain networks like Bitcoin and Ethereum — which rely on proof-of-work for mining — the payment throughput handling capacity is limited and P2P token streaming is not possible.

The scalability requirement can be realized by using a permissioned blockchain network, which relies on consensus algorithms such as PBFT, Proof-of-Authority or Proof-of-Stake. However these permissioned networks are also not designed to run multiple token streaming sessions on chain in parallel.

One possible other (future) solution is usage of Raiden payment channels, which enable direct token streaming interactions between participating nodes [10]. A first implementation that is focused on many-to-one channels is µRaiden which is already operational now. The future Raiden Network will support bi-directional multi-hop payment channels. The team is right now working on multi-hop path-routing protocols. The µRaiden supports already today many-to-one uni-directional payment channels. With µRaiden a retrofitted EV charging infrastructure with one µRaiden node at the EV charging gateway level can be supported to allow token streaming for one-directional charging transactions.

As on these networks the transactions happen instantly and do not have to be mined on the main blockchain the payment channel transactions are much more scalable. This results in the following technical features:

  • Instant Payment — Payments do not need block confirmations on the main chain, and are instant and atomic. Payment channels can be used for device-to-device transaction or in any scenario where instant payments are needed.
  • Micropayments and Micro-Token Streams — Using payment channels high frequency micro payments with zero transaction fees can be enabled whereas Bitcoin / public Ethereum blockchains have a fixed per-transaction fee, which makes micro-payments impractical.
  • M2M interactions — For the EV charging use case that leverage internet-connected devices the support for machine-to-machine payments and automated micro-payment services is be required. Payment channel transactions are conducted off the blockchain without delegation of trust and ownership, allowing users to conduct nearly unlimited transactions between other devices.

In general state channels — state channels as an abstraction of payment channels, allowing to have off-chain common transactions, not only Token payments — work by establishing a multi-signature address between two participating nodes on the main blockchain network. For spending both parties need to agree on the target balance. The current balance is stored on the participants side (not on the chain) as the most recent transaction signed by both parties, spending from the channel address. Any number of payment transactions or asset transfers are possible between any of the nodes provided exchange of secure cryptographic hash is fulfilled, while the custodianship of the funds is still with the main blockchain.

These state or payment channels can be chained together, to allow for multi-hop token transfers or payments between parties, which are not directly linked in a bidirectional payment channel (core feature of the Raiden Network). The bidirectional payment channel will support a bidirectional EV charging process in which energy can be released by a vehicle battery in order to inject energy in a (public) when energy supply is not fulfilling energy demand.

In order to increase the reliability of the charging process micro-payments can be released from the car’s wallet to the charging pole depending on delivered energy packages and the charging pole will continue the process. At any point of time if the payments stops or the wallet runs out of funds the charging will also stop. Thus, numerous such micro-transactions are possible which need not be handled by the main blockchain network. One of the options on how to use the Raiden Network for this scenario is depicted above.

Here is how the Raiden Network will enable the micro-payment process (asset transfers).

  • The micro-payment asset transfer is initiated on the blockchain (if no channel is already present or a path is not found).
  • Transfer manager gets channel info from asset manager, transfers are registered on channel
  • Off-chain bi-directional asset transfers are accomplished after validating signature and security details (especially by a signature signed by the private key, making it as secure as Blockchain transactions)
  • At any time the channel can be closed by either of the parties via an on-chain smart contract transaction
  • On-chain smart contracts facilitates the settlement / reconciliation

Raiden and µRaiden can be used to establish a payment channel framework for fast & free off-chain ERC20 token transfers. This enables to stream Crypto USD, EUR, RMB or ICO tokens [11] [12] as well as wrapped ETH (WETH) uni-directionally between two parties. µRaiden is already deployed on the Ethereum mainnet and will soon release version 0.2.0. This payment channel method also requires a deposit/escrow on each channel.

The ability to establish P2P token streaming capabilities among machines, is currently being explored by companies such as (Universal Sharing Network), Energy Web Foundation and Motionwerk GmbH.

Similar solutions can be envisioned with the Bitcoin Lightning network as well. Key differences are that Raiden is not limited to the underlying native token of Ethereum as the BTC lightning channels are. Another difference is that Raiden uses another approach to lock token. Raiden locks tokens via Smart Contracts and is not using a combination of segregated witness specifications, multi-signature commitment transactions, hash and time locks as used in lightning and thus is easier to understand and maintain.

IOTA DAG Tangle Flash Channel

IOTA Foundation introduced a first scalable distributed ledger architecture that has no transaction fees and is able to execute transactions in the Internet of Things system. The “no transaction fee feature” makes the IOTA DAG tangle an interesting option for P2P token streaming implementations.

To further improve scalability, IOTA flash channels, a bi-directional off-Tangle payment channel enabling instantaneous, high-throughput transactions, has been introduced [13].

Flash channels are similar to Raiden and Lightning. They are an early IOTA technology implementation that provides a method for parties to transact at high frequency without waiting for each transaction to confirm on the public IOTA network.

Warning: The IOTA technology still needs to be validated in field tests and in (academic) reviews of and attacks on the underlying cryptographic foundation, the game theoretic model (based on Nash equilibrium assumptions) as well as the SW implementation of the Tangle.

IOTA Smart City EV Charging and Payment Simulation (Source: IOTA Foundation)

Flash channels reduce the per-transaction overhead to a negligible level by creating signed, feeless transactions. This results in a more plug-and-play type of EV charging implementation without any smart contracts.

The elimination of a smart contract in this approach should not be underestimated in order to achieve a simple, interoperable transaction protocol that does not depend on mining of blocks.

During the token streaming the channel does not need to be connected to the main network until the channels are closed which provides an off-line, partition tolerant capability for future implementations.

Another aspect is that the transaction identities are created on the fly buy using one-time signatures which masks the identities involved in the payment transactions for privacy purposes.

Elaad and Enexis in The Netherlands are exploring the application of IOTA for EV charging [14]. Bosch is exploring the use of IOTA for a variety of mobility use cases including a wallet in a car and other IoT applications. The IOTA foundation is currently running simulations for EV charging to evaluate the technical performance [15] [16].


P2P token streaming is an innovative payment method for liquid supply medium exchange of physical and digital media. It relies on an infrastructure network and a protocol that is providing the token streaming service.

There are further uses cases of P2P token streaming such as real-time bidirectional payment channels among crypto exchanges to instantly flatten out arbitrage structures across different exchanges through trading bots.

This new payment method is eliminating credit risks as well as intermediaries. In addition it eliminates escrow business logic somewhere else. Typical escrow business logic is run by today’s complex ERP and payment systems, a third party, a smart contract or a trusted computing enclave.

P2P token streaming is built upon a simple principle: Lock something on the main chain and assign it a connected system with a (much cheaper) consensus algorithm.

Inter-blockchain protocols such as cosmos, interledger, plasma, polkadot or sidechains are using similar mechanisms. These protocols can be understood as forms of (more complex) streaming channels among blockchains.

P2P token streaming is an interoperable Plug-and-Play payment method for direct counterparty transactions with (almost) zero transaction costs at (almost) no credit risks. P2P token streaming will drive significant innovation for the 4th industrial revolution while enabling an efficient supply medium exchange among machines and humans.

Outlook Liquid Supply Medium Exchange for Machines PART 2

In the second part of this article we will introduce the concept of token streaming among digital twins, i.e. the digital representation of physical objects, machines and humans. This concept enables entirely new transaction systems for the 4th industrial revolution.

We will also describe a powerful alternative solution for P2P token streaming and liquid supply medium exchange using digital assets in Blockchain Databases such as BigchainDB, the interlegder protocol and its integration with Ethereum and IOTA and other existing payment channels concepts.

We acknowledge the help of and the discussions with our valued colleagues Jack Gavigan, Heiko Hees, Alexander Culum and Dominik Schiener to write this article.

About the Authors:

Dr. Carsten Stöcker is founder of Spherity GmbH. Spherity is a scalable decentral platform for the 4th industrial revolution providing secure identities and digital twins bridging the physical, biological and digital spheres. | Twitter: Carsten Stöcker

Dimitri de Jonghe is co-founder and Technical Architect of Spherity GmbH. He worked as head of application engineering at BigchainDB and is now one of the core protocol designers for Ocean Protocol.

Dr. Michael Rüther is CFO/COO and co-founder of Spherity GmbH. Prior to joining Spherity Michael founded two ventures in the IT and innovation space. Michael has a cross-industry technology background.

ADDENDUM — Transaction Privacy with zCash

The zCash section is intended to describe the potential to use zk-SNARKs technology to facilitate blockchain payments for a machine economy while maintaining the parties’ privacy. As currently implemented, zk-SNARKs technology is subject to a performance-scalability trade-off which limits the practicability of large scale deployments for use cases in which the devices connected to the blockchain have limited computational power. For example, with the current levels of performance, the amount of time required for a smartphone device to generate the zk-SNARK proof required to create a shielded transaction (e.g. to deposit funds in escrow) is likely to be significantly longer than would be acceptable for a consumer application.

We are aware of the existing scalability limitations of zCash and the challenges in trusted computing including dependencies HW and SW of one manufacturer (e.g. Intel SGX technology and drivers) as well as TEE vulnerability to side channel effects. Further alternatives are the use virtual enclaves, secure multi-party computation (sMPC) and privacy-preserving smart contracts. First zero-knowledge proof features for privacy preserving smart contract transactions were deployed in the recent Byzantium Ethereum upgrade and will further be developed for Ethereum 2.0.

Zero knowledge proof system [17] and sMPC are quickly advancing and practical implementation for IoT might be in reach soon.

Addendum — Teechain, a combination of Trusted Execution Enviroments and Payment Channels

As a further technical option for token streaming is the combination of Trusted Execution Environments with an off-chain payment channel network to perform secure, efficient and scalable fund transfers on top of a blockchain, with asynchronous blockchain access and secure payment chains to route payments across multiple payment channels [18] [19].

An initial prototype achieved orders of magnitude improvement in most metrics compared to existing implementations of payment channels: with replicated Teechain nodes in a trans-atlantic deployment, the team measured a throughput of over 33,000 transactions per second with 0.1 second latency.

ADDENDUM — Thoughts on Applying the HAWK Protocol Method with TEEs and zero-knowledge proofs for EV Charging

One circumstance in which this might not be suitable solution would be if there was requirement to keep the smart contracts’ “business logic” private including an off-chain TEE. If this is the case, concepts such as the Hawk protocol [20], which is similar in nature to (but pre-dates) Microsoft’s cryptlets concept. With Hawk, the smart contract is split into two parts:

  1. a public contract, which runs on the public blockchain, and
  2. a private contract, which is executed “off-chain”.

The public contract collects inputs and funds from the parties. The private contract takes the form of a cryptographic protocol which decides how the funds that have been collected by the public contract are to be (re-)distributed. The public contract will only distribute funds in response to a valid instruction from the private contract, accompanied by cryptographic proof that the private contract executed correctly.

Because the private contract must be executed “off-chain”, Hawk requires the involvement of a “manager” to execute the private contract. While the manager can see the transactions that take place in a private contract, she cannot affect the outcome of the contract. In essence, the worst thing a manager can do is not execute (or abort) the private contract. To protect against this, the public contract can be programmed to refund the parties’ funds if the private contract isn’t executed correctly in a timely fashion.

Because correctness-of-execution is proven cryptographically, a reputation factor can be replaced with trust of the cryptographic proof. This means that the logic contained within the private contract can be kept private from everyone except the manager.

If the public blockchain in the HAWK concept supports private transactions, the identity of the participants can be kept secret. While the inputs and funds the parties send to the public contract will be visible to the manager, she won’t know the parties’ identities.


[1] Medium, Carsten Stöcker, August 26, 2017, “When a Machine is the Customer — Designing for Machines

[2] BlockCharge on Youtube, March 24, 2016, “BlockCharge — EV Charging via the Ethereum BlockChain (HQ)

[3] Coindesk, January 22, 2017, “Blockchain Wallets Are Coming (Maybe Soon) to a Car Near You

[4] Trustnodes, April 29, 2017, “Germany’s Energy Giant Launches 100s of Ethereum Based Electric Cars Charging Stations

[5] Oslo2Rome EV Charging Project

[6] Education, Mike Moffatt, May 27, 2015, “Liquidity — Dictionary Definition of Liquidity”

[7], Eric Hughes, March 9, 1993, “A Cypherpunk’s Manifesto

[8] Zcash Blog, Jack Gavigan, March 08, 2017, “R3 Report on Confidentiality & Privacy for Blockchains

[9] Personal communication Jack Gavigan, zCash, and Carsten Stöcker

[10] Raiden Network for Ethereum

[11] µRaiden, “A payment channel framework for fast & free off-chain ERC20 token transfers

[12] Hackernoon, Sep 19, 2017, “µRaiden: Micropayments for Ethereum

[13] IOTA Flash Channels

[14] Untangled, October 26, 2017, “IOTA EV charging station taking payments live with IOTA

[15] Twitter, Dominik Schiener, December 3, 2017, “A preview of the IOTA Simulation Environment of a decentralized Smart City Charging Network based on IOTA

[16] IOTA Meetup Berlin on Youtube, September 13, 2017, “#1 Meetup: IOTA and its practical application in the automotive industry

[17] Cryptology ePrint Archive: Report 2018/046, “Scalable, transparent, and post-quantum secure computational integrity

[18] Cornell University Library, Joshua Lind, Ittay Eyal, Florian Kelbert, Oded Naor, Peter Pietzuch, Emin Gun Sirer, Jul 18, 2017, “Teechain: Scalable Blockchain Payments using Trusted Execution Environments

[19] Coindesk, May 22, 2017, “IC3 Debuts Upgraded Off-Chain Transaction Protocol ‘Teechain’

[20] Hawk Protocol