[SERVICE] Blockrand: Double-Blind Randomness (Show HN #1) for Dice/Crash/Games

[rishib]

Your "Provably Fair" System is Only Half-Fair.
Why should players trust a Server Seed generated by the house? They shouldn't.

The Industry Problem:
Standard "Provably Fair" systems (Server Seed + Client Seed) have a fundamental flaw: The house knows the server seed before the player places a bet. Even with a hash commitment, a malicious operator could pre-generate billions of seeds to find ones that favor the house against common client-side patterns.

The Solution: Blockrand API
Blockrand introduces External Entropy into your game loop using the Drand Beacon.

• Phase 1 (Commit): Player bets; your game commits (with Player and Server Hash) to a future Drand round.
  
• Phase 2 (Wait): A 10-second window. The number literally does not exist yet on any server.
  
• Phase 3 (Reveal): The threshold cryptography network broadcasts the seed. The result is revealed.
  

Pilot Results & Initial Data
We recently conducted a public pilot during our Hacker News launch to observe real-world behavior:

• Initial Retention Signal: 90% of users in our pilot completed the 10s cycle, suggesting a high tolerance for wait times when transparency is the trade-off.
  
• Stability: Handled 500+ unique rolls during the launch period with zero lag or failures.
  
• Fair Distribution: Verified hex-spread across all pilot bets.
  

THE OFFER: Free Managed Integration
I am looking for 2 active casinos or game developers (Dice, Crash, Coinflip) to be our anchor partners.

What you get:
1. Free API Access: High-limit access to the Blockrand randomness engine.
2. Hands-on Support: I will personally help your dev team with the Go/JS integration.
3. Trust Badge: "Powered by Blockrand - Externally Verifiable" to put on your UI.

Ready to make your games truly trustless?
Try LIVE :https://blockrand.net/live.html
GitHub : https://github.com/blockrand-api/blockrand-js
Contact : rishi@blockrand.net

Edit: Updated "Battle-Tested" section to "Pilot Data" to more accurately reflect current scale, per feedback from LoyceV.

[yahoo62278]

In theory this sounds great but you have some issues.

1. 10 second wait between bets. Some players are going to be 100% fine with that wait to get results while others are going to dislike the wait. I prefer faster rolls, but would be willing to compromise if truly fair.

2. Any casino open to implementing this would most definitely want to inspect the code before applying it to their site to make sure no backdoors are there to steal the bankroll or compromise their server.

3. Let's assume casino's are using salted seeds and fucking players over pre resulted seeds to screw a player based on their betting tendencies, do you think a casino is going to want to move to a system that they cannot control the result? They're making money hand over fist in the big markets, IDK if they're cheating or not. I'd love to find out, but they're not gonna allow me to bring in a dev to check their code.

Idk whether someone takes you up on this or not but I'd love to hear some of the communities thoughts.

[rishib]

Thanks for the honest feedback, @yahoo62278. Here’s how I’m looking at those three points:

1. The 10s Wait: You’re right—it’s a trade-off. We see this as the "High Roller" or "Transparency" tier. It’s for players who prioritize certainty over speed. Interestingly, our early data shows that the 10s wait actually builds "suspense" that players enjoy, similar to a physical roulette wheel slowing down. It’s a different psychological loop than the "instant-loss" of a 1ms roll.

2. Verifiability vs. Backdoors: I 100% agree on the need for transparency. The client-side integration (JS SDK) is Open Source and available on GitHub for anyone to audit how commitments and reveals are handled. Because we use Drand, the system offers Black-Box Verifiability. Even if a casino (or Blockrand) wanted to cheat, we cannot forge the Drand pulse. The integration is a stateless API call—we never touch the casino's bankroll or private keys.

3. The "Control" Issue: This is the elephant in the room. Honest casinos spend thousands on marketing to prove they aren't cheating. Blockrand gives them a way to prove it without anyone needing to "trust" their dev team. As for the giants making money hand over fist? They might stay with their black boxes. But for a new casino trying to steal market share, offering "Double-Blind" fairness is a massive competitive advantage.

I'm looking for 2 anchor partners to trial this for free and prove that players actually value this level of transparency.

In theory this sounds great but you have some issues.

1. 10 second wait between bets. Some players are going to be 100% fine with that wait to get results while others are going to dislike the wait. I prefer faster rolls, but would be willing to compromise if truly fair.

2. Any casino open to implementing this would most definitely want to inspect the code before applying it to their site to make sure no backdoors are there to steal the bankroll or compromise their server.

3. Let's assume casino's are using salted seeds and fucking players over pre resulted seeds to screw a player based on their betting tendencies, do you think a casino is going to want to move to a system that they cannot control the result? They're making money hand over fist in the big markets, IDK if they're cheating or not. I'd love to find out, but they're not gonna allow me to bring in a dev to check their code.

Idk whether someone takes you up on this or not but I'd love to hear some of the communities thoughts.

[dewez]

1. The 10s Wait: You’re right—it’s a trade-off. We see this as the "High Roller" or "Transparency" tier. It’s for players who prioritize certainty over speed. Interestingly, our early data shows that the 10s wait actually builds "suspense" that players enjoy, similar to a physical roulette wheel slowing down. It’s a different psychological loop than the "instant-loss" of a 1ms roll.
 to get results while others are going to dislike the wait. I prefer faster rolls, but would be willing to compromise if truly fair.

this is the killer. no one wants to wait 10 second between slot style games. 1 bet a second is the sweet spot for autobets. this is a problem you should have never skipped over- if you got any feedback from real players you would know.

the second killer is thinking a casino wants to be reliant on your uptime.

Why should players trust a Server Seed generated by the house? They shouldn't.

the house wants as perfect randomness as possible to ensure their edge is on target and to reduce non-game variance. the player can always cycle their client seed to reveal the server seed and inspect it for length.

Standard "Provably Fair" systems (Server Seed + Client Seed) have a fundamental flaw: The house knows the server seed before the player places a bet. Even with a hash commitment, a malicious operator could pre-generate billions of seeds to find ones that favor the house against common client-side patterns.

thats the whole point of the client seed... a player should always change it before first play.
even if the player didnt, you're assuming the owner knows which game they will play? and do what? skip nonces? the player would see that.


the bottom line is- when PF is done right and there is an offsite verifier (like on L0TT0) its a great system.

your idea is fun- but would be cooler if you just gave it away.

[rishib]

Hi @dewez, thanks for the sharp critique. You’re coming at this from a 'High-Frequency' perspective (slots/autobets), and you’re 100% right: for a $0.01 slot pull every second, a 10s wait is a dealbreaker.

However, Blockrand isn't built for volume-slots; it’s built for High-Trust Events.

1. On Speed: We aren't trying to replace the 1ms 'autobet' loop. We are targeting Games like Lotto, Coinflip, and Crash, or high-stakes Dice rolls. When a player is betting significant capital, they move from a 'dopamine' loop (speed) to a 'security' loop (trust). 10 seconds for a verifiable, non-custodial result is a feature, not a bug, in those contexts.

2. On Uptime/Reliability: This is why we chose Drand. It’s not just 'my' server. Drand is a distributed network (League of Entropy) run by Cloudflare, Swisscom, and academic institutions. If my bridge goes down, the casino can still verify the result directly against the Drand beacon using the round number. It’s the most resilient entropy source on the planet.

3. The 'PF is Enough' Argument: While rotating client seeds works for sophisticated players, the vast majority of casual players never touch their seed. They just see a 'Server Seed' and wonder if the house is choosing a seed that hits their specific betting patterns. Blockrand removes that 'Server Seed' suspicion entirely by using a seed that does not exist yet when the bet is placed.

I agree that PF is great when done right (like on L0TT0), but we’re offering a way to take that trust out of the 'House's hands' and put it into a decentralized protocol.

Would love to hear your thoughts on how this could work for 'Event-based' games rather than high-frequency slots.

1. The 10s Wait: You’re right—it’s a trade-off. We see this as the "High Roller" or "Transparency" tier. It’s for players who prioritize certainty over speed. Interestingly, our early data shows that the 10s wait actually builds "suspense" that players enjoy, similar to a physical roulette wheel slowing down. It’s a different psychological loop than the "instant-loss" of a 1ms roll.
 to get results while others are going to dislike the wait. I prefer faster rolls, but would be willing to compromise if truly fair.

this is the killer. no one wants to wait 10 second between slot style games. 1 bet a second is the sweet spot for autobets. this is a problem you should have never skipped over- if you got any feedback from real players you would know.

the second killer is thinking a casino wants to be reliant on your uptime.

Why should players trust a Server Seed generated by the house? They shouldn't.

the house wants as perfect randomness as possible to ensure their edge is on target and to reduce non-game variance. the player can always cycle their client seed to reveal the server seed and inspect it for length.

Standard "Provably Fair" systems (Server Seed + Client Seed) have a fundamental flaw: The house knows the server seed before the player places a bet. Even with a hash commitment, a malicious operator could pre-generate billions of seeds to find ones that favor the house against common client-side patterns.

thats the whole point of the client seed... a player should always change it before first play.
even if the player didnt, you're assuming the owner knows which game they will play? and do what? skip nonces? the player would see that.


the bottom line is- when PF is done right and there is an offsite verifier (like on L0TT0) its a great system.

your idea is fun- but would be cooler if you just gave it away.

[cryptofrka]

Hey there, replying to the DM sent - for transparency purposes and to keep the dialogue going.

Generally, it has its strengths. If I was taking a 10k$ bet every time, I'd prefer this system. If I was playing a 5$ slot, I'd prefer it to be instant.

Even in cases in which this system would be preferred, there are some topics that would need to be clarified.

1.) What is the fallback mechanism in case of drand downtime for any particular reason? Fallback systems reintroduce the assumption of trust/can't be fully trustless.

