Skip to main content

Vana

Vana (VANA) — справочная карточка криптопроекта: что делает продукт и насколько проверяемы ключевые утверждения проекта; также — соответствие тезису Decentralized AI (DecAI Fit).

Vana — сеть для user‑owned data: пользователи могут объединять данные в DataDAOs, получать “data tokens” за вклад и давать доступ к данным/вычислениям через onchain‑разрешения и защищённое исполнение (TEE). Проект позиционирует это как инфраструктуру для обучения и использования AI на частных данных при сохранении приватности.

Дисклеймер

Важно: эта страница — справочный разбор проекта. В рамках DecAIHub отдельно фиксируется проверка сведений из открытых источников по AI‑тезису (что реально AI/onchain/зачем токен и на каких источниках это основано).
Это не является финансовой рекомендацией и не является советом покупать/продавать/держать актив. Мы не оцениваем цену, доходность, тайминг входа/выхода.
Выводы основаны на публично доступных материалах, обнаруженных на дату проверки. Отсутствие подтверждения не означает отсутствие технологии.

TL;DR (для тех, кто не про ИИ)

  • Что это: сеть и набор контрактов/сервисов, которые превращают вклад данных в “программируемое владение” и даёт доступ к данным через правила/разрешения.
  • Для кого: пользователи‑владельцы данных; DataDAO‑создатели; разработчики/исследователи, которым нужны приватные датасеты для обучения/приложений.
  • Зачем ончейн/токен: onchain хранит доказательства вклада и разрешения доступа; доступ к датасетам требует burn токенов, а выполнение вычислений происходит в TEE с ончейн‑апрувом.
  • Что можно потрогать (Tier‑1): end‑to‑end tutorial “query dataset → submit job → получить artifact” (compute‑workflow в сети).

Как это работает (очень кратко)

  1. Пользователь делает: добавляет данные в DataDAO (через DLP — Data Liquidity Pool) или держит данные у себя (персональный сервер) и выдаёт разрешения.
  2. Система делает: фиксирует права/доступ onchain, а вычисления на приватных данных запускает в защищённой среде (TEE), где данные не раскрываются наружу.
  3. Пользователь получает: VRC‑20 data tokens за вклад + участие в экономике/управлении DataDAO; контроль над тем, кому и на каких условиях доступны данные.
  4. Где блокчейн: standalone EVM‑совместимый L1 для координации доказательств вклада, разрешений доступа и контрактов (без хранения raw data).
  5. Роль токена: VANA используется для комиссий и доступа к данным (burn вместе с data tokens); VRC‑20 токены привязаны к датасетам и тоже “сжигаются” для доступа.
  6. Как выглядит “compute job” на практике (Tier‑1): pre‑deposit в ComputeEngine → submitJob (получаем jobId) → запрос к tee-url API → скачивание результата из artifacts (например query_results.db).

Быстрые ссылки: AI‑соответствие

Паспорт проекта

Поле Значение
Название проекта Vana
Также известен как (aliases) VANA
Лого (logo) ../assets/37_vana_logo.svg
Символ токена (ticker) VANA
Категория AI/Data | Infra
Основная сеть (chain) Vana
Тип EVM
Статус сети mainnet
Консенсус (consensus) —
Дата запуска (launch_date) —
Статус проекта (status) active
Токен (стандарт) native
Контракт токена —
Модель токена (token_type) utility (gas + data access + burn)
Макс. предложение —
Эмиссия —
Токеномика (tokenomics, кратко) доступ к данным требует burn VANA + VRC‑20 data tokens (в документации указано 20%/80%); VRC‑20 зарабатываются вкладом данных
Управление DataDAOs (onchain правила/экономика)
Админы/ключи —
Аудит yes
Bug bounty —
Команда (team) —
Финансирование (investors/funding) —
AI‑компонент (ai_component) user-owned data + TEE compute for AI
Use‑case (use_case) DataDAOs for AI training on private data
DecAI Fit — AI‑соответствие (AI thesis fit) 3/6 — среднее соответствие тезису Decentralized AI
Итог по компонентам DecAI Fit 1 / 3 / 2 / 2
Last verified 2026-02-11
Тип Ссылка
Website https://www.vana.org/
Docs https://docs.vana.org/docs
GitHub https://github.com/vana-com
Releases / Changelog https://docs.vana.org/changelog
Whitepaper https://docs.vana.org/docs/vana-whitepaper
Roadmap https://vana2026roadmap.org/
Security advisories https://docs.vana.org/docs/security
Explorer https://vanascan.io/
App / Demo https://docs.vana.org/docs/tutorial-querying-data-on-vana
X https://twitter.com/vana
Discord https://discord.gg/vanabuilders
Telegram —
Medium —
Audit report(s) https://docs.vana.org/docs/security
Bug bounty —
CoinGecko (профиль, справочно) https://www.coingecko.com/en/coins/vana
CoinMarketCap (профиль, справочно) https://coinmarketcap.com/currencies/vana/

