PolyGame: teardown of a creator-token game-streaming platform
PolyGame is a mobile esports game-streaming platform built "for streamers, by streamers." Every streamer and team gets its own tradeable Social Token, and viewers earn that token by engaging. It runs on Polygon and served a community of more than 700,000 monthly active users. The chain itself was rarely the difficult part. The data that priced every token, engagement, lived off-chain, so the whole economy ran off-chain and settled to Polygon in batches. On top of that, a custom player spliced ads and overlays into live streams without a visible cut.
Snapshot
| What it is | Mobile esports game-streaming platform with per-streamer/team Social Tokens (fan tokens), a central platform token (PGM), and a roadmap into NFTs and token-gated access |
| My role | Tech lead: architecture, all backend and microservices, Polygon/ethers integration, streaming and DevOps, UI wireframing |
| Team | 4 people: lead (me), one frontend dev, one designer, one partner handling client comms and ideation |
| Domain | Web3 creator economy and live esports streaming |
| Core stack | Node.js + Express (custom MVC) · microservices · MongoDB · Redis · React · Ionic Capacitor · Tencent Cloud (compute + CSS/VOD/IM) · ethers.js (Polygon) |
| Clients | Web (React) + iOS + Android from one Capacitor codebase |
| Chain | Polygon PoS, with balances settled in batches on top; gas paid in MATIC. Roadmap: a dedicated app-chain ("Polygem") via the Polygon SDK |
| Infra / CI/CD | Whole stack on Tencent Cloud; services containerized with Docker; pipelines run through GitHub Actions |
| Scale | More than 700,000 monthly active users and 60+ streamers (official figures, January 2022) |
| Footprint | First launched in Indonesia (2021); India and Taiwan targeted for Q3 2022 |
| Built | Roughly 2 months to MVP, then another 5 to 6 months of features, testing, and optimization; announced January 2022 |
The problem
The product bolts a full token economy onto a live esports-streaming app. The pieces:
- A Social Token minted for each streamer or team on verification, split between the creator and a contract-held reserve that pays viewers for engagement.
- A central PGM token that Social Tokens trade against, which also rewards creators.
- Social-token prices that move with viewership and engagement.
- An exchange (Social Token to PGM to external currency) and staking with its own ROI rules.
- Monthly reward distributions to creators and viewers.
- Creator and viewer dashboards and leaderboards, plus an admin console with role-based access.
- A live player with breaks, conditional preset clips and ads, in-video banner ads, live chat, and moment reactions.
- Token-gated perks on top: private streams, invite-only events, exclusive gameplay.
The hard part is in the constraints:
| Constraint | Why it bites |
|---|---|
| Engagement is high-frequency and off-chain | Every view, watched second, reaction, and chat message feeds both price and rewards |
| On-chain writes, even on Polygon | MATIC gas is low, not zero; thousands of monthly micro-rewards still add up, and per-action confirmation latency plus nonce management don't scale |
| Micro-rewards | Paying for engagement monthly across 700,000+ users means a flood of tiny balance changes |
| Read-side math | Dashboards aggregate large engagement histories on every page load |
| Small team, three platforms | Web, iOS, and Android from a three-person core |
In 2022 the reflex was to put it on the blockchain. That fails here for several reasons at once. The chain can't read off-chain engagement in the first place. Even if it could, absorbing a write per engagement at this volume would pile up costs fast, and on-chain confirmation is far too slow for the instant feedback a viewer expects. Polygon makes each write cheap, but cheap is not free, and a continuous stream of writes bleeds you slowly. A chain is a settlement layer rather than a database, which is a lesson plenty of teams in this space pay for. A cheaper chain alone does not solve this. The economy has to live where its data already lives, and the chain handles the one thing it does well: recording final ownership and settling balances.
The architecture
One decision drives the rest. Engagement is the signal that both prices the tokens and earns the rewards, and engagement only exists off-chain. So the economic engine runs off-chain in Node, MongoDB, and Redis. That engine covers the ledger, the pricing oracle, the exchange, staking, and the reward epochs. Polygon holds token ownership and receives the economy's net results in periodic batches. Between those batches the platform is custodial: it owns the books and owes users a reconciliation back to the chain that they can verify. The pattern is off-chain compute with on-chain settlement, the same shape a centralized exchange uses when it nets positions internally and settles to a clearing layer. The batching still holds on Polygon. Cheap gas lowers the cost of getting something wrong, but it does not justify putting a continuous reward stream on the chain.
The other choices all follow from it.
| Decision | Chose | Over | Why | Cost / watch-item |
|---|---|---|---|---|
| Where the economy runs | Off-chain ledger; batched settlement on Polygon | Fully on-chain ledger | Engagement is off-chain; gas, latency, and nonce throughput make per-action writes unworkable at 700k-user scale | Custodial trust between batches; off-chain books have to reconcile to the chain |
| Social-token shape | One ERC20 per creator, deployed as EIP-1167 minimal-proxy clones of a single implementation | Single ERC-1155 multi-token | Each token is its own asset with its own address, so it can be traded and listed on outside markets independently | Even with clones, you carry N proxy contracts to track and approve |
| Social-token price | Engagement-driven oracle, computed off-chain | AMM / bonding curve | Price should track real viewership rather than buy/sell pressure alone, which resists speculative pumps | An administered price means trusting the formula and the platform's reported metrics; the oracle is gameable if engagement can be botted |
| Backend shape | Custom MVC on Express plus many microservices | Monolith / opinionated framework | Isolate the dangerous path (the chain signer) and the heavy paths (rewards, streaming), and scale hot paths on their own | More ops surface and more inter-service contracts, which is real overhead for a one-backend-dev team |
| Clients | Ionic Capacitor: one React codebase for web, iOS, and Android | Native iOS plus Android | Three platforms from a tiny team, quickly, for a mobile-first audience | Real-time video and overlays push a webview to its limits; the player may need native bridges |
The clone factory is the part I'd point to first. Deploying the full ERC20 bytecode for every one of dozens, and eventually thousands, of creators is wasteful. Instead, one ERC20 implementation gets deployed once, and the factory stamps out roughly 45-byte minimal proxies (EIP-1167) that delegate to it. Onboarding a streamer becomes a cheap clone rather than a fresh deployment, and each token still behaves like a normal ERC20 that outside markets can trade.
The full system on one cloud. Compute, MongoDB, Redis, the message broker, and all media run on Tencent Cloud. Polygon is the only external system, and nothing user-facing writes to it. The settlement worker batches the economy's results and is the only component that touches the chain.
Two clocks: engagement now, settlement monthly
The design runs on two clocks. Engagement gets recorded and priced continuously, off-chain. Rewards, exchanges, and stake movements pile up as balanced ledger entries and reach Polygon once a month, in a single batch. That batching is what keeps gas and confirmation latency off the per-action path, and it lets the platform pay a viewer for a thirty-second watch without losing money to fees.
Two clocks. The fast one logs and prices engagement off-chain through a broker-buffered pipeline. The slow one settles balances to Polygon in bulk. The gap between them is the custodial window the platform has to reconcile.
The video player
The player was the other hard system. Integrating video here did not mean embedding a player. It meant building a control layer on top of one.
Tencent Cloud did the heavy lifting, split across a few products. CSS (Cloud Streaming Services, or LVB) took the RTMP ingest from the streamer and served HLS, FLV, and WebRTC playback over Tencent's CDN. VOD held the preset clips and ads. IM carried chat. A single player SDK sat in front of all of it: TCPlayer on web and the mobile SDK inside the Capacitor shell, playing both live and on-demand sources behind one interface.
The control layer had to handle several things. When a streamer goes on a break, whether defined or open-ended, the player asks an Ad-Decision service what to play next. That decision is made server-side from rules (viewer, break type, inventory, timing) and returns a preset clip or an ad. The player then swaps the source without a reload, preloading the next one so the viewer doesn't feel the cut, which is where CSS's seamless switching helps. In-video banners are a separate interactive layer painted over the video in DOM or canvas, kept out of the stream itself on purpose so they stay conditional and clickable. Chat and "react to the moment" run over WebSocket and Tencent IM, timestamped to the playback position, and every reaction feeds straight back into engagement ingestion.
What the video player actually had to do: decide what to show during breaks, swap sources without a visible cut, paint interactive banners on top, and feed every reaction back into the engagement pipeline.
The alternative I didn't take was server-side ad insertion (SSAI):
| Approach | Buys | Costs |
|---|---|---|
| Client-side swap and overlay (chosen) | Simpler infra; interactive, conditional, clickable banners; per-viewer targeting at the edge | Can stutter on the swap, though preloading mitigates that; overlay ads can be blocked |
| Server-side ad insertion (SSAI) | Seamless and resistant to ad blockers; ads stitched into the manifest | Heavier infra; per-viewer interactivity is much harder |
Data model
In a document store, the schema is the architecture. What you embed, reference, shard, and precompute decides whether the system holds up. The spine here is BALANCE ← LEDGER_ENTRY → SETTLEMENT_BATCH: every economic movement is a signed ledger entry, and each entry eventually gets stamped with the on-chain transaction that settled it.
The core entities. Balanced-entry discipline, where every movement nets to zero and links back to the transaction that settled it, is what makes the off-chain books reconcilable to Polygon in a way users can verify.
The collection-level choices are where deferred loading, sharding, and caching become concrete:
| Collection | Pattern | Why |
|---|---|---|
engagement_events | Own collection, append-only, sharded (key ≈ {creatorId, ts}) | Highest write volume; sharding spreads a hot stream's writes and keeps a creator's history local to read |
balances + ledger_entries | Referenced; hot balances cached in Redis | Read-hot for dashboards; balanced entries keep the economy reconcilable to the chain |
chat_messages / reactions | Own high-write collection; reactions also emit engagement events | High volume and realtime; they double as an engagement signal |
| dashboard / leaderboard rollups | Precomputed materialized aggregates, served from Redis | The front end reads a cached rollup instead of raw history, which is what killed the load-time math |
settlement_batches | Links ledger entries, exchanges, and stakes to one txHash | The reconciliation backbone between the off-chain books and Polygon |
A money system earns the right to be fast only once it's correct, so the balanced ledger came first and the speed work came after.
Infrastructure and operations
The whole application stack runs on Tencent Cloud: Node compute, MongoDB, Redis, and the message broker, all sitting next to Tencent's own media services (CSS, VOD, IM, CDN). Keeping everything on one cloud takes the bandwidth- and latency-sensitive video load off the platform's servers and removes a whole class of cross-provider networking and egress problems. Services ship as Docker containers, built and deployed through GitHub Actions pipelines.
Commit-to-cloud path: GitHub Actions tests and builds container images, which deploy onto Tencent Cloud alongside the managed datastores and media services. Polygon is reached over RPC through ethers.js.
Where the pressure lands, and what absorbs it:
| Pressure | Lever |
|---|---|
| Engagement write spikes on a popular live stream | Sharded engagement collection, with ingestion buffered through the Tencent Cloud message broker |
| Dashboard and leaderboard read math | Precomputed rollups, a Redis cache, and front-end deferred loading |
| Monthly reward epoch (heavy compute plus settlement) | Offline batch job: chunked, idempotent, one settlement tx per batch |
| Per-action gas and latency | Designed out of the hot path; nothing user-facing writes to Polygon |
| Streaming load | Offloaded wholesale to Tencent's CDN |
On security:
- Sybil and fraud gate. KYC plus admin verification gate token minting, so there's no reward surface to farm without a verified human behind a Social Token. This is the anti-fraud backbone of the economy rather than a compliance checkbox.
- RBAC admin. Role-based access across the large set of admin functions.
- The signer is the most sensitive asset in the system. A single ethers.js signer can deploy clones, mint, and execute settlement, so if it leaks, the economy is gone. The sound setup is a key held in a KMS or HSM, an isolated signer service, rate limits on minting and withdrawals, and a multisig on the treasury and reserve contracts. The common trap is that same key sitting in an env var on the API box
- Custodial obligation. Between settlements, users are trusting the platform's books, so the real promise of the design is a reconciliation every cycle that they can verify.
A few failure modes are worth naming. The settlement worker is the single point of economic truth, so it has to be idempotent, reconcile every cycle, and raise an alarm on any drift between the books and Polygon. Botted engagement poisons both the price oracle and the reward pool, which puts anti-bot work among the core security controls. A Tencent media outage degrades playback but leaves chat and the economy standing, since neither depends on stream health.
Outcome
- A working MVP of the full system in about 2 months with a three-person core, then 5 to 6 months of features, testing, and optimization.
- Shipped to web, iOS, and Android from a single Ionic Capacitor codebase, suited to a mobile-first esports audience.
- Stood up the whole creator-token economy end to end: clone-minted per-creator Social Tokens with a creator and reserve split, an engagement-driven price oracle, off-chain exchange and staking, monthly reward epochs, and batched on-chain settlement to Polygon.
- Built the custom live player handling conditional ads, in-video overlays, live chat, and moment reactions over Tencent CSS and VOD.
- Solved the front-end load problem with deferred loading, MongoDB sharding, and Redis-cached rollups.
- Sized for PolyGame's stated community of 700,000+ monthly active users and 60+ streamers (official figures, January 2022), with the first launch in Indonesia (2021) and expansion to India and Taiwan targeted for Q3 2022.
What I'd watch
- Reconciliation is the whole game. The first time a botched batch leaves the books and Polygon disagreeing, the trust is gone. So: idempotent settlement, a reconcile every cycle, and an alarm on the first unit of drift.
- The oracle is only as honest as its inputs. If watch-time and reactions can be farmed, then so can price and rewards. Anti-bot work on engagement is itself security.
- Clones cut the deploy cost but not the operational surface. EIP-1167 keeps onboarding a streamer cheap, but you still own N proxy contracts, N approvals, and N tokens to monitor, and that surface grows linearly with the number of creators.
- The webview is the player's ceiling. Real-time video plus overlays is the one place a Capacitor app may have to drop to native code.
- The app-chain is a one-way door. Leaving Polygon's shared security for a self-run chain on the Polygon SDK swaps a free, well-tested validator set for one you have to secure and decentralize yourself, which is easy to underestimate.
- The signer is the treasury. One key can clone, mint, and move everything, so it deserves the protection a vault gets.
The blockchain was the part everyone wanted to talk about. The ledger and the player were the parts that decided whether it worked.