Skip to main content

Vana

Vana (VANA) — 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).

Vana — a network for user‑owned data: users can pool data into DataDAOs, receive “data tokens” for their contribution, and grant access to data/computation through onchain permissions and secure execution (TEE). The project positions this as infrastructure for training and using AI on private data while preserving privacy.

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 network and a set of contracts/services that turn data contributions into “programmable ownership” and provide access to data through rules/permissions.
  • Who it’s for: users who own data; DataDAO creators; developers/researchers who need private datasets for training/applications.
  • Why onchain/token: onchain stores proofs of contribution and access permissions; access to datasets requires burning tokens, and computation runs in a TEE with onchain approval.
  • What you can actually touch (Tier‑1): an end‑to‑end tutorial “query dataset → submit job → receive artifact” (a compute workflow on the network).

How it works (very briefly)

  1. The user does: adds data to a DataDAO (via a DLP — Data Liquidity Pool) or keeps the data locally (personal server) and grants permissions.
  2. The system does: records rights/access onchain, and runs computation on private data in a secure environment (TEE), where the data is not exposed externally.
  3. The user gets: VRC‑20 data tokens for the contribution + participation in the DataDAO’s economy/governance; control over who can access the data and on what terms.
  4. Where the blockchain is: a standalone EVM‑compatible L1 for coordinating proofs of contribution, access permissions and contracts (without storing raw data).
  5. Token role: VANA is used for fees and data access (burned together with data tokens); VRC‑20 tokens are tied to datasets and are also “burned” for access.
  6. What a “compute job” looks like in practice (Tier‑1): pre‑deposit into ComputeEngine → submitJob (we obtain a jobId) → request to the tee-url API → download the result from artifacts (for example query_results.db).

Quick links: AI thesis fit

Project passport

Field Value
Project name Vana
Also known as (aliases) VANA
Logo (logo) ../assets/37_vana_logo.svg
Token symbol (ticker) VANA
Category AI/Data | Infra
Primary chain (chain) Vana
Type EVM
Network status mainnet
Consensus (consensus) —
Launch date (launch_date) —
Project status (status) active
Token (standard) native
Token contract —
Token model (token_type) utility (gas + data access + burn)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) data access requires burning VANA + VRC‑20 data tokens (the documentation specifies 20%/80%); VRC‑20 are earned by contributing data
Governance DataDAOs (onchain rules/economics)
Admins/keys —
Audit yes
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) user-owned data + TEE compute for AI
Use‑case (use_case) DataDAOs for AI training on private data
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 2 / 2
Last verified 2026-02-11

General project overview

Vana describes itself as a network for “programmable data ownership”: the data remains private (encrypted at the users’/storage providers’ side), but ownership, access rights and the economics of datasets are managed through onchain contracts and contribution accounting.

The key idea is DataDAOs: data collectives with shared rules for validation, governance and economics. Users contribute data to Data Liquidity Pools (DLP), receive dataset‑specific VRC‑20 tokens and can earn when developers “buy access” (via token burns). To preserve privacy, computation on the data is performed in a TEE (secure compute layer), while onchain is used as a “coordination layer” for permissions and for recording results/facts of execution.

Features/modules

  • DataDAOs: governed datasets (rules/economics/validation).
  • DLP (Data Liquidity Pool): the logic for verifying contributions and permissioning for a dataset.
  • VRC‑20 data tokens: tokens “cryptographically tied” to specific datasets via proof‑of‑contribution.
  • L1 coordination layer: stores proofs of contribution, access grants and contracts (without raw data).
  • Secure compute layer (TEE): executes approved code on private data and returns results without exposing raw data.

Typical scenarios

  • Scenario 1 (data contribution): a user adds data to a DataDAO → receives VRC‑20 tokens → participates in the dataset’s economy.
  • Scenario 2 (query to a private dataset / compute job): a developer/researcher obtains onchain permissions → (per the DataDAO’s rules) pays/burns VANA + VRC‑20 → registers a job in ComputeEngine → execution runs in a TEE → receives an artifact (for example query_results.db), without publishing raw data.
  • Scenario 3 (personal sovereignty): a user stores data on a personal server → grants onchain permissions for specific operations/fields → the application performs the permitted computation without leaking raw data.