Общее описание проекта

Vana описывает себя как сеть для “programmable data ownership”: данные остаются приватными (шифруются у пользователей/провайдеров хранения), но права владения, доступа и экономика датасетов управляются через onchain‑контракты и учёт вкладов.

Ключевая идея — DataDAOs: коллективы данных с общими правилами валидации, governance и экономики. Пользователи вносят данные в Data Liquidity Pools (DLP), получают dataset‑специфичные VRC‑20 токены и могут зарабатывать, когда разработчики “покупают доступ” (через burn токенов). Чтобы сохранить приватность, вычисления на данных выполняются в TEE (secure compute layer), а onchain используется как “координационный слой” для разрешений и записи результатов/фактов выполнения.

Фичи/модули

  • DataDAOs: governed datasets (правила/экономика/валидация).
  • DLP (Data Liquidity Pool): логика проверки вкладов и permissioning для датасета.
  • VRC‑20 data tokens: токены, “криптографически привязанные” к конкретным датасетам через proof‑of‑contribution.
  • L1 coordination layer: хранит proofs вкладов, access grants и контракты (без raw data).
  • Secure compute layer (TEE): выполняет одобренный код на приватных данных и возвращает результаты, не раскрывая raw data.

Типичные сценарии

  • Сценарий 1 (вклад данных): пользователь добавляет данные в DataDAO → получает VRC‑20 токены → участвует в экономике датасета.
  • Сценарий 2 (запрос к приватному датасету / compute job): разработчик/исследователь получает onchain‑разрешения → (по правилам DataDAO) оплачивает/сжигает VANA + VRC‑20 → регистрирует job в ComputeEngine → выполнение идёт в TEE → получает artifact (например query_results.db), без публикации raw data.
  • Сценарий 3 (персональная суверенность): пользователь хранит данные на персональном сервере → выдаёт onchain‑разрешения на конкретные операции/поля → приложение выполняет разрешённые вычисления без утечки raw data.

Как начать (кошелёк/сеть)

  • Что нужно: EVM‑совместимый кошелёк (идентичность пользователя в Vana завязана на wallet address).
  • Сеть/chain: Vana (EVM‑совместимый L1; explorer — vanascan).
  • Комиссии: gas/fees в нативном VANA (по документации), плюс burn VANA + VRC‑20 для доступа к датасетам.

Архитектура/техника (без AI)

  • Компоненты: DataDAOs (DLP + контракты доступа + VRC‑20) + L1 (координация/реестр/разрешения) + TEE compute layer.
  • Роли участников: data contributors, DataDAO/DLP operators, data/AI builders, validators/инфраструктурные операторы.
  • Где выполняется логика: права/доступ/учёт вкладов — onchain; raw data и исполнение вычислений — offchain в TEE.
  • Зависимости: TEE‑инфраструктура (с GPU/без GPU), offchain storage, wallet‑идентичность.

Токен/экономика (развернуто, без прогнозов)

  • Утилити токенов: VANA — комиссии и компонент доступа к данным; VRC‑20 — dataset‑specific ownership/экономика, сжигаются для доступа.
  • Источники необходимости в протоколе: доступ к данным и запуск compute jobs завязаны на onchain‑апрув и burn токенов; это обеспечивает координацию прав и распределение ценности между вкладчиками.
  • Кто платит комиссии: пользователи сети (gas) и потребители данных (burn VANA+VRC‑20).
  • Куда идут комиссии: — (не установлено по текущим Tier‑1 страницам).
  • Эмиссия/сжигание: в Tier‑1 описан механизм burn для доступа к данным (VANA + VRC‑20; для VANA указан ratio 20%).
  • Механизмы безопасности/стимулов: стимулирование вкладов через VRC‑20; доступ к данным через permissioning и TEE.
  • Распределение и график выпуска токенов: — (не установлено по текущим Tier‑1 страницам).
  • Казначейство: — (не установлено).

Управление

  • Кто принимает решения: DataDAOs (правила/экономика/гранулярные permissions) — onchain механизмы управления.
  • Как меняются параметры протокола: — (не установлено по текущим Tier‑1 страницам).
  • Где обсуждают/принимают решения: —.
  • Ключи/мультисиг: —.

