WULET: a blockchain platform for the loyalty programs implementation and bonus points exchange

Transcription

1 WULET: a blockchain platform for the loyalty programs implementation and bonus points exchange Alexander Tkachev, Alexey Popov, German Domanskii, Leonid Strimovskii, Vladimir Tikhomirov, and Valeriy Dubrava September 15, 2018 Abstract Loyalty programs are currently losing their effectiveness. They are not user-friendly and people do not use them. Companies need a new solution to stop losing money and loyal users. In this paper, we describe the logic of implementing a system that allows users to conveniently store and use loyalty points - the WULET ecosystem. We will describe technical aspects, the logic of data distribution, the processes of connecting loyalty programs and the usage of loyalty points. This platform allows users to exchange points among loyalty programs freely, which increases the interest of users to purchase them. Thus, partners receive an effective tool for attracting and retaining customers. 1 Introduction Promotion codes, bonuses, discount cards - this is what people face every day. However, most of such bonuses are not marketable enough [1]. Unused points are burned, and about 40% of users do not even know that they take part in a loyalty program at all. A classic loyalty program is a centralized service, which records all of the loyalty program terms. User data is stored in a database, which is at the core of the service. Such information as the balance of points, timing of their burning, accrual history is closed, and users have a limited access to it. Users may use an application or a web-service, if any, or should specify the data directly in ticket offices of a retail chain. As a result, the user cannot quickly monitor the balance of their loyalty points and use them in an optimal way. Most of the points either are burnt out or remain unclaimed. There is no technical opportunity to convert points of various loyalty programs to the points of other loyalty programs. The creation of a loyalty points exchange may be a solution to this problem and there are projects already that are moving in this direction. However, they have significant drawbacks, as some of them include a very limited number of bonus programs [2], some require the presence of all bonuses in a certain amount, some do not have a convenient interface, some do not have confidence from users. There is a number of loyalty programs that allow users to convert bonuses of companies only of similar subjects, for example, flights [3]. None of the solutions tackle the issue of data openness. The usage of blockchain provides the required level of anonymity and at the same time openness of information. This technology is the best solution for the sphere of loyalty. Private user information in blockchain is inaccessible outsiders and does not have a binding to the user name on the platform. At the same time, the balance of points, timing of combustion and the entire history is available to each user. In addition, the blockchain system makes it possible to make the conditions of loyalty programs more transparent, including the volume of points emission, provisions (if any), the amount of points and the amount accepted for payment. Partners launching their loyalty program can be confident that the platform works properly, due to the openness of the blockchain system and the fact that the logic of any contract operation can be checked and compared with the published code. The following scenario is at the heart of the WULET platform: users can turn all of their bonuses and points into tokens, collect them in one place and convert these tokens to other ones at any time. This eliminates the need to carry all discount cards with them and write promotional codes down in a notebook [4]. Blockchain guarantees the safety of operations, makes it possible to track all operations and their speed. Bonuses on such exchanges receive high liquidity [5]. The WULET platform is implemented on the basis of the EOS blockchain system, because the transactions of the blockchain are free, and the bandwidth is enough to secure 1

2 the requirements for higher transaction speed. The transparency of blockchain will also make analyzing the behavior of users much easier, so as to offer them only products they are interested in or suitable for all parameters that users are interested in. The loyalty points exchange is convenient both for users and for partners - it allows users to conveniently distribute their bonuses and save them, and it s easier for partners to launch new bonus programs and find new customers. The study showed that 73% of users are more likely to recommend and say good things about brands with good loyalty programs [1]. 2 Architecture Lets consider the architecture of the WULET ecosystem. The platform is a combination of a blockchain and a classic enterprise solution [6], which integrates them. For a better understanding of the platform architecture, it is useful to consider it from different angles: external world subjects interaction and platform modules interaction. It is also useful to present the architecture at different levels of abstraction [7]: from the most general representation to the consideration of particular modules and solutions. 2.1 Subjects and interaction among them Figure 1 shows the interaction among the participants of the ecosystem: Loyalty tokens issuer is a partner of a platform that plans to launch or already has a loyalty program. Partners differ in the way they interact with the platform: there are partners with the existing loyalty program and those that implement (or transfer) a loyalty program on the WULET platform. Loyalty tokens consumer could be the same partners as issuers or other organizations that accept payment (or partial payment) for loyalty tokens. The platform will create a single platform for the sale of goods for loyalty tokens. Exchange is a service for converting loyalty tokens. It is part of the platform. It allows holders of loyalty tokens to exchange points for WU tokens and acquire loyalty points for WU tokens. Customers end point users that own or can receive tokens, and also change convert on the exchange and pay for their goods. Figure 1: Key roles on the platform. 2

