SpinGate Partners · Agreement

Partner program terms.

The operative agreement between SpinGate(“we”, “the operator”) and any approved partner (“you”). The program is no-KYC, payouts settle on-chain in BTC, ETH, or USDC on a monthly cycle, and only the partner code ever touches the visitor's browser.

§ 1 · Commission structure

First-month commission + recurring tail.

Every paid conversion credits your partner balance at the first-month rate; if the buyer renews on a recurring plan, you earn the tail rate on every renewal for the product's lifetime. Tiering is set at approval and may be promoted by us as your coverage scales.

Tier
Standard
The default tier for every approved partner.

Default (per-tier)

5%first month·2%recurring

Year-1 plan

7%first month·3.5%recurring

Early Lifetime

8%one-shot·—no renewals
Tier
Featured
Hand-picked partners with above-100k audience or recurring coverage.

Default (per-tier)

7.5%first month·3%recurring

Year-1 plan

7%first month·3.5%recurring

Early Lifetime

8%one-shot·—no renewals
Tier
Super Affiliate
Top-of-stack partners — higher revenue share + featured placement.

Default (per-tier)

10%first month·4%recurring

Year-1 plan

7%first month·3.5%recurring

Early Lifetime

8%one-shot·—no renewals
Product overrides & floor
Two products carry higher headline rates, and every commission credits a minimum of 1¢ so a sub-cent row never renders as zero on the dashboard.

Year-1 Lock-In: 7% first month and 3.5% recurring on every 12-month renewal — uniformly across all three tiers.

Early Lifetime (one-shot): 8% on the single payment — no recurring tail, since there are no renewals.

All other paid products: per-tier default — Standard 5% first month, 2% recurring; Featured 7.5% first month, 3% recurring; Super Affiliate 10% first month, 4% recurring.

Penny floor: every paid conversion credits a minimum of 1¢ — even a $0.10 Single-Session sale shows up as > 0 on the dashboard, never as zero.

One-off bounties
Stack on top of recurring commissions. Each deliverable pays once per partner per key.

  • Featured tweet

    One post on X highlighting SpinGate, pinned for 7 days.

    $25 USDC

  • In-depth review

    Newsletter issue or 800-word+ blog post covering pricing & hands-on experience.

    $100 USDC

  • Dedicated video

    Stand-alone video walking through the tunnel, the checkout, and one funded session.

    $200 USDC
§ 2 · Payout cadence

Verified-claim payout mechanic.

A payout is not a balance — it's a verified claim moving through a fixed pipeline. The pipeline end-to-end, from your link to the on-chain settlement:

From your link to a payout row. A click on /r/<code> writes a PartnerClick row (hashed UA / IP only, no PII) and sets the partner_ref cookie — HttpOnly, SameSite=Lax, with a 30-day Max-Age. When the visitor pays, the webhook bridge converts that click into a unique PartnerConversion row, locked by PartnerClick.convertedInvoiceId @unique so no double-credit is possible. At cycle close, the cycle-aggregated amount lands as a PartnerPayout row in the admin payout queue.

Payout state machine. Every PartnerPayout row moves through one of these states: awaiting_approval (manual approval gate when the cycle-aggregate + trailing 30-day commission crosses the PAYOUT_APPROVAL_* thresholds), pending (broadcast about to fire), confirmed (on-chain presence probe via probeEthTx / probeBtcTx succeeded), sent (single timestamp flip after confirm; no second broadcast), and failed (after 3 attempts; surfaced for manual /requeue). The dry-run fork lands on dry_run_pending_review when PAYOUTS_DRY_RUN=true — the would-be tx is built but not broadcast, and attemptCount is not bumped.

Kill-switch posture. PAYOUTS_KILL_SWITCH=true halts non-terminal rows (pending and dry_run_pending_review) and surfaces { error: 'payments_disabled' } from the admin send handler. Already-terminal rows (sent, failed) are not retroactively reversed — this is a defensive posture, not a service-level promise.

No-claim-no-payout guarantee. No PartnerConversion means no balance accrues, means no PartnerPayout.amountUsdCents, means no row in the admin queue for that cycle. The conversion count is the denormalised counter on the Partner.conversionCount write path — balance cannot grow without one.

Transparency link. See how payouts move through the queue.

Per-chain rails
Destination chain → commission currency it carries. Each rail has its own attestation path; not every chain is also a commission-currency option at signup.
  • ETH row: carries ETH and USDC (USDC is ERC-20 on the same payoutDestEth address, same signer).
  • BTC: bech32 only (/^bc1[0-9ac-hj-np-z]{6,87}$/); the contract layer rejects legacy 1… / 3… addresses by brand posture.
  • SOL: supported as a destination chain (registered in payoutChainEnum), but not a commission-currency choice at signup.

