Are you sure? The protocol described in Chuck Norris book Applied Cryptography seems to work fine without a randomness beacon. Once you get the commitments from all parties they reveal the nonces and everyone verifies they match the commitments and extracts the same random bits.

For those interested in how a "Time-Lock" UX performs with a technical audience, here are the final numbers:

Total Reach: 370 hit the commit endpoint (Dice Roll).

The 10s Retention: Despite the mandatory 10-second wait for Drand entropy, we saw a 90% completion rate (333 revealed vs 37 abandoned). This suggests that for verifiable randomness, users are remarkably willing to trade instant gratification for proof. The abandoned commits are in read-to-reveal state in our database, can be revealed anytime.

Fairness Audit: A frequency test on the last character of the hex-randomness across all 333 rolls showed a healthy distribution (range of 13–29 hits per char), confirming no architectural bias during the surge.

If you’re interested in implementing trustless randomness for your own project—whether it’s for NFT minting, on-chain gaming, online casino, giveaway selection, or cryptographic auditing, you can reach me at rishi@blockrand.net or dive directly via the [https://github.com/blockrand-api/blockrand-js].

I’ll be hanging around the thread for a bit longer if anyone has more questions about the Drand integration!

    Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data

    Commitment already pending for Round 26020619. Please wait for settlement before starting a new round.

If a server sees the Drand beacon just a few milliseconds before the user's commit is finalized, they can 'veto' a winning roll by dropping the packet.

Is 10s of UX friction a fair price for a Time-Lock that ensures the result literally doesn't exist anywhere in the world at the moment of commitment?

  Error: The string did not match the expected pattern.