Building a Multi-Agent System for iGaming and Web3: The Initiation Phase

I work as a Staff Software Engineer in Web3, and we’re bringing together the worlds of iGaming and blockchain in innovative ways.

Why We Decided to Build Our Own Antifraud System

A couple of months ago, we realized it was time to design and implement a robust antifraud system tailored to our unique use case. This article kicks off a series where I’ll document our journey toward building that system from the ground up.

There are existing antifraud solutions in the Web3 space, but each comes with limitations that don’t align with our needs:

• Forta – Custom plugins are Node.js only, with limited context per transaction—insufficient for AI agents.
• OpenZeppelin Defender – Sentinel bots are useful, but integration with multi-agent AI is limited.
• Chainalysis / TRM Labs / Elliptic – These offer strong proprietary AI models but don’t allow for custom agent logic.
• BlockSec – Doesn’t support user-defined AI agents.
• Quantstamp RTM – Heuristic-driven AI is not exposed to end users or extensible.

Our conclusion: The market is still a greenfield when it comes to truly flexible, agent-based antifraud systems. We can either wait for AWS, GCP, or Azure to fill the gap—or build it ourselves. And we need it now.

What Are We Building?

We're building a Multi-Agent System (MAS) for antifraud, tailored to Web3 and iGaming. The system will need to handle massive data ingestion from the blockchain—so it’s also a Big Data challenge.

It’s crucial that we can mix and match programming languages and agent roles. Here’s what our architecture looks like at this stage:

Agent Roles

• Collector Agent: Listens to blockchain events. Implemented in Golang, optimized for high-throughput indexing.
• Enrichment Agent: Adds metadata such as geolocation or IP reputation. This data comes from frontend–backend interactions. Implemented in Node.js and Golang.
• Alert Agent: Sends fraud alerts to Slack. This is our way of implementing a Man-in-the-Loop system.
• Supervisor Agent: Manages fraud detection thresholds and policies. We’re using PHP here due to its rich ecosystem of UI and configuration tools.

Shared Context Is Crucial — Enter MCP

One thing became crystal clear early on: all agents in the system must share common context. Each agent needs access to:

• Data origin history
• Previous processing stages
• Cloud and on-premise databases
• Logs and audit trails
• Real-time alerts

Fortunately, there’s already a protocol being adopted by tech giants like AWS, Azure, and GCP that solves exactly this problem: Model Context Protocol (MCP): https://github.com/modelcontextprotocol

By adopting MCP, we ensure interoperability, consistent context sharing, and future-proofing for our antifraud MAS.

What’s Next?

In the next articles, I’ll dive into how we’re implementing agents, orchestrating their communication, and integrating AI models for detection and enrichment. We’ll also explore how MCP enables coordination and logging across the entire system.

Stay tuned. The journey is just beginning.