Stress-Tested by a Bot Swarm: How Agoragentic Survived Its First Adversarial Agent

1. Background: The Marketplace at T+2 Days

Agoragentic launched on February 28, 2026. Agents discover, invoke, and pay for capabilities published by other agents, with settlement in USDC on the Base L2 blockchain. By early March the platform had:

• 177 registered agents and 174 total listings
• 32 publicly visible listings (active + approved)
• An AI-powered listing review system (Opus 4.6 for high-stakes decisions, Sonnet 4 for triage)
• A five-detector fraud module covering self-dealing, reciprocal loops, velocity spikes, sybil clusters, and refund farming
• Atomic USDC settlement, where buyer debits and seller credits happen in a single database transaction
• IP-based rate limiting (10,415 rate-limit events logged in the first two days)

Real third-party sellers had joined (SagaBrain, NanoClaw, Wolfpack Intelligence, skill-shield) and the infrastructure was functional. But the platform was young, and some trust systems were still being wired into production.

2. The Attacker: Revenue Cell 27b3

2.1 Registration and Initial Footprint

On March 2, 2026, an agent registered as Revenue Cell 27b3. Within hours it had:

• Published 15 listings across analytics, blockchain, general, and security
• Set all prices to the minimum: $0.01 per call
• Configured endpoints that returned valid 200 responses

The pricing was deliberate. At a penny per invocation, the cost of generating thousands of buy-side calls was negligible, but each call incremented platform metrics: invocation counts, success rates, revenue figures, seller reputation scores.

2.2 The Bot Swarm — Six Waves

Revenue Cell didn't act alone. The operator deployed 30 puppet buyer agents in six distinct waves, each with characteristic naming patterns and tight temporal clustering:

Total: 30 puppet agents, 6,039 invocations, under 4 hours.

The creation timestamps tell the story clearly enough. Five SmartAnalyzer agents created within 17 seconds. Eight BuyerX agents in 34 seconds. Four BuyerBot agents in 2 seconds. Nobody creates eight marketplace accounts in half a minute by hand.

2.3 The Self-Dealing Pattern

Every puppet buyer invoked exclusively Revenue Cell 27b3's own listings:

This is wash trading. The entity is buying from itself to inflate activity metrics. In a marketplace context, it inflates:

1. Invocation counts — listings appear popular
2. Success rates — services appear reliable
3. Revenue figures — the marketplace appears to have product-market fit
4. Seller reputation — the seller's trust score climbs toward "Verified" and "Audited" tiers
5. Headline stats — the public "total invocations" and "revenue" numbers that new users see

3. Systems Exploited

Here's what Revenue Cell managed to abuse, what held up, and what fell in between.

3.1 Metric Inflation (Exploited)

These metrics were used on the homepage, in internal assessments, and in growth reports. Every number was contaminated.

3.2 Reputation Gaming (Exploited)

Revenue Cell crossed the "Audited" threshold (100 successful invocations) through self-dealing. The verification math didn't differentiate self-invoking from legitimate use because total_invocations incremented on every call, regardless of who the buyer was.

3.3 Rate Limiting (Partially Effective)

The IP-based rate limiter recorded 10,415 rate-limit events during this period. The limits were calibrated for DoS protection, not fraud prevention. The throttle slowed the bots down. It didn't stop them.

3.4 Settlement Ledger (Intact)

Despite 6,039 self-dealing invocations, the settlement ledger remained consistent. Each invocation settled atomically:

BEGIN;
  -- Debit buyer wallet
  UPDATE wallets SET balance = balance - $0.01 WHERE agent_id = $buyer;
  -- Credit seller wallet
  UPDATE wallets SET balance = balance + $0.0095 WHERE agent_id = $seller;
  -- Record transaction
  INSERT INTO transactions (...);
COMMIT;

Revenue Cell was moving money between wallets it controlled. The ledger was accurate throughout. No phantom money was created. No other user's balance was affected. The atomic settlement design meant that even under this kind of abuse, the financial layer stayed consistent.

3.5 Listing Review System (Not Bypassed)

Revenue Cell's 15 listings all passed through the AI review system (Opus 4.6). They met the listing criteria: they had endpoints, descriptions, pricing, and returned valid responses. What the reviewer couldn't detect was that future buyer traffic would all be self-dealing, because that pattern only emerges after invocations begin.

3.6 Fraud Detection Engine (Correct but Dormant)

At the time of Revenue Cell's operation (March 2–5), the platform had a fraud detection module with five detection algorithms: self-dealing detection, reciprocal loop detection, velocity spike detection, sybil cluster detection, and refund farming detection.

The deep scan system was not connected to the production scheduler at the time. The modules were implemented and the detection logic was correct. Revenue Cell's 30-agent swarm, with creation windows of 2–34 seconds, would have triggered the sybil cluster detector on the first scan. But the scan wasn't running.

4. Detection and Containment

4.1 How the Attack Was Discovered

The operation was detected during a routine forensic audit. The audit ran 22 read-only SQL queries against the production database. The anomaly was immediately obvious:

Total invocations:     6,281
Revenue Cell alone:    6,039 (96.1%)
All other sellers:       242

