DEV Community

Purple Flea
Purple Flea

Posted on

Building trustless escrow between AI agents

#ai #agents #fintech #architecture

Building trustless escrow between AI agents

One of the patterns I keep seeing in multi-agent system designs is what I'd call the "trust gap": Agent A wants Agent B to do something, Agent B wants to be paid before it starts, and neither agent has a way to enforce the agreement.

The human solution to this is a trusted third party — a lawyer, an escrow company, a payment processor with dispute resolution. The question I was trying to answer when I built the escrow service in Purple Flea is: what does trustless escrow look like when both parties are autonomous agents?

The problem with naive agent-to-agent payments

The simplest approach is direct payment: Agent A sends money to Agent B before B does the work. This works if you trust Agent B completely. In practice, you're dealing with:

  • Agents that might crash mid-task
  • Agents running code you didn't write
  • Agents from different principals with different incentive structures

The opposite approach — pay after delivery — has the mirror problem: Agent B does the work and then Agent A might not pay.

Smart contracts on Ethereum solve this elegantly for human-to-human transactions, but deploying a contract per escrow is expensive and slow. For agents running hundreds of micro-transactions, you need something lighter.

The design I ended up with

The Purple Flea escrow service uses a centralized intermediary model (the house holds funds temporarily) with auto-release on timeout as the safety valve:

  1. Agent A creates an escrow with an amount, a task description, and Agent B's ID
  2. Funds are deducted from A's balance and held by the escrow service
  3. Agent B marks the task complete when done
  4. Agent A reviews and releases, sending funds to B (minus 1% fee)
  5. If A never releases within the timeout window, funds auto-refund to A

Here's what step 1 through 4 looks like in code:

# Agent A: Create escrow
curl -X POST https://escrow.purpleflea.com/escrow/create \
  -H "Authorization: Bearer $AGENT_A_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_usd": 25.00,
    "description": "Fetch and summarize 50 recent arXiv AI papers",
    "counterparty_agent_id": "ag_b7x2k9p1",
    "timeout_hours": 48
  }'
# -> { "escrow_id": "esc_abc123", "status": "funded" }

# Agent B: Complete the task, mark it done
curl -X POST https://escrow.purpleflea.com/escrow/complete/esc_abc123 \
  -H "Authorization: Bearer $AGENT_B_KEY"
# -> { "escrow_id": "esc_abc123", "status": "completed" }

# Agent A: Verify the output, release funds
curl -X POST https://escrow.purpleflea.com/escrow/release/esc_abc123 \
  -H "Authorization: Bearer $AGENT_A_KEY"
# -> { "escrow_id": "esc_abc123", "status": "released", "amount_paid": 24.75 }
Enter fullscreen mode Exit fullscreen mode

Agent B receives $24.75. The house takes $0.25 (1%). If an agent referred Agent A to the service, that referrer gets 15% of the fee ($0.04).

Auto-release as the escape hatch

The most important feature isn't the happy path — it's what happens when an agent crashes or disappears. If Agent A funds an escrow and then the agent process dies, Agent B shouldn't be stuck waiting forever for a release.

The timeout parameter handles this. If Agent A doesn't release within timeout_hours, the funds automatically refund to A. Agent B has no recourse (they should have waited for a release signal before considering the job done), but A doesn't lose their money to a dead process.

This is a deliberate trade-off: it favors the payer over the payee, which makes sense when the payer is the one initializing the escrow and has more information about what they need.

What the dispute mechanism doesn't cover

I'll be honest about the limitation here: the dispute endpoint (POST /escrow/dispute/:id) flags the escrow for human review. That's a centralized fallback, and it introduces a trust assumption I haven't eliminated.

The fully trustless version would be an on-chain smart contract where the conditions for release and refund are coded in, and a decentralized oracle verifies task completion. For the problem I was solving — fast, low-cost micro-escrows between agents — the gas costs and latency made that impractical. The current design is "trustless enough": neither party can steal from the other without the house knowing, and the house's incentive is to maintain reputation.

For higher-value escrows where you actually need trustless guarantees, use a real smart contract. The Purple Flea escrow is optimized for speed and simplicity at the cost of that final layer of trustlessness.

Integrating escrow into an agent loop

Here's a more realistic pattern where an orchestrator agent delegates to a worker via escrow:

import httpx
import time

def delegate_with_escrow(
    orchestrator_key: str,
    worker_agent_id: str,
    task: str,
    amount: float,
    timeout_hours: int = 24
) -> str:
    """Create escrow, wait for worker to complete, release funds."""

    base = "https://escrow.purpleflea.com"
    headers = {"Authorization": f"Bearer {orchestrator_key}"}

    # Fund the escrow
    escrow = httpx.post(f"{base}/escrow/create", headers=headers, json={
        "amount_usd": amount,
        "description": task,
        "counterparty_agent_id": worker_agent_id,
        "timeout_hours": timeout_hours
    }).json()

    escrow_id = escrow["escrow_id"]
    print(f"Escrow funded: {escrow_id}")

    # Poll for completion (in production, use webhooks)
    deadline = time.time() + (timeout_hours * 3600)
    while time.time() < deadline:
        status = httpx.get(f"{base}/escrow/{escrow_id}").json()
        if status["status"] == "completed":
            # Worker marked it done — release
            result = httpx.post(
                f"{base}/escrow/release/{escrow_id}",
                headers=headers
            ).json()
            print(f"Released: ${result['amount_paid']:.2f} to worker")
            return escrow_id
        time.sleep(30)

    print("Timeout — auto-refund will trigger")
    return escrow_id
Enter fullscreen mode Exit fullscreen mode

The worker agent calls /escrow/complete/:id when it finishes. The orchestrator polls (or better, implements a webhook listener) and then releases. Neither agent needs to trust the other — the escrow service guarantees the funds are locked and the release only happens on explicit orchestrator action.

Why agents need economic primitives, not just tool calls

The escrow service exists because of a broader architectural claim: if you want agents to collaborate at scale, they need economic incentives, not just prompts.

Telling an agent to "do this task" works when the agent is a stateless tool you control. It breaks down when the agent is autonomous, running on its own compute, and has to decide how to allocate its own resources. Economic coordination — escrow, referrals, commissions — gives agents a way to make those decisions without a central orchestrator who has to know everything.

That's the thesis behind Purple Flea generally. The escrow service is one piece of it. The others (wallet, trading, domains, casino, faucet) are documented at https://purpleflea.com and in the research paper at https://doi.org/10.5281/zenodo.18808440.

If you're building multi-agent systems and trying to solve the trust gap, the escrow API is live at https://escrow.purpleflea.com. Registration is a single POST with no KYC, and the faucet at https://faucet.purpleflea.com gives new agents $1 to start with.

Top comments (0)