3 2.2 Loyalty tokens flow Consider the life cycle of loyalty tokens (Figure 2). Initially, tokens are emitted by platform partners - organizations whose loyalty programs are integrated with or directly started on the WULET ecosystem. Users can convert these tokens of the loyalty program on the exchange through the platform WU token. Also, the user can generate partial or full payment of the partners goods by a loyalty token. The amount of tokens spent on the purchase of the product comes out of circulation, that is, it burns out. A partner can also limit the lifetime of loyalty points. In this case, the points are burned after a specified period. Figure 2: Loyalty token life cycle. 2.3 Modules & interaction The platform can also be considered as a set of modules, highlighting the components that run on the blockchain, and blockchain external modules. Internal modules implement key business logic; external modules implement integration tasks. Next, lets consider the modules in more detail Modules overview Figure 3 presents the partners divided by the integration method: external loyalty systems, in which the loyalty points management and accounting are centralized and internal, fully implemented on the WULET platform. The platform is imagined in the center by a single module in order to simplify the scheme. Applications for users and partners, solutions for integration with payment terminals and E-commerce are painted blue. Private integration solutions and utilities for platform management are painted gray in the diagram below. Wu Platform Smart Contracts are the key components of the platform, executed as smart contracts on the EOS blockchain. The module is described in detail below. All the interaction among smart contracts and modules is realized through messages in transactions (standard for the EOS approach). Client applications are web (PWA) [8] and mobile applications (ios, Android and others) for loyalty token holders. They realize the functions of managing keys, obtaining tokens when making purchases, monitoring the balance of tokens, exchanging tokens through the exchange and paying tokens. Partners applications are web / mobile applications for managing loyalty programs. Applications implement WU token balance management, Web / POS system integration management, 3

4 Figure 3: Modules and interaction. statistical information collection and its representation for convenient management of the loyalty program. Integration solutions are tools for integration with external loyalty systems. The module implements a two-way data exchange between the platform (the External Loyalty contract) and the external loyalty system. Web/POS Integration is a module for integration with payment terminals and E-commerce. This module implements an API by means of which terminals or web-stores can transmit information about the charging of tokens or write-offs in the purchase offset. The API has mandatory authorization, which is configured in the personal account of the partner. Admins tools is a set of tools to simplify the management of the platform: creating tokens - partner loyalty points, managing WU tokens, updating platform contracts and more. 2.4 WULET Platform smart contracts The WULET platform is a set of smart contracts launched on the EOS blockchain. Contracts interact with each other and implement the API for external interaction according to the EOS blockchain standard - sending messages in transactions. Users can create (publish on the network) a transaction from an already called contract or from any network node. Thus, not only users but other systems and platforms (B2B) can work with the platform through integration with the API [9] of a JSON RPC-based node. Figure 4 shows the implemented smart contracts: Exchange is a contract that implements the logic of the indirect exchange of loyalty tokens between their holders. It allows the holder of tokens to expose them for exchange: to put on the stock exchange and withdraw loyalty tokens from the exchange. Partners (owners of tokens) are allowed to deduce loyalty tokens on a stock exchange and to establish restrictions on exchange pairs. In this case, the exchange of one type of token to another is realized through an intermediate exchange for the WU token. WU token is the contract that implements the WU token. Token emission occurs on the basis of the initial sale of tokens (ICO) on the Ethereum platform. The possession of the tokens is confirmed on the EOS platform. WU token can be traded on public exchanges. Loyalty Tokens are contracts for tokens that implement loyalty points for platform partners. 4

5 Figure 4: WULET Platform Smart Contracts. Partners are allowed to issue securities with collateral, and customers are allowed own tokens, exchange them through the exchange and burn by making purchases (payment) for tokens. Management Contract is the contract for the new loyalty tokens release by platform moderators and their registration on the exchange. External Loyalty is a contract for interacting with special Gateway tools that implement integration directly with an external loyalty system. The interface of this contract corresponds to the interface of Loyalty Tokens contracts so that other contracts (for example, the exchange) can work in the same way with external and internal loyalty tokens. 2.5 Contract structure and interaction For a better understanding of how the interaction with the contract is carried out, consider the Figure 5, describing the typical structure of the contract and the ways of interaction. In general, the contract consists of business logic (in the form of a set of methods) and an open database. Methods can be divided into public ones - allowing users to get information or make a change to all users, and private ones - allowing users to make changes only to a limited number of people (platform administrators and moderators, other contracts). Everyone have an access to the database and may read information from there. Figure 5: Common contract structure and interaction. There are two types of interaction with contracts: direct, when the contract calls the methods 5