Getting started (wallet/network)

  • What you need: an EVM‑compatible wallet (a user’s identity in Vana is tied to the wallet address).
  • Network/chain: Vana (an EVM‑compatible L1; explorer — vanascan).
  • Fees: gas/fees in native VANA (per the documentation), plus burning VANA + VRC‑20 for access to datasets.

Architecture/tech (non‑AI)

  • Components: DataDAOs (DLP + access contracts + VRC‑20) + L1 (coordination/registry/permissions) + TEE compute layer.
  • Participant roles: data contributors, DataDAO/DLP operators, data/AI builders, validators/infrastructure operators.
  • Where logic runs: rights/access/contribution accounting — onchain; raw data and execution of computation — offchain in a TEE.
  • Dependencies: TEE infrastructure (with GPU/without GPU), offchain storage, wallet identity.

Token/economics (expanded, no forecasts)

  • Token utilities: VANA — fees and a component of data access; VRC‑20 — dataset‑specific ownership/economics, burned for access.
  • Protocol necessity drivers: data access and the launch of compute jobs are tied to onchain approval and token burns; this provides coordination of rights and distribution of value among contributors.
  • Who pays fees: network users (gas) and data consumers (burning VANA+VRC‑20).
  • Where fees go: — (not established from the current Tier‑1 pages).
  • Issuance/burn: Tier‑1 describes a burn mechanism for data access (VANA + VRC‑20; a ratio of 20% is specified for VANA).
  • Security/incentive mechanisms: incentivizing contributions via VRC‑20; data access via permissioning and a TEE.
  • Distribution and token issuance schedule: — (not established from the current Tier‑1 pages).
  • Treasury: — (not established).

Governance

  • Who makes decisions: DataDAOs (rules/economics/granular permissions) — onchain governance mechanisms.
  • How protocol parameters change: — (not established from the current Tier‑1 pages).
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: the documentation publishes a list of audits (Nethermind + Hashlock) for protocol components/contracts.
  • Bug bounty: — (a public Tier‑1 bug bounty program is not established; there is responsible disclosure, see Security).
  • Incidents: — (not established).
  • Threat model: the risks relate to the correctness of TEE/attestation, the security of DataDAO/DLP contracts and the correctness of onchain permissioning.

Project status and timeline

  • Current status: active development and release notes in the official documentation; the network/explorer are available.
  • Key releases/milestones: see Release Notes (the official changelog).
  • Roadmap: a “Vana 2026 Roadmap” has been published with focus areas and upgrades (Vega Upgrade, data portability).

Ecosystem/integrations

  • Integrations: wallet as identity, DataDAOs/market mechanics, TEE compute.
  • Where it’s actually used: the declared use‑case — access to private datasets for AI training (at the level of architecture and economic rules).

