Security

Understanding Kelly4X's security architecture and provably fair gaming system.

🛡️ Security Strengths

Kelly4X implements multiple layers of security that make it one of the most trustless decentralized casinos:

TEE-Based Randomness

Trusted Execution Environment (TEE)

Kelly4X uses Trusted Execution Environments for hardware-enforced fairness. The randomness generation runs inside a TEE enclave that:

• Isolates Execution: TEE code runs in hardware-protected memory, isolated from the host OS
• Generates Attestation: Cryptographic proof of what code is running and its integrity
• Signs Outputs: All random outputs are signed by the TEE's private key
• Sequential Nonces: Enforces strict ordering to prevent selective execution attacks

Supported TEE Platforms

Kelly4X supports multiple TEE technologies:

• Intel SGX: Software Guard Extensions with MRENCLAVE measurement
• AMD SEV-SNP: Secure Encrypted Virtualization with attestation reports
• Intel TDX: Trust Domain Extensions for VM-level isolation
• Enarx: Cross-platform TEE abstraction layer

How TEE Randomness Works

1. TEE Initialization: Enclave generates a master seed and ECDSA signing key, sealed to hardware
2. Registration: TEE provides attestation report proving code integrity and public key ownership
3. Bet Placement: Player places bet with nonce range (minNonce, maxNonce)
4. Random Generation: TEE generates: random = H(master_seed || chain_id || app_id || nonce || block_hash || user_pubkey)
5. Signature: TEE signs the random output with its private key
6. On-Chain Verification: Contract verifies signature matches registered TEE public key

// Inside TEE Enclave (Rust pseudo-code)
fn generate_random(
    master_seed: &[u8; 32],
    chain_id: u64,
    app_id: u64,
    nonce: u64,
    block_hash: &[u8; 32],
    user_pubkey: &[u8; 33]
) -> (u256, Signature) {
    // Deterministic random generation
    let random = keccak256(&[
        master_seed,
        &chain_id.to_be_bytes(),
        &app_id.to_be_bytes(),
        &nonce.to_be_bytes(),
        block_hash,
        user_pubkey
    ]);

    // Sign with TEE's private key
    let signature = ecdsa_sign(tee_private_key, random);

    (random, signature)
}

Sequential Nonce Enforcement

The protocol prevents selective execution attacks through:

• Global nonce counter that must increment sequentially
• Players specify nonce range (minNonce, maxNonce) when betting
• TEE only accepts the exact next nonce in sequence
• No nonce skipping allowed - forces settlement of all bets in order

Smart Contract Security

Security Features

The KellyBetting contract implements multiple security measures:

• Reentrancy Guards: OpenZeppelin ReentrancyGuard on all external functions
• Pull Payments: Users receive winnings directly via transfer (no withdrawal pattern)
• 2-Step Settlement: Commit-reveal pattern prevents MEV exploitation
• Signature Replay Protection: Used signatures are tracked and rejected
• Role-Based Access: Separate owner and TEE operator roles
• Emergency Pause: Owner can pause contract in case of critical issues
• Per-Game Pause: Individual games can be paused without affecting others
• UUPS Upgradeability: Owner-controlled upgrades for bug fixes (double-edged sword)
• Fee-on-Transfer Blocking: Contract rejects tokens with transfer fees

Commit-Reveal Settlement

To prevent MEV attacks, bet settlement uses a 2-step process:

1. Commit: TEE operator commits H(betId, randomValue, nonce, signature)
2. Wait: At least 1 block must pass (prevents same-block manipulation)
3. Reveal: TEE operator reveals random value and signature for verification

Known Design Considerations

Be aware of these architectural decisions:

• Centralized TEE Operator: Single operator can settle bets (but cannot cheat due to sequential nonces)
• UUPS Upgradeability: Owner can upgrade contract logic (enables fixes but introduces trust)
• No On-Chain Attestation Verification: Full TEE attestation verification done off-chain by users
• 24-Hour Bet Expiry: Players can cancel and withdraw if not settled within 24 hours

TEE Attestation Verification

On-Chain Verification

The contract performs basic attestation checks:

• Extracts MRENCLAVE (SGX) or measurement (SEV-SNP) from attestation
• Compares against expected measurement set by owner
• Verifies report data contains hash of proposed public key
• Checks attestation freshness (not older than 1 hour)

Off-Chain Verification

Full attestation verification should be done off-chain by users:

• SGX: Verify quote signature against Intel Attestation Service (IAS) or DCAP
• SEV-SNP: Verify signature chain: VCEK → ASK → ARK (AMD Root Key)
• Code Integrity: Verify MRENCLAVE/measurement matches known good build
• Reproducible Builds: Users can rebuild TEE binary and compare measurement

User-Requested Attestation

Players can pay an optional attestation fee to have the full TEE attestation report included with their bet settlement, enabling:

• Independent verification of TEE integrity
• Proof that settlement used legitimate TEE
• Evidence for dispute resolution

Kelly Criterion Safety

Risk Management

The protocol uses the Kelly Criterion to manage risk:

• Kelly Fraction: f = edge / (payout - 1)
• Pool Risk: Each pool risks balance × kelly_fraction × multiplier
• Cascading Pools: Large bets automatically spread across multiple risk tiers
• Max Bet Enforcement: Contract rejects bets exceeding available capacity

Progressive Jackpots

Progressive jackpots include additional safety measures:

• Hard Cap: Jackpot cannot exceed configured maximum
• Seed Funding: Jackpot always maintains minimum reserve
• Separate Determination: Jackpot trigger uses upper 128 bits of random value

Wallet Security

Best Practices

• Never share your private keys or seed phrase
• Use hardware wallets (Ledger, Trezor) for large holdings
• Always verify transaction details before signing
• Check contract addresses carefully (avoid phishing sites)
• Start with small bets to test the system

Smart Contract Interactions

• Verify you're interacting with the official KellyBetting contract
• Check token approvals - only approve what you intend to bet
• Understand gas costs - include betFeeWei + optional attestationFeeWei
• Monitor your pending bets - cancel if not settled within 24 hours

Common Risks

Smart Contract Risks

• Unaudited Code: Contracts have not undergone professional security audit
• Upgrade Risk: Owner can upgrade contract logic (could introduce bugs)
• Oracle Risk: System relies on TEE operator for randomness and settlement
• Economic Risk: LP providers can lose funds if many players win

TEE Risks

• Hardware Vulnerabilities: TEE platforms may have undiscovered security flaws
• Side-Channel Attacks: Spectre/Meltdown-style attacks on some TEE platforms
• Attestation Complexity: Full verification requires understanding of TEE internals

Reporting Security Issues

If you discover a vulnerability:

1. Do NOT exploit the vulnerability
2. Do NOT publicly disclose before it's fixed
3. Contact the team via official channels
4. Provide detailed information and proof-of-concept if possible