Investigation: Luck.io Provably Fair Claims

Luck.io is one of the larger crypto casinos to market itself on an explicitly on-chain footing. It is built on the Solana-based Proov Protocol and described in its public materials as a decentralized, trustless, provably fair platform. In November 2025, ProvablyFair.org conducted an independent technical review of the whole platform: the on-chain programs, the randomness system, the game logic, the payout and reserve handling, and the public fairness claims attached to all of it.

This post focuses on the part of that review most relevant to provable fairness: whether a player can actually verify that a Luck.io game outcome is honest. The short version is that they cannot, and the reason is structural. Luck.io adopted the vocabulary and several of the visible components of a trustless, provably fair system, but stopped short of the implementation that would make those words hold. The result is a platform that looks verifiable from the outside while the operator retains the control the design was supposed to remove.

It is worth saying clearly at the outset that the direction Luck.io was pointing in is a good one. An on-chain casino with verifiable randomness, non-custodial fund handling, and outcomes anyone can check is a genuinely worthwhile goal, and some form of that design is likely to succeed over the next few years. The problem here is not the ambition. It is the gap between the ambition as marketed and the implementation as built.

What Luck.io claims to be

Luck.io’s public positioning rests on three words: provably fair, decentralized, and trustless. Each carries a specific technical meaning.

Provably fair means a player can independently verify that a game outcome was generated honestly and not manipulated. Decentralized means no single party controls the system. Trustless means the design does not require players to trust the operator’s good behaviour, because the rules are enforced by code rather than by a company. These are strong claims. They are also the claims the on-chain framing is meant to deliver: randomness recorded on a public chain, funds held in smart contracts, outcomes anyone can recompute.

Luck.io implements a recognisable shape of each of these. Randomness is produced by a Verifiable Random Function and posted on-chain. Player funds are held in an on-chain vault rather than a company wallet. Outcomes carry cryptographic proofs. On the surface, the architecture reads as the real thing. The review’s central finding is that in each case the implementation stops at the point where it would actually constrain the operator.

The randomness: verifiable, but not trustless

Luck.io’s randomness comes from Proov’s VRF oracle network. When a player places a bet, a request goes to a set of oracle nodes that generate a random value and return a signed VRF output recorded on-chain. The signatures let anyone confirm, after the fact, that a given random value is authentic and was not altered. That part works as described.

The problem is who runs the oracles. A VRF network provides meaningful fairness guarantees only if the oracles are operated by independent parties, or if the protocol structurally prevents the oracle from choosing which random value to publish. Neither condition holds here. The review identified four oracle signer keys in the Proov code, and found no evidence that any of them are run by independent operators. The oracle set is permissioned, closed to outside operators, and appears to be controlled entirely by the team.

That matters because of what the protocol does not do. There is no on-chain commit-reveal scheme binding a random value to a specific bet before the value is drawn. Bets are initiated off-chain, and only the final VRF result is posted on-chain. Nothing forces the random value to be derived from a fixed block hash or slot, and nothing enforces that only one VRF output can ever be produced for a given bet. Taken together, this means an oracle operator can generate multiple candidate random values for the same bet privately, and publish only the one that suits the house. Once that result is on-chain, it carries a perfectly valid VRF proof. To an outside observer it is indistinguishable from an honestly drawn result.

The review demonstrated this conceptually rather than alleging it occurred: by simulating the VRF process, it was possible to take a bet that produced a winning outcome and, by trying a different VRF proof, re-roll it into a losing one, then present the losing proof as the official result. The cryptography still checks out. That is the point. A VRF proves a number was generated by a particular key; it does not, on its own, prove the operator did not quietly discard the numbers it did not like.

So the randomness is verifiable after the fact, but it is not provably fair in real time, and it is not trustless. A player can confirm a result is internally consistent. They cannot confirm it was not selected. The distinction is the entire difference between “provable” and “verifiable-looking.”

The “Custom Seed” option does not affect the outcome

Luck.io’s interface includes a “Custom Seed” field, which presents players with the familiar provably fair idea that their own input contributes to the randomness. In a correctly built commit-reveal system, the client seed is a real defence: because the player’s value feeds into the function that produces the outcome, the operator cannot have pre-selected a result.

On Luck.io, the review found that the Custom Seed has no cryptographic effect on the outcome. The value is accepted in the interface, but it is not combined with the Proov VRF hash and is not stored on-chain. There is no verifiable link between what the player enters and the random value their bet resolves against. The randomness remains entirely dependent on the team-controlled oracles. The feature has the appearance of player-contributed entropy without the function of it.

This is the clearest single example of the pattern that runs through the whole platform: a recognisable provably fair component is present in the interface, but the part that would actually transfer control to the player is missing.

The game logic is off-chain and closed

Even a perfectly fair random number only matters if the logic that turns it into a result is honest. On Luck.io, that logic is entirely off-chain.

