# Compliance Checklist

Regulatory and tax surfaces that fall on the marketplace operator, not on Guild. Review with counsel before launch.

> This document is practical guidance, not legal advice. Jurisdictions vary. Get professional review.

## Summary of what you own

| Surface | Your responsibility | Guild's role |
|---|---|---|
| Tax reporting to users (1099-NEC, 1099-K) | Yes | Provides per-user settled-earnings ledger via wallet API |
| Multi-level payout registration (state-level) | Yes | Provides the structure; you decide whether to register |
| FTC material-connection disclosure on user-shared copylinks | Yes | Provides the link; you surface disclosure copy |
| Money transmission compliance | Yes (operator's Stripe Connect account is the transmitter) | Guild never holds user funds; Stripe is the licensed transmitter |
| Anti-fraud screening on users | Yes | Provides event data; you act on it |
| Terms of service and privacy policy that cover the program | Yes | Not provided by Guild |

## Tax reporting (US marketplaces)

### The issue

User reward payouts flow from your Stripe connected account to users. You are the payer of record, not Guild.

### What that means in practice

Under current US rules (2026):

- **1099-NEC** is generally required for non-employee compensation of $600+ per year to US individuals treated as contractors. Reward payouts to sharing users often qualify.
- **1099-K** thresholds continue to shift at the federal level; stay current with IRS guidance.
- Even if the threshold isn't met, you still want **W-9 collection** at the time users onboard into the rewards program, so you have what you need if they cross the threshold later.

### Actions to take

- [ ] Have your accounting firm confirm which 1099 form(s) apply to your program structure
- [ ] Collect W-9 from US users before they earn payable balances (consider implementing before enabling withdrawals)
- [ ] Build or buy a 1099 generation workflow that can query Guild's per-user settled-earnings via the wallet API
- [ ] Budget for annual 1099 filing and any required back-up withholding on users who refuse W-9
- [ ] For non-US users, consult counsel on local equivalents and treaty withholding

## Multi-level payout structure

### The issue

The Guild token model awards tokens along a referral chain:
- 5 tokens to the direct referrer of each participant (buyer and seller)
- 1 token to each ancestor in the chain, up to `max_depth` (default 2, configurable up to 3)
- 2x multiplier for new users on their first 3 settled earning events

This is mathematically a 3-level-deep payout structure. In several US states this triggers specific compliance obligations.

### States with active MLM/pyramid-scheme-adjacent regulation

Not exhaustive. Confirm with counsel. Representative examples:

- **Wyoming** — registered seller disclosure rules
- **Montana** — specific registration for multi-level marketing
- **Georgia, Maryland, Massachusetts** — various disclosure and cooling-off obligations
- **Federal FTC Business Opportunity Rule** — applies if you cross certain definitions

### What regulators typically look for

- Users earn primarily from the **transactions** generated by their downlines, not from recruiting itself
- No "pay to play" — users do not buy their way into the earning program
- Clear disclosure of typical earnings (or realistic range) in any marketing copy
- Cooling-off or refund rights if applicable

The Guild model is designed to satisfy (1) and (2): rewards trigger only on **settled commission**, not on signups, clicks, or copylink opens. Users pay nothing to earn. But (3) and (4) — income representation and disclosure — are your responsibility in your marketing copy.

### Actions to take

- [ ] Have counsel review the payout structure (3-deep, 5/5/1 tokens, 2x bonus) against your go-live states
- [ ] Prepare income representation language — typical earnings range, not best-case
- [ ] Register where required before marketing the program
- [ ] Ensure your referral-program marketing copy does not describe it as "recruit friends to earn money" — frame it as "share when users transact, earn when settled"

## FTC material-connection disclosure

### The issue

When a user shares their Guild copylink to friends, colleagues, or followers, they are making an implicit endorsement with a financial upside. Under FTC Endorsement Guides (16 CFR Part 255), material connections must be disclosed.

### What Guild provides

The hosted copylink pattern (`/join?tenant=X&ref=Y`) contains no disclosure copy. Guild does not require users to make disclosures when sharing their link.

### Your responsibility

- Explain in your terms of service that users who share the link are making an endorsement for financial consideration and should disclose
- Provide suggested disclosure language (e.g., "I may earn rewards when you sign up") in user-facing share UI
- Avoid operating the program in a way that relies on non-disclosure (e.g., don't instruct users to hide that they're referrers)

### Actions to take

- [ ] Add user-facing copy in your app's share UI that reminds users to disclose
- [ ] Add a terms-of-service section covering referral program endorsements
- [ ] If influencers or paid partners use the program, require explicit disclosure on every share

## Money transmission

### The issue

Aggregating user-earnable balances and paying them out to users can trigger money-transmitter registration in some jurisdictions.

### How Guild is structured to address this

- Guild never holds user funds
- User payouts (when enabled) are executed as `stripe.transfers.create()` from your Stripe connected account to users' Stripe Express connected accounts
- Stripe is the licensed money transmitter
- Guild's own Stripe balance only ever holds protocol fee revenue

### Your responsibility

- Your Stripe Connect account must be in good standing and properly KYC'd
- If you're running user-earnable balances denominated in a way that could be construed as "stored value" (e.g., a points wallet usable elsewhere), consult counsel
- In the Guild model, the token system is an accounting unit that converts to cents on daily settlement — not stored value with independent utility — which typically avoids money-transmitter concerns, but get legal sign-off

### Actions to take

- [ ] Confirm your Stripe Connect setup is production-grade (not sandbox)
- [ ] Have counsel confirm your token/reward surfaces do not qualify as stored value
- [ ] Review user-facing wallet copy to avoid "stored value" implications (Guild's hosted `/wallet` page uses "balance" language — if you surface your own wallet UI, mirror that)

## Anti-fraud screening

### The issue

Any rewards program attracts abuse: fake users, self-referrals (blocked by Guild), ring-farming, chargebacks on "settled" transactions.

### What Guild provides

- Self-referral skipping in chain traversal
- Idempotency enforcement to prevent duplicate mints
- Reversal handling: negative token award and reversal journal on refunds/chargebacks
- Stytch SMS OTP as the auth gate (harder than email for mass fake signups)
- Immudb event trail for forensic review

### Your responsibility

- Decide whether a user is a valid participant (e.g., not a known bad actor on your marketplace)
- Call `reverseTransaction` when you identify fraudulent commission
- Monitor for unusual referral-chain patterns (many accounts sharing the same device, IP, or signup timing)
- Share fraud signals with the Event Hub if your setup participates in network-wide trust

### Actions to take

- [ ] Decide your policy on duplicate-account detection (same phone, same device, same household)
- [ ] Build an internal workflow to call `reverseTransaction` on confirmed fraud
- [ ] Review referral-chain depth distributions monthly for anomalies

## Privacy and data handling

### What Guild stores

- Phone number (hashed SHA-256)
- `guild_user_id`, `tenant_user_id`, `referral_code`
- Referral graph edges (`REFERRED_ON {tenant_id, at}`)
- Settled transaction records (`tenant_id`, `platform_commission_cents`, `settled_at`)
- Wallet ledger entries
- Immudb event chain

### What Guild does NOT store

- Transaction-level PII beyond participant IDs
- Payment card data
- Conversation or session content from your marketplace
- Anything beyond what you explicitly send in `POST /v1/transactions`

### Your responsibility under GDPR / CCPA / analogous laws

- Disclose in your privacy policy that user phone numbers and transaction settlement events are shared with The Guild
- Implement data-subject access and deletion requests that account for Guild as a processor
- Guild supports data deletion via identity removal flows (see Event Hub `user.deletion_requested` event); you must initiate

### Actions to take

- [ ] Update your privacy policy to name Guild as a sub-processor
- [ ] Build a deletion request workflow that triggers Guild deletion via your app's normal GDPR/CCPA flow
- [ ] Ensure DPAs with Guild are in place before you go live

## Pre-launch compliance checklist

Use this as a gate before enabling the program in production:

- [ ] Legal review complete on multi-level payout structure for target states
- [ ] Tax reporting workflow designed (W-9 collection + 1099 generation)
- [ ] FTC disclosure copy added to share UI and terms of service
- [ ] Money-transmission posture confirmed with counsel
- [ ] Privacy policy updated; DPA executed with Guild
- [ ] Fraud response workflow ready (`reverseTransaction` path wired up)
- [ ] Income representation language reviewed for any marketing of the program
- [ ] User-facing `/wallet` state transitions communicated (display-only during v1, cash-out when enabled)

Sign off on all items before enabling transactions in production.