Skip to content
Zyper Docs Beta

Social tasks

Social tasks are off-chain HTTP/browser flows fanned across many burner accounts. The pattern mirrors onchain’s 1-task-per-wallet: one social task row = one account.

Two ways to build a social task

1. Google Forms — paste the URL, done

Paste a Google Forms URL into the Build Social Task dialog. The app fetches the form, parses the FB_PUBLIC_LOAD_DATA blob, and renders one field-mapping row per question.

For each question you decide:

ChoiceWhat it means
Per-accountThe answer comes from the account’s profile fields ({wallet}, {xhandle}, etc.)
Task-scope literalOne value pasted into the dialog, shared by every row.
Auto-fill(Short-answer only.) Random plausible string.

Save → one row per account in the chosen account group.

2. Custom module — pick from the module library

If the site isn’t Google Forms — a Layer3 quest, a Galxe campaign, a custom WL form on a project’s site — the Modules dropdown lists pre-built descriptors pushed by the Zyper team via the admin dashboard.

Modules ship two engines:

  • http — straight HTTP POST. Fast. Doesn’t survive Cloudflare WAF.
  • browser — headless Chromium via go-rod. Survives CF + captcha-gated sites. The canonical pattern uses in-page fetch() so the JA3 fingerprint matches Chrome.

The dialog shows each module’s required fields (per-account, task-scope, or auto-captcha). Fill them, pick the account group, save.

Runner semantics

Each row’s execution:

  1. Resolve account profile fields into the request template ({wallet}, {xhandle}, {discord}, {email}).
  2. (If module specifies) solve captcha through your Settings solver. Inject solution as {captcha} token.
  3. Fire the request (HTTP or in-page-fetch via headless Chromium).
  4. Check the response against the module’s success criteria (status codes, body-contains substrings, body-excludes substrings).
  5. Stamp row status.

Failures retain the verbose log in the row’s live-log modal.

Browser sessions

For browser-engine modules, each account gets its own Chromium profile dir at %LOCALAPPDATA%\zyper-suite\browser\<account-id>\. Cookies and localStorage persist between runs, so Google logins / X sessions / etc. survive.

The first run for an account may prompt for a one-time login (Google’s account picker, X login screen). After that, subsequent runs reuse the session.

Captcha budgets

Plan for 30-60s typical, 90s tail on Turnstile-gated modules. The runner allots a 90s per-iteration budget for captcha-gated rows. Tasks that take longer than 90s are marked failed with captcha_timeout in LastError.

Why some sites need browser, not http

Cloudflare WAF classifies Go’s stdlib TLS handshake as non-browser and serves challenge pages. The fix is to do the actual POST as an in-page fetch from a real Chromium, so the JA3 fingerprint matches a normal browser session.

Modules that use the browser engine do this automatically. You don’t pick the engine; the module’s author picked it based on what the target site needs.

What’s stubbed today

  • Discord automation modules (react / send-message / join with hCaptcha / leave) are designed but not yet built.
  • Discord/Gmail/X login flows are session-based; if a session expires there’s no auto-refresh — re-test the account on the Accounts page.