By Paulo Trezentos CEO AppCoins
One of the areas in which AppCoins innovates is the way developers can use advertising to acquire users.
The AppCoins model changed the industry standard: 1) the developer pays only if the user pays 2 minutes of attention, 2) the user receives 85% of the developer’s investment and 3) everything is registered in the blockchain and is auditable by both the developer and the user.
As defined in the original AppCoins paper, the rewards received by the user have to be spent in In-App Purchases and cannot be cashed out, to incentivize a circular economy.
Besides the AppCoins rewards, other interesting use cases can be devised where the user should not be able to cash out. For instance, giving a bonus for every transaction that can be used in future purchases.
The high level requirements of the AppCoins Rewards were:
- REQUIREMENT 1 — To build trust between the end user and the app developer, with the guarantee that the Credits given exist and the right to them is registered in a persistent and immutable way.
- REQUIREMENT 2 — The end user would not need to have ETH to receive the Credits.
- REQUIREMENT 3 — The Credits can be used to buy digital items inside apps and games but cannot be cash out in an Exchange (Binance, etc…).
Over the last 3 months, the AppCoins Team explored 3 technical approaches to implement these requirements:
- New token (Class B)
- State / payment channel
- Escrowed contract
The creation of a new token (Class B) that would be exchanged with regular APPC through a smart contract would require several operations on-chain, requiring the end user to have ETH to support the earning and spending operations. A state/payment channel could be modified to not allow the cash out but would require ETH as well for the opening of the channel, for top-ups and for closing the channel.
As the first two approaches would always require the user to have some ETH, the team searched for more options. Based in the Trust framework, we can isolate what is the strictly needed on-chain activity for the above requirements:
- On-chain Activity / Currency ownership -> Escrow: as the user doesn’t necessarily trusts the developer or a third party representing the developer, an escrow is important to ensure that the AppCoins that back the credit exist.
- On-chain Activity / proof-of-balance -> time-delayed / digest: the user needs to be able to check the balance of AppCoins Credits after receiving a reward. If the balance changes, the third party has to prove the transaction that led to the change of state.
To help the developers execute the on-chain activity, third-party platforms (aggregators, distributors, app stores) provide dedicated services. Those third parties (blockchainds.com, for example) interact with the escrow smart contract, and they are certified by the App Store Foundation to add an extra level of security.
As depitect in the above diagram, a reward in AppCoins Credits would happen in 3 steps:
Step A - happens when the developer creates the user acquisition campaign through a third-party integrator and specifies the amount of the reward. When the user successfuly pays 2 minutes of attention to the developers app, the step B and step C are executed.
Step B - the part of the user (8.5 APPC) is escrowed in a smart contract and the corresponding amount of AppCoins Credits is added to his wallet balance and is registered in the blockchain (proof-of-balance).
Step C - the user receives the APPC-C (AppCoins Credits) in his wallet.
In conclusion, AppCoins Credits are fast, reliable (always backed by real APPC) and trustworthy (transactions and balances are registered in the blockchain), powering new interactions between developers and users for rewards and bonus.
Originally published at medium.com on December 17, 2018.