Add rate limit rules to Contest platform

[ianrowan]

Description

A contest attack vector has been brought up by @timolegros and I a few times regarding the ability for users to drain our relayer wallet via gas fees from spam content. Given this concern there should be platform rate limiting rules that(imo) are determined by product and add guardrails to how contests are used by users.

My suggestion in terms of rules here that could be implemented at the platform business logic layer would be the following:

1. Allow x number of content per user per contest
2. Require user to hold x stake

These would create both rules for how common contests are conducted and also limit the attack vector from a spam and sybil perspective. I think this is urgent to figure out although its been swept under the rug upon other mentions

[ianrowan]

@jnaviask @ForestMars

[timolegros]

@rbennettcw @kurtisassad @egetekiner

[timolegros]

Proposed values:

• Maximum 2 posts per contest per user.
• Minimum 1 stake owned to participate in contests.

[sachben91]

would just limiting posts prevent this issue? I would prefer not to have the stake restriction since I expect the most used contests to be the directly funded one that does not use stake + we have a ticket in the pipeline for decoupling contests and stake @timolegros @ianrowan

[ianrowan]

@sachben91 The idea with limiting to stake is that users do still always need stake to vote even for directly funded contests so in this case would we expect people posting content to not be doing this as well(ie giving themselves the free self upvote). Otherwise its definitely possible to limit posts just suggesting the stake component as it creates a light paywall to limit attack via sybil

[timolegros]

If we only limit posts, as @ianrowan said we are still open to an attack vector where a user creates a script to:

1. Create a new user
2. Join the community
3. Create 2 threads in a contest

Without the stake requirement you could just run the above script thousands of times and drain our wallet.

[sachben91]

how would the stake restriction work in the case of Farcaster contests (when thats implemented) ?

[timolegros]

we have a ticket in the pipeline for decoupling contests and stake

The stake requirement could be updated to "whatever token is used in the contest".

[timolegros]

how would the stake restriction work in the case of Farcaster contests (when thats implemented) ?

I'm not sure - do Farcaster contests use stake or native tokens? Either way we need to be able to verify the amount of tokens a user has or simply not sponsor transactions. @ianrowan probably has a better answer.

[sachben91]

The risk from the product side is that it costs lets say around $20-30 USDC to spin up a contest, which means that no one is going to casually try out contests - this reduces our top of the funnel intake. On top of that if we paywall participation in contests for users, then that really limits the number of people who will participate in a contest and the corresponding prize money would have to go up exponentially to make it worthwhile for someone, not to mention the UX hassle.

Is it possible to have a restriction that is something like - every participant in the contest must have >0 eth or whatever token the admin is funding the contests with. Is it possible to verify that?

[timolegros]

Is it possible to have a restriction that is something like - every participant in the contest must have >0 eth or whatever token the admin is funding the contests with. Is it possible to verify that?

This may be a good alternative though I would say it should be more than a certain dollar amount of Eth/token. Just greater than 0 may be too low given that someone can multi-send a bunch of Eth dust to a ton of addresses. @ianrowan do you think > 0 is sufficient?

If we do this we would need to make very sure that the user is fully aware that they need a certain amount of Eth/tokens to participate...

[ianrowan]

Yes we can definitely use ETH balances as the gate along with the post limit. But it is still less sybil resistant as tim said for 2 reasons - 1 making users buy stake funds contests and us which means any illicit actors are still lifting the community and us 2 it is pretty easy to fund wallets with dust as tim said vs other more complex methods. I would personally suggest a value that is relatively non-dust and reflects a real user. Something like > 0.0005($1.55).

And again to echo tim there should be affordances for the user to understand they need this amount of eth.

Farcaster contests will be handled differently as I assume we'll use erc20 for voting power. I want to emphasize this ticket is for immediate deployment of contests on the app. That said to respond to the UX concerns of users needing stake, most users(voters) will need stake in general so I'm not sure it adds much of an explicit gate

[sachben91]

I would personally suggest a value that is relatively non-dust and reflects a real user. Something like > 0.0005($1.55)

I think the restriction that a user should have a non dust value of eth should be the way forward if y'all agree on that. I'll post this message to @dillchen to confirm as well. Will work with @jessmart1213 on the design affordances for this. Thanks for bringing this up

.

[sachben91]

are we good to go ahead on the above solution @ianrowan @timolegros , which would be:

• rate limit users to two posts per contest
• user should have non dust value of eth or whichever token is used by the admin to fund the contest

[ianrowan]

@sachben91 Yes that sounds good to me, but would say we should only use ETH for sybil check. And on that note, is .0005 a valid number to use?

If all sounds good there will leave it to @ForestMars @jnaviask @Rotorsoft on how to ticket/dispatch this to the platform. For the eth check my suggestion is to simply use existing TBC/groups functions so there should not be any new protocol/chain interactions

CC @timolegros for his opinion here too

[timolegros]

@sachben91 Yes that sounds good to me, but would say we should only use ETH for sybil check. And on that note, is .0005 a valid number to use?

If all sounds good there will leave it to @ForestMars @jnaviask @Rotorsoft on how to ticket/dispatch this to the platform. For the eth check my suggestion is to simply use existing TBC/groups functions so there should not be any new protocol/chain interactions

CC @timolegros for his opinion here too

I second the ETH check. Would be a simple and performant implementation. Users would need ETH to transact with the native token anyway. Tagging @rbennettcw since he may be the best choice to implement this given his work with contests.

[timolegros]

Also important, the UI affordances should not only inform the user of the contest limits but also the contest creator when selecting topics. For example, an admin creating a contest could include the general topic in the topic and therefore hugely reduce the amount of content users can post in the topic.

Alternatively and maybe preferably we still allow users to post threads in a topic with an active contest but simply exclude that thread/upvote from the contest (don't put it on-chain). This would require additional UI changes such as a tag indicating that a thread is not included in a contest.

[rbennettcw]

@sachben91 what's the final decision on this?

Before implementing, it needs to be clear which rule(s) will be applied and what that looks like for the end-user.

[sachben91]

• rate limit users to two post submissions per contest
• user should have non dust value of eth (eth>0.0005) to submit a post to a contest

For the end user, we'll do an error toast if a user tries to submit a third post to a contest (agnostic of the topic that it is on - meaning if there are two topics #1 and #2 with contests active and the first two posts are in topic #1 and the third attempt is in topic #2, the user should not be able to create the third post)

If a user attempts to submit an entry to a contest, we will check if the user has non dust value of eth in their wallet.

• If they dont have non dust value of eth, we will show a message that says "you must have at least 0..0005 eth to participate in the contest"
• If the user does not have non dust value of eth and has only a magic link login, we will show a message that says "connect wallet to participate in contest" , and step one repeats if the non dust value in the wallet that the user connects is less than 0.0005.

The second step means that users will need non magic link wallets (metamask and others) to participate in contest.

will work with jess on ux affordances. Probably will need till monday to get them to you

@rbennettcw @jessmart1213 @ianrowan @timolegros @jnaviask