[maxfain]

USDC bounties can now be paid on Arc (eip155:5042), Circle's stablecoin chain, alongside Base and Polygon. Coinbase's CDP facilitator, which settles our Base and Polygon payments, doesn't support Arc. Its /supported and network docs don't list it. Arc therefore runs on two paths, the "Circle in, wallet out" design Max picked.

How Arc settles

paymentProviderFor now returns a NetworkRouter. Base and Polygon go to CDP exactly as before. Arc goes to ArcFacilitator (payments/arc.ts), which routes by who signed the transfer.

Leg	Signed by	Settled by
Deposit	the buyer, to the escrow wallet	Circle's Facilitator Service (circle-facilitator.ts), Authorization: Bearer CIRCLE_API_KEY
Release / refund	the escrow wallet, to the agent / buyer	the escrow wallet itself: it broadcasts its own transferWithAuthorization on Arc

Why payouts don't go through Circle. Circle's docs say settling with an API key binds the payment's payTo to that Circle account. That is right for our escrow wallet. It would be wrong for agents' and buyers' wallets, which a payout or refund pays.

The Circle adapter uses the same {x402Version, paymentPayload, paymentRequirements} contract as CDP. Its response shapes come from Circle's published OpenAPI (facilitator-service.yaml).

• Every settle carries a payment-identifier taken from the authorization nonce (ba_<nonce>), so retries resolve to one payment.
• Circle can answer settlement_pending before it has a transaction hash. SettleOutcome.pending now allows a missing hash, and settle.ts keeps any hash an earlier attempt recorded (COALESCE).
• invalid_transaction_state ("a nonce that already settled") is classified like CDP's nonce_already_used.
• 401/403 map to auth, 429 to rate_limited, and 409 and 5xx to server, so they are retried and never re-signed.

The relay is the escrow wallet broadcasting its own authorization. EIP-3009's one-use nonce means no retry, race or lost answer can pay twice. Every attempt runs in rounds, and each round starts from the chain:

1. Used? If authorizationState is set, the money moved. The answer is settled with the transaction from the token's AuthorizationUsed log. The relay finds that transaction by searching the blocks of the authorization's validity window, located by block timestamp however long ago it was, in 5,000-block slices (Arc's nodes refuse 10k). Log queries move to the next endpoint if a node refuses one. A query that can't be answered keeps the leg open and retried, so an outage never settles it without its transaction. Only a window read in full without the log gives nonce_already_used, which settle.ts already resolves.
2. Expired? Only the chain's clock decides. The leg is expired, and can be re-signed, only when a block at or past validBefore exists and the authorization is unused when read at that block. That read is pinned to the block, so a lagging node errors rather than answering from older state. Our own clock and the simulation's "expired" never decide it: a transfer sent earlier could still land.
3. One transaction in flight. The relay waits up to 4 s for any pending escrow-wallet transaction to land, then sends on the next nonce. A send that loses its nonce to a concurrent payout (another Worker) starts a new round, as does one whose nonce goes to another transaction while it is watched.
4. Simulate with eth_estimateGas, and classify a revert by its FiatToken reason (signature, balance, blocklist).
5. Fees: maxFeePerGas = 2 × baseFee + tip, never under Arc's 20 gwei floor, which Arc's mempool silently drops below. The relay also checks the USDC balance covers the transfer plus gas, since Arc's gas token is USDC. If it doesn't, it answers insufficient_funds and sends nothing.
6. Wait up to 6 s for the receipt (Arc finalizes in under a second). Past that, the answer is pending with the hash. A revert after a clean simulation is retried later with backoff, not resent at once.

Once it has sent, it never invites a second signature. On a leg's first attempt, settle.ts's row says nothing was ever broadcast. It would read a reuse answer or a terminal verdict as "this authorization never moved money" and let the cron sign a new one. So after a send in the same call:

• a used authorization with no log in its window is pending without a hash, so the hash already recorded stays (a hash this call sent may never have landed);
• a terminal simulation verdict waits for the next attempt.

Guard rails

• Offered only while configured. New Arc deposits are offered only while CIRCLE_API_KEY is set (fundableBountyNetworks). This applies to the hire 402, the price list, /.well-known/x402, agent and owner posts, and fundEscrowTask. allowedBountyNetworks still includes Arc, so existing Arc tasks stay visible and payable. The relay needs only the escrow key.
• This merge changes nothing for buyers until the key is set. Production offers Base and Polygon as today.
• Arc is escrow only. escrow: false on Arc answers 400 escrow_required. A sign-at-accept transfer would have Circle settle straight to the agent's wallet, binding it to our account. The sign-at-accept path refuses Arc as well.
• Gas float. The escrow wallet needs a small USDC float on Arc, about 0.002 USDC per payout. The runbook says to send it ~1 USDC first.

Arc constants (read on-chain)

• Chain: eth_chainId is 0x13b2 (5042).
• USDC: the ERC-20 interface at 0x3600000000000000000000000000000000000000, 6 decimals (native balance uses 18).
• EIP-712 domain: name() USDC, version() 2. The DOMAIN_SEPARATOR() recomputed from those matches the contract's. The TRANSFER_WITH_AUTHORIZATION_TYPEHASH is the standard one.
• Circle's offer: the offer's extra carries assetTransferMethod: "eip3009", which Circle's schema says it expects. Circle's /supported lists eip155:5042 exact {name: USDC, version: 2}.
• RPC: Arc's own node plus the dRPC, QuickNode and Blockdaemon endpoints from Arc's docs (ARC_RPC_URL first). All four answered eth_blockNumber, a deployless eth_call and eth_getCode.

Also

• Shared EVM code. payments/evm.ts is a new leaf module: hex, EIP-55, the house key parser, RLP and EIP-1559 signing. house-wallet.ts and wallets/bind.ts import from it; house-wallet.ts re-exports, so its API is unchanged. This avoids an import cycle (index → arc → house-wallet → index).
• Payout wallets can be bound on Arc (ALLOWED_WALLET_NETWORKS). A verified plain key bound elsewhere is paid at the same address on Arc. The Circle CLI's chain name is ARC.
• The paid feed counts Arc settlements and links explorer.arc.io. The task page links Arc addresses there, and the web copy names Base, Polygon and Arc.
• SDK 0.10.4. BOUNTY_NETWORKS includes eip155:5042, and the Circle command uses --chain ARC on Arc.
• Docs:
  • SPEC: an Arc section, plus updates to custody, the env table and the network table. The network table's stale "only Base" sentence is fixed.
  • OpenAPI: network enums and copy.
  • SECURITY: the house key line.
  • API README: env rows CIRCLE_API_KEY, CIRCLE_FACILITATOR_URL, ARC_RPC_URL.
  • Deploy runbook: step 8.
  • CHANGELOG.

Tests

• evm.test.ts:
  • RLP reference vectors.
  • Three EIP-1559 transactions that are byte-identical to eth-account 0.13.4: the raw bytes and hashes are pinned, covering long calldata and a two-byte nonce.
  • Sender recovery over 20 random keys, using an RLP decoder.
• circle-facilitator.test.ts: the request envelope and Bearer header, the payment-identifier, the verify and settle mappings, pending with and without a hash, every error status, and /supported without credentials.
• arc.test.ts runs against a fake Arc node. The fake keeps a mempool with pending and latest nonces. It changes authorization state only when a transaction is mined. Its blocks are timestamped, and eth_getLogs is range-checked with the 5,000-block cap. Pinned reads error when lagging. The tests cover:
  • the transaction: calldata, nonce, fees and the 20 gwei floor;
  • a used authorization with and without a log, and its transaction found a day later in ≤ 2 log queries;
  • foreign signer, wrong network, recipient or amount;
  • expiry by the chain's clock only. Our clock past validBefore changes nothing. A transfer still in the mempool near expiry is waited for, then settled when it lands. A dropped one expires only at the pinned block, not on a lagging node;
  • waiting for another escrow-wallet transaction;
  • losing a nonce race and resending in the same call;
  • two Workers paying out at once, landing on nonces 4 and 5;
  • a lost nonce;
  • simulation reverts, including "expired", which waits for the chain;
  • the gas float;
  • broadcast errors;
  • receipt timeout, and a revert that is retried later;
  • a transfer that lands while its receipt and log can't be read: it stays open over two attempts, then settles with its transaction once logs are readable;
  • log queries failing over to the next endpoint;
  • an earlier attempt's transfer landing just as a retry broadcasts, with no log in the window: pending without the refused retry's hash;
  • a terminal simulation verdict after a send, which waits for the next attempt;
  • RPC failover;
  • Circle-vs-relay routing and network routing.
• x402-tasks.test.ts, through the real routes and settle machine, with a fake Circle and the real relay against the fake node:
  • Arc is offered only with the key, Base, then Polygon, then Arc.
  • An Arc hire deposits through Circle and is released by the escrow wallet's own Arc transaction to the deliverer's plain key. Circle sees only the deposit and CDP sees nothing.
  • Cancel refunds the buyer the same way.
  • escrow: false on Arc is refused.
  • A payout still in flight is never re-signed. Retried near expiry, both by the chain's clock and by ours, it stays releasing, and the sweep doesn't re-sign it. Once it lands, it is released with its own transaction, and only one transfer is ever sent. This test fails against the relay's first version, which declared expiry by its own clock 10 s early.
  • A payout that lands while its receipt and log can't be read is not re-signed on its first attempt. It stays releasing through a second retry with logs still unreadable, then resolves to the transfer that landed once logs can be read. This test fails without the "once it has sent" rule.
• Other tests: index.test.ts covers routing and the memo fingerprint; settle.test.ts covers pending without a hash; front-door.test.ts covers Arc held back without the key. SDK: --chain ARC.
• Results:
  • Suites: API 1271, SDK 222, web 3, console 45, MCP 73.
  • Typecheck clean; lint 0 errors (1 pre-existing warning).
  • sync-skill, sync-positioning, check-positioning, check-examples and the script self-tests pass, and the web build succeeds.

Checked live on Arc mainnet with a throwaway key that holds nothing:

• an authorization built by the escrow code passes USDC's signature check in eth_estimateGas, reverting only for "transfer amount exceeds balance";
• the same authorization with one signature byte flipped reverts "invalid signature";
• the node decodes the signed type-2 transaction and prices its gas.

Not tested end to end:

• Circle verify/settle. These need Max's Circle API key. I didn't use the keyless trial, which would sign up for Circle's service.
• A real Arc payout. This needs USDC on Arc in the escrow wallet.

After merge:

1. Set CIRCLE_API_KEY (runbook step 8) and send the escrow wallet ~1 USDC on Arc.
2. Hire for 1 USDC paid on Arc (circle services pay … --chain ARC), then cancel it. The refund exercises the relay.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VX2Nm8D11UusvYsuAtrcY9

---

Generated by Claude Code

[greptile-apps]

Confidence Score: 5/5

[Critical risk] Adds payment settlement on Arc chain with escrow and Circle integration.

The PR appears safe to merge, with no new actionable issues found.

What we checked:

• Paid transfers keep their links: An unreadable log returns a retryable answer instead of finishing the payout without a hash. Later attempts can record the transaction once its log is readable.

Summary

Adds Arc bounties with Circle settling deposits and the escrow wallet sending payouts and refunds.

• New Arc deposits require CIRCLE_API_KEY; Arc payments always use escrow.
• The latest change keeps payments open when their transaction logs cannot be read and tries another endpoint when a log query is refused.
• The seven earlier, unnumbered findings were rechecked against the current code and are addressed.
• No new actionable issues were found. Tests were inspected, not run; live Circle settlement and a funded Arc payout remain the stated rollout checks.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Payment[Payment request] --> Network{Network}
  Network -->|Base or Polygon| CDP[CDP facilitator]
  Network -->|Arc| Signer{Signed by escrow wallet?}
  Signer -->|No: deposit| Circle[Circle facilitator]
  Signer -->|Yes: payout or refund| Relay[Arc relay]
  Relay --> Used{Authorization used?}
  Used -->|No| Send[Check expiry, simulate, and send]
  Used -->|Yes| Logs{Read payment log}
  Logs -->|Found| Settled[Settle with transaction hash]
  Logs -->|Unreadable| Retry[Keep leg open and retry]
  Logs -->|Full window empty| Reuse[Return reuse answer]

Loading

_{Reviews (5) · Last reviewed commit: "Arc relay: a log it can't read keeps the..." · Reviewed by Greptile}

[github-actions]

🔎 Console preview: https://ba9258a5.basedagents-console.pages.dev
🌐 Site preview: https://9185cd5f.auth-ai-web.pages.dev

(Passkey ceremonies only work on app.basedagents.ai — previews are for UI review.)