rishi_blockrand

Thanks to everyone who poked at the site yesterday! It provided a great stress test for the architecture (Go + Firestore + Cloud Tasks).

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 [email protected] 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!

The reason for having a deliberate delay (10 sec here in the demo) is that I think 'the next round' (of drand for example) is a security anti-pattern.

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?

I just checked the code and it was a small demo/front-end issue of assigning the player_id (in javascript)... have corrected it now : )

The logic of back end api (written in go, commitment stored in firestore), is intact, the 409 will come only if the same user tries to commit again before the reveal, this is by design.

Spot on. By using Drand, we move from Optional Reveal to Deterministic Resolution — the result exists publicly the moment the round closes.

It turns the server from a "Judge" into a "Timestamped Vault" that can't hold the outcome hostage if it's unfavourable, giving the player a winning ticket they can verify independently.

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...

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.

The current time (in the demo) is fixed around 10 secs, but it can be anything, minimum being 6 secs (as the fastest) Drand pulse is 3 second, and some latency buffer...

Oh ok... so then thats definitely a bug then... actually drand issues randomness every 3 seconds... so may be multiple on the same drand round has a bug... will correct that... Thanks

Oh yes, its only one commitment per call... this is a UI handling issue, will resolve it... the backend by design only takes one commitment per player, till it is resolved/revealed... Thanks

Hmm... I have not been able to replicate that... Can u screenshot it ? Thanks for trying it out : )

Github of the JS SDK https://github.com/blockrand-api/blockrand-js

One thing I didn't emphasize enough in the post: the 10-second delay isn't just a technical limitation of Drand. It's actually the security feature. If the delay was 1ms, a server could still potentially 'front-run' the beacon. By forcing a 10s 'lock-in' period, we ensure the entropy is truly from the future. Is a 10s UX trade-off acceptable for high-stakes games, or is that a deal-breaker for most devs?

Most "provably fair" games today rely on a commit-reveal model that has a subtle flaw: the server chooses its seed hash privately. This allows for a "Seed Grinding" attack where the house pre-computes millions of outcomes and commits only to the seed that favors them.

I wrote this post to explain how to close that gap using public entropy beacons (Drand). By tying the outcome to a future Drand round that neither the player nor the server knows at the time of commitment, you get a trustless result without needing a slow blockchain.

Live Demo (Dice Roll): https://blockrand.net/live.html

The logic is simple: Hash(Player_Seed : Server_Seed : Future_Drand_Sig).

I’ve written a deep dive on why traditional commitment schemes have a "last-mover advantage" and how this triple-mix eliminates it. Would love to hear the community's thoughts on the trade-off between the 10s settlement delay and the added security.

Nice puzzle mechanics! I noticed you mentioned randomness is only used for the initial config. For 'Daily' style puzzles, there's always a segment of the player base that gets skeptical about whether the 'Daily Seed' was hand-picked to be harder or easier (the classic 'Wordle' suspicion).

A cool way to bypass that is to use a public, decentralized beacon (like Drand) as the seed for your generator. It effectively proves to players that you couldn't have rigged today's puzzle, because the entropy didn't exist until the beacon round fired. It's a low-lift way to add a 'Provably Fair' badge to a daily game without needing a complex backend.

The non-escalating envelope approach in Firecracker is a great way to handle agent drift. I noticed you’re using HMAC approval tokens for gated ops—how are you handling the entropy source for those secrets?

One edge case in agent security is 'Entropy Exhaustion' or prediction if the microVM environment is compromised. I’ve been looking at anchoring HMAC generation to decentralized randomness beacons (like Drand) to ensure that even if an agent compromises the local environment, it can't predict or pre-mine the next set of 'valid' tokens because the entropy hasn't been released by the network yet.

Have you thought about moving the 'Root of Trust' for your HMAC tokens outside the local microVM entirely?The non-escalating envelope approach in Firecracker is a great way to handle agent drift. I noticed you’re using HMAC approval tokens for gated ops—how are you handling the entropy source for those secrets?

One edge case in agent security is 'Entropy Exhaustion' or prediction if the microVM environment is compromised. I’ve been looking at anchoring HMAC generation to decentralized randomness beacons (like Drand) to ensure that even if an agent compromises the local environment, it can't predict or pre-mine the next set of 'valid' tokens because the entropy hasn't been released by the network yet.

Have you thought about moving the 'Root of Trust' for your HMAC tokens outside the local microVM entirely?

Interesting choice using a Feistel cipher for format-preserving encryption here. It’s a solid step up from Hashids for preventing sequential ID discovery.

I’ve been looking into the 'Integrity Gap' in HMAC systems lately—specifically how to prove to an external auditor that the server secret (your masterKey) wasn't speculatively rotated or manipulated before a token was generated. In high-stakes environments like verifiable gaming or sensitive audit trails, the server holding the entropy is often a trust bottleneck.

Have you considered a model where the seed/key is anchored to a decentralized beacon like Drand? I've been experimenting with a 'Commit-Reveal' alternative where the final result is dependent on a future beacon round. It effectively removes the 'Last-Look' advantage from the server. Curious if you see a place for decentralized entropy in ID obfuscation for apps requiring a public audit trail

One thing we’re especially unsure about is whether our double-blind commit model still holds up if one party delays reveals strategically. We modeled this, but I’d love critique from cryptography folks here.

Both node and html versions are there to test Blockrand API with. You just run a curl command to get an API Key (instant) and then you can fire the system. Would love to get feedback on it.

Hi HN, I’m Rishi, the creator of Blockrand.

I built this because I noticed a recurring trust issue in web3 gaming and raffles: users often don't trust the 'house' seed, and developers struggle to implement complex commitment schemes.

How it works: We use a Double-Blind model. The SDK generates a local secret (player_hash) before talking to the server. The server then commits to its own secret and anchors the round to a future Drand beacon. The final result is only revealed once all three pieces of entropy are public.

The Tech: Go/Firestore backend (handling user-level commitments to prevent race conditions). Drand (distributed randomness) as the external anchor. Zero-dependency JS SDK. It's free for developers (up to 100 active users/month). I’d love to hear your thoughts on the commitment logic and the SDK's verification flow.