# Risks & Responsibilities What Guild handles, what you still own, and where the edges are. Read this before you start integration work. ## What Guild owns - Referral graph construction and traversal - Token minting math and daily settlement - Wallet ledger with append-only journal entries - Hosted `/join`, `/login`, `/wallet` pages for your users - Immudb evidence trail and monthly WORM snapshots - Protocol fee invoicing via Stripe - Event Hub emission for network-wide identity and trust signals ## What you still own These are not limitations of Guild — they are inherent responsibilities of any marketplace running a rewards program. ### You are the payer of record for user rewards User payouts (when Stripe Connect withdrawals ship — see [Launch Readiness](./launch-readiness.md)) are executed as `stripe.transfers.create()` from **your** Stripe connected account to each user's Stripe Express account. Guild issues the instruction; Guild never holds user funds. This means: - Your accounting team needs to know that reward payouts flow from your books, not Guild's - **US marketplaces likely owe 1099-NEC or 1099-K to users earning >$600/year.** Guild does not issue these. - Your finance team should model reward payouts as a COGS or marketing expense, not a platform fee See [Compliance Checklist](./compliance-checklist.md) for full detail. ### Compliance and legal review before launch The referral structure (direct referrer + ancestor chain up to 3 levels, with 2x bonus for new users' first 3 earnings) is a multi-level payout structure. In several US states this triggers registration or disclosure obligations. Have counsel review before you market the program to your users. ### Communicating launch-specific dynamics to your users The 2x bonus multiplier on users' first 3 settled earnings means early-period reward payouts are roughly 2x steady-state. Budget accordingly and, if you communicate reward rates publicly, either quote the steady-state rate or explain both. ### Retry queue around `POST /v1/transactions` Guild's `report_transaction` call is designed to be fire-and-forget from the marketplace's perspective — we never block your user flow. The tradeoff: if Guild is briefly unreachable, the call must be retried by your system. You must implement a local retry queue or outbox so settled commissions don't silently drop during a Guild outage. The [retry example](../../examples/retry-queue/) shows the recommended pattern. ### Idempotency key discipline Every `POST /v1/transactions` must include a stable `idempotency_key` that is **deterministically derived from your own transaction identifier** — not a timestamp, not a random UUID. See the [Marketplace Onboarding Guide](../onboarding/marketplace-onboarding.md) for the exact rule. Guild enforces uniqueness on `(tenant_id, idempotency_key)`. A non-deterministic key will either silently duplicate mint (different key → new row) or silently drop correct retries (same wrong key → treated as duplicate). ## Current platform limitations Capabilities that are specified but not yet shipped. These are not hidden — we want them surfaced. ### No outbound webhooks yet Guild currently has no mechanism to push state changes to your system. You must poll `GET /v1/wallet/:id` (or the operator-facing admin endpoints) to see changes. **Impact:** you cannot trigger your own notifications, fraud checks, or accounting entries in real time on Guild events. **On the roadmap:** [Outbound Webhook Subsystem PRD](../prd/Outbound%20Webhook%20Subsystem%20PRD.md). ### Referral graph is not exportable yet The referral graph your users build on your marketplace lives in Guild's Neo4j. There is no `GET /v1/tenants/:id/export` endpoint today. **Impact:** if you ever chose to leave Guild, you would not be able to take the graph with you. **On the roadmap:** [Tenant Graph Export PRD](../prd/Tenant%20Graph%20Export%20PRD.md). ### Fixed protocol fee rate The 9%-of-commission protocol fee is the same for every marketplace. There is no per-tenant negotiation today. **Impact:** enterprise-scale operators used to custom SaaS deals may find this rigid. **On the roadmap:** [Per-Tenant Rate Negotiation PRD](../prd/Per-Tenant%20Rate%20Negotiation%20PRD.md). ### SMS-only authentication for end users User auth on the hosted `/join` and `/login` pages is phone-based (SMS OTP via Stytch). **Impact:** users without reliable SMS delivery (some international markets, VoIP numbers, users unwilling to share phone) cannot participate. The marketplace bears the SMS cost and drop-off. **On the roadmap:** email and social-login alternatives are being scoped but not yet committed. ### Dependency on `guildapi.dev` The hosted `/join`, `/login`, and `/wallet` pages are served from `guildapi.dev`. If Guild has downtime, those pages are affected. **Impact:** your users hit a broken page branded with your marketplace's name. **Mitigation today:** Guild targets 99.9% availability for core paths (see [SLA](./sla.md)). Planned: status page and user-facing incident communication. ## Decision framework Integrate The Guild if: - You run a marketplace where settled commission is a clear, discrete cash event - You want a white-labeled rewards loop without building auth, ledgers, reversals, idempotency, and settlement yourself - You are comfortable owning the tax/compliance surface described above - You can tolerate polling and manual incident awareness in v1 Hold off if: - You need real-time push notifications of reward events right now - You need a custom protocol fee rate - Your users cannot authenticate via SMS - You cannot complete a compliance review before launch