The economy engine.

01 · Overview

The economy behind the runtime.

VEX is the economic layer of the VEX autonomous runtime. The runtime turns user intent into verified onchain action: it reasons about a goal, prepares a plan, asks for approval, signs locally, executes through supported protocols, verifies the final state, and remembers what may improve future decisions. $VEX connects that product activity to a transparent economic system.

The model is built around three functions:

Across the model, Project VEX applies one consistent allocation policy to its revenue share:

The purpose is not to manufacture yield or promise token appreciation. The purpose is to connect real runtime usage, AI consumption, and verified execution to the VEX economy.

VEX is not added on top of the runtime as a speculative feature. It is designed to become the economy engine behind how the runtime consumes intelligence, allocates capacity, and executes economic actions.

The token today

02 · Status

Planned, not live.

This paper describes the intended public economic model of VEX. Unless separately announced and verifiable in production:

This paper does not claim that these mechanisms are already live. It contains no price target, guaranteed return, guaranteed revenue, exchange-listing promise, passive-yield promise, or assurance that burning VEX will increase its market value.

03 · Why an Economy

Scarce resources have real costs.

An autonomous runtime is not only an interface for an AI model. It coordinates several scarce resources: inference, market data, memory, tools, execution capacity, infrastructure, verification, and onchain settlement. Each resource has a real cost.

AI providers charge for inference. Protocols charge gas and execution fees. Reliable memory and long-running missions require storage and compute. High-frequency or concurrent workloads consume more capacity than basic usage. Onchain actions also create measurable economic activity.

A runtime that coordinates these resources needs a coherent way to answer four questions:

1. How do users pay for intelligence?
2. How do power users access more runtime capacity?
3. How does execution activity return value to the protocol economy?
4. How can those flows remain transparent without turning the token into an emissions-based yield product?

VEX is intended to answer those questions. It is designed as a payment, access, and value-accrual asset inside the VEX runtime economy:

04 · System Map

The whole system, one board.

One board holds the full picture: the runtime loop that turns intent into verified action, the memory pipeline that earns what it keeps, and the token loop this paper specifies.

The three economic flows are related but not identical:

They should not be presented as one undifferentiated token loop. Each has a separate user motivation, accounting path, and activation condition.

These functions are intended to reinforce one another without depending on passive rewards. A user does not lock VEX merely to receive more VEX; the runtime capacity itself is useful. A user does not pay with VEX because a token was forced into the checkout flow; the partner arrangement gives a tangible pricing advantage. A buyback does not occur because the treasury chooses to intervene in the market; it follows a scheduled, publicly reported process funded by actual app-fee revenue.

05 · AI Credit Economy

Pay for intelligence in VEX.

AI inference is one of the core operating costs of an autonomous runtime. Users need model access for reasoning, research, planning, market interpretation, tool selection, execution preparation, verification, and memory review.

VEX does not claim to own exclusive premium models, and it does not promise that locking VEX unlocks a particular third-party model. Model availability remains dependent on supported providers and partner integrations. The utility is simpler:

Users may pay for supported AI credits with VEX and receive a lower effective price than alternative supported payment routes.

Why paying with VEX is cheaper

The discount is not an unexplained subsidy. It comes from a commercial revenue-sharing arrangement with an approved infrastructure partner, who agrees to a discounted VEX-denominated payment route because the integration can create:

• additional user acquisition,
• higher payment volume,
• a differentiated distribution channel,
• and shared revenue.

Under the intended structure the partner receives 50% of the applicable payment revenue, Project VEX receives 50%, and Project VEX applies its share according to the 80/20 allocation policy. This model must be implemented only after the commercial agreement, attribution rules, settlement method, and reporting obligations are finalized.

A worked example

The following is illustrative and does not set a final discount rate. Suppose an equivalent AI-credit package costs $10 through an alternative supported payment route, and the partner-supported VEX route offers the same package for the VEX equivalent of $9:

1. The user pays the quoted VEX amount.
2. The user receives the AI credits.
3. Revenue is attributed between the infrastructure partner and Project VEX.
4. The partner receives its 50% share under the agreement.
5. The Project VEX 50% share is accumulated until the weekly settlement.
6. At settlement, 80% of the Project VEX share is burned.
7. The remaining 20% is retained by the protocol treasury.

The final discount, quotation method, price oracle, slippage tolerance, supported chains, and settlement timing must be published before activation.

