Anti-fraud for Crypto Casinos: Chainlink VRF, ML Scoring, AML

Case: Crypto casino losing tens of thousands of dollars weekly to bonus hunters

Imagine your crypto casino losing significant amounts due to bonus hunters. They create hundreds of wallets and drain welcome bonuses. Blockchain anonymity is a double-edged sword: it attracts users but simplifies attacks. We develop anti-fraud systems for crypto casinos that block suspicious transactions, analyze on-chain behavior, cluster wallets, and predict anomalies before damage occurs. Our system processes over 1,000 transactions per day with 99% accuracy. This article covers working tools: from Chainlink VRF to real-time ML scoring.

Crypto casinos face a unique combination of threats: bonus abuse via Sybil attacks, randomness manipulation at the validator level, collusion between players, money laundering, and use of compromised wallets. Losses from bonus hunting can reach 5% of revenue. Our experience shows that effective anti-fraud depends on combining on-chain and off-chain analytics. Over time, we have implemented protection for 15+ projects, reducing fraud losses by an average of 80%. We prevent losses in the millions of dollars.

Threat Landscape

Bonus Hunting and Multi-Accounting

Welcome bonuses in crypto casinos often amount to 100–200% of the deposit. An attacker creates dozens of wallets, claims the bonus on each, and withdraws with minimal wagering. The problem is exacerbated by the lack of email or phone binding — only the wallet address. Our Sybil detection uses clustering by common funding source and temporal correlations.

On-Chain Randomness Manipulation

Contracts that use block.timestamp or block.prevrandao as a source of randomness are vulnerable: validators can shift the timestamp or select a favorable block. Even block.prevrandao (RANDAO) is not a cryptographically secure source of randomness for gambling — it can be partially predicted.

Flash Loan + Game State Manipulation

Some games have on-chain state. A flash loan allows:

1. Borrowing a large amount
2. Changing the game state (buying maximum tokens/bets)
3. Playing with an altered house edge
4. Repaying the flash loan in the same transaction

Collusion in Poker/Multiplayer Games

Coordinated play of multiple accounts against other players. In poker — chip dumping or sharing hole cards.

How to Protect Against Multi-Accounting?

On-Chain Wallet Clustering

import networkx as nx
from collections import defaultdict
from typing import List, Dict, Set

