Initial Feedback on the Kin Rewards Engine

Four weeks ago, we released the first version of Kin Rewards Engine (KRE) request for comments (RFC) document, which was the result of several months of work. We received a lot of interesting feedback, and some of the inputs we received and our thoughts are below.

Before we dive in, we want to let you know that we plan to communicate earlier and more often. This means we’ll try our best to share progress, even if half-baked, for the sake of getting feedback from the community.

Incentivizing Growth

The incentives are the whole point of the KRE, so the most important question to ask about the KRE is whether or not it creates the right incentives. With the right incentives, we will bring in popular services to the Kin ecosystem, making it more varied, valuable, and sustainable.

It’s clear how the proposed KRE could bring already successful apps into the ecosystem. If your app is used by a lot of people who want to buy or sell digital goods, introducing Kin would create a significant revenue stream while providing your users with a great payments platform. So clearly you should do it.

What if your startup doesn’t have many users but will grow to become the next big thing? Kin should be considered by such entrepreneurs. A dual strategy of pursuing early stage VC funding with the promise of KRE monetization down the road is a better plan than monetization around ads IMHO.

How would we incentivize these startups? The trivial approach would be to allocate the KRE rewards according to the service’s growth rather than its current size. We saw two problems with this solution:

1. A service developer can manipulate their KPIs to show higher growth. For example, by “zig-zagging” its users between allegedly-different “apps.” Such a practice can be indistinguishable from honest behavior (why shouldn’t different builds of the app be counted as different apps?).
2. If the entirety of the rewards allocation is given to growing services, mature services that show little or no growth have no incentive to stay in the ecosystem (they might even be subsidizing their growing competitors!).

The latter problem can be mitigated by allocating only a portion of the rewards to growth-stage services, whereas the lion’s part of it should remain in the proposed KRE model. The former problem seems a little harder to solve, and we still don’t have a good model to measure growth that is not susceptible to manipulation. Suggestions would be most welcome here.

An interesting solution, suggested by our friend Christian Catalini from the Cryptoeconomics Lab at MIT, would be to rely on existing institutions to vet the eligibility of startups for growth-based incentives. Reliance on institutions, though it will leave a lot of power to the Kin Foundation (but the process cannot be completely decentralized), mitigates the risk of fraud in this case. For example, VCs could be given the right to submit their startups for the “growth rewards.” We’ll be looking further into this, with the goal of proposing a detailed model to how this should work.

Improvements to the Protocol

Fair choice of favorite app

Several people commented that the process of implicitly assigning a user’s vote by their “favorite app of the day” (as proposed in KRE v1.0) is unfair, as it creates a bias towards high-spend apps and might even open the door to fraud. The suggested alternatives are either to split the vote between the apps by transaction volume, or to split it equally between the apps that user transacted in that day. I personally like the latter approach, although we still need to determine if there’s a way to cheating by splitting their transactions to multiple accounts, multiplying the amount of votes they receive.

Introduce fees to avoid inflation

Currently, the KRE is planned to use funds allocated to it through the Kin Foundation’s monetary reserve. This creates an increase in the supply of money in circulation, which — separate from a correlated increase in demand — would cause a slight devaluation of Kin (around 0.06% per day).

This devaluation can be offset if the rewards sum is not introduced into circulation but rather taken from current circulation by applying fees on transactions. Even though consumers regard them as negative, fees are beneficial for markets as they create friction that prevents small problems from spiraling out of control. Moreover, the Kin Foundation has the ability to use either option, so it can use a mixture of fees and reserves to fund the KRE , effectively stabilizing the economy if it tends to be too inflationary or deflationary.

I maintain that it would be good if the Kin Foundation can use such means to stabilize the economy. However, any such intervention will create profit for some and loss for others. It’s critical that such means are not used before there is a transparent and fair process to determine when to intervene. It’s also crucial that the Kin Foundation be totally impartial and independent from other stakeholders in order to gain the trust of the community.

Allocate rewards to incentivize users

Several people have raised the subject of giving rewards directly to users, either as a type of universal basic income (UBI) or as a reward to “capitalists.” Of course, money doesn’t grow on trees ( not even cryptocurrencies!). Incentivizing users would mean collecting money from Kin users, (either in proportion to stake, through inflation, or in proportion to transaction volumes via fees) and redistributing it back to the users. Distributing UBI is the exact opposite of rewarding “capitalists” — the former reduces inequality and the latter increases it.

Since the mandate of the Rewards Engine is to incentivize the growth of the ecosystem, we see little value in either type of redistribution, as neither seems to be correlated to a growth-related behavior. Implementing UBI would also require a good method to identify users’ real identities and to mitigate Sybil attacks, which would actually create a barrier to adoption by many digital services that don’t identify their users.

Thanks to everybody that took the time and effort to provide feedback. Your inputs have been very helpful. If we missed any important insight, please let us know by commenting here, in GitHub or in our Telegram channel.