Skip to main content

External Agents (ACP & Virtuals)

Virtuals.io is special: it is both a venue/capability and the native EconomyOS / ACP layer. OAW links and operates a user's existing Virtuals agent (Mode B) and routes ACP-native execution through the sidecar.

The verified ACP surface​

The ACP client OAW operates against exposes:

verify_identity · signer_status · verify_authority_proof · wallet_balance
create_job · create_fund_transfer_job · fund_job · complete_job · reject_job
send_message · submit_deliverable · drain_events · get_job · list_resources
dgclaw_join · dgclaw_activate_unified · dgclaw_add_api_wallet · dgclaw_deposit
dgclaw_withdraw · dgclaw_trade · dgclaw_status · dgclaw_receipts

Note what is absent: there is no create_agent. The client operates an existing agent; it cannot mint one. That is why headless creation is unverified — see Agent authority.

What a linked Virtuals agent unlocks (Mode B)​

A Virtuals agent wallet is a Privy wallet plus an EconomyOS envelope:

  • native spending caps & policies, agentmail, a Stripe-powered card,
  • an ACP identity (marketplace + job lifecycle),
  • tokenization (agent token / launch),
  • DegenClaw / Arena (Virtuals-routed perps/spot via Hyperliquid),
  • compute credits.

OAW inherits these by linking the wallet (ownership-proof), never by re-creating it.

ACP-native execution​

For Virtuals and DegenClaw, OAW requires a linked Virtuals identity + ready signer and routes execution through virtuals_acp_sidecar. Under any other authority, or an unverified one, OAW blocks precisely (virtuals_identity_required, virtuals_signer_required, virtuals_authority_not_verified) — never a silent fallback.

The convergence we propose​

Two upstream asks would let every dev's agent gain the EconomyOS envelope without a portal step:

  • Mode D — register an external (Privy) wallet into EconomyOS (no new signer infra, since EconomyOS already runs on Privy).
  • Mode C — a consented, server-safe headless create.

Both are written up in the Virtuals proposal.