08 — Proposal to Privy

Framing: Privy already ships everything needed to be the default wallet substrate for autonomous agents — auth, embedded wallets, server wallets, server-wallet-v2 (agent wallets), and the chain-agnostic deposit address (useDepositAddress). This proposal does not ask Privy to build an agent framework. It asks for a few targeted, additive surfaces that turn "Privy has the pieces" into "Privy is the turnkey agent-economic-actor substrate," and that let OAW's WalletProviderAdapter (Privy) be complete and vendor-neutral.

What Privy already gives us (and OAW relies on)

Privy primitive	OAW usage
Auth (social/email/OAuth)	Ties the human to the agent.
Embedded wallet	User actions (not autonomous).
Server wallet	App treasury building block.
Server wallet v2 / agent wallet	Mode A — the autonomous agent's programmatic, policy-bounded spending authority.
useDepositAddress (chain-agnostic deposit)	Funding Rail 1 — "deposit USDC from any chain → agent wallet."
Policy engine on server/agent wallets	The per-wallet spend caps OAW's policy layer composes with.

Because Virtuals' EconomyOS agent wallets are themselves built on Privy, a Privy agent wallet (Mode A) and a linked Virtuals wallet (Mode B) share a signer substrate. That's the structural reason this whole design is coherent — and the reason a few Privy additions benefit the entire Virtuals ecosystem too.

---

Proposal P1 — First-class "agent wallet" capability descriptor

Ask: expose a non-secret, machine-readable capability descriptor for a server-v2/agent wallet:

{
  "wallet_id": "…",
  "kind": "agent_wallet",
  "controller": "backend_authorization_key",
  "supported_chains": ["eip155:8453","eip155:42161","eip155:137","solana:…", …],
  "policy": {
    "spend_caps": [{ "asset": "USDC", "per_tx": "100", "daily": "500" }],
    "allowed_methods": ["eth_signTypedData_v4","eth_sendTransaction"],
    "allowed_destinations": ["…"]      // optional allowlist
  },
  "signer_status": "ready|pending|required"
}

Why: OAW's agent_authority block (06) and the funding router both need to know which chains this wallet can sign for and what policy already binds it — without holding secrets. Today this has to be inferred. A descriptor makes the adapter's capabilities() and executionRoute() exact.

Proposal P2 — useDepositAddress for agent/server wallets as a destination, server-side

Ask: make the chain-agnostic deposit address flow usable with a server/agent wallet as the destination, callable server-side (not only via the React hook), returning the generated per-source-chain deposit addresses + the bridge/swap quote.

POST /v1/wallets/{agent_wallet_id}/deposit-address
  { "source_chains": ["eip155:1","eip155:56","solana:…"], "asset": "USDC" }
→ { "addresses": [{ "chain": "...", "address": "..." }], "destination_chain": "...", "estimated": {...} }

Why: the agent is funded by a backend, not a user clicking a hook in a browser. OAW's funding Rail 1 needs to generate deposit addresses headlessly so the agent can say "send USDC anywhere to fund me" from chat. This is the single highest-value addition for agentic funding.

Proposal P3 — Programmatic policy mutation with audit

Ask: a server API to read/update an agent wallet's spend policy (caps, allowlists, autonomy thresholds) with an audit trail and idempotency.

PATCH /v1/wallets/{agent_wallet_id}/policy
  { "spend_caps": [{ "asset":"USDC","daily":"250" }], "idempotency_key": "…" }

Why: "change my daily cap to $250" is a core agentic-commerce command (01). Policy must be a backend-enforced object, not a UI setting. OAW composes per-wallet policy (Privy) with per-venue policy and global spend caps; a clean mutation API makes the wallet-level layer first-class.

Proposal P4 — Signed-action receipts / webhooks

Ask: emit a signed, verifiable receipt (and webhook) for every agent-wallet signing/transfer action: { wallet_id, action, chain, tx_hash, policy_decision, timestamp, signature }.

Why: OAW's economic-action ledger (06 A.5) requires every action to be attributable and tamper-evident. A provider-signed receipt lets a dev prove "the agent did X under policy Y" without trusting their own logs — important for autonomous money movement and for the security model (a prior Betvax incident was settlement-proof forgery; provider-signed receipts close that class).

Proposal P5 — CAIP-2 chain coverage parity

Ask: document and, where possible, expand server/agent-wallet + deposit-address support across the CAIP-2 set devs are targeting:

Abstract eip155:2741 · Arbitrum eip155:42161 · Base eip155:8453 · BNB eip155:56
Ethereum eip155:1 · HyperEVM eip155:999 · Hypercore eip155:1337 · Monad eip155:143
Optimism eip155:10 · Polygon eip155:137 · Solana solana:5eykt… · Tron tron:20191129
Tempo · ARC

Why: this is the exact gap OAW exists to close — agents shouldn't be limited to Virtuals' Base/Solana/ARC. Privy as the cross-chain substrate (with venues settling on Arbitrum/Polygon/etc.) is what makes "any chain in, venue-native chain out" real.

---

What OAW contributes back

• A reference @oaw/adapter-privy implementing WalletProviderAdapter (07) against these surfaces — open source, Apache-2.0/MIT.
• A reference funding router wiring useDepositAddress as Rail 1.
• A conformance test suite (Mode A create/load idempotency, no-secrets, policy enforcement, deposit-address routing) Privy can run against changes.

Minimal viable subset

If only one thing ships: P2 (server-side deposit-address for agent wallets). It unlocks headless cross-chain funding for every agent, which is the piece devs cannot easily build themselves. P1 and P4 are the next most valuable.