GHAN frequently asked questions

GHAN is a cross-promotion and paid-install network for macOS and Windows desktop applications. Member apps show each other's templated install cards inside their own in-app lifecycle moments, and settle through a single append-only credit ledger where both the serving and the receiving app have cryptographically signed every monetised line.

Neither. Bundleware installs software alongside software you asked for, usually via a pre-checked box in an installer. GHAN never places anything inside an installer, there is no checkbox, nothing installs unless the person clicks a card and completes the other app's own installer themselves, and every app that can appear has passed a notarisation or Authenticode check and a malware scan.

Three structural differences, each one a direct response to how they failed. They placed offers inside installers, which puts the offer in competition with the Next button; GHAN has no installer-time slot at all. They paid on the install event, which makes manufacturing installs the cheapest way to earn; GHAN clears only after 48 hours of real retention. They let partners ship custom creative, which is how malware payloads travelled; GHAN renders templated cards from a payload that has no field for markup.

Desktop only - macOS via DMG and Windows via EXE. The version 1 SDK covers Electron, Tauri and Node desktop apps. There is no mobile product and none planned.

Nothing to join and no subscription. Advertisers pay from a published floor per cleared install - EUR 12-18 for utilities and consumer, EUR 20-30 for creator tools, EUR 35-50 for prosumer and B2B. The floor never rises and anyone can always buy at it. GHAN keeps 30 percent and the serving app earns 70 percent of whatever cleared, or 84 percent of it in value if taken as credits.

Both, in two layers. The rate card is a floor that never rises and that any approved advertiser can always buy at. Above it there is an optional second-price auction for priority when a category is contested - you pay one cent above the next-highest competing bid, never your own maximum - and thirty percent of every category is reserved at floor and never auctioned. You bid per cleared install rather than per click, so a lost auction costs nothing and a won one costs nothing unless the install survives 48 hours. A purely fixed price cannot clear a market or pay the apps with the best inventory more; a floor plus a market above it does both.

Nine. The gate (code signature, malware scan, domain age, contact challenge, binary identity, re-run weekly). The placement layer (templated cards only, no installer placement, host-controlled slots, client-side exclusions). Attribution (single-use signed tokens, two independent signatures). Device signals (VM indicators, OS install age, salted hardware hash, clock skew, datacenter ASN resolved offline). Economics (48-hour clearing, escrow, pair caps, cost-to-fake above payout). Behaviour (cohort retention shape, canary probes, complaint rate). Enforcement (flag, hold, throttle, suspend, kill switch, clawback). Data (append-only ledger proven on a real database, row-level security, pinned TLS, no PII). Disclosure (published rejection conditions, reason codes, monthly fraud report).

With a single-use token issued at click time, signed, expiring after 15 minutes, redeemed by the receiving SDK on first run and countersigned with that SDK's own ed25519 key. Both signatures are required for the chain to advance past the claim. If the token is missing, expired or already used, the install is simply not attributed.

No, and there is no fallback that amounts to it. No device fingerprinting, no IP-and-timestamp matching, no probabilistic modelling. This costs GHAN attributable volume on purpose, because a probabilistic fallback is the single largest attack surface an install network can have.

Credits move into escrow at the moment an install is claimed, and they only leave escrow if the install is still in use 48 hours later. Pairs trading above EUR 500 per day clear on day-7 engagement instead. Nothing is billed on an impression or a click, ever.

The escrow hold is refunded automatically, the advertiser pays nothing, the serving app earns nothing, and the chain ends as rejected with a reason code both parties can read through get_stats.

It is the cheapest attack on any two-sided install network, so GHAN treats it structurally rather than by detection alone. 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, direct app-to-app targeting does not exist, and a monthly graph job looks for circular flows across three or more apps.

Behavioural counters after consent - session starts and ends, coarse feature counts - and fraud signals attached to an install claim, which are VM indicators, OS install age, a salted hardware hash and clock skew. Never file contents, window titles, clipboard, keystrokes, raw hardware identifiers, or anything personally identifying.

No. The placement payload contains an app id, an icon URL, a name and one line of text. There is no field for HTML, JavaScript or an arbitrary image, and no code path in the SDK that would execute one. This is an implementation property rather than a contractual promise, which is why it is checkable.

No. Serving and buying are independent. An app can serve, accumulate credits and cash out through Stripe Connect without ever running a campaign.

By passing an automated gate - a notarised or Authenticode-signed binary, a clean VirusTotal result, a domain at least six months old verified over RDAP, a contact email that answers a challenge, and a download URL that serves the declared bundle id. Failures come back as machine-readable reason codes with eligibility dates where applicable.

Yes, and that is the intended path. Every write capability ships as an MCP tool before it ships in a dashboard. An agent can register the app, read the score, wire the SDK, create campaigns and pull the ledger. Two moments stay human on purpose - shipping the release containing the SDK, and authorising money.

Take any ledger line, resolve its event chain, and verify the receiving signature against your own registered public key. That signature was produced by an SDK inside a binary you compiled and signed, so GHAN cannot have manufactured it. The ledger blocks UPDATE, DELETE and TRUNCATE at the database level, so corrections appear as new lines rather than edits.

There is no charge to join, to serve placements, or to earn. Impressions and clicks are never billed. You only pay when you are the advertiser and an install you bought is still in use two days later.

Turn off the placements with the kill switch or stop calling the slot API, request a payout of any remaining balance once it is over EUR 50, and ship the next release without the dependency. Nothing about GHAN is load-bearing in your application.