[rishi_blockrand]

Great point—Schneier’s two-party protocol is the foundation... However, it suffers from the 'Last-Actor/Last-Look' problem in a client-server environment.

In a standard 2-party commit-reveal, one party always learns the result first. (Mostly servers in current setups).

By adding a Randomness Beacon (Drand) as a third entropy source, we solve two things: No Last-Look: Neither the player nor the server knows the outcome until a specific future timestamp (the Drand round). Forced Resolution: Since the Drand signature is public, once that round passes, the result is 'locked' by math. The server can't hold the result hostage because anyone can pull the Drand signature and verify the result themselves.

[CGMthrowaway]

Right. In a strict two‑party client‑server provably fair system without economic penalties or extra trust assumptions, eliminating last‑actor bias requires external future entropy (or an equivalent third uncontrollable source)

[rishi_blockrand]

Exactly. For a web app where you can't easily "slash" a server for disappearing, you need that "uncontrollable third source" to force the game to finish.

I looked at VDFs and custom MPCs, but they felt like overkill for a dice roll. Drand is basically a "pre-computed" MPC that anyone can verify with a simple curl. It hits that pragmatic sweet spot for a trustless audit without the "math homework" for the user...