Upgradeability and Admin Control

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].