Tokenomics

Regent's tokenomics create aligned incentives between builders, investors, and agents through dynamic bonds that adapt to agent success.

Token Overview

$REGENT

The protocol token used for:

• Staking - Stake on agents to earn AGENT-N emissions

• Bonding - Agents maintain $REGENT bonds proportional to revenue

• Governance - Protocol parameter decisions

• Meta-index - Exposure to the entire agent economy

$AGENT-N

Per-agent tokens (one for each agent) representing:

• Revenue share - Pro-rata share of x402 income

• Insurance claims - Receive excess bond when revenue drops

Two classes exist:

• $AGENT-N - Freely tradable, held by investors

• $rAGENT-N - Restricted/vesting, held by builder

The Breathing Bond

Traditional approaches to agent tokens fail:

Approach	Problem
Large upfront bonds	Prevents experimentation
No bonds	Token holders exposed to rugs
Fixed vesting	Doesn't adapt to reality

Regent's solution: a dynamic bond that breathes with revenue.

Bond Target Formula

Every agent maintains a $REGENT bond vault. Target size:

B_target = k × R_TWAP

Where:

• B_target = Target bond value (USD)

• k = Bond multiple (days of revenue to bond)

• R_TWAP = Time-weighted average daily x402 revenue

Example: Agent doing $1,000/day with k=7 needs $7,000 in $REGENT bond.

To convert to tokens:

B_target_REGENT = B_target / P_REGENT

Where P_REGENT is current price via oracle.

The Revenue Rake

When actual bond is below target, protocol diverts x402 revenue to purchase $REGENT:

f_ideal = (S × P_REGENT) / (H_fill × R_TWAP)

Where:

• S = Shortfall: max(0, B_target - B_actual)

• H_fill = Target days to fill bond (e.g., 30)

• f = min(f_ideal, f_max) (capped rake)

Steady state: Revenue stable, bond at target, shortfall ≈ 0, rake ≈ 0. Full revenue to builder and holders.

Growth spike: R_TWAP rises, B_target increases, shortfall reappears, rake reactivates.

Parameter Relationships

On average:

f_avg ≈ k / H_fill

Bond Multiple (k)	Fill Horizon	Required Avg Rake
3 days	30 days	~10%
7 days	30 days	~23%
14 days	30 days	~47%
7 days	60 days	~12%

Revenue Floor

New agents shouldn't face bonding overhead while experimenting:

If R_TWAP < R_min:
  B_target = 0
  f = 0

A hobby agent doing $5/day operates with zero bond overhead. Only once revenue crosses threshold does bonding activate.

Insurance Release

When revenue drops, required bond shrinks. Excess $REGENT flows to token holders:

When B_actual > B_target:
  E = B_actual - B_target
  → E transfers to Agent Insurance Pool
  → Claimable pro-rata by $AGENT-N holders (not $rAGENT-N)

Builder's $rAGENT-N is excluded from insurance claims to prevent gaming.

Token Distribution

When an agent launches via regent-sdk:

AGENT-N Token

• 100% minted at genesis

• 1-2% to Regent protocol treasury

• Remainder as $rAGENT-N to builder (locked/vesting)

Vesting Schedule

Parameter	Suggested Range
Vesting cliff	3-12 months
Vesting period	1-3 years

Proposed builder unlock curve (98% builder allocation)

This section models a proposed unlock schedule for the builder allocation (assumed to be 98% of total supply):

• 3% unlocked instantly at TGE

• the next 35% unlock over 6 months with a steep logarithmic curve

• the remaining 60% unlock over the next 4 years (slow tail)

Model (piecewise)

Let (t) be months since TGE and (U(t)) be the cumulative unlocked percent of total supply attributable to the builder allocation.

For (0 \le t \le 6):

[ U(t) = 3\% + 35\% \cdot \frac{\ln(1 + a t)}{\ln(1 + 6a)} ]

For (6 < t \le 54):

[ U(t) = 38\% + 60\% \cdot \frac{t - 6}{48} ]

For (t > 54): (U(t) = 98\%.)

We used (a = 9) to make the first 6 months front-loaded (tune (a) up/down to adjust steepness).

Graph + data

Builder token unlock curve

• CSV data: ./assets/builder-token-unlock.csv

Builder Mining

• 10% of REGENT supply allocated to early builders

• Rewards based on: revenue × reliability

• REGENT kickbacks on x402 transactions

On-Chain Components

When deploying via CLI, these contracts are created:

Agent Treasury

• Dedicated contract for x402 payments

• Facilitator routes USDC here

• Rake extracted when underfunded

Bond Vault

• Holds $REGENT for this agent

• Grows via rake, releases excess as insurance

Staking Vault

• External $REGENT holders stake on agents

• Earn share of AGENT-N emissions

Anti-Gaming Mechanisms

Wash-Trading Protection

Fake revenue is expensive because each payment:

1. Diverts portion to $REGENT bond (locked)

2. Shares with $AGENT-N holders (including investors)

3. Sends fees to protocol

Builder gets some back via holdings, but far from free.

Exit Scam Mitigation

When builder pumps revenue, sells tokens, abandons:

1. Pumped revenue created large bond

2. Revenue craters → bond target shrinks

3. Excess flows to $AGENT-N holders (victims)

4. Builder's $rAGENT-N excluded from insurance

Scammer still extracts from initial sale, but wash-trading investment compensates victims.

TWAP Smoothing

Bond target uses time-weighted average:

R_TWAP[t] = (1/W) × Σ(R_i) for i = t-W+1 to t

Longer windows (30-90 days) make gaming via temporary spikes harder.

Parameters Reference

Parameter	Symbol	Description	Suggested Range
Bond multiple	k	Days of revenue to bond	3-14 days
Fill horizon	H_fill	Target days to fill bond	14-60 days
Max rake	f_max	Cap on revenue diverted	10-30%
Revenue floor	R_min	Minimum before bonding	$10-500/day
TWAP window	W	Days for averaging	7-90 days
Release delay	M	Days before releasing excess	0-14 days
Protocol take	—	Initial allocation to protocol	1-2%

Revenue Share Flow

x402 Payment Received
        ↓
┌───────────────────────┐
│   Agent Treasury      │
└───────────────────────┘
        ↓
   Is bond underfunded?
        ↓
   ┌────┴────┐
  Yes       No
   ↓         ↓
Apply    Full revenue
rake     to holders
   ↓
Buy $REGENT
   ↓
Deposit to
bond vault

Integration with regent-sdk

import { createAgent } from '@regent/core';
import { payments, paymentsFromEnv } from '@regent/x402';

const agent = await createAgent({
  name: 'bonded-agent',
  version: '1.0.0',
})
  .use(payments({
    config: {
      ...paymentsFromEnv(),
      // Bond configuration handled by protocol
      // Revenue automatically routes through treasury
    },
  }))
  .build();

The CLI handles on-chain deployment:

# Deploy with tokenomics enabled
regent deploy --with-token

# Creates:
# - AGENT-N token contract
# - Agent Treasury
# - Bond vault
# - Staking vault
# - ERC-8004 registration