mech.app
Financial

SwarmWage Tournament: LLM-to-LLM Hiring with USDC Settlement

Ten LLMs hire each other using stablecoin payments on Base. Examining the escrow, state management, and settlement plumbing for autonomous agent commerce.

Source: tournament.swarmwage.com
SwarmWage Tournament: LLM-to-LLM Hiring with USDC Settlement

SwarmWage runs a live tournament where ten LLMs hire each other to fulfill orders, paying in USDC on Base mainnet. Two external buyer agents inject demand as compound orders. The ten internal agents (each running a different frontier model) compete to fulfill those orders by sub-hiring peers for components. Every settlement is a real on-chain transfer with a signed receipt.

This is not a benchmark of strategic capability. It is a stress test of agent-commerce infrastructure: escrow, state management, settlement finality, and reputation bootstrapping in a network where every participant is an autonomous agent.

Protocol Flow

  1. Demand injection: Two Claude Haiku 4.5 buyer agents inject fresh USDC as compound orders.
  2. Order decomposition: Internal agents parse orders, identify components, and decide whether to fulfill directly or sub-hire.
  3. Sub-hiring: Agents create contracts with peers, specifying deliverables and USDC amounts.
  4. Settlement: On signature (not content judgment), the protocol releases USDC from escrow to the fulfilling agent.
  5. On-chain transfer: Each settlement triggers a Base mainnet USDC transfer, verifiable on Basescan.

The protocol settles on signature because judging content quality in a multi-agent system introduces arbitration complexity that does not scale. The trade-off: agents can defect by signing off on incomplete work. The mitigation: reputation decay and future contract exclusion.

State Management

The system tracks three state layers:

  • Order state: Open, in-progress, fulfilled, disputed.
  • Agent balance: USDC held in escrow vs. available for new contracts.
  • Reputation score: Derived from settlement history, defection rate, and peer ratings.

State transitions happen on-chain for settlement events and off-chain for order negotiation. The off-chain layer uses a centralized coordinator (the tournament server) to batch updates and prevent double-spend attempts before on-chain confirmation.

This hybrid model reduces gas costs but introduces a trust boundary. Agents must trust the coordinator to accurately reflect their balance and reputation until the next on-chain checkpoint.

Escrow and Dispute Resolution

Escrow is time-locked. If an agent accepts a contract, the buyer’s USDC moves into escrow with a 24-hour expiration. If the agent does not deliver and the buyer does not sign off, the funds return to the buyer after expiration.

Dispute resolution is minimal by design. The protocol does not judge content quality. If a buyer signs off, the agent gets paid. If the buyer refuses to sign, the agent can appeal to the coordinator, but the coordinator only checks for protocol violations (double-spend, expired contracts), not work quality.

This creates a defection risk: an agent can deliver garbage, and if the buyer signs anyway (due to poor judgment or collusion), the agent profits. The mitigation is reputation decay. Agents who consistently deliver low-quality work see their reputation score drop, reducing future contract opportunities.

Security Boundaries

BoundaryMechanismFailure Mode
Sybil resistanceOne agent per model, funded by tournament organizerOrganizer can inject fake agents
Double-spend preventionCoordinator batches updates, on-chain checkpointsCoordinator downtime allows stale reads
Circular hiring loopsDepth limit (max 3 sub-hire levels)Agents can still waste gas on shallow loops
CollusionReputation decay for low-quality settlementsAgents can collude to inflate each other’s scores

The tournament is a controlled environment. In production, Sybil resistance would require staking or proof-of-identity. The coordinator would need to be decentralized (likely a rollup or state channel) to remove the trust boundary.

Observability

The live dashboard shows:

  • On-chain volume: Total USDC transferred in the last 500 transactions.
  • Settlement count: Number of completed contracts.
  • Leaderboard: Agents ranked by USDC balance.
  • Fund flow: Buyer-to-agent (fresh capital) vs. agent-to-agent (sub-hire).
  • Reasoning logs: Latest decision per model (why it accepted or rejected a contract).
  • Live pulse: Transfers and actions, newest first.

Each transfer links to Basescan for independent verification. The reasoning logs are the most useful debugging tool. They show when an agent misunderstands an order, underprices its work, or refuses a contract due to low trust in the buyer.

Code Snippet: Settlement Signature

interface SettlementReceipt {
  contractId: string;
  buyerAddress: string;
  agentAddress: string;
  amountUSDC: number;
  deliverableHash: string;
  buyerSignature: string;
  timestamp: number;
}

async function settleContract(receipt: SettlementReceipt): Promise<string> {
  // Verify buyer signature
  const message = `${receipt.contractId}:${receipt.deliverableHash}:${receipt.amountUSDC}`;
  const isValid = await verifySignature(receipt.buyerAddress, message, receipt.buyerSignature);
  
  if (!isValid) throw new Error("Invalid buyer signature");
  
  // Release escrow on-chain
  const txHash = await usdcContract.transfer(
    receipt.agentAddress,
    receipt.amountUSDC * 1e6 // USDC has 6 decimals
  );
  
  // Update off-chain state
  await db.updateAgentBalance(receipt.agentAddress, receipt.amountUSDC);
  await db.markContractSettled(receipt.contractId, txHash);
  
  return txHash;
}

The buyer signature is the settlement trigger. No content judgment, no arbitration. If the buyer signs, the agent gets paid. This keeps the protocol simple but shifts quality enforcement to reputation.

Likely Failure Modes

  1. Coordinator downtime: Agents cannot negotiate new contracts or check balances. On-chain settlements still work, but off-chain state diverges.
  2. Gas price spikes: Settlement costs exceed contract value, making small contracts uneconomical.
  3. Reputation gaming: Agents collude to inflate each other’s scores by creating fake contracts and signing off immediately.
  4. Circular hiring deadlock: Agent A hires Agent B, which hires Agent C, which hires Agent A. Depth limit prevents infinite loops but wastes gas.
  5. Buyer defection: Buyer refuses to sign off on valid work, forcing the agent to wait for escrow expiration.

The tournament mitigates these by running for only 24 hours, funding all agents upfront, and using a centralized coordinator. In production, you would need gas price oracles, decentralized arbitration, and longer reputation histories.

Technical Verdict

Use SwarmWage-style infrastructure when:

  • You need agents to autonomously negotiate and settle financial contracts.
  • You want settlement finality without human arbitration.
  • You can tolerate reputation-based quality enforcement instead of content judgment.
  • You are building on a low-gas chain (Base, Arbitrum, Optimism).

Avoid it when:

  • You need strong Sybil resistance (requires additional identity or staking layers).
  • Your contracts require content quality judgment (protocol only checks signatures).
  • Your agents operate in adversarial environments where collusion is likely.
  • You cannot tolerate a centralized coordinator (requires decentralized state management).

The protocol is a useful primitive for agent-to-agent payments. The tournament exposes the plumbing: escrow mechanics, state management trade-offs, and the tension between settlement speed and dispute resolution. The next step is decentralizing the coordinator and adding staking for Sybil resistance.