Безопасность и инциденты

  • Аудиты: в документации опубликован список аудитов (Nethermind + Hashlock) для компонентов протокола/контрактов.
  • Bug bounty: — (публичная bug bounty программа Tier‑1 не установлена; есть responsible disclosure, см. Security).
  • Инциденты: — (не установлено).
  • Модель угроз: риски связаны с корректностью TEE/attestation, безопасностью контрактов DataDAO/DLP и корректностью onchain‑permissioning.

Статус проекта и таймлайн

  • Текущий статус: активная разработка и релиз‑ноты в официальной документации; сеть/эксплорер доступны.
  • Ключевые релизы/вехи: см. Release Notes (официальная лента изменений).
  • Roadmap: опубликован “Vana 2026 Roadmap” с фокусами и апгрейдами (Vega Upgrade, data portability).

Экосистема/интеграции

  • Интеграции: кошелёк как identity, DataDAOs/market‑механика, TEE compute.
  • Где реально используется: заявленный use‑case — доступ к приватным датасетам для AI training (на уровне архитектуры и экономических правил).

Ai составляющая проекта

  • Что здесь реально ИИ? В Tier‑1 описан use‑case “AI training on user‑owned/private datasets”, но “собственный AI‑алгоритм/модель проекта” как отдельный артефакт не описан: Vana выступает как data/permissioning + compute‑инфраструктура.
  • Что реально onchain? Ownership/атрибуция вкладов, access grants, контракты DataDAO/DLP и approvals compute jobs фиксируются на standalone EVM‑L1; raw data не хранится onchain.
  • Зачем нужен токен? Для доступа к данным требуется burn VANA и VRC‑20; VANA также используется для комиссий.
  • Красные флаги (по найденной информации): AI‑washing (AI — заявленная область применения; важно отделять “инфраструктура для AI” от “AI‑продукта”), TEE‑trust assumptions (насколько доверяем исполнению/attestation), сложность проверяемости offchain‑частей. Отдельно: текущий Tier‑1 “демо” показывает compute/query workflow, но не доказывает качество/метрики AI‑моделей.

Итог по компонентам DecAI Fit

  • DecAI Fit: 3/6 — среднее соответствие тезису Decentralized AI
Компонент Уровень Score
AI reality средне 1
Onchain necessity высоко 3
Token necessity средне 2
Evidence Tier‑1 есть 2
Подробнее

AI reality

AI_0 — намерения про AI (roadmap Tier‑1) (1/0)

  • AI_0 (decision): 0
  • Claim (1 строка): Есть признаки AI reality по Tier‑1 (см. AI_1..AI_4), поэтому флаг AI_0 (intent‑only) не применяется.
  • Evidence: Tier‑1 — см. Evidence/ссылки в AI_1..AI_4.
  • Why sufficient / why not (1 строка): AI_0=1 допустим только когда AI_1..AI_4=0; здесь ai_score без AI_0 = 1.
  • Conflict note (если есть): —

AI_1 — что делает ИИ (1/0)

  • AI_1 (decision): 0
  • Claim (1 строка): — (не описан конкретный AI‑модуль/модель проекта как работающий компонент).
  • Evidence: Tier‑1 — — | Tier‑1 источник по утверждению “есть конкретный AI‑модуль/модель Vana как продукта” не найден.
  • Why sufficient / why not (1 строка): AI описан как use‑case (инфраструктура), а не как отдельный AI‑компонент.
  • Conflict note (если есть): —

AI_2 — демо/примеры (1/0)

  • AI_2 (decision): 1
  • Claim (1 строка): Tier‑1 docs содержит end‑to‑end tutorial по доступу к датасету и запуску compute job (TEE) для получения query results.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/tutorial-querying-data-on-vana
  • Why sufficient / why not (1 строка): есть воспроизводимый workflow “dataset discovery → permissions → submitJob → artifacts”, но это не метрики качества AI‑модели (AI_3=0).
  • Conflict note (если есть): —

AI_3 — метрики/качество (1/0)

  • AI_3 (decision): 0
  • Метрики: —
  • Контекст (версия/дата/на чём мерили): —
  • Evidence: Tier‑1 — — | Tier‑1 источник по метрикам AI/качества не найден.
  • Why sufficient / why not (1 строка): нет чисел/контекста.
  • Conflict note (если есть): —