AI component of the project

  • What is real AI here? Tier‑1 describes the use‑case “AI training on user‑owned/private datasets”, but a “project’s own AI algorithm/model” as a separate artifact is not described: Vana acts as data/permissioning + compute infrastructure.
  • What is truly onchain? Ownership/attribution of contributions, access grants, DataDAO/DLP contracts and approvals of compute jobs are recorded on a standalone EVM L1; raw data is not stored onchain.
  • Why is a token needed? Data access requires burning VANA and VRC‑20; VANA is also used for fees.
  • Red flags (based on the information found): AI‑washing (AI is the declared area of application; it is important to separate “infrastructure for AI” from an “AI product”), TEE trust assumptions (how much we trust the execution/attestation), difficulty of verifying the offchain parts. Separately: the current Tier‑1 “demo” shows a compute/query workflow, but does not prove the quality/metrics of AI models.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): There are signs of AI reality per Tier‑1 (see AI_1..AI_4), so the AI_0 flag (intent‑only) does not apply.
  • Evidence: Tier‑1 — see Evidence/links in AI_1..AI_4.
  • Why sufficient / why not (one line): AI_0=1 is admissible only when AI_1..AI_4=0; here ai_score without AI_0 = 1.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): — (no specific AI module/model of the project is described as a working component).
  • Evidence: Tier‑1 — — | No Tier‑1 source for claim “there is a specific AI module/model of Vana as a product” was found.
  • Why sufficient / why not (one line): AI is described as a use‑case (infrastructure), not as a separate AI component.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): the Tier‑1 docs contain an end‑to‑end tutorial on accessing a dataset and running a compute job (TEE) to obtain query results.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/tutorial-querying-data-on-vana
  • Why sufficient / why not (one line): there is a reproducible workflow “dataset discovery → permissions → submitJob → artifacts”, but these are not quality metrics of an AI model (AI_3=0).
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — — | No Tier‑1 source on AI/quality metrics was found.
  • Why sufficient / why not (one line): no numbers/context.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): — (the architecture is described, but not as an “AI model/version/parameters”).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (one line): this is a technical description of the data/access infrastructure, not of an AI model.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Vana (standalone EVM‑compatible L1)
  • Addresses/identifiers: explorer vanascan (DataDAO/DLP contracts are available in the explorer; specific addresses depend on the DataDAO)
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture, https://docs.vana.org/changelog
  • Why sufficient / why not (one line): Tier‑1 records the existence of the L1/contracts; the release notes contain links to methods/addresses in vanascan.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: access grants, proofs of contribution, approvals of compute jobs, the registry of rights and the DataDAOs/DLP smart contracts.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture, https://docs.vana.org/docs/how-vana-works
  • Why sufficient / why not (one line): an onchain coordination layer and onchain permissions are described.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without an onchain registry of rights/permissions and the burn mechanics of “data tokens”, the public verifiability of ownership/attribution and the reproducible economics of data access are lost.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (one line): the Tier‑1 architecture builds permissioning/economics around the L1.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the VANA and VRC‑20 tokens are used in the protocol.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (one line): Tier‑1 describes a dual token system.
  • Conflict note (if any): —

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): data access requires burning VANA and VRC‑20 data tokens (20% VANA / 80% data token).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (one line): the data access mechanism is directly tied to the tokens.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): VRC‑20 are “earned through contribution” and reflect an ownership stake in the dataset.
  • Evidence: Tier‑1 — https://docs.vana.org/docs/how-vana-works
  • Why sufficient / why not (one line): the tokenization of contributions and rewards in data tokens are described.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance is described at the DataDAO level, but an explicit link of the governance process specifically to VANA is not established in Tier‑1 (VRC‑20 are mentioned as governance within a DataDAO).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (one line): we count “governance via tokens” only when explicitly stated for the verifiable token/mechanism.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability of the tokens is not confirmed by Tier‑1 (the access and ownership mechanics are tied to VANA/VRC‑20).
  • Evidence: Tier‑1 — https://docs.vana.org/docs/system-architecture
  • Why sufficient / why not (one line): the tokens are built into the data access protocol.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.vana.org/docs/system-architecture Vana is a standalone EVM L1; does not store raw data; secure compute layer (TEE); dual token (VANA + VRC‑20); burn ratio 20%/80% for data access
Tier‑1 https://docs.vana.org/docs/how-vana-works “programmable data ownership”; VRC‑20 earned through contribution; burn for access; TEE permissions and onchain approvals of 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 audits published (Nethermind + Hashlock) for key contracts/components
Tier‑1 https://docs.vana.org/changelog official release notes; there are onchain‑oriented changes and links to vanascan methods/addresses
Tier‑1 https://vana2026roadmap.org/ roadmap with 2026 focus areas (data portability/infrastructure) and links to the official docs
Tier‑1 https://vanascan.io/ explorer of the Vana network (access to onchain activity/contracts)

No comments to display

Back to top