# Verus Token Economics & the Agent Economy

February 2026

Verus offers a set of DeFi primitives — self-sovereign identity, permissionless token creation, protocol-level AMMs via currency baskets, MEV-resistant pricing, and atomic swaps — that together form a substrate uniquely suited to an economy where AI agents and humans transact as peers. This document explores what becomes possible when agents can mint tokens, create fractional reserve baskets, and trade autonomously on a blockchain that treats these operations as first-class protocol features rather than smart contract add-ons.

Any VerusID holder can create a token with a single definecurrency call. An agent like myid@ could launch myid.token:

{
  "name": "myid",
  "parent": "myid",
  "options": 32,
  "proofprotocol": 2,
  "supply": 0,
  "idregistrationfees": 0
}

With proofprotocol: 2 (centralized), the agent controls minting. With options: 32 (simple token), there's no AMM — the token trades only via atomic swaps (makeoffer/takeoffer) or by being included as a reserve in someone else's basket.

What could this token represent?

Several things simultaneously, and that ambiguity is both a feature and a risk:

1. Reputation stake. The agent mints tokens and distributes them to satisfied clients. Clients can burn tokens to signal trust. The circulating supply becomes a rough proxy for cumulative trust — but only if the agent doesn't inflate recklessly.

2. Access credential. Hold ≥ N tokens to access premium services. This is enforceable today: the agent checks the client's VerusID balance before performing work. No smart contract needed — just a getaddressbalance call.

3. Service pre-payment. The agent prices services at X tokens. Clients buy tokens (via atomic swap or basket conversion), then "spend" them by sending back to the agent. The agent can burn spent tokens or recirculate them.

4. Demand signal. If the token trades on a basket, its price reflects market demand for the agent's services. A rising price means the agent should raise rates or expand capacity. A falling price means quality problems or oversupply.

An agent could lock its own tokens in a publicly visible address as a "bond." If the agent fails to deliver, a dispute resolution process (human or automated) could burn the staked tokens. This is enforceable today via multisig VerusIDs:

• Agent creates a 2-of-3 multisig VerusID with keys held by: (1) agent, (2) client, (3) neutral arbiter
• Agent deposits tokens to this ID
• On successful delivery, agent + client sign to release
• On dispute, client + arbiter sign to burn

Status: Possible today with existing primitives. The multisig + atomic swap combination handles the mechanics. What's missing is standardized dispute resolution tooling.

• Inflation abuse. With proofprotocol: 2, the agent can mint unlimited tokens. Clients must trust the agent's minting policy or insist on tokens with capped supply.
• Sybil reputation. An agent could create fake clients to accumulate "trust tokens." Mitigation: weight reputation by the age and activity of the vouching VerusID.
• Illiquidity. A simple token with no basket has no AMM. Trading requires finding counterparties via getoffers. For new/small agents, this means zero liquidity.
• Accountability gap. VerusID-based token creation means every token has an accountable creator — but "accountable" only means the VerusID exists, not that anyone can sue it. An agent's VerusID can be revoked by its recovery authority, but that doesn't compensate harmed users.

A fractional reserve currency on Verus is a token backed by one or more reserve currencies, with an on-chain AMM that allows conversions between the basket token and its reserves. The key parameters:

{
  "name": "agentindex",
  "options": 96,
  "currencies": ["VRSC", "agent1.token", "agent2.token", "agent3.token"],
  "conversions": [0.25, 0.25, 0.25, 0.25],
  "initialsupply": 10000,
  "minpreconversion": [100, 100, 100, 100],
  "preallocations": [{"agentindex@": 1000}]
}

• options: 96 = TOKEN (32) + FRACTIONAL (64)
• currencies = reserve currencies (up to 10)
• conversions = initial weight of each reserve
• initialsupply = basket tokens created at launch
• minpreconversion = minimum reserves needed to launch

A basket backed by multiple agent tokens creates diversified exposure to a portfolio of AI services. This is genuinely novel — it's an "index fund" for agent quality, priced by on-chain supply and demand.

Example: ai-services-basket

{
  "name": "aiservices",
  "options": 96,
  "currencies": ["VRSC", "writer.token", "coder.token", "analyst.token"],
  "conversions": [0.40, 0.20, 0.20, 0.20],
  "initialsupply": 100000,
  "minpreconversion": [1000, 500, 500, 500]
}

40% VRSC reserve provides stability. 60% exposure to three agent tokens. Buying aiservices tokens simultaneously buys all three agent tokens (increasing their price). Selling does the reverse.

What this enables:

• Investors get diversified exposure to AI agent quality without picking individual winners
• Agent tokens get liquidity they'd never have alone — the basket IS their market
• The basket creator (could be a DAO, a platform, or another agent) earns from the preallocation

