Prediction Mining - Security Audit Report

Created: January 23, 2026 Last Updated: March 7, 2026 Audit Date: January 23, 2026 - March 7, 2026 Auditor: Volunteers / WELEPHANT Team / Claude Opus 4.6 / Codex GTP-5.2 (AI-assisted security review) Solidity Version: 0.8.20 Scope: All contracts in /contracts/ directory

Executive Summary

The Prediction Mining smart contract system has been audited for security vulnerabilities. The codebase demonstrates strong security practices including:

• OpenZeppelin battle-tested libraries (AccessControl, ReentrancyGuard, SafeERC20, ERC4626)
• Checks-Effects-Interactions (CEI) pattern consistently applied
• No emergency withdraw functions (rug-proof design)
• Fee percentages as immutable constants
• Gas-checked cursor pattern for batch operations

Overall Assessment: SECURE - All issues from Jan, Feb, and Mar 2026 reviews have been fixed. All findings resolved.

Contracts Audited

Excluded from Audit (No Executable Logic)

Security Analysis by Contract

RaffleMining.sol

Security Features:

• AccessControl for role-based permissions
• ReentrancyGuard on value-transfer functions
• Pausable for emergency circuit breaker
• SafeERC20 for all token transfers
• EnumerableSet for O(1) active user management
• Zero-address validation on setWelephantToken()

Key Findings:

Fix Applied (RM-05):

The registerAutoPlay() function allows anyone to register auto-play for any player (sponsorship model). Without protection, an attacker could repeatedly call registerAutoPlay() for a victim, overwriting their settings and disrupting their auto-play.

// Before (vulnerable to DoS):
require(player != address(0), "E12");

// After (protected):
require(player != address(0) && !autoPlays[player].active, "E12");

This fix ensures:

• Cannot register for a player who already has active auto-play
• Player must cancel their auto-play before anyone can register a new one for them
• Prevents griefing/settings override attacks

Fix Applied (RM-07):

Players could make multiple plays in the same round (via manual play, auto-play, or pending plays). The old code attempted to subtract the previous play's squareTotals contributions before recording the new play, but used numSquares from the new play's popcount to iterate the old bitmask — missing high-numbered squares. This left stale contributions in squareTotals, causing squareTotal < sum(playerAmounts), which inflated proportional rewards beyond the winners pool and reverted ETH transfers during distribution.

