Smurfing and Alt Accounts in Online Games

Every competitive game with free accounts deals with two kinds of alt. The smurf is a skilled player who makes a fresh account to play against beginners, wrecking new-player matches, which are exactly where you can least afford churn. The ban evader is a cheater or abusive player who was removed and comes back the same afternoon on a new account. Both rely on the same thing: accounts cost nothing, and nothing connects the new one to the old.

Email verification and phone checks raise the cost a little. A device-level link raises it a lot, because players can make new accounts all day while getting a new gaming PC is another matter. This post covers how to build that link, and how to tune it for the shared machines games run on.

The signal: accounts on the same device

The core question is simple: has this device created or played other accounts, and what happened to them?

On web logins, launchers with a web sign-in, and mobile games through the iOS, Android, Flutter or React Native SDKs, Prynt gives each device a stable visitorId. When your server fetches the event for a signup or login, it includes accountsOnDevice, every account you’ve linked to that device, with activity counts and first and last seen times:

const ev = await prynt.getEvent(req.body.pryntRequestId);
const accounts = ev.accountsOnDevice.accounts;   // [{ linkedId, events, firstSeenAt, lastSeenAt }]
const banned = await bans.anyOf(accounts.map((a) => a.linkedId));

The list only fills up if you link accounts. Call PUT /v1/events/{requestId} with the new account id after creation, and pass linkedId to identify() when players log in, so devices pick up every account that plays on them, not just the one created there. accountsOnDevice explained covers this in detail.

Ban evasion: the clear case

A new account on a device that holds a banned account is the highest-confidence alt signal you’ll get. Two things make it robust:

• Deny-list the device on ban. When you ban for cheating, add the device’s visitorId to the deny list. Future identifications from it return block with the DENYLIST reason code before any other rule runs.
• Label the outcome. Report the ban with POST /v1/outcomes and a label like abuse or fraud. Include the device as well as the account (a visitorId, or a requestId from one of the player’s sessions), so the label flags the device on future visits and not only the banned account id. It also builds your reputation data. If you opt into the reputation network, it can also flag a device confirmed bad elsewhere.

curl -X POST https://api.pryntid.com/v1/outcomes \
  -H "Authorization: Bearer $PRYNT_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"linkedId":"player_55120","visitorId":"vst_…","label":"abuse","notes":"Aimbot, banned 2026-10-07"}'

Expect determined evaders to try clean environments: virtual machines, spoofed fingerprints, a second machine. Those show up as virtualMachine, tampering and the VIRTUAL_MACHINE and TAMPERING reason codes, and on mobile as emulator, rooted device, instrumentation or cloned-app signals. Banned user re-registration detection goes deeper on evasion tactics.

Smurfing: a matchmaking problem first

Smurfs are different. Most aren’t breaking a rule you’d ban for. They want easy games, to play with lower-ranked friends, or a fresh start. The harm comes from mismatched matches, so the most effective response is often to fix the match rather than the account.

The device link gives you the evidence:

1. A new account is created on a device that already holds an established account: many events, a long firstSeenAt to lastSeenAt span.
2. That established account has a high rating in your own game data.
3. The new account’s early results are far above what its starting rank predicts.

With all three, a reasonable response is to seed the new account’s matchmaking rating from the established one, or speed up its placement, so it reaches its real level in a few games instead of fifty. The smurf gets fewer free stomps, beginners stop being the content, and nobody gets banned for owning two accounts.

Keep ranked restrictions for repeat or organized cases, such as boosting services that run accounts for money. Those show up as one account played from many devices (deviceSpread, the number of distinct devices an account used in 24 hours) or one device cycling through many accounts.

Shared PCs: where naive rules fail

Games run on shared hardware more than most products. Siblings share a family PC, friends play on each other’s consoles and laptops, and internet cafés and LAN centers put hundreds of players on a few dozen machines. A rule like “block any device with more than two accounts” bans all of them.

The account list tells these situations apart if you look at its shape, not only its length:

Pattern	What accountsOnDevice looks like
Family PC	A few accounts, each with many events over months
Internet café	Many accounts, most with repeated sessions spread over a long period
Smurf	One established account plus a new one, created recently
Alt farm or account seller	Many accounts created close together, each with few events, then gone
Ban evasion	Any number, but one of them is banned

In code, that means weighting by recency and activity rather than counting:

const DAY = 864e5;
const now = Date.now();
const fresh = accounts.filter(
  (a) => now - Date.parse(a.firstSeenAt) < 7 * DAY && a.events <= 3
).length;

if (banned) return block();
if (fresh >= 3) return requireVerification();  // a burst of throwaway accounts
return allow();                                // shared machine, normal play

For venues you know about, such as a partner LAN center, add exceptions by device in your own code rather than raising the limit for everyone. And remember that one café machine with a banned account on it shouldn’t ban every future player there. Scope your deny entries to the account where possible, and reserve device deny-listing for cases where the device itself is clearly the cheater’s.

Bots and farms

Some alt accounts aren’t people at all: bot-leveled accounts sold on grey markets, or farms grinding currency. Those look like automation rather than smurfing: the bot signal, AUTOMATION_BEHAVIOR, datacenter or residential proxy networks, emulators on mobile, and many accounts cycling through a small set of devices. Device farm detection and the fraud rings page cover finding the clusters, and bot detection covers the automation side.

Rolling it out

Start by linking accounts on every login for a few weeks, without enforcing anything. Then look at the devices behind your known cheaters and known smurfs, and at your shared-machine edge cases. That data will tell you where your thresholds belong, and whether matchmaking or bans is the right response for each group. Multi-accounting detection has the general playbook. Games just add a lot more shared PCs to it.