TAIFOON  ·  ENGINEERING  ·  Q3 2026

Dev Team Roadmap & Acceptance Criteria

Engineering companion to ROADMAP_Q3_2026 / LITEPAPER. Real chains, real endpoints, real external contracts. 13 weeks, 6 sprints.

Repo split: proof/DA → spinner/da-api (Rust) · venue/solver → taifoon-orderbook (Rust) · agent-facing HTTP + proxies + UI → taifoon-web (thin route.ts + tested logic.ts, agent auth via getAgentAuthError) · actions → taifoon-surge · MCP → taifoon-mcp.

WS0 — Receipts Core (weeks 1–2, blocks everything)

The Receipt is the shared unit across all workstreams. One schema, one signer, one verifier.

Tasks

• R-1 Define TaifoonReceipt v1 schema (JSON + canonical CBOR for signing): receipt_id · subject {chain_id, tx_hash | msg_id, event_index} · verified_claims [inclusion, finality, anchoring] · rpc_quorum {endpoints[], agreement} · client_build {name, version, git_sha} · superroot {mmr_root, height, timestamp} · signature (secp256k1) · signer_pubkey. Publish spec to docs/receipts-spec-v1.md + public page on taifoon.dev.
• R-2 Receipt issuer service (Rust, in da-api): sign with HSM/KMS-held key; idempotent by subject.
• R-3 Receipt API in da-api, proxied via taifoon-web: POST /v5/receipts → 201 receipt · GET /v5/receipts/{id} · GET /v5/receipts/{id}/verify → valid + per-check breakdown.
• R-4 Standalone verifier: @taifoon/receipt-verify (npm) + Rust crate. Verifies signature + recomputes MMR inclusion against published superroot. No Taifoon API dependency at verify time.

Acceptance criteria

• 100/100 sampled mainnet txs across ≥10 chains (incl. Ethereum 1, Base 8453, Arbitrum 42161, Solana) receipt in <5s p95; verify returns valid=true.
• Tampering any field (root, tx_hash, quorum) → valid=false with the failing check named.
• Offline verifier reproduces API verdict on all 100 receipts with only receipt + public root checkpoint.
• Spec reviewed by 1 external party (candidate: LayerZero DevRel, see WS2 BD gate).
• taifoon-web: /v5/receipts rewrite added to vercel.json (explicit approval per repo rules), route tests per CLAUDE.md §C7.

WS1 — Virtuals ACP Provider + Evaluator (weeks 1–6)

Tasks

• A-1 (wk1) Register agent, add Signer key, capture builder code. New service taifoon-acp-agent (Node/TS): wraps existing APIs, SSE listener with job queue (graduation requires concurrency handling + malformed-request rejection).
• A-2 (wk1–2) Offering settlement-proof (service-only, $0.50–$2/job): schema {chain_id, tx_hash, claim_type} → deliverable = TaifoonReceipt (WS0). Backed by POST /v5/receipts.
• A-3 (wk2–3) Offering cross-chain-order-execution (fundTransfer=true): schema {src_chain, dst_chain, market, side, size, limit_price, slippage_bps}; executes on Solana venue via Hand trait; per-client hot wallet (segregated keys per ACP fund-transfer convention); deliverable = fill report + Receipt of settlement tx.
• A-4 (wk2) Free Resources (no escrow): GET orderbook-depth {market}, GET receipt-status {receipt_id} — reuse existing CLOB + receipts APIs.
• A-5 (wk3) Sandbox: second buyer agent, ≥10 successful jobs incl. rejection paths (bad schema, unsupported market, oversized order). Evidence video. Submit graduation (~7 working days review — submit by end wk3 to be live wk5).
• A-6 (wk4–6) Evaluator mode: register as evaluator for fund-transfer jobs; evaluation = fetch claimed tx → issue/verify Receipt → complete/reject on-chain. Target: listed on ≥1 external agent's jobs by wk6.
• A-7 (wk5–6) x402 mirror: same offerings behind HTTP-402 using existing gateways-x402 pattern → reachable by non-Virtuals agents.

Acceptance criteria

