Memory Intelligence (mem0 Pro)
How GASCOIN uses mem0 Pro as a cross-pipeline memory bus so every worker shares intelligence without being coupled to every other worker.
The short version GASCOIN runs five or six independent workers — the submission pipeline, Claude oversight, the referral verification worker, the engagement worker, the intelligence aggregator, the payout worker.
Technical readers and anyone doing due diligence
10 min
Understand the AI and fraud prevention behind GASCOIN
The short version
GASCOIN runs five or six independent workers — the submission pipeline, Claude oversight, the referral verification worker, the engagement worker, the intelligence aggregator, the payout worker. Each one sees a slice of what a wallet is doing. None of them, on their own, can catch a wallet that looks clean in one slice and suspicious in another.
mem0 is the memory bus that stitches those slices together. Every worker writes distilled signals about a wallet into mem0. Every worker reads the synthesized profile back. A referral ring detected by the referral worker ends up in front of the payout worker. A verdict by Claude oversight ends up in front of the next Claude review for the same wallet. Nothing is coupled directly; everything communicates through memories.
GASCOIN runs mem0 Pro. Every Pro-tier feature is engaged — dedicated project, graph memory, custom categories, custom fact-extraction instructions, agent/app/run scoping, immutable records, time-to-live decay, reranking, and real-time webhooks.
What is mem0?
mem0 is a managed memory layer for AI agents. You write facts into it, you search it back later. Under the hood it runs an LLM-powered extraction pipeline that:
- Reads what you sent it (a string, a JSON event, a chat message)
- Extracts durable facts per your custom instructions (what to keep, what to drop)
- Tags each fact into a category you configured (fraud signals, verdicts, ring flags, etc.)
- Stores the fact in a vector database + a graph database for retrieval
- On your next query, it semantically searches the relevant memories and returns them
The interesting part is the transformation on write. You don't just dump raw data in — mem0 applies your extraction rules and stores the distilled form. GASCOIN tested this live: a raw input like "approve | tier=Commuter | claims=3 | risk=low | receipt authentic, gate signals consistent, trust trajectory stable" gets stored as "Claim approved, low risk, Commuter tier, strongest signal: receipt authentic." That's the custom fact-extraction instructions doing their job automatically.
The dedicated project
GASCOIN production memories live in a dedicated mem0 project called gascoin-production, completely separate from any personal or dev memories. That means:
- Protocol runtime memories never mix with development memories from other projects
- The project has its own API key that can be rotated independently
- Budget, quota, and analytics are tracked at the project level
- You can delete or export the entire GASCOIN memory set without affecting anything else
Graph memory — why it matters
Most memory systems store facts as a flat list. mem0 Pro stores them as a graph — every memory is a node, and mem0's extraction pipeline identifies entity relationships and builds edges between them.
For GASCOIN, this matters when fraud investigations require multi-hop reasoning. Questions like "which wallets share referral connections with the ring that hit claim X last week?" become a graph traversal instead of a linear scan through every memory. As the protocol grows and the fraud patterns get more sophisticated, the graph structure is what keeps retrieval fast and informative.
Graph memory is always on for GASCOIN — every write engages it automatically.
The 13 GASCOIN memory categories
Default mem0 categories (personal_details, food, travel, etc.) are useless for a fraud detection pipeline. GASCOIN replaced them with a protocol-specific taxonomy of 13 categories, each one representing a distinct class of signal the AI layers care about:
┌──────────────────────────────────────────────────────────────────┐ │ GASCOIN MEMORY CATEGORIES │ ├──────────────────────────────────────────────────────────────────┤ │ wallet_trust_trajectory · whether a wallet's trust is │ │ improving / stable / declining / new │ │ │ │ claim_verdict · Claude's distilled verdicts on past │ │ claims, compressed for fast re-use │ │ │ │ fraud_signals · detected fraud indicators with │ │ severity and source agent │ │ │ │ referral_ring_flag · BFS-detected ring cycles │ │ (highest retrieval priority) │ │ │ │ tier_change · when a wallet crosses a GASCOIN tier │ │ boundary (Standard → Commuter → RW) │ │ │ │ engagement_pattern · tweet quality signals, bot detection,│ │ spam flags, content-type anomalies │ │ │ │ payout_event · on-chain SOL dispatch events │ │ (immutable history) │ │ │ │ account_quality · X account quality signals │ │ │ │ geo_signal · IP / OCR / EXIF country consistency │ │ │ │ cooldown_window · per-wallet submission cooldown state │ │ │ │ ban_state · auto-ban or manual admin ban events │ │ │ │ pipeline_anomaly · unusual behaviors worth admin review │ │ │ │ misc · durable signals that don't fit above │ └──────────────────────────────────────────────────────────────────┘
Every write lands in one of these buckets. The category drives how mem0 extracts facts, how it surfaces them in retrieval, and how the webhook receiver classifies alerts.
Typed helpers — not raw writes
Pipeline code doesn't call mem0 directly. It calls typed helpers like writeFraudSignal, writeReferralRingFlag, writePayoutEvent, writeDistilledProfile, and writeBanState. Each helper knows:
- Which category to tag
- Which AI agent authored the memory (Gemini Vision, Grok Fraud, Claude Oversight, Referral Worker, Payout Worker)
- Which app / pipeline produced it (submit / workers / payout / admin)
- What run ID to assign for forensic grouping (e.g.
claim_abc123_review) - Whether the memory is immutable (permanent record) or can be updated
- What TTL applies (decaying signals vs permanent truth)
This means every memory in GASCOIN is richly scoped by default. You can query "show me every memory Claude-oversight wrote via gascoin-workers for wallet X in the last 7 days" as a direct filter — no post-processing required.
Immutability — permanent ground truth
Some GASCOIN events should never be rewritten once they happen. Ring flags are fraud evidence. Payout transactions are on-chain truth. Ban records are audit history. Claude verdicts are the audit log of why a claim was approved, flagged, or rejected.
All four of these helpers mark their writes immutable: true. mem0 refuses to overwrite or delete them — even the extraction pipeline can't merge them into something else. They are permanent, append-only, and guaranteed to exist for any future investigation.
If a wallet is unbanned later, that's a new memory (writeBanState with state="unbanned") rather than removal of the old one. The audit trail is preserved.
Time-to-live — old signals decay automatically
Not every signal should live forever. A single elevated aiScore from 6 months ago shouldn't dominate a wallet's profile today if the wallet has been clean since. GASCOIN sets fraud_signals to expire after 90 days — recent fraud signals surface strongly within the window, then mem0 auto-expires them. Retrieval naturally weights recent activity more than ancient activity.
Ring flags, payouts, ban state, and claim verdicts never decay — those are permanent records.
Reranking — Pro-tier retrieval quality
Standard vector search returns the top-K memories by semantic similarity. mem0 Pro adds an optional reranking pass that runs a second deep-semantic-understanding model over the top results and reorders them by true relevance. It costs ~150–200ms but significantly improves the quality of what Claude oversight sees.
GASCOIN uses reranking as an opt-in flag for latency-tolerant reads (Claude oversight runs on the async worker side, so the extra 150ms doesn't matter). Hot-path reads on the submission side stay fast.
Real-time admin alerts via webhooks
mem0 Pro supports webhooks that fire the moment a memory is added or categorized. GASCOIN has a webhook registered on the gascoin-production project that subscribes to two events:
memory_add— fires whenever a new memory is createdmemory_categorize— fires when mem0 tags a memory into a category
The webhook points at a protected endpoint in the GASCOIN platform. When mem0 posts an event, the receiver:
- Validates the bearer token against a shared secret (fail-closed if missing)
- Writes the full event to the immutable
audit_logstable for forensic review - If the event is high-severity — explicitly tagged high/critical, or in a category that's always critical like
referral_ring_flagorban_state— it also writes to the admin dashboard feed
This means: the moment the referral worker writes a ring flag, within ~1 second the webhook fires, the receiver classifies it as critical (category rule), and an admin looking at the dashboard sees the alert without polling anything. Real-time cross-pipeline visibility without any custom event-bus infrastructure.
How the cross-pipeline bus actually works
┌─────────────────────────────────────────────────────────────────┐ │ mem0 CROSS-PIPELINE MEMORY BUS │ │ │ │ ┌─ Submit pipeline ────────────────────────────────────┐ │ │ │ writes: fraud_signals (high-severity only) │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ │ ┌─ Claude oversight ────┴────────────────────────────┐ │ │ │ reads: getEntityProfile(wallet) — trust │ │ │ │ trajectory, past verdicts, fraud signals, │ │ │ │ ring flags, patterns │ │ │ │ writes: writeDistilledProfile (claim_verdict, │ │ │ │ immutable, agent=claude-oversight) │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ ┌─ Referral worker ─────────────────────────────────┐ │ │ │ writes: writeReferralRingFlag (referral_ring_flag,│ │ │ │ immutable, severity=critical) │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ ┌─ Engagement worker ──────────────────────────────┐ │ │ │ writes: engagement_pattern, tweet quality │ │ │ └───────────────────────────────────────────────────┘ │ │ │ │ ┌─ Payout worker ───────────────────────────────────┐ │ │ │ reads: getCachedFlags (Upstash hot-path) + │ │ │ │ getEntityProfile (mem0) before dispatch │ │ │ │ writes: writePayoutEvent (payout_event, │ │ │ │ immutable, run_id=claim_X_payout) │ │ │ └────────────────────────────────────────────────────┘ │ │ │ │ ┌─ Webhooks → admin dashboard ─────────────────────┐ │ │ │ memory_add + memory_categorize → POST receiver │ │ │ │ critical events → admin alerts feed in real time │ │ │ └────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘
The critical property: a referral ring detected after Claude already approved a claim still blocks the payout. That's because the referral worker writes a ring flag to mem0, the payout worker reads mem0 right before dispatching SOL, sees the flag, and refuses to send. No direct coupling between the two workers — the mem0 bus is the entire interface.
What this means in plain terms
- Cross-pipeline intelligence without coupling. Every worker learns from every other worker's signals without importing each other's code.
- Fraud history follows a wallet forever. Ring flags and ban records are immutable — even a new team member investigating a wallet months later sees the full fraud trail.
- Recent signals dominate, old ones decay. Fraud signals expire after 90 days so clean behavior can rehabilitate a wallet's profile naturally.
- Real-time admin visibility. Critical events hit the admin dashboard within a second of being detected — no polling, no custom event bus.
- Forensic queries are trivial. Every memory is scoped by agent, app, and run ID. Audit questions that would normally require log spelunking become one mem0 query.
- Graph structure scales. Multi-hop fraud reasoning (which wallets share connections with a known ring) stays fast as the protocol grows.
- Zero single point of failure. Every mem0 call is fire-and-forget — a mem0 outage never blocks a pipeline. The payout worker falls back to deterministic gate state if mem0 is unavailable.
Safety posture
mem0 is never on the submission hot path. Hot-path reads go through a 15-minute Upstash Redis cache (mem0:profile:{wallet}) with single-flight coalescing — the first read hydrates the cache from mem0, every subsequent read for 15 minutes is served from Redis. A mem0 outage just means the cache doesn't refresh, and the pipeline continues with stale-but-safe data until mem0 comes back.
On the write side, every helper is fire-and-forget safe. If mem0 errors out, the write is dropped but the pipeline keeps running. The next successful write for the same wallet restores synchronization.
mem0 custom exclusion rules make sure the memory system never stores PII beyond a country code, never stores secrets of any kind, and drops the entire memory if it detects a secret in the input. Privacy-first by construction.
What is live right now
- Dedicated mem0 Pro project (
gascoin-production) separate from personal dev memories - Graph memory enabled on every write
- 13 custom categories configured at the project level
- Custom fact-extraction instructions (~2,000 chars) tuned to GASCOIN pipeline events
- Custom update instructions controlling how memories merge on conflict
- Inclusion and exclusion prompts set at the project level
- Agent / app / run scoping on every write via typed helpers
- Immutable records for ring flags, payouts, verdicts, and bans
- 90-day TTL on fraud signals
- Reranking available as an opt-in flag on searches
- Webhook receiver live at a protected endpoint, writing to immutable audit logs and the admin alerts feed
- Upstash hot-path cache protecting submission latency from mem0 outages
- Fire-and-forget safety on every mem0 call — a mem0 outage never blocks the pipeline
mem0 is not a log. It is not a database. It is an intelligence system that grows richer with every claim, every verdict, every fraud signal, and every payout. As GASCOIN runs, the cross-pipeline knowledge compounds — and every new review benefits from everything the protocol has seen before.