Payments & fees

The protocol provides a fee primitive: a per-account escrow. Builders fund a balance; the protocol charges fees against it and settles them to a fee recipient. Access is gated on the fee being paid, but the Personal Server never holds funds — payment and access stay cleanly separated. The escrow holds the native asset VANA and any whitelisted token, so fees can be denominated in VANA or a stablecoin without changing the contract.

Status. The escrow — deposits, balances, per-grant settlement, and the “paid”-gated read on the Personal Server — is live on both Vana mainnet and the Moksha testnet. Each network settles fees in its own whitelisted asset: USDC.e (bridged USDC) on mainnet, and native VANA on Moksha — so a mainnet builder funds in USDC.e, not VANA. The broader token economics (staking, conversion, buyback) are a later phase, separate from this fee mechanism.

How it works

Fund — a builder (or a sponsor on their behalf) deposits into the builder’s escrow balance in the network’s fee asset (USDC.e on mainnet, VANA on Moksha; see Networks for how to bridge and deposit). Funding is permissionless: anyone can credit any account.
Charge — when a grant’s fee comes due, the protocol’s facilitator settles it from the balance to the fee recipient.
Gate — a Personal Server serves data for a grant only once the fee for that access shows as paid. Access fees are per-use, so a repeat read is gated on its own charge — the balance has to stay funded. The server reads payment state; it never moves money.

Fee model

Concept	Meaning
Deposit	Credit an account’s balance (native VANA or a whitelisted token)
Settle	Move funds from a builder’s balance to the protocol fee recipient for a specific charge
Withdraw	Return unspent balance to the account holder
Registration fee	A one-time fee when a grant is created
Access fee	A per-use fee charged as data is accessed

Funding is open to anyone; settlement and withdrawal are performed only by the protocol’s facilitator, so the escrow can collect the fees an account has explicitly funded but cannot redirect funds elsewhere. In today’s deployment the facilitator is the RPC gateway — the same operator that sequences and anchors all protocol transactions (see the DP RPC note). Settle and withdraw are access-restricted to it because all transactions route through the gateway and a confirmation gap to L1 would otherwise let on-chain accounting drift. Its powers are deliberately bounded — it can only collect fees an account has explicitly funded, never redirect balances — and decentralizing it (with the move to a decentralized sequencer) is on the roadmap.

Onchain events

event Deposited(address indexed from, address indexed account, address indexed asset, uint256 amount);
event Settled(address indexed from, address indexed to, address indexed asset, uint256 amount, bytes32 ref);
event Withdrawn(address indexed account, address indexed asset, uint256 amount, bytes32 ref);

In a Settled event, to is the protocol fee recipient and ref tags the charge (e.g. a payment or invoice id).

Two rails

The fee escrow is the token rail — the protocol-native way builders pay, funding an on-chain balance the facilitator settles against. Separately, ODL’s Context Gateway bills its enterprise customers in USD (via Stripe) for metered usage of its hosted service. That USD billing is a commercial layer on top of the Gateway; it is not a way to pay protocol fees, and it is not wired into the escrow today.

Two rails, evolving. The protocol’s token escrow and the Context Gateway’s USD billing operate independently today; reconciling them — so fiat paid to the Gateway settles as protocol token fees — is on the roadmap.

Overview

Protocol reference

Applications

Security

Network

Resources

How it works

Fee model

Onchain events

Two rails

​How it works

​Fee model

​Onchain events

​Two rails

How it works

Fee model

Onchain events

Two rails