The Proov on-chain programs handle two things: a Vault that custodies player funds, and a Slot program that records bets and triggers settlement. Neither contains the actual game mechanics. When a bet is placed, the VRF random value is passed to Luck.io’s backend servers, and the mapping from that value to a result, the reel positions, the card draws, the crash point, the win or loss, is computed in proprietary, closed-source code on centralized infrastructure. The on-chain Slot program receives only the final outcome and instructs the Vault accordingly.

This means a player cannot verify the step that decides whether they won. The random value is on-chain and checkable; what the casino did with it is not. Key game parameters, house edge, payout distributions, jackpot rates, are held in the backend as configurable values, not fixed on-chain. The review found game distributions defined in the backend with editable parameters such as a house edge field. The operator can change these at any time, with no on-chain transaction and no public notice. There is no programmatic guarantee of a fixed return-to-player figure, because the figure lives in a database the operator controls.

The review was able to reproduce one test bet using a simulation function, and the result matched. But that was only possible because the function was provided in the audit context. A regular player has no such function for any game. For everyday use, the outcome calculation is a black box, and the “provably fair” claim covers only the randomness feeding into that box, not anything the box does.

Funds, reserves, and contract control

The financial side of Luck.io comes closest to the trustless ideal, and is still only partway there. On the positive side, player funds are held in an on-chain Vault rather than a company wallet, and routine payouts are settled by smart contract: a standard win is paid by code, automatically, and cannot simply be refused while the Vault holds funds. That is a real improvement over a conventional casino.

The limits sit around that core. The Proov contracts are upgradeable and pausable by the team, with no DAO, multisig, or timelock on the administrative authority, so new code could be deployed or games paused unilaterally. The “cold bankroll” reserve used for large payouts is not a contract at all but a team-controlled wallet; its balance is visible on-chain, its use is not constrained. There are no enforced reserve ratios and no cryptographic proof of liabilities, so the “proof of reserves” claim amounts to “you can see our wallet balance,” not “the funds owed to players are provably secured.”

Where this becomes concrete is large or unusual payouts. The review found cases where a payout to a winning wallet could not be cleanly traced to the public Vault or reserve accounts, which suggests it may have been settled out of band from another wallet. The review treated this as a transparency failure rather than proof of misconduct, the honest position, since on-chain tracing simply could not confirm where the funds came from. But that uncertainty is itself the finding: in a genuinely trustless payout system, there would be nothing to be uncertain about.

Half-implemented trustlessness

Putting the pieces together, a consistent pattern emerges. In each part of the system, Luck.io implemented enough to support the claim and stopped before the part that would have made the claim binding.

• Randomness is on-chain and VRF-signed, but the oracles are team-run and nothing prevents selective publishing.
• The client seed is offered in the interface, but does not enter the randomness calculation.
• Game logic produces outcomes from the randomness, but runs off-chain in closed code the player cannot inspect.
• Funds sit in an on-chain vault, but the contracts are upgradeable and pausable by the team with no governance constraints.
• Reserves are visible on-chain, but unlocked, unaudited, and movable by the team at will.
• The security audit is cited for credibility, but the full report was not published.

Each line is the same shape: the visible, trust-signalling half is present; the constraining half is not. The consistency of that pattern across every part of the system is itself notable. Whatever the intent behind it, the effect is a system that conveys decentralization, trustlessness, and provable fairness while the operator retains the control those properties are specifically meant to remove. The blockchain vocabulary, on-chain randomness, VRF proofs, non-custodial vaults, is doing reputational work that the implementation underneath does not support.

The nature of this failure is worth being precise about. There is no modified probability table here, and no decorative verifier returning made-up results. Luck.io’s components are real and, in isolation, technically sound. The failure is at the level of the claims: novel, technical-sounding language, “on-chain,” “trustless,” “VRF,” “decentralized,” applied to a system that does not deliver what those words promise. That is arguably harder for a player to see through, because the architecture genuinely is more sophisticated. Sophistication is not the same as verifiability, and a more advanced-sounding stack can make a verification gap harder to notice rather than easier.

The idea is right; the execution was not

None of this means the model Luck.io was reaching for is wrong. An on-chain casino with genuinely independent or beacon-based randomness, game logic that is open-source or executed in a verifiable program, governance protected by multisig and timelocks, and reserves provably locked by contract, would be a real advance on both traditional online casinos and most current “provably fair” implementations. The review’s recommendations point in exactly that direction: decentralize the RNG or add an enforced commit-reveal, open-source the game logic or move it on-chain, add real governance, make payouts and reserves provable, and publish the full audit.

We expect some version of that design to succeed within the next few years, and we think it should. The issue with Luck.io specifically is the order in which it did things: it claimed the destination before building the road to it. The technology and the language were adopted ahead of the implementation that would make them true. For a player, the practical consequence is simple. On Luck.io as audited, “provably fair,” “decentralized,” and “trustless” describe the marketing. They do not yet describe the platform.

The most useful thing a player can do is separate the two layers the platform blends together. The randomness can be checked. The game logic, the odds, the reserves, and the contract authority cannot. Until that second layer is verifiable too, Luck.io is a casino with some on-chain transparency attached, not a trustless one, and it should be read that way regardless of the vocabulary on the page.