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.

Awaiting verification is a state, not a rejection

Every code, reward link, cheat and dataset row on the site is in one of the states below from the moment it is recorded. A new row lands as Listed · awaiting editor verification. It is rendered in full with its source, and on code pages with its Copy control and reader controls, and it is indexed like any other content. Nothing waits on an editor.

That is deliberate. It takes real work to get a page, and a system that hides or bounces that work until someone has had time to check it destroys value it did not create. Verification is the job of an editor and never a gate: no page is held out of the index, marked noindex or dropped from the sitemap for want of a check.

Existing content is protected the same way. Every row and every article that was on the site when this record began keeps the status it displayed on that day as its baseline. A row that displayed Active stays Active · as published, a row that was Expired stays Expired, and a row nobody had confirmed became Listed · awaiting editor verification with no change in visibility. Nothing was demoted, and from here only an editor can change any of it.

The three states and the as-published baseline

A row shows exactly one state. Three of them can be produced from today on: Verified, Listed and Expired. The fourth, Active · as published, is a baseline carried over from before this record existed and is never assigned to new content. None of them is typed by a writer, and no editor state changes on its own: a row leaves the live list only when an editor retires it or a reward link passes the expiry its publisher stated.

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 answers "has an editor tested this". The evidence line 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 stays 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.

How to read a row

• Status: one of the four labels above. On a dataset page it is the Status column; on a code or link page it is the label beside each entry.
• Last checked: the date of the newest recorded event on that row. On pages that predate this record it is the as-published baseline date the writer supplied, and it becomes an editor check only when an editor event replaces it. A row with no recorded date reads not yet, and that is the honest answer rather than a gap.
• Evidence: whether a publisher channel or community reporting backs the row, with the source linked where one exists. It sits beside the state and never replaces it.
• Expired archive: every retired or expired row stays on the page, collapsed below the live ones, so a code you find elsewhere can be identified as already dead.
• Counts: every number on a page, from the verified total to the size of the archive, is counted from the rows on that page at build. None is typed.

The public history

Every state on the site comes from a dated event: who did what, by which method, and when. A verification, a review and a retirement are each an event with a named editor, a method and a server timestamp. A row being recorded is an event too, attributed to whoever recorded it, and it never claims more than that.

The page shows the history rather than summarising it. A dataset page carries a change log built from its events, and the date beside a row belongs to the event that produced it: an editor check where one is recorded, otherwise the as-published baseline date the writer supplied, or not yet where there is neither. Pages that predate this record keep their published date line as their baseline until a real editor event replaces it.

No date on the site is relative. "Checked three hours ago" rendered at build time becomes a lie the moment the page is cached, so every date is an absolute date, and the absence of one is stated rather than filled in.

An editor's word supersedes everything within its dimension

Within the question it answers, a recorded act by a named editor outranks every other signal. On whether a code works, a star or a retirement beats a sighting, a heart count, a repeated list, a typed field and anything a script produced. The most recent editor event on a row decides its state, and nothing that is not an editor event can overrule it.

The rule stops at the edge of its dimension. A verification says nothing about whether a source is a publisher, and a source line says nothing about whether the code was tested. An editor who verifies a community-reported code produces a Verified row that is still community-reported, and both facts are shown.

The corollary is that no editor act is ever manufactured. A script cannot invent a reviewer or copy a writer's date into a check, and no field a person types may assert that a check happened. If the site says an editor did something, an editor did it.

What a heart means, and what it does not

Where reader reports are switched on for the site, rows carry a control so you can say whether a code worked for you. This page calls it a heart; on code pages it is drawn as a thumbs up and a thumbs down, and the rule is the same either way. Where they are switched off, which is how the site ships today, no control appears on any page. Hearts are reader reports. No count of them is displayed anywhere on the site, and none of them ever changes a state.

That separation is deliberate. If enough hearts could turn a code green, the site would be publishing unverified consensus as fact, which is the practice this whole method exists to avoid. Hearts never mint a star, and they never touch whether a page is indexed. What they do is order the editor 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.

One report is kept per reader, per code, per day, which stops the same person clicking repeatedly. Readers are told apart by network address, and that 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. An editor reading these reports is reading a rough signal of how a code is behaving in the wild, not a count of distinct people.

No IP address is stored. What is kept is one record holding the day, the code, the verdict and a fingerprint: a one-way hash of the address combined with a server-side secret and a value that rotates daily. The record expires by itself. There is no way to recover an address from it, and no way to follow one reader between codes beyond the rotation window.

What we remove and what we keep

A code an editor retires is marked Expired and kept on the page as a retired record, collapsed below the live codes. A reward link whose publisher stated an expiry expires on that date and is kept the same way. 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 finding rows and for keeping the record. It cannot manufacture the evidence itself, and it never changes a state.

Corrections

If a code on this site does not work, that is a defect and we want to know. Corrections go to support@freetins.com 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 state is recorded as a dated event in the page's history, so the history and the page always agree.