Live events and battle passes are exciting because they give players a reason to return. They are also attractive targets because rewards are limited, public, and often valuable.
Let the server own event time
Device time is not trusted. Players can change clocks, pause devices, or run the game in strange environments. Event start times, end times, cooldowns, and reward windows should use server time.
The client can display countdowns, but the backend should decide whether an event is active and whether a reward can be claimed.
A server-owned event configuration can stay small but precise:
Version every event
Use clear event IDs, season IDs, and reward IDs. A reward from Season 1 should not be confused with a reward from Season 2. If a claim request does not match the current event version, the backend should reject it or ask the client to refresh.
Use reward ledgers
Store what each player has claimed. Include event ID, reward ID, tier, account ID, timestamp, and grant result. This prevents duplicate claims and helps support answer questions after an event ends.
A claim request should be checked against both the event configuration and the player's ledger. The server should ask: Is this event active? Is this reward part of this event version? Did this account already claim it? Does the player own the premium track if the reward requires it?
Protect battle pass progression
Battle pass XP and tier claims should be validated like an economy system. The server should know how XP was earned, whether caps apply, whether the season is active, and whether the player owns the premium track.
For example, if one quest grants 500 pass XP and the daily cap is 3,000 XP, the backend should reject a client that suddenly reports 25,000 XP from a single offline session unless a trusted event rule explains it.
Handle stale clients safely
Mobile players may open the game after an event changed. The client may still show old data. The backend should reject old event claims and return a clear refresh response. This protects the event without making the error feel hostile.
Watch abuse patterns
Useful signals include repeated duplicate claims, claims after event close, impossible tier jumps, stale event versions, and many accounts using the same suspicious timing. These patterns help you protect future events.
Do
- Use server time for event start, end, cooldown, and reward windows.
- Store event version, season ID, reward ID, and claim state in a backend ledger.
- Plan safe fallback behavior when the client has stale event data.
Don't
- Do not trust device time for limited rewards.
- Do not let the client decide that a season tier or event reward is claimable.
- Do not reuse reward IDs across seasons without clear versioning.