6 of another contract (it is marked in red in the diagram) and through the transaction, when the contract or user publish the transaction to the network (it is marked in black in the diagram). Since the blockchain data is open, everyone has a direct access to them (it is indicated in green in the diagram). The following modules can be identified on the diagram: Client is an application for access to the blockchains network. The client allows users to create a transaction or read data from any account. To interact with the network, JSON RPC is used by the network node. TX Queue is the visualization of the transaction process in the blockchain. Smart Contract is a smart contract for EOS blockchain. It consists of the following components: Business logic the basic logic of the contract. Public API is a set of methods for a wide range of users to interact with a contract. Any of these methods can be called up using a transaction or a direct call. Private API a set of methods for a limited number of partners to interact with a contract (contracts or customers). 2.6 Contracts interaction with outside world For the consistency of the blockchain and the formation of blocks by producers, it is necessary that the code of the smart contract work as determined as possible and not depend on the external (as to the blockchain) world. For this reason, requests to any Internet resource cannot be made directly from the contract. The special services oraclize, are used to obtain external information [10]. These services track events from certain contracts in the blockchain. And when a special request event occurs, the information is sampled and transferred to the contract using a standard blockchain transaction. All external modules of the WULET platform work in the same way: they scan network blocks, detect events, react to them, execute logic outside the blockchain, and then enter data into the blockchain through the transaction (if required). Figure 6: Interaction through Oraclize. 6

7 Figure 6 visualizes the interaction of entities in a situation where the task is to transfer data from the outside world to the contract, but so that the contract itself determines the time when the data is needed. In a particular case, which data exactly is needed. This action is divided into two separate transactions: a transaction that initiates a data request (can be created both by the client and another contract), and a transaction that returns data to the contract (initiated by the oraclize service). 2.7 Clients and Partners Applications Modules These modules are executed according to the classical scheme of enterprise solutions and consist of a database, business logic implemented as a web service, and client software. The main distinguishing component is the integration with the blockchain. For the backend, the solution is a module that scans blocks. For client software, this is a special API for publishing transactions to the blockchain network. Figure 7: General structure of the client and partner modules. Figure 7 shows the client software: these are mobile applications for ios, Android and other platforms, and the web interface. The applications and the website interact primarily with the backend module via the RESTful API. The client software can interact directly with the blockaccount through open nodes to publish transactions. The backend module is designed according to the classical enterprise architecture, and in general can be divided into three levels: API - presentation level, BL - business logic level, DAL - data access level. An important component of the backend solution is the block scanner. This module scans all new transactions of the blockchain account and selects the necessary events from them (changes in the state). Events are already processed in business logic along with other requests to the module via the API. Such an architecture allows not only to implement the basic functions of the application and server interaction, but also to make an analytical system with the ability of multi-criteria selections and joins. This makes it possible to make your partner s personal office a convenient tool for managing and analyzing the loyalty program. The partner will also be able to upload data on his loyalty program in a standard form (XML, SQL, etc.) and process this data in external solutions. 7

8 3 Implementation selection 3.1 Blockchain selection Various blockchain platforms could be taken as the basis of the decentralized solution. Private blockchain will make it possible to implement almost any business logic and achieve high platform performance, but will not give the necessary confidence from partners and users. Therefore, the use of public blockchain is always more preferable. Among all public blockchains, only those that support smart contracts that are unlimited in functionality (the so-called Turing-complete ones) are suitable for implementing the platform. Another important criterion is the prevalence of the detachment if the blockchain is not popular, then its publicity may be insufficient and the consensus is vulnerable to the attacks of the majority. All these criteria significantly narrow the choice of a suitable blockage Ethereum At the moment, the public blockchains with support for smart contracts leader is Ethereum. However, Ethereum has a number of limitations: the first one is a low throughput, about 17 transactions per second. The second one is the cost per each transaction. For example, users pay $0,5 per each transfer of tokens (60k of gas costing 20 Gwei at the rate of $417). This cost significantly reduces the capacity to interact with the platform. And the commission for the transaction will be taken regardless of whether the action is successful or not. The blockchain system will charge a commission for the cancellation of the transaction Neo The NEO platform is designed to solve this problem, but the cost of gas on this platform leads to the $5000 (500 GAS at a rate of $10) token contract creation cost. Thus, each procedure for adding functions to the contract will require a cost that can severely hamper the development of the platform, especially at the initial stage Qtum Another public blockchain is Qtum. It combines the advantages of Bitcoin (UTXO) and Ethereum (EVM). The throughput of Qtum is significantly higher than in Ethereum. However, as in Ethereum, the limitation here is the high cost of transactions. Transaction of QRC20-tokens will cost [11]: 40 satoshi * Gas = 0.1 QTUM = $0.7 at the rate of $7. That is, for one transfer of tokens, the user will have to pay $ Radix Radix uses the patented Tempo consensus model. Thanks to it, by the end of 2018 Radix will be able to develop a huge bandwidth more than transactions per second (now about 4000). Radix also supports EMV and standard POS-terminals for sending transactions. Radix has one significant drawback that makes the development of a system based on this technology impossible right now Radix Main Net has not yet been launched [9] [12] Ubiq Ubiq is the fork of Ethereum. The mechanism for the formation of the transaction price in Ubiq is the same as in Ethereum, but it operates on UBQ instead of ETH. Since UBQ is now almost 400 times cheaper than ETH, then transactions in UBQ are also cheaper respectively. In addition, Ubiq uses EVM that makes it easier to develop smart contracts for it. Although the bandwidth of the Ubiq network is higher than in the Ethereum, Ubiq uses the same PoW consensus algorithm it received from Ethereum, which is its disadvantage. PoW is the most inefficient mechanism for achieving consensus in terms of productivity NEM The main advantages of NEM are: 8

