Examination of Recent KRE Improvement Proposals

Personal ruminations of a Kin enthusiast

Kin’s KRE Developers summit concluded in October, after which intense community discussion followed, with several suggestions submitted to github. Great ideas have been flowing from the community and developers on how to best improve Kin’s incentive mechanism.

We follow a process below to help us evaluate proposals that work best for the ecosystem.

Begin with the end in mind

To begin with the end in mind means to start with a clear understanding of your destination. You need to know where you are now so that the steps you take are in the right direction.

Credit: The noun project

To help evaluate proposals, it is important we have a clear picture of the intended outcome in mind. In other words, we first need to answer the following questions:

1. What is the ultimate purpose of the KRE?
2. What are the ecosystem needs, and in what order of importance?
3. What attack vectors must be avoided or at least minimized?

1. Purpose of the KRE

“I imagine millions of people sitting down with their phones each morning, providing value to the world and getting compensated. The value they provide would come in many forms, such as offering advice, hosting experiences or creating content” — Ted Livingston

The most used cryptocurrency in the world.

To unpack this, we need to understand Kin’s economy. Kin’s economy is comprised of Speculators, Developers and Users. For Kin to work in the long term, it needs flow from exchanges, (becoming scarce to speculators) and move into the user economy (becoming more available to users).

This creates an economy where, from the perspective of app users, Kin becomes more available and prices of goods naturally increases inside apps. This internal inflation encourages spending over holding.

On the side of speculators, Kin becomes increasingly scarce, leading to an increase in value and eventual stability relative to the dollar. The KRE rewards developers to facilitate this flow, by creating a vibrant economy for users to spend on.

This intended flow of Kin has been detailed in: Cryptocurrencies and Exchange Rate Volatility. Which references further reading by the Bank of Canada.

In summary, the KRE needs to reward developers to:

1. Encourage a vibrant economy
2. Encourage the flow of Kin into the app ecosystem (Net demand for Kin)

2. Ecosystem — Hierarchy of needs

The Scalability Trilemma, a term coined by Vitalik Buterin, refers to the tradeoffs that projects must make when deciding how to optimize blockchains. In layman’s terms, it’s akin to the phrase:

“You can’t have everything”.

credit: Michael Zochowski

Choosing some aspects to optimize means invariably sacrificing others. Similarly, to create a KRE equation, we first need to list properties the equation will affect, in order of their importance. These are listed below, the first one being the most important:

1. Attractive to developers: The rewards need to be alluring enough to pull developers into the ecosystem. Developers are a key part, and are analogous to miners. This needs to be balanced with other priorities.
2. Discourage low quality spends: The spends in the economy need to be meaningful to users in order to make Kin meaningful and desirable. Low quality spends affect user experience and perception of Kin.
3. Difficult to game: The KRE needs to minimize its attack vectors. Tracking and dealing with malicious apps is not scalable and, with a growing permissionless ecosystem, could become impossible in the future. To reduce the necessity of tracking, the equation should close as many attack vectors as possible.
4. Easy to play: Developers need to easily understand their place in the game, so they can project earnings and compete fairly. Developer feedback has frequently requested simpler reward formats.
5. Allow for tourism: Users need to be able to move Kin from app to app. (This was listed last because tourism numbers have been low, even with incentives encouraging migration. Even with the option available, users have seldom chosen to migrate). Still, open gardens are preferable to closed ones.

Note: Others may list these priorities in different order. However, it is important to be clear what that order is — in order to build an incentive mechanism.

In summary, the KRE needs to fulfill a clearly defined hierarchy of needs.

3. Attack Vectors

Every reward system is open to manipulation. Proof of work blockchains try to minimize the risk of 51% attacks, and proof of stake systems are susceptible to hacks. Private keys to staking pools in particular need to be strongly protected.

Similarly, the Kin Rewards Engine is susceptible to gaming by malicious apps. Since the current KRE rewards apps that have the highest numbers of transactions, unaligned apps try to cheat through the following avenues. Each avenue is aimed at increasing the apparent number of transactions an app has.