What this utility does

What it does not do

• It does not guarantee permanent discounts.
• It does not guarantee support for any named AI model.
• It does not grant exclusive access to third-party models.
• It does not create passive yield.
• It does not distribute provider revenue directly to token holders.
• It does not imply that AI credits are currently live.

Settlement policy

The intended settlement cadence is weekly. A weekly cadence is preferred over per-payment burns because it allows reconciliation of completed payments, correction of refunds or failed credit deliveries, consolidated partner settlement, lower transaction overhead, clearer public reporting, and reduced operational fragmentation.

Only finalized and reconciled Project VEX revenue enters the weekly 80/20 allocation. Pending payments, disputed transactions, refunds, chargebacks, and unearned credits are not counted as burnable revenue.

06 · Runtime Unlocks

Lock for capacity, not yield.

Not all users consume the runtime in the same way. A user running one occasional mission does not require the same capacity as a user operating several agents, maintaining long-running strategies, storing more memory, or calling the runtime through an API. VEX locking allocates higher product capacity to users with greater demand.

Locking VEX is an access mechanism, not a yield product. Users lock VEX because the runtime capability itself is useful.

Tier design

Exact VEX thresholds are not hard-coded into this paper before product economics and usage data support them. A public tier table may eventually take this form:

This table is conceptual. Final thresholds and benefits require separate publication.

Locking rules

Before launch, the protocol should define:

• minimum lock duration and unlock cooldown,
• when tier benefits begin, and when they end after unlock,
• treatment of partially unlocked balances and multiple wallets,
• cross-chain representation,
• and protection against double-counting the same VEX.

The same VEX should not simultaneously count toward multiple incompatible commitments unless explicitly designed and disclosed.

No passive yield

Runtime Unlocks must not be marketed as staking rewards, passive income, guaranteed yield, APY, emissions, or revenue distribution.

The economic return is the product capacity itself. The user gives up liquidity for a defined period in exchange for higher runtime access.

07 · Execution Economy

Fees become buybacks.

The VEX runtime performs real onchain actions. Supported execution categories may include swaps, trades, bridges, automated execution, portfolio actions, position management, and other supported protocol interactions. These actions can generate an app fee, and the intended model converts that revenue into scheduled market demand for VEX.

The app fee

The app fee is charged in a supported asset according to the execution route; it is not presented as direct VEX spending. The intended sequence:

1. A supported action is executed.
2. The applicable app fee is collected.
3. Finalized revenue is accumulated.
4. Revenue enters the scheduled weekly buyback budget.
5. VEX is purchased on the open market.
6. Bought-back VEX is allocated 80% to burn and 20% to treasury.

The exact fee rate, supported routes, exemptions, and transaction treatment must be published before activation.

No double charging

A user should not be charged twice for the same economic action under overlapping VEX mechanisms. The protocol should not charge an app fee, separately require an additional direct VEX action fee, and then describe both as one charge. The user-facing quote shows the applicable fee before approval, and any difference between venue fee, network gas, routing cost, and VEX app fee is clearly disclosed.

Finalized revenue only

A buyback budget is based on finalized and reconciled protocol revenue. The following are not counted as buyback revenue:

• user principal,
• failed transactions and refunded fees,
• pending settlement and disputed transactions,
• external provider costs and gas reimbursements,
• and amounts owed to partners.

If an action has an uncertain final outcome, its fee remains pending until reconciliation.

Weekly buybacks

For every scheduled buyback, the protocol should publish:

• the buyback wallet and approved execution venues,
• the weekly budget and execution window,
• the average execution price,
• purchased VEX, burned VEX, treasury VEX,
• and the relevant transaction hashes.

Weekly execution is preferred to per-transaction market buys because it aggregates small fees, reduces transaction overhead, applies slippage controls, avoids fragmented market orders, reconciles revenue, and publishes one coherent report.

Buyback controls

Before activation, the buyback process should define maximum weekly spend, maximum slippage, maximum price impact, approved liquidity venues, route freshness, pause conditions, minimum market depth, and the treatment of unexecuted budgets.

A scheduled buyback is not permission for the treasury to trade discretionarily around VEX. The buyback system executes according to published rules.

Allocation and the treasury share

