Security & Fraud Prevention

Rewarding real money attracts bad actors. 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. Some apply automatically; others you can tune to your game’s risk tolerance. Here’s how they work and where the limits are.

​

Enforcement actions

When a user trips a fraud check, ZBD can place them in one of the following states. Each restricts what the user can do, without necessarily cutting them off entirely.

• Limited earnings — the user can still earn and withdraw, but their withdrawal limit increases much more slowly, so they can’t earn as much as a normal user over time.
• Withdrawal lock — the user can initialize the SDK and earn normally, but when they try to withdraw they’re prompted to contact support. ZBD (or you) can lift the lock once the user is judged not to be suspicious.
• Disabled — the SDK will not initialize for this user. They cannot earn, send rewards, or withdraw.

​

How the protections work

​

Device attestation

Device attestation is the foundation. 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. When attestation is set up correctly, only users running a legitimate build of your app on a genuine device can increase their withdrawal limit and receive rewards. Users who attempt to sign up from an emulator or a jailbroken or rooted device are disabled automatically — no configuration needed. 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.

​

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.

​

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.

​

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 Earn Controls.

​

VPN and proxy detection

VPN and proxy use is a fraud signal: VPNs are commonly used to spoof locations and bypass regional restrictions. ZBD responds in two different ways, at two different moments — don’t confuse them:

• Policy: limited earnings mode. A player detected using a VPN or proxy is placed into limited earnings mode — the SDK initializes normally and rewards keep working, but their withdrawal limit grows much more slowly. This is reversible: the modal directs the player to support, and their normal earning rate can be restored once it’s resolved.
• Interference: init failure. Some VPNs, ad blockers, and private-DNS setups block the network requests device verification depends on. When that happens Init fails, and because the modal can’t be shown after a failed init, you need to surface your own message asking the player to disable the blocker or VPN and try again. Do not fail silently. See Error Handling.

​

Configurable protections

Some signals are more prone to false positives, so ZBD treats them conservatively by default. You can tighten them for your game if you see abuse — just let us know and we’ll adjust your configuration.

​

Datacenter connections

Most real players connect from a home or mobile network. A datacenter connection is unusual for a genuine player and is far more common among bots and gaming farms. That said, legitimate users do sometimes appear on a datacenter connection — for example, university or airport Wi-Fi that routes through one. Because of that, ZBD allows datacenter sign-ups by default. If you notice increased fraud or farming, you can ask ZBD to disable or withdrawal-lock users on datacenter connections.

​

Factory reset

Most users never factory reset their phones. When they do, it’s often legitimate — a second-hand phone, or occasionally a major system update that sets the factory-reset flag. But factory resets are also a common evasion tactic: a user resets the device to give it a new identity, then plays as a “new” user to escape a disable or a withdrawal limit. We recommend placing a user into withdrawal lock if their device was factory reset within the last 2 weeks. You can adjust this threshold — for example, loosen it if you start seeing an increase in support requests.

​

Developer tools

We can detect when a device has developer tooling enabled — developer options, debugging, and similar low-level access. Plenty of legitimate power users turn these on, but the same tooling is also what’s used to inspect, hook, and manipulate an app, so it’s a useful signal when weighing other risk factors. Because developer tooling on its own isn’t proof of abuse, ZBD allows these devices by default. If you see abuse from devices with developer tooling enabled, you can ask ZBD to disable or withdrawal-lock them.

​

Device model

Fraud farms often run large numbers of the same cheap, low-cost device model. When you notice farming concentrated on a particular device model, ZBD can automatically place users on that model into withdrawal lock (or disable them). Because a popular budget phone can also be used by many genuine players, this control is targeted and off by default — you tell ZBD which device model(s) to action.

​

Minimum app version

You can require a minimum supported version of your game for withdrawals. Users on anything below it won’t be able to withdraw and will be prompted to upgrade — for example, blocking withdrawals below v1.1.2. This protects you when an older build has a known bug or exploit that could be used to farm rewards.

​

Configuring these controls

The configurable protections above are managed by ZBD. To turn any of them on, change a threshold, or set your minimum app version, reach out to your ZBD Customer Success Manager with your preferences. They’re off by default, and we can adjust them as your needs change.

​

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. For a deeper education in game security — how games get attacked and how to harden yours — work through the Game Security Course in the Knowledge Base.

​

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.