9 Low commission cost (0.001%). Transactions are confirmed in a short time. The number of transactions per second reaches NEM smart contracts are deployed outside of the blockchain, which, on the one hand, increases the speed of these smart contracts execution, simplifies updates, facilitates the code, but, on the other hand, reduces decentralization, which leads to a decrease in security level [13] EOS EOS has a number of features [14], favorably distinguishing it from other blockchain systems: Scalability. The bandwidth of the EOS network is already about 5000 transactions per second [15]. In the near future this value will increase 10 times. Moreover, the network parallelizing will allow users to scale the network up to a million transactions per second. In addition, EOS supports asynchronous communications and the separation of authentication from execution. Flexibility. If an error is found in the EOS application, the block manufacturers can freeze it for the time of correcting this error, and then update the code without any forks and stops of other network applications. In addition, EOS allows the node not to have the full state of the entire block, but only the data that is needed. Usability. EOS includes a set of web tools for developing interfaces, self-described interfaces and database schemes, as well as a declarative permissions scheme that allows users to easily delegate permissions to other accounts. Management. In the EOS token holders choose block manufacturers, which increases the degree of mutual trust. In case of disputes, they are resolved by a majority of votes. In addition to this, EOS does not need to pay for transactions. Users just need to have enough EOS tokens. If users own a certain percentage of EOS tokens, then users have access to the same percentage of processing power, bandwidth, and network storage. 3.2 WU Token based on EOS The WU token is the implementation of a contract that is fully compatible with the standard EOS token - eosio.token. Due to this compatibility, the WU token can be traded on external exchanges. The maximum emission of a token is equal to the emission of a token launched on the Ethereum platform and distributed within the ICO. To convert tokens from the Ethereum platform, the WU token function is extended by the ability to release tokens via an oraclize service for an amount equivalent to the blocked tokens in the Ethereum network. 3.3 Loyalty tokens To implement the basic functions of loyalty points on the WULET platform, a token will be issued for each type of a point. This token will work similarly to the platform s basic token - the WU token. That is, loyalty tokens will be compatible with the standard EOS token, except for the following: The emission of the loyalty token is unrestricted, but the issue may be limited for a specified time period or the issue may be limited to collateral. Transfer of tokens is limited in such a way that only the platform exchange can perform the actual transfer. This will avoid trading tokens on external exchanges, or passing tokens directly among users. In the future, this restriction can be removed by the platform administrator both for each, and for a specific token. Since each loyalty score is the obligation of the partner to the holder of points, it is logical to burn them with payment points (fulfillment of the obligation), thereby deducing these points from turnover. This is what happens on the platform. 9

10 3.4 ERC20 WULET Token WULET platform WU tokens are the provision for loyalty points on the platform. The Wu token itself is provided with the capital of the WULET platform. Initial capital will be attracted through ICO, conducted on the Ethereum platform. Initially, the ERC20 WULET token contract will have the ability to withdraw the token from the turnover of the Ethereum network to the EOS network using the method of locking tokens with confirmation Transferring WU tokens from the Ethereum platform to the EOS platform By converting tokens from one platform to another, in this case, we mean the procedure for removing tokens from the turnover on one platform and releasing an equivalent number of new tokens on another platform. For withdrawal, tokens are transferred to a special contract by the user and are blocked for a period of time (for example, 3 days), until the special Oraclize transfers them into a permanent lock. The primary lock with timeout is done in case if Oraclize is not be able to perform the procedure of releasing tokens on the EOS network due to network loading or due to technical malfunctions. This process is shown in Figure 8. Figure 8: The sequence of interaction of modules for the tokens release in the EOS network. 10