2.) In theory, in case of latency/bet delaying by the casino the possibility that the house gets an edge exists - at least in edge cases close to the fixed interval in which the randomness sequence gets published.

3.) Important to ask as well - is a system like this even compliant with a regulator?

I generally feel that, for the average user, currently perceived fairness may already be adequate.
The tradeoff of a worse user experience (with big delays) for a more trustless system is, in my opinion and gambling practice, not worth it.

Then again, would I like this as an option that can be toggled on and off? Yeah, sure, so if I wanna toss 5$ I can just spam it and if I want to play big I can choose an option in which the house cannot get even a (theoretical?) edge.

[rishib]

Hi @cryptofrka, appreciate you moving this here. Let’s dive into the "what-ifs":

1. On the "Toggle" Idea (The Hybrid Model):
This is exactly the right vision. We don't see Blockrand replacing the 1ms "dopamine loop" for $0.01 slots. We see it as "High-Trust Mode" or "VIP Toggles." It allows a player to choose: "I want instant results" vs. "I’m betting big and want 100% mathematical certainty that the house is blind."

2. Drand Uptime:
Since its launch in 2020, the Drand mainnet has maintained 100% uptime. Because it's a distributed "League of Entropy," there is no single point of failure.  You can monitor the real-time health of the network here:
https://status.drand.love