• Graduated (main registry, GRADUATED filter) by end of week 5.
• settlement-proof: 50 consecutive jobs, 0 SLA breaches (SLA 10 min), success rate ≥98%.
• cross-chain-order-execution: 20 funded jobs end-to-end — escrow funded → fill on Solana venue → deliverable + Receipt → complete released; slippage within quoted bps on 100%; malformed/unsupported requests rejected before setBudget (never after funding).
• Evaluator: ≥25 third-party jobs evaluated; every verdict backed by a stored Receipt; 0 disputes lost.
• Revenue telemetry: USDC received, aGDP, job counts exported to /pulse (transform tested in logic.ts).
• Security: signer + hot-wallet keys never in NEXT_PUBLIC_*/client code; per-client wallets segregated; kill-switch env flag halts new setBudget within 60s.

WS2 — LayerZero Proof-First DVN (weeks 3–8)

Tasks

• D-1 (wk3) DVN on-chain contracts per target chain: assignJob/getFee, fee config, admin multisig (2-of-3 minimum), pause.
• D-2 (wk3–5) Off-chain worker (Rust): watch DVNJobAssigned → fetch packet → verify payloadHash against source chain through ≥3 independent RPC providers with quorum (the post-Kelp differentiator; own spinner nodes + 2 commercial — new vendors pass supply-chain check) → call verify on destination.
• D-3 (wk4–5) Receipt per verification (WS0): subject = {src_eid, dst_eid, guid, payload_hash}; GET /v5/receipts/lz/{guid}. Public explorer at taifoon.dev/proof/lz (RSC + ISR).
• D-4 (wk5–6) Testnet soak (Base Sepolia ↔ Arb Sepolia ↔ OP Sepolia), then mainnet behind an allowlisted test OApp we control.
• D-5 (wk6–8) BD gate: submit for DVN listing in LayerZero docs/registry; pilot with 1 external OApp/OFT as optional DVN, then required position.
• D-6 (wk7–8) Managed-DVN packaging: Terraform/Helm + runbook; issuer-branded instance deploys in <1 day.

Acceptance criteria

• 2,000+ messages verified on testnet soak, 0 false attestations, ≥99.5% verified within source finality + 60s.
• Mainnet: 500 messages on own OApp across 3 pathways; every verification has a Receipt; DVNFeePaid sum reconciles with fee config to the wei.
• Chaos: kill 1 of 3 RPC providers → quorum holds, Receipt records degraded quorum; 2 of 3 disagree → REFUSE to attest + PagerDuty alert. Refusal-over-guess is a hard requirement.
• Byzantine RPC test: forged header from one provider → no attestation produced (CI regression test).
• Listed or in written listing pipeline with LayerZero by wk8; ≥1 external OApp running us as optional DVN.
• Fee revenue dashboard on /pulse fed by DVNFeePaid events.

WS3 — Wormhole Settlement Solver (weeks 7–10)

Tasks

• S-1 (wk7) Solver service (Rust, services/mayan-solver): subscribe to Swift auctions, price against CLOB mid + inventory, bid within risk limits.
• S-2 (wk7–8) Risk module: hard caps (per-order, per-asset, aggregate notional — starter $10k/$50k/$100k, TO BE SET BY DESK), inventory rebalancing job, circuit breaker on 3 consecutive losing fills.
• S-3 (wk8) Fill pipeline: win auction → fill from venue inventory → confirm via WormholeScan → issue Receipt (subject = VAA/fill tx) → P&L ledger entry.
• S-4 (wk9) Depth-as-fill-capacity: read-only quote API GET /solver/quote {src_chain, dst_chain, token, amount} → exposed as ACP Resource + x402 endpoint (ties into WS1).
• S-5 (wk9–10) BD gate: volume report → Wormhole/Mayan for named-partner track; xGrant application submitted (flight-recorder scope, WS4).

Acceptance criteria

• Devnet/testnet: 100 simulated auctions, bid-to-fill logic correct on 100%.
• Mainnet pilot: ≥50 auctions entered, ≥15 won, fill success 100% on won auctions (won-but-unfilled = sev-1), p95 fill ≤ 15s.
• 2-week P&L ≥ 0 net of gas/rebalancing at starter caps; every fill has a Receipt; ledger reconciles on-chain to the lamport/wei.
• Circuit breaker fires in staging drill and halts bidding <5s.
• xGrant application submitted by wk10 (owner: BD + eng lead).

