DEV Community: Сhekers

Why Pure RNG is Broken- Building a "Card Deck" Lottery in Rust

Сhekers — Tue, 05 May 2026 18:15:29 +0000

"Pure RNG promises nothing. A shuffled deck promises everything - eventually."

When designing the reward system for active users at SolChekers, we hit a classic Web3 wall.

Usually, projects just roll a digital dice. You get a 1% chance to hit a jackpot on every action. Mathematically, it’s completely fair. Psychologically, it’s a disaster.

With pure independent probabilities, a dedicated user could perform 500 actions and win absolutely nothing, simply because they hit the bad end of the variance curve. That means frustration, churn, and a flooded support inbox.

We needed a system that offered guarantees. So, we killed the dice and brought in the Card Deck.

The Concept: Decks over Dice

Instead of generating a random number on the fly, we assign each user a personalized virtual "deck" of cards. The deck's composition is based on their activity tier.

If there is one Flush (Jackpot) card in a 10-card deck, pure RNG cannot guarantee you'll roll it in 10 tries. A deck does. You are guaranteed to hit it; the only mystery is when.

Here is how we built this pattern in Rust.

1. The Deck State

Every deck tracks its remaining cards, the user's current session strength (Tier), and a soft-pity counter (bad_streak).

use rand::{Rng, rngs::StdRng, SeedableRng};
use sqlx::Row;

/// A user's personal deck. Each card represents one future outcome.
/// When empty, the deck is reshuffled — guaranteeing the user *will* win,
/// just not when. Pure RNG can't promise that.
#[derive(Debug, Clone)]
struct Deck {
    cards: Vec<Card>,    // remaining cards, FIFO
    cursor: u16,         // position for tamper-proof commit
    tier: Tier,          // current "session strength"
    bad_streak: u8,      // soft-pity counter
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
enum Card { Crumbs, Small, Medium, Good, Flush, Reserve, Buffer }

#[derive(Debug, Clone, Copy)]
enum Tier { Tiny, Small, Medium, Big, Whale }

2. Rebuilding and Drawing

When a deck runs out, we build a new one. If a user has a long bad_streak (too many empty draws), we bump up their Tier to inject better cards into their next shuffle.

impl Deck {
    /// Build a fresh deck with composition shaped by tier and pity.
    /// Higher tier → more "Good"/"Flush" cards. Long bad streak → upgrade tier.
    fn rebuild(tier: Tier, bad_streak: u8, rng: &mut impl Rng) -> Self {
        // The exact mix is the secret sauce — left abstract on purpose.
        let mut cards = compose_deck(tier, bad_streak);
        shuffle(&mut cards, rng);
        Self { cards, cursor: 0, tier, bad_streak: 0 }
    }

