On-Chain Transaction Analytics & Red-Flag Detection
Event-driven serverless ETL that detects fraudulent and manipulative EVM tokens through a three-stage anomaly-to-ML classification pipeline with confidence scoring.
- Client
- Confidential · Crypto Investment
- Role
- {{TODO: e.g. Solution Architect / ML Platform Engineer}}
- Period
- {{TODO: e.g. 2023–2024}}
Summary
Overview
The platform is a crypto-native investment risk system that monitors tokenized assets on EVM chains and flags tokens that are fraudulent, manipulative, or default-prone. It ingests on-chain volume and metadata, detects anomalies with statistical methods, and produces real-time red-flag alerts with confidence scores for portfolio managers.
The core challenge was turning noisy, high-volume on-chain transaction data into a defensible red-flag signal while keeping compute costs low and inference latency predictable — solved with an event-driven serverless pipeline that stages cheap statistical filters ahead of expensive ML inference.
Context
The Problem
Manipulative and default-prone tokens on EVM chains are hard to spot from raw transaction data: volume spikes, mint/burn events and holder churn are individually noisy and only meaningful in a temporal baseline. Portfolio managers need actionable, scored alerts — not raw metrics — delivered close to real time.
Constraints
- Detect anomalies across 100s–1000s of live tokens on a daily ingestion cadence.
- Keep inference cost low; ML scoring every candidate is prohibitively expensive.
- Predictable inference latency despite serverless cold starts.
- Reproducible feature lineage so models can be back-tested and retrained.
Scope
Requirements
Functional
- ▹Ingest daily and on-demand volume plus metadata for EVM tokens across 12 metrics
- ▹Detect anomalies via statistical methods — rolling mean deviation, Z-score, cumulative sum
- ▹Pre-classify anomalies with rule-based heuristics
- ▹Final red-flag classification via a supervised ML model on a 7-day time-series window
- ▹Persist anomaly and classification results with confidence scores
- ▹Support back-testing via batch scoring and notebook-based model development
Non-functional
- ▹Multi-token watchlists at scale with a daily ingestion cadence
- ▹Event-driven near-real-time alerting — minutes to hours acceptable
- ▹99%+ alert availability with sub-second warm inference via EFS-preloaded packages
- ▹Serverless cost model — pay-per-use Lambda with batch backfill and retraining
- ▹Validation gates before inference — date bounds, data shape and null checks
System Design
Architecture
Event Router
Validates incoming token id, date and category events, enforces date-bound and data-shape gates, and routes to the detection pipeline or a no-op when history is insufficient.
Anomaly Detector
Statistical detection over a 2-year volume baseline using rolling mean deviation, Z-score and cumulative sum, gating candidates by a confidence threshold before any ML cost is incurred.
Three-Stage Classifier
Anomaly detection feeds a rule-based pre-classifier, which feeds the SageMaker red-flag model — cheap filters run first to minimize API and inference calls.
Dual Storage
MongoDB holds indexed anomaly records and an audit trail; S3 holds the reproducible CSV feature store and model artifacts for back-testing and retraining.
Inference Layer
A shared SageMaker endpoint serves the red-flag classifier across all tokens, with EFS-preloaded scikit-learn and scipy wheels keeping warm inference sub-second.
Stack
Technology Stack
Compute
Data / Storage
ML / Analytics
Infra / Ops
Persistence
Data Model
- TokenVolumeAnomalies (MongoDB): token_id, time, volume, score (confidence)
- onchain_data (MongoDB): 7-day time-series — volume, price, holders, minted, burned, txn, DEX trades
- red_flag_classification (MongoDB): is_red_flag flag plus explanation string
- red_flag_pre_classification (MongoDB): rule-based intermediate result
- status (MongoDB): pending then processed; audit trail via created_at and updated_at
- Feature Store (S3 CSV): Id, Date, Symbol, Price, Market Cap, Volume, Supply, Minted, Burned, Holder, Transaction, Active Address, Transfer Count, Transfer Amount — per-token daily append, upsert on date match
Reasoning
Key Decisions & Trade-offs
Serverless Lambda over scheduled jobs
trade-off
Cold-start penalty of ~5–10s on first invoke, but no idle compute and event-driven throughput that scales with load; EFS preload mitigates the cold start.
Three-stage classification pipeline
trade-off
Sequential stages add latency, but cheap statistical and rule-based filters run before ML, cutting API calls and SageMaker cost.
MongoDB plus S3 dual storage
trade-off
Eventual consistency between systems, but MongoDB gives indexed queries and an audit trail while S3 gives a reproducible feature store for retraining.
2-year lookback window for baselines
trade-off
Higher API load per detection, but statistically valid anomaly baselines; could stratify by token age so younger tokens use a shorter baseline.
No streaming framework — batch plus event-driven hybrid
trade-off
No Kafka/Kinesis backbone, but simpler operations with batch backfill handled by Python scripts.
Operations
Scaling & Reliability
Horizontal: Lambda auto-scales per concurrent event; MongoDB replicas absorb read load and the shared SageMaker endpoint serves all tokens.
Cost: cheap statistical and rule-based filters gate ML inference; batch mode handles backfill to avoid per-item Lambda invocation; a single SageMaker endpoint is amortized across the token universe.
Resilience: Sentry and loguru provide observability and Lambda tracing; EFS mounts share the dependency layer so there is no per-invocation pip install; validation gates fall back to "no anomaly" when history is insufficient.
What made this hard
Architect's Challenges
- →Sub-second inference despite serverless cold starts — EFS preloads scikit-learn and scipy wheels instead of a 10–30s pip install
- →Training/production feature alignment via a fixed 7-day window and StandardScaler preprocessing
- →Managing API dependency risk from an HTTP-based TokenApi that is fragile to backend schema changes
- →Cost optimization through batch backfill and a shared SageMaker endpoint
Results
Outcome
- ▹Anomaly-detection precision/recall and red-flag classifier AUC/F1 on a holdout token set
- ▹Operational targets: Lambda cost per anomaly event, p99 latency, MongoDB query latency under 100ms
- ▹{{TODO: add real metrics — false positive rate, alert actionability, default correlation}}