If the beacon ever did stall (it hasn't since 2020, even once), our protocol's stance is: No Fallback. For a high-stakes roll, "Wait for the beacon or refund" is the only truly trustless path. Moving to a server-side fallback just reintroduces the trust gap we are trying to close.

3. The "Last-Look" Edge Case:
This is a vital technical point. We solve this with a Commitment Cut-off. If a bet arrives within X milliseconds of the next Drand pulse, the bridge automatically pushes the commitment to round N+2 (fixed time commitment). This ensures the bet is cryptographically "locked" before the randomness is even generated, let alone broadcasted.

4. Compliance:
It's a new frontier, but we believe "Public Entropy" exceeds current standards for independent randomness. We are currently documenting the protocol to align with transparent auditing needs.

If a casino like Duel offered a "Double-Blind" toggle for their $100+ rolls, would that be enough to "Join the Resistance"?

Hey there, replying to the DM sent - for transparency purposes and to keep the dialogue going.

Generally, it has its strengths. If I was taking a 10k$ bet every time, I'd prefer this system. If I was playing a 5$ slot, I'd prefer it to be instant.

Even in cases in which this system would be preferred, there are some topics that would need to be clarified.

1.) What is the fallback mechanism in case of drand downtime for any particular reason? Fallback systems reintroduce the assumption of trust/can't be fully trustless.

