VANA — The Asset Behind an Open Data Economy

1. Overview

Vana is open data infrastructure for human-grounded AI. Compute was the last scarce resource; human-grounded data is the next.

Data cannot move on rails that a counterparty owns. A person will not route their data through infrastructure controlled by the party that wants to use it, and a developer will not build on rails whose operator may become their competitor. The protocol records permission, enforces terms, and lets no participant change the rules on its own.

VANA is the economic instrument of that substrate.

Two sides of the market

Data contributed to the network works on the contributor's behalf across every application they authorise, under permissions they set and can revoke. Builders come for permissioned data with a record of provenance, which is hard to get elsewhere.

Each side makes the other more useful. Every dataset added widens what any builder can reach; every builder added gives contributors somewhere to use their data. The reach is the product of the two populations rather than their sum: one dataset serves a thousand applications at the same cost of contribution, and one application reaches a million datasets through the same permission.

What the protocol charges for

The protocol prices transaction types across the data lifecycle. Each transaction type carries its own rate, set independently of the others, and transaction types can be added over time.

Some transaction types happen once. Data comes into the network, a personal server is registered, a grant is issued — each happens once per user or per piece of data.

Others repeat against what those created. Once data is in the network and a grant exists, it can be read and paid for an unlimited number of times.

That is where the fee base grows. Repeat transaction types scale with how much the data is used, not with how many users join.

Where the fees go

To the parties securing the network. The larger share is allocated across operator pools in proportion to the VANA staked with them. Operators run the network and take a commission on what their pool earns. A bonding period applies before staked VANA earns, and what it earns depends on the operator chosen and the commission that operator sets.

To the token. A further share is used to buy VANA on the market, and what is bought is burned.

To the ecosystem. The Foundation holds the remainder and deploys it as grants and support for builders, expanding the number of applications using the network.

2. Fees and where they go

2.1 Transaction types

Transaction type	What it is	How often
Data write	Data brought into the network	Each time a user writes data to the network, including updating an already connected data source
Personal server registration	The user's own data environment	Once per user
Permission grant	Consent recorded on-chain for a defined scope	Once per application, per data source
Read against a granted scope	An application reading data it holds a permission for	Every time the application uses the data

The first three happen once or as new data is added. Reads repeat indefinitely: once data is in the network, it can be read and used over and over.

2.2 Rates

Fees attach to specific transaction types, allowing for granular pricing. A registry holds the rate for each transaction type, and the rates below are the ones currently set.

Transaction type	Rate now
Read against a granted scope	$0.01 per scope-read
Permission grant	Zero
Data write	Not set
Personal server registration	Not set

Reads are priced at $0.01 per scope-read as at September 2026. Rates are held against a named transaction type, so each can move on its own.

2.3 The fee base can grow

The architecture is flexible. Transaction types can be added and rates can be changed without redeploying a contract.

Dimension	Now	Designed to support
Rate control	Settable per transaction type, no redeploy	In use
Which transaction types carry a rate	Reads	Any transaction type in the lifecycle
Rate by payload	One rate per transaction type	Rate varying with the scope and depth of what is returned
Transaction type count	Four	More transaction types placed into the same structure

Which of these matters most depends on how the network is used. The point is that growth does not require rebuilding anything — a transaction type needs to be defined with a rate slot before demand for it arrives, and adding one is a parameter change.

2.4 Transformations

The protocol is being extended to serve requests for computed answers rather than raw records.

Compute runs over a user's data and produces a transformation: a new record with a pointer back to what it was computed from.

To take one example: a raw archive sits at the root, a categoriser produces a topic tree from it, and a summariser produces a health summary from one branch. The user grants access at the node matching what the application asked for, so an application needing only that summary receives it, not the root and not the sibling branches. The same structure applies to any domain.

Transformations add further transaction types: a context query, redacting patient information, and any other operation run on top of the data.

Deletion is exercised by the user, at a single node or across a full lineage. A transformation survives deletion of its sources, so the records an application reads against persist independently of the raw data they came from.

Transformations also give the protocol a way to price by payload. Telling one payload from another requires the protocol to know what a payload is, and a transformation node has a recorded position, lineage and scope.

A transformation can be computed once or recomputed as its sources grow. The second case is a single grant that generates priced reads for as long as the underlying data changes.

2.5 The unit

An application needs continuing access to a person's data — a listening history, a fitness record, a purchase log — on terms that person set. The owner grants a scope. The application reads against that scope when it needs the data. Each read is priced at a fixed, adjustable rate, settled via the protocol.

One application reading one scope once a day is 365 priced reads in a year, from a single act of contribution. The contribution happens once; the fees do not.

2.6 How a fee splits

The larger share of every fee is allocated to the parties who secure and operate the network, which is what ties the network's security to how much it is used. A further share buys VANA on the market and burns it. The Foundation holds the remainder for ecosystem funding.

These are parameters rather than fixed properties. Both splits and the commission can be changed without redeploying a contract. Section 6 lists them.

2.7 Fees become demand for VANA

Fees are paid into the network by its users, currently in USDC. The staking and buyback shares are both used to buy VANA on the market. The staking share is distributed and the buyback share burned, so income the network earns from outside it becomes demand for the asset rather than an internal transfer.

Staking is intended to tie the network's security to the value staked in it.

2.8 How the parts feed each other

Loop	Mechanism	Result
Usage → allocation → staking	More reads means more fees per unit of staked VANA	More VANA staked
Fees → burn → supply	Burn scales with fees; issuance does not	Beyond a level of use, net supply falls
Ecosystem → applications → usage	Foundation capital funds builders, whose applications generate reads	More of the input everything else draws on
Operator income → operators	Fee income makes running an operator viable without subsidy	More operators

