Virtuals Protocol
Virtuals Protocol — справочная карточка криптопроекта: что делает продукт и насколько проверяемы ключевые утверждения проекта; также — соответствие тезису Decentralized AI (DecAI Fit).
Virtuals Protocol — AI/Agents | Infra протокол для экономики AI‑агентов (Agent Commerce Protocol / ACP) и токенизации агент‑токенов; токен: VIRTUAL.
Дисклеймер
Важно: эта страница — справочный разбор проекта. В рамках DecAIHub отдельно фиксируется проверка сведений из открытых источников по AI‑тезису (что реально AI/onchain/зачем токен и на каких источниках это основано).
Это не является финансовой рекомендацией и не является советом покупать/продавать/держать актив. Мы не оцениваем цену, доходность, тайминг входа/выхода.
Выводы основаны на публично доступных материалах, обнаруженных на дату проверки. Отсутствие подтверждения не означает отсутствие технологии.
TL;DR (для тех, кто не про ИИ)
- Что это: протокол и инфраструктура для “agent‑to‑agent commerce”: сделки между автономными агентами с escrow и аудит‑трейлом.
- Для кого: разработчики AI‑агентов/продуктов и пользователи, которые покупают услуги/инференсы у агентов.
- Зачем ончейн/токен: ончейн нужен для escrow/подписанных соглашений/аудита; VIRTUAL используется как базовый актив и валюта платежей (в т.ч. per‑inference).
- Что можно потрогать (Tier‑1): публичный портал
app.virtuals.ioи dev‑документация/SDK по Agent Commerce Protocol (ACP) с примерами job‑workflow.
Как это работает (очень кратко)
- Пользователь делает: выбирает агента‑провайдера и инициирует job (заказ услуги/действия).
- Система делает: создаёт onchain Job‑контракт (state machine), фиксирует мемо‑сообщения/подписи, держит оплату в escrow.
- Пользователь получает: проверяемую сделку и автоматическую выплату провайдеру после подтверждения deliverable.
- Где блокчейн: Job contracts, escrow, фазы workflow и аудит‑трейл действий/подписей.
- Роль токена (если есть): VIRTUAL — базовый актив для agent‑токенов и платежей (в т.ч. per‑inference payments).
Быстрые ссылки: AI‑соответствие
Паспорт проекта
| Поле | Значение |
|---|---|
| Название проекта | Virtuals Protocol |
| Также известен как (aliases) | Virtuals, VIRTUAL |
| Лого (logo) | ../assets/8_virtual-protocol_logo.ico |
| Символ токена (ticker) | VIRTUAL |
| Категория | AI/Agents | Infra |
| Основная сеть (chain) | Base |
| Тип | EVM |
| Статус сети | mainnet |
| Консенсус (consensus) | — |
| Дата запуска (launch_date) | — |
| Статус проекта (status) | active |
| Токен (стандарт) | ERC-20 |
| Контракт токена | 0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b |
| Модель токена (token_type) | utility (payments + governance) |
| Макс. предложение | 1,000,000,000 |
| Эмиссия | fixed (no future inflation) |
| Токеномика (tokenomics, кратко) | VIRTUAL — base asset для agent‑токенов и routing currency; используется для onchain платежей за AI‑инференсы. |
| Управление | DAO (veVIRTUAL holders) |
| Админы/ключи | multisig (DAO‑controlled treasury) |
| Аудит | yes |
| Bug bounty | yes |
| Команда (team) | — |
| Финансирование (investors/funding) | — |
| AI‑компонент (ai_component) | autonomous AI agents + ACP escrow |
| Use‑case (use_case) | on-chain transactions between AI agents |
| DecAI Fit — AI‑соответствие (AI thesis fit) | 5/6 — высокое соответствие тезису Decentralized AI |
| Итог по компонентам DecAI Fit | ai_score 2 / onchain_score 3 / token_score 2 / evidence_score 3 |
| Last verified | 2026-02-10 |
Ссылки (links_*)
| Тип | Ссылка |
|---|---|
| Website | https://www.virtuals.io/ |
| Docs | https://whitepaper.virtuals.io/ |
| GitHub | https://github.com/Virtual-Protocol |
| Releases / Changelog | https://whitepaper.virtuals.io/acp-product-resources/acp-changelogs |
| Whitepaper | https://whitepaper.virtuals.io |
| Roadmap | https://x.com/virtuals_io/status/1899838132343972019 |
| Security advisories | https://whitepaper.virtuals.io/info-hub/builders-hub/security-policy-responsible-disclosure |
| Explorer | https://basescan.org/token/0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b |
| X | https://twitter.com/virtuals_io |
| Discord | https://discord.gg/virtualsio |
| Telegram | https://t.me/virtuals |
| Medium | — |
| Audit report(s) | https://whitepaper.virtuals.io/info-hub/security/security-audit-reports |
| Bug bounty | https://whitepaper.virtuals.io/info-hub/builders-hub/security-policy-responsible-disclosure |
| App / Demo | https://app.virtuals.io/ |
| CoinGecko (профиль, справочно) | https://www.coingecko.com/en/coins/virtual-protocol |
| CoinMarketCap (профиль, справочно) | https://coinmarketcap.com/currencies/virtual-protocol/ |
Общее описание проекта
Virtuals Protocol описывает себя как инфраструктуру для экономики автономных AI‑агентов: агенты могут публиковать “job offerings”, принимать заказы, договариваться об условиях и проводить расчёты так, чтобы стороны не доверяли друг другу и не нуждались в централизованном посреднике.
Ключевой элемент — Agent Commerce Protocol (ACP): он описывает onchain job‑контракты как state machine с escrow и криптографически подписанными мемо‑сообщениями. Это делает сделки между агентами проверяемыми и аудируемыми “по цепочке”.
Фичи/модули
- ACP Job contracts: escrow + фазы workflow (Request → Negotiation → Transaction → Evaluation → Completed).
- Agent Registry / Job Factory: реестр агентов и фабрика деплоя job‑контрактов (описано в ACP документации).
- Tokenization/Launch system: токенизация агент‑проектов и распределения/airdrops (описано в FAQ).
Типичные сценарии
- Сценарий 1: buyer‑агент инициирует job у provider‑агента → оплата в escrow → deliverable → автоматический release средств.
- Сценарий 2: пользователь покупает agent‑токены через routing через VIRTUAL → создаётся спрос на VIRTUAL как base asset.
- Сценарий 3: участник стейкает/локает VIRTUAL (veVIRTUAL) → участвует в governance и решениях по протоколу/трежери.
- Сценарий 4 (demo/дев‑поток): разработчик использует ACP/SDK и UI‑портал, чтобы завести агента и прогнать job‑сделку через onchain state machine (escrow → подтверждение результата → выплата).
Как начать (кошелёк/сеть)
- Что нужно: EVM‑кошелёк и доступ к Base (для основной версии токена/активности).
- Сеть/chain: Base.
- Комиссии: комиссии сети Base при ончейн‑операциях (создание job, переводы токенов и т.п.).
Архитектура/техника (без AI)
- Компоненты: Agent Registry, Job Factory, Job contracts (state machine + escrow), memo system (подписанные сообщения), SDK‑слой для интеграции.
- Роли участников: buyer‑агент (client), provider‑агент (seller), evaluator (опционально), пользователи/разработчики, участники governance (veVIRTUAL).
- Где выполняется логика: ключевая логика сделки — onchain (job/escrow/аудит‑трейл); прикладная логика агентов — offchain, но с onchain‑подписями/состоянием.
- Зависимости: Base/EVM, блок‑эксплореры, кошельки, SDK.
Токен/экономика (развернуто, без прогнозов)
- Утилити токена: VIRTUAL — base asset для agent‑токенов (liquidity pairing) и routing currency; также заявлены per‑inference payments в VIRTUAL (Tier‑1).
- Источники необходимости: создание агента требует VIRTUAL для создания LP; платежи/свапы агент‑токенов проходят через VIRTUAL; governance через veVIRTUAL.
- Кто платит комиссии: пользователи сети (gas) и пользователи, которые оплачивают агент‑сервисы/инференсы.
- Куда идут комиссии: escrow‑платежи идут провайдерам после подтверждения deliverable; трежери/распределения зависят от governance.
- Эмиссия/сжигание: total supply 1,000,000,000 “minted without any future inflation”; речь про распределение, а не про инфляцию (Tier‑1).
- Механизмы безопасности/стимулов: veVIRTUAL как механизм голоса; трежери в DAO‑controlled multisig; ограничение “не более 10% emission/год” для трежери (в пределах 3 лет) — как правило распределения (Tier‑1).
- Распределение: 60% public, 5% liquidity pool, 35% ecosystem treasury (Tier‑1).
- Казначейство: ecosystem allocation находится в DAO‑controlled multi‑sig и расходуется по governance approval (Tier‑1).
Управление
- Кто принимает решения: veVIRTUAL holders.
- Как меняются параметры протокола: через onchain governance (процедура comment window → snapshot → voting → quorum/execute) в Tier‑1 описании.
- Где обсуждают/принимают решения: governance портал
gov.virtuals.io(ссылка есть в Tier‑1 governance странице). - Ключи/мультисиг: treasury упоминается как DAO‑controlled multi‑sig; состав подписантов и порог подтверждения не зафиксированы в Tier‑1 источниках карточки.
Безопасность и инциденты
- Аудиты: публично заявлены (см. links_* → Audit report(s)).
- Bug bounty: публичная политика disclosure/bug bounty (см. links_*).
- Инциденты: —.
- Модель угроз: риски смарт‑контрактов escrow/registry/factory, риски интеграции агентов и ключей, риски мостов/кросс‑чейн.
Статус проекта и таймлайн
- Текущий статус: mainnet.
- Ключевые релизы/вехи: — (ключевые даты запуска по Tier‑1 источникам карточки не зафиксированы).
- Roadmap: опубликован (см. links_*).
Экосистема/интеграции
- Интеграции: app.virtuals.io, ACP SDK/ресурсы для билдера, ончейн‑контракты/эксплореры.
- Партнёры: —.
- Где реально используется: запуск и токенизация агент‑проектов через Virtuals Launch System и сделки через ACP (Tier‑1 FAQ/доки).
Ai составляющая проекта
- Что здесь реально ИИ? Tier‑1 токеномика прямо говорит про AI‑agent inferences и per‑inference payments; при этом “качество моделей/метрики” в Tier‑1 не представлены (есть лишь ссылка на протокольные метрики через дашборд).
- Что реально onchain? ACP job contracts (escrow + state machine + подписи мемо) и аудит‑трейл транзакций onchain.
- Зачем нужен токен? VIRTUAL используется для платежей (включая per‑inference), как base asset/routing currency и для governance через veVIRTUAL.
- Красные флаги (по найденной информации): AI‑washing — умеренный риск (много про “агентов”, но мало метрик/бенчмарков); onchain‑washing — низкий риск (escrow/state machine onchain); token‑washing — низкий риск (токен встроен в платежи и governance по Tier‑1).
Итог по компонентам DecAI Fit
- DecAI Fit: 5/6 — высокое соответствие тезису Decentralized AI
| Компонент | Уровень | Score |
|---|---|---|
| AI reality | средне | 2 |
| Onchain necessity | высоко | 3 |
| Token necessity | средне | 2 |
| Evidence | Tier‑1 есть | 3 |
Подробнее
AI reality
AI_0 — намерения про AI (roadmap Tier‑1) (1/0)
- AI_0 (decision): 0
- Claim (1 строка): Tier‑1 “намерение” отдельно не требуется: в Tier‑1 уже есть заявление о реальном использовании AI‑агентов (AI_1).
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
- Why sufficient / why not (1 строка): Здесь есть прямое описание AI‑агент‑инференсов, поэтому intent‑флаг не используется как единственное основание.
- Conflict note (если есть): —
AI_1 — что делает ИИ (1/0)
- AI_1 (decision): 1
- Claim (1 строка): В документации заявлено, что пользователи платят за AI‑agent inferences “per‑use basis” (onchain платежи в VIRTUAL).
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
- Why sufficient / why not (1 строка): Это Tier‑1 описание конкретной AI‑операции (инференс) и факта оплаты за неё.
- Conflict note (если есть): —
AI_2 — демо/примеры (1/0)
- AI_2 (decision): 1
- Claim (1 строка): есть Tier‑1 “demo surface”: официальный app‑портал с перечнем AI‑агентов + dev‑гайд/SDK для симуляции и взаимодействия с агентами.
- 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 (1 строка): Tier‑1 даёт воспроизводимый способ “попробовать/симулировать” агент‑взаимодействие (без метрик качества → AI_3 остаётся 0).
- Conflict note (если есть): —
AI_3 — метрики/качество (1/0)
- AI_3 (decision): 0
- Метрики: —
- Контекст (версия/дата/на чём мерили): —
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/
- Why sufficient / why not (1 строка): Tier‑1 метрик качества AI‑агентов/моделей не найдено (в Tier‑1 есть лишь ссылка на dashboard с протокольными метриками).
- Conflict note (если есть): —
AI_4 — техописание/архитектура/версии (1/0)
- AI_4 (decision): 0
- Claim (1 строка): Tier‑1 описывает протокол ACP (архитектура сделок), но не фиксирует версии/архитектуру AI‑моделей.
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture
- Why sufficient / why not (1 строка): Это техописание onchain протокола, а не AI‑модели/версий.
- Conflict note (если есть): —
Onchain necessity
OC_1 — контракты/адреса/сеть (1/0)
- OC_1 (decision): 1
- Сеть: Base (EVM)
- Адреса/идентификаторы: VIRTUAL token contract
0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b - Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics ; https://basescan.org/token/0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b
- Why sufficient / why not (1 строка): Tier‑1 docs публикуют адреса токена, а блок‑эксплорер даёт проверяемый onchain‑артефакт.
- Conflict note (если есть): —
OC_2 — onchain не только токен (1/0)
- OC_2 (decision): 1
- Какая полезная логика onchain: ACP Job contracts: escrow, state machine workflow, onchain memos/подписи и аудит‑трейл.
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture
- Why sufficient / why not (1 строка): В Tier‑1 описаны конкретные onchain‑контракты/состояния, которые обеспечивают trustless сделки между агентами.
- Conflict note (если есть): —
OC_3 — onchain критичен (1/0)
- OC_3 (decision): 1
- Тест “замены блокчейна”: без ончейна теряются trustless escrow, неизменяемый аудит‑трейл и проверяемость фаз сделки/подписей между незнакомыми агентами.
- 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 (1 строка): Tier‑1 прямо описывает доверие “через смарт‑контракт escrow + криптографическую верификацию”, что и является аргументом критичности ончейна.
- Conflict note (если есть): —
Token necessity
TK_0 — токена нет (1/0)
- TK_0 (decision): 0
- Claim (1 строка): В проекте есть токен VIRTUAL.
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
- Why sufficient / why not (1 строка): Tier‑1 страница токеномики описывает токен и адреса.
- Conflict note (если есть): —
TK_1..TK_4 (1/0)
TK_1 — платёж за сервис (1/0)
- TK_1 (decision): 1
- Claim (1 строка): Платежи за AI‑agent inferences описаны как onchain “per‑use” и выполняются в VIRTUAL.
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics
- Why sufficient / why not (1 строка): Это прямое Tier‑1 утверждение про оплату сервиса токеном.
- Conflict note (если есть): —
TK_2 — стимулы/залоги/штрафы (1/0)
- TK_2 (decision): 0
- Claim (1 строка): Tier‑1 не фиксирует slashing/штрафные механизмы на уровне протокола; lock/staking используется для governance (TK_3).
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
- Why sufficient / why not (1 строка): Наличие veVIRTUAL описано как governance‑механизм, но без штрафной модели.
- Conflict note (если есть): —
TK_3 — управление (1/0)
- TK_3 (decision): 1
- Claim (1 строка): Протокол управляется veVIRTUAL holders, описаны правила proposal/voting/quorum.
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
- Why sufficient / why not (1 строка): Tier‑1 страница governance описывает, как veVIRTUAL даёт voting power и как принимаются решения.
- Conflict note (если есть): —
TK_4 — токен заменим (1/0)
- TK_4 (decision): 0
- Claim (1 строка): Токен встроен в base‑asset/routing‑механику и governance (veVIRTUAL), поэтому “простая замена” не следует из Tier‑1.
- Evidence: Tier‑1 — https://whitepaper.virtuals.io/usdvirtual-tokenomics ; https://whitepaper.virtuals.io/info-hub/usdvirtual/governance
- Why sufficient / why not (1 строка): Tier‑1 описывает конкретные роли VIRTUAL в протоколе (routing/payments + governance).
- Conflict note (если есть): —
Evidence (таблица)
| Tier | Источник | Что доказывает |
|---|---|---|
| Tier‑1 | https://whitepaper.virtuals.io/usdvirtual-tokenomics | Роль токена: base asset/routing currency и per‑inference payments в VIRTUAL; адреса токена на Base/ETH/Solana. |
| Tier‑1 | https://whitepaper.virtuals.io/info-hub/usdvirtual/token-distribution | Max supply 1,000,000,000 и “minted without any future inflation”; распределение 60/5/35 и treasury‑правила. |
| Tier‑1 | https://whitepaper.virtuals.io/acp-product-resources/acp-concepts-terminologies-and-architecture | ACP: onchain job contracts (state machine) + escrow + memos/подписи + onchain auditability. |
| Tier‑1 | https://whitepaper.virtuals.io/about-virtuals/agent-commerce-protocol-acp | Зачем стандарт: trustless escrow и криптографическая проверка соглашений для agent‑commerce. |
| Tier‑1 | https://whitepaper.virtuals.io/info-hub/usdvirtual/governance | Governance через veVIRTUAL: правила proposal/snapshot/voting/quorum. |
| Tier‑1 | https://basescan.org/token/0x0b3e328455c4059EEb9e3f84b5543F74E24e7E1b | Onchain‑факт: контракт токена VIRTUAL на Base (проверяемость). |
| Tier‑1 | https://app.virtuals.io/ | Публичный app‑портал/витрина агентов (demo surface) и базовые сценарии взаимодействия. |
| Tier‑1 | https://whitepaper.virtuals.io/acp-product-resources/acp-dev-onboarding-guide/customize-agent/simulate-agent-with-code/acp-sdk | Dev‑документация: SDK для симуляции/интеграции и взаимодействия с агентами (пример воспроизводимого теста). |
| Tier‑1 | https://whitepaper.virtuals.io/info-hub/protocol-metrics | Tier‑1: ссылка на dashboard протокольных метрик (Dune) проекта. |
| Tier‑2 | — | — |
| Tier‑3 | — | — |
No comments to display
No comments to display