NEM Service Partner, Unibright, and Deutsche Bahn Vertrieb: Ecosystem Tokenization via the NEM Blockchain

Motivation and explanation of terms

Telling from the project’s name, the terms of the working title “Ecosystem Tokenization via Blockchain” shall be explained and motivated.

Ecosystem

There are both structural and technical views on an ecosystem.

Structural, the Deutsche Bahn and all connected service providers already build an ecosystem. From a customer’s point of view, some actors in this ecosystem are already connected, e.g. when a customer buys a ticket and the corresponding travel is fulfilled by both Deutsche Bahn trains and local trains of independent providers. Other players are not yet fully integrated, e.g. the surrounding services like hotels. A loose coupling of the involved players is provided by vouchers Deutsche Bahn offers, e.g. a hotel voucher a customer can use when he missed the last connecting train due to a train delay.

Technical, an ecosystem is defined by datastreams between different companies and their underlying IT systems. Some of these datastreams may be defined and empowered by the offering of APIs on one or both sides of the connection. Other data streams may exist but are not yet supported by an automated integration.

Marten Jung, CEO of Unibright, states:

One goal of the workshop concept was to define better, which players can be part of an ecosystem around Deutsche Bahn and to make proposals on how this ecosystem can be built. The result should feel natural to the customer and provide tangible advantage.

Tokenization

The method chosen to build an ecosystem in this challenge is Tokenization. Basically, it means to transfer the participating values and assets into tokens, that act like value representatives or vouchers with a specific sense in the ecosystem.

Tokens can be configured as transferable, partial, controllable and can be restricted in their use due to location, time or events.

Daniel Benkenstein, CIO of Unibright, explains:

One goal of the workshop concept was to tokenize values and assets that can be part of that future ecosystem, and also to check on possible transformations of existing value based systems like “BahnBonus-Punkte” (a reward program where a customer can collect points for each ticket purchase).

Blockchain

Blockchain is the perfect technology to build tokenized ecosystems. The values in a blockchain can be personalized while not being centralized. The concept of “trustless trust” is defined by blockchain technology itself, making it easier for new participants to decide on becoming part of the ecosystem. And finally, the client has a real benefit of being part of a decentralized ecosystem and implicitly strengthens the ecosystem by using it.

Stefan Schmidt, CTO of Unibright, adds:

The technical part of integrating existing players into a newly build ecosystem is not trivial. Therefore, one goal of the workshop concept was to show, which parts of the solution can live in a blockchain and how can they be integrated with the “off-chain world”, a challenge that is explicitly targeted by the Unibright Framework.

Basic Concepts

The basic idea is to represent all parts of a common “journey” by tokens on a blockchain. This means single travels (or travelled miles), services, catering, hotel bookings, local transport or other assets that bring value to the overall journey.

These assets can be purchased by the customer, to save them in a personal wallet. The customer can transfer these assets, in a whole or divided into parts, he can perhaps sell them or give them back to the issuer.

The use of a specific asset is then carried out by transferring the corresponding tokens from the customer’s wallet to those of the service provider.

Roles and Processes

To enable the process, the following roles are defined.

• The issuing office defines new tokens to become part of the ecosystem, e.g. when a new provider is included
• The provider can offer his tokens for sale on a dedicated platform
• A collector transfers tokens from users to providers. This can happen automatically (e.g. “transferring a token per travelled mile”) or manually (e.g. triggered by a train conductor)
• The consumer manages his wallet to hold and monitor the different assets, represented by tokens. From a customer’s view, the token concept (and especially the underlying blockchain technology) should be abstracted as much as possible and should be reduced to an easy to understand the concept like “My balance”

On these roles, the following processes are defined.

• Selling and buying tokens
• Collecting tokens
• Transferring tokens
• Issuing new tokens for new assets of new providers

Use of tokenized assets

Different suppliers can define new assets (= issuing new tokens) and bring them into the ecosystem. These tokens can be (independently) redeemed for their initial purpose and also be bought later to refill the personal balance. In the example shown in the following image, “Token A” could be issued by Deutsche Bahn directly and would be redeemed per driven mile in a long-distance train (the current model does not work on billing per mile, but billing per relation).

A big benefit arises from the option to connect and convert different assets from the ecosystem.

For example, generic conversions can serve as a transformation of miles in long-distance trains to miles in local transport trains. The conversion rate could be adapted due to specific events, e.g. DB motivating a consumer to rather use a local train due to a temporal higher workload in the long-distance train network.

Therefore, a high potential is given in time-, location- or event-based conversions, for example:

• Suspension of a route: Option to convert “Distance Token A” to “Taxi Token C”
• Train delay: Subsidized (“cheaper”) conversion of distance tokens to hotel tokens, e.g. when the last connecting train was missed and there is no option to go on
• Train delay: Subsided supply of food vouchers
• Advertisement: “Airdrop”-Vouchers for specific events at specific locations

These conversions could be offered depending on location (specific train), depending on time (“only valid in the next 20 minutes”), or automatically, based on specific events (“delay> 29 minutes”).

PoC Implementation

For the Proof of Concept, 4 different areas were covered.

• A token and asset model based on NEM features, including a basic REST-API, working on these assets and offering the most important operations.
• Views for the customer, to show the experience of a tokenized ecosystem from a consumer’s perspective.
• Views for the responsible designer of the ecosystem, using the Unibright Workflow Designer.
• Views for the responsible manager of the ecosystem, using the Unibright Explorer.

Assets and Tokens based on NEM features

The described solution is based on the NEM Protocol, offering different smart assets and operations based on NEM features. You can read on the used NEM features (tokens, wallets, levys…) on the official NEM documentation.

• For each asset, a specific token is created, representing the balance of this asset
• For each token, a reverse token is created, modelling the claim to this asset as soon as the service is provided. This token is connected to a “levy”-token that disables the recipient to refuse this claim
• All tokens initially are located in wallets that are owned by DB, acting as the central issuing instance
• Every purchased travel leads to an account (wallet), assigned to a specific user, holding the purchased and claimed tokens

The API has to support the following operations on these smart assets:

1. Booking a journey: The customer is able to book a journey via an app and to pay for it
2. Creating a wallet and purchasing tokens: A new NEM account is generated, and all tokens belonging to the assets of the journey are transferred to the corresponding wallet
3. Transferring tokens: As soon as the service is provided, the corresponding reverse tokens are sent to the wallet of the user using that service. The number of reverse tokens may differ from the amount of initially calculated tokens due to event-based discounts or conversions from other tokens.
4. Clearing: Periodically, a “clearing” is performed. The amount of reverse tokens per asset controls the refund of the initial asset token to the issuer, hence clearing the reverse tokens. If fiat money is involved, the different service providers can now receive the money from the central issuer.

Customer Experience

For the customer, the main advantage of purchasing assets in an ecosystem of a public transport company is the option to book a journey as a complete experience.

For the workshop, we presented a “door-to-door” solution, assuming a customer wants to book a journey from his very home to a dedicated end location.

Below, you find the screens of the customer walkthrough.