Guild.xyz

  • Name: Guild.xyz
  • URL: https://guild.xyz/
  • Category: membership-policy operator / community-access and identity-aggregation company / cross-platform role-sync middleware company
  • Tags: ethereum-ecosystem
  • Summary: Guild.xyz belongs in companies/ because the useful control-surface question is not only how a role requirement works inside guild. A named service provider runs the hosted profile graph, linked-identity aggregation, admin API, reward-sync workflow, analytics, billing, and legal/data-processing shell around those rules. The practical leverage sits in who decides supported integrations, profile and guild-admin workflows, private member-data visibility, hosted sync behavior, and subscription / communications defaults — not only in what a role can express.
  • What it does:
    • Operates the hosted Guild platform for creating, administering, and joining token-gated or proof-gated communities across Discord, Telegram, X, GitHub, Farcaster, email, and wallet-linked identities
    • Maintains the profile layer that links wallet addresses and social identities so guild admins can treat one member as a cross-platform account rather than a set of disconnected handles
    • Ships the API and SDK surface for creating guilds, roles, requirements, rewards, points systems, admin lists, and membership checks from application code
    • Packages quests, analytics, points, rewards, and access management into one operator-controlled community workflow instead of leaving those as neutral onchain primitives
    • Controls the privacy, billing, communications, and subprocessor shell around the platform, including which third-party infrastructure and indexing providers sit underneath the product
  • Key claims:
    • The homepage says Guild is one platform with 100+ integrations designed to scale from 100 to 1 million members, which is a strong first-party signal that the important dependency is a hosted operator stack rather than only a requirement engine
    • The docs say Guild helps projects see members’ wallet addresses and linked social accounts in one place, manages Discord and Telegram access, runs quests, and provides analytics, which makes the operator-controlled identity and data layer explicit
    • The Terms of Use say the services are provided by Z Gen Kibernetika Korlátolt Felelősségű Társaság and that guild creator onboarding may require a Google account or verified email address, which is a clear sign that access and administration are mediated by a named service provider rather than only by wallets
    • The same terms say the service provider may update the services, modify features and functionality, and revise the agreement by posting modified terms on the website, which is an important company-shaped control surface around communities that depend on the hosted stack
    • The Privacy Policy says Guild processes connected identity data, social-account data, membership information, blockchain information, billing data, and usage data, and may share data with guild owners and service providers; that makes the company boundary analytically useful in a way the product note alone cannot capture
    • That same policy names concrete infrastructure and workflow providers including Railway, Cloudflare, Sentry, PostHog, Intercom, Resend, Alchemy, Pinata, Stripe, and Coinbase, which is a good reminder that Guild’s community-control layer is partly a vendor-composed hosted service
    • The SDK README exposes guild creation, update, deletion, join, access checks, admin listing, role and requirement management, reward management, and points / leaderboard APIs, confirming that Guild.xyz is operating a real admin control plane rather than a thin website in front of static token checks
  • Whitepaper: No classic standalone Guild.xyz company whitepaper is the point here. The strongest primary materials were the official site, docs, legal/privacy pages, and SDK materials captured in ../whitepapers/guild-company-primary-sources-2026-08-12.md.
  • Sources:

Internal linkages

  • Product-layer note: guild.
  • Useful adjacent operator-shell comparisons where hosted identity, onboarding, or account policy matter separately from lower-layer primitives: reown, privy, and dynamic.
  • Nearby mechanism and electorate-shaping contrasts: hats-protocol, census3, and common.

Protocol / company boundary

  • Keep projects/guild focused on the product layer: requirements, role logic, rewards, continuous syncing, and the practical way Guild maps proofs and identities into community privileges.
  • Keep this note focused on the named operator boundary that hosts the profile graph, manages supported integrations, controls the admin and member-data surface, defines the legal/privacy shell, and packages quests, analytics, billing, and communications around the rules engine.
  • That split matters because how does Guild express access policy? and who operates the identity, sync, and data-processing shell around that policy? are related but not identical questions.

Control surface

  • Practical leverage sits in which identities and third-party platforms Guild supports, what private member data guild admins can access, how often membership and reward syncs run, which analytics and quest surfaces are bundled into the dashboard, and how the service provider changes features, pricing, or policy over time.

  • The sticky dependency is not only the role logic. It is the company-run profile and sync shell that many communities treat as the source of truth for access, rewards, and member legibility across platforms.

  • Read Guild.xyz as hosted community-policy infrastructure first. The composable rule engine is real, but the operational authority sits with the company that runs the account, data, and integration boundary around it.

  • Last reviewed: 2026-08-12 UTC