# Network Participation When you integrate Guild, your marketplace is not just adopting a referral engine — you are joining the **Serendipity Network**, a portfolio-wide trust graph that spans every marketplace in the Guild ecosystem. This page is an honest account of what that means today, what it means next quarter, and why participating early compounds in your favor. --- ## What is the Serendipity Network? A canonical, real-time graph of trust-bearing signals emitted by every participating marketplace in the portfolio. It catalogs: - **People** (identity-resolved across apps via verified phone / email) - **Relationships** (`REFERRED`, `KNOWS`, `PARTICIPATED`, `ENGAGED`, ...) - **Events** (settled commissions, verified signups, consent changes) - **Anchors** (immutable references back to the marketplace of origin) Every Guild marketplace emits into this graph. Every Guild marketplace will be able to read from it. --- ## What's wired today (v1, shipping) Your Guild integration **contributes** to the network automatically. You do nothing extra. Every time one of these happens on your marketplace, Guild emits a canonical v3 event to the Serendipity Event Hub through a durable outbox: | Action on your marketplace | Event emitted | Graph impact | |---|---|---| | User joins via `POST /v1/users/link` | `user.signed_up`, `user.verified` | Person node resolved/created, `IDENTIFIED_BY` edges | | User joins via copylink | `relationship.observed` (type: `REFERRED`) | `REFERRED` edge between referrer and new user | | Commission settles via `POST /v1/transactions` | `entity.observed` (settlement event) | Settlement `Event` node with tier classification | | Referral chain extends | `relationship.observed` per ancestor | Multi-hop `REFERRED` chain recorded | **Key properties of the emission path:** - Atomic with your business write (same DB transaction — no partial states) - Fire-and-forget on the network side (a Hub outage never blocks your API response) - Type-checked at compile time (`PayloadFor` — malformed payloads fail the build) - Identity resolved through platform identity (same person across Guild marketplaces is the same graph node) You can verify this yourself: grep `apps/backend/src/service-referral-events.ts` in the Guild codebase. The emitters are three small functions, not a black box. ### What contributing gets you *today* Immediate, even without any read integration: - **Portfolio-wide identity**: a user who already verified on *another* Guild marketplace is recognized on yours on first signup. No re-verification friction. - **Cross-marketplace anti-fraud posture**: bad actors flagged on one Guild marketplace raise trust-graph signals visible to ops across the portfolio. You inherit the network's negative-signal detection. - **Durable history**: your marketplace's contribution to the graph is immutable. When read-side capabilities ship, your data is already in place — earliest contributors have the richest starting position. --- ## What's coming (committed roadmap) The network's read-side capabilities are a formal committed work item. See **[Network-Derived Recommendations PRD](../prd/Network-Derived%20Recommendations%20PRD.md)** for the full specification. Summary: - **`GET /v1/network/signals`** — trust-graph context for a user on your marketplace (cross-marketplace activity summary, reputation score, connection density) - **`GET /v1/network/recommendations`** — surfaced candidates (users similar to your high-LTV cohort, in-network referral suggestions) - **Network-aware bonus multipliers** (optional) — operators who want to use high-contribution users' reputation signal to set starting token velocity for new signups - **Cross-marketplace reputation in the ops console** — see at a glance whether a flagged user has a broad portfolio history or is a first-time appearance Adds `@platform/sdk` to the Guild backend, defines the query surface, wires tenant-scoped access control, ships. --- ## Why this grows in value The network's utility to you is roughly a function of: 1. How many marketplaces are emitting (portfolio growth) 2. How much history has accumulated (time since your integration) 3. How sophisticated the read-side surface is (roadmap delivery) All three vectors point the same direction. **The network is more valuable next quarter than this quarter, and more valuable next year than next quarter.** The operators with the richest network picture when read APIs ship will be those who integrated earliest — their users are already resolved, their referral chains already in the graph, their settled-commission history already anchored. --- ## Data boundaries — what stays yours Joining the network does **not** mean your data is visible to other marketplaces. - Your referral graph edges, commission history, and wallet ledger remain **tenant-local**. Other marketplaces cannot read them. - What the network sees is **canonical, de-identified graph structure** — that a `Person` node exists, that they have a `REFERRED` relationship, that they `PARTICIPATED` in a settlement event of a certain tier. Not your `platform_commission_cents` values, not your internal user IDs, not your marketplace's take rate. - Identity resolution is one-way: the network knows a user by their `global_user_id`; your marketplace knows them by your `tenant_user_id`. The mapping is only traversable with your API key. - See the [FAQ on data sharing across marketplaces](./faq.md#is-user-data-shared-across-marketplaces-in-the-portfolio) for specifics. If your legal or BD posture requires contractual limits on network participation, tell us before launch. We can scope emission by event type on a tenant basis. --- ## What you should do **Today:** nothing. Network emission is already wired into your integration. If you're sending `POST /v1/users/link` and `POST /v1/transactions` correctly, you're contributing. **Before launch:** review the [event-hub-integration spec](../prd/event-hub-integration.md) with your security and legal team if they want to understand what data leaves Guild's boundary. **When read-side capabilities ship:** opt into the endpoints that make sense for your marketplace. None are forced. The baseline Guild integration continues to work identically even if you never touch the network read APIs. --- ## Questions - *"Can I opt out of network emission?"* — Yes, on a contractual basis. Ask us. Note you would forfeit portfolio-wide identity and cross-marketplace anti-fraud benefits. - *"Who else is emitting?"* — We can share the current portfolio under NDA. Ask us. - *"Does this affect my compliance posture?"* — Marginally. The network does not change what Guild stores or who owns user data (you still do). It does mean canonical trust signals derived from your marketplace are emitted to a shared graph. If your privacy policy doesn't already cover "we participate in a cross-marketplace trust network for referral integrity," update it. Review with counsel. For anything else: `support@guildapi.dev`.