    /// Draw the next card. The deck *commits* to its remaining future
    /// the moment it's shuffled — players can't reroll, can't skip.
    fn draw(&mut self) -> Option<Card> {
        let c = self.cards.pop()?;
        self.cursor += 1;
        Some(c)
    }
}

3. The UI Twist: Showing the Future

Because the deck is finite and already shuffled, the system actually "knows" the user's future. This unlocks a killer UI feature: *Expected Value (EV) Remaining.
*
Instead of just showing users what they’ve already won, we can show them the mathematical value currently trapped inside their remaining deck. It’s an incredibly powerful retention hook.

impl Deck {
    /// Expected value of *what's left*. A deck knows its own future.
    fn ev_remaining(&self, pool: u64) -> u64 {
        self.cards.iter().map(|c| card_value(*c, pool)).sum::<u64>()
            / self.cards.len().max(1) as u64
    }
}

Atomic Execution (The Ledger) In Web3, distribution logic has to be bulletproof. The prize pool, the deck state, and the ledger must move together atomically. We use sqlx to lock the rows and ensure idempotency. No race conditions, no double spends.

/// One lottery event — atomic and idempotent.
/// The pool, the deck, the ledger: all move together or not at all.
async fn deal_card(
    db: &sqlx::PgPool,
    user_id: i32,
    activity: u64,
    source_id: &str,
) -> anyhow::Result<Outcome> {
    let mut tx = db.begin().await?;

    // Lock the row to prevent concurrent draws
    let row = sqlx::query(
        "SELECT deck, cursor, tier, bad_streak, pool_balance \
         FROM lottery_state WHERE user_id = $1 FOR UPDATE"
    )
    .bind(user_id)
    .fetch_one(&mut tx)
    .await?;

    let mut deck = decode_deck(&row);
    let pool: u64 = row.get::<i64, _>("pool_balance") as u64;

    // Empty deck = a fresh promise. Tier may shift based on activity.
    if deck.cards.is_empty() {
        let mut rng = StdRng::from_entropy();
        let tier = upgrade_tier(deck.tier, deck.bad_streak, activity);
        deck = Deck::rebuild(tier, deck.bad_streak, &mut rng);
    }

    let card = deck.draw().expect("just rebuilt");
    let prize = card_value(card, pool);

    // Pity accumulates on weak draws — feeds back into tier upgrades.
    deck.bad_streak = if prize == 0 { deck.bad_streak + 1 } else { 0 };

    sqlx::query(
        "UPDATE lottery_state SET deck = $1, cursor = $2, tier = $3, \
         bad_streak = $4, pool_balance = pool_balance - $5 \
         WHERE user_id = $6"
    )
    .bind(encode_deck(&deck))
    .bind(deck.cursor as i32)
    .bind(deck.tier as i32)
    .bind(deck.bad_streak as i32)
    .bind(prize as i64)
    .bind(user_id)
    .execute(&mut tx)
    .await?;

    // Replay-safe ledger: same source_id = same outcome, always.
    sqlx::query(
        "INSERT INTO ledger (user_id, card, amount, source_id) \
         VALUES ($1, $2, $3, $4) ON CONFLICT (source_id) DO NOTHING"
    )
    .bind(user_id)
    .bind(format!("{:?}", card))
    .bind(prize as i64)
    .bind(source_id)
    .execute(&mut tx)
    .await?;

    tx.commit().await?;

    Ok(Outcome { 
        card, 
        prize, 
        ev_remaining: deck.ev_remaining(pool) // Revealing the future to the UI
    })
}

struct Outcome {
    card: Card,
    prize: u64,
    ev_remaining: u64,
}

The Takeaway

The crypto space can feel like a chaotic casino. But by applying strict, pedantic engineering principles-what I call the disciplined degen approach-you can build systems that are reliably fair.

The Card Deck pattern completely eliminates the "infinite loss" problem. Users are no longer fighting variance; they are actively playing out a guaranteed set of rewards, earning better decks through their engagement.

How are you handling fair RNG and user retention in your Web3 stacks? Drop a comment below, or let's argue about the Rust borrow checker.

70,000 Empty Accounts: The Owner Doesn't Know He Left 120 SOL Behind

Сhekers — Fri, 24 Apr 2026 22:42:21 +0000

If you are active in the Solana ecosystem, there is a very high chance you have money sitting completely frozen on the blockchain.

Recently, I was analyzing some on-chain data and stumbled upon a single address holding 70,000 empty Token Accounts. That is roughly 120 SOL (thousands of dollars) just lying dead for months. The owner probably had no idea.

Why does this happen? It all comes down to how Solana handles storage space.

What is locked rent in Solana?
Solana requires a ~0.002 SOL deposit for every token account you open. When you interact with a new token, swap, or receive an airdrop, an Associated Token Account (ATA) is created, and your SOL is locked to pay for its "rent" on the blockchain.

When these accounts become empty after you sell or transfer the tokens, the deposit stays locked. It doesn't automatically return to you. To claim your sol, you must manually close these empty accounts. Active wallets can easily have 0.5 to 5+ SOL locked this way over time.

The Token-2022 Trap
Closing standard SPL tokens is straightforward. But with the introduction of the Token-2022 standard, things got more complicated. You can't just forcefully close them if there are withheld transfer fees or leftover balances.

If you are building a tool to reclaim sol programmatically, you must follow a strict sequence. Here is the correct execution order in Rust to avoid transaction errors:

// 1. First, harvest withheld fees (Crucial for Token-2022)
tf_instruction::harvest_withheld_tokens_to_mint(
    &spl_token_2022::ID,
    mint_pubkey,
    &[token_account_pubkey],
)?;

// 2. Burn remaining junk tokens (if there is a balance)
token2022_instruction::burn(
    &spl_token_2022::ID,
    token_account,
    mint,
    owner,
    &[],
    amount,
)?;

// 3. Close the account and refund your sol
token2022_instruction::close_account(
    &spl_token_2022::ID,
    token_account,
    owner,
    owner,
    &[],
)?;

Key differences from the old SPL standard:

You must invoke spl_token_2022::ID instead of spl_token::id().
The harvest_withheld_tokens_to_mint step is mandatory if you want to cleanly claim sol fees that were trapped by token extensions.
When reading the account data, you need to use StateWithExtensions::<Account>::unpack instead of standard unpacking.

The Easy Way Out

Building these instructions and batching them for hundreds of accounts is a headache. I kept seeing people lose out on free money, so I built a lightweight utility for the community: SolChekers

I wanted to make it as transparent as possible:

Free Scanner: You can go to solchekers.com/scan and just paste up to 10 wallet addresses. No wallet connection required. It will scan the chain and tell you exactly how much locked rent is sitting there, just for your information.
Batch Closing: If you decide to clean up, the dApp allows you to batch-burn useless junk and close empty ATAs to claim sol straight back to your main balance in a few clicks.

It's a small tool, but it does one job very well. (We also maintain a comprehensive Solana Wiki on the site if you want to dive deeper into how Token-2022 and ATAs work under the hood).

Go check your address. You might be richer than you think.

What is the most locked rent you've ever recovered from an old wallet? Drop your high score in the comments! )))

The Sweet Lure of Prediction Arb: How I Tried to Speedrun a Rust Monitor (and Fried My Brain)

Сhekers — Thu, 23 Apr 2026 19:49:19 +0000

It all started with some casual research. I was deep down the prediction market rabbit hole, trying to figure out if there was any real alpha in playing options strategies based on crypto crowd expectations.

Then I spotted it: the discrepancies. You could buy >Yes< on one platform, grab >No< on another, and pocket a risk-free delta. The spreads weren't massive, but they were definitely there.

Just to give you an idea, here is one of the tastiest setups from that time:

Imagine an NBA market like "New York at Chicago Winner?". On Kalshi, you could buy "YES" for an average of 21.0¢, while on Predictfun you could scoop up the opposing "NO" for 22.3¢. You lock in both sides for roughly 43.3¢ total, guaranteeing a $1.00 payout. As you can see in the stats: you drop $47k to secure both sides, and walk away with $109k. That's a massive +129% net yield (+$61k profit) after fees in a single event. A literal free money glitch.

That sweet, sweet arbitrage FOMO hit me hard. My inner degen whispered: "We’re building a real-time monitor. Right now." I teamed up with Claude as my AI co-pilot, delegated the boilerplate, and started slapping together a tracker. After a quick recon, I pulled together 6 platforms: Polymarket, Kalshi, PredictFun, Proba, Limitless, and Opinion.

The tech side was actually pretty elegant. I whipped up a lightweight Rust architecture: REST requests to scrape all active markets, and WebSockets to pump the order books straight to the frontend. Watch the tape, analyze the spread, ape in. Everything worked flawlessly... until I got to the matching engine.

Matching the exact same real-world event across different platforms turned out to be the boss fight that completely fried my brain.

I designed a 4-stage filtering pipeline:

Xref: PredictFun actually provides direct links to Poly/Kalshi. Easy money. 100% accuracy right out of the gate using a BFS traversal on the relationship graph.
Normalized: If the normalized question string matched 1:1 across platforms = match. This gave me about ~95% accuracy.
Fuzzy Jaccard: For the stragglers. I used an inverted index to find pairs with ≥3 shared words, calculated the Jaccard similarity, and slapped on a strict Entity Guard so it wouldn't accidentally merge "France vs Brazil" with completely different events. Finally, I used Union-Find to stitch transitive chains together.
Merge: The final boss-fusing markets that landed in both the Xref and Normalized buckets.

Sounds like a gigabrain setup, right? But I just couldn't hit that holy grail of 98% accuracy. Edge cases and false positives kept creeping in, entirely because platforms phrase their questions so wildly differently. Honestly, my patience just ran out. I was trying to speedrun the build while hyped on FOMO, and I hit a wall.

The takeaway? Regex and Jaccard aren't enough. You need heavy LLM artillery for this. The real solution is classifying every single question against a strict template, deploying an AI agent to audit and read the actual description rules of each market, and aggressively caching the verified matches. No big deal, just processing 2M+ variations! 😅

I originally planned to ship this monitor to the public, but because of those inaccuracies, I tossed it in the drawer. PredictWit is on pause for now, but the idea is still sitting there, waiting for its time.