Skip to main content
No rewards system is 100% fraud-proof — but ZBD builds multiple layers of protection into the SDK so you don’t have to build them yourself. Here’s how they work and where the limits are.

Geolocation

ZBD detects a player’s country from their IP address on SDK initialization. This determines:
  • Which payout methods are shown to the player
  • What withdrawal limits apply (Tier 1 countries like the US, UK, and DE have higher limits than Tier 2 countries)
  • Whether the player is in a supported region at all
If a player’s detected country is incorrect — due to a VPN, travel, or a bad IP lookup — you can override it from the developer dashboard. See SDK Controls.

VPN and proxy detection

If a player is detected as using a VPN or proxy during SDK initialization, Init returns false. This is a fraud signal: VPNs are commonly used to spoof locations and bypass regional restrictions. When this happens, always call ShowModal() — the modal surfaces the reason to the player and gives them a path to retry. Do not silently fail. See Error Handling.

Time Alive

The SDK sends a ping to ZBD servers approximately every 20 seconds while your app is open. This builds up a “Time Alive” value that gates how much a player can withdraw. A player can earn rewards faster than they can withdraw them — but they can only access what their Time Alive allows. This means a bad actor who calls SendReward repeatedly can inflate their balance, but can’t immediately withdraw it. The withdrawal limit accrues slowly enough to make farming unprofitable.
For example: a player might earn 10,000 units in a session, but their withdrawal limit may only allow 200 units per hour of genuine gameplay. Farming requires real time, which limits the economics of an attack.

Device attestation

ZBD uses Apple and Google attestation systems to verify that the device running your game is genuine and unmodified — not rooted, jailbroken, or running in an emulator. This restricts farming operations that use modified devices or emulators. A sophisticated attacker using genuine devices can still pass attestation, which is why Time Alive and server-side reward delivery are additional layers rather than a substitute. To enable attestation, you’ll need to provide ZBD with your app’s Bundle ID and signing key details. See Attestation Setup.

Bot and emulator detection

ZBD monitors network behavior and device signals to detect automated reward farming — bots running at scale, emulators, and coordinated IP patterns. This runs server-side and requires no configuration from you. For higher-risk integrations, additional verification steps can be enabled at the point of withdrawal, including CAPTCHAs. Talk to your Customer Success Manager if you’re concerned about large-scale farming.

What you can do

The single most effective thing you can do is move to server-side reward delivery:
  • Your server sends rewards, not the client — so the reward path is never exposed
  • Disable client-side SendReward entirely in the dashboard
  • Provide ZBD with your server’s IP address so we can allowlist it
A bad actor who reverse-engineers your game client finds nothing useful if rewards can only be issued from a trusted server. See Send Rewards (Server) for setup.

Honest assessment

No system is foolproof. A sophisticated operation running hundreds of genuine, attested devices with real time-alive can still farm rewards — slowly. The economics of doing so at scale are unattractive given the low withdrawal limits, but it’s worth knowing the limits of these protections. ZBD monitors for patterns at the platform level and will flag anomalies with you.