Coinbase Blog
Featured
Most recent
Consumer Protection Tuesday: Following the money. Stopping the scammers.
Singapore Sees 43% Drop in Crypto Scam Losses and Partnerships Like Ours Are Helping Drive the Change
TL;DR: Singapore’s crypto scam losses fell 43% year over year, from S$114.9 million to S$65.5 million, as a result of stronger enforcement, public education, and partnerships between the Anti-Scam Centre and industry leaders like Coinbase. Through four joint operations, Coinbase’s Global Intelligence team helped identify 720+ victims and prevent more than S$18.9 million in potential losses, while a new anti-scam awareness campaign reached Singapore retail customers.
Discover more
Read and watch the latest ecosystem news, insights, and resources
Part 3/3 Owning Intelligence Series: How Coinbase Built, Evaluated, and Post-Trained a Fraud Agent
TL;DR: Using SkyRL on Anyscale, we post-trained Qwen3.5-9B for Onramp fraud detection and served it with Ray Serve LLM and vLLM. On our benchmark, it exceeded Opus 4.5 across all four detection metrics, including 9.6% higher F1. In online inference, we reduced end to end latency by 55%.
Part 2/3 Owning Intelligence Series: How Coinbase Built, Evaluated, and Post-Trained a Fraud Agent
TL;DR: Newer LLMs are not necessarily better at domain-specific tasks. On our fraud benchmark, newer Opus, Sonnet, and GPT versions all had lower recall, F1, and dollar-weighted recall—even when precision improved. The lesson: choose models using high-quality, domain-specific benchmarks, with reproducible evaluation and ideally deterministic scoring against verified outcomes. These findings also motivated our next step: post-training open-weight models for greater control over quality, cost, and deployment.
Part 1/3 Owning Intelligence Series: How Coinbase Built, Evaluated, and Post-Trained a Fraud Agent
TL;DR: How Coinbase built, evaluated, and post-trained an Onramp fraud agent to achieve 9.6% higher performance (F1 score) and 55% lower end to end latency than frontier models.
Migrating 300+ namespaces from self-hosted Temporal to Temporal Cloud
TL;DR: We moved more than 300 Temporal namespaces, across more than 300 services, from a cluster we ran ourselves onto Temporal Cloud. You cannot finish the move by repointing services at Temporal Cloud while workflows are still running on the old one. Where teams could pause new work, we waited for in-flight runs to finish and then switched; for trading, payments, and long-running work, we ran the old cluster and Temporal Cloud, and moved new workflows over in steps, with rollback as a config change. Private connectivity, per-namespace service allowlists, and encrypted payloads were in place before the first production namespace moved.