PvP Gaming Mini-App

Role
Frontend Developer
Period
2024
Private Build

A Telegram-first PvP mini-app with live socket matches, Web3 payments, donations, referrals, and a fast tap loop shaped for high-volume player onboarding.

StackReact, Web3, Socket.IO
4M

Users in ~3 months

grown from a 100K paid base.

18s

Time to first match

down from about 90 seconds.

TON

On-chain stakes

TON Connect and Stars behind one wallet.

From a 100K paid base to 1M players in a single week.

  1. Fast Canvas game
  2. Real-time PvP
  3. Automated rewards
  4. In-game economy
  5. Web3 payments
  6. Tournaments
~100Kpaid user base
~1Mplayers in week one
~4Musers in ~3 months

What I owned

Frontend ownership end to end: the game client and how it feels on cheap phones, the realtime layer, and the Web3 payment surface.

Canvas rendering
Sprite animation
Game loop
Mobile controls
Haptics feedback
Economy UI / UX
Web3 payment UX
Frontend performance
The problem

It started as one fast Canvas game inside Telegram, then grew into a full arena: PvP, tournaments, an in-game economy and Web3 payments. Each layer had to stay fast on cheap phones and trustworthy once real currency was on the line.

How I approached it
  1. 01
    A custom 2D game, not a heavy engineBuilt on Canvas 2D with a requestAnimationFrame loop and a sprite system, so it loads fast inside the Telegram mini-app and stays smooth on low-end phones, no multi-megabyte engine.
  2. 02
    Deterministic match stateModelled the match as a socket reducer; the client renders an optimistic prediction and reconciles against the server frame, so play feels instant without trusting the client for outcomes.
  3. 03
    The client is untrustedAnti-cheat validates timing, consistency and rate limits server-side before any reward is credited, which matters the moment premium currency and betting are involved.
  4. 04
    One wallet providerTON Connect and Telegram Stars sit behind a single Wallet provider, so staking, donations and payments share one integration surface instead of three.
How it helped
  • Onboarding stopped being the funnel's drop-off point.
  • Referrals, not paid spend, carried the growth.

From tap to payout

Every result is settled on the server

The client only renders and predicts. Match logic, anti-cheat and reward approval all run server-side, the moment real currency is in play.

Player clientTelegram mini-app
WebSocketmatch events
Validationanti-cheat + game logic
Redissession & match state
PostgreSQLpersistent data
Reward approvalserver authority
Timing checks
action frequency validated
Consistency checks
state integrity verified
Rate limits
abuse prevention
Server approval
rewards issued only on validation

The game economy

A loop players come back to

Energy, currencies and upgrades feed one another, so every session has an obvious next step. That pull is what kept players returning and inviting others.

Core loop
1Playbattle & progress
2Earnwin & collect
3Upgradeimprove gear
4Shop & casesget items
5Competerank & climb

Realtime data flow

ClientSocketRedisPG

Key considerations

  • The client is untrusted; PvP results and rewards are validated server-side.
  • Redis holds session and match state; PostgreSQL holds persistent data.
  • Anti-cheat checks timing, consistency and rate limits before crediting.
  • Passive income is calculated lazily, so idle users cost nothing.
PvP arena, two players mid-matchMobile 2D PvP arcade game arena inside a phone frame, two competing players, glowing sprites, score HUD, dark polished UI, no text, no logos
Placeholder · 4:3
Rewards: wheel, loot box, currenciesMobile game rewards screen with wheel of fortune, loot box, multi-currency balances and an energy meter, dark polished game UI, no text, no logos
Placeholder · 4:3

Tech stack

ReactTypeScriptMobXCanvas 2DWebSocketRedisPostgreSQLTON Connect
All workNext projectEngagement & Referral Systems