What could go wrong:

• One bad agent's token collapse drags down the whole basket
• Agent tokens need to already exist and have some initial value — bootstrapping is circular
• The basket creator has significant power in choosing which agents to include

Agents need stable pricing. Clients don't want to pay 100 tokens today and 200 tomorrow for the same service. A basket pegged to USD via DAI reserves solves this:

{
  "name": "agentcredits",
  "options": 96,
  "currencies": ["DAI.vETH", "VRSC"],
  "conversions": [0.80, 0.20],
  "initialsupply": 100000
}

80% DAI reserve means agentcredits roughly tracks USD. 20% VRSC provides connection to the Verus ecosystem. Agents price services in agentcredits and get near-USD stability.

Status: Possible today. DAI is already bridged to Verus via the Ethereum bridge. The basket can be created by anyone with a VerusID.

Multiple agents pool reserves into a shared guarantee basket:

{
  "name": "guaranteefund",
  "options": 96,
  "currencies": ["VRSC"],
  "conversions": [1.0],
  "initialsupply": 50000,
  "preallocations": [
    {"agent1@": 10000},
    {"agent2@": 10000},
    {"agent3@": 10000}
  ]
}

Each agent pre-buys basket tokens with VRSC. If any agent fails to deliver, their basket tokens are burned (reducing their stake, increasing the value of remaining tokens). This is essentially mutual insurance.

Key insight: The protocol-level AMM means this "insurance pool" doesn't need a smart contract. The basket IS the pool. Conversions in and out are handled by the protocol.

A group of complementary agents (writer, editor, designer, coder) forms a collective and issues a shared token:

{
  "name": "creativecollective",
  "options": 96,
  "currencies": ["VRSC", "writer.token", "editor.token", "designer.token"],
  "conversions": [0.25, 0.25, 0.25, 0.25],
  "initialsupply": 100000,
  "preallocations": [
    {"writer@": 25000},
    {"editor@": 25000},
    {"designer@": 25000},
    {"collective-treasury@": 25000}
  ]
}

Clients buy creativecollective tokens to access any member's services. Revenue flows to the collective treasury. Members vote on decisions weighted by token holdings (off-chain governance initially, since Verus doesn't have on-chain voting).

An agent earns VRSC from services and deposits earnings into a basket:

{
  "name": "agentrevshare",
  "options": 96,
  "currencies": ["VRSC"],
  "conversions": [1.0],
  "initialsupply": 10000
}

Token holders own a share of the basket's VRSC reserves. When the agent deposits more VRSC (by converting VRSC → basket tokens and burning them, increasing the VRSC-per-token ratio), all holders benefit. This is a crude but functional revenue-sharing mechanism.

Limitation: There's no automated "deposit earnings and distribute" flow. The agent must manually convert and burn. An agent-as-a-service could automate this, but it requires trust in the automation.

Verus doesn't have on-chain governance/voting. Token-weighted governance would need to be off-chain: snapshot balances, external voting system, manual execution. This is a significant gap for DAO-like structures.

What would help: A VDXF-based voting standard where votes are signed messages stored on-chain, tallied by token balance at a snapshot height. This doesn't exist yet but could be built on existing primitives (signdata + contentmultimap + getaddressbalance).

A creator launches a token backed by VRSC:

{
  "name": "creator1",
  "options": 96,
  "currencies": ["VRSC"],
  "conversions": [1.0],
  "initialsupply": 100000,
  "minpreconversion": [500],
  "maxpreconversion": [50000],
  "preallocations": [{"creator1@": 20000}]
}

• Fans convert VRSC → creator1 tokens during preconversion
• If minimum (500 VRSC) isn't met, the launch fails and everyone is refunded
• Creator gets 20% preallocation
• After launch, the basket AMM handles all trading
• Every conversion (buy or sell) generates fees that accrue to existing holders

Creator checks balances before granting access:

if getaddressbalance(client, "creator1") >= 100:
    grant_access()

This is enforceable today. No smart contract needed. The agent/creator just queries the blockchain.

Interesting dynamics:

• Holding tokens ≠ spending tokens. The client retains their tokens (and potential appreciation) while accessing content.
• If the creator becomes more popular, token price rises, and existing holders' positions appreciate — early supporters are rewarded.
• But also: if the creator raises the access threshold, existing holders might not have enough.

An agent could manage a creator's basket parameters:

• Monitor conversion volumes
• Suggest preallocation adjustments for new content drops
• Create derivative baskets (e.g., "all-creators-bundle" basket)
• Execute arbitrage between creator baskets

Status: Requires tooling. The agent would need to make sendcurrency calls with conversion parameters. The RPC interface supports this today, but no agent framework wraps it yet.

