Lition is a scalable public-private blockchain infrastructure with deletable data features, made for commercial products. This state of the art protocol enables blockchain-based applications to step out of their current niche into commercial mainstream deployment.

Blockchain development is co-innovated with SAP, whose chief innovation officer Dr. Jürgen Müller is also Lition’s advisor. SAP, a company with >400mn users and >10.000 developers, is developing the decentral ledger and smart contract layer, and Lition is providing the open consensus layer. Lition will run the public mainnet using Lition tokens issued in an ICO for transaction execution, staking and sidechain creation.

Lition is well positioned to design a blockchain infrastructure for business use, as it launched the world’s first P2P energy trading dApp that is commercially live in a mass market with real revenues and real customers in over 10 cities.

Next to this already-existing P2P trading dApp, there are many more use cases with initial implementations in the green energy space, with potential to disrupt the finance sector and beyond. Furthermore, SAP can easily implement this blockchain into their existing customer base of >400.000 making them immediately ready for blockchain use cases. It is therefore well positioned to be the standard mainnet for business applications.


Feature 1 – Light client that can run on IoT devices

Many use cases need IoT devices, e.g. sensors, appliances or Smart Meters, as used by Lition (see the appropriate section in the use cases). Today’s blockchain clients who participate in the network as nodes always require significant storage and processing capacity. Lition’s current Ethereum client from Parity (, the most popular client in use, needs over 300 GB of storage. Even special clients like GETH1 need 80 GB of storage in their fast mode, going as low as 40 GB for pruned (trimmed) clients if only the most recent blocks are stored. Pure light clients that only store block headers go down to 40 MB, but just like remote clients that don’t need any storage, light clients do not have access to the data of previous blockchain executions. The latter, however is needed to execute smart contracts and to verify the correct execution of network nodes.

A blockchain built for widespread commercial use therefore needs clients that can run on thin hardware, like in the case of Smart Meters or the control units of the distribution grid’s voltage regulators while still calling and verifying the smart contracts they deploy. Other industries face the same barriers with existing blockchains, for example banking with lightweight Point-of-Sales (PoS) devices or the automotive sector with connected cars, increasing relevance for such features beyond the energy space.

A promising solution could be, which is piloting a similar light client, but so far is only limited to the Ethereum network with its corresponding shortfalls.

Feature 2 – Low transaction costs

High transaction costs caused by low energy inefficiency are a common drawback of typical blockchain implementations, with Bitcoin as the most prominent example. Today, a smart contract execution for an trade on the existing Lition use case costs approx. USD 0.60. The reason is the number of hash computations that are required by the Proof-of-Work (PoW) consensus algorithms, and thus the underlying energy costs to calculate them.

Bitcoin currently needs 60 TWh2 annually for its blockchain to operate, an amount of energy equivalent to the country of Columbia’s annual energy consumption. At Lition, a sustainable energy environment is key, and it is therefore pivotal that it operates on the most energy-efficient platform available. In comparison, the Ethereum blockchain consumes 78 kWh/transaction2, thus making it 12.2 times more energy efficient than the Bitcoin solution, which uses 957 kWh/transaction2. These numbers will further improve once Ethereum developers switch from their current PoW solution into a Proof-of-Stake (PoS) algorithm and Vitalik Buterin’s work on off-chain smart contracts with Plasma3 is released into production state. To operate sustainably, Lition aims to reduce the energy consumption and thus, costs per transaction, to less than USD 0.01.

Almost all modern infrastructure chains like NEM, Cardano, ZipChain, or Hashgraph have developed solutions to solve this issue with the many open-source reference implementations available. Therefore, this issue has been solved. However, none of these chains are additionally able to solve the other drawbacks that concern businesses, like storage of private data in separated but publicly verifiable sidechains, or deletability.

Feature 3 – Fast Block confirmation

Currently, customers need to wait well over a minute until their transactions are successfully executed on the Ethereum blockchain. The underlying reason is high block confirmation times of 10-20 seconds along with a block height of several blocks needed for certainty. As no paying customer is willing to wait more than 1-3 seconds, Lition needs a solution to massively improve the feedback times for smart contract executions.

Similar to the second issue of high transaction costs, most modern chains have claimed to find solutions to this problem while staying permission-less. But as is the case with the transaction cost issue, they have not been able to do so in combination with solving other shortcomings, like private data (see upcoming point).

Feature 4 – Private sidechains for private data

Today, typical permission-less blockchains store their data publicly, allowing criminals to potentially misapply this information, e.g. bank accounts or social security numbers. In the existing use case, this could be Smart Meter data, e.g. availability of electrical appliances, can provide an indication of household income: A customer possessing 3 TVs, an energy-efficient dishwasher, a dryer and an electric floor heater is obviously wealthier than the average household. This is all data that Lition can already detect today with its Smart Meter integration (see the use case section later in this white paper for details), but no customer would want this information to be publicly known.

This aspect applies to many industries, such as (a) banking with personal loans, transaction data of bank accounts, (b) construction with historic property data, (c) healthcare with medical patient data, (d) supply chain management with product, contract and origin data or (e) social media with identity or personal (meta)data.

Typical solutions propose to reach privacy by putting private data on a public chain and encrypting it, as suggested e.g. by researchers Karla Kvaternik et. al.4, or used for location-data by the blockchain Project Fysical5. Lition is aware that these solutions have fundamental limitations as the encrypted data is still publicly available and therefore prone to hacking if vulnerabilities in the encryption are found or sufficient processing power is available. This is unlikely now, but as the data is stored permanently and publicly it will also be there in 5 or 10 years, when Quantum Computing is to emerge and loopholes may be found. This has happened many times so far, e.g. for the widely used WEP encryption, which due to faulty design does not give reliable protection against hackers.

Instead, Lition knows private data needs to reside on private sidechains available only to trusted nodes. Furthermore, public sidechains are still needed for public data, such as the offered energy price of powerplants that need to be publicly available. Both the private and the public sidechains need to be embedded in a greater public and permission-less network so that new participants can easily join to ensure a developer-friendly and easy adoption of the chain. Thanks to the new pseudo-zero-knowledge-proof algorithm developed by Lition, public nodes can still verify the private transactions inside private sidechains, ensuring overall consistency.

Feature 5 – API interface for chain ↔ backend communication for easy developer access

During the development of the Lition energy trading use case, Lition developers had to spend intense time and resources to develop an API interface to communicate between the blockchain and the Lition backend application. In fact, blockchain nodes need a simple API interface to allow easy integration into non-blockchain applications. This is basically required by any business blockchain application in every industry that needs integration into offchain systems.

This issue needs to be addressed in order to allow a quick and easy rollout of the Lition Blockchain solution into mass markets and additional use cases. Typical large industry players have a complex legacy IT landscape, making an easy and seamless integration even more important. These findings are not new, as corporate-targeted projects like NEM or SAP’s blockchain-as-a-service solutions have also identified this pain point, which now needs to be addressed. However neither NEM nor SAP’s current solution is able to also solve the other issues that remain in regulated markets.

Feature 6 – Data can be deleted from blockchain

Currently, transactions on blockchains are permanently and irreversibly stored on the blockchain. While this is a precondition of any public chain, it is not necessarily in the customer’s best interest. In an ongoing business relationship, a customer might accept that his social security number or bank account is needed, but he wants to make sure this data is deleted once the business relationship ends and there is no more need for the data. However, once a customer terminates his contract, there currently is no way to delete this sensitive data – blockchains are not designed for this. Most solutions today that support deletion of data only store the references in the blockchain, with the real data stored off-block. When private data needs to be deleted, the on-block reference is kept unchanged, but the off-block data is deleted. The problem with this approach is that any smart-contract execution needing private data requires access to the off-block resource, defeating the purpose of a blockchain.

In addition to customer issues, there are also legal requirements from the GDPR (General Data Protection Rules) effective throughout the EU, and many other national data-privacy guidelines. They enforce deletion of private data once it is not needed anymore. For the EU, violations of this law can lead to fines up to 4% of a company’s global annual revenue, which can be hundreds of millions of dollars for large corporations. This was also the focus of several

While this might not be an issue for Proof-of-Concept blockchain applications, it is once an application launches and is brought to commercial mainstream adoption. Therefore, any business desiring to share its blockchain application with on-block storage of private data to the masses needs to use an infrastructure supporting data deletion

Blockchain Architecture

Lition presents the design for a blockchain network and minimum requirements for a governing agreement among a privileged subset of the nodes’ operators, ensuring that private, sensitive data can be handled and securely deleted on demand – even connected to smart contracts for deletion. The guiding design criteria are postquantum security for data integrity, a path towards post-quantum security for data privacy, data minimization under the constraint of providing fault tolerance, privacy of sensitive data, a provision to delete all occurrences of sensitive data, and the freedom to join as a (non-privileged) node without any special provisions or legal obligations. Lition also proposes a novel approach to solve the security issue of private data (and private transactions) in a blockchain technology by providing a technique to publicly prove the correctness of a transaction involving private data without revealing the private data. This proof is not fully trustless but is of a probabilistic nature and is similar to non-interactive zero knowledge proofs (NIZKPs).

Figure 5: Lition Blockchain infrastructure concept

The fundamental concept is based on a Proof-of-Stake consensus mechanism with two types of nodes: Public nodes and privileged nodes. The public nodes are permission-less and have access to the mainchain as well as any public sidechain. They don’t have access to the data of private sidechains, but they have access to the transaction hashes and endorsements provided by privileged node. This allows public nodes to probabilistically verify the integrity of private data without knowing it. Any node can subscribe to public sidechains, but nodes willing to mine private sidechains and thus see private data need a special permission by the owner of the sidechain (actor), making them privileged nodes. To ensure data is truly deleted, such nodes operating private sidechains will also need to agree to terms of service. These terms of service require the nodes to carry out data deletion requests needed by legal requirements on data privacy rules, for example.

While the functional requirements addressed by this blockchain are derived from the shortcomings described earlier in this chapter, Lition provides the technical description in a separate, technical whitepaper. It is confidential, caters to the technically interested reader, and also provides the fundamentals from current research.

See Also on BitcoinWiki