11 3.5 Transferring existing loyalty programs to the WULET Platform and launching new ones WULET Platform provides an opportunity to implement a loyalty program on a blockchain solution. This opportunity is both for partners who want to start a new loyalty program, and for partners with an already launched loyalty program. Let s consider each of the scenarios Creation of a new loyalty program To create a new loyalty program on the WULET platform, the partner (using the platform moderators) is to perform the following steps: Create a token contract with a unique name for issuing loyalty program points. Determine the cost of 1 point of the program in WU tokens based on the desired value of the point in Fiat currency (in case users provide loyalty points for platform tokens). Figure 9: Creation a new loyalty program on the WULET platform. Interaction of modules when creating a new loyalty program: The moderator sends a transaction to create a new loyalty program on the Management Contract. Management Contract, which creates a new Loyalty Token loyalty program contract. The partner will issue and manage the loyalty tokens in its loyalty program through this contract. Loyalty Token Contract - this contract stores the users token balance, implements the transfer of tokens among program participants and emits new ones/burns used tokens. The economy of tokens loyalty partners. A partner company that owns a loyalty program can provide its loyalty token by backing it with WU tokens, or it may not. To do this, the partner company must purchase the required number of WU tokens. The required number of WU tokens for purchase is determined by the formula: where: W Ucount = LT count LT price/w Uprice, (1) WUCount the number of WU tokens to be purchased, LTcount the number of loyalty tokens to be produced, LTprice the price of 1 point (token) of loyalty, WUprice the price of 1 WU token. Let s say users need to create loyalty points for this program. Hence, the company must issue of its LT tokens. 1 point costs $0.5, 1 WU token costs $0.05. Then the company should buy * $0.5 / $0.05 = WU. Methods to link the program clients to the internal platform accounts. The contract records information that identifies the client, but is protected by cryptography (a hash of a phone number or ). When the user confirms ownership of this phone or , his account is linked to the account of the loyalty program. 11

12 3.5.2 Transfer of an existing loyalty program to the WU platform The transfer of the existing loyalty program to the WU platform is different from the creation of a new loyalty program only because the company that manages the loyalty program must transfer the program database to the platform and perform the pre-issue of loyalty tokens to all those who already had loyalty points of this program. Figures 10 and 11 show the processes of transferring loyalty programs without security and with security, respectively. Transition steps: Create a token contract for the loyalty program. Include data about the clients of the program in the platform. Link them to accounts within the platform. Provide the required number of tokens for initial emission (optional). For this, users need: Determine the cost of 1 point of the program in WU tokens and purchase the required number of WU tokens. Load WU tokens on the loyalty token contract. Issue loyalty programs for all customers that have points, new program tokens indicating the validity period of all points (or mark them as unlimited). The following modules participate in the transfer of the loyalty program to the WULET platform: External stock exchange. The partner company buys WU tokens, which will provide the value of their loyalty tokens. Management Contract. A contract, which creates a new contract for Loyalty Token loyalty program. The partner will issue and manage the loyalty tokens in its loyalty program through this contract. Loyalty Token Contract. Loyalty Token Contract this contract stores the balance of user tokens, implements the movement of tokens between program participants and emits new ones/burns used tokens. Figure 10: Transfer of an existing loyalty program without collateral. 12

13 Figure 11: Transfer of an existing loyalty program with collateral. 3.6 Integration with external loyalty programs WULET Platform may provide key platform functions for external loyalty programs. External loyalty programs that are implemented on the basis of centralized solutions and / or can not be directly integrated with the WULET platform are considered external. Providing and issuing points of such loyalty programs is not transparent to the user. If the technical requirements are met, the points of the external loyalty system can be converted at the exchange and used to pay for purchases External loyalty program description The external loyalty program of the partner company generally consists of a database, a program interface (API) for managing points, users, etc. and an interface for users and program administrators (mobile / web applications). A gateway is used to connect the loyalty program of the partner company to the WU platform without its full transfer to the platform. The gateway will be an intermediate link between the loyalty program API and the WU platform Requirements To connect to the platform, an external loyalty program is to meet certain requirements. It is to: Provide information on the balance and lifetime of the points. Allow users to transfer their points to other users of the program. This is necessary so that users can exchange their points for the points of another loyalty program. Take loyalty points as payment for services, burning these points Integration methods A smart External Loyalty contract is at the core of the platform, which has the interface of the Loyalty Token contract. This contract is needed to unify the interaction of users with loyalty programs, so as clients of this contract see no difference between interacting with the internal or external loyalty programs. In this case, the implementation of External Loyalty is different from Loyalty Token. The contract of the external loyalty program interacts with the external API of the program through a special gateway. Since loyalty programs may not have a public API, or it can vary greatly from program to program, the gateway must be implemented in accordance with the API to enable it to perform all the requested queries. There may be several options for transferring data to a contract from an external loyalty program: 13

