给开发同学看的同一笔票：从 TG initData 登录、活动查询、号码锁定、账本扣款，到
VRF_ONLY
开奖和中奖履约。重点看服务边界、状态变化、链上随机数、签名隔离。
用户在 Telegram 里点击官方 Bot 的 Open App 按钮，TG Mini App 在 TG 内嵌打开。
前端拿到 initData 后送给后端校验签名，验证通过即登录 —— 用户不需要输入任何东西。
首页展示进行中的活动。Top banner 是高奖品 + 高人气活动，下面是按进度排序的列表。
用户被 iPhone 16 Pro 活动吸引（剩 23/1024 张，要开奖了）。
/api/rounds?status=open 走 Redis 缓存 → 返回活动列表 + 实时进度（每 2s websocket 推 1 次）
奖品 / 票价 / 已售 / 倒计时一屏可见。PRD 6 的最小可玩集合。
点 购票 进入号码池。
/api/rounds/{id} · 包含 prize / price / sold / max / remainingSeconds
1024 个号码池可视化。已售号码画掉、自己买过的高亮、可挑的留白。
用户挑了 0512 · 0768 · 1024 三个号 —— 3 USDT。
底部 sheet 弹出，余额从 100 USDT 扣到 97 USDT，链下账本，不是链上 tx。
用户点确认 → 扣款 → 锁号 → 写订单一气呵成。
1021 → 1024 张售完。game-service 检测到满约触发条件 → 准备开奖。
顶部 block height 滚动，提示 BSC 链在出块 —— 接下来这个数字就是开奖凭证的一部分。
5 步链路：game-service 检测满约 → sign-service 签名 VRF 请求 tx → chain-service 广播到 BSC → Chainlink VRF Coordinator 异步回调 → game-service 用回调的随机数算中奖号。
整个过程随机数来自链上、可验证，平台无法干预；结算（mod 1024）在链下省 gas。
中奖号 1024 命中用户买的号 —— 撒花。
关键：附 tx hash + 区块高度 + 区块浏览器入口，让用户能独立验证开奖结果不是平台编的。
用户在 72 小时内选择领奖方式：实物寄送 / 折 USDT 到余额。
实物：进入实物履约流程（运营后台 fulfillment 模块）；USDT：按市价 + 链上发款（sign-service 签名）。
gateway · user · game · wallet · sign · chain · sms
每个服务在不同 scene 出现，共同完成一笔票。
详见 architecture.html。
本演示走 VRF_ONLY：Chainlink VRF 提供随机数，链下结算。
其他 2 种引擎（FULL_CHAIN / BACKEND）见
draw-modes-explainer。
本页是 30 秒概览。
每个 scene 背后的完整请求 / 事件链，见
tech-flows.html 三张时序图。