For publishers

Ship a module. CheatersX handles the rest.

Build with the C++ SDK, publish through a reviewed pipeline, and reach members who already live in the hub.

A product sits on a game. Versions move from draft to live on a channel. Module bytes are stored and delivered encrypted. The loader is a separate binary; members launch entitled products from there.

Platform surface

You ship the module. The hub already has the rest.

Accounts, listing, seats, chat, and encrypted delivery stay on CheatersX. Integrate the SDK and stay on the product.

  • C++ module contract

    Integrate the CheatersX SDK and ship a module. Stay on the product; the hub owns accounts, listing, and seats.

  • Catalog and users

    Products, games, and member accounts are platform surfaces. You do not build a second store or identity stack.

  • Seats and plans

    Price a product directly, or let a platform plan cover it by monthly price band. Checkout stays on CheatersX.

  • Live chat

    Members already have hub chat. Hook the room; do not ship a messenger.

  • Encrypted packaging

    You upload a module. The platform stores it encrypted, hashes it, and delivers it only to an entitled session.

  • Channels and allowlists

    Up to ten channels per product. Scope a channel to you only, an allowlist, or the public catalog.

C++ SDK

The SDK is how you build a CheatersX module. The platform already has accounts, catalog, seats, and chat. You do not stand up a second store.

SDK to live members

  1. 01

    Build with the SDK

    Integrate the C++ SDK and produce a module.

  2. 02

    Upload on a version

    Attach the module to a draft. Bytes are hashed and stored encrypted.

  3. 03

    Live for entitled members

    After checks and operator accept, members launch it from the loader.

How publishing works

A version is never live on upload. Draft, encrypt and store, submit, required checks, then an operator accept. Failed required checks reject. There is no auto-accept. The loader exe is a different release track.

Version pipeline

  1. 01

    Create a product

    Attach it to an existing game. Fill catalog fields and prices.

  2. 02

    Open a channel

    Max ten. One default. Scope: publisher only, allowlist, or public.

  3. 03

    Draft a version

    Semver on that channel. Draft only; nothing is live yet.

  4. 04

    Upload the module

    Multipart upload. Content hash. Encrypted object store.

  5. 05

    Submit for checks

    Required checks must pass or skip. Failed required checks reject.

  6. 06

    Operator review

    Accept makes it live on that channel. Reject lets you draft that number again.

Games and products

Games are the catalog root. Products nest under a game. Channels carry access scope and allowlist. One live version per channel.

  • Game management

    Games are the catalog root (name, slug, optional variant). Operators own the game list. You pick a game when you create a product.

  • Product management

    Catalog fields, prices, channels, versions, allowlist, changelog. Product bans are yours or ops. Private listings stay off the public storefront.

  • Who can launch

    A ban always wins. Channel scope decides who sees the live version. A platform plan can cover a monthly price band. Private access is a separate door.

  • Loader is a separate track

    The member loader binary is published and activated on its own history. Product modules never ship inside that exe.

Catalog nest

  1. 01

    Game

    Catalog root. Optional variants under a parent. Operators maintain the list.

  2. 02

    Product

    Your listing: name, copy, tags, features, prices. Nested under a game.

  3. 03

    Channels

    Distribution tracks. Allowlist lives on the channel and survives a version bump.

  4. 04

    Versions

    One live version per channel: published and active. Drafts stay off the catalog.

Loader delivery

Members download a single active loader. That binary is not your module. When they launch, the platform checks ban, entitlement, and channel scope, then delivers an encrypted artifact over a bound session. Integrity is verified before the session is prepared.

  • Encrypted at rest

    Uploaded modules sit in object storage as encrypted artifacts. Publishers do not handle delivery keys.

  • Encrypted in transfer

    A launch pulls ciphertext over an authenticated session. Clear module bytes are not a public download.

  • Integrity

    A content hash is taken on upload. The loader verifies integrity before a session is prepared.

  • Session bound

    A load is tied to an entitled member session. It is not a durable public URL.

Encrypted delivery

  1. 01

    Entitled launch

    A member picks a product they can use. Ban, seat, and channel scope are checked first.

  2. 02

    Bound session

    The platform issues a short-lived load bound to that member session.

  3. 03

    Encrypted artifact

    Module bytes travel encrypted. Integrity is proven before the loader prepares the session.

  4. 04

    Ready in the loader

    The member launches from the desktop hub. Delivery crypto stays on the platform.

Delivery crypto and session binding stay on the platform. Module bytes are not a public download.