可能影响：理论上有人想做"假牌堆"或操纵发牌顺序。

当前兜底：三道关一起封死这条路——① 每个玩家都必须各自参与洗牌并加锁，没有任何单方（包括官方）能决定或得知牌序；② 定稿牌堆必须是 52 张互不相同的密文，做假牌堆会当场红灯；③ 每手摊牌时验证器解出真实牌再查有无重复明文、能否正确解密。只要这手牌 4 灯通过且无重复明文，这副牌就是被全员合法洗过的 52 张真牌。缺的只是"在不亮牌前用零知识数学证明合法置换"，即把现在的"事后每手必抓"升级为"事前数学上不可能"。

计划：引入可验证洗牌证明并纳入验证器。

可能影响：全下之后只剩翻公共牌时，一名快要输的玩家可以直接掉线、并扣住自己的解牌钥匙，使这手牌翻不出板而被判作废、双方退还本金——把"大概率会输"变成"退款"。

当前兜底：这不是偷钱（双方都退回本金、筹码不增不减）；"在线状态下喊作废"的赖账已被完全封死（当作弃牌、照常输掉），只剩"真掉线"这一条。我们刻意保留"退款"而非"掉线就判负"，因为后者会给掌控连线的官方一个新的作弊面（可在你钥匙广播前掐断连接逼你判负）——退款才是对玩家最安全的选择，并可在账号层对反复全下掉线做检测告警。

计划：引入零知识 / 可中途退出的发牌——让公共牌可凭公开承诺由在场各方独立翻出、无需逃跑者事后配合，从根上消除这条赖账（届时真掉线也照常分出胜负）。

可能影响：只影响账号登录，且仅在"服务端被攻破、有人拿到密码库后慢慢离线猜测弱密码"时才有意义。不影响任何牌局、筹码或底牌。

当前兜底：登录只发客户端 PBKDF2 派生的 authSecret，服务端从不接触明文密码、密钥库密钥永不出本机，无法即时解开钥匙库冒充你；高轮次 PBKDF2 也大幅拖慢猜测。强密码基本完全免疫，残留风险只针对弱密码 + 已被攻破并持库的服务端。

计划：迁移到完整 OPAQUE / SRP，连弱密码的离线猜测也一并堵死。

可能影响：把一条合法签名事件"重放"到别的桌、别的版本或过期后再用。

当前兜底：每条签名事件绑定 tableId 并在线上强制拒收不属于本桌的事件——跨桌重放已完全封死；sessionNonce 会话域分离 + 序号检测还能发现同一会话内的重放与乱序。尚未强绑定的是 handId / buildCid / expiry，残留的只是"同桌跨手"这类更窄的边角场景。

计划：补全剩余域字段并在受控测试后线上强制。

可能影响：只影响"谁能按开新局、改设置这类桌面控制按钮"。不影响下注、弃牌、筹码与发牌——那些必须玩家本人签名，任何人都偷不走你的筹码、也改不了你的牌。

当前兜底：按零裁判设计，协议层本就没有"操作员 / 房主"特权；真正涉及钱与牌的行动全部需本人签名 + 浏览器为权威 + 无法继续时全员共识作废全额退还。所以这项缺失最多造成"控制按钮的权限边界不够明确"，够不到筹码或牌面。

进展：已定义房主角色（开第一手的人即房主），并让离线验证器把"非房主擅自改设置 / 重开报名"在可复验记录里标注出来、可归因到具体签名者（CI 测试覆盖）。下一步是把这条授权在收发端也强制（现仅在验证侧标注，不在现场拦截，以免误伤刚刚重构过的开局/重开流程）。

可能影响：离线验证器与实时状态机暂未合并为同一套纯函数，理论上存在"某个合法事件顺序被离线验证器误判"的边角情况。

当前兜底：关键在于这种偏差只会让验证器把一手合法牌误报为可疑（宁可错杀），永远不会放过一次真正的作弊。也就是说它影响的是"会不会偶尔虚惊一场"，而不是"会不会漏掉坏人"。

进展：现场端已统一为单一确定性 reducer——座位 / 底池 / 轮到谁 / 赢家全部由它从签名事件日志算出，中继不再参与。并已加一致性测试（CI 强制）：把同一份签名记录同时喂给"可下载的离线验证器"和现场 reducer，断言两者算出的筹码结果逐分一致——弃牌结束与摊牌（含边池/比牌赢家）两条路径均已覆盖，二者永远不会悄悄分叉。剩余仅一项：把离线验证器与现场逻辑合并成同一份编译产物（需引入打包工具、并进可复现源码包，留待可验证一次发布时稳做）。

可能影响：这不是安全漏洞，而是公开范围的取舍——可玩客户端（界面 + 公平内核 + 入口 + 静态资源）的完整可构建源码已经公开、并可字节级复现；仍未公开的只是首页、营销文案、AI 摘要页与后端运维这类不参与发牌、也不进入 Game client CID 的非玩法部分。影响的只是"能否一键重建整个站点的每个角落"，不影响任何一手牌的公平性。

当前兜底：所有与公平性相关的核心文件都已开源；你可以在固定 Docker 环境里用公开源码重编出与线上一致的客户端 CID（见独立验证指南），并对照逐文件哈希、信任边界清单与运行中 CID 校验，核对你正在运行的就是公开审计过的那份代码。

