Improving the KRE’s resilience to large parked accounts (exploit fix)
KRE 3 has continued to show promising results in stimulating a growing Kin economy. Of note, we have seen Active Users and Active User Balances continue to increase in the apps over time.
Active Users means that users remain engaged in apps and interact with Kin. Active User Balance means that Kin is being encouraged to flow from the external world into Kin’s Economy. Over time, we would like to see more apps joining the economy and creating a bigger demand and pull for Kin.
As the economy grows, we also want to make sure that we maintain a good playing field for apps, giving them as much room to innovate and iterate as possible. We also intentionally make minor changes to the KRE to ensure it does what it is intended to do – Encourage a growing and rewarding economy for apps and users.
To this end, we propose a minor update to the current KRE (detailed below) that protects the KRE from a vulnerability of parked accounts with large balances that appear to be outliers. This is a minimal change and will not require any changes from apps. However, it will strengthen the KRE and make it less susceptible to these parked accounts.
We look forward to community discussions pertaining to this proposal on Reddit or GitHub and expect the update to take effect shortly after it is approved by the Kin Foundation (following developer feedback on GitHub) on July 24th.
The purpose of this document is to outline a proposed improvement to the existing KRE algorithm.
The Kin Foundation
This proposal introduces and addresses the vulnerability of parked accounts. A parked account is a large account with a disproportionately large balance that could be used to game the AUB metric. This can be controlled using standard deviations as described below.
KRE 3.0.2 is a minor update that addresses a vulnerability of the KRE to parked addresses that inflate an app’s Active User Balance.
The Active User Balance (AUB) metric is a simplified incentive mechanism that takes into account all of the mechanisms in previous iterations of the KRE. While previous iterations explicitly rewarded holding, buy tracks, peer to peer transactions, transaction volumes and transaction counts, AUB encompases all these metrics.
An app that has a high AUB naturally has users transacting in its ecosystem (Active Users), and users with higher balances tend to spend more inside the app as the same amount of currency competes for the same amount of goods. Apps are incentivized to keep as many of their users as possible transacting in Kin to maintain a high Active User (AU) count.
Apps are also encouraged to experiment with different incentive methods within their app and the cap placed on the AUB (100,000 * AU) is intentionally unconstrained for this purpose.
In short, the AUB metric encourages Kin to flow into apps while also requiring that users remain active and transacting with Kin. We propose a method to address a vulnerability described below.
Consider an app X with 1,000 Active users. This app can have up to 100,000,000 Kin (AUB ) counted by the KRE for its KRE reward.
Suppose the app has addresses with about 10 Kin each:
It’s total AUB from usage would be 10 * 1,000 = 10,000 Kin
However, a vulnerability exists where the app could create an address it controls, and deposit a large volume of Kin to increase its AUB.
Its total AUB in this case would jump by orders of magnitude, due to the single parked address.
While the incentive metric encourages deposits in addition to active users, it is also important that account balances reflect the typical usage of Kin in the app.
It is possible to mathematically define typical usage in a simple way that ensures apps are not penalized and only outlier parked addresses are filtered out by the KRE. To define typical usage, we must appreciate that some apps may naturally have large balances and others have smaller ones.
These balances also change with time as apps evolve and gain more use cases. Some ways of defining typical usage are described below:
- Cap the maximum balance that can be counted per account to 1MM Kin:
As described above, different apps have different balances and use-cases for Kin, so this method would be too constrained.
- Cap the maximum balance that can be counted to an average of the app’s current Active Users:
This is slightly less constrained but given that apps can have a large range in balances, this would also affect non parked addresses.
Since parked addresses are extreme outliers of an app’s distribution of balances, the KRE can use a simple standard deviation to protect itself from outlier parked accounts.
This method allows apps to have a healthy distribution of balances without adding constraints and only parked addresses on the extreme outside of normal distribution would be affected. The method is formalized below.
KRE Logic Update
Where payout for app i is defined as follows: ref
Payout_i = (AUB_i / AUB_total) * KRE_total
let AUB_i = 0
for each account of app_i
AUB_i = AUB_i + IF(account >= 15stdev_avg THEN avg ELSE account)
Where for a payment period:
account = the balance of an active user
avg = average balance of active users
15stdev_avg = 15 standard deviations from an app’s AU balance distribution
If an account is found to be an outlier 15 standard deviations away from the norm, the average is applied to its balance instead.
This method only affects extreme outliers of a distribution of wallets. For any wallet to be affected, it would have to have a z-score of 15, making it more than 15 standard deviations from the average, which is extremely rare. Parking an account of a lower standard deviation does not make much of a difference in the ecosystem.
From a list of 375,062 active user accounts in the considered period (June), only 8 accounts from 4 apps are affected ~ 0.000021%.
While simple, this update helps protect the KRE from parked accounts.
We propose this is included in the KRE as soon as it is approved by the Kin Foundation so it can be part of KRE 3 by July 30 2021
Kin is uniting apps and services of all sizes & varieties, putting the power back in the hands of businesses, developers, and users with a focus on creating compelling digital experiences and fueling the exchange of real value for the ultimate win-win scenario and a more transparent, trustworthy economy built around a decentralized shared digital currency. If you are interested in building your app with Kin, we invite you to join us and help build a fairer digital world together.