OST Alpha III developers challenge — Final Submission

Hello everyone! My name is Aleksei and I’m from Russia. This is the final blog post for PoC OST Alpha III developers challenge on OST.com.

I integrated OST Kit functions into program management company loyalty (QPAXX Solution). In doing so, I used the API and the framework 1C: Enterprise in desktop version.

For example four types of users

As an example of real life, he took into account the rewards of service engineers in the course of work on the elimination of malfunctions in the network of Gas Stations. What are the goals helps to achieve this application? With the help of such integration it becomes possible transparent accounting of bonuses and a closed cycle of Brand Token (BT) Economy.

There are four types of participants in the loyalty program and four UI.

The company — issues tokens, registers employees, issues tokens at the Gas stations with the help of Airdrop, for rewarding technicians. (type = Company)
Company Dashboard
Available functions
Gas Stations — in the event of a malfunction, technicians are attracted to repair it, and after completion of work perform the accrual of reward. To do this, a directory has been created “Faults”, in which each type of fault is set a bet reward. (type = User)
Gas station Dashboard — can add malfunction and set reward
When work is complete, execute reward
Servicemans — performing work, get tokens, which they can then spend with others participants in the loyalty program (cafes, gyms, etc.) (type = User)
Avaliable functions for serviceman UI
Other participants of the loyalty program — cafes, gyms, rental services. All those who is the Company’s partners. Get Brand Tokens from the technicians. Can exchange them for USD or services of the Company, transferring them to the Company. (type = User)

Thus, there are three types of interaction:

Company_User,
User_User,
User_Company.

To generate 1000 transactions, I had to write a simulator that simulates occurrence of malfunctions, charge of reward, BT payment in a cafe and other services, as well as transfer of BT from these services to the Company account.

Simulation for execute 1000 transaction
Log
Same log in OST View

Below answers to questions according to conditions Poc developers challenge.

How did you plan the design for your wallet features?

When planning the design of the wallet, I took into account the minimum required functions: balance, transaction history. For the convenience of users, eliminated unnecessary parameters. For example, when rewarding a Gas Station for technicians, you do not need to calculate a BT reward. It is enough to specify the type of malfunction (which is stored in its own database) and select the recipient. When translating tokens from other members of the loyalty program, it is also sufficient to specify only the number of BTs, and so on. The transaction is of type User-Company, then the address of the final recipient is substituted automatically. Well, the main functions of the wallet — check balance, execute transaction and see the transaction history. Of course, a lot of improvements are required in the interface part, it’s PoC, then I created a simplified version.

What APIs did you use: Ledger, Balance, Actions, Token Details, etc.?

When developing, I did not use all API functions. Below are the ones that found application:

Create User; Update User; List Users; Execute Airdrop
Retrieve Airdrop; List Airdrops; Create Action
List Actions; Get Balance; Ledger

What information did you show to the end user and why?

For each type of user, I determined the necessary information, depending on the role. So the Company needs access to all information (Users, Brand Token settings, Actions, Gas Stations). The company needs to see the full picture of the interaction in the OST Brand Token Economy. For other participants of the loyalty program, data and functions are available to a lesser extent.

How did you use design (UX/UI) for how to display this information?

Actually, when using framework 1C: Enterprise, the design is reduced to determining the fields required for each type of interface. The rest of the framework does it automatically. Of course for the final product, you need to make a mobile application, and there already have to optimize the design for small screens.

What did you like about using these APIs?

Using the API did not cause any special difficulties. Of course I would like to add some features inherent in smartcontracts. But overall the impression is positive. The main thing is that the documentation is exhaustive and technical support responds quickly and provides the necessary assistance.

What did you learn about designing these wallet features

First of all, I got an invaluable experience in the blockchain industry and implemented the OST Kit function in my application, in effect, I created a kernel on which other projects can be based. And using these developments, the next project can be created much faster, better and better.

Thanks to OST Alpha III developers challenge, I discovered new horizons and there were already ideas for new applications with the use of blockchain.

Also came the understanding in which companies OST BT can be used. This is a company,who want to conduct calculations on a daily basis with each other, and at the same time to see the picture of mutual settlements online, and at the time of fixing the debit or credit balance to pay bank payment, based on the balance of the tokens. Those. With the help of OST Brand Token it is possible to maintain enlarged mutual settlements, but at the same time the operational discreteness is achieved mutual settlements.

Summing up, of course realized not everything that was originally intended (for example, a mobile client), but stillI can say that it was fascinating and easy. I hope that the OST Kit will continue to develop in this direction. I wish Ost.com team success.