WS4 — Long-Haul Sync + Flight Recorder (weeks 7–13)

4a · Long-haul task sync (ACP primitive)

• L-1 (wk7–9) Checkpoint store: state machine created → checkpoint[n] → finalizing → settled; each checkpoint hashed and anchored into the superroot pipeline; API POST /v5/tasks, POST /v5/tasks/{id}/checkpoints, GET /v5/tasks/{id}/attestation.
• L-2 (wk9–10) ACP offering long-haul-task-sync (subscription job via SubscriptionHook) — progress attestations let buyers verify liveness mid-job instead of waiting for expiry.

• 72-hour synthetic agent job survives service restart with zero checkpoint loss.
• Attestation for checkpoint N verifiable offline against superroot.
• 1 external design-partner agent running on it by wk13.

4b · Flight recorder (private beta)

• F-1 (wk10–12) Ingest: LayerZero delivered messages (endpoint events + lzRead where available) and Wormhole VAAs (WormholeScan) for enrolled issuer contracts; continuously re-verify against source state via spinner; emit Receipt or discrepancy alert.
• F-2 (wk11–12) Config-risk scoring: DVN set / required-position analysis per OApp (the 47%-on-1/1 problem), Guardian-set assumptions for NTT; webhook + Slack alerts on config change, unknown DVN, default reliance.
• F-3 (wk12–13) Beta UI at taifoon.dev/recorder + 3 design partners enrolled (target: mid-size OFT issuers from WS2 pipeline).

• Replays the April Kelp scenario from archived data and flags the fraudulent attestation window.
• <2 min alert latency on injected config change in staging.
• 3 signed beta LOIs.

WS5 — Platform, Security, Publishing (continuous)

• P-1 All new taifoon-web routes: thin route.ts + tested logic.ts, agent auth via getAgentAuthError/getAgentInboxAuth, no new Supabase clients outside src/lib/db, secrets server-only. npm test && npm run typecheck green; husky hook never bypassed.
• P-2 New rewrites (/v5/receipts, /solver, recorder) — explicit approval before touching vercel.json/next.config.ts; allowlists updated with route tests first (security boundary rule).
• P-3 Key management: DVN signer, ACP signer, solver wallets in KMS; quarterly rotation runbook; kill-switch env flags per service (FEATURE_* pattern, no hardcoded gates).
• P-4 Observability: per-workstream dashboards on /pulse; alerting: attestation refusal, SLA burn >50%, solver breaker, escrow anomalies.
• P-5 External-dependency audit gate: every new npm/cargo dep (acp-node-v2, mayan SDK, RPC SDKs) → downloads/maintainer/postinstall check per repo CLAUDE.md §A before merge.
• P-6 Publishing cadence: weekly metrics post (jobs, messages, auctions, receipts) via existing blog pipeline.

Sprint Map & Gates

Gate rule: a gate failing moves BD asks, not engineering scope — nothing downstream hard-depends on an external approval except WS2 D-5 and WS3 S-5.

External Projects Involved

Virtuals ACP (acp-node-v2, Base 8453, app.virtuals.io) · Base (USDC, builder codes, sponsored gas) · LayerZero V2 (ILayerZeroDVN, EIDs 30184/30110/30111/30101, DVN registry listing) · EigenLayer (CryptoEconomic DVN — design only) · Wormhole (WormholeScan API, chain IDs 1/2/30, xGrant, Queries closed beta — blocked external dependency, flagged) · Mayan (Swift auctions, solver SDK) · x402 (existing gateway code) · RPC vendors (Alchemy/QuickNode + own spinner nodes) · Solana (prod venue) · Drift v2 fork (venue engine).

Out of scope Q3 (explicit): EVM Reactor mainnet, EigenLayer AVS implementation, Wormhole Queries-dependent recorder features (until beta access), token/tokenomics work.

TAIFOON · EVERY ACTION PROVABLE · TAIFOON.DEV