Skip to main content

Virtuals Protocol

Virtuals Protocol — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Virtuals Protocol — an AI/Agents | Infra protocol for the economy of AI agents (Agent Commerce Protocol / ACP) and the tokenization of agent tokens; token: VIRTUAL.

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: a protocol and infrastructure for “agent‑to‑agent commerce”: deals between autonomous agents with escrow and an audit trail.
  • Who it’s for: developers of AI agents/products and users who buy services/inferences from agents.
  • Why onchain/token: onchain is needed for escrow/signed agreements/auditing; VIRTUAL is used as the base asset and payment currency (including per‑inference).
  • What you can actually touch (Tier‑1): the public portal app.virtuals.io and the dev documentation/SDK for the Agent Commerce Protocol (ACP) with job‑workflow examples.

How it works (very briefly)

  1. The user does: selects a provider agent and initiates a job (an order for a service/action).
  2. The system does: creates an onchain Job contract (state machine), records memo messages/signatures, holds the payment in escrow.
  3. The user gets: a verifiable deal and an automatic payout to the provider after the deliverable is confirmed.
  4. Where the blockchain is: Job contracts, escrow, workflow phases and the audit trail of actions/signatures.
  5. Token role (if any): VIRTUAL — the base asset for agent tokens and payments (including per‑inference payments).

Quick links: AI thesis fit

Project passport

Field Value
Project name Virtuals Protocol
Also known as (aliases) Virtuals, VIRTUAL
Logo (logo) ../assets/8_virtual-protocol_logo.ico
Token symbol (ticker) VIRTUAL
Category AI/Agents | Infra
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b
Token model (token_type) utility (payments + governance)
Max supply 1,000,000,000
Issuance fixed (no future inflation)
Tokenomics (tokenomics, brief) VIRTUAL — the base asset for agent tokens and the routing currency; used for onchain payments for AI inferences.
Governance DAO (veVIRTUAL holders)
Admins/keys multisig (DAO‑controlled treasury)
Audit yes
Bug bounty yes
Team (team) —
Funding (investors/funding) —
AI component (ai_component) autonomous AI agents + ACP escrow
Use‑case (use_case) on-chain transactions between AI agents
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 2 / onchain_score 3 / token_score 2 / evidence_score 3
Last verified 2026-02-10

General project overview

Virtuals Protocol describes itself as infrastructure for the economy of autonomous AI agents: agents can publish “job offerings”, accept orders, negotiate terms and settle so that the parties do not need to trust each other and do not need a centralized intermediary.

The key element is the Agent Commerce Protocol (ACP): it describes onchain job contracts as a state machine with escrow and cryptographically signed memo messages. This makes deals between agents verifiable and auditable “along the chain”.

Features/modules

  • ACP Job contracts: escrow + workflow phases (Request → Negotiation → Transaction → Evaluation → Completed).
  • Agent Registry / Job Factory: the agent registry and the factory for deploying job contracts (described in the ACP documentation).
  • Tokenization/Launch system: tokenization of agent projects and distributions/airdrops (described in the FAQ).

Typical scenarios

  • Scenario 1: a buyer agent initiates a job with a provider agent → payment goes into escrow → deliverable → automatic release of funds.
  • Scenario 2: a user buys agent tokens via routing through VIRTUAL → demand for VIRTUAL as the base asset is created.
  • Scenario 3: a participant stakes/locks VIRTUAL (veVIRTUAL) → participates in governance and decisions on the protocol/treasury.
  • Scenario 4 (demo/dev flow): a developer uses the ACP/SDK and the UI portal to set up an agent and run a job deal through the onchain state machine (escrow → result confirmation → payout).

Getting started (wallet/network)

  • What you need: an EVM wallet and access to Base (for the main version of the token/activity).
  • Network/chain: Base.
  • Fees: Base network fees for onchain operations (job creation, token transfers, etc.).

Architecture/tech (non‑AI)

  • Components: Agent Registry, Job Factory, Job contracts (state machine + escrow), memo system (signed messages), an SDK layer for integration.
  • Participant roles: buyer agent (client), provider agent (seller), evaluator (optional), users/developers, governance participants (veVIRTUAL).
  • Where logic runs: the key deal logic — onchain (job/escrow/audit trail); the application logic of agents — offchain, but with onchain signatures/state.
  • Dependencies: Base/EVM, block explorers, wallets, SDK.

