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.
rishi_blockrand•2h ago
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.