10 — Roadmap & open questions

1. What is verified vs proposed (be honest about the line)

Claim	Status	Evidence
One parent authority, many venue bindings	VERIFIED	economyos_agent_wallet_service.py, pre-bind gate, VenueBinding
Mode A (provider/Privy agent wallet) headlessly creatable	VERIFIED	ensure_agent_wallet(...)
Mode B (link existing Virtuals, ownership-proof)	VERIFIED	link_existing_virtuals_agent(...), verify_authority_proof
Virtuals wallet not headlessly creatable today	VERIFIED (absence)	ACP client has no create_agent; docs = owner/portal flow
Universal pre-bind gate (authority before setup)	VERIFIED	venue_prebind_gate.py (full module)
Cross-chain funding (resolve + gated execute)	VERIFIED	venue_funding_router.py, stablecoin_route_service, polymarket_bridge_service
Reasoning intent classifier (deterministic execution)	VERIFIED	chat_capability_intent_service.py
agent_authority execution block surfacing Mode A/B	PARTIAL	designed + funding-router consumer; per-venue execution wiring in progress
Mode B → real ACP-sidecar execution	PROPOSED	needs Virtuals V3 (IEvmProviderAdapter)
Mode C (Virtuals programmatic create)	UNVERIFIED	needs Virtuals V1
Mode D (register Privy wallet into EconomyOS)	UNVERIFIED	needs Virtuals V2
Privy server-side deposit address for agent wallets	PROPOSED	needs Privy P2

2. Phasing (how a dev / the OAW repo ships this)

Phase 0 — Extract the open-source core (no vendor changes needed)

• @oaw/core (TS) + oaw (Python): AgentAuthority, VenueCapabilityContract, pre-bind gate, funding router, intent classifier interfaces (07).
• @oaw/adapter-privy (Mode A) + @oaw/adapter-virtuals (Mode B, link-and-operate).
• Reference venue adapters: Hyperliquid, Polymarket (the two most-requested).
• Conformance test suites. Apache-2.0/MIT. This is buildable today from the verified Betvax patterns.

Phase 1 — Authority-aware execution everywhere

• agent_authority block in every venue's execution binding (Mode A/B distinguishable; exact blockers; no secrets).
• Strict classifier-failure policy for all money/action paths (06 B.4).
• Durable spend-intent + receipt traceability for every live action (06 A.5).

Phase 2 — Controlled live canary

• Flip one venue's live-execution flag + VENUE_FUNDING_EXECUTE_ENABLED behind approval; one supervised cross-chain transfer; one supervised order. Verify the full ledger chain attributes correctly.

Phase 3 — Vendor convergence (depends on PRs landing)

• Privy P2 → headless deposit addresses for agent wallets (funding Rail 1 fully programmatic).
• Virtuals V2 (Mode D) → register the Privy agent wallet into EconomyOS; Mode A gains the envelope. Or Virtuals V1 (Mode C) → mint Virtuals wallets headlessly. Either collapses the Mode A/B split.
• Virtuals V3 → Mode B real execution via external-signer ACP adapter; remove virtuals_authority_execution_not_supported_for_venue.

Phase 4 — Breadth

• More venue adapters (Pump.fun, Bankr, Binance, Trade.xyz, Kalshi when supported).
• Full CAIP-2 chain coverage in the funding router.
• Compose with x402 / AP2 at the funding/execution layer for agent-to-agent commerce.

3. Open questions only Privy / Virtuals can answer

These are the questions that, once answered, let OAW delete entire fallback paths. They are written as direct asks for the respective teams.

For Virtuals

1. Is there (or will there be) a server-safe agent-wallet creation API with a consent token, that provisions the EconomyOS envelope without a portal step? (Mode C / V1.)
2. Can an external Privy wallet be registered/adopted into EconomyOS so it gains caps/agentmail/card/ACP without re-creation? (Mode D / V2.) — We believe this is the cleanest path since EconomyOS already runs on Privy.
3. Can ACP/DegenClaw execute with an external signer (dev's agent wallet) via a documented IEvmProviderAdapter callback, with no raw key handed to Virtuals? (V3.)
4. What is the canonical ownership-proof Virtuals will honor for linking (verify_authority_proof payload), and is it stable across ACP versions?
5. What is the bridge/settlement contract for chains beyond Base/Solana/ARC, so funding routing is deterministic? (V4.)
6. Is acp-cli ever production-safe, or is it strictly a dev harness? (We currently treat it as dev-only.)

For Privy

1. Can useDepositAddress be driven server-side with an agent/server wallet as destination, returning per-source-chain addresses + quote? (P2.)
2. Is there a non-secret agent-wallet capability descriptor (supported chains + bound policy + signer status)? (P1.)
3. Is there a programmatic policy-mutation API with audit + idempotency? (P3.)
4. Are provider-signed action receipts/webhooks available for tamper-evident ledgering? (P4.)
5. What is the current CAIP-2 coverage for server/agent wallets and deposit addresses, and the roadmap for the rest? (P5.)

4. Risks & how OAW mitigates them

Risk	Mitigation
Prompt injection moves money	Brain/executor split + reasoning classifier + L4 policy gates — two independent non-LLM gates (06).
Silent wrong-authority signing (Mode B treated as A)	agent_authority block + no-silent-fallback rule.
Settlement-proof forgery	Provider-signed receipts (Privy P4) + durable attributable ledger.
Premature binding_supported=True	Treat the flag as "the backend can actually service it"; keep False until the adapter exists (the kalshi lesson).
Vendor lock-in	Vendor-neutral interfaces; Privy and Virtuals are adapters, not the core.
Cross-chain funding loss / wrong chain	Funding target read from the execution binding (single source of truth); fail-closed execute behind flags + policy + approval.
Over-eager auto-create on reads	allow_auto_create=False on every read/status/passive path.

5. The one-paragraph pitch for each audience

• For a dev: Install OAW, pick the Privy adapter, enable the venues you want. You get an agent wallet, multi-venue binding, cross-chain funding, and safe chat-driven execution — without solving wallet creation, venue auth, or chain routing yourself.
• For Privy: Your agent wallet + deposit address are already the substrate. A server-side deposit-address API and a capability descriptor make you the turnkey agent-economic-actor platform — and it benefits Virtuals too, since they run on you.
• For Virtuals: Devs want your EconomyOS wallet (caps/agentmail/card/ACP/ tokenization) for every user, not just portal-created ones. A wallet-register API (adopt a Privy wallet) or a consented headless-create API makes "use Virtuals wallet infrastructure" true for the entire developer base.

---

This folder is a living design. Update the verified/proposed table as PRs land and as Virtuals/Privy answer the open questions. The goal is convergence: one agent authority, any chain, any venue, safe from chat — built on Privy, enriched by Virtuals, owned by no single vendor.