// Before (allowed multiple plays — corrupted squareTotals):
function _recordPlay(...) internal {
    bool isFirstPlay = gameHistory.getPlayerSquareBitmask(player, roundId) == 0;
    // ... recorded play even if not first

// After (one play per round):
function _recordPlay(...) internal {
    (uint256 totalPlay,,,,) = gameHistory.getPlayerRoundSummary(player, roundId);
    require(totalPlay == 0, "E43");
    bool isFirstPlay = true;

Fix Applied (RM-08):

Pending plays (submitted after round expiry) are queued and processed by the crank into the next round. If a player already has an auto-play processed for that round, the pending play would create a duplicate. The crank now checks for existing plays and refunds duplicates:

// In RaffleMiningCrank._processPendingPlays():
(uint256 existingPlay,,,,) = gh.getPlayerRoundSummary(player, currentRound);
if (existingPlay > 0) {
    uint256 refundAmount = amountPerSquare * _popcount(squareBitmask);
    if (refundAmount > 0) {
        storage_.depositEthReward(player, refundAmount, "pending-play-refund");
    }
    continue;  // Skip duplicate, refund ETH
}

Access Control:

DEFAULT_ADMIN_ROLE → Can grant/revoke all roles
ADMIN_ROLE → Update game parameters
PAUSER_ROLE → pause()/unpause()
STORAGE_WRITER_ROLE → Crank write access

RaffleMiningCrank.sol (CrankCore) + CrankFinalization.sol

Architecture Note: The crank is split into two deployed contracts to stay under the 24,576 byte EVM contract size limit. CrankCore (RaffleMiningCrank.sol) handles orchestration, auto-play, and pending play processing. CrankFinalization handles round finalization, winner selection, reward distribution, vault swaps, and fee distribution. CrankCore delegates to CrankFinalization via the ICrankFinalization interface; CrankFinalization restricts these calls via onlyCrankCore modifier.

Security Features:

• ReentrancyGuard on crank() function
• Immutable storage contract reference (shared by both contracts)
• Gas-checked cursor pattern prevents out-of-gas
• Backward iteration for safe EnumerableSet removal
• onlyCrankCore modifier restricts CrankFinalization to single authorized caller

Key Findings:

Fix Applied (RC-01):

// Before (potential underflow):
uint256 remainingRounds = autoPlay.initialRounds - autoPlay.roundsPlayed;

// After (safe):
uint256 remainingRounds = 0;
if (autoPlay.initialRounds > autoPlay.roundsPlayed) {
    remainingRounds = autoPlay.initialRounds - autoPlay.roundsPlayed;
}

Fix Applied (RC-06):

The crank used nested state machines for WELEPHANT auto-staking and ETH looping. Pending queues (pendingAutoStakePlayers/Amounts, pendingEthLoopPlayers/Amounts) were accumulated during distribution, then flushed via separate gas-checked loops with their own *FlushInProgress / *FlushCursor state. If a flush could not complete (e.g., welephantVault.canWithdraw() returned false due to pending swaps), the flush returned false — but the parent distribution's *InProgress flag was never reset. This blocked newRoundPending from clearing, permanently bricking the game with no admin recovery path.

Root cause: Nested state machine (flush inside distribution) where the inner machine's failure blocked the outer machine's completion.

Fix: Removed all pending queue infrastructure and flush state machines. Auto-staking and ETH looping are now handled inline within the parent distribution loops:

// Before (nested state machine — could brick):
_addPendingAutoStake(winner, reward);
if (_shouldFlushAutoStakeBatch()) {
    if (!_flushPendingAutoStakes(storage_)) {
        return processed;  // welephantDistributionInProgress stays true FOREVER
    }
}

// After (inline — cursor always advances):
if (autoStakeWelephant && canWithdraw(reward)) {
    depositToStakingVaultForPlayer(winner, reward);
} else {
    _addPendingWelephantReward(winner, reward, label);  // Fallback: claimable
}

Removed state variables: pendingEthLoopPlayers/Amounts, pendingAutoStakePlayers/Amounts, ethLoopFlushCursor, ethLoopFlushInProgress, autoStakeFlushCursor, autoStakeFlushInProgress

Removed functions: _addPendingEthLoop, _flushPendingEthLoops, _shouldFlushEthLoopBatch, _addPendingAutoStake, _flushPendingAutoStakes, _shouldFlushAutoStakeBatch

Result: Distribution loops can never get stuck. The cursor always advances, and auto-stake failures gracefully fall back to claimable rewards. Net reduction: ~170 lines removed.

Fix Applied (RC-07):

Reward deposits (ETH and WELEPHANT) were accumulated in pending arrays (pendingEthPlayers/Amounts, pendingWelephantPlayers/Amounts) and flushed via batchDepositEthReward / batchDepositWelephantReward when the batch reached MAX_BATCH_SIZE or the distribution loop completed. The batch functions in WelephantRewards contain require checks per-item (require(amounts[i] > 0), require(players[i] != address(0))) — a single bad item would revert the entire batch, losing all accumulated rewards.

Fix: Removed all batch accumulation. Each winner now receives their reward via a direct per-winner call (depositEthReward / depositWelephantReward) inline in the distribution loop. No intermediate arrays, no batch flush.

Removed state: pendingEthPlayers/Amounts, pendingWelephantPlayers/Amounts, pendingEthLabel, pendingWelephantLabel, MAX_BATCH_SIZE

Removed functions: _addPendingEthReward, _flushPendingEthRewards, _shouldFlushEthBatch, _addPendingWelephantReward, _flushPendingWelephantRewards, _shouldFlushWelephantBatch

Fix Applied (RC-08):

depositToStakingVaultForPlayer calls _ensureWelephantBalance which contains require(success, "E78"). If the vault withdrawal fails for any reason (insufficient liquidity, token transfer revert, staking vault error), this hard reverts the entire crank transaction — bricking the distribution.

The previous canWithdraw guard only protected against insufficient liquidity, not against token-level or staking vault failures.

Fix: Replaced the canWithdraw guard with try/catch around depositToStakingVaultForPlayer. Any failure mode falls back to a claimable reward:

// Before (hard revert on any failure past canWithdraw):
if (autoStakeWelephant && canWithdraw(reward)) {
    storage_.depositToStakingVaultForPlayer(winner, reward);  // require(success, "E78") inside
}

// After (universal fallback):
if (autoStakeWelephant) {
    try storage_.depositToStakingVaultForPlayer(winner, reward) returns (uint256 shares) {
        storage_.emitWelephantAutoStaked(winner, reward, shares);
    } catch {
        storage_.depositWelephantReward(winner, reward, label);  // Claimable fallback
    }
}

Fix Applied (RC-11):

The auto-play batch iterates backward through an EnumerableSet, saving a cursor between crank calls when gas runs out. If users cancel auto-play between crank calls (shrinking the set), the saved cursor could point past the end of the set, causing getAutoPlayUserAt to revert with an out-of-bounds error. This would DoS the crank until the batch state was somehow cleared.

// Before (cursor stale after removals):
if (!autoPlayBatchInProgress) {
    autoPlayBatchInProgress = true;
    autoPlayBatchCursor = userCount;
}

// After (clamp cursor when set shrinks between cranks):
if (!autoPlayBatchInProgress) {
    autoPlayBatchInProgress = true;
    autoPlayBatchCursor = userCount;
} else if (autoPlayBatchCursor > userCount) {
    // Users cancelled auto-play between crank calls — clamp cursor to avoid out-of-bounds
    autoPlayBatchCursor = userCount;
}

Fix Applied (RC-12):

getPendingWork() computed distribution remaining counts via unchecked subtraction (totalWinners - cursor). If a cursor ever exceeded totalWinners (even transiently), Solidity 0.8's overflow protection would revert the view function. Since crank() calls this.getPendingWork() as an early-exit check, this would brick the crank entirely.

// Before (underflow reverts the view, bricking crank):
work.welephantDistributionsRemaining = totalWinners - fin.getWelephantDistributionCursor();
work.ethDistributionsRemaining = totalWinners - fin.getEthDistributionCursor();

// After (defensive — gracefully returns 0):
uint256 welCursor = fin.getWelephantDistributionCursor();
work.welephantDistributionsRemaining = totalWinners > welCursor ? totalWinners - welCursor : 0;
uint256 ethCursor = fin.getEthDistributionCursor();
work.ethDistributionsRemaining = totalWinners > ethCursor ? totalWinners - ethCursor : 0;

Fix Applied (RC-13):

getPendingWork().autoPlaysRemaining was computed as getAutoPlayUsersLength() - autoPlayBatchCursor. The cursor counts down from userCount to 0, so the cursor value is the remaining count. The subtraction gave the processed count instead. The heartbeat event (line 352) already used the cursor directly, confirming the correct semantics.

// Before (reports processed count, not remaining):
work.autoPlaysRemaining = storageContract.getAutoPlayUsersLength() - autoPlayBatchCursor;

// After (cursor IS the remaining count):
work.autoPlaysRemaining = autoPlayBatchCursor;

GameHistory.sol

Security Features:

• AccessControl with WRITER_ROLE
• Append-only design (no deletions)
• Indexed lookups via mappings
• Single-writer architecture (only RaffleMining holds WRITER_ROLE)
• External AddressMinHeap bounded at K=100 with Ownable restriction

Key Findings:

Fix Applied (GH-01):

function getRoundSummary(uint256 roundId) external view returns (RoundSummary memory) {
    // Check length first to avoid array out-of-bounds
    if (_roundSummaries.length == 0) {
        return RoundSummary({/* empty */});
    }
    // ... rest of logic
}

Fix Applied (GH-12):

recordPlayerPlay receives a numSquares parameter and uses it as the loop bound for iterating bitmask bits to update squareTotals. The caller (RaffleMining._recordPlay) passed _popcount(squareBitmask) (the count of selected squares) instead of the board size (16). This meant the loop for (i = 0; i < numSquares; i++) only checked the first N bit positions where N = number of selected squares. High-numbered squares (bit positions >= popcount) were never added to squareTotals.

Impact: If a player selected only square 10 (bit 9), numSquares=1, the loop only checked bit 0, never reaching bit 9. squareTotals[10] was never incremented for this player, but playerAmountPerSquare was stored. During reward distribution, reward = winnersPool × playerAmount / squareTotal divided by a too-small denominator, producing rewards exceeding the winners pool. This caused ETH transfers to revert with "Transaction reverted without a reason string".

The same bug affected _popcount(squareBitmask, numSquares) which was also bounded by popcount, potentially miscounting set bits in the bitmask.

// Before (caller passes popcount — misses high-numbered squares):
uint256 numSelected = _popcount(squareBitmask);
gameHistory.recordPlayerPlay(roundId, player, squareBitmask, amountPerSquare, numSelected);

// After (caller passes board size — iterates all 16 bit positions):
gameHistory.recordPlayerPlay(roundId, player, squareBitmask, amountPerSquare, numSquares);

Verification.sol

Security Features:

• AccessControl with WRITER_ROLE
• Hash-chained entropy accumulation (order-dependent, non-canceling, one-way)
• Per-round salt masks accumulated seed (prevents prediction)
• block.prevrandao (beacon chain randomness) included at every entropy point
• Stores all entropy components for post-hoc verification
• Finalization is irreversible

Key Findings:

Fix Applied (V-04):

Replaced XOR-based entropy accumulation with hash-chaining:

// Before (XOR - commutative, self-canceling, reversible):
maskedAccumulatedSeed = maskedAccumulatedSeed ^ playEntropy ^ roundSalt;

// After (hash-chain - order-dependent, non-canceling, one-way):
maskedAccumulatedSeed = keccak256(abi.encodePacked(maskedAccumulatedSeed, playEntropy)) ^ roundSalt;

XOR weaknesses eliminated:

• Order independence: XOR produced the same result regardless of play order. Hash-chaining makes each play commit to the full history before it.
• Cancellation: Identical plays cancelled each other (x ^ x = 0), reducing entropy. Hash-chaining ensures every play strictly adds entropy.
• Reversibility: XOR is trivially reversible. Hash-chaining is one-way at every step.

Fix Applied (V-05):

Added block.prevrandao to playEntropy computation for consistency with all other seed derivation points:

bytes32 playEntropy = keccak256(abi.encodePacked(
    player, square, amount,
    block.timestamp, block.number,
    block.prevrandao  // beacon chain randomness
));

Fix Applied (V-03):

finalizeRound() divides by numSquares, paydayChance, and singleWinnerChance to compute outcomes. While these are validated upstream (constants in RaffleMining), defense-in-depth requires the Verification contract to protect itself independently.

require(numSquares > 0, "Verification: zero numSquares");
require(paydayChance > 0, "Verification: zero paydayChance");
require(singleWinnerChance > 0, "Verification: zero singleWinnerChance");

Entropy Sources:

1. Player actions (address, square, amount, timestamp, block number, prevrandao)
2. Block hashes (3 previous blocks)
3. block.timestamp
4. block.prevrandao (beacon chain randomness — included at all seed derivation points)
5. Per-round salt

WelephantRewards.sol

Security Features:

• OpenZeppelin AccessControl (DEPOSITOR_ROLE for WELEPHANT credits)
• ReentrancyGuard on all claims
• receive() credits sender (no lost ETH)
• ETH deposits permissionless (require actual ETH — no griefing vector)
• WELEPHANT credits restricted to DEPOSITOR_ROLE (RaffleMining game contract)
• Partial claims: if vault is underfunded, ETH is still claimed, WELEPHANT balance preserved for retry
• Only balance owner can claim

Key Findings:

Fix Applied (WR-04):

Replaced Ownable with AccessControl. Added DEPOSITOR_ROLE to creditWelephant(). Only the game contract (RaffleMining) can credit WELEPHANT. depositEth() remains permissionless since it requires actual ETH. Batch functions (batchDepositEth, batchCreditWelephant) removed — unused after RC-07 inlined all distribution.

// Before (vulnerable to zero-cost griefing):
function creditWelephant(address player, uint256 amount, string calldata label) external {

// After (protected):
function creditWelephant(address player, uint256 amount, string calldata label) external onlyRole(DEPOSITOR_ROLE) {

Fix Applied (WR-05):

Claims now support partial completion. If the WELEPHANT vault is underfunded, ETH is still claimed and WELEPHANT balance is restored for later retry:

// Before (all-or-nothing — reverts entire tx):
bool success = welephantVault.withdrawWelephant(msg.sender, welephantAmount);
require(success, "E78");

// After (partial claims — ETH still delivered):
bool success = welephantVault.withdrawWelephant(msg.sender, welephantAmount);
if (!success) {
    welephantBalances[msg.sender] = welephantAmount;  // Restore for retry
    emit RewardsClaimed(msg.sender, ethAmount, 0);
    return;
}

StakingVault.sol

Security Features:

• ERC4626 standard (OpenZeppelin)
• 100% permissionless (no owner/admin)
• SafeERC20 for transfers
• Inflation attack protection via _decimalsOffset

Key Findings:

WelephantVault.sol

Security Features:

• AccessControl with DEPOSITOR_ROLE, CONSUMER_ROLE, and CRANK_ROLE
• ReentrancyGuard on all state-changing functions
• SafeERC20 for token transfers
• Central liquidity vault for all WELEPHANT
• Try/catch safety - Only contract in ecosystem with try/catch around swaps
• Chunked swaps - Limits single-swap exposure
• Failure tracking - Monitors consecutive swap failures

Key Findings:

Critical Design: Async Swap Model

The vault implements a resilient async swap pattern:

1. depositETH()           → ETH received, no immediate swap
2. update()               → Refresh TWAP oracle paths (once per tx)
3. swapReserves()         → Pass maxSlippageBps to swapExactETHForWrappedTWAP
   ├── Success: WELEPHANT added to vault (TWAP-derived slippage at router level)
   └── Failure: Logged, crank continues (try/catch never reverts)
4. withdrawWelephant()    → JIT delivery to consumers

Configuration Parameters:

defaultSwapChunk = 1 ether;      // Limits single-swap size
minSwapAmount = 0.01 ether;      // Prevents dust swaps
maxSlippageBps = 500;            // 5% max slippage

Failure Monitoring:

uint256 consecutiveSwapFailures;  // Increments on failure, resets on success
string lastSwapError;             // Stores error reason for debugging

Architecture Note: The payday jackpot fund is now managed as an accounting-only pattern in GameHistory. The actual WELEPHANT tokens are held in WelephantVault and delivered JIT when needed.

GasChargeVault.sol

Security Features:

• AccessControl with DEPOSITOR_ROLE
• ReentrancyGuard on deposits/withdrawals
• Graceful cap on withdrawals (never reverts)
• receive() tracks all ETH

Key Findings:

Critical Design Decision:

function withdraw(...) returns (bool success) {
    // Cap to available pool - never revert to avoid bricking crank
    uint256 actualAmount = amount > gasChargePool ? gasChargePool : amount;
    if (actualAmount == 0) { return false; }
    // ... transfer logic
}

AutoPlayRegistry.sol (replaces AutoPlayDeposit.sol)

AutoPlayRegistry merges the former AutoPlayDeposit (ETH custody) with all auto-play state that previously lived in RaffleMining. This makes RaffleMining stateless — it can be replaced without losing player registrations or funds.

State held:

• mapping(address => AutoPlay) — registration structs (squares, rounds, amounts)
• EnumerableSet.AddressSet — active auto-play users
• mapping(address => PlayerAutoPlaySettings) — per-player preferences (loopEthRewards, autoStakeWelephant)
• mapping(address => uint256) — ETH balances for auto-play funding

Security Features:

• ReentrancyGuard on cancel (ETH transfer to player) and debit
• Ownable for setGameContract() — allows pointing to a new RaffleMining without losing state
• Only game contract can register, cancel, debit, or mutate auto-play state
• CEI pattern in all operations
• No direct player withdrawal (prevents state desync DDoS)
• cancelAutoPlay() requires roundsPlayed >= 1 (E85) to prevent register-then-cancel churn

Key Findings:

Design rationale: By co-locating auto-play registration state with ETH custody, the DDoS vector from the old AutoPlayDeposit (AP-07) is eliminated by design — there is no way to drain the deposit without also cleaning up the registration, because both live in the same contract and are managed atomically.

PendingPlaysRegistry.sol

Holds plays submitted after round expiry and their ETH until the crank processes them into the next round.

State held:

• PendingPlay[] — stack of pending plays (player, square, amount)
• ETH held in contract balance (sent with push(), returned with pop())

Security Features:

• ReentrancyGuard on pop (ETH transfer back to game contract)
• Ownable for setGameContract() — allows pointing to a new RaffleMining
• Only game contract can push or pop
• Stack-based (LIFO) — simple, no cursor management needed

Key Findings:

WelephantSwap.sol

Security Features:

• ReentrancyGuard on all swap functions
• SafeERC20 for token transfers (forceApprove, safeTransfer)
• call{value:}() instead of transfer() for ETH
• Immutable external addresses
• Solidity 0.8 native overflow protection
• TWAP Oracle Integration - Manipulation-resistant pricing
• Dual-Path Routing - Selects most liquid swap route

Key Findings:

TWAP Oracle Integration:

Uses IPcsSnapshotTwapOracle at 0x5606ee12d741716c260fDA2f6C89EfDf60326D3C:

// Must call update() once per transaction before TWAP operations
function update() external {
    twapOracle.updatePath([WBNB, ELEPHANT]);        // Direct path
    twapOracle.updatePath([WBNB, BUSD, ELEPHANT]);  // Indirect path
}

// TWAP-based estimate for crank accounting
function estimateWelephantForETHTwap(uint256 ethAmount, uint256 maxSlippageBps)
    returns (uint256 netWrappedAmount)

Dual-Path Routing:

Direct Path:   WBNB → ELEPHANT
Indirect Path: WBNB → BUSD → ELEPHANT

Path Selection:
- _getBestPathTWAP()    → For crank (manipulation-resistant)
- pathEthForCore()   → For UI (real-time spot prices)

Price Functions:

Fee Model:

SWAP_FEE_BASIS_POINTS = 25;           // 0.25% fee
MIN_FEE_FORWARD_AMOUNT = 1000e18;     // Threshold to forward
// Fees auto-forwarded to StakingVault.fundYield()

Fixes Applied:

1. Added ReentrancyGuard inheritance and nonReentrant modifier
2. Replaced payable(to).transfer() with call{value:}()
3. Removed inline SafeMath library (402 lines)
4. Imported OpenZeppelin's IERC20 and SafeERC20
5. Removed _swapETHForSender() — receive() now refunds ETH instead of executing a zero-slippage swap (EX-07)
6. Added TWAP oracle integration for manipulation resistance
7. Added dual-path routing for optimal liquidity
8. swapExactETHForWrappedTWAP() now takes slippageBps and passes TWAP-derived minimum to PancakeSwap router (EX-11)
9. _getBestPathTWAP() returns estimateAmount (best TWAP amount scaled by slippage) for router-level enforcement

RaffleMiningViews.sol

Security Features:

• Immutable storage reference
• Pure read-only functions
• Comprehensive pagination support
• All O(n) unbounded array functions removed

Key Findings:

Fix Applied (RV-06):

IRaffleMiningStorage.verifyRoundRandomness declared 17 return values but RaffleMining.verifyRoundRandomness returns 18. The interface was missing finalizationBlock (position 8 in the real implementation). At the ABI level, the caller decoded only 17 words from an 18-word response — positions 8+ were silently shifted to wrong values. getRoundSeed() only reads position 0 (accumulatedSeed) so it worked correctly, but any future use of later positions would have returned wrong data.

// Before (17 returns — missing finalizationBlock):
function verifyRoundRandomness(uint256 roundId) external view returns (
    bytes32 accumulatedSeed, bytes32 finalRandomSeed,
    bytes32 blockhash1, bytes32 blockhash2, bytes32 blockhash3,
    uint256 blockTimestamp, uint256 prevrandao,
    uint256 numSquaresUsed, // position 8 — actually finalizationBlock in real contract
    ...
);

// After (18 returns — matches RaffleMining):
function verifyRoundRandomness(uint256 roundId) external view returns (
    bytes32 accumulatedSeed, bytes32 finalRandomSeed,
    bytes32 blockhash1, bytes32 blockhash2, bytes32 blockhash3,
    uint256 blockTimestamp, uint256 prevrandao,
    uint256 finalizationBlock, // position 8 — correct
    uint256 numSquaresUsed,    // position 9 — correct
    ...
);

Fix Applied (RV-07):

IRaffleMiningStorage.getPlayerAutoPlaySettings declared 2 return values but the actual function returns 4. The Views wrapper silently dropped loopEthRewards and autoStakeWelephant. Added both missing fields to the interface and wrapper function.

Fix Applied (RV-08):

Added require(roundId > 0 && roundId <= gameHistory.currentRoundId(), "E01") to getRoundInfo() for consistency with getSquareInfo, getAllSquaresInfo, and getRoundSummaryById.

Removed Functions (O(n) unbounded):

• getRoundParticipants(roundId) - returned full array, use paginated version
• getPlayerRoundHistory(player, offset, limit) - fetched full array first
• getPlayerRecentRounds(player, count) - fetched full array first

Fixed Functions (now O(1)):

• getPlayerTotalRounds() - now uses getPlayerRoundIdCount()
• getPlayerDetailedStats() - now uses getPlayerRoundIdCount()

RaffleMiningLib.sol

Security Features:

• Pure/internal library functions only
• No external calls
• Handles edge cases (poolTotal == 0)

Key Findings:

RaffleMiningTypes.sol

Security Features:

• Pure library with no state or external calls
• Fee percentages as public constants (immutable)
• Game parameters as public constants (defaults for admin-updatable values)

Key Findings:

Fix Applied (RT-01):

RaffleMiningEvents defined a 5-parameter RoundFinalized event, but it was never emitted by any contract. The actual RoundFinalized events are emitted by:

• GameHistory.addRoundSummary() — 9-parameter version (roundId, totalPot, gameFee, welephantBoughtBack, paydayAmount, winningSquare, isPayday, isSingleWinner, singleWinner)
• Verification.finalizeRound() — 4-parameter version (roundId, finalRandomSeed, winningSquare, finalizationBlock)

Any ABI consumer using the Types library definition would have the wrong event signature and silently miss events. Removed the dead event definition and added a comment pointing to the canonical emit locations.

Fix Applied (RT-02):

RoundSummary.welephantBoughtBack is populated with welephantVault.estimateWelephantForETHTwap(gameFee) — a TWAP estimate. The actual swap happens asynchronously via processVaultSwaps(). Updated the field comment from "Total WELEPHANT from buyback (before distribution)" to "Estimated WELEPHANT via TWAP (actual swap is async)" to prevent misleading indexers/analytics.

Fix Applied (RT-03):

IStakingVault { fundYield(uint256) } was defined identically in three files: RaffleMiningTypes.sol, WelephantSwap.sol, and MockWelephantSwap.sol. Extracted to a standalone IStakingVault.sol file and replaced all three inline definitions with imports.

FeeAccounting.sol

Security Features:

• AccessControl with WRITER_ROLE and DISTRIBUTOR_ROLE
• Accounting-only pattern (no token custody)
• Separates fee recording from token transfers
• Enables async fee distribution

Key Findings:

Architecture:

The contract maintains pending fee counters without holding tokens:

uint256 private _pendingAdminFees;     // Accumulated admin fees
uint256 private _pendingStakingFees;   // Accumulated staking fees

Flow:

Round Finalization (WRITER_ROLE):
├── addAdminFee(amount)    → Increment counter (no transfer)
└── addStakingFee(amount)  → Increment counter (no transfer)

Crank Distribution (DISTRIBUTOR_ROLE):
├── distributeAdminFees()   → Zero counter, return amount
└── distributeStakingFees() → Zero counter, return amount
    ↓
Caller performs actual transfer via WelephantVault.withdrawWelephant()

Key Design Decision: By separating accounting from transfers, fee recording never blocks round finalization. Actual WELEPHANT transfers happen async when vault liquidity is available.

Access Control:

WRITER_ROLE      → CrankFinalization (records fees during finalization)
DISTRIBUTOR_ROLE → CrankFinalization (distributes when liquidity ready)

Common Vulnerability Checklist

Sponsorship Model & msg.sender Patterns

The system implements a deliberate sponsorship model where certain functions allow msg.sender to pay on behalf of other addresses. This is intentional, not a vulnerability.

Design Principles

Function Categories

Self-Only (msg.sender enforced):

Sponsorship (pay for others):

Security Rationale

1. Sponsorship functions cannot steal funds - The sponsor (msg.sender) always pays; they can only give, not take.

2. DoS protection on registerAutoPlay - Without the !autoPlays[player].active check, an attacker could repeatedly register auto-plays for a victim, overwriting their settings. The fix ensures only inactive players can have auto-play registered for them.

3. Withdrawal functions use msg.sender - All functions that return value to users (claimRewards, cancelAutoPlay, withdraw) use msg.sender to determine the recipient, ensuring you can only withdraw your own funds.

Access Control Matrix

PUBLIC Functions (Users)

ADMIN Functions (Governance)

PAUSER Functions (Emergency)

Pause Scope: Only play() and registerAutoPlay() carry the whenNotPaused modifier. All withdrawal and claim paths remain available during pause:

Design: Pause stops new money entering while allowing all existing funds to exit. The crank continues running so in-progress rounds finalize and credit rewards.

SYSTEM Functions (Internal Roles)

STORAGE_WRITER_ROLE (CrankCore + CrankFinalization → RaffleMining)

DEPOSITOR_ROLE (RaffleMining → WelephantRewards)

WRITER_ROLE (RaffleMining → GameHistory/Verification, CrankFinalization → FeeAccounting)

DISTRIBUTOR_ROLE (CrankFinalization → FeeAccounting)

DEPOSITOR_ROLE (RaffleMining → Vaults)

CONSUMER_ROLE (RaffleMining/Rewards/CrankFinalization → WelephantVault)

CRANK_ROLE (CrankFinalization → WelephantVault/Swap)

Note: Game constants roundDuration, cooldownBlocks, numSquares, singleWinnerChance, paydayDistributionPercent are immutable (no admin setters).

Threat Assessment

1. Admin Key Compromise

2. Crank Operator Compromise

3. Contract Address Update Attack

4. Price Oracle Manipulation

5. Griefing via Deposits

6. Reentrancy Attack

7. Flash Loan / Same-Block Manipulation

8. Denial of Service

Note (RC-06 fix): An earlier design used nested flush state machines for auto-staking and ETH looping that could permanently block crank progress. This was resolved by inlining these operations within the parent distribution loops with fallback to claimable rewards.

Note (AP-07 fix): AutoPlayRegistry has no direct withdraw() — the DDoS vector where attackers register auto-play, drain deposits, and leave zombie entries is eliminated by design. ETH custody and registration state are co-located in AutoPlayRegistry, so cancellation is always atomic. Additionally, cancelAutoPlay() requires at least 1 round played (E85) to prevent register-then-cancel churn.

Note (AT-01/AT-02 fix): Even without the AP-07 attack vector, zombie entries could accumulate organically when auto-play balances became insufficient mid-session. The crank now proactively deactivates and refunds players with insufficient balance both before play execution (AT-01) and after play execution (AT-02), regardless of the loopEthRewards setting.

9. Fee Swap Front-Running

Implementation:

All plays (manual, auto-play, and pending) route through RaffleMining._recordPlay(), which forwards the 10% game fee to WelephantVault immediately per-play:

Why This Works:

1. Unpredictable timing: Deposits occur at play time, not finalization
2. Smaller transactions: Each play's fee is a small fraction of total
3. No finalization target: At round end, fees are already deposited
4. TWAP protection: Combined with TWAP oracle, swap timing is resilient

Role Assignment Summary

DEFAULT_ADMIN_ROLE (Deployer/Multisig)
├── Can grant/revoke all roles
├── ADMIN_ROLE → Game parameter updates
└── PAUSER_ROLE → Emergency pause

STORAGE_WRITER_ROLE (CrankCore + CrankFinalization)
└── Batch processing writes to RaffleMining

WRITER_ROLE
├── RaffleMining → Writes to GameHistory, Verification
└── CrankFinalization → Writes to FeeAccounting

DEPOSITOR_ROLE (RaffleMining only)
└── Deposits to GasChargeVault, WelephantVault

CONSUMER_ROLE (RaffleMining, WelephantRewards, CrankFinalization)
└── Withdraws from WelephantVault

CRANK_ROLE (CrankFinalization only)
└── Swap operations on WelephantVault

DISTRIBUTOR_ROLE (CrankFinalization only)
└── Fee distribution from FeeAccounting

Gas Optimization Audit

Bitmask Storage Model

The largest per-play gas optimization is the bitmask storage model. Each player's square selections are stored as a single uint256 bitmask (bit N-1 = square N) with a uniform amountPerSquare, instead of per-square dynamic arrays.

Storage cost comparison per play:

Gameplay constraint: All selected squares receive the same amountPerSquare. This eliminates per-square amount arrays entirely. The constraint is documented in architecture.md.

squareTotals overhead: Recording a play still iterates the bitmask to update squareTotals[square] for each selected square (up to 16 SSTORE increments). This is unavoidable for proportional reward calculation but is write-only during play recording and read-only during distribution.

One play per round: Enforced via require(totalPlay == 0, "E43"). This eliminates the need to read and subtract old contributions from squareTotals when overwriting a play, saving up to 16 additional SLOADs + 16 SSTOREs per duplicate play attempt.

Recommendations

Implemented (No Action Required)

1. Fee percentages are constants - cannot be changed by admin
2. No emergency withdraw functions in vaults
3. Graceful degradation in GasChargeVault
4. SafeERC20 for all token operations
5. ReentrancyGuard on all value transfers

Future Considerations

1. Monitoring: Set up alerts for unusual crank activity
2. Upgrades: Deploy behind proxy pattern if upgradability needed
3. Rate Limiting: Consider per-block limits on auto-play registrations
4. Circuit Breakers: Pausable is implemented but ensure monitoring

February 2026 Pre-Launch Review

Review Date: February 7, 2026 Scope: Full re-review of all 32 contracts in /contracts/, plus architecture.md and audit.md Method: Line-by-line source review, cross-referencing documented fixes, architecture consistency checks

RW-01: creditWelephant() lacks access control — permanent reward lockout [HIGH]

File: WelephantRewards.sol:71-79 Status: FIXED

creditWelephant() was fully public with no access restriction. Unlike depositEth() which requires actual ETH (msg.value > 0), WELEPHANT credits are pure accounting and cost nothing. This enabled a zero-cost griefing attack:

1. Attacker calls creditWelephant(victim, type(uint256).max, "grief") — costs only gas
2. Victim's welephantBalances is inflated to an amount the vault can never cover
3. When victim calls claimRewards(), the vault returns false (insufficient balance)
4. Transaction reverts — victim can never claim any rewards

Fix: Replaced Ownable with OpenZeppelin AccessControl. Added DEPOSITOR_ROLE required by creditWelephant(). Only the RaffleMining game contract (granted DEPOSITOR_ROLE at deployment) can credit WELEPHANT. Batch functions (batchDepositEth, batchCreditWelephant) removed entirely — unused since RC-07 inlined all distribution. Corresponding proxy functions (batchDepositEthReward, batchDepositWelephantReward) removed from RaffleMining.sol and IRaffleMiningWritableStorage.sol. Frontend ABIs updated.

RW-02: claimRewards() all-or-nothing blocks ETH claims during vault underfunding [MEDIUM]

File: WelephantRewards.sol:129-152 Status: FIXED

The claim function zeroed both balances before transfers. If WELEPHANT withdrawal failed (vault underfunded), the revert restored both balances — player couldn't access ETH either.

Fix: Claims now support partial completion. If WELEPHANT vault is underfunded, ETH is still delivered and WELEPHANT balance is restored for later retry. No revert on vault underfunding. This now matches architecture.md ("claims never revert due to insufficient WELEPHANT").

RW-03: AddressMinHeap.setScore() has no access control [LOW]

File: AddressMinHeap.sol:33 Status: FIXED

setScore() was external with no restriction. The heap address is discoverable on-chain via deployment transaction traces, allowing anyone to manipulate the leaderboard.

Fix: Added OpenZeppelin Ownable to AddressMinHeap. setScore() is now onlyOwner. Owner is automatically set to GameHistory (the deploying contract via msg.sender in constructor).

RW-04: WelephantVault.receive() bypasses DEPOSITOR_ROLE [LOW]

File: WelephantVault.sol:261-263 Status: ACCEPTED (by design)

receive() intentionally accepts ETH from anyone to allow permissionless vault funding. Additional ETH increases swap reserves, benefiting the system by enabling larger WELEPHANT buybacks. This is a feature, not a bug.

RW-05: Crank setter functions lack events [INFO]

File: CrankFinalization.sol (previously RaffleMiningCrank.sol) Status: FIXED

setWelephantVault() and setFeeAccounting() didn't emit events. All equivalent setters in RaffleMining.sol emit events (e.g., WelephantVaultUpdated).

Fix: Added WelephantVaultUpdated(address oldVault, address newVault) and FeeAccountingUpdated(address oldFeeAccounting, address newFeeAccounting) events to CrankFinalization (where these setters now live after the CrankCore/CrankFinalization split). Both setters emit events with old and new addresses, consistent with the RaffleMining.sol convention. CrankCore also emits FinalizationContractUpdated when setFinalizationContract() is called.

RW-06: WelephantVault.setMinSwapAmount() has no bounds validation [INFO]

File: WelephantVault.sol:245-247 Status: FIXED

Previously accepted any value. Now enforces 0.0001 ether <= newMin <= 1 ether to prevent admin misconfiguration (dust swaps or disabled swaps).

Previously Reported Fixes — Verification Results

All fixes documented in the January 2026 audit have been verified against current source:

Architecture Verification Summary

February 10, 2026 Exhaustive Review

Review Date: February 10, 2026 Scope: Exhaustive third-pass audit of all Solidity files in /contracts/, building on Jan + Feb 7 baselines Method: Line-by-line review, crank revert propagation analysis, external call graph mapping, fee flow tracing, TOCTOU analysis

EX-01: _distributePendingFees lacks try/catch — can brick crank [MEDIUM]

File: CrankFinalization.sol:_distributePendingFees() (previously in RaffleMiningCrank.sol) Status: FIXED

_distributePendingFees() was the only unprotected external-call path in the entire crank execution flow. Unlike swapReserves() (try/catch) and depositToStakingVaultForPlayer() (try/catch), fee distribution made three unprotected external calls: withdrawWelephant(), token.approve(), and vault.fundYield(). If fundYield() reverted (e.g., token pause, StakingVault issue), the revert propagated through _processVaultSwaps() → _finishCrank() → crank(), bricking the crank.

Fix: Reordered operations so distributeStakingFees() (which zeros the accounting counter) is only called AFTER successful fundYield. Wrapped fundYield() in try/catch — on failure, WELEPHANT is returned to the vault and fees remain pending for retry on the next crank.

// Before (unprotected — revert bricks crank):
uint256 amount = feeAccounting.distributeStakingFees();  // Zeroes counter first
welephantVault.withdrawWelephant(address(this), amount);  // Return value ignored
token.approve(address(vault), amount);
vault.fundYield(amount);  // Revert propagates to crank()

// After (protected — fees retry on failure):
bool success = welephantVault.withdrawWelephant(address(this), pendingStaking);
if (success) {
    token.forceApprove(address(vault), pendingStaking);
    try vault.fundYield(pendingStaking) {
        feeAccounting.distributeStakingFees();  // Only zeroed on success
        distributed = true;
    } catch {
        token.safeTransfer(address(welephantVault), pendingStaking);  // Return tokens
    }
}

EX-02: withdrawWelephant return value unchecked in admin fee distribution [MEDIUM]

File: CrankFinalization.sol:_distributePendingFees() (previously in RaffleMiningCrank.sol) Status: FIXED

In the admin fee path, feeAccounting.distributeAdminFees() zeroed the counter before withdrawWelephant() was called. The boolean return value was ignored — if withdrawal returned false, admin fees were lost from accounting.

Fix: Reordered to withdraw first, check success, then zero the counter only on success:

// Before (counter zeroed before transfer):
uint256 amount = feeAccounting.distributeAdminFees();
welephantVault.withdrawWelephant(feeCollector, amount);  // Return ignored

// After (counter zeroed only on success):
bool success = welephantVault.withdrawWelephant(feeCollector, pendingAdmin);
if (success) {
    feeAccounting.distributeAdminFees();
    distributed = true;
}

EX-03: withdrawWelephant return value unchecked in staking fee distribution [MEDIUM]

File: CrankFinalization.sol:_distributePendingFees() (previously in RaffleMiningCrank.sol) Status: FIXED

Same pattern as EX-02 for staking fees, compounded by the fact that a false return led to fundYield() being called without tokens, causing a revert (triggering EX-01).

Fix: Combined with EX-01/02 — return value is now checked, and the entire staking distribution is wrapped in try/catch.

EX-04: setMaxSlippageBps allows 0 bps — would disable all swaps [LOW]

File: WelephantVault.sol:setMaxSlippageBps() Status: FIXED

Only validated <= 10000, allowing 0. With ELEPHANT being a fee-on-transfer token, actual swap output is always less than the TWAP estimate. Setting slippage to 0 would cause every swap to fail because minOut would equal the pre-tax TWAP estimate, which post-tax output can never match.

Fix: Added minimum floor of 50 bps (0.5%):

require(newSlippageBps >= 50, "WelephantVault: slippage too low");
require(newSlippageBps <= 10000, "WelephantVault: slippage exceeds 100%");

EX-05: No upper bound on defaultSwapChunk [LOW]

File: WelephantVault.sol:setDefaultSwapChunk() Status: FIXED

Only validated > 0. An extremely large chunk could cause massive slippage.

Fix: Added upper bound of 100 ETH:

require(newChunk > 0, "WelephantVault: zero chunk");
require(newChunk <= 100 ether, "WelephantVault: chunk too large");

EX-06: Fee accounting drift from TWAP estimation vs actual swap results [LOW]

Status: ACKNOWLEDGED (by design)

During round finalization, WELEPHANT fee amounts are estimated via TWAP. Actual swaps may produce more or less due to TWAP lag, fee-on-transfer tax, and slippage. This creates gradual accounting drift.

Existing mitigations: canWithdraw guards, partial claims in WelephantRewards, admin can top up vault directly. The system handles underfunding gracefully.

EX-07: WelephantSwap.receive() executes zero-slippage swap [MEDIUM]

File: WelephantSwap.sol:receive() Status: FIXED

The receive() fallback performed a full swap flow via _swapETHForSender() passing 0 as amountOutMin to the PancakeSwap router, with no post-swap slippage check and no nonReentrant guard. Every direct ETH transfer to WelephantSwap was fully vulnerable to sandwich attacks.

Fix: Removed _swapETHForSender() entirely. receive() now refunds ETH to the sender. Callers must use swapExactETHForWrapped() or swapExactETHForWrappedTWAP() (both with slippage protection) to perform swaps:

receive() external payable {
    if (msg.value > 0) {
        (bool success, ) = msg.sender.call{value: msg.value}("");
        require(success, "ETH refund failed");
    }
}

EX-08: approve instead of forceApprove in crank and staking paths [INFO]

Files: RaffleMining.sol:depositToStakingVaultForPlayer(), CrankFinalization.sol:_distributePendingFees() (previously in RaffleMiningCrank.sol) Status: FIXED

Both used token.approve() instead of SafeERC20.forceApprove(). While WELEPHANT follows standard ERC20, forceApprove is the established best practice and was already used elsewhere (WelephantSwap).

Fix: Replaced both with forceApprove. Added SafeERC20 import and using directive to RaffleMiningCrank.

EX-09: BlockInfo.sol test utility in production contracts directory [INFO]

File: contracts/BlockInfo.sol Status: FIXED

Self-documented as "A simple test contract" used for deployment credential testing. Did not belong in the production /contracts/ directory.

Fix: Moved to contracts/test/BlockInfo.sol. Ignition module and deploy script reference by contract name (unchanged).

EX-10: sendETHDirect is unused dead code with elevated permissions [INFO]

File: RaffleMining.sol:sendETHDirect() Status: FIXED

External function gated by STORAGE_WRITER_ROLE that sent ETH directly from the RaffleMining contract's balance to any address. Not declared in IRaffleMiningWritableStorage, not called by the crank or any contract. Compare with sendETH() which IS used and properly routes through GasChargeVault. The dead code expanded the attack surface if the writer role were compromised.

Fix: Removed sendETHDirect() from RaffleMining.sol and the corresponding ABI entry from the frontend.

EX-11: swapExactETHForWrappedTWAP passes 0 as router amountOutMin — MEV sandwich vector [MEDIUM]

File: WelephantSwap.sol:swapExactETHForWrappedTWAP() Status: FIXED

swapExactETHForWrappedTWAP() — the primary swap path used by WelephantVault.swapReserves() during every crank cycle — passed 0 as amountOutMin to the PancakeSwap router. While a post-swap require(wrappedAmount >= amountOutMin) existed, the router call itself was unprotected. A sandwich bot could manipulate the pool price during the router call and extract value up to the amountOutMin threshold on every crank cycle.

Fix (3 coordinated changes):

1. _getBestPathTWAP(wethAmount, slippageBps) now returns (path, directAmount, indirectAmount, estimateAmount) where estimateAmount is the best TWAP amount scaled down by slippage.

2. swapExactETHForWrappedTWAP(slippageBps, to) takes slippageBps instead of amountOutMin. It passes the TWAP-derived minimum directly to the PancakeSwap router:

// BEFORE: zero slippage at router level, post-swap check only
collateralRouter.swapExact...{value:msg.value}(0, path, ...);
require(wrappedAmount >= amountOutMin, "Insufficient output amount");

// AFTER: TWAP-derived minimum enforced at router level
(address[] memory path,,, uint256 minCoreOut) = _getBestPathTWAP(msg.value, slippageBps);
collateralRouter.swapExact...{value:msg.value}(minCoreOut, path, ...);

3. WelephantVault.swapReserves() passes maxSlippageBps directly instead of pre-computing minOut:

// BEFORE:
uint256 minOut = _welephantSwap.estimateWelephantForETHTwap(swapAmount, maxSlippageBps);
try _welephantSwap.swapExactETHForWrappedTWAP{value: swapAmount}(minOut, address(this))

// AFTER:
try _welephantSwap.swapExactETHForWrappedTWAP{value: swapAmount}(maxSlippageBps, address(this))

The router now enforces the slippage floor during the swap. The try/catch in swapReserves() catches any revert, so a failed swap doesn't brick the crank.

Crank Revert Propagation — Complete Safety Analysis

After applying EX-01/02/03, every external call in the crank execution path is now protected:

CrankCore.crank() [nonReentrant]
├── CrankFinalization.selectSingleWinner()     → Cursor-based, gas-checked        ✓
├── CrankFinalization.distributeWelephant...() → try/catch on auto-stake           ✓
├── CrankFinalization.distributeETH...()       → Inline deposits                   ✓
├── _startNewRound()                           → Internal state only               ✓
├── _processAutoPlays()                        → Backward iteration, gas-checked   ✓
├── _processPendingPlays()                     → Forward iteration, gas-checked    ✓
├── CrankFinalization.finalizeRoundWith...()   → Internal calculations             ✓
├── CrankFinalization.finalizeRound()          → Internal state + FeeAccounting    ✓
├── _refundGasCost()                           → GasChargeVault (never reverts)    ✓
└── _finishCrank()
    ├── CrankFinalization.processVaultSwaps()
    │   ├── welephantVault.update()            → Oracle update                     ✓
    │   ├── welephantVault.swapReserves()      → try/catch                         ✓
    │   └── _distributePendingFees()           → try/catch + return checks         ✓ FIXED
    └── _emitHeartbeat()                       → View calls + emit                 ✓

Architecture Verification Summary (Updated)

February 13, 2026 — CrankCore + CrankFinalization Split

Date: February 13, 2026 Scope: Contract size reduction — split RaffleMiningCrank.sol into two deployed contracts Reason: RaffleMiningCrank.sol exceeded the 24,576 byte EVM Spurious Dragon contract size limit (was 30,715 bytes with optimizer runs: 1, viaIR: true)

CS-01: Contract Split — CrankCore + CrankFinalization [STRUCTURAL]

Status: IMPLEMENTED

RaffleMiningCrank.sol was split into two contracts:

Access Control Changes:

• CrankFinalization uses onlyCrankCore modifier (checks msg.sender == crankCore) for all externally-called functions
• CONSUMER_ROLE + CRANK_ROLE on WelephantVault moved from CrankCore → CrankFinalization
• DISTRIBUTOR_ROLE + WRITER_ROLE on FeeAccounting moved from CrankCore → CrankFinalization
• Both contracts hold STORAGE_WRITER_ROLE on RaffleMining
• CrankCore no longer holds welephantVault or feeAccounting references

Security Properties Preserved:

• Same crank execution flow and priority order (single winner → distribution → new round → auto-plays → pending plays → vault swaps)
• Same state machine patterns (cursor + inProgress flags)
• Same try/catch safety coverage on all external calls
• Same gas-checked batch processing
• address(this) in CrankFinalization correctly resolves to CrankFinalization for temporary token holding during staking fee distribution

Deployment Wiring:

CrankCore.setFinalizationContract(crankFinalization)
CrankFinalization.setCrankCore(crankCore)
CrankFinalization.setWelephantVault(welephantVault)
CrankFinalization.setFeeAccounting(feeAccounting)

February 13, 2026 — Vault Contract Security Review

Review Date: February 13, 2026 Scope: Focused security review of all vault/registry contracts that hold user funds long-term: WelephantVault, StakingVault, GasChargeVault, AutoPlayRegistry (formerly AutoPlayDeposit), PendingPlaysRegistry, WelephantRewards Method: Attack surface analysis, reentrancy path mapping, admin privilege escalation, MEV/front-running vectors

VR-01: AutoPlayRegistry (formerly AutoPlayDeposit) — nonReentrant coverage [MEDIUM-LOW]

File: AutoPlayRegistry.sol Status: FIXED (carried forward from AutoPlayDeposit)

All ETH-transferring functions (cancel, debit) have nonReentrant applied. The original issue (VR-01) was that ReentrancyGuard was inherited but not applied to functions making external ETH transfers. This was fixed in AutoPlayDeposit and the fix carried forward to AutoPlayRegistry.

VR-02: AutoPlayRegistry — No direct withdrawal by design [LOW]

File: AutoPlayRegistry.sol Status: RESOLVED by design

AutoPlayRegistry has no direct withdraw() function. Players use cancelAutoPlay() which atomically cleans up registration state and refunds ETH. Because auto-play state and ETH custody are co-located in the same contract, there is no state desync risk (the original AP-07 DDoS vector is eliminated by design).

VR-03: WelephantVault maxSlippageBps upper bound too high (100%) [LOW]

File: WelephantVault.sol:setMaxSlippageBps() Status: FIXED

setMaxSlippageBps permitted values up to 10000 (100%). A compromised admin could set 100% slippage tolerance, making swapReserves accept any output amount and enabling sandwich attacks that extract nearly all ETH value during swaps.

Fix: Reduced upper bound from 10000 to 2000 (20%):

// Before:
require(newSlippageBps <= 10000, "WelephantVault: slippage exceeds 100%");

// After:
require(newSlippageBps <= 2000, "WelephantVault: slippage exceeds 20%");

VR-04: GasChargeVault — Single role for deposit and withdraw [INFO]

File: GasChargeVault.sol Status: ACCEPTED (by design)

DEPOSITOR_ROLE controls both deposit() and withdraw(). In theory, separating into DEPOSITOR_ROLE / WITHDRAWER_ROLE would limit blast radius if a consumer contract were compromised. In practice, only the crank contract holds this role, and the crank needs both operations (collect gas charges from players, refund gas to the operator).

VR-05: StakingVault — JIT yield sniping via fundYield front-running [ACCEPTED — LOW RISK]

File: StakingVault.sol:fundYield() Status: ACCEPTED (risk mitigated by design)

The StakingVault has no deposit lock or withdrawal delay. Since fundYield() is permissionless and immediately increases share price via ERC4626 mechanics, an attacker could theoretically:

1. See a fundYield(100 WELEPHANT) transaction in the mempool
2. Front-run with a large deposit to capture the majority of shares
3. Back-run with redeem after the yield lands

However, the crank's 60-second round cadence acts as an application-layer drip mechanism that makes this attack economically unviable:

• Tiny per-call yield: Each fundYield delivers one round's staking fee share (~20% of one round's fees). The extractable value per snipe is negligible.
• Gas cost floor: The attacker must pay gas for both deposit and redeem on every attempt. At 60-second intervals, gas costs exceed the capturable yield.
• No surprise lump sums: Yield arrives in small, predictable, frequent increments — there is no large single-transaction windfall to front-run.
• Capital inefficiency: The attacker must acquire and hold a large WELEPHANT position. Slippage on acquisition and disposal further erodes any theoretical profit.

The StakingVault is intentionally permissionless (no owner, no roles, no admin keys) to match the decentralization properties of the WELEPHANT token itself. Adding time-locks or entry fees would compromise this design goal for marginal benefit against an attack that is already economically impractical given the crank's continuous small-yield pattern.

February 17, 2026 — Flat Gas Tax & Sweep Threshold

Date: February 17, 2026 Scope: Gas charge model replacement and sweep buffer threshold

GT-01: Flat Gas Tax Model — Now Immutable [STRUCTURAL]

Status: IMPLEMENTED → HARDENED (constant)

Replaced the per-play gas unit model (gasUnitsPerPlay × gasChargeMultiplier × gasPrice) with a flat percentage tax on play amounts. The gas tax is permanently fixed at 1% (100 basis points) of the total play amount.

Originally gasTaxBasisPoints was a configurable state variable with setGasTaxBasisPoints() (range: 1–100 bps). As of February 17, 2026, it has been made an immutable constant — the setter and GasTaxBasisPointsUpdated event have been removed. calculateGasCharge() is now pure instead of view.

Removed state variables: gasUnitsPerPlay, gasChargeMultiplier, gasTaxBasisPoints (→ constant) Removed admin setters: setGasUnitsPerPlay(), setGasChargeMultiplier(), setGasTaxBasisPoints() Removed events: GasTaxBasisPointsUpdated

// Before (configurable — admin attack surface):
uint256 public gasTaxBasisPoints = 10;
function setGasTaxBasisPoints(uint256 newBps) external onlyRole(ADMIN_ROLE) { ... }
function calculateGasCharge(uint256 totalAmount) public view returns (uint256) { ... }

// After (immutable — zero admin surface):
uint256 public constant gasTaxBasisPoints = 100;
function calculateGasCharge(uint256 totalAmount) public pure returns (uint256) { ... }

Security properties:

• Gas tax scales proportionally with play size — no fixed-cost manipulation
• Immutable constant — cannot be changed by admin, eliminating misconfiguration risk
• Gas charge calculation is a pure function with no external dependencies

GT-02: Gas Charge Pool Sweep — 10% Buffer Threshold [ENHANCEMENT]

Status: IMPLEMENTED

Previously, excess gas charges were swept to WelephantVault whenever the pool exceeded maxGasChargePool. Now the sweep only triggers when the pool exceeds 110% of maxGasChargePool (a 10% buffer). This avoids frequent small sweeps on every crank cycle. The excess pads WELEPHANT buybacks without changing the economics of the fee split.

Changed logic in:

• RaffleMining.sweepGasChargeExcess() — adds threshold = maxGasChargePool + maxGasChargePool / 10 guard
• RaffleMiningCrank._sweepGasChargeExcess() — mirrors the same cap + cap / 10 check

// Before (any excess triggers sweep):
if (pool <= maxGasChargePool) return 0;

// After (10% buffer before sweep):
uint256 threshold = maxGasChargePool + maxGasChargePool / 10;
if (pool <= threshold) return 0;

uint256 excess = pool - maxGasChargePool;  // Still sweeps all excess down to cap

Security properties:

• No new attack surface — same sweep destination (WelephantVault)
• Threshold is deterministic (no oracle dependency)
• When triggered, sweep still drains to maxGasChargePool (not to threshold)

February 17, 2026 — Auto-Play Termination Hardening

Date: February 17, 2026 Scope: Zombie auto-play cleanup, broadened termination checks, event signature consistency, UX view function Method: Crank iteration analysis, gas waste profiling, event ABI verification

AT-01: Zombie auto-play entries consume crank gas indefinitely [MEDIUM]

File: RaffleMiningCrank.sol:_processAutoPlayForPlayer() Status: FIXED

When a player had active auto-play but insufficient balance to cover totalCost (play amount + gas tax), the crank silently skipped them but left them in the activeAutoPlayUsers EnumerableSet. These zombie entries were iterated on every crank batch forever, wasting gas without producing any plays.

Root cause: The pre-play balance check returned early without deactivating the player.

Fix: Insufficient balance now triggers immediate deactivation and refund:

// Before (zombie — skipped but never cleaned up):
uint256 balance = autoPlayRegistry.balanceOf(player);
if (balance < totalCost) return;  // Zombie: iterated every batch, does nothing

// After (cleaned up immediately):
uint256 balance = autoPlayRegistry.balanceOf(player);
if (balance < totalCost) {
    // Insufficient balance — deactivate and refund via registry
    autoPlayRegistry.setActive(player, false);
    autoPlayRegistry.cancel(player);
    return;
}

Impact: Prevents unbounded gas waste from accumulated zombie entries. Each zombie added ~5,000 gas per crank cycle with no useful work performed.

AT-02: Post-play termination gated on loopEthRewards flag [LOW]

File: RaffleMiningCrank.sol:_processAutoPlayForPlayer() Status: FIXED

After executing a play, the post-play termination check only fired when loopEthRewards == true AND the remaining balance was below totalCost. A non-looping player whose balance fell below totalCost mid-session (e.g., due to gas tax rounding or partial deposits) would fall through uncleaned — becoming a zombie on subsequent iterations.

Fix: Removed the loopEthRewards gate. Termination now fires unconditionally when balance is insufficient:

// Before (only terminates looping players with low balance):
} else if (loopEthRewards && newBalance < totalCost) {
    autoPlayRegistry.setActive(player, false);
    autoPlayRegistry.cancel(player);
}

// After (terminates any player with insufficient balance):
} else if (newBalance < totalCost) {
    // Insufficient balance for next round — terminate and refund
    autoPlayRegistry.setActive(player, false);
    autoPlayRegistry.cancel(player);
}

AT-03: GasRefunded event signature mismatch between interface and types [INFO]

Files: IRaffleMining.sol, RaffleMiningTypes.sol Status: FIXED

The GasRefunded event was declared inconsistently:

• IRaffleMining.sol: event GasRefunded(address indexed recipient, uint256 amount)
• RaffleMiningTypes.sol: event GasRefunded(address indexed recipient, uint256 amount, string operation)

The stale string operation third parameter in RaffleMiningTypes.sol was never emitted anywhere in the codebase. This mismatch could cause ABI decoding failures in off-chain indexers and frontend event listeners.

Fix: Removed the stale string operation parameter from RaffleMiningTypes.sol to match the canonical interface declaration.

AT-04: canCancelAutoPlay view function for proactive UX [ENHANCEMENT]

File: RaffleMining.sol Status: IMPLEMENTED

Added a view function so the frontend can pre-check cancellation eligibility before sending a transaction:

function canCancelAutoPlay(address player) external view returns (
    bool canCancel,
    bool isActive,
    uint256 roundsPlayed
) {
    RaffleMiningTypes.AutoPlay storage autoPlay = autoPlays[player];
    isActive = autoPlay.active;
    roundsPlayed = autoPlay.roundsPlayed;
    canCancel = isActive && roundsPlayed >= 1;
}

This allows the frontend to give immediate feedback (e.g., "Cannot cancel yet — at least 1 round must complete first") instead of waiting for a reverted transaction. Complements the E85 guard added in AP-07.

AT-05: setCrankCore missing zero-address check [LOW]

File: CrankFinalization.sol:setCrankCore() Status: FIXED

Unlike setWelephantVault (validates _welephantVault != address(0), error E79) and setFeeAccounting (validates _feeAccounting != address(0), error E77), setCrankCore had no zero-address validation. Setting crankCore to address(0) would permanently lock out all onlyCrankCore functions — no transaction can originate from address(0) — bricking finalization, distribution, and vault swaps with no recovery path.

Fix: Added zero-address validation consistent with sibling setters:

// Before (no validation):
function setCrankCore(address _crankCore) external {
    require(storageContract.hasRole(bytes32(0), msg.sender), "E60");
    ...

// After (zero-address protected):
function setCrankCore(address _crankCore) external {
    require(storageContract.hasRole(bytes32(0), msg.sender), "E60");
    require(_crankCore != address(0), "E60");
    ...

February 20, 2026 Zero-Amount Guard Audit

Review Date: February 20, 2026 Scope: All crank-driven paths that transfer ETH or WELEPHANT, checking for missing zero-amount guards Trigger: Production crank revert with GasChargeVault: zero amount during gas estimation

ZG-01: _refundGasCost reverts when tx.gasprice is 0 during gas estimation [MEDIUM]

File: RaffleMiningCrank.sol:_refundGasCost() Status: FIXED

During eth_estimateGas on BSC, tx.gasprice can be 0. The existing guards (gasChargePool == 0 || gasUsed == 0) pass because both are non-zero, but refundAmount = gasUsed * 0 = 0. This flows into gasChargeVault.withdraw(recipient, 0) which reverts with "GasChargeVault: zero amount", preventing the crank from executing any work.

Fix: Added if (refundAmount == 0) return; after computing refundAmount.

ZG-02: Distribution loops revert on zero proportional rewards [MEDIUM]

File: CrankFinalization.sol:_distributeETHToWinners(), _distributeWelephantToWinners() Status: FIXED

RaffleMiningLib.calculateProportionalReward() computes (totalAmount * playerAmount) / poolTotal which can return 0 due to integer rounding. The downstream contracts all enforce require(amount > 0):

• WelephantRewards.depositEth() — require(msg.value > 0)
• WelephantRewards.creditWelephant() — require(amount > 0)
• AutoPlayRegistry.credit() — require(msg.value > 0)
• StakingVault.deposit() — require(amount > 0)

A zero reward for any player would revert the entire crank transaction, halting all distributions.

Fix: Wrapped the deposit and stats recording in both distribution loops with if (reward > 0). Players with zero rewards (due to rounding) are skipped — cursor still advances, no funds lost.

ZG-03: addPaydayFund reverts on zero TWAP estimates [LOW]

File: CrankFinalization.sol:_finalizeRound() Status: FIXED

GameHistory.addPaydayFund() requires amount > 0 but is called from three paths that can produce 0:

1. Line 360: paydayContribution = (estimatedWelephant * paydayFundPercent) / 100 — rounds to 0 when estimatedWelephant * paydayFundPercent < 100
2. Line 391: remainingWelephant = estimatedWelephant - adminFee - stakingFee — is 0 when estimatedWelephant == 0 (no game fee collected)
3. Line 397: additionalEstimate = estimateWelephantForETHTwap(winnersPool) — TWAP oracle can return 0

Fix: Added if (amount > 0) guards before each addPaydayFund call.

ZG-04: Single-winner WELEPHANT distribution reverts on zero amount [LOW]

File: CrankFinalization.sol:_finalizeRound() Status: FIXED

In the single-winner path, welephantToDistribute = remainingWelephant - paydayContribution can be 0. This flows directly into either depositToStakingVaultForPlayer (requires amount > 0) or depositWelephantReward → creditWelephant (requires amount > 0), reverting the finalization.

Fix: Wrapped the entire single-winner/distribution block in if (welephantToDistribute > 0).

ZG-06: estimateWelephantForETHTwap reverts when TWAP oracle uninitialized [HIGH]

File: CrankFinalization.sol:_finalizeRound() Status: FIXED

After a fresh deploy (RESET), the PcsSnapshotTwapOracle may not have enough observations for the registered paths. welephantVault.estimateWelephantForETHTwap(gameFee) calls through to TWAP_ORACLE.consultAmountsOut() which reverts when insufficient snapshots exist. This bare external call is not wrapped in try/catch, so the revert propagates and halts the entire finalization — the crank cannot finalize any round until the oracle warms up.

Two call sites affected:

1. Line 322: estimateWelephantForETHTwap(gameFee) — main WELEPHANT estimation for fee accounting
2. Line 402: estimateWelephantForETHTwap(winnersPool) — payday fund estimation for no-winner rounds

BSC nodes do not return revert data for failed transactions, so the error presents as reason=null, data=null — making the root cause difficult to diagnose on-chain.

Fix: Wrapped both estimateWelephantForETHTwap calls in try/catch. On failure, estimatedWelephant defaults to 0 and the existing zero-amount guards (ZG-02 through ZG-04) handle all downstream cases safely. WELEPHANT accounting catches up on subsequent rounds once the oracle has data.

ZG-05: Paths confirmed safe — no fix needed [INFO]

Status: VERIFIED

The following paths were reviewed and confirmed safe:

Conclusion

The Prediction Mining smart contract system demonstrates mature security practices across three audit passes:

January 2026 Audit: 11 findings fixed (RM-05, RC-01/06/07/08, GH-01, WS-01/02, V-04/05, RV-03)

February 7, 2026 Pre-Launch Review:

• 1 High (RW-01: creditWelephant() griefing — FIXED)
• 1 Medium (RW-02: all-or-nothing claims — FIXED)
• 2 Low (RW-03: AddressMinHeap Ownable — FIXED, RW-04: vault receive() accepted by design)
• 2 Info (RW-05: crank setter events — FIXED, RW-06: setMinSwapAmount bounds — FIXED)

February 10–13, 2026 Exhaustive Review:

• 5 Medium (EX-01/02/03: _distributePendingFees try/catch + return value checks — FIXED, EX-07: receive() zero-slippage swap removed — FIXED, EX-11: swapExactETHForWrappedTWAP router slippage — FIXED)
• 3 Low (EX-04: slippage floor — FIXED, EX-05: chunk cap — FIXED, EX-06: TWAP drift — ACKNOWLEDGED)
• 3 Info (EX-08: forceApprove — FIXED, EX-09: BlockInfo moved — FIXED, EX-10: sendETHDirect removed — FIXED)

February 13, 2026 Vault Security Review:

• 1 Medium-Low (VR-01: AutoPlayRegistry nonReentrant coverage — FIXED)
• 1 Medium (AP-07: withdraw() DDoS vector — RESOLVED by design in AutoPlayRegistry, co-located state eliminates desync)
• 2 Low (VR-02: no escape hatch — RESOLVED by design, VR-03: WelephantVault slippage cap — FIXED)
• 1 Info (VR-04: GasChargeVault single role — ACCEPTED)
• 1 Info (VR-05: StakingVault JIT yield sniping — ACCEPTED, mitigated by crank's 60-second yield cadence)

February 17, 2026 Gas Tax & Sweep Threshold:

• 2 Structural (GT-01: flat 1% gas tax, now immutable constant — HARDENED, GT-02: 10% buffer threshold before gas charge sweep — IMPLEMENTED)

February 17, 2026 Auto-Play Termination Hardening:

• 1 Medium (AT-01: zombie auto-play entries consume crank gas indefinitely — FIXED)
• 1 Low (AT-02: post-play termination gated on loopEthRewards flag — FIXED)
• 1 Low (AT-05: setCrankCore missing zero-address check — FIXED)
• 1 Info (AT-03: GasRefunded event signature mismatch — FIXED)
• 1 Enhancement (AT-04: canCancelAutoPlay view function for proactive UX — IMPLEMENTED)

February 17, 2026 WelephantSwap Fee Forwarding Review:

• 1 Medium (WS-11: _forwardFeesToVault fundYield revert permanently bricks all swaps — FIXED)
• 1 Info (WS-12: estimateCoreToCollateral unused dead code — FIXED)

February 17, 2026 WelephantRewards Review:

• 1 Info (WR-06: welephantToken unused dead state — FIXED)

February 17, 2026 WelephantVault Review:

• 2 Medium (WV-10: setWelephantSwap silent change — FIXED; WV-12: no ETH rescue — FIXED)
• 2 Low (WV-11: admin setters missing events — FIXED; WV-13: unbounded lastSwapError — FIXED)

February 19, 2026 Registry Architecture:

• RaffleMining made stateless — auto-play state (structs, active set, settings, ETH balances) moved to AutoPlayRegistry; pending plays moved to PendingPlaysRegistry
• AutoPlayDeposit retired and replaced by AutoPlayRegistry (merges ETH custody + registration state)
• PendingPlaysRegistry introduced (pending play queue + ETH custody)
• Upgrade path: pause RaffleMining, finish crank, deploy new instance, update registry gameContract pointers

The codebase follows industry best practices:

• Battle-tested OpenZeppelin libraries (AccessControl, ReentrancyGuard, SafeERC20, ERC4626)
• Consistent CEI pattern with ReentrancyGuard on all value-transfer functions
• Comprehensive role-based access control across 8 distinct roles
• Gas-efficient batch processing with cursor pattern
• Complete try/catch safety coverage across the entire crank execution path
• Rug-proof vault design with immutable fee constants
• Partial claim support for resilient reward delivery
• Admin parameter bounds validation on all configuration setters
• Stateless game coordinator — all persistent state in registries that survive upgrades

February 20, 2026 Zero-Amount Guard Audit:

• 1 High (ZG-06: estimateWelephantForETHTwap reverts on uninitialized TWAP oracle — FIXED)
• 2 Medium (ZG-01: _refundGasCost tx.gasprice=0 revert — FIXED, ZG-02: distribution loop zero-reward reverts — FIXED)
• 2 Low (ZG-03: addPaydayFund zero TWAP estimates — FIXED, ZG-04: single-winner zero WELEPHANT — FIXED)
• 1 Info (ZG-05: 5 paths verified safe — VERIFIED)

March 6–8, 2026 Gas Optimization Pass (Wave 1 — Bitmask Storage Migration):

• 1 Structural (GO-01: replaced per-square dynamic arrays with uint256 bitmask + uniform amountPerSquare — 2 SSTOREs per play vs up to 32 — IMPLEMENTED)
• 1 High (GH-12: recordPlayerPlay loop bound used popcount instead of board size — FIXED)
• 1 High (RM-07: multiple plays per round corrupted squareTotals — FIXED with one-play-per-round enforcement)
• 1 Medium (RM-08: pending play duplicates after auto-play — FIXED with crank-side duplicate check)

March 8, 2026 Gas Optimization Pass (Wave 2 — Hot Path Optimizations):

• 7 Enhancement (GO-02: inline Fisher-Yates bitmap with early return — IMPLEMENTED, GO-03: cached hasMinPlayers eliminates redundant getRoundCore() — IMPLEMENTED, GO-04: Kernighan's bit counting replaces 256-bit loop — IMPLEMENTED, GO-05: getPlayerRoundData() batch getter eliminates dual cross-contract calls in distribution loops — IMPLEMENTED, GO-06: pre-fetched balanceOf() eliminates redundant call — IMPLEMENTED, GO-07: pre-fetched auto-play settings eliminates redundant getPlayerAutoPlaySettings() — IMPLEMENTED, GO-08: unchecked autoPlayBatchCursor-- in overflow-safe loop — IMPLEMENTED)
• 1 Configuration (GO-09: simulator gas price corrected from 1 gwei to 0.05 gwei — FIXED)

Assessment: All findings from ten audit passes have been addressed. No open issues remain. Ready for mainnet deployment.

Appendix: All Fixes Applied

AddressMinHeap.sol

Security Features:

• Ownable access control — only GameHistory (deployer) can call setScore
• Bounded size K=100 — O(log K) mutations, no unbounded loops in state-modifying functions
• 1-based array indexing with sentinel at index 0
• heapIndex mapping prevents duplicate entries for the same address

Key Findings:

Overall: Core heap algorithm is correct. No critical or high-severity issues.

Multicall3.sol

Assessment: Canonical Multicall3 adaptation — widely deployed at 0xcA11bde05977b3631167028862bE2a173976CA11 on most EVM chains.

Differences from canonical:

Key Findings:

Overall: No security issues. Battle-tested canonical contract.

Interface Verification (All I*.sol Files)

All 16 interface files were verified against their implementations on February 18, 2026.