Cloud phones: how offerwall farms rent Android in a data center, and how to catch them

Short answer

A cloud phone is an Android container rented on a server board. Farms name each one a different phone model and route it through residential proxies, so IP checks pass. The GPU gives it away: a bare "Mali-G610" from an ARM server board instead of a phone's "Mali-G610 MC6", an Adreno 640 at OpenGL ES 3.1, or a model that never shipped with that GPU.

Browsers on one server GPU

621 in 30 days, naming 99 different phone models.

Real phones with that GPU

30, every one reporting its core count (MC4 or MC6).

Extra conversions to hold

54 in four days that other checks had let through.

Networks they came from

Up to 47 different /16 ranges for one device profile.

What a cloud phone is

Cloud phone services rent out Android devices that live on servers. Behind each one is a container or virtual machine on an ARM board, shown to the renter as a phone screen in a browser or an app. They are sold for app testing and for running mobile games around the clock, and they cost a few dollars a month each.

For a farm they solve every problem of real phones at once. There is no hardware to buy, charge or replace. Hundreds of devices can be started from one dashboard. Each container can be given any model name, Android ID and screen size, and wiped in a second when an account is banned. Pair them with a residential proxy per device and each one looks like a different person at home in a high-payout country.

What they looked like on a real network

On a US-traffic offerwall network, we grouped every browser by the GPU it reported. One group stood out. 621 browsers in 30 days reported a GPU named simply "Mali-G610", and between them they claimed to be 99 different phones: Pixel 3, Pixel 7 Pro, Galaxy A22, Xiaomi Mi 11, vivo and Infinix models, even phones that do not exist yet.

Real phones with a Mali-G610 exist: some MediaTek Dimensity models use it. In the same month, 30 of them visited the network, and every one reported the GPU with its core count, "Mali-G610 MC4" or "MC6". The bare name is what an ARM server board reports. A second group reported an Adreno 640, the GPU of 2019 Snapdragon phones, running at OpenGL ES 3.1. Real phones with that GPU run at 3.2. These claimed to be Galaxy S23 and S24 models or the default profiles of Android emulators.

Why IP checks miss them

Cloud phones rarely connect from the data center's own address. The farm routes each device through a residential or mobile proxy, so the IP is a home connection in the right country. One device profile in our data came through 47 different /16 networks in a month. A VPN or hosting check sees a clean home user every time.

Rotating the model name defeats simple device fingerprinting too: if the fingerprint includes the model, each container looks new. What the farm cannot change is the hardware under the container. The GPU name comes from the server board's driver, and the same board serves every container on it.

The tells that give cloud phones away

• A server GPU name. "Mali-G610" without a core count is what ARM server boards report. Phones with that GPU say "Mali-G610 MC4" or "MC6".
• An old GPU at the wrong OpenGL version. An Adreno 640 at OpenGL ES 3.0 or 3.1 is a virtualized Snapdragon 855 board. Phones with that GPU run ES 3.2.
• A vendor pair that does not exist. A renderer that names ARM with an Adreno GPU, or Qualcomm with a Mali GPU, describes hardware nobody makes.
• A model that never had that GPU. A Galaxy S24 ships with an Adreno 750 or an Xclipse 940, never an Adreno 640. A Pixel 7 has a Mali-G710. Checking the claimed model against its real chip catches the rest.
• Many models on one hardware profile. When dozens of "different" phones share one GPU, screen and timezone, they are one kind of machine wearing many names.
• A flagship on a 16:9 screen. Farms of real phones force them to 720x1280 so one PC can stream and control dozens at once. A 2024 flagship GPU on a 360x640 screen is one of those phones, since no recent phone ships with a 16:9 display.

None of these depend on the IP, so residential proxies do not help. And none of them flag real phones: every rule only fires on combinations a real phone does not produce.

What changed when we checked for them

CashoutGuard already blocked many of these devices for other reasons: the same device behind several accounts, a clock from another country, or a farm pattern on residential proxies. Run over the first four days of enforce mode, checking the GPU itself would have held 54 more conversions, about $138 in payouts, from 46 accounts. 16 of those conversions had no other warning at all: a clean IP, no linked accounts, nothing but a phone that could not exist.

Since October 2026 CashoutGuard reports this as "Cloud phone" (code cloud_phone), and a known phone model with another chip's GPU as a spoofed device. Both are part of the Emulators switch in Rules & lists, so a site that always blocks emulators blocks cloud phones too.

What to do on your network or rewards site

1. Scan the device on clicks and conversions, not only at signup. A cloud phone shows its GPU on every page; if your click URL never runs a scan, it never shows it. See offer clicks from app WebViews for clicks that arrive without one.
2. Block emulators and cloud phones at the money moment. In enforce mode, blocking only conversions or cashouts leaves every click and signup untouched while the payout is held.
3. Look at the publisher. When one publisher's users are mostly cloud phones, the problem is the traffic source, not a few accounts. The publisher profile shows its share of flagged conversions.
4. Do not rely on the model name. It is the first thing a farm changes. The hardware behind it is the last.