14 A loyalty system may not have a public API (or none at all). But it should certainly have a database. Users can conduct regular uploads of the database with the current state of users, their points, etc. in the gateway. The gateway will take the difference between the current state and the state at the last unload and load the new values into the External Loyalty contract. If it is possible to download the transaction history, users can upload it to the gateway. The gateway will process the history, receive new values and upload them to the External Loyalty contract. If the loyalty system provides a sufficient API (balance information, token transfer function and purchases for tokens), users can sign the gateway to update the points, users, etc. a subscription method if the API provides it, or by polling the server. Performing any operation with loyalty points of an external program connected through the gateway is done through the External Loyalty contract. External Loyalty contract either performs requests to the API of the program through the gateway, or interacts with the internal exchange, if it is exchange requests for points. Interaction of modules when requesting the balance of the user s points is shown in Figure 12. Figure 12: Interaction of modules when requesting the balance of the user s points from External Loyalty Contract. The process is as follows: The API of the external loyalty program periodically downloads the balances updates to the External Loyalty contract through the gateway in one of the ways described above. The client application requests a balance from External Loyalty contract. External Loyalty contract returns the current user balance downloaded by the external API through the gateway. Let us further consider the interaction of modules when exchanging loyalty points, Figure

15 Figure 13: Interaction of modules when converting external loyalty programs points on an exchange. To exchange loyalty points, the client application interacts directly with the Exchange contract, and the client already performs the actual exchange through External Loyalty contracts of loyalty programs, whose points are converted. Process: 1. The user wants to perform two operations on the exchange - the sale of tokens A, and then the purchase of tokens B. He selected the desired offer on the exchange and sent an exchange request. The client application generated the transaction and sent it to the exchange contract. 2. Exchange contract for converting points is to perform two operations - transfer A tokens to one user, and send WU tokens to another user. First, the exchange makes a direct call to the contract External Loyalty Contract A. 3. External Loyalty Contract A publishes an event about the exchange s request for the transfer of loyalty points. 4. The gateway monitors the contract events and, as soon as it finds a newly published event, sends a request for the transfer of points to the external API of the loyalty program. 5. The API performs a transaction and sends a response to the gateway. 6. The gateway receives a response, generates a confirmation transaction that the transfer of the points has been completed successfully, and sends it to External Loyalty Contract A. 7. External Loyalty Contract A updates the internal state of user points balances and performs a direct call to the contract of the exchange with confirmation of the successful points transfer. 8. The exchange contract makes a direct call to the WU token contract to transfer its tokens to another user and to withdraw the exchange commission. After that, the exchange marks the transaction as successfully completed. 9. To buy on-exchange tokens B for WU, the user sends a new request, and the exchange performs the similar operations described above. 15

16 3.6.4 Integration To proceed the integration, users are to complete the following steps: 1. Develop a gateway to interact with the loyalty program API. 2. Create an External Loyalty smart contract that will interact with the loyalty program API through the gateway. 3. Connect the client application to the platform so that it applies to the smart contract. 3.7 Linking an external user account with a platform account Two types of loyalty programs are possible from the prospective of linking users: existing programs and new ones. For new loyalty programs, user binding is not required, because there is only an account on the platform. For existing programs, a special procedure is required to link the old account (not the blockchain account) to the account on the platform. Binding can be done by and / or by phone number. At the same time, since in the blockchain information is stored openly and distributed, it is necessary to avoid sending open private data External loyalty programs The procedure for linking an external user account with a platform account can be presented in the form of a diagram below: Figure 14: Binding external user account with platform one by phone number. The figure identifies two areas of interaction: private area private area where information is protected by classical algorithms (TLS, for example), and public area where information is open. It is critical that the open information does not appear in the public area. In some cases, for example, with a telephone number, the presentation of information in a hashed form is not enough due to a limited set of possible phone number values. In other words, users can calculate hashes of all phone numbers and compare each with what is stored on the block. This procedure can be performed in a reasonable time (hours, days) and it is enough to do this once for all users. 16

