Agent Authority

Everything in OAW hangs off one question: what is the agent's spending authority, and who can create it? There is exactly one active authority per agent, regardless of how many venues it binds or how many chains it touches.

The AgentAuthority object

Provider- and venue-agnostic. It never holds raw key material — only an opaque provider id; the provider adapter resolves signing.

{
  "authoritySource": "provider_managed | virtuals_linked | external_imported",
  "walletProvider":  "privy | virtuals | external",
  "walletAddress":   "0x… | <solana pubkey>",
  "providerWalletId": "opaque-id",        // e.g. privy_agent_wallet_id
  "virtualsAgentId":  "id | null",
  "proofState":      "verified | pending | unverified | not_applicable",
  "signerStatus":    "ready | required | pending | unsupported",
  "supportedChains": ["base","ethereum","arbitrum","polygon","solana"]
}

The decisive question

Can a developer backend create a Virtuals/EconomyOS agent wallet (with its native spending caps, agentmail, Stripe card, ACP identity) headlessly, server-side?

Resolved answer: No verified server-side creation surface exists today. The verified ACP client exposes verify_identity, signer_status, verify_authority_proof, create_job / fund_job / complete_job, and the dgclaw_* family — but no create_agent. It operates an existing agent; it does not mint one. Creation is the app.virtuals.io/acp/new owner/portal flow.

Precise wording

We say "no production-safe server-side creation surface is verified," never "Virtuals cannot do programmatic creation." That door stays open — it is exactly what the Virtuals proposal asks for.

The wallet modes

Mode	authoritySource	Who creates	Inherits Virtuals caps/card/ACP	Status
A	provider_managed	Dev backend, programmatic (Privy)	No	Production
B	virtuals_linked	User, in Virtuals portal → you link it	Yes	Production
C	provider_managed → virtuals	Virtuals server API (consented)	Yes	Unverified — proposal
D	virtuals_linked	Register a Privy wallet into EconomyOS	Yes	Unverified — proposal
E	external_imported	User (own key / capped signer)	No	Scaffolded

Mode A — provider-managed (Privy) agent wallet

Fully programmatic; the autonomous-from-chat default. Any user gets one instantly on explicit bind/setup intent. Missing Virtuals identity is non-fatal for Polymarket, Hyperliquid, etc. Idempotent; no secrets in responses.

Mode B — linked existing Virtuals wallet

The user created the agent on Virtuals.io; OAW links it. Verification is not ownership — verify_identity only proves existence; verify_authority_proof proves control. walletProvider becomes "virtuals" (active authority) only after proof passes. Mode B never provisions a Privy wallet and never silently falls back to Mode A.

Authority integrity rules

• A ready Mode A authority is not overwritten by a Virtuals link unless the switch is explicit and ownership proof passes.
• An unverified virtuals profile blocks rather than degrading to Mode A.
• ACP-native venues (Virtuals, DegenClaw) additionally require a linked Virtuals identity + ready signer; non-ACP venues do not.

Next: Venue binding.