Every paid view is proven, not promised.

A marketplace only works if the views are real

Dawdlo pays developers for genuine, on-screen sponsor views during real agent wait states. That model only holds if a view that earns money was actually rendered to a person — not minted by a script, a hidden render, or a click farm. Advertisers fund the marketplace; they need to trust that every charge maps to attention they truly received.

So verification is not a feature bolted on the side — it is the settlement path itself. An impression earns nothing until the server has independently observed proof that it stayed on screen, and earnings can be frozen before they ever leave the platform if an account's behaviour looks automated. Every protection below is enforced server-side, which means it applies identically to every surface — the Claude Code plugin and the VS Code extension run through the exact same endpoints and the exact same checks.

Cryptographically verified views

Every served impression carries an HMAC-signed token bound to its identity and serve time. The token can't be forged or replayed onto a different impression, and it's checked again at settlement.

Proof of a sustained view is a challenge–response handshake the client cannot fake from a single round trip:

1. The serve response includes a one-time proof challenge.
2. While the line is visible and the agent is active, the client heartbeats with that challenge. The server records the view start and rotates the challenge to a fresh one-time value.
3. A later heartbeat must present the rotated challenge — a stale or guessed value is rejected.
4. Only after at least two spaced heartbeats inside the allowed dwell window does a confirm settle the charge.

Because the server enforces a minimum spacing between heartbeats, dwell time must elapse in real wall-clock time per impression. A rogue client can't replay a burst of heartbeats to fake a sustained view, and it can't pre-roll proof for a line it never showed. Honest visibility signals from the client can only ever stop billing early; they can never manufacture it.

One view at a time per device

A real person looks at one wait line at a time. Dawdlo enforces that with an attention lease: only a single impression per device can be actively proving a view within a short window. Attempts to settle many overlapping impressions on one machine — the core trick of a render farm — collide on the lease and earn nothing.

Rate caps that resist rotation

Earning is throttled at several layers, so no single device or connection can mint unbounded views:

• Six views per campaign, per device, per hour — no single advertiser is shown on loop to the same machine.
• Ninety paid views per device, per hour.
• Ninety paid views per connection (IP), per hour.

The device identifier is ultimately client-supplied, so a rogue client could try to rotate it. The per-connection cap is derived server-side from the request itself and cannot be rotated by the client — it's the cap that holds against device-hash churn. Device hashes are also namespaced per account, so identifiers can't be correlated or reused across developers.

Anti-farming detection

Rate caps bound volume; they don't judge pattern. A patient bot or coordinated farm that stays under the caps would still accrue earnings. So Dawdlo continuously scores each account's recent settled views for the behavioural signature of automated or farmed traffic, combining several independent signals — for example:

• Views that consistently settle at the very edge of the minimum dwell window, the way a script does.
• Robotically regular spacing between views, rather than the natural irregularity of real work.
• High volume that no human ever clicks.
• Concentration of earnings on a single device or a single connection.

No single signal condemns an account — a solo developer testing on one machine, or a quiet integration with few clicks, looks unremarkable on any one axis. An account is only flagged when several independent signals agree on a meaningful sample, which keeps honest developers clear while still catching deliberate abuse. Detection is surface-agnostic: a farm trips the same threshold whether its views came from Claude Code or VS Code, and the dominant surface is recorded with the evidence.

Payouts freeze before money moves

The most important property: a flagged account cannot withdraw. When the detector trips, the account's payouts are hard-frozen — the developer keeps their dashboard and their visible balance, but any payout request is refused regardless of the amount available. Money does not leave the platform on a farming pattern.

A frozen account surfaces in the operations console with the evidence that triggered it. Clearing a freeze is a deliberate, manual review decision — there is no automatic path back — so a confirmed abuser stays paused while a false positive can be reviewed and released by a human.

POST /api/v1/developers/payout
→ 403  { "frozen": true,
         "error": "payouts are frozen pending review" }

This sits on top of the existing payout requirements: completed Stripe onboarding with transfers enabled, and a minimum available balance. Charging happens at confirm time, not serve time, so advertisers only ever pay for views that demonstrably stayed on screen — and the platform holds developer earnings as a liability until they clear review and settle.

Reporting abuse

If you believe you're seeing manipulated inventory or suspect a developer account is gaming the system, contact us with the campaign or account in question. Advertisers can audit their own delivery through the reporting API, and every settlement is written to an immutable ledger we can reconcile against.

Thresholds and signal weights are tuned continuously against live traffic; we deliberately don't publish exact values, since doing so would only help bad actors calibrate around them.