Live read volume, fee income and burn are published at token.vana.org.

3. Staking

3.1 What is allocated

The larger share of fee income is allocated to the parties securing the network. The Foundation holds the remainder, and uses a defined share of it to buy VANA on the market.

Staking on Vana is delegation to a named operator, not a deposit into a single pool. That is what determines how the allocation behaves.

3.2 How delegation works

The protocol allocates fee income across operator pools in proportion to the VANA staked with each. The operator does the work, sets its commission, and passes on the rest pro rata. A delegator picks an operator on published terms.

3.3 What determines what a delegator earns

Input	Effect	Set by
Fee income	Rises with reads	Network usage
Operator share	Fixed	Protocol configuration
Delegator's share of staked VANA	Rises with the operator's standing	Delegators
Operator commission	Reduces what is passed on	The operator
Total staked VANA	Divides the same income further	Everyone staking

More reads raise the numerator. More VANA staked divides the same income across a larger base.

3.4 How an operator's share is worked out

Each operator is allocated a share of fee income in proportion to the VANA staked with it, and passes that on to its delegators after taking its commission.

The intended end state ties an operator's share to the work it actually does, with staked VANA determining how much work it is given. That runs through stake-weighted allocation of work at the consensus layer, which is a planned upgrade. The operator's role does not change: it does the work, sets its commission, and makes the distribution.

3.5 Yield

Yield follows from four things:

yield = fee income × operator share × (1 − commission)

÷ (VANA staked × price of VANA)

Fee income — what the network collects from paid reads over the period.

Operator share — the 60% allocated to operator pools.

Commission — what the operator keeps, 5% by default.

VANA staked × price — the value of the capital the income is divided across.

Worked through. Suppose the network collects $1,000,000 in fees over a year. 60% goes to operator pools — $600,000. Operators keep 5% of that, so $570,000 reaches stakers.

If 1,000,000 VANA is staked and VANA trades at $1.00, that capital is worth $1,000,000. So stakers earn $570,000 on $1,000,000 staked — a yield of 57%.

Now change one input at a time. Double the fees to $2,000,000 and the yield doubles to 114%. Double the staked VANA to 2,000,000 instead and it halves to 28.5%. Double the price and it halves again, because the same income is divided across capital worth twice as much.

Fee income depends on how much the network is used, and the staked base and price are set by the market.

3.6 Bonding

A bonding period applies before staked VANA earns. Restaking recalculates on a weighted average, and rewards compound through automatic restake.

The intended end state puts delegated VANA at risk alongside the operator's own stake. That is a planned upgrade; section 6 records where it stands.

3.7 Choosing an operator

The staking surface publishes, per operator: name, total staked VANA, commission, and what a delegator receives after it. Current pools and their terms are at stake.vana.org.

4. Buyback

A defined share of fee income is used to buy VANA on the market, and what is bought is burned.

The share is a parameter, not a discretionary decision each cycle, and it is adjustable. It scales with reads and with nothing else. Section 6 records its current value. Each buyback and burn is published with its transaction hash at token.vana.org/burn.

5. Supply

5.1 The cap

VANA is issued against a policy cap of 120,000,000 tokens.

Issuance is validator reward under standard proof-of-stake: a function of how much is staked and how well validators participate. It does not reference network usage or fees. Nothing an application does causes VANA to be issued. Issuance runs at approximately 440,700 VANA per year. Current supply and issuance are published at token.vana.org.

5.2 Issuance against burn

Two things act on supply, on unrelated drivers. Issuance is validator reward and is indifferent to network activity. Burn scales with fee income.

Only one of the two responds to use. Beyond some level of activity, burn exceeds issuance and net supply contracts. Reaching that point takes no vote, no intervention and no parameter change; it is a function of how much the network is used.

6. Parameters

Values as at 22 September 2026, Vana mainnet (chainId 1480). Live values are at token.vana.org. Adjustable means the parameter can be changed without redeploying a contract.

Fees

Transaction type	Current	Status
Read against a granted scope	$0.01 per scope-read	Adjustable
Permission grant	Zero	Adjustable
Data write	Not set	Adjustable
Personal server registration	Not set	Adjustable
Rate by payload	One rate per transaction type	Target state
Context query	Not set	Target state
Transformation request	Not set	Target state
Transformation registration	Not set	Target state
Transformation grant	Not set	Target state
Node-addressed read	Not set	Target state
Lineage query	Not set	Target state
Deletion	Not set	Target state
Settlement	External stable currency; gas in VANA	Adjustable

Allocation

Parameter	Current	Adjustable
Operator / treasury share	60 / 40	Yes
Treasury / buyback share	50 / 50	Yes
Operator commission	Operator-settable, 5% default	Yes

Staking

Parameter	Current	Target state
Allocation basis	Pro rata to staked VANA	Work-proportional
Work allocation	Uniform across the validator set	Stake-weighted
Slashing	Operator stake	Operator stake and delegated VANA
Validator activation	35,000 VANA	Network upgrade
Validator set	31 permissioned validators, 1,085,000 VANA credited	—
Delegator minimum	None	—
Bonding period	5 days	Adjustable
Yield	Market-determined	Unchanged

Buyback

Parameter	Current	Adjustable
Funding	Defined share of fee income	Yes

Every current value marked adjustable can be changed by a maintainer role without redeploying a contract; the target states are protocol upgrades rather than parameter changes. That is what makes each adjustable parameter a candidate for holder governance in future.

Issuance

Parameter	Value
Issuance	~440,700 VANA/yr
Responds to fees	No — validator reward only
Supply cap	120,000,000 VANA — policy commitment