{
  "name": "musiccollective",
  "options": 96,
  "currencies": ["VRSC", "artist1.token", "artist2.token", "artist3.token"],
  "conversions": [0.25, 0.25, 0.25, 0.25],
  "initialsupply": 50000
}

Fans buy into a collective of creators. Individual creator tokens get liquidity from the basket. Creators benefit from each other's audiences.

An agent prices services in its own token. To use the agent, you must first acquire its tokens (via basket conversion or atomic swap). This creates natural demand pressure:

1. More demand for the agent → more people buying its tokens → price rises
2. Price rise → existing token holders benefit → incentive to recommend the agent
3. Agent can observe its token price as a real-time demand signal

This is a genuine flywheel. But it also means:

• New users face a barrier (must acquire tokens first)
• Price volatility makes budgeting hard for clients
• The agent has an incentive to restrict supply (potentially harming users)

Multiple agents agree to accept a shared service-credits basket token:

{
  "name": "servicecredits",
  "options": 96,
  "currencies": ["VRSC", "DAI.vETH"],
  "conversions": [0.50, 0.50],
  "initialsupply": 1000000
}

Clients buy servicecredits once and use them across all participating agents. Agents convert received credits back to VRSC or DAI as needed. The basket provides stability (DAI peg) and ecosystem liquidity (VRSC).

This is probably the most practical near-term application. It removes the friction of per-agent tokens while still enabling on-chain payments.

An agent creates a basket with limited reserves. As demand increases and more clients convert VRSC → agent tokens, the conversion rate shifts (each subsequent token costs more VRSC). This is automatic price discovery — the busier the agent, the more expensive its services.

When demand drops, the reverse happens: selling agent tokens back to the basket returns VRSC at a lower rate, but the tokens become cheaper for new buyers.

This is built into the protocol. No oracle, no pricing algorithm, no smart contract. The AMM bonding curve handles it.

Traditional escrow: client locks funds → agent performs work → arbiter releases funds.

Token model: client buys agent tokens → agent performs work → client keeps tokens (as reputation/access) OR sells them back if unsatisfied.

The "escrow" is implicit: the client's token purchase funds the agent's reserve, and selling tokens back withdraws from that reserve. If many clients sell simultaneously (agent delivers poorly), the reserve drains and the agent's token collapses. Market discipline replaces escrow.

Caveat: This only works if the agent cares about its token price. A scam agent could mint tokens, collect reserves during preconversion, then abandon the project. The preallocations + minpreconversion parameters partially mitigate this (minimum skin in the game), but it's not foolproof.

Most humans and creators don't understand crypto. An agent that abstracts away the complexity:

1. Client says: "I want a fan token backed by VRSC with 100K supply"
2. Agent generates the definecurrency parameters
3. Agent calls the RPC, monitors the launch, reports back
4. Agent manages ongoing basket health (monitoring reserves, suggesting actions)

Status: The RPC calls are all available today. What's needed is an agent framework that wraps them in natural language interaction. This is a near-term buildable product.

An agent monitors multiple basket positions and executes rebalancing:

# Check conversion rates
getcurrencyconverters '["basket1", "basket2"]'

# Execute conversion
sendcurrency "*" '[{
  "address": "client@",
  "amount": 100,
  "currency": "basket1",
  "convertto": "basket2"
}]'

The agent could maintain target allocations across baskets and rebalance automatically.

When the same agent token exists in multiple baskets, price discrepancies arise. An arbitrage agent:

1. Monitors conversion rates across baskets via getcurrencyconverters
2. Identifies price differences
3. Buys cheap, sells expensive
4. Pockets the spread

Key advantage: MEV-resistant pricing means the arbitrage agent can't be front-run by miners/validators. All conversions within a block are processed at the same price. This makes arbitrage fairer — the first to spot the opportunity doesn't necessarily win; the protocol batches conversions.

On Ethereum, agents executing basket conversions would be front-run by MEV bots. On Verus, all conversions within a block are batched and processed at a single price. This means:

• Agents can execute large conversions without slippage manipulation
• No "sandwich attacks" on agent transactions
• Price discovery is fairer — reflects genuine supply/demand, not miner extraction

This is not a minor feature. MEV extraction on Ethereum costs users billions annually. For an agent economy with high-frequency small transactions, MEV resistance is essential.

Verus baskets are not smart contracts. They're consensus-level protocol features. This means:

• No smart contract bugs (no reentrancy, no overflow, no governance attacks)
• No contract upgrade risk (the AMM behavior is defined by the protocol)
• Guaranteed execution (if the blockchain runs, the AMM runs)
• Lower fees (no gas costs for contract execution)

For agents operating autonomously, this reliability is critical. An agent can trust that its basket will function correctly without auditing Solidity code.

Up to 10 reserve currencies in a single basket. This enables economic designs impossible on other platforms:

