AppCoins News Update, or ANU for short, is a regular bi-weekly update by the AppCoins team. As usual, we are going to cover dev updates, market reports, team members and upcoming events. This week’s focus is on the Ritchie Release, the development of the BDS Billing System and the new credit card feature to facilitate in-app purchases with AppCoins, and the coverage of team’s presence at the Gamescom.

Quicklinks

Dev Update

APPC Markets Report

Featured Team Member

Gamescom

Another Dev Update is upon us!

We’ll update you on the developments for the Ritchie release that will occur next Sunday.

This release was all about the BDS Billing System and supporting credit card payments in the AppCoins Wallet when users are purchasing in-app items. The latter had the additional constraint of having to maintain one of the key assumptions of the AppCoins Protocol: total verifiability by developers and regarding their transactions.

We decided to build on top of the ASF billing system, which relied solely on Blockchain tech, and develop the BDS Billing System. It already comprises the server-side management of items and purchases but still stores all relevant data in the Blockchain. This extended billing system implements the same interfaces developers already know when they integrate and use Google Play billing system. Hence, migrating from it to ours is as simple as changing a few variables. In addition, instead of relying on the Google Play app, it relies on our AppCoins Wallet to communicate with our API.

Paying with credit card for in-app items using the AppCoins Wallet

At the same time, we’ve been building support in the AppCoins Wallet to purchase in-app items using credit cards. Users can just use their credit cards and pay for in-app items as they are used to. This automatically solves the biggest adoption friction we’ve encountered so far and opens the AppCoins Protocol to a large portion of users. However, by itself, this solution breaks the assumption that developers should be able to validate the interactions between users and their apps without the need to trust any third party because these transactions are done off-chain, i.e. outside the Blockchain.

In order to solve this issue, we started consolidating these off-chain transactions in the Blockchain and have them verifiable by developers. Periodically, for each developer’s wallet, we gather all the transactions and compute a Merkle Tree. Merkle Trees are a nice and affordable way of representing large portions of data and providing a proof that someone holds that data. Once a Merkle Tree is computed for a given developer’s wallet, its root hash is sent to the Blockchain coupled with the developer’s wallet. If the developer wants to validate the transactions they have in his wallet, the developer can either ask our API for all the transactions and compute the Merkle Tree himself. In addition, he can store the transactions himself and use them to compute the Merkle Tree. Then, he can validate that the root hash sent by our system to the Blockchain is correctly computed.

We are able to maintain the verifiability assumption with off-chain transactions, which was a hard constraint while building the support for credit card payments.