Server can choose serverSeed after seeing clientSeed, breaking commit-reveal order
The session initialization allowed the server to observe clientSeed before committing to serverSeedHash, breaking the commit-reveal order and enabling outcome manipulation without detection.
Description
A correct commit-reveal flow requires the server to publish serverSeedHash (a commitment to serverSeed) before the client reveals clientSeed. In the audited implementation, the server received clientSeed first, then chose serverSeed (and the matching serverSeedHash).
With both seeds visible before the server commits, the server can pick a serverSeed whose combined hash with the revealed clientSeed produces a preferred game outcome. The published serverSeedHash still verifies against the eventually-revealed serverSeed, so independent verification reports success.
Impact
Verification still passes mathematically, but the provably-fair model is no longer cryptographically binding. Outcome selection is silently steerable by the server.
Recommendation
Enforce strict commit-reveal order on the server: serverSeedHash must be committed and returned to the client before any clientSeed is accepted. Reject session start payloads that include both fields, and version-pin the commit-reveal API so old clients cannot fall back to the unsafe path.
Fair Casino: Fixed. Zealynx: Verified.