How GHAN prevents install fraud
GHAN runs eight fraud rules continuously against every event chain, each logging to an append-only flag table with a reason code the affected app can read. The ladder goes flag, hold clearing, throttle, suspend.
The rules
1. Click-to-install time
GHAN builds a CTIT histogram per campaign. Chains falling in anomalous bands — spikes under 10 seconds, or a tail beyond 24 hours — are rejected and the source is flagged. The judgement is made against the distribution, not against individual chains, because any single chain can be unusual for innocent reasons and a distribution cannot.
2. Token integrity
Expired, reused or unsigned tokens are a hard reject with no discretion. Single use is a unique database constraint; expiry is checked server side against the issue time. There is no override and no support ticket that changes the outcome.
3. Device signals
Attached to every claim: virtual-machine and hypervisor indicators, operating-system install age, a salted hardware hash, and clock skew. An OS installed under 48 hours ago, a hypervisor flag, or a hardware hash already seen on another claim rejects the chain. Three or more from the same serving partner throttles that partner.
The claiming IP's autonomous system is resolved offline. A desktop install claim arriving from a hosting or datacenter AS is treated as a farm.
4. Retention shape
Cohort retention curves are compared against the category baseline. Both a suspiciously perfect curve and a cliff curve hold clearing for manual review. Fraud that survives every per-chain check usually fails at the cohort level, because faking a realistic decay curve is much harder than faking an install.
5. Pair collusion
- Net flow between any pair is capped at EUR 500 per month until both apps have behaviour scores.
- Early payouts are funded only from third-party cash, never from the colluding pair's own top-ups.
- A monthly graph job looks for circular flows across three or more apps, which is what collusion looks like once a pair cap makes the two-app version unprofitable.
6. Geo and time
Claims arriving from outside the serving app's own telemetry geography are weighted down rather than rejected outright. An app whose users are 90 percent in Germany producing installs claimed from three other continents is not necessarily fraudulent, but it is not evidence either.
7. Canary compliance
The server sends signed liveness probes; the SDK answers with its own signature. An app claiming inventory whose shipped build never answers a probe is not serving placements. Canary failure suspends the app and freezes escrow immediately, because it is the one signal that indicates deliberate misrepresentation rather than a bad traffic source.
8. Complaint rate
Complaints from end users about a member app are tracked per app and feed the behaviour score. Above threshold, an app is auto-throttled regardless of how clean its chains look.
The auto-action ladder
| Step | Trigger | Effect | Reversible |
|---|---|---|---|
| Flag | Any rule fires | Logged to fraud_flags, visible in get_stats | n/a |
| Hold clearing | Retention shape, geo anomaly | Chains stop clearing, escrow stays held | Yes |
| Throttle | Repeated device rejects, behaviour score below threshold | Placement volume cut | Yes |
| Suspend + freeze escrow | Canary failure, token forgery, confirmed collusion | All placements off, escrow frozen | Yes, by admin |
Every action is reversible by an administrator and every action is visible to the app it happened to. There is no silent throttle.
Why the economics matter more than the rules
Rules are a losing game played alone: a sufficiently motivated attacker studies them. The structural defence is an economic one, applied as a design constraint to every monetised feature in GHAN:
The cost to fake an event must exceed the payout for it.
Faking one cleared install requires forging an ed25519 signature that belongs to an SDK inside another company's signed binary, on a machine that does not look like a VM, from an IP that does not belong to a hosting provider, with a plausible click-to-install time, that then gets used again two days later, inside a pair whose net flow is capped at EUR 500 a month. The payout for that is a share of EUR 12 to EUR 50.
When a proposed feature breaks that inequality, GHAN does not build it. That rule has already removed installer-time placements, custom creatives, probabilistic attribution and direct app-to-app targeting from the product.
The monthly public fraud report
Generated from fraud_flags and the ledger, published through get_network_stats and on the transparency page:
- Installs rejected, by rule
- Euros clawed back
- Apps throttled, suspended and expelled
- Clearing rate across the network
Publishing the number of installs GHAN rejected is the only version of this claim that means anything, because a network with no fraud report is not a network with no fraud.
Questions people ask about this
What is click-to-install time and why does it matter?
Click-to-install time, or CTIT, is the interval between the click that issued a token and the claim that redeemed it. Real human installs produce a broad, right-skewed distribution measured in minutes. A spike below ten seconds means the install was not downloaded in that time, and a long tail beyond 24 hours usually means tokens are being harvested and replayed. GHAN builds a CTIT histogram per campaign and rejects the chains in anomalous bands rather than judging chains individually.
How does GHAN detect install farms?
Primarily from the autonomous system of the claiming IP address. A desktop application install claim arriving from an IP whose AS domain is a hosting provider is a farm, not a customer, and that is a far stronger signal than city-level geography. GHAN resolves country and ASN from an offline database on the hot path, so no partner IP is sent to a third party, and uses a conservative allowlist because a false positive silently destroys a real install and costs a partner money.
What is pair collusion?
Pair collusion is two apps sending each other installs to extract network payouts rather than to acquire users. It is the cheapest attack on any two-sided install network. GHAN caps net flow between any pair at EUR 500 per month until both apps have behaviour scores, funds early payouts only from third-party cash rather than from the colluding pair's own top-ups, and runs a monthly graph job looking for circular flows across three or more apps.
Can I see why my installs were rejected?
Yes. get_stats returns fraud_rejected broken down by reason code. Transparency applies to rejections as much as to payouts, because a network that will not tell you why it did not pay you is indistinguishable from one that simply did not want to.
What happens to money when fraud is detected after clearing?
The ledger records a clawback as a new line. Nothing is ever edited or deleted, because the ledger table blocks UPDATE, DELETE and TRUNCATE at the database level. A clawback is visible to both parties and appears in the monthly public fraud report as euros recovered.
Machine-readable versions of this page: markdown · llms.txt · llms-full.txt · OpenAPI · AI catalog