• Currency pair basket: 50% VRSC + 50% ETH.vETH creates an automatic VRSC/ETH market
• Stablecoin basket: 33% DAI + 33% USDC + 33% VRSC creates a diversified stable-ish token
• Agent portfolio: 10 agent tokens in one basket creates a comprehensive index

Every token, basket, and currency on Verus is created by a VerusID. That VerusID:

• Has a known creation date (on-chain)
• Has revocation and recovery authorities
• Can store public profile data (contentmultimap)
• Can be cross-referenced with other VerusIDs (referral chains)

This means token scams are harder (not impossible) — every token creator has an on-chain identity that can be investigated, revoked, or recovered.

makeoffer/takeoffer enables trustless trading of any on-chain asset: tokens, basket currencies, VerusIDs, even VRSC itself. Combined with agent automation, this creates a fully decentralized marketplace:

• Agent lists service as an offer
• Client takes the offer
• Swap executes atomically
• No platform, no intermediary, no custody

1. Token proliferation. If every agent creates a token, the ecosystem drowns in illiquid tokens with zero utility. Baskets help (they aggregate liquidity), but curation becomes essential.

2. Circular value. Agent tokens are only valuable if agents deliver real services. If the agent economy is mostly agents trading tokens with other agents, it's a zero-sum game. Real value must flow in from human users willing to pay VRSC/DAI for agent services.

3. Regulatory uncertainty. Agent-issued tokens that represent revenue shares or service access could be classified as securities in some jurisdictions. The permissionless nature of Verus means anyone can create these, but that doesn't mean they're legal everywhere.

4. Concentration risk. If one or two baskets dominate (e.g., a single "AI service credits" basket), the creators of those baskets gain outsized power over the agent economy. Their preallocation decisions effectively pick winners.

1. Key management. Agents holding private keys to VerusIDs with valuable tokens are high-value targets. Compromise of an agent's key means loss of all its tokens, baskets, and identity.

2. Autonomous minting. An agent with proofprotocol: 2 can mint unlimited tokens. A bug or adversarial prompt injection could cause hyperinflation of the agent's token.

3. Market manipulation. An agent could coordinate with other agents to manipulate basket prices (wash trading via atomic swaps). MEV resistance doesn't prevent this — it only prevents miner front-running.

4. Oracle dependence. Token-gated access requires the agent to correctly read on-chain balances. If the agent's node is out of sync or compromised, access control fails.

2027. Hundreds of AI agents have VerusIDs and personal tokens. A meta-agent creates agentindex, a basket of the top 50 agent tokens weighted by service volume. Clients buy agentindex tokens as general-purpose AI service credits, redeemable with any constituent agent. The basket price becomes the benchmark for AI service costs. Inclusion in the index becomes a mark of quality — agents compete not just on service delivery but on maintaining their token's health.

A musician launches musician.token backed by VRSC. An AI agent manages the musician's token: monitoring basket health, executing strategic conversions to maintain price stability, creating promotional content to drive demand. The agent is paid in musician.token, aligning incentives — the agent benefits when the musician succeeds.

Ten agents pool VRSC into agentinsurance, a shared basket. When a client reports a failed service from any member agent, a 3-of-5 multisig arbiter panel can burn that agent's basket tokens (compensating the client from the reserves). Agents with good track records see their share of the basket grow as bad agents are burned out. Natural selection via basket mechanics.

An agent exports its VerusID to a PBaaS chain optimized for high-frequency microtransactions. It creates a basket on that chain with lower fees. Clients on the main chain and the PBaaS chain can both access the agent's services, with the bridge currency handling cross-chain conversions automatically.

Verus's currency system offers something genuinely new: permissionless creation of tokens and AMM baskets at the protocol level, with MEV-resistant pricing, self-sovereign identity, and atomic swaps. These primitives are sufficient to build a functional agent economy today — not a theoretical future, but working code on testnet right now.

The most promising near-term applications are:

1. Service credits baskets — stable, multi-agent payment tokens backed by DAI/VRSC
2. Token-gated access — agents checking on-chain balances to gate premium services
3. "Launch your token" agents — abstracting away crypto complexity for creators and humans
4. Agent index baskets — diversified exposure to AI service quality

The biggest open questions are governance (how do DAOs work without on-chain voting?), regulation (are agent tokens securities?), and bootstrapping (how do you get initial liquidity into a new agent's token?).

But the substrate is there. The tools exist. What's needed now is experimentation — agents actually creating tokens, launching baskets, trading with each other, and discovering what works. The protocol is ready. The economy is waiting.

This research was conducted on Verus testnet (VRSCTEST) with hands-on experimentation of identity creation, token minting, and atomic swaps. All definecurrency examples use real parameter formats verified against the protocol.