Token/economics (expanded, no forecasts)

  • Token utility: VIRTUAL — the base asset for agent tokens (liquidity pairing) and the routing currency; per‑inference payments in VIRTUAL are also stated (Tier‑1).
  • Protocol necessity drivers: creating an agent requires VIRTUAL to create an LP; payments/swaps of agent tokens go through VIRTUAL; governance via veVIRTUAL.
  • Who pays fees: network users (gas) and users who pay for agent services/inferences.
  • Where fees go: escrow payments go to providers after the deliverable is confirmed; treasury/distributions depend on governance.
  • Issuance/burn: total supply 1,000,000,000 “minted without any future inflation”; this is about distribution, not inflation (Tier‑1).
  • Security/incentive mechanisms: veVIRTUAL as the voting mechanism; the treasury in a DAO‑controlled multisig; a limit of “no more than 10% emission/year” for the treasury (within 3 years) — as a distribution rule (Tier‑1).
  • Distribution: 60% public, 5% liquidity pool, 35% ecosystem treasury (Tier‑1).
  • Treasury: the ecosystem allocation is held in a DAO‑controlled multi‑sig and is spent upon governance approval (Tier‑1).

Governance

  • Who makes decisions: veVIRTUAL holders.
  • How protocol parameters change: via onchain governance (the procedure comment window → snapshot → voting → quorum/execute) in the Tier‑1 description.
  • Where decisions are discussed/made: the governance portal gov.virtuals.io (the link is on the Tier‑1 governance page).
  • Keys/multisig: the treasury is mentioned as a DAO‑controlled multi‑sig; the set of signers and the confirmation threshold are not recorded in the card’s Tier‑1 sources.

Security and incidents

  • Audits: publicly stated (see links_* → Audit report(s)).
  • Bug bounty: a public disclosure/bug bounty policy (see links_*).
  • Incidents: —.
  • Threat model: smart‑contract risks of escrow/registry/factory, risks of agent and key integration, bridge/cross‑chain risks.

Project status and timeline

  • Current status: mainnet.
  • Key releases/milestones: — (key launch dates are not recorded in the card’s Tier‑1 sources).
  • Roadmap: published (see links_*).

Ecosystem/integrations

  • Integrations: app.virtuals.io, ACP SDK/builder resources, onchain contracts/explorers.
  • Partners: —.
  • Where it’s actually used: launching and tokenizing agent projects via the Virtuals Launch System and deals via ACP (Tier‑1 FAQ/docs).

