How I Built a Sub-15ms Discord Username Sniper with Raw Sockets

rrobio — Sat, 11 Jul 2026 22:30:51 +0000

How I Built a Sub-15ms Discord Username Sniper with Raw Sockets

If you've ever tried to grab a rare Discord username, you know the pain. The official Discord client is slow. The API has rate limits. By the time you click "Claim," someone else already has it.

So I built blosm — a Discord username sniping platform that claims usernames in under 15ms using raw socket architecture. It now handles 1,200+ active users with a 99.9% success rate.

Here's the technical breakdown.

The Problem

Discord's public API is designed for general-purpose use, not speed. When a username drops, hundreds of people are trying to grab it simultaneously. The official client adds overhead through:

HTTP connection overhead
JSON serialization/deserialization
Rate limit handling (Discord aggressively throttles)
TLS handshake latency on every request

By the time a normal request completes, a sniping tool running raw sockets has already claimed the name.

The Architecture

Raw Socket Layer

The core of blosm bypasses Discord's HTTP API entirely. Instead, it communicates directly through WebSocket connections at the socket level.

Traditional approach:
Client → HTTPS Request → Discord API → Response (50-200ms)

blosm approach:
Raw Socket → WebSocket Frame → Discord Gateway → Response (<15ms)

This eliminates:

HTTP connection setup overhead
Repeated TLS handshakes (connection is persistent)
JSON parsing on the hot path
Rate limit buckets (gateway-level operations have different limits)

C++ Socket Engine

The claim engine is written in C++ for maximum performance. The key decisions:

Custom SSL fingerprinting — mimics legitimate Discord client behavior
Non-blocking I/O — handles thousands of concurrent connections on a single thread
Memory-mapped username queues — zero-copy operations for claim processing
Lock-free data structures — no mutex contention under high load

// Simplified claim flow
void claim_username(const std::string& username, const Token& token) {
    // Build Discord gateway payload directly (no JSON library)
    auto payload = build_gateway_payload(OPCODE_MESSAGE_CREATE, {
        {"content", "/name " + username}
    });

    // Send raw bytes over persistent WebSocket
    socket.send(payload.data(), payload.size());

    // Response handled by event loop — no blocking
}

Anti-Detection System

Discord actively fights automation. blosm uses multiple layers to avoid detection:

SSL Fingerprint Rotation — rotates JA3 fingerprints to look like different clients
User-Agent Pool — 200+ realistic Discord client user agents
Proxy Distribution — requests spread across 4,200+ residential and datacenter proxies
Behavioral Timing — adds human-like jitter to claim patterns
Token Health Monitoring — automatically rotates compromised tokens

The Proxy Network

Proxies are critical for username sniping. Each claim attempt needs to come from a different IP to avoid rate limiting.

blosm maintains a global pool of:

Residential proxies — for highest success rate
Datacenter proxies — for speed when rate limits aren't a concern
ISP proxies — middle ground, good balance of speed and reliability

The proxy manager health-checks every proxy every 30 seconds and removes dead ones automatically. During peak hours, it handles 50,000+ connection attempts.

Auto-Snipe Engine

The auto-snipe engine monitors username availability in real-time:

Regex Pattern Matching — users define patterns like ^[a-z]{3}$ for 3-letter names
Availability Checking — constant polling of Discord's name resolution endpoint
Priority Queue — claims are prioritized by user plan (Elite > Standard)
Instant Claim — when availability is detected, claim fires in <15ms

Username detected available
  → Priority queue lookup (0.1ms)
  → Token selection (0.2ms)
  → Proxy selection (0.1ms)
  → Raw socket claim (10-15ms)
  → Webhook notification (async)
  Total: ~15ms end-to-end

Scaling to 1,200+ Users

The Hard Parts

Concurrency: Each user can have 10+ patterns running simultaneously. That's 12,000+ active monitors.

Rate Limits: Discord's gateway has connection rate limits. blosm multiplexes multiple users over shared connections using Discord's session management.

Token Management: Each claim requires a valid, unthrottized token. The system manages a pool of tokens per user and automatically rotates when one gets rate-limited.

What Actually Broke (So Far)

Week 2: Socket connection pool leaked under heavy load. Fixed with aggressive connection timeout and cleanup.
Month 1: Discord changed their gateway protocol slightly. Had to update the payload parser within 2 hours.
Month 2: A user ran 500 regex patterns simultaneously, DoS'd the claim queue. Added per-user concurrency limits.

Tech Stack

Component	Technology
Claim Engine	C++ (custom socket library)
Backend API	Node.js + Express
Dashboard	Next.js + Tailwind
Database	PostgreSQL + Redis
Monitoring	Custom metrics pipeline
Infrastructure	Docker on bare metal

Results

After 6 months of building and iterating:

8-15ms average claim latency
99.9% uptime
1,200+ active users
4,200+ proxies in the pool
Sub-second time from detection to claim

What's Next

AI-powered username prediction (predicting which names will become available)
Multi-platform support (Roblox, Twitch, etc.)
Public API for developers
Browser extension for real-time availability checking

If you're interested in the project, check it out at blosm.lol. I also have a Discord community where we discuss the technical challenges of building at this scale: Join the Discord.

Happy to answer questions about the architecture in the comments.

Built with curiosity, caffeine, and way too many Discord API documentation tabs open.

DEV Community: rrobio

How I Built a Sub-15ms Discord Username Sniper with Raw Sockets

How I Built a Sub-15ms Discord Username Sniper with Raw Sockets

The Problem

The Architecture

Raw Socket Layer

C++ Socket Engine

Anti-Detection System

The Proxy Network

Auto-Snipe Engine

Scaling to 1,200+ Users

The Hard Parts

What Actually Broke (So Far)

Tech Stack

Results

What's Next