IOTA-powered Telco Asset Marketplace: Architecture Overview (Part 2)

After reading the first and more business-oriented part of our blogpost, this second part will guide through the technical implementation of our Telco Asset Marketplace and show how it works in practice.

A multi-sided marketplace can only build on a decentralized trust layer. In our prototype marketplace, the trust layer was provided by the IOTA infrastructure.

To build an asset-trading marketplace, we need to develop a number of building blocks, more or less decentralized.

The result of our work is the first IOTA Telco Asset marketplace PoC. You can play with it here.

The result of our work is the first IOTA Telco Asset marketplace PoC. You can play with it here.

For our first PoC (Proof of Concept), we focused on the Orders Management, Settlement and Payments architecture blocks. By storing agreements onto the IOTA Tangle, we keep an immutable trail of which asset is accessed by which Service Provider, without the involvement of any centralized third-party authority. Based on this information, requested payments can be easily tracked and distributed.

The figure below summarizes the different functions available to the marketplace actors, namely Asset Providers, Service Providers and Auditors.

To implement the proposed workflow and to capture each actor data and transactions, the implemented architecture utilizes MAM channels. A digital twin based on the offers, requests and orders data models was defined as the basic structure for every MAM message. As a result, each MAM channel represents an immutable audit trail of asset offers, requests and orders.

MAM Channels were preferred to store data instead of using individual and independent IOTA transactions, for the following reasons:

Assets belong to a given Asset Provider, therefore they are unique and need to have associated offers easily linked together. This can be done by posting MAM messages with the current offer (e.g., availability and price) in a dedicated Asset MAM channel.
Requests generated by the same Service Provider need to be linked in order to force one request per asset at a time (per Service Provider) and to simplify auditing. This can be done by posting MAM messages with the current request in a dedicated Service Provider MAM Channel.
Assets assigned to Service Providers through orders should be linked to the identity of the Service Providers. To this extent, identifiers of MAM Channels (root keys) can be used as a proxy for the identity of Assets and Service Providers. A dedicated Orders MAM Channel maintains this information.

Asset Providers create a new MAM channel for each of their assets. The first MAM message contains details of the asset. All following transactions specify the start and end of a specific offer and link to the successful order (if any) involving it.

Service Providers create a request by specifying the details of the requested asset. A new MAM channel is created for this request. The first MAM message contains details of the needed asset. All following transactions specify the start and end of the specific request and link to the successful orders (if any).

When an order is created, a new MAM message in the orders MAM channel is created to immutably link into the IOTA Tangle the relevant matching asset offer and request.

A matching algorithm runs automatically once a new offer or a new request is created.

Manual matching is also available and can be triggered by initiating a search of assets and offers.

After confirmation of a found match, payments are then processed. IOTA tokens are transferred from the Service Provider wallet to the Asset Provider wallet as soon as an order is confirmed.

Although the current architecture focuses on a restricted number of functionalities, however, we already implemented a notifications service that should simplify integration of third-party building blocks. For instance, this allows a connected Orchestrator to listen for orders creation notifications and consequently configure temporary access to selected assets for service providers.

All APIs have been matched to existing TMForum APIs,in order to simplify such integration with external third party services.

For a live demo of the marketplace, check out this video:

The marketplace is composed of two main sections. A Marketplace area (shown below), can be accessed by everybody, without any registration. This area shows the list of currently available asset offers and requests and their details.

Once a marketplace user logs in, his/her requests and offers are highlighted. By selecting an active offer or request, the system automatically identifies matching requests and offers (if any).

These matches can be reviewed in the other section of the marketplace, the Dashboard page. The Dashboard is only accessible after log-in. (At the moment we provisioned a simple log-in mechanism through Google OAuth ID). From the Dashboard a user can:

Fund his/her IOTA Wallet to pay for assets
Create new asset offers and requests by filling out template forms that collect the required asset’s (offered or requested) info and to immutably save them with one click onto the IOTA Tangle
Managing existing (not expired) asset offers and requests by enabling, disabling, or removing them
Generate orders from matching asset offers and requests, and immutably store them with one click onto the IOTA Tangle
Automatically send or receive the corresponding IOTA payments
Review owned asset history by gaining insights into orders that make use of them and corresponding generated revenues
Access transactions’ raw data and explore them using any IOTA Tangle Explorer

From the dashboard, a user can also access his/her API Key and User ID. These are useful to call the provided APIs from third-party services and to guarantee access to auditors who wish to review existing orders for compliance purposes.

Developing a decentralized, immutable audit trail of asset offers, requests and orders allow all the transacting parties to increase their trust while auditors can gain full transparency and traceability of the process.

Using IOTA for such infrastructure brings additional benefits:

The feeless microtransaction structure does not impose any extra cost for the use of this infrastructure, neither does it limit the amount of data and transactions that can be processed
The flexible transaction structure allows for the accommodation of various asset descriptions along with offer, request and order data models
The permissionless nature allows each stakeholder to host a node and a copy of the ledger, thus removing the single point of failure as well as the need to trust intermediary third parties to provide the marketplace “trust” layer
The use of restricted MAM channels protects the confidentiality of the order (who has access to what) and controls the access to the relevant information
The IOTA token provides an interoperable payment system.

While this PoC confirms the value of an Asset Marketplace, our future work will continue to facilitate development of other elements of this decentralized platform. This is in addition to continuing engagement with an ecosystem of CSPs for the deployment and testing of this marketplace in real testbeds.

If you are an asset or service provider who wants to learn more and help to shape this vision and participate in real testbeds, please do get in touch.

On the other end, if you are a technology provider, we would like to understand how your technology can fulfill the requirements of the missing marketplace building blocks. Interesting functionalities will include:

Decentralizing asset and service providers organizational identities
Decentralizing asset delegation and access
Building a reputation system for asset and service providers, leveraging the integration of IoT data to monitor asset use

To get involved in developing technology components of the marketplace please contact: [email protected]