How we verify

The problem this method exists to solve

Game codes expire without announcement. A code posted on Monday can be dead by Wednesday, and nothing tells the reader which one they are looking at. The usual response across code sites is to copy a list from another code site, add the current month to the title, and let the reader find out by typing.

That practice has a specific failure mode: the codes propagate faster than the corrections. One site publishes an unconfirmed code, five aggregators repeat it within a day, and every copy cites a different one of the others. The result looks corroborated and is not. Nobody in the chain redeemed anything.

Freetins exists to break that chain in one place: we say what was checked, how it was checked, and when. Where we have not checked something, the page says so rather than implying otherwise.

What counts as a source

A source is a channel the publisher controls. That means the studio or game account posting on its own website, YouTube channel, Discord server, Twitch stream, or X account. If the publisher announced the code, there is a post, and that post is the citation.

Two things are explicitly not sources. Other code sites are not sources, however many of them agree, because agreement between aggregators is usually just one unverified post being reprinted. And a game listing is not a source either: a Roblox game page proves the game exists, not that a code was ever issued, so we link it to open the game and never cite it as evidence for a code.

Where we found a code and what proves it are different questions. Both are recorded. Only the second is shown to you as evidence.

The four evidence states

Every code, reward link and cheat on the site carries exactly one state. The state is calculated from the verification record, never typed by hand, so a page cannot claim a freshness it has not earned.

Verification and sourcing are separate questions

A code has two independent properties, and collapsing them is how other sites end up overstating what they know.

The state above answers "did the last check pass". The tier answers "do we know the publisher ever issued this". A code an editor redeemed successfully is verified whatever its paper trail, because redemption is direct evidence. A code repeated by fifty blogs with no publisher post is community-reported, because repetition is not evidence.

Both are shown. A row that says community-reported is telling you the code may well work, and that nobody at Freetins can point to the publisher issuing it.

Reader reports, and why they are not verification

Code rows carry a thumbs up and a thumbs down so you can say whether a code worked for you. These are reader reports. They are counted, they are shown, and they never change a code published state.

That separation is deliberate. If enough thumbs could turn a code green, the site would be publishing unverified consensus as fact, which is the practice this whole method exists to avoid. What the reports actually do is drive the re-check queue: a code collecting failure reports is moved to the front of the list for an editor to check properly, and it is the editor check that changes the label.

Reports are de-duplicated per network address, which stops the same person clicking repeatedly. It is not fraud resistance and we do not present it as such: carrier networks put thousands of genuine readers behind a single address, so real reports get absorbed, and anyone switching networks can report more than once. Treat the numbers as a rough signal of how a code is behaving in the wild, not as a count of distinct people.

No IP address is stored. The de-duplication key is a one-way hash of the address combined with a server-side secret and a daily-rotating value, and it expires by itself. There is no way to recover an address from what is kept, and no way to follow one reader between codes beyond the rotation window.

When is a code usable

A code is usable when its most recent check passed and that check is still inside the game freshness window. In practice that means one of two states: verified or source-reported.

Stale, expired and unverified entries are all excluded. This is why a game page can list twelve codes and report zero usable ones: the codes exist as records, and none of them currently passes.

We would rather show you a page that says nothing works today than a list of twelve dead strings ordered by how recently someone reposted them.

When does a game have an active record

A game has an active record when at least one of its entries is usable by the rule above. That number, not the number of codes on file, is what the site reports as active and what decides whether a game is promoted anywhere on the site.

A game with an active record of zero stays published, because the page is still the correct answer to the question "does anything work right now" — but it is not featured, not listed in the most-searched row, and its page leads with the fact that nothing currently passes.

• Active record = at least one entry in the verified or source-reported state.
• The count is recalculated from the verification log on every build, never stored.
• A game with zero active entries is never promoted, only reachable.
• A game with no published entries at all does not get a route.

Freshness windows

Each game carries its own window, because code lifetimes differ by title. A game that ships codes on a weekly stream cadence does not need the same window as one that drops them during a live event.

When a check ages past its window, the entry becomes stale automatically. Nothing has to be edited for that to happen, which is the point: an unmaintained page degrades honestly instead of silently continuing to look fresh.

What we remove and what we keep

A code that fails a re-check is marked expired and kept on the game page as a retired record, collapsed below the working codes. It is kept because the alternative is worse: if dead codes simply disappear, a reader who finds one elsewhere has no way to learn that it was checked and rejected.

Expired codes do not get their own page. A list of dead strings is a maintenance record, not something anyone searches for, and giving each one a URL puts thin near-duplicate pages in front of crawlers for no reader benefit.

Entries are deleted outright in one case only: when there is no acceptable evidence for them at all. Three Basketball Zero codes were removed on 24 August 2026 for exactly this reason — their only citation was a throwaway preview host, which is not a publisher.

The constraints, and how the method handles them

This method is more expensive than copying a list, and pretending otherwise would be dishonest. These are the real limits and what we do about each.

Can this be automated

Partly, and it matters which parts. Automation is useful for detection and for decay. It cannot manufacture the evidence itself.

Corrections

If a code on this site does not work, that is a defect and we want to know. Corrections go to [email protected] with the page URL and, if you have it, what happened when you tried to redeem it.

Section owners are accountable for their own surfaces: Guides, Answers and Cheats each have a named editor, and anything else routes to the site editor. A correction that changes a published state is recorded as a verification event like any other check, so the page history stays consistent with the page.