Simplifying the KRE4 while maintaining its effectiveness

[skyf0xx]

The KRE 4.0 proposal rewards apps for having:

1. Higher AU
2. Higher AUB
3. Higher Balances in wallets
4. Higher spends

When these factors are put together, they result in an equation that works but also introduces complexity in the game. Let us see if we can simplify this with Net Economic Activity:

Net Economic Activity

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, nothing has really happened and it's just two accounts sending Kin between each other. Dishonest apps in the past have used this as a gaming avenue.

One way to close this gaming vector is by looking at the balances in Alice and Bob's wallets at the end of the day. If, at the end of the day, all they did was juggle Kin between them and the balances remain the same, nothing really happened. If they still each have 5 Kin, their Net Economic Activity is effectively 0.

However, for an app that has genuine economic activity, the balances of each wallet change on a daily basis, just like in real life. An app with high Net Economic Activity is one where genuine transactions have happened during the day.

In addition, Net Economic Activity has hidden interesting properties we examine below.

Hidden Properties of Net Economic Activity

Net Economic Activity is the median of absolute differences of balances in an app in a day. Let us simplify this formal statement with an example:

In the table below, Net Economic Activity of a hypothetical app totals to 15.

To calculate the NEA for an app, we:

1. Get the differences in the balances of each wallet for the last 24 hours. (Absolute difference)
2. Get their median

E.g.

The median of 15, 9, 15, 30, 399 is: 9, 15, **15**, 30, 399. In other words, the NEA for this sample app = 15. The median user is spending 15 KIN on a daily basis.

How to Win as an app
In order for an app to win, they will need to maximize their Net Economic Activity (NEA). To do this, they need to:

1. Give Alice & Bob very high balances (solves for Median Balance & AUB)
2. With high balances, get them to spend as much as possible (solves for Median Spends)
3. With high spends, get them to spend as often as possible (solves for economic activity)

Reasoning

1. An app with low balances can only get users to spend tiny amounts. E.g. 5 Kin.
2. An app with high balances can get users to spend millions of Kin each day
3. To have a daily high NEA, the app needs to get each user to spend as much as possible on a daily basis

This allows us to encourage a vibrant economy in apps, while keeping things simple. The KRE equation now becomes:

Where the numerator (top) is the NEA of the app multiplied by its AU. The denominator is the sum of other apps' NEA & AU. This equation is simple, includes all of our factors and is difficult to game. Additionally, apps will compete by trying to keep balances and spends as high as possible, without needing constraints that force a minimum spend amount.

Fewer constraints allow the economy to dynamically adjust itself with the price of Kin.

But why not be explicit and add more terms to the equation? (AU, AUB, MB, MS)

It is tempting to be explicit with everything we want to control. However, it is easer and way more efficient to be implicit, using latent variables.

These are variables that are hidden in the simple equation. For example, an app with a high median balance and high AU naturally has a high AUB. Therefore, we wouldn't need to include all of AU, AUB, and Median Balances in one KRE equation. We would simply need AU and Median Balances, while AUB would be implicit

By using Net Economic Activity, we have managed to include all of the factors that KRE 4 wishes to attain, while keeping the equation deceptively simple. Any developer looking at NEA will instinctively know they need high balances, spends and as much activity as possible.

The True GDP of an App

Net Economic Activity shows us how much the median users are spending and earning in an app. Multiplied by the Active Users, this gives us an approximation of the true GDP (economic activity) - after filtering out gaming vectors.

In a nutshell, what we have done here is:

1. Create a strong definition of economic activity including all the hidden variables we want (NEA)
2. Multiply it with Active Users to get the true GDP of the app
3. Reward the app in proportion to how much it contributes to the overall GDP

[skyf0xx]

One gameable avenue (also present in other proposals) is:

1. An app only has two users.
2. One user transfers 1B Kin to the other user

This gives them an artificially high NEA. It also gives them an artificially high AUB. This can be solved by capping the NEA of each app with a multiple of its Active Users. This is the same way that AUB is capped to prevent gaming

[hann228]

Thanks for this Will, very interesting read.

A few questions for you:

Regarding an AUB Cap - would you suggest in that case to maintain $10 worth of Kin per Active User (as proposed in the KF's KRE 4). This is a dynamic cap which decreases (in units of Kin) as the price increases. In Jan 2022 what we saw as the price of Kin increased, the apps with the highest AUB had large moats around them because no smaller apps could compete with the USD dollar value of their user economies to catch up (their AUB cap was also increasing in $ terms) The idea being for this $10 cap was that as the Kin price increases the AUB cap is decreasing meaning that in-app metrics will help get the edge over close competitors as the cap narrows. What are your thoughts on this?

How do you see this proposal fitting with the quality factor which was proposed? Would you maintain this in your proposal?

[skyf0xx]

A good point - This proposal stands on its own and would work with or without additional constraints like:

1. $10 cap
2. Quality Factor

However, this system does not use AUB directly - AUB is a hidden variable. There would be no need for a cap. Even if a large app had 10B Kin in its wallet, the only thing that would count is the Net Economic Activity. So if the median users in the 10B app only traded, 3 Kin daily, that is all that would be counted.

So I guess the NEA is safe from apps parking a large amount of Kin

[skyf0xx]

@hann228 please see here for Quality Factor: #171

The factor stands on its own and would work with any system. However, my humble suggestion is for the explicit reason for each rule to be considered. It's possible the goal of the Quality Factor can be achieved with fewer rules.