Protection against channel reward farming

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):

  1. 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%

  1. 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
Scenario 1
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.

Scenario 2
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 %.

Final thoughts
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”.

Counter Argument
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.

  1. It could be construed by some as a type of KYC, which is generally frowned upon
  2. 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
  3. 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.

1 Like

3rd Link for post

I do agree with your points and in general reward mechanism is a bit tricky and I think we have to change it

  • Channels have to deposit a high amount of DAI to get a reasonable amount of rewards from interest(~5% APR) and rewards will be very less if there are many users who opted for that channel
  • Farmers can write a bot to find the newly created channel to get more rewards from weighted reward distribution and again genuine users will miss out
  • I don’t see channels depositing very high DAI just to create that small chunk of interest for reward. It’s not very efficient for the companies to lock their high amount of funds for this

My proposal is Can we use this mechanism to pay for gas fees while opting for notification?

In the documentation they stated a minimum of 50 $DAI. I imagine that some projects, like uniswap, would be willing to stake much more than that. I also imagine that there will be some kind of priority/spam protection where the higher the amount staked, the less likely a notification will be marked as spam. So defi projects with money on the line will stake a very high amount to ensure their messages get through. Again, this is assumptions I am making on how EPNS will handle it based on the extremely limited documentation they’ve released. If they’re not planning to do it that way, maybe they should hit me up for more on that idea as well, lol.

That said, the amounts earned may not be much per channel, especially because it will be fairly linear where the projects staking more will also have more consumers so the returns per user will be small either way. However, it all adds up. If you’re subscribed to 100 channels and each channel earns 0.01 dai per month, then you’re stillmaking 1 dai per month for simply using a protocol you’d use anyway.

On the second point, Farmers will write bots, and will get newly created channels. Even if human verifications were set up, the farmers would atleast get instant notifications of new channels to quickly go and add those channels. This cannot be prevented, but hopefully my idea would slow them down and make it less appealing to them as they could invest those funds in other places to earn more…hopefully.

On the 3rd point, that I covered above, I do think channels will deposit high amounts for those reasons.

Finally, I don’t fully comprehend your last question. What gas fees are you wanting interest income to pay for? There shouldnt be any gas fees involved for the average user.

50 DAI is nearly 50$ which is not very much right. There is no correlation with the amount staked to the spam score

Every operation we do on Ethereum we have to pay gas fees. So when a user opts for notifications he has to pay for gas fees. Gas fees can be very high sometimes. So it might not be a good experience to ask the user for the fee.
So we can solve this problem either by asking the user to just sign the transaction and have a meta transaction layer in between where EPNS will create the transaction envelope by paying the fees from the staked DAI. We can use for doing this. But the problem is can we get enough staked dai to pay for every user fee.
To reduce the gas fee we can migrate to L2 layers but compatibility with dapps that are not on L2 will be very tricky

The main problem I see is a high gas fee users have to pay while opting for notifications and the proposal is can we have a meta transaction in between to pay the user fees from the staked DAI

Yes, I know there is no current correlation with amount and spam score. I imagine, again my inference, that a correlation will come later; that is just a guess and definitely not fact. The fact is, the documentation is exteremely light, and I believe thats because really they just have an outline of what they see may be coming. It is highly probable things will change and the setup will likely be highly dynamic as they fight spam and hit roadblocks from scammers/spammers.

That said, I see what you mean about gas fees, and I think the income from channel subscriptions will never be nearly enough to cover gas fees in any determinate amount of time. Honestly, I do not even understand why gas fees are required in order to subscribe to channels. The ethereum global ledger should not need to store that information for simple notification to average users. Hopefully they amend this in the future to some type of snapshot/signature-only requirements.

I also believe that the most correct way to shield the ecosystem is to distribute the rewards of the dai wagered to users who block a convenient amount of “PUSH”, in this way the possession of PUSH is promoted which, together with an adoption of the EPNS protocol, will create demand for the push token, revaluing it and giving solidity to the entire ecosystem

Thanks for resurrecting this topic @Ozaru :slight_smile:

Things have changed a lot after this post, and we pivoted from the original idea that Stake was going to be put against Aave to generate interest and then split it among the subscribers of the channel. We pivoted from this idea in order to go gasless and multi-chain.

v2 of the protocol is currently in the works and we’ll be sharing more information about it shortly.

Since this topic is very outdated now, I will close it.