Skip to main content

Whitepaper — Roadmap

OAW is a reference SDK + standard. Here is exactly what is real today versus what still needs production wiring, upstream vendor APIs, or live canaries — so nothing is overclaimed.

✅ Done in the reference SDK​

  • Mode A (provider/Privy) + Mode B (linked Virtuals, ownership-proof) authority
  • Universal pre-bind gate (parent authority resolved before any venue setup)
  • agent_authority block surfaced on every execution (Mode A/B distinguishable)
  • Cross-chain funding router (resolve + fail-closed gated execute)
  • Reasoning intent layer (no keyword decides money movement)
  • Strict money-path gating (policy + live-flag + approval; no silent fallback)
  • 7 reference venue adapters, incl. the ACP-native Mode B sidecar route
  • 61 tests + conformance suite, clean type-check, npm-publishable build

🔌 Needs production adapter wiring (per venue, by integrators)​

  • Real venue API/SDK calls inside each executeOrPlan (today: reference receipts)
  • Durable spend-intent + receipt persistence (reference store is in-memory)
  • A Python oaw mirror

🤝 Needs upstream vendor APIs (proposals filed)​

  • Privy — server-side chain-agnostic deposit addresses for agent wallets
  • Virtuals — register an external (Privy) wallet into EconomyOS (Mode D)
  • Virtuals — consented headless create (Mode C); the verified surface has none today
  • Virtuals — ACP external-signer adapter for Mode B live execution

🧪 Needs live canary (opt-in, supervised)​

  • One supervised cross-chain transfer (flip the fail-closed flag once)
  • One supervised live order per venue, with end-to-end receipt attribution
info

Progress on the "needs vendor APIs" track depends on the upstream teams. The Privy and Virtuals proposals are paste-ready and evidence-based.