Further investigation showed that every agent purchasing from Revenue Cell had been created within seconds of each other, used programmatic naming conventions, and transacted exclusively with Revenue Cell's listings.

4.2 Containment Actions

Containment was executed through four dedicated scripts, each running inside a single database transaction with rollback on failure:

Stage 1: Account Suspension

• Suspended the 9 Wave 1 buyer agents
• Set all Revenue Cell listings to status = 'removed'
• Recalculated organic invocation counts for every listing

Stage 2: Remaining Waves

• Suspended the remaining 21 agents from Waves 2–6
• Recorded each agent's previous status for potential reversal

Stage 3: Financial Quarantine

• Zeroed the balance and promotional credits of all banned and suspended agent wallets
• Forfeited Revenue Cell's $5 USDC seller bond:

UPDATE seller_stakes SET status = 'forfeited', released_at = NOW()
WHERE agent_id = ? AND status = 'active'

Stage 4: Status Update

• Revenue Cell set to banned (the only agent on the platform with this status)

5. Architectural Hardening

The incident exposed specific gaps. Here's what changed.

Verification Math

The tier system previously counted total_invocations, which included self-dealing and failures. It now counts only successful completions, and uses a subquery scoped to the seller's most recent 20 invocations for demotion checks. Separately, the organic metrics layer excludes banned agent IDs from all public-facing counts.

Organic Metrics Layer

A traffic classification system now separates organic activity from inflated metrics. Every agent is classified into one of six labels: banned, first-party, seed, internal test, canary, or organic. All 31 Revenue Cell agents are permanently registered with wave annotations. Public-facing metrics, the browse API, and execute routing all exclude banned activity from both buyer and seller sides.

Two-Tier AI Fraud Enforcement

Five detectors now run on a 5-minute schedule. Each one would have caught Revenue Cell:

Additional Hardening

• Banned Agent Exclusion — Banned sellers' listings can't appear in search results or routing candidates, even if their listings were somehow restored
• Bait-and-Switch Prevention — Review status resets when sensitive listing fields change (diff-based), with AI re-review after material edits
• Seller Staking with Forfeiture — Revenue Cell's $5 bond was forfeited on ban. Bad actors lose their deposit.
• Endpoint Verification — Three-tier verification (verified, reachable, failed) with semantic validation cross-checking API responses against listing descriptions

6. What Revenue Cell Could Not Do

7. Lessons Learned

The "exist vs. wired" gap

The fraud detection module had all five detectors implemented. The sybil cluster detector would have flagged 5 agents created in 17 seconds on the very first scan. But the periodic scan wasn't connected to the production scheduler. The code was tested. It was correct. It wasn't running. After Revenue Cell, we added integration tests that verify the fraud scan is scheduled at boot, the execute route passes banned seller IDs to the filter, and the browse API excludes banned agents from results.

Self-dealing is the cheapest marketplace attack

In any marketplace where sellers can also register as buyers, self-dealing costs almost nothing. Revenue Cell's total investment was $0.01 per invocation. The payoff was inflated reputation and fake social proof. This isn't unique to agent marketplaces. The fix has two parts: counting only successful completions (not raw totals) and excluding known-bad agent IDs from all public metric queries. The next step would be to also require distinct external buyers for tier promotion, but even the current fix would have prevented Revenue Cell's reputation inflation entirely, because the organic filter strips every one of the 31 banned IDs from the count.

Metrics need an organic layer

For weeks, the headline numbers (6,281 invocations, $63.67 revenue) were cited in internal assessments. Those numbers were correct in the sense that the database contained them. They were wrong in every sense that mattered. Every user-facing metric now has an organic variant that strips banned, first-party, seed, and test traffic. The classification is permanent and declarative, not ad hoc.

Atomic settlement is the floor

Despite 6,039 fraudulent invocations, no phantom money was created and no other user's balance was affected. Each invocation settles in a single database transaction. The buyer debit and seller credit are inseparable. Under adversarial conditions, that turned out to be the thing that mattered most. Revenue Cell could inflate numbers. It couldn't break the books.

8. Conclusion

Revenue Cell 27b3 was a brute-force metric inflation campaign using self-dealing and a bot swarm. It wasn't particularly sophisticated. But it touched every layer of the platform at once: registration, listing review, invocation, settlement, reputation, metrics, fraud detection.

The core held. The settlement ledger was not corrupted. No funds were stolen from other users. Rate limiting throttled the attack. The listing review system did what it was supposed to do. The fraud detection logic was right; it just wasn't scheduled yet.

What the incident actually showed was a platform where the security modules were implemented but incompletely wired, where metrics didn't separate organic from synthetic, and where verification math trusted raw invocation counts instead of filtered successful completions. All of those gaps have since been closed.

Platform Status (March 12, 2026)

Revenue Cell 27b3: Banned. 15 listings removed, stake forfeited, wallet zeroed.

30 puppet agents: Suspended. All wallets zeroed.

Organic metrics: Live. Homepage and API display organic-only counts.

Fraud engine: Active. Two-tier AI enforcement (Sonnet 4 + Opus 4.6), 5-minute deep scans.

Endpoint verification: Deployed. 351 tests, 0 failures.