1. Ghost to Ghost accounts: An app creates hidden accounts (ghosts) in users’ phones, and sends Kin back and forth between other ghosts.
2. Round Robins: Similar to Ghost to Ghosts, an app sends the exact amount of Kin back and forth between two users. The wallet balance remains the same, but this is registered as a valid KRE transaction. To obfuscate this , the app can send the Kin to more than two users and still have the same effect. E.g. 100 KIN to Bob, then to Alice, then to David, then back to Bob.
3. Cheeky Boomerangs: An app sends e.g. 100 KIN to a user, and charges the user 100 KIN immediately for the next action they take. E.g. logging in. This makes it look like there is an economic exchange of value, while the net effect is zero.
4. Spurious Spends: An app loads its interface with hidden or meaningless spends, where the user may not be aware they are earning or spending Kin for certain actions.

Some of these vectors are expressly prohibited by the terms of agreement, while others are implicitly permitted but dilute the user experience.

The transaction problem: The problem with directly rewarding transactions is that apps, while competing, may dilute the user experience or worse, cheat — for short term gains. Since Kin can change hands thousands of times a day, it is easy for an attacker to hide their bad behavior.

Finding bad actors is an expensive and time consuming process. As the ecosystem grows, this becomes harder to track and to deal with. One option is for the Kin SDK to collect additional pseudonymized data such as IP addresses and device IMEIs — However, this adds to its complexity and also has privacy implications.

A more desirable option is to make the KRE equation difficult to game by design.

Evaluating proposals

Now that we have clearly defined purpose, need hierarchies and attack vectors, we can logically test two proposals from github, and hopefully iterate to a better outcome.

Credit: The noun project

The goal is to directionally improve over time. Every iteration needs time in the market before further improvements can be made.

Proposal 1: kre_3.md

This proposal rewards apps for having a high GDP (transaction volume) and high purchases through buy modules. Apps that hold more Kin are awarded more.

The intended net effect is that Kin moves from exchanges and settles mostly in app developer wallets.

Evaluation:

Purpose

1. Encourage a vibrant economy: Apps are rewarded for having more transactions ★★★★☆
2. Encourage the flow of Kin into the app ecosystem: Kin moves from exchanges and concentrates in developer wallets ★★☆☆☆

Hierarchy of needs

1. Attractive to developers: This is similar to the current KRE (transactions and buys) — but it adds a staking component. ★★★★☆
2. Discourage low quality spends: Hard to differentiate between low and high quality spends. ✖
3. Difficult to game: This is open to the gaming methods described. ✖
4. Easy to play: Much simpler than previous KRE iterations. ★★★★☆
5. Allow for tourism: A tourist transaction is counted as a spend. ★★★★☆

Vulnerability:

1. Ghost to Ghost accounts: Vulnerable ✖
2. Round Robins: Vulnerable ✖
3. Cheeky Boomerangs: Vulnerable ✖
4. Spurious Spends: Vulnerable ✖

Verdict:

This proposal is an improvement to previous KRE versions, but does not satisfy some higher level hierarchies, and is vulnerable to all the attack vectors.

Exercise:

How would you evaluate the current KRE and buy module? Is it vulnerable to boomerangs? Where would Kin end up flowing to? Does most Kin end up with developers, users or exchanges? Do developers use the hold track? What are its advantages?

KRE 2.2

Proposal 2: kik_kre_3.md

This proposal rewards apps based on the total kin stored in monthly active wallets. A developer’s AUWB is capped at 100,000 times the number of MA, meaning the max reward per wallet is capped at the same amount.

The intended net effect is that Kin moves from exchanges and settles mostly in app user wallets.

Evaluation:

Purpose

