TL;DR: We presented a PoC (proof-of-concept) during Web Summit to highlight the possibilities of the AppCoins protocol. The user would be able to perform an in-app purchase using APPC. The smart contract was deployed in the main network, making AppCoins the first app store related crypto project performing a transaction in the main network.

Introduction

AppCoins is an open and distributed protocol for mobile app stores(GitHub). It will drastically improve and speed up advertising, in-app billing and app approvals, using blockchain and smart contracts technology. In this article, we are not going to focus on adversing nor app approval, the focus will be on in-app purchases.

What we did

As a PoC, we developed a sample app (GitHub) based on the Aptoide App Store (GitHub), which allows the users to purchase in-app items using AppCoins. The sample app uses the AppCoins lib, which can be found here.

The sample app would call a smart contract running on the Ethereum’s main net, which implements the token and the revenue share model proposed in the white paper.

We are focusing this article on the smart contract. If you want to know more about the app part, please read this article.

Smart Contract

The smart contract had some requirements it needed to meet:

Create APPC dummy token

Provide functionality to transfer tokens

Split token transfers according to our proposed revenue share model for the IAB use case

The token was a dummy one in the sense that it didn’t need to be ERC20 compliant and didn’t need to be secure, since it was only going to be used by our PoC and wasn’t going to be listed anywhere else.

The revenue share model for the IAB use case states that for every itembought in an app, its developer is entitled to 85% of it, the app store to 10% and the OEM to 5%. The transfer function in the smart contract implements this logic, splitting the amount being transferred and sending each portion to the corresponding wallet.

The smart contract used can be seen here. The method we introduced to perform a split was:

Then it was used inside the transfer method:

Deployment

During development and deployment, we relied on the development framework Truffle. It makes it easy to develop smart contracts and deploythem. It relies on a configuration file where the networks are defined (either local, test and main networks) and then the contracts are compiled and send to one of the configured networks. The reader can see from the linked configuration file that all the hosts point to localhost. That is because we had clients with both the Kovan test network and the main network already synced.

For testing purposes, we did 2-step tests using a local network with TestRPC, and then the Kovan test network. Only when the smart contract had the required behaviour in both (first in the local network and then in Kovan), we deployed to the main network.

As an example, to deploy to Kovan, we would use the command:

truffle migrate --network kovan

However, Truffle has a problem with the gas price when deploying to the main net, which makes transactions very costly in terms of gas. To solve that, we changed the gas and gasPrice default configurations to meet our needs.

Next Steps

Again, this was a very simple PoC that served primarily for historical purposes. It’s probable that the protocol won’t rely on any of the code used for it.

The technology we would like to get a grasp on next is µRaiden and integrate in an experiment close to the PoC because Raiden, although it’s obviously different to µRaiden, can be an important component of the AppCoins protocol. We project that the protocol will have to support a significant amount of micro-transactions coming from mobile advertising and IAB, which means that pure on-chain solutions aren’t suitable for it.