Technology Overview
The full GASCOIN verification + AI cost-defense stack on one page.
What this is The real, end-to-end GASCOIN verification pipeline.
Technical readers and anyone doing due diligence
5 min
Understand the AI and fraud prevention behind GASCOIN
What this is
The real, end-to-end GASCOIN verification pipeline. Arrows always point in the direction data moves. The three AI providers are not peers — they form a pipeline where Gemini Vision runs first on the receipt image, Grok runs second (conditionally, on elevated risk signals) to reason across Gemini's output, and Claude runs last as the final reviewer of everything before a single lamport of SOL leaves the treasury.
┌──────────────────────────────────────────────────────────────────────────┐ │ GASCOIN VERIFICATION PIPELINE │ │ │ │ USER SUBMIT │ │ │ │ │ ├──► X API v2 (verifyTweet, followers, account quality) ──┐ │ │ │ │ │ │ ├──► Solana RPC (tier holdings) ─────────────────────────┐│ │ │ │ ││ │ │ └──► GEMINI VISION (receipt OCR, EXIF, tamper, AI signal)││ │ │ │ ▼▼ │ │ ▼ ┌────────────────────┐ │ │ fraud.ts::runFraudChecks ────────►│ POLICY GATES │ │ │ │ (elevated risk?) │ (13 sequential) │ │ │ ▼ │ │ │ │ GROK REASONING │ ai_image · tamper │ │ │ (cross-signal fraud)────────────────► x_verified · etc │ │ │ └─────────┬──────────┘ │ │ │ │ │ ▼ │ │ DB + audit log + mem0 │ │ │ │ │ (async — cron worker boundary) │ │ │ │ │ ┌─────────────────────┴──────────┐ │ │ ▼ │ │ │ ┌──────────────────────────┐ │ │ │ Knowledge Base ────►│ CLAUDE OVERSIGHT │◄── mem0 profile │ │ │ (gate rules, │ (FINAL reviewer of │ (wallet trust │ │ │ fraud patterns) │ Gemini + Grok + gates │ trajectory, │ │ │ │ + KB + entity intel) │ distilled │ │ │ │ │ summary) │ │ │ │ verdict: approve/flag │ │ │ │ │ /reject │───► mem0 write │ │ │ └──────────┬───────────────┘ (distilled │ │ │ │ profile) │ │ │ ▼ │ │ │ ┌──────────────────────────┐ │ │ │ │ PAYOUT WORKER │ │ │ │ │ · re-verify X API │ │ │ │ │ · check mem0 ring flags │ │ │ │ │ · sendSolPayout (Helius)│ │ │ │ └──────────┬───────────────┘ │ │ │ │ │ │ │ ▼ │ │ │ ON-CHAIN SOL │ │ │ + payout row │ │ │ + audit log │ │ │ │ │ ├─────────────────────────────────────────────────────────────────────┼────┤ │ mem0 CROSS-PIPELINE BUS (horizontal hub) │ │ │ │ │ │ ┌─ Submit pipeline ──────► addMemory after each claim ─────┐ │ │ │ ├─ Claude oversight ─────► writeDistilledProfile ─────────┐│ │ │ │ ├─ Referral worker ──────► ring flags (BFS detect) ──────┐││ │ │ │ └─ Engagement worker ────► tweet quality + points ──────┐│││ │ │ │ ▼▼▼▼ │ │ │ (read by Claude + Payout Worker) ───────┘ │ │ │ ├──────────────────────────────────────────────────────────────────────────┤ │ UNIFIED AI ROUTING — Vercel AI Gateway │ │ OIDC auth · failover · per-call tags · hard budget cap · audit log │ ├──────────────────────────────────────────────────────────────────────────┤ │ FOUR-LAYER CACHE DEFENSE │ │ L1 Provider-native prompt caching (90% Claude · 75% Gemini · │ │ 50-75% Grok — cached rulebook) │ │ L2 Upstash Redis + single-flight coalescing │ │ (SHA-256 receipt dedup · claim verdict dedup · tweet quality) │ │ L3 Vercel Data Cache (unstable_cache + revalidateTag) │ │ (KB context, leaderboard, mem0 profiles) │ │ L4 Vercel Edge Config (sub-ms live-editable prompt prefixes) │ ├──────────────────────────────────────────────────────────────────────────┤ │ FLUID COMPUTE · OIDC AUTH · 258 UNIT TESTS · VERIFIED COMMITS │ └──────────────────────────────────────────────────────────────────────────┘
How to read the diagram
- Top block (the real flow). A user submission fans out in parallel to the cheap signals (X API v2, Solana RPC) and the expensive signal (Gemini Vision receipt extraction). The fraud module conditionally escalates to Grok. The 13-gate policy engine consumes everything, persists the decision, and returns the user their response.
- The async boundary. Claude does not run inside the submit request. Auto-approved claims are picked up by a cron worker, which is where Claude acts as the final reviewer — with the Gemini output, the Grok verdict (if it ran), the gate results, the mem0 entity profile, and the knowledge base rulebook all in front of it. No SOL moves until Claude has signed off.
- The payout worker does a second verification pass. It re-hits the X API to confirm the tweet is still live and re-reads mem0 for referral-ring flags before calling
sendSolPayout. This is why a referral ring detected after a claim was approved still blocks the payout. - mem0 is a horizontal bus, not a sidebar. The submit pipeline, Claude oversight, the referral worker, and the engagement worker all write to it. Claude and the payout worker read from it. Nothing is floating — every block has arrows into and out of the rest of the system.
- Bottom three rows are horizontal support layers. The AI Gateway routes every model call; the four-layer cache defense sits underneath; Fluid Compute with elastic concurrency is the runtime that makes the in-memory single-flight coalescing actually work.
Core components
- Signal ingestion (wallet, X, receipt payloads)
- Receipt intelligence (Gemini OCR + tamper scoring + duplicate checks)
- Deterministic gate/policy engine (13 gates)
- Cross-signal fraud reasoning via Grok
- Final oversight review via Claude with cached rulebook context
- Persistent memory layer (mem0) with distilled profile compression
- Institutional knowledge base for dynamic policy context
- Four-layer AI cache defense — see AI Engine Architecture & Cost Defense
- Queue/retry orchestration for treasury constraints
- Immutable audit and reviewer observability
Why this matters
The stack combines model-assisted scoring with deterministic policy enforcement to reduce abuse without losing traceability. The cache defense layer makes the AI spend predictable and bounded, so the protocol can scale user volume without scaling AI risk. Three independent AI providers, one unified gateway, and four independent cache layers ensure no single failure mode — outage, rate limit, price move, or thundering herd — can take the pipeline down or blow out the budget.
Operator note
For implementation depth on the AI cost defense, see AI Engine Architecture & Cost Defense. For the end-to-end flow map see End-to-End Architecture Map. For gate-level rules see Verification Gates Reference.