2.) In theory, in case of latency/bet delaying by the casino the possibility that the house gets an edge exists - at least in edge cases close to the fixed interval in which the randomness sequence gets published.

3.) Important to ask as well - is a system like this even compliant with a regulator?

I generally feel that, for the average user, currently perceived fairness may already be adequate.
The tradeoff of a worse user experience (with big delays) for a more trustless system is, in my opinion and gambling practice, not worth it.

Then again, would I like this as an option that can be toggled on and off? Yeah, sure, so if I wanna toss 5$ I can just spam it and if I want to play big I can choose an option in which the house cannot get even a (theoretical?) edge.

[cryptofrka]

If the beacon ever did stall (it hasn't since 2020, even once), our protocol's stance is: No Fallback. For a high-stakes roll, "Wait for the beacon or refund" is the only truly trustless path. Moving to a server-side fallback just reintroduces the trust gap we are trying to close.

If a bet arrives within X milliseconds of the next Drand pulse, the bridge automatically pushes the commitment to round N+2 (fixed time commitment). This ensures the bet is cryptographically "locked" before the randomness is even generated, let alone broadcasted.

I like both of these answers. Some additional questions come to mind though, but are regarding edge cases once again and not really needed at this point in time.

I'd say that the idea, although not revolutional, is well positioned for a crypto high-roller environment and I'd like to see it implemented as long as it is optional for the player.

In a right environment (and if it passes strict operational test), I see this as a strong selling point to a small niche of players - but those whose wagering amounts should be of interest to most casinos.

[rishib]

Thanks for the deep dive, @cryptofrka. Having a veteran advocate for the "High-Roller Toggle" approach confirms our market fit.

For a $0.01 slot pull, speed is king. But for a $100+ Coinflip or Max-Bet Dice roll, the 10-second window is the digital equivalent of a physical dealer shuffling a fresh deck in front of the player. It provides a "Safe Harbor" where neither the house nor the player has "Last-Look" knowledge.

To the Casino Operators and Devs:

As discussed, the goal isn't to replace your high-frequency loops, but to offer a verifiable "VIP Mode" for your most valuable players.

Our API is stateless, the JS SDK is open-source, and the entropy is 100% external. If you're looking to bridge the trust gap for high-stakes events, let's talk tech.

PM me or reach out on Telegram (@rishiblockrand) or email me on rishi@blockrand.net for integration docs.

[The Cryptovator]

Let's say you are creating something in favour of gamblers; am I right? From the overall theme, it's pretty clear you want to introduce a system that will be fully transparent. But who will benefit from that new system? It's definitely gamblers or users. Then do you think your script would be used by gamblers? No way, you have to sell or add your script with the gambling sites. On this stage you have to have regrets at the end of the day.

Let me ask you, why will gambling platforms replace their existing, probably fair system with your fully fair script? Though I don't believe there is something fair, we even saw some of the biggest wins. If at the end of the day the casino becomes a loser, and it does happen every day, then how will they sustain and continue their business? They don't have any money-making machine to pay out. Means I don't believe any gambling platform is at least going to implement this.

Since I am not a gambling technical expert, I just discussed your theme. Gambling sites never want to share how their probably fair system works. They won't allow you to read their code anyway. Unless they have some system to make money, they can't run a business. I am not sure; it would probably be 40% win and 60% loss. So the platform will have 20% revenue from them. It would be different, but if there is no such system, then I am afraid of how gambling platforms are earning.

[rishib]

@The Cryptovator — That’s a fair and blunt assessment. You're touching on the fundamental tension in this industry.

However, there’s a key distinction to make: Blockrand doesn't change the math of the game (the House Edge); it only secures the outcome (the Entropy).

To address your points:

"Why would they replace existing systems?"
Most current "Provably Fair" systems rely on a Server Seed generated by the casino. The "Trust Gap" happens when a high-roller wonders: "Did the casino generate a seed that specifically ensures my $10k bet loses?" By using Drand (external entropy), the casino can say: "We didn't even know the winning number when you placed the bet." It’s about marketing trust to attract bigger fish.

"If the casino becomes a loser..."
Even with 100% fair randomness, the Casino still wins because of the House Edge. Whether a dice roll is generated by a server or by the stars, a 1% edge over 1,000,000 rolls is a guaranteed profit. They don't need to "cheat" the randomness to make money; the math already does it for them.

The Benefit to the Platform:
High-rollers will leave "black box" casinos for platforms that can prove they aren't messsing with the seeds. We aren't asking casinos to give away their revenue; we're giving them a tool to prove they aren't "Last-Looking" at bets.

It’s not about being "pro-gambler"—it’s about being pro-transparency so the industry can actually scale. Does that distinction make sense from a service-provider perspective?

Let's say you are creating something in favour of gamblers; am I right? From the overall theme, it's pretty clear you want to introduce a system that will be fully transparent. But who will benefit from that new system? It's definitely gamblers or users. Then do you think your script would be used by gamblers? No way, you have to sell or add your script with the gambling sites. On this stage you have to have regrets at the end of the day.

Let me ask you, why will gambling platforms replace their existing, probably fair system with your fully fair script? Though I don't believe there is something fair, we even saw some of the biggest wins. If at the end of the day the casino becomes a loser, and it does happen every day, then how will they sustain and continue their business? They don't have any money-making machine to pay out. Means I don't believe any gambling platform is at least going to implement this.

Since I am not a gambling technical expert, I just discussed your theme. Gambling sites never want to share how their probably fair system works. They won't allow you to read their code anyway. Unless they have some system to make money, they can't run a business. I am not sure; it would probably be 40% win and 60% loss. So the platform will have 20% revenue from them. It would be different, but if there is no such system, then I am afraid of how gambling platforms are earning.

[Zwei]

The Industry Problem:
Standard "Provably Fair" systems (Server Seed + Client Seed) have a fundamental flaw: The house knows the server seed before the player places a bet. Even with a hash commitment, a malicious operator could pre-generate billions of seeds to find ones that favor the house against common client-side patterns.

favors the house how?

i mean, even with the house knowing the server seed, as long as the player sets their own client seed after the house commits to the hashed server seed, the house can't cheat.
not to mention, the house doesn't even know how you are going to play for them to give you a seed that favors them.

the only real industry problem is that some casinos don't implement provably fair systems the right way.

The Solution: Blockrand API
Blockrand introduces External Entropy into your game loop using the Drand Beacon.

• Phase 1 (Commit): Player bets; your game commits (with Player and Server Hash) to a future Drand round.
  
• Phase 2 (Wait): A 10-second window. The number literally does not exist yet on any server.
  
• Phase 3 (Reveal): The threshold cryptography network broadcasts the seed. The result is revealed.
  

Battle-Tested & Production Ready
We recently stress-tested this on Hacker News (reaching #1).

• 90% Retention: Proof that players prefer a 10s wait for 100% transparency over instant "trust-me" rolls.
  
• High Uptime: Handled 500+ rolls from multiple users with zero lag or failures.
  
• Fair Distribution: Verified hex-spread across all test bets.
  

THE OFFER: Free Managed Integration
I am looking for 2 active casinos or game developers (Dice, Crash, Coinflip) to be our anchor partners.

What you get:
1. Free API Access: High-limit access to the Blockrand randomness engine.
2. Hands-on Support: I will personally help your dev team with the Go/JS integration.
3. Trust Badge: "Powered by Blockrand - Externally Verifiable" to put on your UI.

this is just making things more complicated and adding another layer that players need to trust.

it's a cool concept. but as someone who has been gambling for many years now, and played games like dice, limbo, etc... on many sites.
i can tell you that no serious casino operator is going to use this for their in house games, cause imo, you are making a solution to a problem that doesn't exist (but this is just my opinion, i could be wrong).

Since I am not a gambling technical expert, I just discussed your theme. Gambling sites never want to share how their probably fair system works.

it's actually the opposite. any casino that has provably fair implemented correctly would want to share documentation on how it works and the logic they use to generate the results.

[rishib]

@Zwei — That’s a sharp technical critique, and you're spot on: Post-commitment, standard PF is mathematically sound if the player actively rotates seeds.

However, Blockrand is designed to solve for Pre-commitment Blindness, a trust boundary that standard PF cannot bridge.

To be technically concise:

"The Last Look" Gap: In classic PF, the operator generates and knows the Server Seed before the bet. While they can't change it once hashed, they have Pre-commit Visibility. In an adversarial model, this allows for "Seed Grinding" against default client seeds or cohort-based seed optimization.

Blindness vs. Honesty: Standard PF proves Honesty (I didn't change the number). Blockrand proves Blindness (I didn't even know the number). By using a future Drand round, the entropy literally does not exist in the universe at the moment the bet is locked.

Zero-Trust Coordination: Regarding the "extra layer," Blockrand isn't a source you must trust—it’s a coordination layer for Publicly Verifiable Entropy. Since Drand is a threshold-cryptography network (League of Entropy), the reveal is deterministic and independent. If Blockrand disappears, the round remains auditable against the global beacon.

The Use Case: I agree it’s not for 1ms slot loops. We are positioning this for High-Roller Toggles and Event-based outcomes (Jackpots/Lotto).

It’s not about fixing "broken" PF; it’s about offering a Stronger Fairness Primitive where neither the player nor the house has "Last-Look" knowledge. For a whale dropping $100/$1000 on a single roll, "The House is Blind" is a much more powerful claim than "The House is Honest."

Does that architectural distinction make the utility clearer?

The Industry Problem:
Standard "Provably Fair" systems (Server Seed + Client Seed) have a fundamental flaw: The house knows the server seed before the player places a bet. Even with a hash commitment, a malicious operator could pre-generate billions of seeds to find ones that favor the house against common client-side patterns.

favors the house how?

i mean, even with the house knowing the server seed, as long as the player sets their own client seed after the house commits to the hashed server seed, the house can't cheat.
not to mention, the house doesn't even know how you are going to play for them to give you a seed that favors them.

the only real industry problem is that some casinos don't implement provably fair systems the right way.

The Solution: Blockrand API
Blockrand introduces External Entropy into your game loop using the Drand Beacon.

• Phase 1 (Commit): Player bets; your game commits (with Player and Server Hash) to a future Drand round.
  
• Phase 2 (Wait): A 10-second window. The number literally does not exist yet on any server.
  
• Phase 3 (Reveal): The threshold cryptography network broadcasts the seed. The result is revealed.
  

Battle-Tested & Production Ready
We recently stress-tested this on Hacker News (reaching #1).

• 90% Retention: Proof that players prefer a 10s wait for 100% transparency over instant "trust-me" rolls.
  
• High Uptime: Handled 500+ rolls from multiple users with zero lag or failures.
  
• Fair Distribution: Verified hex-spread across all test bets.
  

THE OFFER: Free Managed Integration
I am looking for 2 active casinos or game developers (Dice, Crash, Coinflip) to be our anchor partners.

What you get:
1. Free API Access: High-limit access to the Blockrand randomness engine.
2. Hands-on Support: I will personally help your dev team with the Go/JS integration.
3. Trust Badge: "Powered by Blockrand - Externally Verifiable" to put on your UI.

this is just making things more complicated and adding another layer that players need to trust.

it's a cool concept. but as someone who has been gambling for many years now, and played games like dice, limbo, etc... on many sites.
i can tell you that no serious casino operator is going to use this for their in house games, cause imo, you are making a solution to a problem that doesn't exist (but this is just my opinion, i could be wrong).

Since I am not a gambling technical expert, I just discussed your theme. Gambling sites never want to share how their probably fair system works.

it's actually the opposite. any casino that has provably fair implemented correctly would want to share documentation on how it works and the logic they use to generate the results.

[Pmalek]

I received a PM to come and take a look at this proposal. Here are my comments.

Anything that makes gambling fairer and more transparent is a welcome move. Having said that, I don't see why the majority of online/crypto casinos would be on board with implementing a different system if the current one works well for them and makes them ridiculous amounts of money. Your randomness proposal would also have to undergo detailed and long testing before a serious casino would even consider implementing it. Still, the question remains whether they would ever agree to change. I don't think the online gambling industry suffers from a lack of clients even with this half-fair system, as you call it.

Then there is the question of the 10-seconds wait between two bets. Many bettors won't like it, especially not those who play fast-outcome, one-click games. I don't think patience is a big virtue among gamblers. Must this waiting time be 10 seconds? Is there a way to shorten it?

[rishib]

Thanks for the feedback, @Pmalek. You’ve highlighted the two biggest hurdles: Inertia and Latency.

1. Why would casinos change?
You're right—they’re making money now. But they are also losing it to "Scam Accusations" and reputation damage. Blockrand isn't just about "fairness"; it’s Reputation Insurance. A casino using this can prove they can’t selectively enforce ToS based on the outcome. In a saturated market, that "Mathematically Impossible to Cheat" label is a massive competitive edge for attracting whales.

2. The 10-Second Wait
You're spot on—10s (we can reduce it a bit to say 6 sec) is too slow for "one-click" games. We solve this via Optimistic Commitment:
- The bet is locked to Round X instantly.
- The game "spins" or "rolls" immediately for UX.
- Settlement happens the millisecond the beacon is broadcast.

For high-frequency play, we are also prototyping VDF-based entropy to provide sub-second local results that remain verifiable against the Drand anchor.

Do you think whales would trade a few seconds of "settlement" delay for a 100% guarantee that the house isn't looking at the seed?

I received a PM to come and take a look at this proposal. Here are my comments.

Anything that makes gambling fairer and more transparent is a welcome move. Having said that, I don't see why the majority of online/crypto casinos would be on board with implementing a different system if the current one works well for them and makes them ridiculous amounts of money. Your randomness proposal would also have to undergo detailed and long testing before a serious casino would even consider implementing it. Still, the question remains whether they would ever agree to change. I don't think the online gambling industry suffers from a lack of clients even with this half-fair system, as you call it.

Then there is the question of the 10-seconds wait between two bets. Many bettors won't like it, especially not those who play fast-outcome, one-click games. I don't think patience is a big virtue among gamblers. Must this waiting time be 10 seconds? Is there a way to shorten it?

[LoyceV]

a malicious operator could pre-generate billions of seeds to find ones that favor the house against common client-side patterns.

Can you give an example of a "common client-side pattern"? Users shouldn't use any pattern but create their own random client seed.

Phase 2 (Wait): A 10-second window.

How does a delay improve a provably fair system?

The number literally does not exist yet on any server.

That's because there's no reason to do so.

Battle-Tested
We recently stress-tested this
~
High Uptime: Handled 500+ rolls from multiple users

I wouldn't call 500+ rolls anywhere near "battle-tested", "stress-tested" or "high uptime". Try a billion rolls.

90% Retention: Proof that players prefer a 10s wait for 100% transparency over instant "trust-me" rolls.

Losing 10% of the players does not justify this conclusion.

3. The 'PF is Enough' Argument: While rotating client seeds works for sophisticated players, the vast majority of casual players never touch their seed. They just see a 'Server Seed' and wonder if the house is choosing a seed that hits their specific betting patterns. Blockrand removes that 'Server Seed' suspicion entirely by using a seed that does not exist yet when the bet is placed.

That's a weak argument: if a player doesn't care about changing the client seed, it means they're okay with trusting the casino. No need to change a good system because of that.

The "Trust Gap" happens when a high-roller wonders: "Did the casino generate a seed that specifically ensures my $10k bet loses?"

If a casino would do that, the player could game it by selecting the opposite and win.

It sounds to me like OP is selling a solution to a problem that doesn't exist. Even worse: it will be even more difficult to verify fairness on your own.

[Zwei]

"The Last Look" Gap: In classic PF, the operator generates and knows the Server Seed before the bet. While they can't change it once hashed, they have Pre-commit Visibility. In an adversarial model, this allows for "Seed Grinding" against default client seeds or cohort-based seed optimization.

let's say the house is doing what you are saying, how does that give them an advantage?
say they know what the next number is going to be, for example 22.22 on a dice roll. they still don't know, can't know how you are going to play on that seed, so that gives them absolutely zero advantage on you. so i have no idea what you are trying to make it sound like a flaw in PF.

Zero-Trust Coordination: Regarding the "extra layer," Blockrand isn't a source you must trust—it’s a coordination layer for Publicly Verifiable Entropy. Since Drand is a threshold-cryptography network (League of Entropy), the reveal is deterministic and independent. If Blockrand disappears, the round remains auditable against the global beacon.

The Use Case: I agree it’s not for 1ms slot loops. We are positioning this for High-Roller Toggles and Event-based outcomes (Jackpots/Lotto).

It’s not about fixing "broken" PF; it’s about offering a Stronger Fairness Primitive where neither the player nor the house has "Last-Look" knowledge. For a whale dropping $100/$1000 on a single roll, "The House is Blind" is a much more powerful claim than "The House is Honest."

Does that architectural distinction make the utility clearer?

i'm still not buying the need for something like that, when current provably fair systems work just fine and have been doing so for years now.

but here is a question for you from the business side. assuming a casino would want to implement a system like that, what's stopping them from doing it in house? after all drand which this is based on is public and open source and the concept of blockrand shouldn't be too hard to code and implement i imagine.
why use a paid third party API and trust them not to pull any shenanigans in the background?

[rishib]

Thanks for the direct feedback @LoyceV

I wouldn't call 500+ rolls anywhere near "battle-tested"... Try a billion rolls.

You’re 100% right. I’ll take the hit for that phrasing—500 rolls was internal dev-speak for "it didn't crash during the pilot," but in this community, that’s not "battle-tested." I’ll adjust the wording.

Can you give an example of a "common client-side pattern"? Users shouldn't use any pattern but create their own random client seed.

Ideally, yes. In reality, most (I would guess ~95%) of casual players never touch their client seed. This allows for Seed Grinding: an operator pre-calculating millions of server seeds to find one that results in a "house win" streak against that specific, static client seed. Standard PF prevents changing the seed after it's hashed, but it doesn't prevent the house from "choosing" a favorable seed to hash in the first place.

How does a delay improve a provably fair system?

The delay is a Security Buffer. Drand issues a beacon every 3s, but we enforce a window to ensure the player's and server's commitment are fully propagated and locked before the next beacon exists. Without this buffer, a malicious operator could intercept the beacon and "fake" a latency issue to reject a winning bet. The delay ensures a Symmetry of Ignorance: neither side can know the outcome until the bet is immutable.

if a player doesn't care about changing the client seed, it means they're okay with trusting the casino.

I disagree that apathy equals trust. Most players don't change seeds because of UX friction. Blockrand removes the burden of "manual verification" by ensuring the house literally cannot know the outcome when the bet is placed.

If a casino would do that, the player could game it by selecting the opposite and win.

Only if the player knows the seed is biased. If a whale is betting $$$ on a 50/50 roll, and the house has pre-calculated a seed where that specific roll is a loss, the player doesn't know to "switch."

Regarding verification: Every Drand round is public and immutable. Verifying a Blockrand roll is actually easier for a third party because you aren't checking a casino's internal database; you're checking a global public beacon.

[rishib]

let's say the house is doing what you are saying, how does that give them an advantage? ... they still don't know, can't know how you are going to play on that seed

They don't need to know your next bet if they have your historical data. If a high-roller follows a specific pattern (Martingale, specific increments, or a predictable "rhythm"), an operator with Pre-commitment Visibility can select a seed that contains a "red streak" exactly where that player’s math historically fails.

Standard PF is "Fair," but the house has a "Last-Look" at the result before the player does. Blockrand creates a Symmetry of Ignorance. Neither side knows the outcome until the bet is immutable. For a whale dropping $1k per roll, "The House is Blind" is a much more powerful psychological claim than "The House is Honest."

assuming a casino would want to implement a system like that, what's stopping them from doing it in house?

Absolutely nothing, and we actually encourage it. The SDK is open-source for that reason. Blockrand isn't a "black box" middleman; it's an infrastructure layer that makes the raw Drand beacon usable in a high-speed game loop via Optimistic Commitment. We provide the coordination logic to ensure that lock is ironclad. If a casino builds their own version of our logic, it still validates the "Double-Blind" standard we're pushing. We’re selling time-to-market and third-party auditability.

why use a paid third party API and trust them not to pull any shenanigans in the background?

That’s the beauty of it: You don't have to trust us. Since Drand is a public, deterministic beacon, anyone can verify that the "Blockrand Result" matches the "Drand Beacon" for that round. If we pulled "shenanigans," the mathematical proof of fraud would be public and permanent.

P.S. I’ve updated the OP to reflect that we are currently in the "Pilot Data" phase rather than "Battle-Tested," per the feedback from LoyceV. I appreciate the high bar this community sets for those terms.