1. Encourage a vibrant economy: Apps are rewarded for monthly active wallets, but not explicitly for transactions ★★★☆☆
2. Encourage the flow of Kin into the app ecosystem: Kin moves from exchanges and concentrates in user wallets ★★★★★

Hierarchy of needs

1. Attractive to developers: This is a departure from previous formats, but developer feedback has been positive. ★★★★☆
2. Discourage low quality spends: Developers have nothing to gain from spam transactions. ★★★★★
3. Difficult to game: This closes many attack vectors. ★★★★☆
4. Easy to play: This is the simplest iteration so far. ★★★★★
5. Allow for tourism: Apps have more incentive to keep Kin inside their ecosystem. ✖

Vulnerability:

1. Ghost to Ghost accounts: Safer ★★★☆☆
2. Round Robins: Safer ★★★☆☆
3. Cheeky Boomerangs: Safer ★★★★☆
4. Spurious Spends: Safe ★★★★★

Verdict:

This proposal satisfies all the higher level hierarchies and is harder to game. It is also easier to find apps gaming the system, by comparing their monthly active wallets to total downloads in the app stores. Importantly, it also drives Kin from exchanges into app user wallets.

Note: The equation does not explicitly have a buy track, but implicitly encourages buying. The only way to sustainably fund active wallets is by buying Kin from the market. For example, funding 10K new wallets requires 1 billion KIN to get fully rewarded for each wallet. Large apps create many new wallets per minute, and can only fund them sustainably by getting users to buy Kin.

However, there are two apparent disadvantages:

1. Tourism is discouraged
2. Transactions are not explicitly encouraged. (It is enough to have only 1 transaction per month for a wallet)

“You can’t have everything” — But can we improve this somehow? Is there a way to explicitly encourage economic activity, without encouraging spurious spends?

Net Economic Activity

Trivially rewarding apps for GDP (volume of transactions) has led to gaming challenges. However, if we tighten our definition of GDP from simply transaction volume, to the net economic activity in a given time period, we get better clarity.

Kin Transactions

Consider two users: Bob and Alice who each have 5 KIN in their wallets. If they juggle this Kin between them 100 times in a day, the total GDP for that day is 500 KIN. However, if at the end of the day, they still have 5 KIN in each wallet, the Net Economic Activity is effectively 0. In other words, nothing happened.

However, for an app that has genuine economic activity, the balances of each wallet change on a daily basis, just like in real life.

App X wallet balances

Formally defined as the sum of absolute differences of balances in an app in a day, the Net Economic Activity of the app above totals to 4.

This allows us to encourage a vibrant economy in apps, while still avoiding round robins, cheeky boomerangs and spurious spends, without dramatically increasing the effect of ghost to ghost accounts. (Tracking the ratio of Active User Wallets to total downloads an app has would limit the effect of ghost accounts.)

The new payout equation becomes:

Apps that have the most amount of Kin in their economy (stake), and the most economic activity (vibrancy) receive the highest rewards.

Apps can also place a cap on the max amount of Kin a user can withdraw per day (tourism), and get rewarded for those transactions.

To maximize rewards, apps will need to implement buy modules, maximize wallet balances, increase transactions and allow tourism.

Does this really work?

At first glance, the incentive seems to encourage actions that benefit the ecosystem the most. However:

A closer look reveals that over time, apps would start to optimize for larger and larger transactions. Adding other factors as checks to prevent this outcome (such as normalizing the NEA with the wallet’s largest transaction) lead to similar outcomes.

Complexity is proportional to a system’s attack surface

Simpler solutions are usually easier to forecast, safer, and can be tweaked marginally over time.

Conclusion

We have covered the challenges and opportunities that must be considered when designing incentive mechanisms for Kin. Hopefully this sheds light on the process behind incentive design. Some work well for new economies, but as the dynamics of the environment change the mechanism needs to evolve as well.

The goal is to iterate the KRE to fulfilling Kin’s vision of being the most used cryptocurrency in the world. Each iteration solves previous challenges, while opening up opportunities to further refine itself.