[Feature request] A server-safe way for a dev backend to create or adopt an EconomyOS agent wallet
Context
We're building Open Agent Wallet (https://github.com/Abelhubprog/open-agent-wallet) — a vendor-neutral, open (Apache-2.0) standard + reference implementation for AI agents as autonomous economic actors. We want devs to make the EconomyOS agent wallet (native spending caps, agentmail, Stripe card, ACP identity, tokenization, DegenClaw, compute credits) the default for their users — not only for portal-created ones.
What we verified (so we're precise): the ACP v3 client surface we operate against exposes verify_identity, signer_status, verify_authority_proof, create_job / fund_job / complete_job, and the dgclaw_* family — but no create_agent / create_agent_wallet. Creation is the owner/portal flow (app.virtuals.io/acp/new). So today a third-party backend can link and operate an existing agent (we call this Mode B, gated on ownership proof — verify_identity ≠ ownership), but it cannot provision an EconomyOS wallet for a new user. That's the one gap blocking "use Virtuals wallet infrastructure" for the whole developer base.
We are not claiming Virtuals can't support this — only that no server-safe creation surface is documented. This issue asks for one.
Ask 1 (cleanest) — register an external (Privy) wallet into EconomyOS [Mode D]
POST /v1/economyos/agents/register-wallet
{ "owner_user_ref": "...", "wallet": { "provider":"privy","address":"0x...","proof":{...} },
"consent": {...}, "idempotency_key": "..." }
→ { "agent_id": "...", "capabilities": { "agentmail": true, "card": "...", "acp_identity": "..." } }Because EconomyOS already runs on Privy, adopting a Privy agent wallet means the signer substrate is unchanged — you wrap caps/agentmail/card/ACP around a wallet the dev already controls. No new signer infra, no migration, no fund-shuffling. This instantly makes every dev's existing Mode-A wallet an EconomyOS wallet.
Ask 2 — server-safe, consented headless create [Mode C]
POST /v1/economyos/agents
{ "owner_user_ref":"...", "consent":{ "type":"signed_consent_token|oauth_grant","value":"..." },
"policy":{...}, "chains":["base","solana","arc","arbitrum","polygon"], "idempotency_key":"..." }
→ { "agent_id":"...", "wallet_address":"...", "signer_status":"...", "capabilities":{...} }Gate behind a dev API key + an explicit user-consent token (so it's "headless for the dev, consented by the user"), default to conservative fail-closed policy, and keep high-trust actions (raising caps, card issuance) on the owner/portal path.
Ask 3 — ACP execution with an external signer (IEvmProviderAdapter)
Let ACP/DegenClaw execute with signatures from the dev's agent-wallet signer via a documented callback, with no raw key handed to Virtuals. This makes Mode B → real execution possible without custody transfer.
Ask 4 — chain coverage beyond Base/Solana/ARC (or a documented bridge contract) so agents can settle on Arbitrum/Polygon/etc. under one EconomyOS wallet.
What we contribute back
- Open-source
@oaw/adapter-virtualsthat already wraps the verified ACP surface, withregisterExternalWallet(Mode D) andcreateManagedAgentWallet(Mode C) stubbed and ready to light up the moment these ship. - Our ownership-proof model (
verify_identity≠ ownership) as a reference for safe linking, plus a conformance suite (no-secrets, ACP-native gating, idempotency).
Minimal viable subset: if only one ships, Ask 1 (register external wallet) — no new signer infra and the biggest unlock. Happy to pair on the API shape. — Abelhubprog · Open Agent Wallet