This is to start a discussion based on the limited information provided in the white paper on user rewards for subscribing to channels, as gathered here.
User […] can become subscriber to one or more channel and start receiving token incentives.
And further discussed in the white paper here, and a medium post - link posted in a following comment as I can only place 2 links in a post.
Disclaimer: The documentation is very light on this functionality so much of this is based on assumptions.
Problem: Farmers will create many accounts and subscribe to channels with the sole purpose of farming incentives from channel subscriptions, thus “stealing” funds from legitimate user base.
Proposal: Require $push staking within the app in order to enable subscription rewards.
This is a type of Proof of Stake mechanism to require skin in the game for users in order to reap rewards. The benefit here would be 2-fold since $push token holders would also earn rewards from the fee pool as per the medium post linked above.
The idea is that a channel’s rewards would only be distributed to users who stake a predetermined amount of push in their account to verify eligibility. This could be done in several ways, which is why I wish to start a discussion! Some of my ideas are as follows (strictly for the examples and simplicity we will assume 100 push predtermined stake):
- A parabolic reward curve, benefiting users who stake more. 0% to users who do not provide eligibility, then a %gradient to those who provide some of the predetermined amount all the way to 100% for those who provide the full predetermined amount. Something along the lines of $reward = ($staked/10)^2 to generate a parabolic rewards.
In one scenario, staking 10% would net 1% of rewards available to said user - 10 $push is 10% … 10% / 10 = 1 ^2 = 1%.
In a second scenario, staking 50% would net 25% of rewards available - 50 $push is 50% … 50% / 10 = 5 ^2 = 25%.
Finally third scenario, staking 100% would net 100% of rewards - 100 $push is 100% … 100% / 10 = 10 ^2 = 100%
- A linear reward curve where % of $reward simply = % of predetermined max stake. No examples needed here, if you stake 10% of predetermined $push, you would receive 10% of rewards available to said user.
Pros & Cons
The benefits of 1 would be that anyone attempting to farm the system would basically need to stake the full amount to take full advantage of each farm they create.
The cons of 1 would be that it could create a hurdle to the average user who may not have enough $push token or funds to purchase said $push token in order to gain rewards.
The benefits of 2 would be that most users could likely find the means to acquire some $push, and thus begin earning rewards. They could then use rewards to further acquire push and stake more until they reach the full stake and maximize rewards earned. Also in this scenario it would likely be more beneficial to have 1 farm with 100% of maxed rewards as opposed to 10 farms with 10% of rewards maxed, so you would cut down on the number of farming accounts.
The cons here would be that a farmer could create a new farm without the full 100% stake and begin earning rewards. In scenario 1 it generally would not be worth a farmers time to put in less than a very high %.
While this solution will likely not prevent farming altogether, it should be possible to limit the farming based on the amount of funds a farmer is willing to lock away into his farm. Further, it will require said farmers to be invested in the protocol themselves, and thus not wish to harm the network or token lest their own investment lose value.
I believe the final determination of the amounts required to be staked would depend on what reward payouts would look like. It would not be necessary, for example, to require 100 $push be staked if the general payout was 0.01 $push per month. The lack of documentation and experience here would make determining the actual value extremely difficult if not simply impossible at this time. At the same time, the amount shouldnt be low enough that a farmer could take rewards from existing farms and use those to create new farms at a high degree or fast pace. Scenario 1 would also help here since farmers would only really be gaining from farms which are “fully stocked”.
One could also use a twitter style verification system wherein a user verifies a telephone number to confirm their account. This has a few flaws, however.
- It could be construed by some as a type of KYC, which is generally frowned upon
- It can be bypassed by purchasing disposable sim cards and/or virtual sims available online. If a farmer is going to invest funds, why not make them invest in $push itself to generate their farms
- This would place a greater burden on the EPNS team to invest infrastructure and funds to indefinitely maintain this functionality, as we as possibly placing the team in front of legal hurdles based on various countries they maintain this functionality within.
I’m sure i’ve missed stuff, and perhaps not explained things thoroughly but thats what a discussion is about! Looking forward to hearing your thoughts.