17 The binding algorithm is as follows: 1. The user sends his phone number to the integration module (outside the blockchain) using a secure API. 2. The integration module calls the user verification procedure in the external loyalty program and transmits the phone number. 3. A personal unique code is created on the external loyalty program side (the length of the code must be sufficient to enumerate and calculate all codes and numbers for an unreasonable time hundreds of years). Then this code is sent to the phone number specified by the user. The code should either be calculated based on user data, or stored in the loyalty program database for further use. The value of the hash function calculated from the phone number and the code is the identifier connecting the external user account to the internal one. 4. If the user owns the number, he will receive a message and enter the code into the application. Then the application will calculate the same hash value of the function and publish it in the blockchain, signing it with its own key. 5. The integration module will have to use a hash to get balance and other operations with the token to identify the user in the external system Internal loyalty programs For the case when the existing loyalty program is transferred to the platform, personal codes are created when the data is transferred to the blockchain. The codes are stored in the integration module (outside the blockchain). Hashes are installed within the blockchain. As users connect to the platform, they go through the validation procedure, which allows them to link the user s account with the external account (transferred to the platform) of a loyalty program. As a result, the technical transfer of the existing loyalty program data can be implemented in the way that private user data will not be included in the blockchain in an open form. Moreover, only the partner and the user will have an access to it, until the latter agrees to this data usage. 3.8 Exchange The WULET exchange is intended for buying and selling loyalty program points transferred to the platform (or created on it) for WU tokens, or loyalty points of external loyalty programs connected through the gateway. The exchange provides a set of mechanisms standard for exchange software [16], but specific for loyalty tokens: the purchase and sale of loyalty tokens on the market, the issuance of limit orders Commission The platform takes a commission of 1% of the transaction amount at the time it is made in the WU tokens. The commission is charged both with the person who placed the offer on the market, and with the one who accepted the offer. The offered tokens are blocked at the time of their offer placement together with the commission, which will be withdrawn from the user as a result of the transaction. That is, the user will not be able to use them until the offer is withdrawn as a result of the transaction, or withdrawal of the offer by the user, or as a result of its expiration Cancellation of an offer A user who posted a token exchange offer can cancel it until the pair is found and the transaction is launched. Blocked proposal tokens are thawed immediately after the proposal is withdrawn Tokens with a limited lifetime The user can place a proposal for the sale of tokens with a limited lifetime. The lifetime of each token in the offer should be the same. The tokens which will burn in less than, for example, an hour (the parameter is configured by the platform administrator) cannot be placed for an offer. 17

18 In case a proposal for the tokens with a limited lifetime has been placed, it will be automatically canceled if the tokens have less than a specified period of time left (for example, one hour). The same mechanism is used when the user who placed the offer manually remove it the placed tokens will be unlocked Interaction with the exchange The interaction logic is presented in Figure 15. Suppose user 1 needs to exchange A for B, and there are two corresponding offers on the market: A WU (from user 2) and WU B (from user 3). 1. User 1 executes the first offer by selling its A-tokens: (a) The client application sends a transaction about the sale of tokens A to the exchange contract, then the exchange executes two direct calls: i. For transferring tokens from user 1 account to user 2 account on the token A contract. ii. For transferring tokens from user 2 account to user 1 account and from user accounts 1 and 2 to the exchange account as a commission on the WU contract. 2. User 1 fulfills the second offer by purchasing B tokens from the user 3 account: (a) Through the client application, user 1 sends a transaction to the exchange contract to purchase tokens B. The exchange executes two direct calls: i. For transferring tokens from user 3 account to user 1 account on the token B contract. ii. For transferring tokens from user 1 account to user accounts and 3 and the account of the exchange as a commission on the WU contract. Figure 15: Interaction of modules when converting tokens of internal loyalty programs. 18

19 3.9 Receiving tokens and loyalty tokens payment Receiving loyalty tokens for purchases Members of loyalty programs of partner companies can receive cashback loyalty points for purchases in retail and online stores. Integration To implement the issuance of tokens for purchases, users are to: Obtain permission to issue bonus loyalty points. Develop software for the payment terminal (POS or Mobile / Web Application). The terminal should be able to: Receive account names from users Send a request for the calculation of loyalty points to POS / Web Integration, which contains the account name of the user and the number of points to be burnt. Interaction of modules when charging tokens for purchase Figure 16: Interaction of modules when charging tokens for purchase. The interaction is as follows: POS or Mobile / Web Application receives a payment from the user account name in one of the ways: The POS terminal scans the QR / bar code from the loyalty card. The code contains account name. The POS terminal scans the QR / bar code generated by the Client Application. Client Application in this case can be used instead of a physical loyalty card. An NFC smartphone transmits an account name to the POS terminal. Mobile / Web Application receives account name from the user device via HTTP. POS or Mobile / Web Application initiates the transfer of points to the user, sending a request to POS / Web Integration containing his account name and the number of points for accrual. 19

