Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Luck.io presents itself as a “decentralized, trustless casino” leveraging blockchain. Our findings show a mix of decentralized and centralized elements. We summarize which components are trustless vs. which require trust in the operator:
Random Number Generation: Partially decentralized. The RNG uses a VRF and posts results on-chain, which is verifiable after the fact[1]. However, because the VRF oracles are centralized (team-run), the process is not trustless. Users must trust the operator not to manipulate or delay the random draws[4][5]. (In a truly decentralized scenario, oracles would be independent or the randomness would come from a public beacon; that’s not the case here.)
Game Outcome Logic: Centralized. All game rules (win conditions, payout calculations, jackpot triggers) are executed off-chain by Luck.io’s servers[15]. There is zero on-chain enforcement of game fairness beyond the input randomness. This means players trust the casino’s backend entirely for correct outcomes. Competitors like BC.Game allow client-side verification of results via seeds, which Luck.io does not provide[15]. Luck.io’s model is closer to a traditional online casino with a blockchain RNG attached.
Payout Execution: On-chain but with caveats. The normal payout logic is handled by Solana smart contracts (Vault program) – this is a strong decentralized element[9]. It ensures that if a win outcome is recognized by the system, the payout cannot be arbitrarily withheld and is processed by code (assuming liquidity is there). However, because the input to that logic (the win recognition) is off-chain, this guarantee is only as good as the off-chain component. Additionally, if liquidity is insufficient, the contract on its own can’t mint money – it still relies on the team to top up reserves. So payout enforcement is decentralized, but payout permissioning has a central link.
Player Funds Custody: Non-custodial but operator-administered. Players deposit to a smart contract, not to the casino’s private wallet – a positive aspect. This means the casino cannot misappropriate funds without leaving an on-chain trace. However, these contracts are admin-owned (not user-owned like a personal wallet)[40]. The team has the power to move funds between their own contracts and wallets, and possibly to halt withdrawals via upgrades. So while funds are on-chain (transparent), they are not under user control during play. The casino effectively custodies funds via smart contract, which is safer than pure centralized custody but still requires trust in the contract’s owner.
Reserves and Liquidity: Transparent but not trustless. Luck.io’s bankroll addresses are known, and anyone can inspect balances (unlike in a centralized casino where you rely on financial statements)[24]. However, “proof of reserve” is superficial – there’s no cryptographic attestation of liabilities, no enforced reserve ratios, and the funds can be moved by the team freely. We categorize this as centralized control with a veneer of transparency. It’s better than nothing (you can catch if they empty their vault), but it doesn’t prevent insolvency or misconduct.
Security Audit and Code Transparency: Opaque. Luck.io’s team points to a Halborn security audit for credibility, but the actual report was not publicly released on their site or GitHub[36]. Only a summary and a FAQ were provided, and obtaining full details requires directly contacting the team. This is an unusual practice in DeFi/crypto, where audits are typically published for community review. The fact that “trusting in an invisible audit is functionally no better than no audit at all” was noted in our assessment. Moreover, the platform’s code (especially game logic) is closed-source. This means the community cannot self-verify the security beyond what the team and their auditors claim. True decentralization would involve open-sourcing contracts and ideally the client code.
We can identify central trust points that currently exist in the Luck.io/Proov ecosystem: - Luck.io backend – controls game configurations, odds, and when to trigger settlement. - Proov oracles – generate randomness; if compromised or instructed, could bias results. - Team wallets (reserves) – hold the money; if those are mismanaged or if an insider theft occurs, players could lose funds (though on-chain evidence would be visible after the fact). - Upgrade/Audit opacity – the player community must trust that the code running is the same code audited, and that no malicious updates have been added; without a public audit or versioned code, this trust is unverified.
In conclusion, Luck.io is not fully decentralized or trust-free at present – it is a hybrid model. It leverages blockchain for certain integrity guarantees (non-custodial holding of funds during bets, tamper-evident RNG outputs), but retains centralized control in many areas. Players should be aware that they are ultimately betting on a platform where the operator must still be trusted for fair play and solvent payouts. The next section provides our risk assessment and suggests steps Luck.io should take to move toward the trustless ideal it advertises.
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.
Luck.io, a crypto casino built on the Solana-based Proov Protocol, purports to be a “provably fair” and decentralized gambling platform. Our security audit finds that while some components are on-chain (e.g. random number generation and vault-based payouts), critical aspects remain centrally controlled, undermining full trustlessness.
Key findings include:
Randomness Generation (RNG) – Luck.io uses a VRF-based oracle network (Proov) to generate random outcomes on-chain, but all VRF oracles are team-operated, allowing potential cherry-picking of favorable outcomes before publishing[36][44]. There is no on-chain commit-reveal scheme binding randomness to bets, meaning the operator could re-roll random seeds off-chain until a desired result is obtained[2][3].
Game Logic & Fairness – The mapping of random outputs to game results (slot reels, card draws, etc.) is executed off-chain in Luck.io’s backend. Game logic and payout rules are not enforced by smart contracts or publicly verifiable code, so players must trust the operator on house edge and win calculations[10][11]. The platform does not publish return-to-player (RTP) or odds on-chain, and Halborn’s audit confirmed reliance on off-chain critical logic** for outcomes[10][13].
Jackpot Anomalies – An investigation into a recent jackpot winner’s wallet uncovered red-flag behavior: a fresh wallet funded by large exchange deposits that hit two large jackpots in a short span. The odds of two jackpot wins in ~5,000 plays are ~0.00125% (∼1 in 80,000) under fair conditions[22], raising concerns of potential backend manipulation or insider advantage. The wallet showed ephemeral usage (no DeFi/NFT activity, only rapid micro-bets across casinos) consistent with a “sniper” bot or aided account[16][17].
Smart Contracts & Admin Controls – Luck.io employs on-chain programs (Vault and Slot) to custody funds and automate payouts, providing non-custodial player deposits and instant settlement in principle[12][13]. However, administrative privileges remain with the team: the Proov contracts are upgradeable and/or pausable by a central authority (no evidence of DAO governance or multisig protection)[31][32]. This means the operator could alter game contracts or freeze payouts unilaterally, contrary to full decentralization.
Payout Mechanics & Liquidity – Routine win payouts are handled by on-chain vault logic, and Luck.io claims even large wins (e.g. $500K) are auto-paid from an on-chain “cold bankroll” reserve[16]. In practice, jackpot payouts were not traceable to the public bankroll contracts, suggesting they may be settled via internal wallets off-chain[24][25]. While players can see casino wallet balances on Solana, there is no cryptographic proof of reserves or liabilities – balances can be moved by the team at will (albeit transparently on-chain)[25][26].
Overall, our assessment concludes that Luck.io’s architecture is a hybrid of on-chain and off-chain components. It offers better transparency than a traditional casino (on-chain RNG proofs and fund custody), but falls short of a fully trustless system. Critical trust points – centralized RNG oracles, closed-source game code, team-controlled wallets, and an unpublished code audit – mean users must ultimately trust Luck.io’s operators. We outline below the technical architecture, identified risks, and recommendations to strengthen the platform’s security and fairness.
Risk Assessment: From a security perspective, Luck.io’s current design presents a moderate to high risk to fairness and user trust. While no direct exploits (e.g., hacks or vulnerabilities) were identified in the on-chain code, the architecture choices introduce these key risks:
Fairness Risk (Critical): The central control over RNG and game logic means a rogue operator or compromised insider could secretly manipulate game outcomes without immediate detection [11]. This is a critical risk because it strikes at the core promise of the platform (provable fairness). The jackpot anomaly, though not proof of wrongdoing, exemplifies why this risk is not just theoretical.
Custodial/Financial Risk (High): Users’ funds, though on-chain, are managed by the casino’s contracts. The team’s ability to pause or upgrade contracts, and the lack of strict reserve safeguards, means there is a high counterparty risk similar to a traditional casino. In extreme cases, withdrawals could be halted or funds moved in ways users don’t expect (even if only temporarily) [40].
Centralization Risk (High): The dependency on the team for oracle operation, contract governance, and maintenance concentrates a lot of power in one entity. Should that entity act maliciously or incompetently, the platform’s integrity could fail. This risk is high in impact (it affects all users) but can be mitigated by decentralizing those roles.
Transparency Risk (Medium): The opaque audit and closed-source code present a medium risk to security assurance. It’s possible the code is secure (Halborn did review it), but without public scrutiny, vulnerabilities or backdoors (intentional or not) might go unnoticed by the community. The impact is potentially critical (if an undisclosed issue exists), but we rate it medium due to some external audit presence.
Operational Risk (Low/Medium): Typical technical risks like smart contract bugs were largely addressed by the professional audit (only informational issues remain like off-chain logic reliance) [11]. We did not find evidence of unresolved critical vulnerabilities in the on-chain programs. So pure technical bug risk is low to medium (given complexity of vault logic, etc., but Halborn found no remaining critical flaws).
Overall, in its current state we would not consider Luck.io trustless. It has significant centralization points that a security-conscious user should weigh. That said, these are issues that can be addressed. Below we outline recommendations to reduce or eliminate these risks. Implementing these would move Luck.io closer to a truly fair and decentralized model and align it with best practices in blockchain gaming.
A special focus of our audit was an alleged jackpot incident: a single player wallet that hit two major jackpots in a short timeframe. We analyzed on-chain data for that wallet and the associated transactions to assess whether this could be a coincidence or if it suggests exploitation or insider activity.
Wallet Profile: The wallet in question (address beginning 5or7BFp...) exhibits atypical behavior for a casual player[]: - It was funded by two large deposits from a centralized exchange (Kraken), each >600 SOL (worth $60k+), shortly before the jackpot wins[]. This indicates a deliberate funding event, possibly for the purpose of high-rolling. - The wallet engages almost exclusively in gambling dApp transactions – not just on Luck.io but also very small micro-transactions to other Solana casinos like flip.gg and solwheel.vip[]. It sent 10–30 rapid micro transfers (0.000005 SOL each) in batch sequences, which could be testing interactions or manipulating on-chain state (though the amounts are tiny). - There is no typical user activity: it holds virtually no other tokens (only 0.001 USDC, no NFTs) and never did staking or DeFi trades[]. This suggests it’s a throwaway wallet, used solely for short-term betting[]. - The timing of bets is concentrated. We observed the large SOL inflows, then heavy betting activity around the time of the known jackpot wins, and afterwards, large outflows (200–230 SOL in single transactions) to other wallets[]. It appears the wallet was emptied not long after hitting wins.
These patterns are red flags. As noted in our investigation: the wallet “appears ephemeral (created for short use)... shows two large Kraken deposits, followed by two publicized jackpot wins... bulk plays seem focused around the jackpot hit window”[]. Such behavior is consistent with either: - a “sniper” strategy – a user (or bot) that specifically targets jackpot conditions, possibly by exploiting knowledge of how to trigger them (if any weakness is known in RNG or game logic), or - a privileged/assisted account – potentially controlled or aided by insiders with knowledge of when a jackpot might payout or with the ability to influence outcomes.
Luck.io’s team advertised these jackpot wins publicly as proof of big payouts, but without further transparency, the circumstances are suspicious. A normal player hitting two jackpots by chance in short order is extraordinarily unlikely.
Statistical Improbability: We calculated the probability of this event assuming the game was fair. If the true odds of a jackpot on each play are, say, 1 in 1,000,000 (0.0001%), and the wallet made roughly 5,000 bets, the chance of hitting two jackpots in that span is astronomically low: - Probability of exactly 2 jackpots in 5,000 tries ≈ 0.00124%[]. - Probability of 2 or more jackpots (at least 2) ≈ 0.00125%[]. This equates to roughly 1 in 80,000 odds of such an event[]. In other terms, even among 80,000 players each doing 5,000 spins, you’d expect only one player to achieve two jackpots on pure luck. The observed wallet did just that, which sits “deep in the tail – an extremely rare event if the game is truly random”.
While rare events do happen, in a provably fair system one should be able to audit that each win was legitimate. However, Luck.io provides no public way to verify those jackpot outcomes. For each jackpot, an ideal system would allow anyone to see the random seed that led to the win and confirm it was generated without manipulation. In this case: - We could not find on-chain evidence clearly linking the jackpot outcomes to specific VRF outputs or game states, because such linking information isn’t published in an accessible way (the transaction logs are not easily decoded to outcomes without the game server data). - The payouts themselves did not come directly from an identifiable jackpot smart contract; as mentioned, “who paid the jackpot? Not visible in the transaction logs. Likely from a Vault or admin wallet”[], indicating an opaque payout process. - Luck.io does not publish a jackpot transparency report. There’s no dashboard or block explorer hint that “Jackpot of X paid from reserve Y on date Z,” which would help clear the doubt[18].
Given the combination of improbable luck and lack of verifiable data, we conclude that the fairness of the repeated jackpot wins cannot be confirmed. As our report states: “Without VRF pre-commitment proofs, public RNG inputs, and payout traceability, the fairness of repeated jackpot wins cannot be verified.”[] In a trustless system, the casino would not ask us to take their word for it – every user should be able to audit such outcomes.
Recommendation: To address this, Luck.io should improve transparency around big wins. Publishing detailed jackpot logs including: the exact VRF output and oracle signatures for the win, the game state (bet parameters), and which reserve wallet paid out the prize, would allow independent parties to verify that the win was genuine and not an internal payout. Additionally, implementing preventative measures from the RNG side (as discussed, binding randomness to bets so it can’t be tampered) would mitigate suspicion. If the event was fair, proving it via on-chain data would greatly boost user confidence.
Luck.io’s system comprises a Solana on-chain backend (the Proov Protocol) coupled with Luck.io’s off-chain game servers and web interface. The architecture can be summarized as follows:
Proov On-Chain Programs: The core of Luck.io’s casino operations runs on two Solana smart contracts provided by Proov[]:
Vault Program – an on-chain vault that escrows player funds during gameplay. Players deposit SOL or SPL tokens into the Vault (also referred to as a “bankroll contract”), which locks funds and later releases payouts or burns losses according to game outcomes[]. The vault holds the pooled bankroll and, if necessary, a cold reserve for large payouts[][].
Slot (Game) Program – an on-chain program that interfaces with games, tracking bets and outcomes. It records metrics like total wagered/won and triggers settlement by instructing the Vault to credit or debit player balances based on game results[]. This program does not contain the full game logic for determining wins; it relies on inputs from the off-chain game engine.
Decentralized VRF Oracles: Randomness is sourced via Proov’s VRF (Verifiable Random Function) network. When a player places a bet, a request is sent to multiple off-chain oracle nodes (run by Proov/Luck.io) which generate a random seed and return a signed VRF output on-chain[][]. The VRF uses Ed25519 cryptographic signatures to allow anyone to verify that the random number is authentic and unmodified[]. In theory, this provides provably fair entropy recorded on-chain for each bet.
Luck.io Off-Chain Game Engine: The actual game outcome logic – e.g. slot reel generation, card draws, Plinko paths, etc. – is executed by Luck.io’s backend servers using the VRF random seed as input[]. The mapping from random input to win/lose result occurs off-chain in proprietary code. Once the outcome is determined, the result (win amount, if any) is sent to the on-chain Slot program, which instructs the Vault to pay the player or update balances accordingly[][]. The user’s web client only sees the front-end result but can theoretically cross-verify the randomness on-chain.
Player Wallet and UI: Players interact via Luck.io’s web interface, connecting a Solana wallet. A user session begins by depositing tokens into the on-chain Vault (via a transaction the user signs). The casino front-end then lets the user place bets, which are authorized by the user (often via an off-chain signature for convenience) and relayed to the backend. Each bet triggers an on-chain VRF request and, after the outcome is resolved, the smart contracts handle payout from the Vault to the user’s wallet automatically if the user wins[]. Withdrawals of remaining balance are done on-chain from the Vault back to the user’s wallet on demand.
Administrative Keys & Upgrade Authority: The deployment is currently not trustless in terms of governance. The Luck.io/Proov team retains upgrade or admin authority over the Solana programs (as is common for upgradable Solana programs), though details are not publicly disclosed[]. Likewise, the VRF oracle nodes are permissioned by the team. There is no indication of a DAO or external governance controlling contract upgrades, parameter changes, or oracle operations[][].
This architecture provides non-custodial fund management and transparent randomness on-chain, but it centralizes control over game logic and critical configuration. The following sections analyze the implications and risks in each area.
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].
Our audit looked for any mechanisms that would allow the Luck.io team to interfere with games or user funds outside of the expected logic. We discovered that administrative controls exist or are likely present, given the architecture, and they introduce trust dependencies.
Contract Upgrade and Pause Authority: The Proov Protocol’s Solana programs (Vault and Slot) appear to be upgradeable (they were delivered to auditors as upgradable programs). Typically, Solana programs can have an upgrade authority – often a team-held key. We searched on-chain and in documentation and found no public confirmation of renounced or decentralized control of these authorities[30]. This means the Luck.io team (or a single key custodian) could deploy new code to these programs at any time, unless they have intentionally locked it (not disclosed). An upgrade could change game rules, add a backdoor, or pause functionality. Similarly, if the programs include a pause switch or emergency stop (common in custodial contracts), only the team would control it. We did not find a specific pause() instruction in the limited public interface, but absence of evidence is not proof of absence. The Halborn audit did note issues around authority management (e.g., “multi-step authority transfer not enforced,” which was a low-severity finding) – this suggests the design initially had central admin keys that required more secure transfer procedures[31].
Possibility of Blocking/Delaying Payouts: Luck.io markets that all wins are “automatically settled” by smart contract, implying no manual intervention[26][27]. However, our analysis of user reports and the system design indicates that settlement might be batched or delayed under certain conditions. In fact, Luck.io acknowledges that settlements can take up to some minutes (or even hours in worst case) to finalize. This suggests an off-chain process collects VRF results and then triggers on-chain settlement in intervals. Any time there is a delay between a win being determined and the on-chain payout, there is room for an admin to step in – for instance, flagging a suspiciously large win for review. If such a flag exists, it’s not visible to users. We could not confirm whether large wins truly settle trustlessly or if an operator can silently veto them. The lack of a hard-coded max payout limit in the contracts (no on-chain max_win parameter was found) means any cap or review process would likely be off-chain logic.
Administrative Functions and Overrides: The audit looked for any documented admin functions like pause_bets() or overridePayout() that might be built into the smart contracts[33]. None were explicitly found in public code, but given that the game logic isn’t on-chain, such controls could be purely off-chain as well (the backend could simply stop accepting bets or ignore certain outcomes). Halborn’s review of the vault and payout programs likely checked that only authorized game contracts can move funds and that basic checks were in place. They did not, however, publish details on whether the team has special roles. The centralization risk is that if the team wanted to, they could: - Halt all betting or withdrawals (by either pausing the program or turning off the backend). - Selectively cancel a bet outcome or withhold a payout (by not executing the settlement on-chain, since settlement is not user-triggered but system-triggered). - Change game configurations or even the code via an upgrade to respond to “abnormal” wins.
Without a multisig or timelock on the admin controls, these actions could be taken unilaterally. Our review of project materials shows no evidence of multisig governance or timelocked changes – “no DAO, no open codebase, no contract-level protections” as one summary noted. The team holds the levers, and users must trust they won’t be abused.
Findings from Risk Review: We compiled the following risk considerations regarding admin control: - Large Payout Intervention: The risk that a very large win could be blocked or delayed by the team for manual verification. (We consider this possible given no hard-coded enforcement otherwise[31]). - Lack of On-Chain Limits: Since payout limits are not coded on-chain, the system relies on off-chain business logic to handle edge cases (like refusing bets that could win more than available liquidity). This is flexible but not transparent[36]. - Upgradeability: The presence of an upgrade authority is a central point of trust – if that key were compromised or misused, the whole protocol could be altered. Halborn’s critical finding about token extensions shows the team did upgrade/fix issues post-audit[33][34], which implies the authority was in use as of Jan 2025 (audit remediation date). Ideally, after fixes, such authority would be handed to a multisig or burned, but we have no confirmation of that. - Transparency of Admin Actions: Because the audit report was not fully released publicly (only a summary FAQ, requiring users to email the team for details)[37], the community cannot easily verify what powers the team kept. This “audit trust” is opaque – effectively asking users to trust an unseen report.
In essence, Luck.io currently operates more like a traditional online casino with a crypto facade – users deposit into a smart contract and get cryptographic RNG proofs, but the operator still has full control to change the rules or intervene in execution if desired. This undermines claims of being “trust-free” or fully decentralized.
Recommendations: We strongly recommend that Luck.io: 1. Disclose and limit upgrade keys – If the programs are upgradeable, move the authority to a multisig wallet with community or third-party oversight, or time-lock upgrades so changes are transparent and cannot be done instantly[28]. 2. Implement governance– Introduce on-chain governance (token-weighted or otherwise) for critical parameters and upgrades, so the community has a say or at least visibility[32]. 3. Clarify settlement processes – Hard-code automatic settlement where possible, or publish a policy on how big wins are handled. Ideally, remove any ability to halt payouts manually, aside from emergency pauses for security incidents (and even those should be multi-signature controlled). 4. Publicize admin functions – At minimum, document what administrative functions exist (pauses, overrides, oracle management). Security by obscurity is risky; users deserve to know the conditions under which the game can be stopped or altered[48].
Decentralize and Secure RNG: Integrate a more trustless RNG mechanism. For example, use Chainlink VRF or a similar decentralized oracle network for randomness, or require multiple independent VRF providers. At minimum, implement a commit–reveal scheme where each bet’s hash or ID is committed on-chain before randomness is generated, preventing oracle re-roll attacks[7]. This will significantly improve fairness guarantees.
Open-Source Game Logic: Publish the game outcome algorithms (e.g., as open-source code or detailed documentation with hash commitments). Ideally, move critical game logic on-chain via smart contracts or vetted WebAssembly modules. This would allow the community to audit how wins are determined and ensure the house edge and odds are exactly as claimed. If on-chain execution is too costly, consider zero-knowledge proofs for game outcomes.
Publicize the Halborn Audit Report: Release the full Halborn audit report (or at least a technical summary of findings) to the public, e.g., via IPFS or on the project website[10]. This enables independent analysts to verify what was audited and what issues were found/fixed. It increases trust that there are no lingering critical vulnerabilities or hidden backdoors.
Implement Multisig and Governance Controls: Remove single points of failure by introducing multisignature governance:
Manage the upgrade authority for smart contracts with a multisig wallet that includes multiple team members and possibly reputable community members or investors. This prevents unilateral malicious upgrades.
Enhance Jackpot and Payout Transparency: Establish a clear, on-chain record for major payouts:
Use a designated payout contract or log for jackpots. For example, implement an event emission or separate vault for jackpots that marks each payout and its corresponding randomness proof. This way anyone can track big win events from blockchain data directly[11].
Regularly publish a jackpot report listing recent big wins, the wallet that won, the VRF output that led to the win, and which address paid it. This report can be cross-verified with on-chain data, reinforcing fairness.
Consider a “jackpot reserve contract” that always holds a set amount for jackpot payouts, proving to players that those funds are locked and available (and automatically distributed when a jackpot occurs).
Proof of Reserve & Liability: Provide stronger proof to users that the platform is solvent and not fractionally reserved:
Introduce an on-chain proof-of-liquidity mechanism – for instance, periodically snapshot total player balances and show that the Vault contains at least that amount (this might already be inherently true, but making a point of it via an audit or script is good practice)[25].
If Luck.io ever issues loyalty tokens or a bankroll investment scheme, adopt full proof-of-reserve audits by third parties to assure players that their funds are safe.
Oracle Transparency and Rotation: If continuing with a proprietary oracle network, make it more transparent:
Periodically rotate oracle signers, and if possible, involve community voting or staking for new oracles[1]. This reduces the risk of long-term collusion or key compromise.
Provide a dashboard or feed of unused VRF requests (if any) to prove that no hidden re-rolls are happening – for example, disclose if multiple VRF proofs were generated for a single bet (this is advanced and not typical, but would bolster trust).
User Education and Honesty in Marketing: Adjust messaging to accurately reflect the platform’s state. If certain aspects are still centralized, be clear about it while you work to decentralize them. Users and the crypto community appreciate transparency about what is trustless vs what is still trust-based. Overstating claims (“trust-free” or “fully decentralized”) before those are true could invite backlash.
By implementing the above changes, Luck.io can significantly improve its security posture and trustworthiness. It would move from a closed, centrally-operated service with a blockchain veneer toward a genuinely transparent, community-verifiable gambling protocol. Many of these steps (publishing audits, open-sourcing code, using decentralized oracles) are standard in the blockchain industry for projects that aim to be trustless.
Final Verdict: At present, Luck.io and Proov Protocol deliver a novel hybrid of on-chain and off-chain gaming, but they require substantial trust in the team. The concept of provably fair gambling is partially realized – the random seeds are verifiable – but the lack of end-to-end verifiability means it does not fully meet the ideals of a trustless system. Until the recommended improvements are made, users should approach the platform with an understanding of these limitations and risks. Luck.io has the opportunity to set a new standard in crypto gambling by addressing these issues, thereby providing both the convenience of blockchain betting and the genuine security of decentralization.
A comprehensive Next.js application for analyzing and verifying bets on the Proov Network gaming platform. This application provides real-time analytics, bet verification, and detailed insights into gaming data.
Github Repository: https://github.com/Devilla/luck.io
🎰 Bet Analysis
Detailed bet information display
Profit/loss calculations
Multiplier analysis
Shard information
🔍 Bet Verification
6-step verification process
Signature validation
Payout verification
Settlement confirmation
🎮 Game Distribution Analysis
House edge calculations
Volatility ratings
Betting limits
Payout structures
👤 User Analytics
User statistics
Betting patterns
Authentication details
Session analysis
Frontend: Next.js 14, React 18, TypeScript
Styling: Tailwind CSS
Icons: Lucide React
API Client: Axios
Charts: Recharts
Node.js 18+
npm or yarn
Install dependencies:
npm installRun the development server:
npm run devOpen your browser: Navigate to http://localhost:3000
Enter a bet address and nonce in the search form
Click "Search Bet" to load bet details
View comprehensive bet information including:
Bet amount and winnings
Game details
Shard information
Timestamps and addresses
After loading a bet, click "Verify Bet"
View the 6-step verification process:
Login message signature verification
Bet request signature verification
Oracle randomness validation
Payout calculation verification
Shard award verification
Settlement value confirmation
Browse available games and their configurations
View house edge, volatility ratings, and betting limits
Analyze game-specific settings
View aggregated statistics
Monitor platform performance
Analyze betting patterns
The application integrates with several Proov Network endpoints:
/solana/bets/{address}/{nonce} - Bet details
/games/distributions - Game configurations
/games/distributions/{id} - Specific game distribution
/solana/login/key/{publicKey} - User authentication
/solana/settlements/{address}/{nonce} - Settlement data
/solana/signers - Oracle signers
The application includes sample data based on the provided API responses:
Sample Bet: Address 6kRQgeBFq3Qh32rP16cGz9gisfMUM6umFpPZVwkQx8Ez, Nonce 43359
Game: Madame Fortune
Bet: $1,000 (5.85 SOL)
Win: $1,661,000 (9,714.36 SOL)
Multiplier: 1,661x
BetCard: Displays comprehensive bet information
GameDistributionCard: Shows game configuration and limits
UserLoginCard: User authentication and statistics
BetVerificationCard: Multi-step verification process
Responsive Design: Mobile-first approach with Tailwind CSS
Real-time Data: Live API integration with error handling
Interactive UI: Tabbed navigation and collapsible sections
TypeScript: Full type safety throughout the application
Since this is a client-side application calling external APIs, you may encounter CORS restrictions. For production use, consider:
Setting up a backend proxy
Using Next.js API routes as middleware
Configuring CORS on the Proov Network APIs
├── app/ # Next.js 13+ app directory
│ ├── globals.css # Global styles
│ ├── layout.tsx # Root layout
│ └── page.tsx # Home page
├── components/ # React components
│ ├── BetCard.tsx
│ ├── GameDistributionCard.tsx
│ ├── UserLoginCard.tsx
│ └── BetVerificationCard.tsx
├── lib/ # Utility libraries
│ └── api.ts # API client functions
├── types/ # TypeScript type definitions
│ └── proov.ts # Proov Network types
└── public/ # Static assetsnpm run dev - Start development server
npm run build - Build for production
npm run start - Start production server
npm run lint - Run ESLint
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
This project is licensed under the MIT License.
Proov Network for providing the gaming platform APIs
Next.js team for the excellent framework
Tailwind CSS for the utility-first styling approach
In a gambling platform, honest and timely payouts are as important as fair odds. We reviewed how Luck.io manages payouts, the transparency of its bankroll, and whether users can trust that sufficient liquidity is locked for big wins.
On-Chain Vaults and Automated Payouts: Luck.io uses an on-chain Vault to handle player funds, which is a positive security feature. When a bet is resolved, the outcome (win or loss) is settled by the smart contract: - If the player wins, the Vault transfers the winnings to the player’s wallet (or credits their balance) instantly and without needing manual approval[12]. - If the player loses, their wager is already in the Vault and simply remains there (becoming part of the house funds).
For typical wins, this system is trust-minimized – the code itself releases funds, and it won’t refuse a valid win as long as the Vault has funds. Indeed, during normal operations we saw that withdrawals and small wins were processed on-chain to user addresses promptly, indicating the automated flow works.
“Cold Bankroll” Reserve: Luck.io has mentioned a secondary reserve (often called a cold wallet or cold bankroll) used for very large payouts[25][26]. This is essentially an overflow pool of liquidity controlled by the team. If a win exceeds the funds currently in the active Vault, the idea is the reserve wallet would supply the difference. This reserve’s address is known (Luck.io has at times shared it), and players can observe its balance on-chain. However: - It’s not a smart contract, just a Solana wallet (team-controlled). So while you can see its SOL balance, the usage of those funds is manual. - There is no on-chain linkage indicating when or how the reserve is tapped. An operator would have to transfer funds from the cold wallet into the Vault or directly to a winner when needed, which would be a normal Solana transaction but not automatically tied to the bet. Hence, tracking if a jackpot was paid from the reserve is non-trivial unless the team discloses it.
In the jackpot case we analyzed, the payout to the winner’s wallet did not clearly come from the main Vault program, implying it may have been paid out of band (perhaps the team sent it from a cold wallet or a fresh funding source)[16]. This reduces the provability of payouts – an ideal design would use a smart contract escrow for jackpots as well, or at least route all payouts through known on-chain addresses.
Proof of Reserves (PoR) Claims: Luck.io claims to have “proof of reserves” because all bankroll funds are on the blockchain that players can inspect[24]. It’s true that one can look up the Vault account and cold wallet balances to see the casino’s funds. However, this is a limited form of transparency: - There is no published schedule or guarantee of reserve levels (unlike a true PoR with liabilities, we don’t know how much is owed to players vs house capital). - The team can move funds in and out at will (e.g., refill the bankroll from another wallet, or withdraw profits). We saw that there are no enforced reserve ratios or locks – “no on-chain contract enforcement of reserve ratios or maximum exposure”. - No multi-signature protection on the reserve wallets was evident[49]. A single key loss or compromise could drain funds, which is a security risk for players. - If Luck.io wanted to silently remove funds (for example, take a portion of the bankroll), they could, and the only recourse is user vigilance in watching the blockchain. There’s no automated alert or smart-contract constraint to prevent it.
Transparency Grade: We rate the payout and reserve transparency as partial at best: - Visible Balances: Yes – Users can see the addresses and their token balances on Solana[25]. - Custody of Funds: No – Players do not hold custody during betting; funds are in team-controlled contracts/wallets (though governed by code to some extent)[40]. - Use of Funds Restricted by Code: No – The code does not restrict moving reserves or changing limits; this is all off-chain policy[24][25]. - Real-time Audit of Liquidity: No – There is no dashboard or oracle that tells players that, for example, X amount is locked for jackpots or Y is the current liability. It’s up to the user to manually parse blockchain data.
This means counterparty risk remains. If Luck.io faced a liquidity crunch or decided to pause withdrawals, nothing in the smart contracts would stop them from doing so (aside from reputational damage and users noticing on-chain movements). Our investigation explicitly notes: “The team controls the reserves and most smart contracts… This means the team can move funds at any time, though it would be publicly visible. This exposes players to counterparty risk, especially if high-value withdrawals are delayed or paused ‘for review.’ In a truly trustless casino, no human could interfere with payouts at all, and funds would be secured by code until legitimately won or lost.
Incident Consideration: It’s worth noting that during the jackpot scenario, after the wins, the player’s wallet received a large inflow (the winnings). We could not definitively trace that inflow to the official Vault or reserve account. It’s possible the team temporarily pulled funds from elsewhere (e.g., an exchange or another wallet) to pay it, then later reconciled their reserves. This is speculation, but the lack of clear on-chain traceability is exactly the issue – “no wallet disclosures, no smart contract vault with audit access [specifically for jackpots]”[16] means we can’t be sure where the money came from. A best practice for transparency would be to have a dedicated on-chain jackpot treasury or an event log linking payouts to a reserve transaction.
Recommendations: To bolster user confidence, we recommend: - Automating Large Payout Funding: Use a programmatic mechanism to draw from the cold reserve when needed. For example, the Vault program could be extended or complemented with a treasury contract that automatically loans funds to the Vault for a large win, all in one atomic transaction. This would leave an on-chain footprint tying the reserve to the payout event. - Multisig & Time-lock on Reserves: The main bankroll and reserve wallets should be secured by a multisignature scheme (e.g., 2-of-3 or more) including perhaps an independent party. Also, consider time-locking large withdrawals from the reserve (e.g., require 24h notice)[28]– this can prevent a single rogue actor from emptying funds and give users a warning if funds are moved abnormally. - Regular Proof-of-Reserve Audits: Periodically (or in real-time via an oracle), publish a proof that the on-chain reserves match or exceed user balances. Since user balances are actually in the Vault, an equivalent concept is proof that the Vault is solvent relative to active player funds. This could be done via a view function or snapshot, increasing transparency. - Publish Payout Logs: As mentioned earlier, for major wins, publish a transaction breakdown. If Luck.io wants to maintain trust, being forthcoming with exactly how a 1000 SOL jackpot was paid (which addresses and when) and linking it to the VRF result would dispel a lot of doubt.
RNG & Oracles (Control, centralization, manipulation risk)
Game Logic (off-chain black box, unverifiable fairness)
No Game logic provided:
Payouts, Liquidity, Proof-of-Reserves
Admin / Upgradeability / Governance
IST to UST Time (At least 2 minutes settlement delay)
Halborn Scope / Audit Transparency
Trustless vs Reality (Marketing vs facts)
Earlier, no Client Seed Input provided.
Recently, Client Seed UI added but no verification that it is used for RNG with Proov VRF hash (Server Seed).
Public Explorer (“we show everything now”) rebuttal
Custom Seed (i.e. Player Seed) not used with Proov VRF to generate RNG for game outcome.
In simple terms, Custom seed parameter which is just taken in the bet request but not combined with RNG which is the least for any online crypto casino.