After the weekly buyback, 80% of purchased VEX is burned and 20% is retained by the protocol treasury. The burn reduces token supply permanently only after the transaction is finalized and publicly verifiable. The treasury share may support protocol development, infrastructure, audits, security, legal and accounting work, reporting systems, partner integrations, liquidity operations governed by published policy, and future runtime-economy development.

The treasury must not describe unrealized token holdings as revenue. Treasury holdings are not burned supply.

08 · Settlement

One policy, two paths.

The same high-level allocation applies to the two revenue-linked paths:

The two paths should be reported separately, so the public can distinguish direct VEX spent for AI credits, VEX purchased through app-fee buybacks, VEX burned from each source, and VEX retained by treasury from each source.

09 · Flywheel

Usage-linked, not emission-fed.

The VEX model is usage-linked. It begins with product activity, not token emissions.

The model does not claim that a burn automatically creates price appreciation. The intended alignment is narrower and more defensible:

• more AI usage can create more direct VEX payment volume,
• more execution can create more app-fee-funded buyback volume,
• more power usage can create more demand for locked VEX,
• and scheduled burns can reduce supply in a verifiable way.

Actual market value remains determined by market conditions, adoption, liquidity, execution quality, risk, and many factors outside protocol control.

10 · Runtime & Safety

The economy never holds the pen.

The economic model remains subordinate to the runtime's safety architecture. VEX does not give the model authority over user funds. The runtime separates intelligence from authority.

Locking does not override safety

A higher VEX lock tier must not:

• disable approvals or expose keys,
• bypass policy or transaction verification,
• increase leverage beyond user rules,
• or ignore slippage limits.

Payment does not purchase outcomes

Paying VEX purchases service access or credits. It does not purchase a successful AgentScan result, a favorable verification badge, search ranking presented as trust, or immunity from safety checks.

Treasury operations do not touch user funds

Buybacks, burns, and treasury activity remain separate from user wallets and user principal. The user's self-custody remains unchanged.

11 · Principles

Ten rules the model keeps.

Out of scope: the launchpad

A launchpad is not part of the core VEX economic model. It may exist as an application integration surface in the future: VEX may help an agent prepare token deployment, verify agent-token relationships, interact with a partner launchpad, monitor launch activity, or execute approved actions.

This paper therefore does not rely on mandatory VEX base pairs, bonding curves, token graduation, launchpad fee shares, or locked launch liquidity. Those mechanisms require separate product, partner, legal, and economic review.

12 · Transparency

Auditable by default.

A public economic model is credible only when its operations can be checked independently.

Public addresses

Before activation, Project VEX should publish the AI-credit settlement wallet, the app-fee collection wallet, the buyback wallet, the burn destination, and the treasury wallet. If different chains are used, addresses are published per chain.

The weekly report

Dashboard

The public dashboard should make it possible to distinguish direct VEX consumption, market-purchased VEX, burned VEX, treasury-held VEX, and locked VEX. Combining these categories into one removed-from-circulation number would be misleading.

Corrections

If reporting errors occur, corrections remain visible. A revised weekly report states what changed, why it changed, the old value, the corrected value, and the relevant evidence.

Public language

13 · Rollout

Live when ready, not when loud.

The model activates in stages, each with hard conditions:

The stages may be developed in parallel, but public activation depends on readiness rather than narrative timing.

14 · Risks

What can go wrong.

What VEX will not claim

• Guaranteed token appreciation or scarcity value.
• Guaranteed revenue, buyback volume, or AI discounts forever.
• Guaranteed APY, passive income, or risk-free locking.
• Exclusive access to named third-party AI models.
• That planned mechanisms are already live.

And VEX will not describe:

• locked tokens or treasury tokens as burned,
• gross user payments as protocol revenue,
• failed transactions as fee-generating activity,
• or partner revenue as Project VEX revenue.

15 · FAQ

The questions that decide trust.

16 · Disclaimer

Read before you rely.

This paper is a public description of an intended economic model and is provided for informational purposes only. It is not financial advice, an offer to sell securities, a solicitation to purchase tokens, a guarantee of implementation, a guarantee of revenue, or a promise of token value.

Features described as planned are not live unless separately announced and independently verifiable. The final design may change because of product testing, partner terms, security review, market conditions, technical constraints, or legal and regulatory requirements.

Users should independently evaluate all risks before acquiring, holding, locking, or using VEX.

The economy engine behind autonomous runtime: used for intelligence, locked for capacity, and acquired through execution.