20 POS / Web Integration signs and sends a transaction to Loyalty Token Contract for scoring to the user. Loyalty Token contract issues loyalty tokens to the user, changing the status of the contract Purchase for loyalty tokens Partners may accept payment for purchases in loyalty tokens or in WU tokens. It can be either a company managing a loyalty program, or another company that has permission to accept payments in loyalty tokens. Integration To implement the acceptance of payment it is necessary to: Develop software for the payment terminal (POS or Mobile / Web Application). The terminal should be able to: Receive names or a signed debit transaction from user accounts. Send a payment request from the account name of the user and the number of points to be burnt to POS / Web Integration, or send a signed user write-off transaction to Loyalty Token Contract. Receive payment confirmation from POS / Web Integration. Interaction of modules when purchasing for loyalty tokens Figure 17: Interaction of modules when purchasing for loyalty tokens. The interaction is as follows: POS or Mobile / Web Application receives a payment from the user account name in one of the ways: The POS terminal scans the QR / bar code from the loyalty card. The code contains account name. The POS terminal scans the QR / bar code generated by the Client Application. Client Application can be used instead of a physical loyalty card in this case. 20

21 An NFC smartphone transmits an account name to the POS terminal. Mobile / Web Application receives account name from the user device via HTTP. POS or Mobile / Web Application initiates a token payment request by sending a request to POS / Web Integration, containing the account name and the number of points to be burnt. POS / Web Integration signs and sends a transaction to Loyalty Token Contract to publish a payment request for tokens. Loyalty Token Contract publishes a payment request for the purchase in loyalty tokens Client Integration scans the events of the loyalty token contract, catches the event that it published, and sends a request for purchase payment in tokens to the user s smartphone in the form of an SMS or PUSH-notification. The user confirms the request by signing and sending a token transaction to Loyalty Token Contract. Loyalty Token Contract burns the user s tokens and publishes the event. POS / Web Integration catches the contract event and sends a payment confirmation to the POS-terminal or the online store server (Mobile / Web Application). Figure 18 shows another way to implement a purchase for loyalty points using a POS terminal. Figure 18: Loyalty points purchase with NFC transaction signature. The user device signs a token transaction and sends it via NFC to the POS terminal. The POS terminal sends a token transaction to Loyalty Token Contract. Loyalty Token Contract burns the user s tokens and publishes the event. POS / Web Integration catches the contract event and sends a payment confirmation to the POS-terminal or the online store server (Mobile / Web Application). 21

22 4 Reliability Achieving a high level of reliability requires the application of complex measures from the correct architecture to the system safe maintenance. The implementation of the project on the basis of the blockchain brings its pluses and minuses the decentralized solution is more reliable, because there is no single point of failure, but at the same time the blockchain introduces other risks that we will consider them below. 4.1 Blockchain failure The key risk are so-called network forks. They can occur for various reasons: Software errors in the client. Physical separation of the network (so-called split brain). Political / social network separation (so-called 51% attack). From the prospective of a blockchain solution, the fork problem could be simply solved only one branch is selected, the others lose their relevance. Those actions that were committed in the other forks never existed in the history of the accepted fork in fact. However, blockchain forks may lead to catastrophic errors, such as double expenses, cancellation of charges, etc for centralized (external) solutions. To prevent such situations, the integration modules responsible for integration with payment terminals and E-commerce necessarily interact with the nodes of the network included in the platform. In the case of forks, these nodes will lead only one fork, which will give the consistency for the period of instability. In case that this fork is not selected as the main one, it will be possible to correctly transfer data between forks. If the network instability threatens the platform s operation, the nodes can be put into block creation mode, thereby creating a private blockchain. Thus, the platform will use its own network nodes, ready to switch to the regime of private blockchain in a critical situation, so as to work continuously and have the data to be fully consistent with centralized services. 4.2 Analytics, statistics and backup The blockchain database does not involve changes, and any data change at a low level leads to the addition of new ones, and the installation of a reference on them. Thus, it turns out that the blockchain is accumulating the entire history of changes of all the data stored in it. The specificity of the blockchain data storage does not always allow them to be used for analytics, since the data indexation is limited by the number of fields. In addition, there is not always a convenient way to analyze its history. In addition, when moving from the classical method of data storage (in the RDB) to blockchain, partners may have a lack of confidence in technology. Relational databases are best suited for analytics right now. Therefore, RDB with the current section of the data selected from the blockchain will be included in the personal account of the partner. Data will be organized in such a way that it can be used most effectively for analytics. In addition to actual data, the RDB will also accumulate for analysts its history. A regular backup by the classical scheme dumping data into the file system on the server from different data centers, will be created on the base of the actual data. In addition, each partner can download the backup of their loyalty program in the same format. As a result, data storage in the RDB will fulfill the needs of analysts and will increase the reliability of the platform in a traditional way for enterprise solutions. 5 Performance and scalability For a blockchain, performance is the number of transactions per unit of time. But transactions do not always have a direct connection with the number of basic computing operations. For example, in EOS, transaction are limited not by operations, but by the execution time. This time depends on the average performance of 1 node. Thus, the scalability of the network with the growth of 22