Skip to main content
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.

​
How it works

  1. Fund — a builder (or a sponsor on their behalf) deposits into the builder’s escrow balance. Funding is permissionless: anyone can credit any account.
  2. Charge — when a grant’s fee comes due, the protocol’s facilitator settles it from the balance to the fee recipient.
  3. Gate — a Personal Server serves data for a grant only once its fee shows as paid. The server reads payment state; it never moves money.

​
Fee model

ConceptMeaning
DepositCredit an account’s balance (native VANA or a whitelisted token)
SettleMove funds from a builder’s balance to the protocol fee recipient for a specific charge
WithdrawReturn unspent balance to the account holder
Registration feeA one-time fee when a grant is created
Access feeA 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, native to the protocol. Separately, a USD rail (card/invoice billing) is available for builders who prefer to pay in fiat. They are independent: direct protocol users pay the escrow; enterprise customers can pay in fiat.
Two rails, evolving. The token escrow and the Context Gateway’s USD rail operate independently today; reconciling them — so fiat paid to the Gateway settles as protocol token fees — is on the roadmap.
Status. The escrow — deposits, balances, per-grant settlement in VANA/ERC-20, and the “paid”-gated read on the Personal Server — is live on the Moksha testnet. The broader token economics (staking, conversion, buyback) are a later phase, separate from this fee mechanism.