AI component of the project

  • What is real AI here? The Tier‑1 tokenomics directly speaks of AI‑agent inferences and per‑inference payments; at the same time, “model quality/metrics” are not presented in Tier‑1 (there is only a link to protocol metrics via a dashboard).
  • What is truly onchain? ACP job contracts (escrow + state machine + memo signatures) and the audit trail of transactions onchain.
  • Why is a token needed? VIRTUAL is used for payments (including per‑inference), as the base asset/routing currency and for governance via veVIRTUAL.
  • Red flags (based on the information found): AI‑washing — moderate risk (a lot about “agents”, but few metrics/benchmarks); onchain‑washing — low risk (escrow/state machine onchain); token‑washing — low risk (the token is embedded in payments and governance per Tier‑1).

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity high 3
Token necessity medium 2
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): A separate Tier‑1 “intent” is not required: Tier‑1 already contains a statement about the actual use of AI agents (AI_1).
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
  • Why sufficient / why not (one line): There is a direct description of AI‑agent inferences here, so the intent flag is not used as the sole basis.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): The documentation states that users pay for AI‑agent inferences on a “per‑use basis” (onchain payments in VIRTUAL).
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
  • Why sufficient / why not (one line): This is a Tier‑1 description of a specific AI operation (inference) and of the fact of payment for it.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there is a Tier‑1 “demo surface”: the official app portal with a list of AI agents + a dev guide/SDK for simulating and interacting with agents.
  • Evidence: Tier‑1 — https://app.virtuals.io/, https://whitepaper.virtuals.io/acp-product-resources/acp-dev-onboarding-guide/customize-agent/simulate-agent-with-code/acp-sdk
  • Why sufficient / why not (one line): Tier‑1 provides a reproducible way to “try/simulate” agent interaction (without quality metrics → AI_3 remains 0).
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/
  • Why sufficient / why not (one line): No Tier‑1 quality metrics for AI agents/models were found (Tier‑1 only contains a link to a dashboard with protocol metrics).
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): Tier‑1 describes the ACP protocol (deal architecture) but does not record versions/architecture of AI models.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture
  • Why sufficient / why not (one line): This is a technical description of the onchain protocol, not of an AI model/versions.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Base (EVM)
  • Addresses/identifiers: VIRTUAL token contract 0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics ; https://basescan.org/token/0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b
  • Why sufficient / why not (one line): Tier‑1 docs publish the token addresses, and the block explorer provides a verifiable onchain artifact.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: ACP Job contracts: escrow, state machine workflow, onchain memos/signatures and the audit trail.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture
  • Why sufficient / why not (one line): Tier‑1 describes specific onchain contracts/states that enable trustless deals between agents.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without onchain, trustless escrow, the immutable audit trail and the verifiability of deal phases/signatures between unfamiliar agents are lost.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/about-virtuals/agent-commerce-protocol-acp ; https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture
  • Why sufficient / why not (one line): Tier‑1 directly describes trust “via a smart‑contract escrow + cryptographic verification”, which is precisely the argument for the criticality of onchain.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, VIRTUAL.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
  • Why sufficient / why not (one line): The Tier‑1 tokenomics page describes the token and the addresses.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): Payments for AI‑agent inferences are described as onchain “per‑use” and are made in VIRTUAL.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
  • Why sufficient / why not (one line): This is a direct Tier‑1 statement about paying for the service with the token.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 0
  • Claim (one line): Tier‑1 does not record slashing/penalty mechanisms at the protocol level; lock/staking is used for governance (TK_3).
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
  • Why sufficient / why not (one line): The existence of veVIRTUAL is described as a governance mechanism, but without a penalty model.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): The protocol is governed by veVIRTUAL holders; the proposal/voting/quorum rules are described.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
  • Why sufficient / why not (one line): The Tier‑1 governance page describes how veVIRTUAL grants voting power and how decisions are made.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The token is embedded in the base‑asset/routing mechanics and governance (veVIRTUAL), so a “simple replacement” does not follow from Tier‑1.
  • Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics ; https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
  • Why sufficient / why not (one line): Tier‑1 describes specific roles of VIRTUAL in the protocol (routing/payments + governance).
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://whitepaper.virtuals.io/usdvirtual-tokenomics Token role: base asset/routing currency and per‑inference payments in VIRTUAL; token addresses on Base/ETH/Solana.
Tier‑1 https://whitepaper.virtuals.io/info-hub/usdvirtual/token-distribution Max supply 1,000,000,000 and “minted without any future inflation”; the 60/5/35 distribution and treasury rules.
Tier‑1 https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture ACP: onchain job contracts (state machine) + escrow + memos/signatures + onchain auditability.
Tier‑1 https://whitepaper.virtuals.io/about-virtuals/agent-commerce-protocol-acp Why the standard exists: trustless escrow and cryptographic verification of agreements for agent‑commerce.
Tier‑1 https://whitepaper.virtuals.io/info-hub/usdvirtual/governance Governance via veVIRTUAL: proposal/snapshot/voting/quorum rules.
Tier‑1 https://basescan.org/token/0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b Onchain fact: the VIRTUAL token contract on Base (verifiability).
Tier‑1 https://app.virtuals.io/ The public app portal/agent showcase (demo surface) and basic interaction scenarios.
Tier‑1 https://whitepaper.virtuals.io/acp-product-resources/acp-dev-onboarding-guide/customize-agent/simulate-agent-with-code/acp-sdk Dev documentation: an SDK for simulating/integrating and interacting with agents (an example of a reproducible test).
Tier‑1 https://whitepaper.virtuals.io/info-hub/protocol-metrics Tier‑1: a link to the project’s protocol metrics dashboard (Dune).
Tier‑2 — —
Tier‑3 — —

No comments to display

Back to top