Polyglot — an escrow-gated localization foundry on CAP

CROO Agent Hackathon · Project 2. A paid, callable CAP agent that localizes a software string file into many languages by fanning the job out to a swarm of translator agents, running a deterministic QA gate on every returned locale, auto-re-routing failures to a backup translator, and delivering a verified multi-locale bundle whose keccak256 settles on Base — earning a coordination margin as the provider.

Money shot (runs offline, $0): one buyer order fans out into 6 per-locale sub-orders across a translator swarm; the Japanese translation comes back with a broken {count} placeholder, Polyglot's deterministic gate flags it RED, instantly re-routes JA to a backup translator, and delivers a 100%-verified bundle — a crash-causing bad translation caught and auto-fixed, on-chain.

Why this is hard-to-replicate on a normal API marketplace

On Stripe/RapidAPI you cannot escrow-pay six independent stranger translator agents per-locale with no shared bank/KYC, machine-gate each deliverable, auto-re-route the failures, and hash-prove every leg on-chain. Polyglot is a trust-minimized, instantly-settled, machine-verified piecework labor market — the value is the coordination + verification + settlement, not the translation itself.

Quick start (mock mode — offline, $0, no keys, no funds)

npm install
npm test          # 111 tests across 21 files — the full build, all gates
npm run demo      # runs the money shot in mock mode; writes dist/demo/{run-log.json,index.html}

Then open dist/demo/index.html in a browser (a single self-contained file — no network) to see the fan-out mesh, the JA fail → re-route → heal, and the final on-chain bundle hash.

Requirements: Node ≥ 20. Stack: TypeScript (strict, ESM), vitest, viem. No other runtime services.

Architecture

core        domain types + the CapClient seam · deterministic QA gate (key-parity + placeholder
            integrity) · verified-bundle assembler · keccak256 (viem) · CAP_MODE config loader
mock-cap    offline MockCapService emulating the full CAP order lifecycle + MockCapClient + fixtures
foundry     TranslatorAgent providers · the Polyglot engine (fan-out → QA gate → re-route → settle)
base-events read-only decoding of CAPCore/CAPVault settlement logs (tested on recorded fixtures)
demo        end-to-end money-shot runner + a self-contained offline HTML dashboard + CLI
live        LiveCapClient (@croo-network/sdk) · live smoke script · register-agents runbook · .env.example

The product logic is mode-blind: it talks only to a CapClient interface. CAP_MODE=mock (default) uses the offline mock service; CAP_MODE=live uses the real CROO CAP SDK. Going live is a config flip — no product-code changes.

Honest CAP order model

CAP is escrow-first and a requester cannot reject after paying (paid → Provider-only). So:

• Buyer ↔ Polyglot — Polyglot is the provider (earns a margin; deliverOrders the verified bundle, or rejectOrders an undeliverable job → buyer refund).
• Polyglot ↔ translator (per locale) — Polyglot is the requester; on a QA failure it cannot claw back a paid translator, so it re-routes to a backup and absorbs the cost (its QA guarantee is the value it sells). Buyer refunds come only from provider-reject on a deterministic content verdict — never from an SLA timeout.

payOrder is not concurrency-safe per wallet, so the per-locale fan-out is serialized per wallet and sharded across 2–3 Polyglot requester wallets.

CAP SDK methods used (@croo-network/sdk, live mode)

negotiateOrder · acceptNegotiation · payOrder · deliverOrder (writes the keccak256 of the deliverable on-chain) · rejectOrder · getOrder · getDelivery · connectWebSocket (mapped to the internal event stream: OrderCreated/OrderPaid/OrderCompleted/OrderRejected). Payment token: USDC on Base (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913). Contracts: CAPCore 0xaD46f1Eba2fe9cBB689D2874a52039192F2ac821, CAPVault 0x33ECdcC8dD32330ec5a62AB1986F25ED5B5D170d. Gas is sponsored (no ETH).

Live proof — a real CAP order settled on Base mainnet

The live smoke (scripts/live-order.ts, run against @croo-network/sdk v0.2.x) drove one real order end-to-end — negotiate → accept (on-chain create) → pay (USDC escrow) → deliver (schema bundle, content hash on-chain) → clear — all four transactions confirmed on Base mainnet (chain order id 166868, total cost ≈ $0.02, gas sponsored):

Lifecycle step	Basescan transaction
Create (provider accepts)	0x84ddadcc…f209122
Pay (buyer escrows USDC)	0x91ddd987…5ea8aa0
Deliver (bundle hash on-chain)	0x755ee594…fc66118b
Clear (settlement)	0xaf3e9a14…40aba7e4

Buyer (requester) AA wallet 0xa497EB1C8F572e501D196e617240F040F1D416b3 · provider AA wallet 0xF6D638240b663BA874e1C81081d4a93E60C96dd7. This smoke pair is self-owned (it proves the integration, not counterparty diversity — diverse buyer/counterparty activity comes from external partner teams).

Going live

Live execution is human-gated — see docs/runbooks/register-agents.md and .env.example (env var names only — never commit secrets): register the agents, fund the requester wallets, flip CAP_MODE=live, and run the smoke. Cost is ≈ $0: orders are $0.01 and gas is sponsored. The executed live smoke is scripts/live-order.ts (npx tsx scripts/live-order.ts); it hard-caps spend at $0.10, serializes payOrder per wallet, and supports RESUME_ORDER_ID to re-deliver an already-paid order without paying twice.

Tracks

Creator & Content Ops Agents (primary) + Open – Any A2A Agents (secondary).

License

MIT.