计划：在不被整体抄袭的前提下持续扩大可复现构建范围，并引入外部签名发布日志与第三方复现见证。

What it affects: in theory, someone trying to "stack the deck" or rig the deal order.

Contained today: three gates already close this off — ① every player must each shuffle and lock, so no single party (including the operator) can set or learn the order; ② the finalized deck must be 52 distinct ciphertexts, so a stacked deck lights red on the spot; ③ at every showdown the verifier decrypts the real cards and checks for duplicate plaintext and correct decryption. If a hand passes its four lights with no duplicate plaintext, that deck was a genuine 52-card deck shuffled by everyone. What's missing is only a zero-knowledge proof of a valid permutation without revealing — i.e. upgrading today's "caught every hand, after the fact" to "mathematically impossible, before the fact".

Plan: add a verifiable shuffle proof and fold it into the verifier.

Could affect: after an all-in, when only the board reveal remains, a player who is about to lose can disconnect and withhold their decryption keys so the board can't be revealed — the hand voids and both stakes are refunded, turning a likely loss into a refund.

Current cover: this is not theft (both stakes returned, no chips minted or destroyed); the connected "claim a void" dodge is fully blocked (treated as a fold, the loss stands), leaving only a genuine disconnect. We deliberately keep "refund" rather than "disconnect = forfeit", because forfeiting would hand the connectivity-controlling operator a new attack surface (cut your link before your keys broadcast to force a loss) — refund is the player-safest choice, with account-level detection of repeated all-in disconnects.

Plan: a zero-knowledge / abort-resistant deal — the board is recoverable from public commitments by the present players with no cooperation from the leaver, removing this dodge at the root (a genuine disconnect then still resolves normally).

What it affects: account login only, and only in the case where the server is breached and someone slowly offline-guesses weak passwords from the stolen database. It does not affect any hand, chips, or hole cards.

Contained today: login only sends a client-side PBKDF2-derived authSecret; the server never touches the plaintext password, the vault key never leaves your device, and it cannot instantly open your vault to impersonate you. High-iteration PBKDF2 also greatly slows guessing. A strong password is essentially immune; the residual risk is only weak passwords plus an already-breached, database-holding server.

Plan: migrate to full OPAQUE / SRP to also close off offline guessing of weak passwords.

What it affects: replaying a legitimate signed event into a different table, a different build, or after it has expired.

Contained today: every signed event is bound to its tableId and live-rejected if it doesn't belong to the table — cross-table replay is fully closed; sessionNonce domain separation plus sequence checks also catch replay and reordering within a session. Not yet strongly bound are handId / buildCid / expiry, so the residual is only narrow edge cases like "same-table, across hands".

Plan: add the remaining domain fields and enforce them live after controlled testing.

What it affects: only "who may press table-control buttons like start-new-hand or change-settings". It does not affect bets, folds, chips, or dealing — those require the player's own signature, so no one can take your chips or change your cards.

Contained today: by the zero-referee design the protocol has no "operator / table owner" privilege to begin with; everything involving money and cards requires your own signature, browser-authoritative state, and a unanimous void with full refund when play can't continue. So this gap can at most leave "the permission boundary on control buttons under-specified" — it cannot reach chips or card faces.

Progress: the host role is now defined (the signer of the first hand is the host), and the offline verifier flags a non-host changing settings or reopening registration in the replayable record, attributable to the specific signer (covered by CI tests). Next is to also enforce it on senders/receivers (today it is flagged at verify time, not blocked live, to avoid disturbing the just-reworked start/restart flow).

What it affects: the offline verifier and the live state machine aren't yet one shared pure function, leaving a theoretical edge case where a legal event order could be misjudged offline.

Contained today: crucially, such a divergence can only make the verifier flag a legitimate hand as suspicious (fail-safe) — it can never let a real cheat through. So it affects "might we occasionally raise a false alarm", not "might we miss a bad actor".

Progress: the live side is now a single deterministic reducer — seats / pot / turn / winner are all derived by it from the signed event log, with the relay no longer involved. A CI-enforced parity test now feeds the same signed record to both the downloadable offline verifier and the live reducer and asserts their chip outcomes are identical to the chip — both the fold-out and the showdown (side-pot / best-hand winner) paths are covered, so the two can never silently diverge. Only one item remains: merging the offline verifier and live logic into one compiled artifact (needs adding a bundler and baking it into the reproducible source package — left for a release we can verify).

What it affects: this is not a security hole but a disclosure choice — the complete buildable source of the playable client (UI + fairness core + entry points + static assets) is public and byte-for-byte reproducible; what is still withheld is only non-gameplay parts — the homepage, marketing copy, AI summary pages, and backend operations — which do not deal cards and are not inputs to the Game client CID. It affects only "can you one-click rebuild every corner of the whole site", not the fairness of any single hand.

Contained today: all fairness-critical core files are open; you can recompile the public source in a pinned Docker environment to a client CID identical to the live one (see the verification guide), and cross-check per-file hashes, a trust-boundary manifest, and a live CID check to confirm that what you're running is the same code that was publicly audited.

Plan: keep widening the reproducibly-buildable scope without exposing the project to wholesale copying, and add an external signed publish log plus third-party reproduction witnesses.