Game Logic Verifiability

While the random number generation is recorded on-chain, the game outcome logic that interprets randomness and calculates payouts is entirely off-chain and proprietary. This section examines how game rules are handled and the transparency issues therein.

Off-Chain Outcome Determination: For each bet, once a VRF random seed is obtained, Luck.io’s backend uses it to determine the game result. No smart contract on Solana is executing the actual game mechanics (e.g. dealing cards, spinning reels, or picking a crash point) — those computations occur on the centralized server[36]. The on-chain Slot program only receives the final outcome and triggers fund transfers accordingly. This design means players cannot independently verify the mapping from random input to outcome using on-chain data alone.

For example, consider a slot machine spin: the VRF might yield a random hash, but how that hash is mapped to specific reel symbols and whether the spin results in a win is determined by Luck.io’s closed-source code. If Luck.io claimed a 95% RTP (return-to-player) for a game, users have no on-chain evidence to confirm that odds or payout tables are implemented as stated[13]. Unlike some other crypto casinos that publish game algorithms or use client-side code, Luck.io does not expose its game logic for public audit. Halborn’s audit explicitly flagged the “reliance on off-chain critical logic” as a concern: the fairness of outcomes relies on backend code outside the blockchain’s purview[10].

Opaque RTP and Payout Parameters: We found that key game parameters (house edge, probability distributions, jackpot rates) are configurable by the operator and are not immutable on-chain. In the backend database, each game refers to a distribution ID with parameters such as edge (%), max multiplier, bet limits, etc. – one example shows a JSON snippet for distribution_id 10050 with an edge: 0.02 (2% house edge) and other limits[13]. These settings can be changed by Luck.io without any on-chain transaction or public notice. In other words, the casino can alter the payout odds or jackpot frequency off-chain at any time. The smart contracts do not contain these values, so there is no programmatic guarantee of a fixed RTP. This undermines the “provably fair” concept: provable fairness extends only to the randomness, not to how that randomness is used.

Because the logic is closed, players must trust that the outcome calculation is honest. A malicious implementation could, for instance, detect a certain pattern and reduce payouts or silently increase the house edge after large wins, etc., all invisible to the user. Our audit did not find evidence of specific manipulations in the provided data – for one test bet, we were able to recompute the outcome with a provided simulation function (simulate_mines) and it matched the recorded result. However, this verification was only possible because the simulation function was shared in the audit context. Regular users do not have access to such functions for every game.

Halborn Audit’s Note: The Halborn security assessment also acknowledges that critical game computations occur off-chain (marked as an informational issue) and cannot be verified on-chain[36]. Essentially, Proov’s on-chain programs handle fund custody and tracking, but not the actual game fairness logic. Compared to some competitors, Luck.io’s approach is less transparent: e.g., BC.Game uses a client-server seed that players can verify, and some of its simple games run in auditable browser code[15], whereas Luck.io’s game outcomes are determined in a backend “black box.”

Implication: This lack of verifiable game logic means that Luck.io is not fully trustless – even if the RNG were perfectly fair, a player cannot prove that the casino didn’t skew the outcomes or payouts after the random draw. It also means any claims about RTP or odds cannot be independently confirmed. From a security perspective, this is a central point of failure: if the backend were compromised or malicious, it could systematically cheat players without the smart contracts detecting it.

Recommendation: To improve trust, Luck.io should publish the game logic or move it on-chain. Ideally, the outcome determination for each bet would be executed by a smart contract or a publicly verifiable program (e.g. a transparent WebAssembly module or zk-SNARK proof) that players or third-party auditors can inspect[50]. At minimum, making the game algorithms open-source (or at least publishing cryptographic hashes of the code and committing not to change them without notice) would allow the community to audit the fairness. Without this, Luck.io’s fairness claims hinge entirely on trusting their team and the promised Halborn audit results – which, as noted below, have not been fully released to the public.