VANA

Vana turns user-controlled data into an onchain permission and access system

Vana is an EVM-compatible layer 1 built around data portability, encrypted storage, permissioned access, and DataDAO applications. VANA pays for network activity, supports validator security, and connects the chain to data-focused markets and governance.

What Vana is designed to do

Vana is a purpose-built, EVM-compatible blockchain for data portability rather than a general-purpose chain with data features added later. Its protocol records personal-server registrations, application identities, consent grants, file records, and schemas onchain. The underlying data remains offchain and encrypted; the chain records the permissions and references needed to govern access. This gives users a verifiable way to grant or revoke application access without placing private files directly on a public ledger.

The project’s central users are data owners, application builders, DataDAO operators, researchers, data consumers, and network validators. A builder can register an application, request particular data scopes, and receive data only when the relevant grant is valid. Vana’s documentation presents this as a consent layer for applications that need user data, including AI-related uses, but the usefulness of that model depends on compatible connectors, storage services, builders, and actual demand for the resulting datasets.

The data portability architecture

The Data Portability Protocol separates the user-facing client, a registered Personal Server, storage backends, builders, and the blockchain. Personal Servers can store data locally, enforce access requests, maintain access logs, and synchronize encrypted copies to a selected backend. Supported storage designs described in the protocol include Vana Storage, local storage, Google Drive, Dropbox, and IPFS. Storage providers receive encrypted blobs rather than plaintext, while the DataRegistry records file identifiers, schemas, permissions, and storage references.

Access is based on signed grants that identify the permitted builder and data scopes. The specification uses wallet signatures, nonces, grant expiry, revocation checks, and scope checks to authorize requests. Vana also operates a Data Portability RPC or Gateway that relays signed operations and can provide faster responses while transactions are confirmed asynchronously. That creates a practical dependency: the chain is described as the authority, but applications may still rely on gateway availability, synchronization, storage availability, and correct implementation by each Personal Server.

DataDAOs, proof of contribution, and private processing

DataDAOs are application-level markets built on Vana’s data and smart-contract infrastructure. Their contracts can coordinate data contributions, validation, rewards, dataset refinement, access, and a separate token representing a particular data asset or community. Vana’s published contract repository describes Data Liquidity Pool templates as customizable foundations rather than a single standardized marketplace, so each DataDAO may have its own contribution rules, validation logic, token design, and governance arrangements.

Proof of Contribution is intended to evaluate whether submitted data meets a DataDAO’s requirements without exposing raw data to ordinary validators or the public chain. Vana’s Satya validators run data-validation and access jobs inside Trusted Execution Environments, where the data can be decrypted and processed while the chain receives proofs and metadata. The project’s documentation describes attestations that can include checksums, ownership details, contribution scores, and DataDAO-specific metadata. These mechanisms address provenance and privacy at the protocol level, but they do not guarantee that a dataset is commercially valuable, legally usable, representative, or free of manipulation.

What VANA does

VANA is the native gas and utility token of Vana’s layer 1. The project documents it as the payment asset for transactions such as grants, file records, Personal Server registration, builder registration, smart-contract execution, and data-application interactions. VANA is also used for staking by blockchain validators and is described as a default payment and trading-pair asset for DataDAO applications, although individual DataDAOs can specify other access currencies.

The documented total supply is capped at 120 million VANA. Vana states that the token is native on its own layer 1 and has wrapped or ERC-20 representations on other networks. This distinction matters operationally: an address displayed for an ERC-20 representation is not the native Vana mainnet token address. Users and applications must verify the network, bridge or omnichain mechanism, and contract address before transferring or interacting with VANA.

Security, validators, and governance control

Vana separates blockchain consensus from data validation. L1 validators use proof of stake to produce and finalize blocks and stake VANA as collateral. Satya validators perform data-related jobs in TEEs and can receive VANA for validation work. This creates two different security dependencies: the economic and operational quality of the L1 validator set, and the availability, implementation, and hardware security of the data-validation infrastructure.

The project uses Vana Request for Comments documents as its formal mechanism for proposing features, recording design decisions, and documenting implementation guidelines. Vana’s token documentation also describes holder participation in network governance and a planned expansion of treasury governance through a Vana DAO. The practical scope of token-holder control should therefore be assessed proposal by proposal; the existence of an RFC process does not by itself establish that every protocol parameter or treasury decision is controlled by VANA holders.

Practical limits for users and builders

Vana’s architecture does not eliminate the hard parts of data markets. Data must still be exported from source platforms, normalized into useful schemas, stored reliably, and evaluated with contribution rules that resist duplication or low-quality submissions. Data consumers must also trust the relevance of the dataset and the terms under which it was collected. The protocol specification explicitly leaves platform-specific connectors, application features, and user-interface design outside its core scope, meaning those capabilities remain application and ecosystem responsibilities.

Builders also face dependencies on gateway services, Personal Server deployments, storage backends, TEEs, smart contracts, bridges, and the availability of compatible DataDAOs. Vana publishes core contract addresses and explorer references, but contract upgrades, deprecated components, changing reward systems, and DataDAO-specific implementations require separate review. The system is therefore best understood as a coordination and permission framework whose results depend heavily on the quality and resilience of the surrounding applications.

Key takeaways

• Vana is an EVM-compatible layer 1 focused on data portability, consent, encrypted storage, and application access.
• Private files remain offchain; the blockchain records permissions, registrations, schemas, and references used to control access.
• DataDAOs can create dataset-specific contribution, validation, access, reward, and token systems on top of Vana.
• VANA pays network fees, supports validator staking, participates in governance, and commonly serves as a DataDAO payment or trading-pair asset.
• Proof of Contribution and Satya TEEs are project mechanisms for validating data while limiting exposure of raw content.
• The protocol’s practical success depends on connectors, builders, storage, gateways, validators, DataDAOs, and sustained demand for usable datasets.

Risks and open questions

• Trusted Execution Environments reduce some data-exposure risks but introduce dependencies on hardware, attestation, validator operations, and implementation quality.
• A valid contribution proof does not establish that a dataset is valuable, legally reusable, representative, or suitable for training a particular AI system.
• The Gateway, storage backends, Personal Servers, bridges, and DataDAO contracts create operational dependencies beyond the Vana L1 itself.
• DataDAO tokens and reward mechanisms are application-specific; their liquidity, governance, supply controls, and access utility require separate contract-level review.
• The documentation describes governance participation and a planned expansion of treasury governance, but the effective scope of VANA-holder control may change through future proposals and implementations.