WaitSpin public contract

WaitSpin Privacy

This notice explains the data WaitSpin uses to operate the API, marketplace, publisher extension surface, billing, fraud controls, support, and monitoring.

Last updated: June 17, 2026. The public launch surface is CLI, REST API, verified publisher surfaces for VS Code, Claude Code, MiMo Code, OpenCode, and Grok Code CLI, public market, and guarded wallet/ledger/Connect/payout routes.

Data We Process

  • Email address, verification attempts, OTP delivery metadata, account status, plan/trust level, and API key metadata such as prefix, scopes, hashed secret, status, and last-used timestamps.
  • Advertiser campaign data, including ad line, brand name, destination URL, block count, price, campaign state, Checkout session IDs, Stripe payment identifiers, and webhook event IDs.
  • Publisher install data, including install ID, target, status, serve sessions, impression events, visible time, timestamps, user-agent, IP-derived rate-limit and fraud signals, and audit events.
  • Operational logs, support messages, incident notes, monitor evidence, abuse reports, and security/audit records needed to run and protect the service.

Publisher Surface Behavior

Verified publisher surfaces include the VS Code Activity Bar/status-bar extension, Claude Code statusline command, MiMo Code shell hook, OpenCode TUI plugin slot, and Grok Code CLI footer. They poll the WaitSpin API for a sponsored message, show the message in the relevant wait-state surface, open the advertiser destination only after user action, and report an impression after the required visible interval. The documented surfaces do not need source code, keystrokes, editor contents, terminal output, or repository files to serve ads.

The VS Code extension connects a publisher install inside VS Code, stores the publisher API key in VS Code SecretStorage, stores the install ID in user-scoped extension state, and polls only the WaitSpin API. Serve polling sends the install ID; impression reporting sends the serve ID, serve receipt, install ID, and visible duration. WaitSpin also receives standard network metadata used for rate limits, abuse prevention, and audit logging.

  • VS Code: Uses VS Code SecretStorage for the publisher API key and user-scoped extension state for the install ID. The Marketplace extension provides an Activity Bar publisher view, status-bar mini state, wallet balance, pending balance, recent ledger entries, current sponsor card, no-inventory state, connect/polling/refresh/open commands, and a five-second visible impression hold.
  • : Inspects user/scoped Claude settings, manages statusLine.command with --compose-existing support, and stores WaitSpin state/cache under ~/.waitspin.
  • : Installs a managed runtime under ~/.local/bin, adds a bash hook in ~/.bashrc, and stores WaitSpin state/cache under ~/.waitspin.
  • : Installs a plugin under ~/.config/opencode/plugins, manages the tui.json plugin entry, and stores WaitSpin state/cache under ~/.waitspin.
  • : Uses a managed text-asset footer patch with hash-backed backup/restore plus managed runtime/cache/state; it does not patch native binaries.

The VS Code extension is distributed through the Visual Studio Marketplace. Public source is published at github.com/citedy/waitspin. Public source and provenance are documented on the WaitSpin Trust page, including the machine-readable manifest at /provenance/waitspin-vscode.json.

What Publisher Clients Do Not Send

WaitSpin is designed to measure wait-state ad visibility, not your work. The public clients do not send:

  • workspace files
  • source code
  • open editor text
  • prompts
  • model responses
  • integrated terminal output
  • shell history
  • repository URLs
  • screenshots
  • clipboard contents
  • raw keystrokes

Operational Telemetry

WaitSpin has no separate analytics telemetry stream in the public clients. Serve, impression, wallet, and accounting events are operational telemetry needed to run the marketplace.

  • publisher registration: {install_id,target}
  • serve polling: {install_id}
  • impression event: {serve_id,serve_receipt,install_id,visible_ms}
  • standard network metadata used for rate limits, fraud controls, abuse response, and audit logs

How We Use Data

We use WaitSpin data to verify accounts, issue and secure API keys, create campaigns, route Checkout, activate paid blocks, select and serve ads, record billable impressions, enforce quotas, prevent fraud, investigate incidents, provide support, and satisfy legal, accounting, tax, and security obligations.

Processors And Infrastructure

WaitSpin uses PostgreSQL/Supabase-compatible database infrastructure, a dedicated DigitalOcean VPS, Cloudflare DNS/security services, Stripe for payments, Resend for email, GitHub Actions for public smoke checks, and logging/monitoring tools needed for reliability and abuse response. Stripe handles card data directly; WaitSpin stores Stripe identifiers and payment state, not full card numbers.

Retention

API, campaign, payment, ledger, audit, and fraud records are retained as long as needed for marketplace accounting, dispute handling, security, compliance, and support. Operational logs and monitor evidence should be kept only as long as needed for incident response and launch evidence. We may retain minimal records after account closure when required to prevent abuse, resolve disputes, or meet legal obligations.

Choices And Security

You can stop using the extension, remove local extension settings, rotate API keys, avoid storing keys in workspace settings, and contact support for privacy or account questions. WaitSpin protects keys with hashed storage, uses trusted-edge and host-isolation checks in production, limits request rates, and avoids printing secrets in launch evidence or incident notes.

Money And Payout Data

Wallet, ledger, Stripe Connect onboarding, payout dry-run, and guarded payout execution are release-candidate surfaces. They process payout, tax, compliance, account, balance, ledger, and Stripe Connect status data when used. Public payout promises and live transfers remain gated until deployed E2E, legal approval, test-transfer proof, and explicit operator flags are complete. Account-credit redemption and self-serve refund workflows are not shipped; if they are added later, updated public docs will describe the additional data they require.