We found developers with a ready-made project who were just missing a solution with a randomization protocol that was secure for both themselves and their users.
Thanks to the well-thought-out simplicity of integration that we built into the foundation of our protocol, everything went smoothly.
Final testing is currently underway. So, in the next 2 hours, expect a major announcement regarding the first full-fledged project based on our protocol.
Yesterday, we found the first three completely independent smarts that are ready to take on the role of operators in our protocol.
We’re currently working with them, which means we’ve already taken a step toward full decentralization.
Also, don’t forget: if you’re a developer and want to collaborate - whether on the project or the operational side - send us a DM.
Good morning,
First of all, thank you for such a strong start—even though the subsequent outcome was rather disappointing, as you can now see on the token’s chart.
Be that as it may, the technology is alive and well, fully functional, and hasn’t gone anywhere.
You still have a chance to get involved and become a part of it.
Everything you asked for is done.
Burn done. DEX paid.
Whose were your wishes. Now ours.
We built RH-VRF because a game should not be able to cheat you and neither should the people running the randomness behind it. Nine machines. Five signatures. A key that has never existed anywhere as a whole.
Live on mainnet. Median three seconds, measured.
The token was the last thing we built. But the work is not yet finished
Yes, and it is where this goes.
The service already produces what a token can honestly attach to: a fee on every fulfilled request. What is missing is not a mechanism, it is independence. While every operator is us, any cut we take is us paying ourselves
Once they are not us: stake to claim one of the nine seats, with delegation so the buyer is not limited to nine people. Seats go to whoever has the most stake behind them, and slashing has teeth, because a node that signs two different shares for one seed leaves a proof anyone can check
A share of every fee then buys the token and burns it. Note the direction. The protocol earns in the chain's coin and buys the token, rather than accepting the token and selling it
Operators stop needing to be paid entirely in fees, because they hold a bond that rises with the buybacks their own work funds. Gas stays reimbursed in the chain's coin: one that cannot pay it stops publishing, whatever its stake is worth
None of it is built yet, and independence comes first
So yes, not just possible. Part of the plan
Yes, and it is where this goes.
The service already produces what a token can honestly attach to: a fee on every fulfilled request. What is missing is not a mechanism, it is independence. While every operator is us, any cut we take is us paying ourselves
Once they are not us: stake to claim one of the nine seats, with delegation so the buyer is not limited to nine people. Seats go to whoever has the most stake behind them, and slashing has teeth, because a node that signs two different shares for one seed leaves a proof anyone can check
A share of every fee then buys the token and burns it. Note the direction. The protocol earns in the chain's coin and buys the token, rather than accepting the token and selling it
Operators stop needing to be paid entirely in fees, because they hold a bond that rises with the buybacks their own work funds. Gas stays reimbursed in the chain's coin: one that cannot pay it stops publishing, whatever its stake is worth
None of it is built yet, and independence comes first
So yes, not just possible. Part of the plan
1. Are the 9 nodes truly independent operators?
No. All nine are run by us today. They sit on separate hosts across several providers and countries, but one team holds the access, so treat it as one party with nine machines, not nine parties.
What is already true: the group key came from a networked ceremony, so no machine ever held it whole. What is not yet true is independence of the operators themselves. An on-chain registry and staking are the way there, and neither is built.
2. Is the source of the threshold/BLS implementation public?
The contracts are, and fully verified. Links below. The operator node is not public yet.
We wrote no cryptography. Pairing, hash-to-curve and the curve arithmetic are kevincharm/bls-bn254; the DKG is drand/kyber. Both public, both widely used. Our code is the plumbing around them.
3. How are keys, DKG and rotation done?
Each operator generates its identity on its own machine; the private half never leaves it. Pedersen DKG over BN254, run across the network, one process per operator, no machine holding more than its share. Every participant prints the resulting group key at the end, and they must all match or nothing is deployed.
Rotation is resharing: it changes the shares and preserves the group public key, so the verifier address and every integration stay put. Tested, including swapping an operator out.
One caveat we will not hide: seven of the nine machines currently run on temporary hosting, so we hold an encrypted backup of the shares against losing them all at once. That weakens the property above, we know it, and it is destroyed when the fleet moves to permanent servers.
4. Contracts verified?
Yes, all three, full match on Sourcify. Source and deployed bytecode agree byte for byte:
VRFCoordinator 0x1637195a674630E475ACD18B3D27b13C0EefDac1
Subscription 0x3fbFE73935B729C6A30AE6060D5708215b3633f5
VRFVerifier 0x035299fe87211f35f5F36FBBa67919f9545dDd16
5. Third-party audit?
No. We ran an internal one: twelve findings, four fixed in code, and 205 tests including sixteen written as attacks. That is not a substitute and we do not present it as one.
Are the 9 nodes truly independent operators?
Is the source code of the threshold/BLS implementation publicly available?
How is the generation of node keys, DKG, and rotation mechanism carried out?
Has the contract source code been fully verified?
Is there any third-party security audit?
Is there a real project that continuously uses it, rather than just deploying and demonstrating by oneself?
23,620,989 $RHVRF burned
2.36% of supply sent to 0x…dEaD where nobody moves it again
Don't take our word for it. It's on chain: https://t.co/u3vzUs069g
Same rule as everything else we build.
$RHVRF is live
The randomness it belongs to has been running on Robinhood Chain mainnet since day one
ca: 0xb8276B1ab93474C8675e5c22Aad529D62c6c4cd0
https://t.co/GYi9q4io6v
rhVRF vs. Dice: Architecture & Threat Model
Dice uses a single-provider commit-reveal scheme. Since the provider acts last, they hold selective withholding power explicitly stated in their own docs: "The provider can still withhold a reveal." If an outcome is unfavorable, they can simply stall for 60–90s to trigger a refund.
How rhVRF changes the game:
Deterministic State: Our threshold signature over the seed is finalized before exposure.
Collusion Resistance: No single actor can opt out. Once 5 of 9 shares are gathered, anyone can publish. Stalling requires active 5-of-9 collusion.
The Economic Trade-Off:
Dice: 1 provider | Low gas | Ideal for low-value mints & lootboxes.
rhVRF: 5-of-9 threshold | Maximum integrity | Built for high-stakes bets & real value.
## . Event hints on top of polling
- Added an optional subscription that tells the poll loop to look now, instead of replacing the poll loop with it.
- Kept the poll as the only thing that decides what gets signed, so a hint endpoint that dies, lies or never connects costs latency and nothing else.
- Made a burst of hints coalesce into one scan, so a flood of events cannot become a flood of chain calls.
- Fixed a dead subscription becoming a busy loop, since a closed channel is always ready to receive.
- Added reconnection with backoff and jitter, so operators that lost the same endpoint do not all come back at the same moment.
- Cut request discovery from three seconds to one where the endpoint was fresh.
- Measured that log indexing on the available endpoints lags between 3.6 and over 40 seconds and varies by the minute, which the poll interval had been hiding.
## . Mainnet
- Deployed the verifier, the coordinator and the accounting contract to mainnet.
- Confirmed the deployed key hash matches what every operator produced in the ceremony.
- Wrote a separate deployment script for mainnet that refuses a group key built in a single process, refuses to leave operators unpaid for the gas they burn, and refuses to reuse an existing deployment.
- Set the price from measurement: a base covering the verification, a marginal price per word, and a price per unit of the callback budget a consumer asks for.
- Made the coordinator charge for the callback budget requested rather than used, so the price can be quoted when the request is made and asking for less costs less.
- Handed the coordinator and the subscription account to their owner in two steps each.
- Pointed the site at mainnet and moved the addresses into the code, since a verifier is immutable and there is nothing left for a build variable to vary.