FairLuck Protocol
Disclaimer & Agreement
By using this protocol, you acknowledge:
- This is a decentralized protocol that operates entirely according to its smart contract code. No individual or entity controls it.
- Cryptocurrency involves substantial risk of loss. You may lose some or all of your funds. Only participate with funds you can afford to lose.
- You must be 18 years or older to use this protocol.
- This protocol is NOT available to citizens, residents, or persons located in the United States of America.
- This website uses cookies and local storage to remember your preferences and improve your experience.
Security Audit Report
FairLuck Protocol — Smart Contract Security Review
Reviewed By
Grey Zone Security Review Team
Audit Date
April 2026
Scope
All Core Contracts (v1.0)
Executive Summary
Grey Zone Security Review Team conducted a comprehensive security audit of the FairLuck Protocol smart contracts deployed on Base (Ethereum L2). The audit covered all 13 deployed contracts including FairLuckPool (6 pool instances), FairLuckVRF, FeeCollector, FAIRToken, FairLuckGovernor, FairLuckTimelock, FairLuckAutomation, and FairLuckTokenClaim.
The audit found no critical or high severity vulnerabilities. The protocol demonstrates strong security practices including the use of battle-tested OpenZeppelin libraries, Chainlink VRF for provably fair randomness, and a robust governance system with timelock protection.
Overall, the FairLuck Protocol is well-designed and implements appropriate security measures for a decentralized lottery system. The identified findings are primarily informational or low severity, relating to operational dependencies and potential future optimizations.
Finding Summary
0
Critical
0
High
1
Medium
3
Low
2
Info
Audit Scope
| Contract | Lines of Code | Compiler |
|---|---|---|
| FairLuckPool.sol | ~320 | 0.8.34 |
| FairLuckVRF.sol | ~150 | 0.8.34 |
| FeeCollector.sol | ~85 | 0.8.34 |
| FAIRToken.sol | ~25 | 0.8.34 |
| FairLuckGovernor.sol | ~60 | 0.8.34 |
| FairLuckTimelock.sol | ~15 | 0.8.34 |
| FairLuckAutomation.sol | ~90 | 0.8.34 |
| FairLuckTokenClaim.sol | ~280 | 0.8.34 |
Detailed Findings
Centralization Risk in Initial Deployment Phase
Description
During the initial deployment phase, the deployer address holds administrative privileges over the FeeCollector contract before governance is fully activated. This creates a temporary centralization vector.
Recommendation
Transfer all administrative roles to the Timelock governance contract as soon as the governance system is operational.
Resolution
The team has transferred all admin roles to the FairLuckTimelock contract. The deployer no longer holds any privileged access. Verified on-chain.
VRF Subscription Funding Dependency
Description
The Chainlink VRF subscription must remain funded with LINK tokens for draws to execute. If the subscription runs out of LINK, draws will fail until refunded.
Recommendation
Implement monitoring and alerting for VRF subscription balance. Consider adding an automated top-up mechanism or a public function allowing anyone to fund the subscription.
Resolution
The team has set up Chainlink Automation with monitoring. The VRF subscription balance is monitored and will be topped up as needed. The team acknowledges this operational dependency.
Stablecoin Depeg Assumption
Description
The protocol treats both USDT and USDC as exactly $1 regardless of market conditions. In a depeg scenario, the actual value of contributions and prizes could differ from the nominal $1-per-ticket assumption.
Recommendation
Document this assumption clearly for users. Consider adding a circuit breaker that pauses contributions if stablecoin prices deviate significantly from $1.
Resolution
The team has documented this assumption in the protocol documentation and Terms of Service. A circuit breaker is being considered for future implementation via governance proposal.
Minimum Threshold Edge Case
Description
If a pool reaches exactly its minimum threshold and a user withdraws just before the cutoff, the pool could fall below threshold. The contract correctly handles this by checking the threshold at draw time.
Recommendation
No action required. The current implementation correctly handles this edge case by checking totalValue >= minThreshold at draw initiation.
Resolution
Verified that the contract checks threshold at draw time, not at contribution time. If withdrawals bring the pool below threshold, the draw will not proceed and funds will be refundable.
Gas Optimization Opportunities
Description
Several functions in FairLuckPool.sol could benefit from gas optimizations, including batch ticket assignment and storage packing for the PoolCycle struct.
Recommendation
Consider implementing batch operations for high-volume pools and optimizing struct packing to reduce storage costs.
Resolution
The team acknowledges these optimizations and will consider them for future versions. Current gas costs are acceptable for Base L2 where gas is significantly cheaper than Ethereum mainnet.
Withdrawal Timing Window
Description
The 5-minute cutoff before pool close prevents last-second withdrawals. However, the exact block timestamp used for comparison could vary slightly from wall-clock time.
Recommendation
The current implementation using block.timestamp is standard practice. Document that the cutoff is based on block timestamp, which may differ slightly from wall-clock time.
Resolution
The contract uses block.timestamp which is standard for time-based logic in Solidity. The 5-minute buffer provides sufficient margin for any timestamp variance.
Conclusion
The FairLuck Protocol demonstrates a well-architected decentralized lottery system with strong security fundamentals. The use of Chainlink VRF ensures provably fair randomness, while the OpenZeppelin-based governance system provides decentralized control over protocol parameters.
No critical or high severity vulnerabilities were identified during this review. The medium severity finding regarding initial centralization has been fully mitigated by transferring all administrative roles to the governance timelock.
Grey Zone Security Review Team considers the FairLuck Protocol to be suitable for mainnet deployment with the current security posture.
Disclaimer: This audit report is provided for informational purposes only. It does not constitute financial advice or a guarantee of security. Smart contract audits cannot guarantee the absence of all vulnerabilities. Users should conduct their own research and assess risks before interacting with any smart contract.
Grey Zone Security Review Team performed this audit based on the source code available at the time of review. Any subsequent modifications to the contracts may invalidate the findings of this report.