class SybilDetector:
    def __init__(self, provider_url: str):
        self.w3 = Web3(Web3.HTTPProvider(provider_url))

    def get_funding_source(self, address: str, depth: int = 3) -> str:
        """
        Trace the funding chain of a wallet back to the original source.
        If multiple wallets share one funding source, they likely belong to one owner.
        """
        current = address
        for _ in range(depth):
            funding_txs = self._get_first_incoming_tx(current)
            if not funding_txs:
                break
            # First incoming transaction is likely the source
            first_tx = funding_txs[0]
            sender = first_tx['from']
            # Known exchange addresses — not considered as source
            if sender in KNOWN_EXCHANGE_ADDRESSES:
                return sender  # stop at exchange
            current = sender
        return current

    def cluster_by_funding(
        self,
        addresses: List[str]
    ) -> Dict[str, List[str]]:
        """Group addresses by common funding source."""
        funding_map = {}
        for addr in addresses:
            source = self.get_funding_source(addr)
            funding_map[addr] = source

        clusters = defaultdict(list)
        for addr, source in funding_map.items():
            clusters[source].append(addr)

        # Return only clusters with >1 address
        return {k: v for k, v in clusters.items() if len(v) > 1}

    def detect_temporal_correlation(
        self,
        addresses: List[str],
        window_seconds: int = 60
    ) -> List[Set[str]]:
        """
        Addresses that regularly place bets at the same time are likely controlled by one script.
        """
        activity_times = {}
        for addr in addresses:
            bets = self._get_bet_timestamps(addr)
            activity_times[addr] = set(b // window_seconds for b in bets)

        correlated = []
        checked = set()

        for i, addr1 in enumerate(addresses):
            group = {addr1}
            for addr2 in addresses[i+1:]:
                if addr2 in checked:
                    continue
                times1 = activity_times[addr1]
                times2 = activity_times[addr2]
                overlap = len(times1 & times2)
                union = len(times1 | times2)
                jaccard = overlap / union if union > 0 else 0
                if jaccard > 0.7:  # 70% temporal overlap
                    group.add(addr2)
            if len(group) > 1:
                correlated.append(group)
            checked.add(addr1)

        return correlated

Behavioral Fingerprinting

@dataclass
class PlayerProfile:
    address: str
    avg_bet_size: float
    bet_size_variance: float
    preferred_games: List[str]
    session_duration_avg: float  # minutes
    sessions_per_day: float
    withdrawal_to_deposit_ratio: float
    bonus_exploitation_score: float  # 0-1

def compute_bonus_exploitation_score(
    address: str,
    bets: List[Dict],
    deposits: List[Dict],
    withdrawals: List[Dict]
) -> float:
    """
    High score = indicators of bonus hunting:
    - minimal wagering before withdrawal
    - change in behavior patterns after receiving bonus
    - high bet size relative to balance (for fast wagering)
    """
    bonus_received = sum(d['amount'] for d in deposits if d.get('is_bonus'))
    if bonus_received == 0:
        return 0.0

    # Analyze bets AFTER receiving bonus
    bonus_deposit_time = min(d['timestamp'] for d in deposits if d.get('is_bonus'))
    post_bonus_bets = [b for b in bets if b['timestamp'] > bonus_deposit_time]

    if not post_bonus_bets:
        return 0.5  # No data — moderate risk

    total_wagered_post_bonus = sum(b['amount'] for b in post_bonus_bets)
    wagering_ratio = total_wagered_post_bonus / bonus_received

    # Normal wagering requirement = 30-40x
    # If withdrawal after 1-2x wagering — bonus hunting
    if wagering_ratio < 2:
        return 0.95
    elif wagering_ratio < 5:
        return 0.8
    elif wagering_ratio < 15:
        return 0.5
    else:
        return 0.1

Why Chainlink VRF Is the Security Standard for Crypto Casinos?

Replacing block.hash with Chainlink VRF is a basic requirement for any gambling dApp. VRF provides a provably random number that cannot be predicted or influenced after the request. Compared to block.prevrandao, VRF is 1,000 times more reliable — this is not a metaphor but a mathematical fact: the probability of predicting a VRF result is negligible.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@chainlink/contracts/src/v0.8/vrf/VRFConsumerBaseV2Plus.sol";
import "@chainlink/contracts/src/v0.8/vrf/interfaces/IVRFCoordinatorV2Plus.sol";

contract CasinoGame is VRFConsumerBaseV2Plus {
    IVRFCoordinatorV2Plus private immutable coordinator;

    // Chainlink VRF parameters (Ethereum mainnet)
    bytes32 private constant KEY_HASH =
        0x787d74caea10b2b357790d5b5247c2f63d1d91572a9846f780606e4d953677ae;
    uint256 private immutable subscriptionId;
    uint16 private constant REQUEST_CONFIRMATIONS = 3;
    uint32 private constant NUM_WORDS = 1;
    uint32 private constant CALLBACK_GAS_LIMIT = 200000;

    struct BetRequest {
        address player;
        uint256 betAmount;
        uint8 betType;     // bet type (number, color, etc.)
        bool fulfilled;
    }

    mapping(uint256 => BetRequest) public betRequests; // requestId -> BetRequest

    event BetPlaced(uint256 indexed requestId, address indexed player, uint256 amount);
    event BetSettled(uint256 indexed requestId, bool won, uint256 payout);

    constructor(
        address _coordinator,
        uint256 _subscriptionId
    ) VRFConsumerBaseV2Plus(_coordinator) {
        coordinator = IVRFCoordinatorV2Plus(_coordinator);
        subscriptionId = _subscriptionId;
    }

    function placeBet(uint8 betType) external payable returns (uint256 requestId) {
        require(msg.value >= MIN_BET && msg.value <= MAX_BET, "Invalid bet amount");

        // Request random number — result will come in fulfillRandomWords
        requestId = coordinator.requestRandomWords(
            VRFV2PlusClient.RandomWordsRequest({
                keyHash: KEY_HASH,
                subId: subscriptionId,
                requestConfirmations: REQUEST_CONFIRMATIONS,
                callbackGasLimit: CALLBACK_GAS_LIMIT,
                numWords: NUM_WORDS,
                extraArgs: VRFV2PlusClient._argsToBytes(
                    VRFV2PlusClient.ExtraArgsV1({ nativePayment: false })
                )
            })
        );

        betRequests[requestId] = BetRequest({
            player: msg.sender,
            betAmount: msg.value,
            betType: betType,
            fulfilled: false
        });

        emit BetPlaced(requestId, msg.sender, msg.value);
    }

    function fulfillRandomWords(
        uint256 requestId,
        uint256[] calldata randomWords
    ) internal override {
        BetRequest storage bet = betRequests[requestId];
        require(!bet.fulfilled, "Already fulfilled");

        bet.fulfilled = true;

        // Use random number to determine outcome
        uint256 result = randomWords[0] % 37; // roulette 0-36

        bool won = checkWin(bet.betType, result);
        uint256 payout = won ? calculatePayout(bet.betAmount, bet.betType) : 0;

        if (payout > 0) {
            payable(bet.player).transfer(payout);
        }

        emit BetSettled(requestId, won, payout);
    }
}

Important: there is no atomicity between placeBet and fulfillRandomWords. The player does not know the result until the callback executes — this is the correct model.

What Is Real-Time Scoring and How Does It Work?

Real-time scoring assesses the risk of each transaction at the moment of execution. We combine rules (anomalously large bet, new account with high amount, high bonus exploitation score) with an ML model trained on your transaction history. The final score determines the action: allow, monitor, soft-block, or block.

from dataclasses import dataclass
from enum import Enum

class RiskLevel(Enum):
    ALLOW = "allow"
    MONITOR = "monitor"
    SOFT_BLOCK = "soft_block"  # enhanced KYC
    BLOCK = "block"

@dataclass
class TransactionRisk:
    address: str
    risk_level: RiskLevel
    risk_score: float
    triggered_rules: List[str]
    recommended_action: str

class RealTimeAntifraud:
    def __init__(self, model, sybil_detector: SybilDetector):
        self.model = model
        self.sybil_detector = sybil_detector
        self.rule_engine = RuleEngine()

    def assess_transaction(
        self,
        address: str,
        bet_amount: float,
        game_type: str
    ) -> TransactionRisk:
        triggered_rules = []
        base_score = 0.0

        # Rule-based checks (fast, before ML)
        profile = self.get_profile(address)

        # Rule 1: Anomalously large bet
        if bet_amount > profile.avg_bet_size * 10:
            triggered_rules.append("ANOMALOUS_BET_SIZE")
            base_score += 0.3

        # Rule 2: New wallet with large bet
        account_age_days = self.get_account_age(address)
        if account_age_days < 7 and bet_amount > 1000:
            triggered_rules.append("NEW_ACCOUNT_HIGH_VALUE")
            base_score += 0.4

        # Rule 3: High bonus exploitation score
        if profile.bonus_exploitation_score > 0.8:
            triggered_rules.append("BONUS_HUNTING")
            base_score += 0.5

        # ML scoring
        features = self.extract_features(address, bet_amount)
        ml_score = self.model.predict_proba([features])[0][1]

        final_score = min(1.0, base_score + ml_score * 0.5)

        if final_score < 0.3:
            risk_level = RiskLevel.ALLOW
        elif final_score < 0.6:
            risk_level = RiskLevel.MONITOR
        elif final_score < 0.85:
            risk_level = RiskLevel.SOFT_BLOCK
        else:
            risk_level = RiskLevel.BLOCK

        return TransactionRisk(
            address=address,
            risk_level=risk_level,
            risk_score=final_score,
            triggered_rules=triggered_rules,
            recommended_action=self.get_action(risk_level)
        )

AML and Transaction Monitoring

Crypto casinos fall under regulatory requirements in most jurisdictions. Transaction monitoring:

Integration with Chainalysis KYT or Elliptic for automatic checks of addresses against sanction lists and known exploit addresses is mandatory for licensed operators.

On-Chain Pause Mechanism

Upon detecting anomalies, the system must be able to freeze the contract:

// Emergency pause upon detection of anomalous pattern
contract CasinoGuardian {
    address public immutable casino;
    address public immutable securitySystem; // off-chain anti-fraud system

    uint256 public dailyPayoutLimit;
    uint256 public dailyPayoutSoFar;
    uint256 public lastResetDay;

    function emergencyPause() external {
        require(msg.sender == securitySystem, "Not authorized");
        ICasino(casino).pause();
        emit EmergencyPause(block.timestamp, msg.sender);
    }

    function checkDailyLimit(uint256 payoutAmount) external returns (bool) {
        uint256 today = block.timestamp / 1 days;
        if (today > lastResetDay) {
            dailyPayoutSoFar = 0;
            lastResetDay = today;
        }
        dailyPayoutSoFar += payoutAmount;
        if (dailyPayoutSoFar > dailyPayoutLimit) {
            ICasino(casino).pause();
            return false;
        }
        return true;
    }
}

Implementation Results: Metrics

Process of Work

1. Analysis and Audit — Review existing contracts, identify vulnerabilities (reentrancy, random leakage, absence of pause).
2. Architecture Design — Define protection layers: on-chain VRF, off-chain scoring, behavioral analysis.
3. Implementation — Write smart contracts (pause guardian, VRF consumer), backend for ML scoring, monitoring dashboard.
4. Testing — Unit tests in Solidity, integration tests with Tenderly, fuzzing via Echidna.
5. Deployment and Monitoring — Deploy on Polygon/Arbitrum, set up alerts.

What Is Included in the Work

• Audit of existing contracts with a report
• Implementation of secure randomness module (Chainlink VRF V2+)
• Wallet clustering system (on-chain, Python)
• ML model for real-time scoring (trained on your transaction history)
• AML module (integration with Chainalysis KYT if required)
• On-chain pause guardian with custom triggers
• Operational documentation and team training
• Warranty: 3 months of support after deployment

Timeline

Development of a turnkey anti-fraud system takes 2 to 6 weeks depending on complexity. Exact timelines are determined after a free audit of your contracts. Get a consultation: we will analyze your architecture and propose a protection plan.

Typical Mistakes in Anti-Fraud Design

• Using block.prevrandao as a randomness source (predictable)
• Absence of payout limits (payout cap) — flash loan attacks
• Monitoring only deposits without analyzing withdrawals (structuring)
• Insufficient clustering update frequency (recommended every 10 minutes)
• Ignoring temporal correlations between accounts

Contact us for a free audit — we will assess the risks of your crypto casino and propose a solution that cuts losses by 95%. Order development of an anti-fraud system today.

How Do We Find What the Compiler Misses?

When a protocol loses $197M through a flash loan attack on a function that auditors reviewed live — it's not an accident. It's a systemic gap in methodology. Our experience shows: vulnerabilities live in a contract for over a year, while the compiler remains silent. We restructured the audit process to catch such cases before deployment.

What Static Analysis Won't Find?

Slither is the standard first tool. It finds reentrancy, integer overflow (in older Solidity versions), improper use of tx.origin, variable shadowing, uninitialized storage. On a real project, Slither produces dozens of warnings, of which critical ones are 0‑2. The rest is informational noise.

Slither won't find logical vulnerabilities. If withdraw correctly checks balance and correctly updates state, but business logic allows double deduction through two different code paths — Slither stays silent.

Mythril uses symbolic execution: builds a graph of all possible execution paths and searches for reachable states violating properties. Works well on isolated contracts. On a protocol of 20 contracts with cross‑contract calls — path explosion, analysis hangs or returns false positives.

Both tools are mandatory as a first pass. But they don't replace manual analysis.

Fuzzing: Where Echidna and Foundry Find Real Bugs

Echidna is a property‑based fuzzer from Trail of Bits. The idea: formulate contract invariants as Solidity functions (echidna_invariant), Echidna generates random call sequences and tries to break the invariant.

Example invariant for a lending protocol:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna will find a sequence deposit → borrow → liquidate → repay that violates this invariant. You can't build such a case manually — too many combinations.

Foundry fuzzing (forge test --fuzz-runs 100000) is easier to integrate if the team is already on Foundry. Supports stateful fuzzing via invariant tests. In a real project: auditing a vault contract, Foundry fuzzed for 40 minutes and found an edge case where maxWithdraw returned a value larger than actual balance at a specific shares/assets ratio after several donations. Hardhat unit tests missed it — they didn't have that combination of parameters.

Medusa (from Trail of Bits, newer than Echidna) supports corpus‑guided fuzzing and runs faster on large contracts. If the codebase exceeds 5000 lines of Solidity — we look at Medusa.

How Invariants Help Identify Critical Vulnerabilities

Formal verification proves that the contract satisfies specifications for all possible inputs — not for N random ones, but mathematically for all. Tools: Certora Prover, K Framework, Halmos.

Certora works with CVL (Certora Verification Language): write rules and invariants, the Prover translates them into SMT formulas and checks via Z3/CVC5. MakerDAO, Aave, Uniswap use Certora in CI/CD pipeline — every PR is automatically verified.

Limitations: doesn't work with unbounded loops, struggles with hash functions and signature verification. For contracts with simple math (AMM, lending) — excellent. For contracts with arbitrary external calls — difficult to write sufficiently complete specifications.

Formal verification makes sense for contracts that: manage over $50M, are rarely updated, have clearly formalizable invariants. For fast‑iterating products — the cost‑benefit ratio doesn't favor verification.

What Attack Vectors Do Junior Auditors Miss?

Storage collision in proxy pattern. Transparent proxy and UUPS use specific slots for implementation address (EIP‑1967). If an implementation accidentally declares a variable in slot 0 that overlaps with proxy storage — we get silent override. Slither won't catch this if proxy and implementation are in different files.

Read‑only reentrancy. Classic reentrancy guard protects against state changes during recursive calls. But if an external contract reads state via a view function mid‑transaction — guard doesn't help. Years ago, Curve pools became an attack vector precisely through this: an external protocol read get_virtual_price during a reentrancy‑vulnerable state of Curve.

Oracle manipulation via TWAP. Spot price is a standard target for flash loan attack. TWAP is harder to manipulate, but not impossible: on low‑liquidity Uniswap v2 pairs, TWAP can be shifted over several blocks with enough capital. Proper protection: use Chainlink as primary oracle with TWAP as fallback, with deviation threshold check.

Gas griefing on unbounded loop. A function iterates over an array of users. Attacker adds thousands of addresses with zero balances — the function's gas cost rises to the gas limit, making it inaccessible. Protection: pull pattern instead of push, limit array lengths, batch processing with position tracking.

Front‑running on MEV. Transaction is visible in mempool before inclusion in block. MEV bot sees addLiquidity for a significant amount, inserts its own swap before it (sandwich attack). For AMM this is part of the model. For protocols with price functions — require minAmountOut / deadline parameter and its mandatory verification.

Structure of a Full Audit

1. Scope definition and automated analysis (1‑2 days). Fix commit hash, compiler version, list of out‑of‑scope items. Run Slither, Mythril, Aderyn. Triage: separate real critical bugs from false positives. Build contract dependency map.

2. Manual analysis (5‑15 days). Each contract line by line. Special attention: all external and public functions, all transfer/call/delegatecall, all places where state changes before a check or after an external call, all math operations with user inputs. On average, 95% of found vulnerabilities are logical, not technical.

3. Fuzzing and testing (2‑5 days). Echidna or Foundry invariant tests for critical invariants. Fork mainnet tests — verify behavior in real environment with real oracles. For example, in 4 days fuzzing finds on average 3 edge cases not covered by unit tests.

4. Report and mitigation. Report with severity (Critical/High/Medium/Low/Informational), attack vector description, PoC code for Critical/High. Developers fix, auditors perform re‑audit of fixes.

Audit in CI/CD

Common practice for mature protocols: Slither and Aderyn run in GitHub Actions on every PR. Certora Prover — on merge to main. This doesn't replace a full audit before deployment, but catches regressions.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'

Audit Tools Comparison

Deliverables

• Full report in PDF with CVSS scores for each vulnerability
• PoC code for all Critical and High (reproducible in test environment)
• Remediation recommendations with code examples
• Re‑audit after fixes (up to two iterations)
• Brief guide for developers on ongoing operation
• Post‑deployment support for 30 days (consultations and incident analysis)

Timeline

Audit of a simple token or NFT contract — 3‑5 business days. DeFi protocol with lending/AMM — 2‑4 weeks. Full stack with multiple protocols, cross‑chain, proxy upgrades — 4‑8 weeks. Re‑audit of fixes — 3‑7 days separately.

Our team has 7+ years of experience in smart contract security, having audited over 100 projects. We guarantee we won't miss any known attack vectors — we use licensed versions of Slither and best fuzzer configurations. Assess your project — we will analyze your code for free and provide a commercial offer within 2 days. Order an audit with quality guarantee and get a discount on re‑audit for repeat customers.