Per-chain envelope

  • ETH
  • SOL
  • BTC

Commission currency is BTC, ETH, USDC — picked at signup, switchable from your dashboard. In-flight payouts remain in the currency they were scheduled in; switching affects future settlements only.

§ 3 · Payment rails & no-KYC

On-chain settlement, no custodian, no KYC.

The operator runs its own hot wallet and signs payouts directly. There is no third-party payout processor between your wallet and ours — and no identity check required to receive funds.

On-chain only
We sign and broadcast the payout ourselves to the address you file at signup. Switching your wallet address mid-cycle updates future sends only — queued payouts continue to the address on file at schedule time.
No KYC
We do not request passport, ID, address proof, or any government identity. The payout wallet is the only thing you give us; the partner agreement is the rest.
Hot-wallet posture
The operator hot-wallet signs partner payouts directly. When a cycle-aggregate crosses the PAYOUT_APPROVAL_* thresholds, the row lands in the § 2 awaiting_approval state until an operator signs off — operational hygiene, not a per-transaction delay you can plan around.

Tx hash & status: every successful payout carries an on-chain transaction hash surfaced on your dashboard. A failed send is retried on the next cycle at no commission cost to you; we do not charge back a commission on a buyer-side refund unless the underlying invoice is reversed.

§ 4 · Link attribution & privacy

30 days.A cookie. Nothing else from the visitor's browser.

Attribution is anchored to a single first-party cookie carrying only your partner code. The visitor's raw user-agent and IP are never stored — they are hashed with a per-deploy pepper and truncated to a 16-character fingerprint for uniqueness checking only.

What we collect
The minimum needed to credit you without leaking visitor identity.
  • partner_ref cookie:your 8-character partner code, set on the visitor's browser via /r/<code>. Lifetime 30 days; no raw UID, no user-agent, no IP.
  • Server-side fingerprint: SHA-256(UA + IP + pepper), truncated to 16 hex chars. Pepper is per-deploy and rotates with our infrastructure — the same UA pattern shared by many visitors does not re-bucket without it.
  • Zero PII: no name, email, payment data, or device identifier is stored against the click row. Attribution is a cookie + a hash, both stamped against the same partner code.
§ 5 · Eligibility & termination

We may decline, suspend, or close a partner account.

Partner status flows through a small fixed state machine: an application starts at pending_approval and transitions to approved, denied, or post-approval suspended. The transition rules are below; the dashboard renders your live status.

Denied at application (denied)
An application is declined before approval. We may deny a partner for, but not limited to:
  • Fraud indicators on the outlet: inflated audience metrics, paid-follower composition, or unverifiable reach claims.
  • Audience-policy violation: off-brand verticals that conflict with the operator's privacy-first positioning.
  • Repeat chargeback abuse: a pattern of attributed conversions that are reversed post-payment.
Suspended post-approval (suspended)
An approved partner may be moved to suspended at the operator's discretion. Grounds include:
  • Click injection / cookie stuffing: mechanical or scripted attribution on traffic you didn't actually send.
  • Attribution abuse: claiming conversions via undisclosed paid placements or cross-channel arbitrage.
  • Brand-safety events:coverage or placement we consider materially harmful to the operator's positioning.
  • Voluntary cancellation by you: a partner may close their account at any time, with already-accrued commissions settling on the next cycle.

Plain-English summary: we may suspend or decline a partner for the lifetime of their account, and we may close a partner dashboard at any time. The full operator-controlled status set we expose is pending_approval | approved | denied | suspended; suspended and denied partners lose access to the dashboard and are not eligible for further payouts.

§ 6 · General

Operative agreement.

This page — together with the commission figures you see when you apply, the cookie lifetime on your referral link, and the payout currency you select at signup — is the operative agreement between you and SpinGate governing your participation in the partner program. No other representation, marketing copy, or sidebar term controls.

We may amend this agreement at any time. Material changes (a tier default change, a payout-currency change, a cookie-lifetime change) will be reflected here; continued participation after a posted change constitutes acceptance.

Questions, disputes, or terminations requests: Join the waitlist. Looking for a quick answer? See the FAQ.

Last updated: 2026-07-23. Questions? Join the waitlist. This page is user-owned static content; commission figures are sourced from the webhook handler at render time.

Tiers rendered: standard · featured · super_affiliate. Payout currencies: BTC · ETH · USDC. Chains rendered: ETH · SOL · BTC.