Every way to stop giveaway bots costs you real entries too

The first time a giveaway gets farmed it is obvious: the entry count climbs faster than your viewer count, the names look generated, and the winner is an account created this week with no messages. What is less obvious is that every tool for preventing this works by making entry harder, and honest viewers are far more sensitive to friction than a script is.

So the useful question is not "how do I stop all of them". It is "how much friction is this prize worth", and the answer for a Steam key is different from the answer for a graphics card.

What people actually try

Chat-command giveaways lean on account age and follow requirements: you must have followed for a week, or your account must be older than a month. This works reasonably against casual farming and not at all against someone with a stock of aged accounts, which is a thing that exists precisely because these checks are common. It also silently excludes the viewer who discovered you twenty minutes ago, who is the person you most wanted to convert.

Requiring a sign-in is the strongest ordinary defence, because it moves the cost of a fake entry from "run a script" to "create and verify a real account somewhere". It is also the most expensive in entries. Our own estimate when building this was that requiring sign-in cuts entries to roughly 60–70% of a name-only giveaway, and the product says so on the setting rather than pretending it is free.

Device-level deduplication catches the lazy version — the same phone entering four times with different names — without asking anyone to log in. It is trivially defeated by someone who cares, and it costs almost nothing in genuine entries, which makes it a good default rather than a real defence.

The thing nobody mentions: the prize is the incentive

Farming is economic. Nobody writes a script for a $12 game key, and everybody considers it for a GPU. If your giveaway is being attacked, the prize is worth attacking — which means the cheapest available fix is often to run more small giveaways rather than one large one. That is not a satisfying answer if the big prize is the point, but it is worth naming before you start layering checks that annoy your regulars. It also tends to be better for the stream: four draws across a month give your audience four reasons to show up, where one draw gives them one, and the small ones are the ones nobody bothers to attack.

How to tell farming from a good night

Before adding friction, check that you have a problem. A giveaway that suddenly gets four hundred entries is not necessarily farmed — a raid, a clip doing numbers, or simply putting the code on screen for longer than usual will all do that. The signals worth looking at are the shape rather than the size: entries arriving at a perfectly even rate, names following a visible pattern, a spike that continues after you took the code off screen, or a burst that starts within seconds of the giveaway opening rather than ramping.

The reason to check first is that the fix is not free. Turning on sign-in because of one unusual night costs you entries on every subsequent giveaway, including the ones nobody was ever going to farm.

What verification actually buys you

With sign-in on, entry is tied to an identity rather than a typed name, so the same person cannot enter twice however many browser tabs they open. That is the whole benefit and it is a real one: it makes the entry list mean something, which matters most when you have to defend the result afterwards.

It does not make the draw provably fair — that is a separate mechanism — and it does not stop someone determined enough to sign in twice with two real accounts. It changes the cost, not the possibility. Anyone selling you certainty here is overselling.

Chat commands have a specific weakness here

It is worth being precise about why chat-based entry is easy to farm, because it is not that chat is insecure. It is that the entry action is a plain text message, which is the single most automated interface on the internet — every platform has mature libraries for sending them, and a giveaway command is indistinguishable from any other message. Nothing about the entry itself proves a person was involved.

Entry by scanning a code is not magically safe either — the endpoint behind it can be posted to just as easily — but it does move the fight to a place where ordinary defences like rate limiting, device fingerprinting and a challenge actually apply, because there is a request you control rather than a chat message someone else’s platform delivers.

The claim step does quiet work here

A detail that gets missed: requiring the winner to actively claim within a couple of minutes filters farmed entries after the fact. A script can enter a hundred times; it is much less likely to be watching when the draw lands, and if nobody taps the draw rerolls automatically. That does not prevent the flood, but it substantially reduces the chance a farmed entry actually collects the prize, which is the outcome you cared about.

It is also the only one of these that costs your genuine viewers nothing, because a real entrant who is watching taps a button on the phone already in their hand. That is the property worth optimising for generally: defences that are invisible to the people you want and expensive for the people you do not. Account age requirements are the opposite — invisible to a prepared farmer and immediately visible to a new viewer.