RNG and Oracle Control Analysis

Luck.io relies on Proov’s VRF-based random number generation, which is advertised as decentralized but is, in fact, under centralized control. We examined how the RNG is produced and identified a potential vulnerability: because the same team controls all oracle nodes, they could manipulate outcomes by selective publication of random seeds.

VRF Oracles and Potential Manipulation: The Proov network uses multiple oracle signers to generate each random outcome. In principle, requiring several independent oracles to sign a VRF output is meant to prevent any single party from tampering with the randomness[1]. However, our investigation found no evidence that these oracles are run by independent parties – on the contrary, all known VRF signer keys are likely operated or authorized by the Luck.io/Proov team[1][2]. The oracle network is closed to external operators (no public instructions for anyone to run a node), indicating a permissioned setup[3]. Four oracle public keys were identified in the Proov code, suggesting a fixed small signer set fully under project control.

Crucially, nothing in the on-chain protocol prevents the oracles from re-rolling random outputs before finalizing a result. Because bets are initiated off-chain and only the final VRF result is posted on-chain, a malicious or insider-controlled oracle could internally generate many candidate random values and only publish the one that favors the house[4][6]. There is no commit-reveal or timestamp binding the random seed to the moment the bet was placed: - No pre-commitment: The system does not hash or commit the user’s bet and a random nonce on-chain before revealing the random number[6]. This means the oracle’s VRF generation isn’t verifiably tied to a unique bet ID or timestamp at the time of bet placement. - No enforced timestamp/slot: The VRF output isn’t derived from a specific blockchain slot or block hash; it’s purely generated by the off-chain oracles and then submitted. An oracle could delay responding until it finds a favorable number. - Duplicate nonce risk: While each bet has a nonce/counter, the protocol doesn’t enforce that only one VRF output can be produced per nonce in real time. The oracles could discard a result and generate a new one under the same nonce if done privately.

This selective publishing attack means the VRF randomness, though cryptographically verifiable after the fact, cannot guarantee fairness if the source is untrusted[13]. Our team demonstrated this conceptually: by simulating the VRF process, we found that it was possible to iterate multiple VRF attempts for a given bet until a losing outcome was found, and then use that as the “official” result. In one example, a bet that would have won (target multiplier 25x, initial VRF gave a win at ~29.44x) was re-rolled into a losing outcome simply by trying a different VRF proof – underscoring that “so much for having VRF” if the oracles are colluding. Once the losing VRF proof was published on-chain, it appears perfectly legitimate to observers, even though it was potentially cherry-picked.

Lack of Oracle Governance: Another issue is the absence of any on-chain governance or rotation for the oracle nodes. We did not find a public set_oracle_signers function or similar admin interface in the audited contracts that would allow a community or decentralized mechanism to change or add oracles[32]. All control of oracle selection lies off-chain with the team. This means trust in RNG = trust in the team’s honesty, a centralization that conflicts with the “provably fair” ethos. The Halborn audit’s findings also highlight this as an acknowledged issue: “Reliance on off-chain critical logic” (the VRF mechanism being off-chain) was noted, implying the fairness of randomness ultimately depends on an off-chain process[47].

Player Seed (Client Seed) Implementation – Cosmetic Only: Luck․io’s recently added “Custom Seed” (player seed) input gives the impression that users can influence randomness[42], but review of the Proov VRF integration and bet logs confirms it has no cryptographic effect on outcomes[45]. The value is accepted in the UI but not combined with the Proov VRF hash or stored on-chain, providing no verifiable linkage between player input and the resulting RNG [43][44]. In effect, the feature is purely cosmetic—randomness remains entirely dependent on team-controlled oracles[45].

In summary, the RNG is only partially decentralized. The VRF approach would provide strong fairness guarantees if the oracles were truly independent or if a commit-reveal scheme prevented reseeding. In Luck.io’s current design, however, the operator has the technical capability to influence random outcomes undetected, presenting a critical risk to game fairness: - Probability of exploitation: Only the insider team or a compromise of their oracle keys would be required – no complex hack needed, just abuse of authority[1][2]. - Impact: This could covertly tilt odds (e.g. prevent jackpots or big wins) while still showing legitimate VRF proofs on-chain, breaking the trust of the “provable fairness” claim[38].

Mitigations: To address this, we recommend (details in Conclusion) that Luck.io/Proov integrate on-chain enforcement for randomness (e.g. using an external oracle like Chainlink VRF which automatically includes commit and reveal tied to a specific request) or implement a system where the user’s bet and a random seed commitment are posted on-chain before the actual random draw[45][46]. Additionally, opening the oracle set to multiple independent operators or a DAO-run oracle pool would vastly improve trust in the RNG process[32][50].