AI_4 — техописание/архитектура/версии (1/0)

  • AI_4 (decision): 0
  • Claim (1 строка): — (архитектура описана, но не как “AI‑модель/версия/параметры”).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (1 строка): это техописание инфраструктуры данных/доступа, а не AI‑модели.
  • Conflict note (если есть): —

Onchain necessity

OC_1 — контракты/адреса/сеть (1/0)

  • OC_1 (decision): 1
  • Сеть: Vana (standalone EVM‑compatible L1)
  • Адреса/идентификаторы: explorer vanascan (контракты DataDAO/DLP доступны в эксплорере; конкретные адреса зависят от DataDAO)
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture, https://docs.vana.org/changelog
  • Why sufficient / why not (1 строка): Tier‑1 фиксирует наличие L1/контрактов; релиз‑ноты содержат ссылки на методы/адреса в vanascan.
  • Conflict note (если есть): —

OC_2 — onchain не только токен (1/0)

  • OC_2 (decision): 1
  • Какая полезная логика onchain: access grants, proofs вкладов, approvals compute jobs, реестр прав и смарт‑контракты DataDAOs/DLP.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture, https://docs.vana.org/docs/how-vana-works
  • Why sufficient / why not (1 строка): описан onchain coordination layer и onchain permissions.
  • Conflict note (если есть): —

OC_3 — onchain критичен (1/0)

  • OC_3 (decision): 1
  • Тест “замены блокчейна”: без onchain реестра прав/разрешений и burn‑механики “data tokens” теряется публичная проверяемость ownership/атрибуции и воспроизводимая экономика доступа к данным.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (1 строка): Tier‑1 архитектура строит permissioning/экономику вокруг L1.
  • Conflict note (если есть): —

Token necessity

TK_0 — токена нет (1/0)

  • TK_0 (decision): 0
  • Claim (1 строка): токены VANA и VRC‑20 используются в протоколе.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (1 строка): в Tier‑1 описана dual token система.
  • Conflict note (если есть): —

TK_1 — платёж за сервис (1/0)

  • TK_1 (decision): 1
  • Claim (1 строка): для data access требуется burn VANA и VRC‑20 data tokens (20% VANA / 80% data token).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (1 строка): механизм доступа к данным прямо завязан на токены.
  • Conflict note (если есть): —

TK_2 — стимулы/залоги/штрафы (1/0)

  • TK_2 (decision): 1
  • Claim (1 строка): VRC‑20 “earned through contribution” и отражают ownership stake в датасете.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/how-vana-works
  • Why sufficient / why not (1 строка): описана токенизация вкладов и вознаграждение в data tokens.
  • Conflict note (если есть): —

TK_3 — управление (1/0)

  • TK_3 (decision): 0
  • Claim (1 строка): governance описан на уровне DataDAOs, но явная привязка governance‑процесса именно к VANA в Tier‑1 не установлена (VRC‑20 упоминаются как governance в DataDAO).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (1 строка): засчитываем “governance через токены” только при явной формулировке для проверяемого токена/механизма.
  • Conflict note (если есть): —

TK_4 — токен заменим (1/0)

  • TK_4 (decision): 0
  • Claim (1 строка): заменимость токенов не подтверждена Tier‑1 (механика доступа и ownership завязана на VANA/VRC‑20).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (1 строка): токены встроены в протокол доступа к данным.
  • Conflict note (если есть): —

Evidence (таблица)

Tier Источник Что доказывает
Tier‑1 https://docs.vana.org/docs/system-architecture Vana — standalone EVM‑L1; не хранит raw data; secure compute layer (TEE); dual token (VANA + VRC‑20); burn ratio 20%/80% для data access
Tier‑1 https://docs.vana.org/docs/how-vana-works “programmable data ownership”; VRC‑20 earned through contribution; burn для access; TEE permissions и onchain approvals compute jobs
Tier‑1 https://docs.vana.org/docs/tutorial-querying-data-on-vana end‑to‑end tutorial: dataset discovery → onchain permissions → submitJob → API execution → artifacts (query_results.db)
Tier‑1 https://docs.vana.org/docs/security опубликованы аудиты (Nethermind + Hashlock) по ключевым контрактам/компонентам
Tier‑1 https://docs.vana.org/changelog официальные release notes; есть onchain‑ориентированные изменения и ссылки на vanascan методы/адреса
Tier‑1 https://vana2026roadmap.org/ roadmap с фокусами 2026 (data portability/инфраструктура) и ссылками на official docs
Tier‑1 https://vanascan.io/ эксплорер сети Vana (доступ к ончейн активности/контрактам)

No comments to display

Back to top