# Giants — Tokenomics Lab
> Tokenomics design and implementation for Web3 protocols. Free knowledge base, models, calculators, and real-world case studies.
Site: https://giantslabs.pro/
Language: en
Author: Alexey Karanyuk
Generated: 2026-08-27
Total pages: 95
Index file: https://giantslabs.pro/llms.txt
This file: https://giantslabs.pro/llms-full.txt
AI policy: https://giantslabs.pro/ai.txt
This is the full-text dump of every article on the site, prepared for LLM ingestion (retrieval and training). Content is in markdown. Attribution to the source is required when content is cited.
---
# Section: Basics
## Section landing: Tokenomics Fundamentals
- URL: https://giantslabs.pro/basics/
- Kind: section landing
- Section: basics
- Description: Core concepts of token economics: definitions, stakeholder analysis, and the design process.
---
## Stakeholders in Tokenomics
- URL: https://giantslabs.pro/basics/stakeholders/
- Section: basics
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Stakeholder typology for token economic models: roles, interests, conflicts. Motivation-horizon matrix, utility function, and a sell pressure calculator.
Most projects start tokenomics design with a pie chart: 30% team, 20% investors, 15% ecosystem. But where did these numbers come from? Why 30% and not 15%? Why these specific groups? Without answering **"for whom are we designing and why each group needs the token"**, the allocation is random — not designed.
{{< callout title="Note on numbers in this article" type="info" >}}
The allocation splits and sell-probability ranges below are **illustrative modeling priors**, not empirical industry benchmarks or recommendations. They are the kind of defaults a designer picks before calibrating against data. For actual 2025 empirical ranges (team, investor, community allocations and post-unlock behavior), see [vesting benchmarks]({{< relref "knowledge/vesting-benchmarks" >}}).
{{< /callout >}}
Stakeholders are the starting point of any token economic model. Their composition, motivation, and time horizon determine every subsequent decision: allocation, vesting, supply model, utility mechanisms. This article provides a complete stakeholder typology, an analytical framework for their interests, and a practical approach to balancing them.
## What Are Stakeholders
A **stakeholder** is any participant who influences the ecosystem or depends on it. In traditional loyalty systems (Web2), the project fully controls the economy: issues points, sets exchange rules, and can change terms unilaterally.
In tokenized systems (Web3), the situation is fundamentally different:
| Characteristic | Loyalty system (Web2) | Tokenized system (Web3) |
|---|---|---|
| Control | Project manages points | Stakeholder owns the token |
| Transferability | Points are non-transferable | Token is freely tradeable |
| Pricing | Fixed rate set by project | Market price on exchange |
| Decisions | Project decides for user | Stakeholder makes independent decisions |
| Ecosystem | Closed | Open (independent services, DEXs) |
{{< callout title="Key difference" >}}
In Web2, the project "manages" user behavior through points. In Web3, a stakeholder is an independent economic agent with their own utility function. They can sell the token, stake it, vote against the team's proposal, or leave the ecosystem entirely. The tokenomist's job is to design a system where rational behavior by each stakeholder leads to overall ecosystem sustainability.
{{< /callout >}}
## Stakeholder Typology
Stakeholders fall into two groups by their interaction horizon: **short-term** and **long-term**. This distinction is critical for design: short-term participants create liquidity and attention, long-term ones create sustainability and value.
### Short-Term Stakeholders
These participants come for quick gains. They don't plan to stay in the ecosystem for years, but they serve a vital function — bringing capital and attention.
| Stakeholder | Interest | What the system gets |
|---|---|---|
| **Speculators** | Quick profit, calculated returns | Capital inflow, trading volume, buzz |
| **Traders** | Profit from volatility and arbitrage, high liquidity | Liquidity provision, price discovery |
| **Influencers** | Access to exclusive opportunities, promotion rewards | Marketing, new user acquisition |
### Long-Term Stakeholders
These participants form the ecosystem's foundation. Their departure destroys the system, so tokenomics must provide them with sustainable motivation.
| Stakeholder | Interest | What the system gets |
|---|---|---|
| **Users** | Useful, secure product; usage rewards | Active usage, feedback, new participant referrals |
| **Gamers** (in GameFi) | Engaging gameplay, fair rewards, asset earnings | Active participation, asset spending, content creation |
| **Community** | Exclusive access, ability to influence the project | Marketing, brand image, new participant referrals |
| **Market makers** | Income from price management and liquidity, arbitrage | Price stability, reduced volatility |
| **Team and advisors** | High income, a great product or landmark project | Achieving product goals, loyalty, connections and expertise |
| **Validators** | Predictable sustainable income, governance participation | Network uptime, governance participation, security |
| **Liquidity providers** | Predictable passive income, rewards | Liquidity provision, price stability |
| **Investors** | High return-to-risk ratio, growth potential, transparency | Early-stage capital, connections and expertise |
## Stakeholder Matrix
The typology shows who participates in the system. But for designing tokenomics, you need a practical tool — the **stakeholder matrix**. For each participant, define three parameters: motivation, token acquisition model, and holding horizon.
| Stakeholder | Motivation | Acquisition model | Horizon |
|---|---|---|---|
| **Team** | Project growth, reputation | [Allocation]({{< relref "models/allocation" >}}) (cliff + linear vesting) | 3–5 years |
| **Investors** | Return relative to risk | Allocation (cliff + vesting) | 1–3 years |
| **Users** | Product access, rewards | Airdrop, reward | Ongoing |
| **Validators** | Stable income, influence | Reward (validation emissions) | 2–5 years |
| **Liquidity providers** | Fees, rewards | Reward (LP incentives) | 6–18 months |
| **Treasury** | Ecosystem development | Allocation | Indefinite |
{{< formula math="Vesting_horizon(i) ≥ Holding_horizon(i)" >}}
- Vesting_horizon(i) — duration of vesting + cliff for stakeholder i (months)
- Holding_horizon(i) — operationally: the time needed for stakeholder i to deliver the value they were brought in for. For the team — product maturation window (typically 3–5 years to a working product at scale). For investors — expected holding period in their fund thesis (typically 1–3 years). For liquidity providers — the period until organic liquidity replaces incentivized liquidity (typically 6–18 months)
- Design rule: a stakeholder's vesting must not be shorter than their expected horizon
- Otherwise the stakeholder receives tokens and leaves before creating value
{{< /formula >}}
{{< callout title="One stakeholder — one supply model" >}}
Don't mix models: if the team receives tokens through allocation, don't add rewards on top. It complicates the system and dilutes incentives. Exceptions are possible (e.g., a team member who also validates receives both allocation and validation rewards), but they must be justified.
{{< /callout >}}
## Conflicts of Interest
The hardest part of working with stakeholders is managing conflicts. Each group has its own **utility function**, and these functions contradict each other.
{{< formula math="U(i) = R(i) − C(i)" >}}
- U(i) — stakeholder i's utility function
- R(i) — benefit from participation (income, access, influence)
- C(i) — costs (time, capital, risk)
- A stakeholder stays in the system as long as U(i) > 0
{{< /formula >}}
Worked examples of R and C by group:
| Stakeholder | R(i) — benefits | C(i) — costs |
|---|---|---|
| **Team** | Salary in tokens + allocation upside, reputation, control | Time (years of product work), opportunity cost of other offers, reputational risk if project fails |
| **Investors** | Token appreciation relative to entry price, pro-rata in follow-ons | Capital locked during vesting, fund illiquidity, portfolio risk |
| **Users** | Product utility, rewards, airdrop value | Gas fees, time to learn the product, counterparty risk |
| **Validators** | Staking rewards + fees, governance influence | Hardware + infra costs, slashing risk, stake locked |
| **Liquidity providers** | Trading fees + LP incentives | Impermanent loss, smart-contract risk, opportunity cost of capital |
### Team vs Investors
| Parameter | Team's interest | Investors' interest |
|---|---|---|
| Vesting duration | Longer (tie to results) | Shorter (faster profit realization) |
| TGE unlock | Minimal (less price pressure) | Maximum (immediate liquidity) |
| Valuation | Higher (less dilution) | Lower (more tokens for the same money) |
**Resolution:** investor cliff no shorter than 6 months post-TGE, team vesting at least 12 months longer than investor vesting. A common concrete instantiation of this rule in 2025 is **team 4-year vesting with a 1-year cliff** against **investor 2–3-year vesting with a 6-month cliff** — giving the team roughly 12–24 months of additional runway beyond the investor tail.
### Investors vs Users
Investors receive tokens at a discount to market price. When vesting ends, they sell — creating price pressure. Users who bought on the open market lose value.
{{< formula math="Pressure(t) = Σ Unlock(i, t) × P_sell(i)" >}}
- Pressure(t) — aggregate sell pressure in month t
- Unlock(i, t) — stakeholder i's unlock in month t
- P_sell(i) — sell probability for group i
- **Priors used below (not empirical benchmarks):** investors P = 0.3–0.7; team P = 0.05–0.15; liquidity providers P ≈ 0.30. These are calibrated modeling defaults, not industry-validated figures — empirical unlock-tracking platforms report price impact and supply overhangs, not per-group sell probabilities. Adjust against observed behavior for your cohort. See [vesting benchmarks]({{< relref "knowledge/vesting-benchmarks" >}}) for the sell-pressure empirical example.
- **First-order approximation:** the formula assumes P_sell is independent of price, unlock size, and time since TGE. In practice all three matter — large unlocks into thin order books and recent-TGE unlocks into weak markets raise P_sell; deep holding after multiple unlocks lowers it.
{{< /formula >}}
**Resolution:** smooth vesting (monthly, not quarterly), cliff after price stabilization, utility mechanisms ([staking]({{< relref "models/staking" >}}), governance) that create alternatives to selling.
### Traders vs Liquidity Providers
Traders profit from volatility. Liquidity providers earn from fees but lose to impermanent loss (IL), which grows with volatility. The better it is for traders, the worse for LPs.
**Resolution:** concentrated liquidity, dynamic fees, IL compensation through additional reward incentives.
### Quantitative Conflict Example
Consider a project with total supply of 100,000,000 tokens. The 20 / 15 / 30 / 20 / 15 split below is **illustrative only, not a recommendation**. For context, 2025 industry benchmarks cluster as: Community + Ecosystem 35–45% (often > 50% combined), Team 17–20%, Investors 12–18%, Treasury 20–25%. The example here runs Community slightly low to keep the arithmetic clean — see [vesting benchmarks]({{< relref "knowledge/vesting-benchmarks" >}}) for current ranges.
| Group | Allocation | Vesting | TGE unlock | Sell pressure (month 13) |
|---|---|---|---|---|
| Team | 20% | 48 mo, 12-mo cliff | 0% | 20M × (1/36) × 0.10 = 55,556 |
| Investors | 15% | 24 mo, 6-mo cliff | 5% | (15M − 750K) × (1/18) × 0.50 = 395,833 |
| Community | 30% | None (airdrop + reward) | — | Depends on mechanisms |
| Treasury | 20% | DAO-managed | 0% | 0 (locked) |
| Liquidity | 15% | 12 mo linear | 20% | 0 (vesting completed at month 12) |
In month 13, investors create 7.1x more sell pressure than the team (liquidity vesting has already finished by then). This is a predictable conflict — it must be offset by utility mechanisms that create demand.
Python: sell pressure calculation by month
```python
import json
stakeholders = {
"Team": {"alloc": 20_000_000, "cliff": 12, "vesting": 48, "tge": 0.00, "p_sell": 0.10},
"Investors": {"alloc": 15_000_000, "cliff": 6, "vesting": 24, "tge": 0.05, "p_sell": 0.50},
"Liquidity": {"alloc": 15_000_000, "cliff": 0, "vesting": 12, "tge": 0.20, "p_sell": 0.30},
}
results = []
for month in range(1, 49):
pressure = {}
for name, s in stakeholders.items():
tge_tokens = s["alloc"] * s["tge"]
remaining = s["alloc"] - tge_tokens
vesting_months = s["vesting"] - s["cliff"]
if vesting_months <= 0:
monthly_unlock = 0
elif month <= s["cliff"]:
monthly_unlock = 0
elif month <= s["vesting"]:
monthly_unlock = remaining / vesting_months
else:
monthly_unlock = 0
pressure[name] = round(monthly_unlock * s["p_sell"])
pressure["month"] = month
pressure["total"] = sum(v for k, v in pressure.items() if k != "month")
results.append(pressure)
# Peak pressure months
peak = max(results, key=lambda x: x["total"])
print(f"Peak pressure: month {peak['month']}, {peak['total']:,} tokens")
for name in stakeholders:
print(f" {name}: {peak[name]:,}")
```
## Common Stakeholder Analysis Mistakes
{{< checklist title="Mistake checklist" type="check" >}}
Forgotten stakeholders: market makers, exchanges, and auditors are overlooked. Each affects the token economy and belongs in the matrix
Copy-pasting allocations: "Project X has 48% for ecosystem, let's do the same." But the context is different — different stakeholders, market, and product. Numbers must flow from your matrix, not someone else's whitepaper
Identical vesting for all: if team and investors unlock on the same schedule, there's no incentive for collaboration. Vesting is a tool for horizon alignment, not a formality
Ignoring short-term participants: speculators and traders are not enemies. Without them there's no liquidity or price discovery. The question isn't whether to exclude them, but whether their behavior destabilizes the system
No conflict analysis: listing stakeholders isn't enough. You must explicitly map conflicts and resolution mechanisms — otherwise conflicts resolve chaotically, usually in favor of large holders
{{< /checklist >}}
## From Stakeholders to Supply Models
Stakeholder analysis is the second stage of the [tokenomics design process]({{< relref "basics/tokenomics-process" >}}). The output is a completed matrix where each stakeholder's motivation, acquisition model, and horizon are defined. The matrix then drives the choice of [supply models]({{< relref "models/token-supply-models" >}}):
| If the stakeholder needs... | Supply model |
|---|---|
| Fixed share of total supply | [Allocation]({{< relref "models/allocation" >}}) (with vesting) |
| Reward for a targeted action | Reward or airdrop |
| Tie to market demand | Bonding curve or DEX |
Each stakeholder maps to a specific supply model. If you can't find a model for a stakeholder, reconsider whether they need the token at all. Sometimes stablecoin payments or fiat compensation is a more honest solution than tokenization for its own sake.
Stakeholders also define requirements for [mechanism design]({{< relref "models/mechanism-design" >}}): what incentives and penalties are needed so that honest behavior by each participant leads to system-wide sustainability.
{{< cta title="Need help with stakeholder analysis?" text="We've mapped stakeholder ecosystems for 85+ projects — from DeFi to GameFi. We identify conflicts, design resolution mechanisms, and build allocation models grounded in your matrix." button="Get in touch" link="/quote/" >}}
---
## The Tokenomics Design Process
- URL: https://giantslabs.pro/basics/tokenomics-process/
- Section: basics
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Complete tokenomics design process: from market research to final documentation. Stages, stakeholders, supply and demand models.
## What Is Tokenomics Design
**Tokenomics design** is the sequential process of engineering a token's economic system. Not "draw a pie chart," not "pick a ticker," and not "decide what percentage the team gets." It's engineering work: from market research and stakeholder analysis to parameter balancing and final documentation.
The process has two components: **design**, which answers **"what to build and for whom,"** and **modeling**, which validates decisions with numbers ("how to calculate"). Both parts are essential and inseparable, but their sequence determines the quality of the outcome.
Without a structured process, projects make random decisions: copy someone else's allocations, choose parameters by gut feel, forget entire stakeholder groups. The result — a system that falls apart at first contact with reality. The process ensures every decision is justified and verifiable.
{{< callout title="Core principle" >}}
Tokenomics design is not a one-time action but a sequence of stages where each step builds on the results of the previous one. Skipping a stage means making decisions without foundation.
{{< /callout >}}
## Six Stages of Tokenomics Design
The process consists of six sequential stages. Each builds on the previous. Skipping is not an option — otherwise decisions are made in a vacuum.
1. **Research.** Study the market, competitors, and regulatory landscape. What tokenomics already exist in the niche? What works, what failed? What constraints does the jurisdiction impose?
2. **Stakeholder analysis.** Identify all ecosystem participants: who they are, what motivates each, where their interests overlap and conflict.
3. **Supply design.** How and to whom tokens are distributed: vesting, airdrop, reward, bonding curve. Choose an emission model for each stakeholder.
4. **Demand design.** Why would anyone need this token? Utility mechanisms: governance, staking, payment, access, burn. Without demand, supply is just a number series.
5. **System balancing.** Sustainability check: inflation vs. deflation ratio, velocity, scenario analysis. Iterative parameter tuning.
6. **Documentation.** Deliverables: tokenomics document, financial model, distribution tables, technical specification for developers.
{{< callout type="warning" title="Common mistake" >}}
Most projects start at stage three — immediately drawing a pie chart: "30% team, 20% investors." Without research and stakeholder analysis, these numbers are arbitrary. They're not tied to real ecosystem needs.
{{< /callout >}}
## Stakeholder Analysis
A stakeholder is any participant who influences the ecosystem or depends on it. Before designing token distribution, you need to understand: **for whom are we distributing and why each group needs exactly that amount**.
### Typical Stakeholders
- **Founders and team** — build the product, incentivized by long-term price growth
- **Investors** — fund development, expect return on investment
- **Users** — use the product, need clear token value proposition
- **Validators / node operators** — provide infrastructure, motivated by rewards
- **Ecosystem developers** — build applications on top of the protocol, need grants and incentives
- **Treasury / foundation** — reserve for future development, managed through governance
- **Liquidity providers** — ensure the token is tradeable, motivated by yield
- **Partners and advisors** — attract users and capital, compensated for contributions
### Stakeholder Matrix
For each stakeholder, define three things: motivation, token acquisition model, and holding horizon. The diagram above and this matrix are focused views: the matrix details the six primary groups, while the treasury (a governance-managed reserve) and partners/advisors (a secondary allocation group) are covered in the prose list rather than repeated in every representation.
| Stakeholder | Motivation | Acquisition model | Horizon |
|---|---|---|---|
| **Team** | Project growth, reputation | Allocation (cliff + linear vesting) | 3–5 years |
| **Investors** | Return on investment | Allocation (shorter vesting than team) | 1–3 years |
| **Users** | Product access, value | Reward, airdrop | Short-term |
| **Validators** | Infrastructure income | Reward (staking, block rewards) | Medium-term |
| **Developers** | Grants, ecosystem growth | Treasury, grants | Medium-term |
| **LPs** | Yield | Reward (LP incentives) | Short-term |
{{< callout title="Design principle" >}}
The longer the stakeholder's horizon, the longer the vesting should be. Team and investors should not receive tokens before the product is live. This aligns incentives: you can't sell and leave.
{{< /callout >}}
## Supply Design
Supply answers the question: **how and for what does each stakeholder receive tokens**. This is not just "what percentage goes to whom" — it's choosing the distribution mechanism for each group.
### Supply Models
| Model | Mechanism | For whom | When to use |
|---|---|---|---|
| **Allocation** | Fixed share with unlock schedule (vesting) | Team, investors, partners | When time-binding is needed |
| **Bonding curve** | Price is algorithmically set by supply (typically monotonic on mint) | Early users, public sale | When fair pricing without intermediaries is needed |
| **Airdrop** | Distribution for targeted actions | Users, community | When attraction and distribution are needed |
| **Reward** | Compensation for actions | Validators, users, LPs | When behavior needs to be sustained |
| **Market (DEX/CEX)** | Open market, liquidity pools | Any participant | After initial distribution |
For a detailed breakdown of each model, see [5 Token Supply Models]({{< relref "models/token-supply-models" >}}).
{{< callout title="Vesting and cliff are not supply models" >}}
**Vesting** (gradual unlock) and **cliff** (freeze period) are unlock mechanisms, not standalone supply models. They combine with any model: allocation + vesting (classic for teams), reward + vesting (rewards with delayed unlock), bonding curve + vesting (minted tokens unlock gradually).
{{< /callout >}}
### Model Selection Decision Tree
For each stakeholder, ask three questions:
{{< callout title="Rule" >}}
One stakeholder — one supply model. Don't mix: if the team receives tokens through allocation, don't add rewards on top. This complicates the system and dilutes incentives.
{{< /callout >}}
### What Is Vesting and How to Set It Up
Vesting is the most common unlock mechanism for team and investors. Key parameters:
- **Cliff** — period during which no tokens unlock (typically 6–12 months)
- **Duration** — total unlock period (typically 2–4 years)
- **Schedule** — linear, step-function, or exponential
- **Trigger event** — what to count from: TGE, listing, mainnet launch
{{< formula math="Unlocked(t) = Allocation × min(1, max(0, (t − Cliff) / Duration))" >}}
- t — time since TGE (months)
- cliff, duration — in months
- The inner max(0, …) keeps the schedule flat before the cliff; the outer min(1, …) caps it at 100% after full unlock
{{< /formula >}}
## Demand Design
Supply without demand is inflation. If nobody needs to hold the token, it will be sold at the first opportunity. Demand design is the hardest and most important part of a tokenomist's work.
Token demand is created through **utility** — mechanisms that compel participants to buy and hold tokens. The main ones:
### Utility Mechanisms
| Mechanism | How it creates demand | Holding strength | Examples |
|---|---|---|---|
| **Governance** | Voting power proportional to holdings | Medium | Compound, Uniswap |
| **Staking** | Income for locking tokens | High | Ethereum, Cosmos |
| **Payment** | Token as medium of exchange in the ecosystem | Low | Filecoin, Audius |
| **Access** | Token as a key to features or content | Medium | ENS (domains), Helium |
| **Burn** | Tokens destroyed on usage | High | Ethereum (EIP-1559), BNB |
### Why Would Anyone Hold Your Token?
For each mechanism, ask the test question: **"Can the participant get the same value without the token?"** If yes — the mechanism doesn't create real demand. It's fake utility.
- **Governance without influence** — if voting doesn't matter, holding for governance is pointless
- **Payment without discount** — if you can pay with stablecoins and get the same result, a payment token is unnecessary
- **Staking without productive load** — if staking exists only to reduce sell pressure, it's a circular trap
{{< callout type="warning" title="Criterion for real demand" >}}
Real demand is when the participant **cannot** obtain value without the token. Fee burning (Ethereum) works because gas can't be paid any other way. Governance works when the treasury distributes real funds. Staking works when it secures the network.
{{< /callout >}}
### Combining Mechanisms
Strong tokenomics uses 2–3 demand mechanisms that reinforce each other:
- **Staking + governance** — staked tokens grant voting rights (veTokenomics, Curve)
- **Payment + burn** — a portion of payments is destroyed, creating deflation (Ethereum)
- **Work + staking** — operators stake tokens to secure job assignments and earn fees (Chainlink Staking v0.2, The Graph)
## System Balancing
Designing supply and demand separately is not enough. You need to verify the system is sustainable dynamically: in a month, in a year, in five years.
### Inflation and Deflation
Every token entering the market (reward, vesting unlock, airdrop) is inflation. Only tokens that are permanently destroyed (burns, treasury buybacks that are burned) are deflationary — they reduce total supply. Staking locks and ve-locks do **not** reduce supply; they remove tokens from the circulating float, which is a velocity-side effect, not a supply-side one.
{{< formula math="Net_supply_change = Emission − Burn" >}}
- Emissions — new tokens entering circulation (rewards, vesting unlocks, airdrops)
- Burns — tokens permanently destroyed (usage burning, treasury buyback + burn)
- If positive — supply is growing; if negative — the system is deflationary
{{< /formula >}}
Velocity reduction is tracked **separately**, because locked tokens do not disappear — they only leave the circulating float:
{{< formula math="Eff_float = Circulating − Locked − Staked" >}}
- Circulating — total circulating supply
- Locked — locked in vesting, ve-lock, etc. (excludes staked)
- Staked — staked in consensus/protocol (separate from Locked)
- A lower effective float means fewer tokens under real sell pressure
{{< /formula >}}
The goal is not to make the system deflationary (that can kill growth), but to ensure **balance**: supply should grow slower than demand, and a healthy share of float should sit in velocity sinks.
### The Velocity Problem
The velocity problem is one of the key challenges in tokenomics. If a token rapidly changes hands (buy → use → sell), its market value will be low even with high transaction volume.
{{< formula math="M = PQ / V" >}}
- M — required token network value (market cap proxy)
- PQ — transaction volume (economic throughput)
- V — velocity (turnover rate)
{{< /formula >}}
This is the **Burniske INET adaptation** of Fisher's equation of exchange (Chris Burniske, *Cryptoassets*, 2017). In classical macro, M is the money supply; in crypto tokenomics, M is interpreted as **market capitalization** (price × circulating supply). The simplification works well for single-utility tokens but is a loose fit for multi-utility assets — keep the caveat in mind when citing it.
The higher V (velocity), the lower M (market cap) for the same economic throughput. Velocity reduction mechanisms: staking, vesting, lock-up for access.
### Scenario Analysis
To verify system sustainability, run three scenarios:
| Scenario | Assumptions | What to check |
|---|---|---|
| **Optimistic** | Rapid user growth, high staking rate | Token shortage? Rewards too generous? |
| **Base** | Moderate growth, average staking rate | Is inflation sustainable? Enough demand? |
| **Pessimistic** | Slow growth, low staking rate, investor sales | Token devaluation? Treasury sufficient? |
{{< callout title="Key principle" >}}
Tokenomics must work in the pessimistic scenario. If the system is only sustainable under ideal conditions, it will break at the first crisis. Design for the worst, hope for the best.
{{< /callout >}}
## Deliverables
After the design process, the client receives a set of documents and tools. Each artifact serves a specific purpose.
### Tokenomics Document
The core document (20–40 pages) describing the token economy architecture. Includes:
- Token purpose and type (utility, governance, security)
- Stakeholder descriptions and their incentives
- Supply model: allocations, vesting schedules, emission mechanisms
- Demand model: utility mechanisms, value sources
- System parameters: total supply, inflation, burn rate
- Competitor comparison
### Financial Model
A spreadsheet (Google Sheets or Excel) with monthly projections for 3–5 years:
- Emissions by stakeholder per month
- Cumulative and circulating supply
- Staking rate forecast and locked tokens
- Three scenarios (optimistic, base, pessimistic)
- Charts and visualizations
### Distribution Tables
Detailed tables for each group: how many tokens, on what schedule, with what cliff, from what event. These serve as the basis for configuring vesting smart contracts.
### Technical Specification
A specification for developers: which contracts are needed, which parameters to hardcode, which to make configurable, which events to emit. Includes:
- Contract descriptions (vesting, staking, governance, burn)
- Parameters for each contract
- Inter-contract dependencies
- Security and audit requirements
## Common Mistakes
Over years of working with dozens of projects, we've seen the same mistakes repeated. Here are the ten most frequent — and how to avoid them.
### 1. Token for the sake of a token
The project doesn't need a token but launches one "because everyone does." If the product works without a token, a token is unnecessary. Adding one to attract investment is a path to failure.
### 2. Utility overload
The token is assigned 8–10 functions: governance, staking, payment, access, burn, reward, and more. In practice, users pick one or two. The rest is dead weight that complicates the system.
### 3. No real demand
All demand mechanisms are fake. Governance doesn't affect anything, staking exists only to reduce sell pressure, payment can be done without the token. The test: remove the token — what breaks?
### 4. Wrong blockchain choice
Choosing the network before designing tokenomics. Result: transaction fees exceed reward sizes, or the chain doesn't support needed contracts. The blockchain is a tool. First the task, then the tool.
### 5. Short team vesting
The team gets tokens within 6–12 months. The market sees the unlock coming and starts selling in advance. Standard: 12-month cliff, 36–48-month vesting. The team should receive tokens last.
### 6. Ignoring the velocity problem
The token rapidly changes hands, nobody holds. High turnover with low market cap. Solution: slowdown mechanisms — staking, lock-ups, veTokenomics.
### 7. Copy-pasting tokenomics
"Solana has a Community Reserve of ≈38.89%, let's do the same." But the context is different: different stakeholders, different market, different product. Numbers must emerge from your stakeholder matrix, not someone else's whitepaper.
### 8. No treasury
All tokens distributed from day one. A year later, funds are needed for development — but there's nothing to allocate. The treasury is a safety net: 10–20% for future needs.
### 9. Forgotten liquidity
Token launched, but nowhere to buy or sell it. No liquidity pools, no market maker. A token without liquidity is worthless. The liquidity budget must be planned during design.
### 10. Design without modeling
The architecture looks logical on paper, but nobody verified the numbers. Six months later, inflation hits 50% annually, staking rewards drop below attractive levels, the treasury runs out early. Every design decision needs model validation.
{{< callout title="Design rule" >}}
If you can't explain why the token is needed in 30 seconds, the project has a design problem. Tokenomics is not a list of mechanisms — it's the answer to: **"why would a rational participant buy and hold this token?"**
{{< /callout >}}
## Checklist
{{< checklist title="Tokenomics design checklist" type="check" >}}
Competitor analysis done — minimum 5 projects in the niche
Token type determined — utility, governance, or security
All stakeholders identified — with motivations and horizons
Supply model chosen per stakeholder — one model per group
Vesting configured — cliff, duration, TGE unlock for each group
2–3 demand mechanisms defined — with real utility test passed
Net supply change calculated monthly — for 3–5 years
Velocity sinks in place — staking, vesting, or lock-ups
Three scenarios modeled — optimistic, base, pessimistic
System works in pessimistic scenario — validated by numbers
Liquidity budget planned — pools, market makers, initial capital
Treasury allocated — 10–20% reserved for future needs
Team vesting is longest — longer than investors
Technical spec written — contract parameters, events, dependencies
{{< /checklist >}}
{{< cta title="Need tokenomics for your project?" text="We cover every stage — from research to the final model. Average project timeline: 4–6 weeks." button="Get in touch" link="/quote/" >}}
---
## What Is Tokenomics
- URL: https://giantslabs.pro/basics/what-is-tokenomics/
- Section: basics
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Tokenomics definition: six disciplines, how it differs from cryptoeconomics, stakeholder analysis, and how parameters shape a token system.
Tokenomics is not "the economics of a coin" and not a spreadsheet with allocation percentages. It is an analytical discipline that determines whether a project **survives** or not. Below is a formal definition, the sciences tokenomics draws from, how it differs from cryptoeconomics, and a numerical example that shows how parameter choices destroy or save a system.
## Definition
{{< callout title="Definition" type="info" >}}
**Tokenomics** is the analysis of how the choice of supply and demand models, their parameters, and stakeholder behavior in a Web3 system affect its economic sustainability.
{{< /callout >}}
**Sustainability** is a state of equilibrium in which the chosen supply and demand models appear beneficial to key stakeholders in both the short and long term.
Three key words: **models**, **stakeholders**, **sustainability**. If a project lacks even one of these elements, it is not tokenomics — it is a Google Sheets table.
### Timeline
| Year | Event |
|------|-------|
| 2008 | Bitcoin whitepaper published (network launched January 2009) — foundation for tokenized value |
| 2014 | Ethereum ICO and early research lay the groundwork; the term "cryptoeconomics" is popularized later by Zamfir and Buterin during Ethereum development (2015-2017) |
| 2015 | Ethereum mainnet launch; ERC-20 standard proposed by Fabian Vogelsteller — the major programmable-token milestone |
| 2017 | Mass adoption of the term "tokenomics" |
## Tokenomics ≠ Cryptoeconomics
Cryptoeconomics studies economic mechanisms in blockchain systems broadly: consensus, validation, MEV. Tokenomics focuses on designing and analyzing tokens as economic instruments.
Whether tokenomics is a subset of cryptoeconomics or a standalone discipline remains debated. Kensuke Ito (2024) in *Cryptoeconomics and Tokenomics as Economics: A Survey with Opinions* ([arXiv:2407.15715](https://arxiv.org/abs/2407.15715)) proposes treating tokenomics as a separate field that overlaps with cryptoeconomics but is not contained within it — since tokenomics relies on microeconomics, behavioral economics, and game theory beyond the blockchain context.
In practice, the boundary runs along the object of analysis: studying PoW/PoS consensus, MEV strategies, and gas optimization — that is cryptoeconomics. Designing emission curves, airdrop strategies, staking rewards, and token utility — that is tokenomics. The fields overlap: staking rewards simultaneously affect network security (cryptoeconomics) and the token supply model (tokenomics).
## Six Disciplines Behind Tokenomics
Tokenomics does not invent theory from scratch. It takes tools from six established disciplines and applies them to systems with a token:
{{< checklist title="What tokenomics is built on" type="check" >}}
Microeconomics — supply, demand, pricing, equilibrium. A bonding curve is a pricing function written into a smart contract (and also a supply model)
Macroeconomics — monetary aggregates, inflation, monetary policy. Token emission is analogous to the M0 money supply
Game theory — strategic interaction of participants, Nash equilibrium. Every stakeholder optimizes their own utility function
Behavioral economics — irrationality, anchoring, FOMO. A token system must work not only for rational agents
Corporate finance — valuation, capital structure, dividends vs buyback. Token buyback is a financial operation with market impact
Economic sociology — community behavior, network effects, trust. The community is not a marketing channel — it is a stakeholder
{{< /checklist >}}
## Web2 vs Web3: What Changes for Economics
The comparison is easiest to see through a loyalty program.
### Web2 Loyalty Program
The project fully controls user behavior. The flow is linear:
1. The user performs "useful actions" (purchases, surveys)
2. The project issues points at its own rate
3. Points are redeemed for benefits **within** the project ecosystem
The project controls everything: the earning rate, the rewards catalog, the redemption rules. The user is a passive participant.
### Web3 Tokenization
The user **owns the token** and makes independent decisions:
1. The project issues tokens for useful actions
2. The user decides what to do: spend within the ecosystem, sell on the market, or hold
3. The ecosystem is **independent** of the project — other developers build utility
4. Token markets allow exchanging the token for BTC, ETH, or stablecoins
{{< callout title="The key difference" >}}
In Web2, the project determines the value of a point. In Web3, the market determines the value of a token. This means bad tokenomics is punished instantly — participants sell, and the price drops.
{{< /callout >}}
This is why the unit economics of a token project is radically more complex than traditional: CAC depends on the token price, the price depends on demand, demand depends on the number of users.
## Numerical Example: Three NFT Economy Variants
Let's walk through a concrete example. A game with NFT characters has 100 participants. Each can buy one of three NFT types:
| Parameter | Variant A | Variant B | Variant C |
|-----------|-----------|-----------|-----------|
| NFT cost | 20 credits | 100 credits | 400 credits |
| Buy probability | 90% | 50% | 20% |
| Participant income | 1 credit/day | 3 credits/day | 5 credits/day |
| Participant expense | 0 credits/day | 1 credit/day | 2 credits/day |
| Lifespan | 2 months | 3 months | 4 months |
Now let's calculate the **supply-demand balance** over the full lifecycle. We assume participant daily expenses are token sinks (burns or protocol fees that leave circulation), so in Variants B and C they count as demand alongside the NFT purchase; in Variant A expenses are zero, so the sink term vanishes.
### Variant A (Cheap NFT)
- Buyers: 100 × 90% = 90 people
- Token supply: 90 × 1 × 60 days = **5,400**
- Token demand (NFT purchases): 90 × 20 = **1,800**
- Result: supply 5,400, demand 1,800 → **supply is 3x greater than demand**
### Variant B (Mid-range NFT)
- Buyers: 100 × 50% = 50 people
- Supply: 50 × 3 × 90 = **13,500**
- Demand: NFT purchase (50 × 100 = 5,000) + expenses (50 × 1 × 90 = 4,500) = **9,500**
- Result: supply 13,500, demand 9,500 → **supply exceeds demand by 1.4x**
### Variant C (Expensive NFT)
- Buyers: 100 × 20% = 20 people
- Supply: 20 × 5 × 120 = **12,000**
- Demand: NFT purchase (20 × 400 = 8,000) + expenses (20 × 2 × 120 = 4,800) = **12,800**
- Result: supply 12,000, demand 12,800 → **demand exceeds supply**
{{< callout title="Takeaway" type="warning" >}}
Only Variant C — with the lowest buy probability — produces a sustainable balance. Intuition says make NFTs accessible; economics says the opposite. This is the tokenomist's job: finding parameters where the system is sustainable, not popular.
{{< /callout >}}
## Analysis Framework: Three Categories
Any tokenomics system can be decomposed into three categories of factors:
### External Factors
What the project **does not control**:
- Participant decision-making (buy probability, lifespan)
- Market conditions (if BTC drops, the native token drops too)
- Marketing and product inputs (how many users arrive)
### Internal Factors
What the project **designs**:
- [Supply model]({{< relref "models/token-supply-models" >}}) — how tokens are created and distributed
- [Demand model]({{< relref "models/demand-models" >}}) — what the token is spent on and why
- System parameters — specific numbers (NFT price, reward size, fee rate)
### Sustainability
The result of external and internal factors interacting. Key questions:
1. What is the supply-to-demand ratio for the token?
2. How much capital is in the treasury?
3. What is the expected token price in each period?
4. Is it beneficial for all participants to acquire and hold the token?
{{< callout title="The tokenomist's task" >}}
Select internal factors (models and parameters) so that the system remains sustainable under a realistic range of external factors. Not in the best-case scenario, but in the worst.
{{< /callout >}}
## The Stakeholder System
Stakeholders are everyone who interacts with the system and affects the supply-demand balance. Each stakeholder simultaneously **wants something from the system** and **is needed by the system** for something. Tokenomics works when these interests align.
### Short-Term Stakeholders
| Stakeholder | What they want | Why the system needs them |
|-------------|---------------|--------------------------|
| Traders | Profit from volatility, high liquidity | Providing liquidity, generating interest |
| Influencers | Exclusive access, promotion rewards | Marketing, attracting new participants |
### Long-Term Stakeholders
| Stakeholder | What they want | Why the system needs them |
|-------------|---------------|--------------------------|
| Users | Useful product, usage rewards | Active usage, feedback |
| Community | Exclusive opportunities, influence | Promotion, onboarding new users |
| Market makers | Revenue from liquidity management | Maintaining price at target levels |
| Team | High income, great product | Achieving product goals |
| Validators | Predictable income, governance participation | Network security and uptime |
| Liquidity providers | Predictable passive income | Liquidity depth, reduced volatility |
| Investors | High return-to-risk ratio | Capital, connections, expertise |
The full stakeholder composition depends on the project type. An L1 blockchain will have validators and builders. A GameFi project — players and content creators. A memecoin — traders and insiders. But the principle is the same: **every stakeholder affects the supply-demand balance**.
## Stakeholder Utility Function
To predict a participant's behavior, you need to understand their **utility function** — a formula describing what they value. An analogy: let d = donuts, c = cream:
- Alice: U = d + c (both equally valuable)
- Bob: U = d + 3c (cream is 3x more valuable)
- Carol: U = d + c + d·c (synergy — together worth more than apart)
- Dave: U = d + 0·c (cream is irrelevant)
- Eve: U = d − c (cream reduces utility)
- Frank: U = d / (1 + c) (donuts only valuable without cream)
In a real project, utility functions are identified three ways:
{{< checklist title="How to determine the utility function" type="step" >}}
On-chain analysis — study participants' actual choices on the blockchain: what they buy, when they sell, how they react to changes
Surveys and interviews — sociological research with the target audience
Choice experiments — offer participants alternatives ("200 tokens now or 500 in a month?") and measure preferences
{{< /checklist >}}
{{< cta title="Need tokenomics for your project?" text="We design tokenomics for DeFi, GameFi, and infrastructure projects — from market research to the final model." button="Get in touch" link="/quote/" >}}
---
# Section: Models
## Section landing: Models & Tools
- URL: https://giantslabs.pro/models/
- Kind: section landing
- Section: models
- Description: Tokenomics models: allocation, bonding curves, AMM, staking, emission. Templates and calculators.
---
## 5 Token Demand Models
- URL: https://giantslabs.pro/models/demand-models/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Five demand models for token utility: Discount, Payment, Ownership, Securities, Value Transfer. Formulas, real-world examples, and a selection algorithm.
If [supply models]({{< relref "models/token-supply-models" >}}) determine how tokens enter the system, demand models determine **why anyone would buy and hold them**. Without sustainable demand, any emission turns into an inflationary spiral.
## What Is a Demand Model
A **demand model** (also called a utility model) is a mechanism that creates an ongoing need for participants to buy or hold the token. It answers three questions:
1. **Why buy** the token? What benefit does the holder receive?
2. **Why hold** the token? What incentivizes not selling?
3. **Where does demand come from** — real economic activity or speculation?
In practice, there are **five core demand models**, each solving a distinct class of problems. A project can combine several.
{{< callout title="Connection to supply" >}}
Demand models **do not exist** apart from supply models. Tokenomics is the balance between emission and utilization. Design starts with understanding both sides, and their integration is [mechanism design]({{< relref "models/mechanism-design" >}}).
{{< /callout >}}
## 1. Discount — Fee Reduction for Token Holders
**In short:** token holders receive a discount on the protocol's services or products.
This is the simplest demand model. A user buys the token to pay for a service at a lower cost than in fiat or stablecoins. The discount creates price arbitrage: as long as the savings exceed the cost of acquiring the token, using it is rational.
### Mechanics
1. The protocol charges a fee for its service (e.g., 1% per transaction)
2. Paying with the protocol's token reduces the fee (e.g., to 0.5%)
3. The user buys the token on the market, pays for the service at a discount
4. The token is burned or returned to the treasury
### Price Ceiling Formula
{{< formula math="P_max = Fee × Volume × Discount_% / Supply" >}}
- P_max — maximum justified token price
- Fee — standard fee in fiat
- Volume — transaction volume per period
- Discount_% — discount when paying with the token
- Supply — tokens in circulation
{{< /formula >}}
If the fee is 1% on $100M/year volume, the discount is 50%, and 10M tokens are in circulation:
{{< formula math="P_max = 0.01 × $100M × 0.5 / 10M = $0.05" >}}
- Fundamental price ceiling: $0.05 per token at current volumes
{{< /formula >}}
### Examples
**BNB (Binance).** Trading fee discount when paying in BNB: originally 50% (2017), currently 25% on spot and 10% on futures. Per the original schedule, the discount was meant to decrease to zero, but Binance has maintained it. Additionally — access to Launchpad, IEOs, and other services.
**CRO (Crypto.com).** CRO holders receive higher cashback (up to 5%) on Crypto.com cards and access to exclusive features through the Level Up program (since September 2025), which combines CRO lockup with subscription tiers.
### When It Works
The discount model is effective when the protocol has a **stable transaction flow** with a clear fee structure. For projects without an established volume, this model creates insufficient demand.
{{< callout type="warning" title="Limitation" >}}
The discount model creates demand **only at the moment of the transaction**. Users have no incentive to hold the token longer than needed — they buy and spend immediately. For long-term retention, additional mechanisms are required.
{{< /callout >}}
## 2. Payment — In-Ecosystem Currency
**In short:** the token is the sole or preferred payment method within the protocol.
Unlike the discount model, the token does not give a discount — it **is** the medium of payment. The protocol only accepts its own token, creating mandatory demand.
### Mechanics
1. A user wants to use a service (data storage, compute, subscription)
2. The service only accepts payment in the protocol's token
3. The user buys the token on the market
4. Payment goes to the treasury, validators, or is burned
### Token Velocity
The critical metric for the payment model is **velocity**: how many times the token changes hands per period. High velocity means the token moves quickly through the "buy → pay → sell" chain without staying with any holder.
{{< formula math="Mcap = Volume / V" >}}
- The equation of exchange (MV = PQ) applied to tokens
- Volume — transaction volume per period
- V — velocity (V > 10 = fast turnover)
{{< /formula >}}
If annual transaction volume is $50M and velocity is 20 (each token turns over 20 times a year):
{{< formula math="Mcap = $50M / 20 = $2.5M" >}}
- Fundamental market cap of $2.5M at velocity 20
{{< /formula >}}
The problem: the more efficient the payment model, the higher the velocity, the lower the justified price. The velocity paradox is the main weakness of pure payment tokens.
### Solution: Velocity Sinks
To slow token turnover and raise the price, projects add **velocity sinks** — mechanisms that reduce circulation speed:
| Mechanism | Effect | Example |
|-----------|--------|---------|
| Staking | Locks tokens for a period | Helium (HNT → veHNT) |
| Burn | Destroys tokens permanently | EIP-1559 on Ethereum |
| Long contracts | Tokens locked for the service term | Filecoin (180–1,278 day sector commitment) |
| Vote-locking | Tokens locked for governance | Curve (veCRV up to 4 years) |
### Examples
**Filecoin (FIL).** Storage providers post collateral in FIL to participate in the network. Storage deals have a minimum duration of 180 days and a maximum of 1,278 days (since FIP-0052); collateral is locked for the duration of the sector commitment. Clients pay for storage in FIL. Two-sided demand — from providers (collateral) and clients (payment).
**Ethereum (ETH).** Gas for every transaction is paid in ETH. EIP-1559 burns the base fee, creating deflationary pressure during high network activity.
### When It Works
The payment model is effective for **infrastructure projects** with mandatory resource usage: storage, compute, bandwidth. For discretionary services (social networks, games), forcing payment in the token creates friction and repels users.
## 3. Ownership — Claim on Assets
**In short:** the token grants a property right over a digital or real-world asset.
This model spans a wide spectrum: from NFTs and in-game items to tokenized real estate and fund shares.
### Three Subcategories
**NFTs and digital objects.** The token represents a unique digital asset: art, an in-game item, a domain name, virtual land. Demand is driven by the subjective value of the asset, collectibility, and speculative interest.
**Commodity tokens.** The token represents a right to a physical commodity: gold (PAXG), carbon credits (KlimaDAO), energy. Demand is tied to the price of the underlying asset.
**Real-world assets (RWA).** The token represents a share in a real asset: real estate, Treasury bills, corporate bonds, fund shares. Demand is driven by the yield and liquidity of the underlying asset.
### Valuation Formula
{{< formula math="P = NAV / Supply" >}}
- P — fundamental token price
- NAV — net asset value backing the token
- Supply — total token supply
{{< /formula >}}
### Examples
**PAXG (Paxos Gold).** Each token is backed by 1 troy ounce of gold held in Brinks vaults. Token price tracks the gold price. Demand — an alternative way to own gold with fractional ownership and instant transfers.
**Ondo Finance (USDY).** Tokenized US Treasury bills yielding ~4–5% annually (varies with US Treasury rates). Demand — yield and liquidity of US Treasuries in tokenized form, accessible from ~$500 (vs high minimums in traditional Treasury products).
### When It Works
The ownership model works when the **underlying asset has intrinsic value**. If the asset's value depends solely on speculative demand (most NFT collections), the model is unstable. For RWA, the legal structure ensuring the right of claim is critical.
## 4. Securities — Tokens as Revenue Instruments
**In short:** the token grants a right to income from the protocol's operations.
This is the model closest to traditional finance. The token holder receives a share of profits, dividends, or value appreciation tied to the project's financial performance.
### Three Types of Yield
**Revenue share (dividends).** The protocol distributes part of its revenue to stakers.
**Buy-back & burn.** The protocol buys tokens on the market and burns them, increasing the value of remaining tokens. An indirect form of income.
**Collateral.** The token is used as collateral for borrowing. Staking in a Safety Module (AAVE) is a hybrid of collateral and insurance.
### Discounted Cash Flow Formula
{{< formula math="PV = Σ(CF_t / (1 + r)^t)" >}}
- PV — present value
- CF_t — cash flow in period t
- r — discount rate (20–50% for crypto)
{{< /formula >}}
When designing a securities model, you need to estimate future cash flows and discount them. The high uncertainty of crypto markets means a high discount rate — the value of future income is significantly reduced.
### Regulatory Context
{{< callout type="warning" title="The Howey Test" >}}
A token with revenue share falls under the definition of a security per the Howey Test: (1) investment of money, (2) in a common enterprise, (3) with expectation of profit, (4) from the efforts of others. Most jurisdictions require registration of such tokens. Projects mitigate this risk through governance decentralization, ve-models, and utility functions.
{{< /callout >}}
### Examples
**GMX.** GMX V2 allocates a share of trading fees to buyback-and-distribute: initially 27% (October 2024), with an active proposal to increase to 90%. Since March 2026, distribution is weighted by Staking Power — a loyalty metric that resets if the staker reduces their position below 80% of peak. Real yield is tied to trading volume — more volume, higher yield.
**Sky (formerly MakerDAO).** Surplus income from loan interest funds SKY buyback and burn (previously — MKR burn; MKR migrated to SKY at 1:24,000 in August 2024). The P/E ratio of SKY can be calculated as a standard financial multiple.
### When It Works
The securities model requires the protocol to have **established revenue**. For early-stage projects, promising future dividends is a red flag: no revenue means no real yield, only emission-based rewards.
## 5. Value Transfer — Transferring Value Within Systems
**In short:** the token serves as a vehicle for transferring value within or between systems.
This model differs from payment: the token is not bought to pay for a specific service but is used as a **channel for value transfer** between participants.
### Subcategories
**Staking for consensus participation.** Validators lock tokens to earn the right to confirm transactions. Demand is proportional to the number of validators and the minimum stake.
{{< formula math="Avg_locked = Validators × Min_stake × min(Period, 365) / 365" >}}
- Avg_locked — average number of tokens locked in staking at any point in time
- Validators — number of validators
- Min_stake — minimum stake per validator
- Period — average lock period (days)
{{< /formula >}}
**Governance.** The token grants a vote in protocol governance. The more tokens locked for voting, the fewer in circulation.
**Cross-system bridge.** The token is used to move value between blockchains (native bridge tokens) or between crypto and fiat.
### Examples
**ETH (Ethereum PoS).** 32 ETH is the minimum validator stake (since the Pectra upgrade in May 2025, consolidation up to 2,048 ETH is possible). With roughly 900,000 active validators as of mid-2026 (down from over 1M after post-Pectra consolidation), approximately 38M ETH (~31% of total supply) is locked. This is a massive velocity sink.
**LINK (Chainlink).** Chainlink nodes stake LINK as collateral for providing data feeds. Slashing for inaccurate data is still being rolled out and remains limited in current staking versions. Demand is proportional to the number of active nodes and the volume of data served.
### When It Works
The value transfer model is effective for **infrastructure networks** where participation requires collateral. The key factor is a genuine need for staking, not an artificial constraint. If staking carries no economic risk (no slashing, no lock period), it becomes a marketing tool with minimal impact on demand.
## Case Study: Lessons from TON
TON (The Open Network) tokenomics is a clear example of a supply-demand imbalance.
### What Happened
TON inflation is **~0.6% annually** (~84,000 TON/day with a total supply of ~5.1B, circulating ~2.5B), and staking APY is ~4–5% on retail platforms after fees (network base ~17%). Yet the primary demand driver is validator staking alone — the DeFi ecosystem and payment use cases are insufficiently developed to balance even modest emission.
### Demand Model Analysis
| Demand model | Status in TON | Problem |
|-------------|---------------|---------|
| Discount | Minimal | Low fees, small DeFi volume |
| Payment | Weak | Gas is cheap, ecosystem developing |
| Ownership | Absent | No significant RWA or NFTs |
| Securities | Nominal | Staking APY ~4–5% retail (network ~17%), no revenue share |
| Value Transfer | The only one | Validator staking, but excess emission |
{{< callout type="warning" title="Lesson" >}}
TON demonstrates a common scenario: even with modest inflation (~0.6%), a single significant demand driver — validator staking — is insufficient for a sustainable token economy. Without diversified demand models (DeFi fees, payment, governance), the token remains dependent on speculative interest. As of early 2026, TON's ecosystem is rapidly developing — Telegram wallet integration, mini-apps, and DeFi growth may shift this balance, though the structural tokenomics challenges remain.
{{< /callout >}}
## Combining Demand Models
No single demand model sustains tokenomics on its own. Successful projects combine several:
| Project | Discount | Payment | Ownership | Securities | Value Transfer |
|---------|----------|---------|-----------|------------|----------------|
| **Ethereum** | | ✓ Gas | ✓ NFTs | ✓ Burn | ✓ PoS staking |
| **BNB** | ✓ Discounts | ✓ BNB Chain gas | | ✓ Burn | |
| **Filecoin** | | ✓ Storage payment | | | ✓ Miner collateral |
| **Curve** | | | | ✓ Revenue share | ✓ veCRV governance |
| **AAVE** | | | | ✓ Safety Module (Umbrella) | ✓ Governance |
### The Combination Principle
An optimal combination typically includes:
- **Mandatory demand** (payment or value transfer) — a baseline independent of speculation
- **Incentive demand** (discount or securities) — additional motivation to buy
- **Locking demand** (staking, governance lock) — reducing circulating supply
## Demand Model Selection Algorithm
### Determining Factors
| Factor | Recommended model |
|--------|-------------------|
| Stable transaction flow | Payment + Discount |
| Tokenizable assets | Ownership |
| Protocol generates revenue | Securities (revenue share or buyback) |
| Validators or nodes | Value Transfer (staking + slashing) |
| Strong community | Value Transfer (governance) |
### Decision Tree
{{< cta title="Where does the money come from?" text="If the only source of demand is new investors, that is not a demand model — it is a Ponzi-like scheme. We design utility mechanics based on real protocol revenue." button="Get in touch" link="/quote/" >}}
---
## 5 Token Supply Models
- URL: https://giantslabs.pro/models/token-supply-models/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Five token supply models: allocation, bonding curve, airdrop, reward, and market distribution. Each explained with examples, formulas, and practical guidance.
## What Is a Supply Model
A supply model determines **how tokens come into existence** and **how they reach participants**. It is the foundation of any tokenomics — without it, you cannot design demand or governance.
A supply model answers three questions:
1. **How many tokens** exist (or will exist)?
2. **Who receives** tokens and on what terms?
3. **How does supply change** over time — growing, shrinking, or staying fixed?
In practice, there are **five core models**, each solving a distinct class of problems. A project can use one model or combine several.
{{< callout title="Important" >}}
Vesting is not a supply model. It is a mechanism that controls the _speed_ of token release and can be combined with any of the five models. Similarly, **burn (deflationary) mechanisms** — buyback-and-burn (BNB, ETH post-EIP-1559), transaction fee burns, scheduled burns — are supply _reduction_ mechanisms that can be layered on top of any model, not a standalone supply model.
{{< /callout >}}
## 1. Allocation — Initial Distribution
**In short:** a fixed pool of tokens is distributed among stakeholder groups at project launch.
This is the most common model. The total supply is defined upfront and then split into pools:
| Pool | Typical share | Purpose |
|------|---------------|---------|
| Team & founders | 15–20% | Creator incentives |
| Investors (seed, private) | 10–25% | Capital raising |
| Treasury | 15–30% | Ecosystem development |
| Community & incentives | 20–40% | User acquisition |
| Liquidity | 5–15% | Trading infrastructure |
### Key Decisions
**Total supply size.** Psychologically, 1 billion tokens feels different from 21 million. But economically it makes no difference — what matters is the allocation ratios, not the absolute numbers.
**Balance between groups.** Too much to investors — selling pressure after unlock. Too little — hard to raise capital. A common guideline suggests 15–25% across all investor rounds combined, though this varies by project stage and type.
**Transparency.** Every pool should be documented: size, wallet address, unlock schedule.
### When to Use
Allocation is the baseline model for any project raising investment. It suits projects that know their stakeholders at launch.
{{< callout type="warning" title="Common mistake" >}}
Creating a "future" pool with no clear purpose. Unallocated tokens create uncertainty for investors and put pressure on price.
{{< /callout >}}
## 2. Bonding Curve — Dynamic Pricing
**In short:** tokens are minted according to a mathematical formula where price depends on current supply.
Unlike allocation, there is no fixed total supply. New tokens are created when someone buys from the smart contract and destroyed when sold back.
### Formula
{{< formula math="P(T) = A + B × T^C" >}}
- P — price
- T — current supply
- A — starting price
- B — scale factor
- C — curve steepness
{{< /formula >}}
Three parameters control the curve:
- **A** (starting price) — price of the first token. Sets the entry threshold
- **B** (scale) — how fast price grows in absolute terms
- **C** (steepness) — curve shape. C = 1 means linear growth, C > 1 means exponential
### How It Works in Practice
With C = 1.5 and initial parameters A = 0.10, B = 0.00000001:
| Supply | Minting price | Cumulative cost |
|--------|--------------|-----------------|
| 0 | $0.10 | $0 |
| 10,000 | $0.11 | ~$1,040 |
| 25,000 | $0.14 | ~$2,900 |
| 50,000 | $0.21 | ~$7,250 |
Early participants get tokens cheaper — a natural incentive for first users.
### Advantages
- **Automatic liquidity** — always possible to buy or sell through the contract
- **Transparent pricing** — the formula is open, no manipulation
- **Early adopter reward** — price rises with community growth
### Risks
- **Irreversible parameters** — a mistake in A, B, C is locked in forever
- **Front-running** — large purchases are visible in the mempool; arbitrageurs can front-run
- **Complexity for users** — not everyone understands the mechanics
### When to Use
Bonding curves suit projects without centralized fundraising: DAOs, community tokens, continuous funding protocols.
## 3. Airdrop — Free Distribution
**In short:** tokens are distributed for free to a specific group of users based on predefined criteria.
An airdrop is not just a marketing tool. In the context of supply models, it is a way to achieve **initial distribution** that solves the cold-start problem: how to attract first users when the token has no value yet.
### Distribution Criteria
| Criteria | Example | Pros | Cons |
|----------|---------|------|------|
| Protocol activity | Transaction count | Rewards real users | Bot farming |
| Staking/holding | Held ETH > 6 months | Attracts loyal holders | Excludes newcomers |
| Social activity | DAO votes | Engagement | Easy to fake |
| Retroactive | Used before announcement | Fair | Cannot be planned |
### The Key Decision: Drop Size
Too small an airdrop (< 5% of supply) — users are disappointed, sell immediately. Too large (> 30%) — price pressure, dilution for investors.
A common range is **10–20% of total supply**, though successful projects have allocated from 5% to over 30% (Hyperliquid: 31%, Bonk: 50%). The Uniswap airdrop (15%) is often cited as a benchmark. Holding requirements (e.g., linear unlock over 6 months) help reduce immediate sell pressure.
### When to Use
Airdrops work best as a **supplement** to allocation. On their own they rarely succeed — you need a base distribution model, with the airdrop adding reach.
## 4. Reward — Mining and Incentives
**In short:** new tokens are created as rewards for useful work in the system.
This is the Bitcoin model: new BTC are not pre-allocated but created as a reward for miners confirming transactions. But the reward model extends far beyond mining.
### Reward Types
- **Proof-of-Work** — for computational work (Bitcoin, pre-Merge Ethereum)
- **Proof-of-Stake** — for locking capital (Ethereum, Solana via DPoS + PoH)
- **Proof-of-Storage** — for storing data: Filecoin (Proof of Replication + Proof of Spacetime), Arweave (Proof of Access)
- **Proof-of-Coverage** — for providing infrastructure (Helium, DePIN projects)
### Emission Curve
In the reward model, the **emission rate** is critical. Too high — inflation devalues the token. Too low — insufficient incentives for participants.
The classic solution is **decreasing emission**: rewards decline on a schedule (like Bitcoin's halving every ~4 years).
### The TON Problem
A revealing example: even with modest inflation (~3.6% per year, as with TON post-Catchain 2.0), a reward model may not generate sufficient demand if the ecosystem lacks token utility beyond staking. Without balancing demand mechanisms (DeFi, payments, governance), emission rewards merely redistribute value from non-stakers to stakers.
### When to Use
The reward model is essential for **infrastructure projects** where participants perform work for the network: validators, miners, node operators, data providers.
## 5. Market — Secondary Circulation
**In short:** tokens circulate and are priced through market mechanisms — liquidity pools, AMMs, order books.
This model differs from the others: it does not create new supply but provides the infrastructure for trading and price discovery after primary distribution.
### Mechanisms
**AMM (Automated Market Maker)** — tokens circulate in a liquidity pool. Price is set by a formula (CPMM in Uniswap: x × y = k). New tokens are not created automatically, but pool behavior affects effective supply.
**Order book** — a classic book of orders. Market makers provide liquidity by placing buy and sell orders.
**Intent-based** — a newer model where the user declares an intent, and solvers compete to fulfill it.
### When to Use
The market model is a **secondary circulation** model. It does not replace allocation or reward but complements them, providing liquidity and price discovery after primary distribution.
## How to Combine Models
In practice, projects use **model combinations**:
| Project type | Allocation | Bonding | Airdrop | Reward | Market |
|-------------|-----------|---------|---------|--------|--------|
| Typical DeFi | ✓ Primary | ✗ | ✓ Reach | ✓ Staking | ✓ AMM |
| DAO | ✓ Minimal | ✓ Primary | ✓ Reach | ✗ | ✗ |
| L1 Blockchain | ✓ Primary | ✗ | ✓ Testnet | ✓ Validation | ✓ Exchanges |
| DePIN | ✓ Primary | ✗ | ✗ | ✓ Primary | ✓ DEX |
| Memecoin | ✓ Full | ✓ pump.fun | ✓ Marketing | ✗ | ✓ DEX |
The choice of combination depends on the **project type**, not on trends. Don't use a bonding curve just because it's popular — it's not right for every case.
**Choosing a supply model**
## Design Checklist
Before choosing a supply model, answer these questions:
1. Is there a fixed total supply? If yes → allocation as the foundation
2. Do you need automatic liquidity from day one? If yes → bonding curve
3. Do you need to onboard existing users? If yes → airdrop
4. Do participants perform work for the network? If yes → reward
5. How will trading happen after launch? → market model
{{< cta title="Need help with your supply model?" text="We design token distribution tailored to your project" button="Get in touch" link="/quote/" >}}
---
## Agent-Based Modeling in Tokenomics
- URL: https://giantslabs.pro/models/agent-based-modeling/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: When spreadsheets aren't enough: agent-based modeling for stress-testing tokenomics. Python code, charts, and result analysis.
## The Problem: Spreadsheets Model Averages, Systems Break at Extremes
A spreadsheet tokenomics model works with aggregates: total supply, average price, total staking. It's a useful tool — we start every project with a spreadsheet. But spreadsheets have a fundamental limitation: they don't model **individual participant behavior.**
Consider staking. A spreadsheet says: "at 5% APR, 60% of tokens will be staked." One scenario, one number. But in reality, stake distribution is uneven — 10 wallets may control 25% of the stake. If three whales exit simultaneously, the APR changes, triggering reactions from other participants. A spreadsheet won't show this.
Agent-based modeling (ABM) builds the system bottom-up: each participant is a separate **agent** with their own balance, strategy, and decision thresholds. The model runs for hundreds of iterations, and at each step agents make decisions based on the current system state.
The result is not one forecast, but a **distribution of possible outcomes**, including extreme scenarios.
## When You Need ABM vs When a Spreadsheet Is Enough
| Task | Spreadsheet | ABM |
|---|---|---|
| Allocation and vesting schedules | Sufficient | Overkill |
| Supply forecast at given emission | Sufficient | Overkill |
| Unit economics (CAC, LTV) | Sufficient | Overkill |
| Staking with uneven distribution | Can't see cascades | **Required** |
| Governance voting | Can't see attacks | **Required** |
| AMM pools and liquidity | Can't see slippage | **Required** |
| Economies with multiple participant types | Can't see interactions | **Required** |
The rule is simple: if one participant's actions change conditions for others — you need ABM. If not — a spreadsheet is sufficient.
## Example: Staking and Bank Run
A concrete case where a spreadsheet gives false confidence, while an agent-based simulation reveals systemic risk.
### Setup
A protocol with fixed emission: 800 tokens per day distributed to stakers proportionally. At 60% of tokens staked, this yields an APR of ~4.9%.
Questions:
- How many stakers will remain if APR falls below some participants' expectations?
- What happens if the 10 largest wallets exit simultaneously?
A spreadsheet would answer: "when 10 stakers exit, APR increases proportionally." But this doesn't account for **who** exits (a whale or a small holder) and **what happens next** (cascading reactions).
### The Model: 200 Agents with Different Strategies
Each agent has three parameters:
| Parameter | Distribution | Meaning |
|---|---|---|
| Balance | Pareto (alpha=1.5) | A few whales + many small holders, as in real networks |
| APR threshold | Uniform (3–15%) | Minimum APR below which the agent exits |
| Reaction delay | 1–14 days | Not everyone reacts instantly |
The top 10 agents control ~22% of the stake — a power-law distribution.
### Simulation Code
Full code — copy into Google Colab and run:
```python
import numpy as np
import matplotlib.pyplot as plt
np.random.seed(42)
# === Parameters ===
num_agents = 200
num_steps = 365 # days
total_supply = 10_000_000
daily_rewards = 800 # tokens/day (~4.9% APR at full stake)
# === Generate agents ===
# Balances: power law (Pareto) — a few whales, many small holders
raw = np.random.pareto(a=1.5, size=num_agents) + 1
balances = (raw / raw.sum() * total_supply * 0.6).astype(int)
# APR threshold: below this value the agent exits staking
apr_thresholds = np.random.uniform(0.03, 0.15, size=num_agents)
# Reaction delay: how many days APR must stay below threshold
reaction_delay = np.random.randint(1, 15, size=num_agents)
# State
is_staking = np.ones(num_agents, dtype=bool)
days_below_threshold = np.zeros(num_agents, dtype=int)
# Metrics
h_staked = np.zeros(num_steps)
h_apr = np.zeros(num_steps)
h_num = np.zeros(num_steps)
# === Simulation ===
for day in range(num_steps):
staked_total = balances[is_staking].sum()
if staked_total == 0:
break
current_apr = (daily_rewards * 365) / staked_total
h_staked[day] = staked_total
h_apr[day] = current_apr
h_num[day] = is_staking.sum()
for i in range(num_agents):
if not is_staking[i]:
continue
if current_apr < apr_thresholds[i]:
days_below_threshold[i] += 1
if days_below_threshold[i] >= reaction_delay[i]:
is_staking[i] = False # exit
else:
days_below_threshold[i] = 0 # reset counter
```
Key mechanic: at each step, every agent checks the current APR. If APR is below their threshold for longer than their reaction delay — they exit. One agent's exit reduces the total stake, which **changes the APR for everyone else.** This is the cascading effect that's invisible in a spreadsheet.
### Results
Two scenarios with the same agents:
- **No shock** — the system evolves on its own
- **With shock** — on day 60, the 10 largest stakers are forcibly removed
#### No-Shock Scenario
| Metric | Day 0 | Day 7 | Day 14 | Equilibrium |
|---|---|---|---|---|
| Stakers | 200 | 130 | 80 | 80 |
| Staked | 6.0M | 3.7M | 2.4M | 2.4M |
| APR | 4.9% | 7.8% | 12.1% | 12.1% |
Starting APR of 4.9% is below threshold for most agents. Over 14 days, 120 agents exit — those whose thresholds remain above the rising APR long enough to trigger their reaction delay. Stake drops from 6M to 2.4M, APR rises to 12.1%, and the system stabilizes. The remaining 80 agents are satisfied.
A spreadsheet would say: "60% is staked at 4.9% APR." The simulation showed: actually **24%** is staked (2.4M out of 10M), and equilibrium APR is **12.1%**, not 4.9%.
#### Shock Scenario (10 Whales Exit on Day 60)
By day 60, the system is already at equilibrium (80 stakers, 12.1% APR). Then 10 largest wallets exit simultaneously:
| Metric | Before shock | After shock | New equilibrium |
|---|---|---|---|
| Stakers | 80 | 70 | 70 |
| Staked | 2.4M | 1.38M | 1.38M |
| APR | 12.1% | 21.2% | 21.2% |
The 10 whales' exit removes ~1M tokens from the stake. APR jumps to 21.2%. In this specific run, there is no cascade — all remaining 70 agents have thresholds below 21.2% and reach equilibrium immediately.
In a more realistic model (accounting for token price drops during mass exits), the effect would be amplified: whale exit → sell pressure → price drops → real USD yield falls → cascade intensifies.
### What the Simulation Showed That a Spreadsheet Wouldn't
1. **Real equilibrium** (80 stakers, not 200) — with the same APR and supply
2. **Cascade speed** (14 days to stabilization) — specific dynamics, not "instant recalculation"
3. **Reaction delay matters** — agents with delay=14 exit later, stretching the cascade
4. **Distribution matters** — 10 whales exiting removed ~1M, while 10 smallest holders would remove ~130K
## Scaling the Model
The example above is basic. For a real project, you can add:
**Price feedback.** Currently, the token price doesn't change when stakers exit. In reality: exit → sell → price drops → real yield falls → cascade intensifies. This turns a soft stabilization into a hard bank run.
**Multiple agent types.** "Farmers" move between protocols as APR changes, "holders" ignore APR and react only to price, "attackers" deliberately destabilize the stake.
**Multiple runs.** One run = one outcome. 100 runs with different seeds yield a distribution of outcomes. The question isn't "what will happen" but "in what percentage of runs does stake fall below 20% of supply."
## Tools
For the example in this article, **NumPy + Matplotlib** is enough. For more complex models:
**cadCAD** — the original Python framework by BlockScience (low activity in recent years, but still released and used). Formalizes the model as a chain of "state → policy → state update mechanism." Was used for modeling Ethereum 2.0, Filecoin, Ocean Protocol.
**radCAD** — a lightweight reimplementation of the cadCAD execution engine by CADLabs (Rust+Python). Compatible model structure, faster execution, less boilerplate.
**Mesa** — the most popular general-purpose ABM framework for Python. Well-documented, actively maintained. Many tokenomics teams use Mesa instead of cadCAD for its broader community and flexibility.
**TokenSPICE** — a simulator by Ocean Protocol. Works with actual EVM contracts via a local EVM network (Ganache). Tests not an abstract model but specific Solidity code. The project has been unmaintained since late 2022, but the code is available.
## Workflow
1. **Design the economy in a spreadsheet.** Allocation, vesting, emission, unit economics. Make sure the [supply model]({{< relref "models/token-supply-models" >}}) converges.
2. **Identify the critical mechanism.** What can break? Staking, governance, liquidity?
3. **Define agent types.** Who are the participants, what are their goals? Which parameters vary?
4. **Run 100+ simulations.** One run proves nothing.
5. **Analyze the tails.** Not the average outcome, but the 5th percentile — what happens in the worst 5% of scenarios?
6. **Iterate on mechanism parameters.** The goal: robustness in 95%+ of runs.
{{< checklist title="Checklist: do you need an agent-based model?" >}}
The system has participants with competing interests
One participant's actions affect conditions for others
There are feedback mechanisms (staking, AMM, bonding curve)
Robustness to extreme scenarios matters
Position distribution is highly uneven (whales exist)
The system includes governance with voting
{{< /checklist >}}
3+ items checked — ABM will pay for itself. 0–1 — start with a [spreadsheet model]({{< relref "models/token-supply-models" >}}).
{{< cta title="Need an agent-based model for your project?" text="We design tokenomics and verify it with simulations — from spreadsheet models to agent-based modeling." button="Get in touch" link="/quote/" >}}
---
## Agro-Token Architecture: Why You Can't Fractionalize Grain
- URL: https://giantslabs.pro/models/agro-token-architecture/
- Section: models
- Date: 2026-07-03
- Last modified: 2026-07-03
- Description: Two-tier commodity-token design: a non-fractionalized NFT warrant holds the title, a fungible pool token carries the yield—why one token cannot do both.
A commodity token has to satisfy two customers with opposite needs. The first is a warehouse clerk, who wants exactly one name on the certificate—someone who can show up, present the document, and take the grain. The second is a market maker, who wants ten thousand holders trading small tickets in and out all day. Design for the clerk and the token is illiquid; design for the market maker and the certificate stops working as collateral.
This tension is the central architecture problem in agricultural tokenization, and most failed designs die on it. The good news: the solution does not need to be invented. Brazilian commercial law split these two functions decades ago, and the token structure that works is the same split, executed on a ledger. This article walks through that structure—what we consider the reference architecture for lending against tokenized farm collateral—layer by layer.
Context from earlier in this series: [which agro-token projects actually settle deals]({{< relref "knowledge/agricultural-tokenization" >}}), and [the legal stack underneath them]({{< relref "knowledge/agri-finance-stack" >}}). Here we assume both and go one level deeper.
## Two properties, one token, no solution
Lending against a tokenized commodity needs two things at once:
- **Enforceability.** On default, the creditor presents a document and takes the goods—days, not lawsuits. In Brazil this works because farm titles are extrajudicial executive titles and warehouse receipts entitle the holder to the physical lot.
- **Liquidity.** Investors want small tickets, instant entry and exit, and a fungible instrument a market can price continuously.
Put both in one token and each destroys the other. Fractionalize the warehouse receipt across ten thousand wallets and no one can enforce it: a warehouse releases a lot to a titleholder, and there is no procedure for ten thousand of them. Enforcement law assumes a name; a liquid market assumes there is no name. Worse, a fractional claim on a physical asset is precisely the shape regulators read as a collective investment scheme—the least favorable qualification available.
{{< callout title="The design rule" type="info" >}}
Enforceability and liquidity cannot live in the same token. Fractionalizing the **title** destroys the collateral; keeping the instrument whole destroys the market. The two properties belong in two different tokens, linked through a credit relationship rather than co-ownership.
{{< /callout >}}
## The law already made this split
Any lawyer in the room can relax: Brazil's warehouse-receipt law has separated these functions since 2004. When a certified warehouse (armazém geral, a licensed custodian of third-party goods) accepts grain, it issues two certificates—the CDA (deposit certificate) carrying title to the goods, and the WA (warrant) carrying the pledge right. They circulate separately: the producer keeps the CDA and hands the WA to a lender, creating a security interest without moving the grain.
The two-tier token architecture is the same maneuver, one level up: keep the title instrument whole where enforcement lives, and let a separate instrument—a claim against a pool of loans—carry the liquidity. Nothing about the split is a crypto invention; the ledger only makes it programmable.
{{< schema "mechanism/agro-token-two-tier" >}}
## The bottom tier: a warrant that refuses to fractionalize
The base layer is a **non-fungible warrant: one token, one certificate, one lot** (in EVM terms, ERC-721). It represents the warehouse receipt or the registered farm title, and it is deliberately kept whole.
What the token adds over the paper it mirrors:
- **Machine-readable collateral.** The metadata carries the lot, grade, warehouse, insurance policy, and encumbrance status—so a lender, an auditor, or a pool contract can verify the collateral without calling anyone.
- **A public price anchor.** Soy, corn, coffee, and sugar are priced off published indices (CEPEA/Esalq spot, B3 futures, Argus/Platts export parity), which is what lets banks set advance rates without a bespoke oracle—the pricing problem was solved by the commodity exchanges long ago.
- **Programmable encumbrance.** Locking the warrant in a lending contract is the on-chain equivalent of endorsing the WA to a creditor—except the lock, the release, and the default trigger are code.
The boundary of this design is data. Exchange-traded crops clear it; specialty crops mostly do not—the olive-harvest project we mentioned in [the first article]({{< relref "knowledge/agricultural-tokenization" >}}) stalled on precisely this bar: no published index for its grades, and lot values that swing with who pays the freight. If the asset's price and quality cannot be verified from public data plus warehouse-and-insurer attestations, the warrant tier has nothing solid to stand on.
## The top tier: a share in the loan book
Investors never touch the warrant. They hold a **fungible pool token** (ERC-20): a pro-rata claim on a portfolio of loans that are each secured by locked warrants. Yield equals the interest the portfolio earns, gross of structuring, servicing, and hedging costs—in Brazil's free-market circuit, the underlying loans price off farmer rates of 18–25% in BRL.
The token holder owns a credit claim on the portfolio, and everything the design gets right follows from that:
1. **Enforcement stays intact.** The pool, a single legal entity, is the sole name on every warrant. On default there is exactly one party for the warehouse to deal with.
2. **The regulatory read improves.** A share in a credit instrument is a known, wrapped, taxable thing; a fractional interest in physical grain is an exotic one. Brazil offers two ready wrappers: the FIDC receivables fund and the tokenized CRA (agribusiness receivables certificate), which brings a segregated estate and the individual income-tax exemption—the same wrapper logic as [tokenized equity]({{< relref "knowledge/tokenized-equity-instruments" >}}).
3. **The utility model is honest.** In our taxonomy this is an [ownership-model token]({{< relref "models/ownership-model" >}}) on a cash-flow-bearing portfolio: its fair value is the NAV of the loan book, its yield is the portfolio coupon, and it needs no artificial sinks or emissions to justify itself.
In economic substance, the structure is a bank or a plain securitization. What is new is machine-readable collateral and programmable waterfalls—an incremental, real improvement. Pitch decks that promise more are usually promising away the credit risk, which no ledger absorbs.
## Default: capital flows up, legal force flows down
The architecture proves itself on a bad day, so walk the bad day explicitly. A borrower misses payment. The pool contract already holds the locked warrant. The pool, as titleholder, presents it to the warehouse, the lot is auctioned under the warehouse-receipt procedure, and proceeds return to the pool. Investors take a haircut only if the collateral sale falls short; they never take custody of grain.
Brazil's 2024–2025 default wave ran a live experiment on exactly this distinction. When the farm-retail group AgroGalaxy entered judicial recovery, the creditor holding fiduciary title to specific collateral stayed outside the process and collected; holders of certificates backed by unsecured corporate receivables took an 85% haircut. The architecture described here is built to put token holders on the first side of that line—the warrant tier exists precisely to keep the pool's claim on the secured side. One honest caveat travels with it: inside a court-supervised recovery, a judge can declare collateral essential to the debtor's operations and stay even secured enforcement for 180+ days. (We dissect the AgroGalaxy case, including which protections failed and which held, later in this series.)
## The money leg: onshore, through the front door
One more constraint shapes the design, and it comes from the regulator. Brazil reclassified foreign-currency stablecoin operations as FX transactions: legal, but routed through authorized institutions, with a US$100k limit against unauthorized counterparties. From 1 October 2026, a further rule bars stablecoin settlement abroad by cross-border payment providers (unlicensed firms have until 31 May 2027 to seek authorization). A direct "global DeFi pool pays the farmer in USDC" bridge is, from that date, simply not a lawful design in Brazil.
The compliant shape: global capital converts through an authorized bank's FX desk into a local fund vehicle (the FIDC), the fund lends in BRL, and the farmer never sees a stablecoin. The stablecoin's remaining role is upstream, as an asset wrapper in which foreign investors hold and transfer their claim; settlement itself runs through the bank's FX desk. Any architecture that ignores this leg is designing for a jurisdiction that stops existing in October 2026.
## Three architectures compared
| | Direct fractionalization | Mirror token | Two-tier (warrant + pool) |
|---|---|---|---|
| What the investor holds | A fraction of the physical lot's title | A receipt tracking an off-chain security | A share in a secured loan portfolio |
| Enforceability | Broken—no single titleholder | Unchanged—lives entirely off-chain | Intact—pool is the sole titleholder |
| Liquidity | High on paper, until default | Limited by the wrapped security | High—fungible pool token |
| Regulatory read | Collective scheme on a physical asset | Follows the underlying security | Credit instrument in a known wrapper |
| Default path | Effectively none | Standard, but the token adds nothing to it | Warrant → warehouse auction → pool |
| Where you see it | Failed pilots and pitch decks | VERT-style on-chain CRA issuances | Emerging lending designs |
The mirror token deserves a fair word: it is the proven, conservative end of this spectrum—the R$1.1 billion of on-chain CRA issuances across two deals from the first article are mirror tokens, and they work. What they do not do is change the instrument: the token is a window onto the securitization; the load-bearing structure stays off-chain. The two-tier design is what it looks like when the token layer starts carrying weight—collateral verification, encumbrance, waterfall execution—while still respecting the enforcement boundary.
## What is still missing
The honest gap in every current implementation: a verifiable bridge between the state-sanctioned registrar and the public chain. Brazilian titles must live in authorized registries (B3, CERC), which internally already run on a permissioned ledger. Until the registry state is provable on the public network (rather than re-attested by the issuer), the warrant NFT is only as good as the process that syncs it. Whoever ships that bridge removes the last trusted intermediary in the stack; until then, every design carries a named reconciliation agent, and diligence should ask who it is.
{{< checklist title="Design decisions, in the order they bind" type="step" >}}
Verify the asset clears the data bar. Published price index, standardized grades, certified warehousing, insurable. If not, stop—no architecture fixes an unpriceable collateral.
Keep the title whole. A single warrant per lot, a single holder per warrant. Every fractionalization decision happens above the title layer.
Choose the pool wrapper before the token standard. The FIDC or tokenized-CRA decision drives tax, disclosure, and who may invest; ERC numbers are downstream details.
Route the currency leg onshore. Authorized FX conversion into the local vehicle; stablecoins as an investor-side wrapper only.
Name the reconciliation agent. Someone attests that the on-chain warrant matches the registry entry. That party is part of your trust model—put them in the docs.
{{< /checklist >}}
{{< cta title="Designing a token on real-world collateral?" text="We build two-tier RWA architectures end to end—title layer, pool economics, wrapper selection, and the default-path modeling that investors now ask for first." button="Get in touch" link="/quote/" >}}
## The takeaway
The architecture that holds up in front of a warehouse clerk, a securities regulator, and a defaulting borrower is the one that refuses to merge two jobs into one token. A whole, machine-readable warrant holds the enforcement power, and a fungible pool token carries the liquidity and the yield. The onshore wrapper carries the law. Brazilian commercial practice arrived at the same division of labor on paper twenty years ago; the ledger's contribution is verification and programmability on top of that split. The open question this architecture cannot answer by itself is price: what yield does the pool token have to pay a dollar investor, once hedging and country risk are counted honestly? That is the next article in this series—and the honest number is higher than most pitch decks assume.
---
## AI Agent Tokenomics: Six Design Patterns That Work, One That Failed
- URL: https://giantslabs.pro/models/agent-tokenomics-patterns/
- Section: models
- Date: 2026-05-19
- Last modified: 2026-05-19
- Description: AI agent tokenomics catalog: 6 design patterns that work and 1 that failed. Platform buyback, provider staking, routing currency, subnet model, compute-indexed primitive, reputation economies — with Virtuals, Aethir, Akash, Bittensor numbers.
AI agent tokenomics had its first full cycle between January 2025 and May 2026. The "AI Agents" category on CoinGecko peaked at $15.5B in market cap in January 2025; by May 2026 it sat at $3.18B—an 80% drawdown, while the broader AI economy outside of crypto is projected to reach $206B in agentic-software spend in 2026 (Gartner forecast). The drawdown is not a verdict on the trend. It is a verdict on the dominant token design.
Most AI agent tokens through that window borrowed shape from memecoins: launchpad bonding curves, narrative-driven liquidity, no structural link between token holders and what the agent actually does. A small number borrowed shape from DePIN, from inter-agent payments, and from compute-as-a-commodity—and those held up.
This article is a practitioner catalog. Seven tokenomics design patterns for AI agents: six that have at least one working configuration, one that is structurally broken. Each pattern gets the mechanic, a live example with numbers, an effectiveness assessment, and the white space where design value still lives.
For the higher-level entry point on whether an AI agent project needs a token at all, see [AI Agent Tokenomics: From Memecoins to Revenue Share]({{< relref "knowledge/ai-agents-tokenomics" >}}) and [When You Don't Need a Token]({{< relref "knowledge/when-token-not-needed" >}}). This article assumes the answer is yes and zooms into the design choice that follows.
## The seven patterns at a glance
| # | Pattern | Live example | What it does | Works? |
|---|---|---|---|---|
| 1 | Platform-revenue buyback-and-burn | Virtuals (VIRTUAL) | Platform fees buy back and burn native token | Mixed—works only when revenue is non-speculative |
| 2 | Provider staking + reward distribution | Aethir (ATH), Akash (AKT) | Operators stake to supply infrastructure, earn from real revenue | Yes—when rewards scale with revenue, not inflation |
| 3 | Routing currency + bonding curve | Virtuals VIRTUAL as ecosystem rail | Native token paired with every launched agent token | Speculation-dependent; collapses out of cycle |
| 4 | Subnet-token model | Bittensor (TAO + 128 subnet alphas) | Core token routed to subnets via AMM pools, each subnet has its own alpha | Yes—most sophisticated working design, with subnet-sweep tail risk |
| 5 | Pure agent-launched coin | Agentic Coin, similar memes | "Self-aware AI launches its own crypto"; no actual autonomy | No—structurally broken |
| 6 | Compute-cost-indexed currency | ClawCoin (arxiv 2604.19026) | 1 token = X verified compute-hours, redeemable via DePIN | Theoretical; closest production is AKT pricing |
| 7 | Reputation and credentialing economies | Catena ACK on W3C DIDs + x402 | Agents accrue verifiable reputation that gates access | Pre-PMF; rails exist, demand catching up |
The rest of this article walks pattern by pattern.
## Pattern 1—Platform-revenue buyback-and-burn
### Mechanic
A platform charges fees on user-agent interactions, then uses revenue to buy back and burn its native token on the open market. Deflation accrues to holders without an explicit dividend stream and without the regulatory framing of a security distribution. The same mechanic dominates 2024–2026 generalist crypto tokenomics outside of agents—see the [buyback engineering playbook]({{< relref "models/buyback-engineering" >}}) for the full 5-axis framework (fee source, routing, ownership, execution, sink).
For agent platforms, the design choice is what funds the buyback.
### Live example: Virtuals
Virtuals Protocol on Base became the reference implementation for the agent-launchpad version of this pattern. The mechanic, layer by layer:
- **Agent-creation fee.** Launching a new agent on Virtuals costs 100 VIRTUAL.
- **Bonding curve.** Each new agent's token sits on a bonding curve denominated in VIRTUAL, raising up to 42,000 VIRTUAL.
- **Graduation.** When the curve completes, the agent token mints 1B units paired with VIRTUAL in a 10-year locked LP on a Base DEX.
- **Inference fees.** Agent inference is paid in VIRTUAL, fees flow to a treasury contract.
- **Buyback-and-burn.** Treasury VIRTUAL is bought from the market and burned.
In January 2025 alone, Virtuals bought back and burned 13.05M VIRTUAL—roughly $12M at the accrued buyback price, or about $66M valued at the ATH. On paper, an aggressive deflationary loop.
### Effectiveness
Mixed, leaning negative. VIRTUAL peaked at $5.05 in January 2025 and traded around $0.72 in May 2026—an 87% drawdown from ATH. The buyback announcement produced a transient 30% rally and no durable re-rating.
The structural failure surfaces when you look at where the revenue came from. Daily protocol revenue ran around $1.02M/day in January 2025 and collapsed to about $34K/day by February. The buyback flow tracked the speculation flow, not real agent usage. When secondary speculation on agent-tokens cooled, the buyback dried up automatically. Holders who priced VIRTUAL on the burn number got a lesson in what was actually behind it.
A more durable variant of the same mechanic is OriginTrail (TRAC), where buyback-and-burn is funded by enterprise data revenue from customers including Walmart and BSI. Less liquid, slower, structurally more honest. The price action through 2025–2026 was correspondingly less dramatic in both directions.
{{< callout type="warning" title="What kills buyback-funded designs" >}}
A buyback is only as durable as its revenue source. If revenue is bonding-curve speculation on the platform's own ecosystem tokens, the buyback is a positive-feedback amplifier in both directions. Bull turns into burn; bear turns into nothing. Design for the worst-case revenue path, not the launch-week one.
{{< /callout >}}
### White space
Vertical agent platforms with enterprise subscription revenue, not launchpad-speculation revenue. A buyback fed by SaaS-style ARR scales smoothly with usage and degrades gracefully out of cycle. The design problem is making the fee mechanic compatible with how enterprise customers actually buy (annual contracts, not pay-per-call), without losing the on-chain auditability that justifies a token in the first place.
## Pattern 2—Provider staking and reward distribution
### Mechanic
Infrastructure providers—operators of GPUs, storage, bandwidth, or data—stake the native token to participate. Token-aligned operators earn rewards proportional to verified service delivery. Stake works as skin-in-the-game: misbehavior can be slashed; quality can be priced.
The pattern is inherited from DePIN. For agent platforms, the question is what verifies service delivery and how rewards scale relative to network revenue. The mechanics of Burn-and-Mint Equilibrium that underpin most mature DePIN tokens are derived in [DePIN tokenomics]({{< relref "models/depin-tokenomics" >}}); the agent-specific configurations below assume that derivation.
### Live example 1: Aethir
Aethir is a GPU-DePIN network targeted at enterprise inference and gaming workloads. Operators stake ATH and supply GPU capacity; Checker Nodes verify availability and performance. The economic shape:
- **ARR.** Aethir reported $147M ARR by Q3 2025, with monthly revenue around $13M by late 2025.
- **Token-aligned providers + enterprise SLA.** An unusual combination for DePIN—most networks pick one. Aethir's enterprise contracts force SLA discipline; the token alignment keeps operator incentives sticky.
- **Burn volume.** ATH burn volume tied to network usage is the metric exchanges and analysts track, per KuCoin research updates through Q1 2026.
The lesson from Aethir: Burn-and-Mint Equilibrium (BME) plus an enforceable SLA produces a credible revenue model. Without the SLA, BME degenerates into a token-velocity story.
### Live example 2: Akash
Akash launched its post-2024 BME refresh on March 23, 2026, tying burns to network spending rather than to inflation rewards. The design goal: decouple token economics from emission decay, push value capture toward real network revenue.
- **ARR.** ~$4.2M per BlockEden, April 2026. Small by absolute terms but the highest "earnings DePIN" in the category by revenue-to-mcap ratio.
- **Mcap.** ~$216M token cap—an order of magnitude tighter than Aethir, consistent with the smaller revenue base.
- **BME shape.** Burns scale with network spending, not with fixed-schedule inflation. Under usage growth, the system tilts net-deflationary.
## BME equilibrium: when does the math tip deflationary?
The interesting question is structural: at what level of daily network revenue does buyback-driven burn outpace daily emission? The point where they cross is the equilibrium that separates a sustainable BME design from an inflationary one. Move the sliders to model your own protocol; the formulas are derived from the BME mechanics in the [DePIN tokenomics article]({{< relref "models/depin-tokenomics" >}}).
BME equilibrium calculator
Daily burn
80,000 / day
Net supply change
−76,400 / day
Annual net inflation
−27.89%
Equilibrium revenue
$4.5K / day
Net-deflationary — −27.89% per year at current parameters
The default values reproduce the Aethir-midscale case: at $100K/day revenue and 80% buyback share with $1 token price, the burn outpaces a Bittensor-style 3,600/day emission by an order of magnitude—solidly deflationary. Drop revenue below the equilibrium threshold and the design flips inflationary; lower the burn share and the threshold shifts upward.
### Effectiveness
The pattern works when rewards scale with revenue. It breaks when rewards exceed revenue and the only thing keeping operators in the network is token-price expectation. Old io.net pre-Incentive Dynamic Engine is the canonical breakage example—emission-driven operator yields that were unsustainable in any realistic revenue scenario, papered over by token-price assumptions that did not survive contact with the market.
{{< callout title="The rewards-to-revenue ratio" >}}
A provider-staking design is sound if, in a flat-token-price scenario, operator yield from real network revenue is competitive against opportunity cost (electricity, depreciation, alternative deployment of GPUs). If the design only works under a rising token-price assumption, it is an inflation distribution dressed up as a revenue model.
{{< /callout >}}
### White space
Provider-staking redesign for compute DePIN is, commercially, the most valuable engagement in agent-adjacent tokenomics in 2026. Aethir, Akash, io.net, and new EigenLayer-AVS GPU networks all have unresolved design questions around how staking interacts with slashing, how rewards arbitrate between attestation quality and raw capacity, and how to keep operator yield stable across token-price regimes. Engagement budgets in this segment cluster in the $50–250K range for serious modeling work.
## Pattern 3—Routing currency and bonding curve
### Mechanic
The native token serves as the ecosystem's "routing currency": every new agent-token launched on the platform is paired with it in a liquidity pool. A bonding curve enables permissionless launches and price discovery in the pre-graduation period. Holders of the routing currency hold a transient claim on the speculative flow into new launches.
### Live example: VIRTUAL
VIRTUAL is the textbook routing currency. Every agent launched on Virtuals goes through the bonding curve in VIRTUAL, graduates into a VIRTUAL-paired LP, and pays inference fees in VIRTUAL. The token is the rail. Bonding-curve mechanics are derived more fully in [bonding curve models]({{< relref "models/bonding-curve" >}}).
### Effectiveness
The pattern works in a speculation-heavy regime where new agent launches command attention. It collapses when speculation cools, because the routing demand evaporates—nobody is launching, nobody is graduating, nobody needs to hold VIRTUAL to participate. The Virtuals revenue collapse from $1.02M/day to $34K/day across January–February 2025 is the same fact viewed from the routing-currency angle.
This is not a sustainable-revenue design. It is a fee-on-speculation design. The two should not be confused.
### White space
Two cleaner adjacent designs are open. The first is a bonding curve with an anchored price floor (a hard reserve below which the curve does not transact), reducing slip-circle exposure when new launch volume drops. The second—more interesting—is a routing currency reserved strictly for inter-agent payments, modeled on Catena's [Agent Commerce Kit](https://catena.xyz/) (ACK) on top of W3C DIDs with USDC as the settlement asset. The native token there is identity-and-policy infrastructure, not the value-bearing rail. That separates "platform exists" demand from "speculation is hot" demand.
## Pattern 4—Subnet-token model
### Mechanic
A core protocol token (TAO in Bittensor's case) is distributed across subnets via AMM-style pools. Each subnet has its own alpha-token. When a participant stakes the core token into a subnet, it is technically swapped into that subnet's alpha. Subnets compete for emissions through market-determined alpha valuations: higher alpha price implies more demand for the subnet's work, which routes more core-token emissions there.
This is the most mathematically sophisticated production tokenomics design currently running. The full mechanics, including Yuma Consensus and the validator/miner/owner split, are covered in [Bittensor tokenomics: Yuma, dTAO and the 2025 Halving]({{< relref "models/bittensor-tao-deep-dive" >}}). The pattern catalog only treats the design surface.
### Live example: Bittensor dTAO
- **128 subnets in May 2026**, expanding toward 256 under the dTAO roadmap.
- **TAO mcap $2.58B**, subnet alpha-tokens aggregating ~$1.1B—about 27% of TAO mcap. The alpha layer is large enough to matter and small enough to remain inefficient.
- **Halving Dec 14, 2025.** Emission stepped from 7,200 to 3,600 TAO/day. Subnets compete for a fixed (and now smaller) pie.
- **Institutional validation.** Grayscale GTAO Trust trades OTC (OTCQX); NYSE Arca listing and ETF conversion S-1 pending SEC approval as of early 2026. The most mainstream tokenomics on this list.
### Effectiveness
The strongest design on the list. dTAO genuinely decentralized emission allocation: nobody at the foundation decides which subnet gets paid; the market does. Subnets that produce real ML value attract validators and capital; subnets that do not lose alpha price and emission share.
The tail risk is the subnet-sweep pattern: an opportunistic team launches a subnet, captures emission share through gamed validator weights, fails to deliver durable ML value, and exits. Covenant AI's exit on April 10, 2026—37,000 TAO sold and withdrawal from Templar SN3—made the pattern concrete. The system survived; the precedent did not improve confidence.
{{< callout type="info" title="Subnet alphas as a tokenomics design surface" >}}
Many subnets have an unclear value-accrual story for their own alpha-token. The mechanic that routes core-token emissions to the subnet is well-defined; the mechanic that routes value to alpha holders often is not. Top-30 subnet teams are increasingly buying serious economic-design work in the $30–100K range, especially after the Covenant precedent.
{{< /callout >}}
### White space
Subnet-alpha economic design is open. The Bittensor protocol guarantees that some subnets win on emission—it does not guarantee that any specific subnet's alpha holders win on value capture. Closing that gap with a defensible design is real work, with willing buyers among serious subnet teams.
## Pattern 5—Pure agent-launched coin (the failure)
### Mechanic
The narrative: an autonomous AI launches its own cryptocurrency. The token represents the agent's economy; holders participate in whatever the agent does.
The reality: the agent is a scripted LLM output. The "launch" is a team running a smart contract. The "economy" is a Telegram channel and a Twitter account.
### Live example: Agentic Coin
Agentic Coin is the cleanest case of the pattern, with comparable launches across Solana and Base through 2024–2025. The launch hit the top of the agent meta in late 2024 / early 2025 on the back of viral framing—"the first self-aware crypto." Within months the token was down 99% from launch.
Three structural reasons:
1. **The "agent" was scripted, not autonomous.** No real ability to act, transact, hire, or earn. The token holder owned a fraction of nothing.
2. **No revenue mechanism.** Even if the agent had been real, there was no path from agent activity to token value.
3. **No enforceable behavior.** Holders had no contractual claim on what the agent did. The team could change the prompt, the persona, or the chain at will.
### Effectiveness
Structurally broken. This is the only pattern in the catalog with no working configuration. Variants on the same idea continue to launch and continue to fail in the same way.
The pattern would change verdict only if the agent were genuinely autonomous and revenue-generating—a trading bot with on-chain books and verifiable PnL, an ad-buying agent with on-chain attribution, a content-distribution agent with attestable engagement. The infrastructure for that case is emerging through Catena ACK plus W3C DIDs plus x402 payments. The structural fix is technical, not marketing.
{{< callout type="warning" title="Why the rebrand to 'autonomous agent' rarely changes the verdict" >}}
A token-pre-agent launch with a planned "autonomy upgrade later" is the same design as Pattern 5 with a delay clause. If the autonomy comes online, the project becomes one of the other patterns (1–4) and lives or dies by that pattern's economics. If it does not, holders get what Agentic Coin holders got. Building the autonomy first reverses the order of risk in the only way that survives auditing.
{{< /callout >}}
### White space
For commercial tokenomics work, none. Pattern 5 is the place where consulting engagements get declined. The white space is speculative and engineering-heavy: solve the autonomy problem and the token design becomes interesting; ignore it and the design is fraud-adjacent.
## Pattern 6—Compute-cost-indexed currency
### Mechanic
One token equals X verified compute-hours, redeemable through a network of DePIN compute providers. The token is a stablecoin-like primitive, but indexed against compute capacity rather than against fiat.
Why this matters: compute cost is the binding resource of the AI agent economy, and it is currently locked inside vendor-specific, non-transferable accounts. A compute-indexed primitive would let agents settle obligations in a unit that means the same thing across hyperscalers and DePIN providers.
### Live example (paper): ClawCoin
The reference design is ClawCoin, formalized in [arxiv 2604.19026](https://arxiv.org/abs/2604.19026). Four layers:
- **Basket index** over standardized GPU prices (H100, A100, L4, and successors).
- **Oracle layer** publishing signed fresh attestations from the underlying compute markets.
- **NAV-based mint/redeem vault** with coverage thresholds and rate limits to prevent runs.
- **Settlement layer** on-chain, supporting multi-hop delegations between agents.
The closest production approximations are Akash AKT pricing (which denominates compute pricing in token terms without a stable redemption guarantee) and emerging compute-stablecoin proposals from regulated stablecoin issuers.
To keep the design out of the four-bullet zone, here is a toy NAV calculation for the basket: fix weights of three workhorse GPUs (H100/A100/L4) and their hourly prices, compute the dollar value of one "basket compute-hour", and add a coverage function (the vault must hold more hours of underlying capacity than there are tokens outstanding, otherwise redemption breaks).
```python
# Compute-basket NAV per token, simplified
# Weights reflect 2026 cloud GPU mix used by AI agents
gpu_basket = {
"H100": {"weight": 0.55, "usd_per_hour": 2.30},
"A100": {"weight": 0.30, "usd_per_hour": 1.10},
"L4": {"weight": 0.15, "usd_per_hour": 0.55},
}
# Reference unit: one token = one "compute-hour" of the basket
nav_usd_per_token = sum(
g["weight"] * g["usd_per_hour"] for g in gpu_basket.values()
)
# nav_usd_per_token = 0.55*2.30 + 0.30*1.10 + 0.15*0.55
# = 1.265 + 0.330 + 0.0825 = $1.6775
print(f"NAV per token (USD): ${nav_usd_per_token:.4f}")
# Coverage check: vault holds N hours of underlying capacity
# Total tokens outstanding must be backed by underlying coverage >= 1.0
def coverage_ratio(vault_hours_by_gpu, tokens_outstanding):
nav_hours = sum(
gpu_basket[g]["weight"] * vault_hours_by_gpu[g]
for g in gpu_basket
)
return nav_hours / tokens_outstanding if tokens_outstanding else float("inf")
```
The simplified version drops slashing, oracle staleness penalties, and the rate-limit mechanics that prevent vault drainage during stress—those are the parts of the design where most engineering effort goes.
### Effectiveness
Theoretical for now. The pattern is the most promising intersection of three live trends: DePIN compute markets with real revenue, agent payment rails (x402, ACK) with real volume, and stablecoin-style stability frameworks with real regulatory traction. No production deployment combines all three yet.
### White space
The most commercially valuable design space on this list for academically rigorous teams. Catena Labs, a16z crypto portfolio companies, Circle Ventures targets, and the Base/Solana foundations are the natural buyers for serious modeling work. Engagement budgets cluster at $150–500K for end-to-end design with simulation deliverables.
## Pattern 7—Reputation and credentialing economies
### Mechanic
Agents accumulate verifiable reputation through on-chain attestations or W3C Verifiable Credentials. Reputation gates access to higher-value agent commerce. The token is the unit of stake against reputation and the medium of settlement, but the value-bearing asset is the reputation registry itself.
### Live example (early-stage)
The rails exist:
- **Catena ACK** on W3C DIDs and Verifiable Credentials, MIT-licensed, with credible backing (a16z crypto led the $18M seed in May 2025).
- **x402 plus AgentCore Payments.** Coinbase, AWS, Stripe, Visa, MA, Cloudflare, Microsoft, Google, Circle, Base, Polygon, Solana under a Linux Foundation x402 Foundation umbrella as of April 2026.
- **Active volume.** 69,000 active agents, 165M cumulative transactions, ~$50M cumulative volume via x402 by late April 2026—though "real" daily volume is closer to $28K/day after filtering for gamified flow, per CoinDesk March 2026.
The gap between rails and production volume is significant. The design pattern exists; the demand is still catching up.
### Effectiveness
Pre product-market-fit. This pattern is in the catalog because it is the next pattern that needs design work, not because it has a track record to learn from. Treat the section as a sketch of where the next 18 months of agent-tokenomics engagements will land, not as a recipe.
### White space
Agent reputation tokenomics has almost no competition among tokenomics consultancies. Budgets in this segment range $50–150K, the modeling fit is medium (closer to mechanism-design and game-theory work than to cadCAD simulation), and the buyer universe is the agentic-payments infrastructure stack—Catena, the x402 facilitators, and the larger DePIN operators that will eventually need reputation overlays.
## The white-space matrix
The pattern-by-pattern view collapses into a designer's matrix. For a tokenomics team picking where to invest engineering and modeling effort, the relevant axes are: total addressable market for tokenomics services on this pattern, competitive density (how many other firms are already credibly working there), typical engagement budget, and how well the pattern fits a cadCAD/agent-based-modeling toolchain.
| Pattern | Annual TAM (tokenomics services) | Competition | Engagement budget | cadCAD/ABM fit |
|---|---|---|---|---|
| 1—Platform buyback (vertical agent SaaS) | $5–15M | Sparse | $50–200K | High |
| 2—Provider staking redesign (compute DePIN) | $15–30M | Gauntlet, Sigmacore, Outlier Ventures | $50–250K | Very high |
| 3—Routing currency + bonding curve | Limited—structural ceiling | Sparse | $30–100K | Medium |
| 4—Subnet-token design (Bittensor-style) | $5–15M | Few specialized firms | $30–100K | High |
| 5—Pure agent-launched coin | None (structurally broken) | n/a | n/a | n/a |
| 6—Compute-indexed primitive (ClawCoin-style) | $5–10M | Gauntlet, Block Analitica | $150–500K | Very high |
| 7—Agent reputation / credentialing | $3–10M | Almost none | $50–150K | Medium |
A few reading notes.
**Pattern 2 is the largest current commercial slice.** Provider-staking redesign is where serious compute-DePIN teams have committed budget. The competitive landscape is real but the surface is wide enough to support multiple credible shops.
**Pattern 6 has the highest ticket size per engagement** because the buyer universe is regulated-stablecoin-adjacent and academically demanding. The work is closer to financial engineering than to crypto-native tokenomics.
**Pattern 5 stays in the table as a marker.** Engagements offered around Pattern 5 are the engagements to decline. The reputation hit from a high-profile Agentic-Coin-class failure outweighs the fee in every modeling we have done.
**Pattern 7 is mispriced upward in budget for the maturity of the market.** Treat current quotes as exploratory; the real budgets follow real x402 volume.
## Pitfalls—what kills agent tokenomics
Six failure modes recur across the patterns. They are worth naming because they ride underneath the surface design and cause the bulk of post-launch regret.
**1. Buyback tied to speculation, not usage.** The Virtuals trap. A buyback funded by secondary speculation on the platform's own ecosystem tokens amplifies both directions. Design for the worst-case revenue path.
**2. Inflation rewards exceeding real network revenue.** The old-io.net trap. If, in a flat-token-price scenario, operator yields stop being competitive with opportunity cost, the design is an inflation distribution wearing a revenue label.
**3. Subnet sweep.** The Covenant precedent. Emission-allocation mechanisms that route core-token value via market signals are gameable by opportunistic subnets that capture share without delivering durable work.
**4. Agent-as-narrative-wrapper without real autonomy.** The Agentic Coin trap. If the agent's autonomy lives in the marketing copy and not in the contract surface, the token is unanchored.
**5. Bonding curves with no price floor.** Slip-circle exposure. When launch volume drops, an unfloored bonding curve compounds the drawdown by extracting liquidity in both directions.
**6. Token forced into a workflow where USDC + a smart contract would do.** The "we need a token because" trap. If the workflow runs on USDC settlement and the token's only role is governance over a small treasury, you have built a worse stablecoin with extra steps. The [when-token-not-needed checklist]({{< relref "knowledge/when-token-not-needed" >}}) is the canonical filter.
The patterns that survive the next cycle are the ones designed against these six failure modes from the first whiteboard.
{{< cta title="Need a tokenomics design that survives a cycle?" text="Giants Labs builds tokenomics models, simulations, and audits for serious agent, DePIN, and AVS teams. cadCAD-grade modeling, academic-rigorous documentation, no launchpad work." button="Discuss your design" link="/services/" >}}
---
## Airdrop as a Token Distribution Model
- URL: https://giantslabs.pro/models/airdrop/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Airdrop — free token distribution for activity. Four airdrop types, allocation formulas, sybil protection, sell pressure, and a distribution calculator.
Airdrop is one of the most powerful — and most risky — tools in tokenomics. Done right, it creates a loyal community and distributes governance. Done wrong, it triggers an instant dump and kills the price.
## What Is an Airdrop
An **airdrop** is a free distribution of tokens to users who have met certain conditions. Unlike a sale (ICO, IDO), an airdrop doesn't require a purchase — tokens are credited for past or future activity.
In the context of [supply models]({{< relref "models/token-supply-models" >}}), an airdrop is a method of primary token distribution from the community pool. It answers **"how to deliver tokens to users"** — not through purchase, not through mining, but through merit.
{{< callout title="Airdrop and allocation" type="info" >}}
The airdrop pool is part of the overall [allocation]({{< relref "models/allocation" >}}). A typical airdrop share: 5–15% of total supply. The remaining community tokens go to staking rewards, grants, and ecosystem programs.
{{< /callout >}}
### Why Projects Run Airdrops
1. **Governance decentralization** — broad token distribution reduces vote concentration
2. **User acquisition** — airdrop farming drives traffic and TVL
3. **Early participant reward** — creates loyalty and social proof
4. **Regulatory mitigation** — free distribution reduces risk of classifying the token as a security
## Four Airdrop Types
### 1. Retroactive Airdrop
Tokens are distributed for **past actions**: transactions, protocol usage, testnet participation. Users didn't know about the reward in advance.
This is the most effective type: it rewards real users and minimizes farming. The challenge — defining fair criteria after the fact.
**Examples.** Uniswap distributed 400 UNI to every address that had interacted with the protocol (a swap, liquidity provision, or even a failed transaction) before September 1, 2020; historical liquidity providers and SOCKS holders received significantly more on top. Arbitrum distributed tokens based on transaction count, bridge volume, active months, unique contracts, and Nova usage, with a minimum of 3 of 6 criteria required.
### 2. Criteria-Based Airdrop
Tokens are distributed based on **publicly announced criteria**: transaction count, volume, participation duration, number of unique protocols used.
{{< formula math="Score = Σ(w_i × Action_i)" >}}
- w_i — criterion weight
- Action_i — quantitative value of the action (transactions, volume, active days)
{{< /formula >}}
Advantage: transparency. Disadvantage: incentivizes farming — users deliberately execute criteria.
### 3. Stake-Based Airdrop
Tokens are distributed proportional to **staked assets** or **liquidity**. The user locks capital in the protocol and receives tokens as a reward.
{{< formula math="Reward = Pool × (User_stake / Total_stake)" >}}
- Pool — total airdrop pool
- User_stake — user's stake amount
- Total_stake — sum of all stakes
{{< /formula >}}
### 4. Task-Based Airdrop
Tokens are distributed for **specific tasks**: linking social accounts, referrals, content creation, governance participation. Often implemented through quest platforms (Galxe, Zealy, Layer3).
Advantage: control over user behavior. Disadvantage: attracts bots and farmers, not real users.
### Type Comparison
| Type | Farm resistance | Fairness | User acquisition | Implementation complexity |
|------|----------------|----------|------------------|--------------------------|
| Retroactive | High | High | Low (after the fact) | Medium |
| Criteria-based | Low | Medium | High | Low |
| Stake-based | Medium | Medium | Medium | Low |
| Task-based | Low | Low | High | Medium |
## Designing an Airdrop
### Pool Size
Typical airdrop share in [allocation]({{< relref "models/allocation" >}}): 5–15% of total supply. Key constraint: if the pool is too small, the airdrop won't cover gas costs. If too large — catastrophic sell pressure.
{{< formula math="Min_reward = Gas_claim × 10" >}}
- Min_reward — minimum airdrop per address
- Gas_claim — gas cost to claim
- If the reward doesn't cover gas by 10x, recipients won't claim
{{< /formula >}}
This heuristic assumes L1 gas of $1–5. On L2 chains with sub-cent gas, the binding constraint shifts to a minimum meaningful reward ($5–10 equivalent) rather than gas coverage.
### Sybil Protection
A **sybil attack** is one person creating multiple wallets to receive multiple airdrops. Without robust protection, sybil farmers can capture a significant share of airdropped tokens; estimates vary widely by methodology, from ~22% (Arbitrum, strict Nansen classification) to 60–80%+ (aPriori, contested).
Protection methods:
| Method | Effectiveness | Drawbacks |
|--------|--------------|-----------|
| Minimum balance | Low | Easy to bypass |
| Cluster analysis | Medium | False positives |
| Human Passport (ex-Gitcoin Passport) / World ID | High | Limits audience |
| BrightID | Medium | Requires social verification |
| Non-linear scale | Medium | Doesn't prevent, mitigates |
| KYC (identity verification) | High | Contradicts decentralization |
**Non-linear scale** — the most popular compromise. Instead of a linear "more transactions = more tokens" relationship, a square root function is used:
{{< formula math="Reward(x) = Base + k × √x" >}}
- x — number of actions
- k — scaling coefficient
- √x — diminishing returns: 100 transactions yield not 10× of 10, but only ~3.2×
{{< /formula >}}
The square root dependence makes farming across multiple wallets less profitable than deep usage of a single address.
### Claim Mechanics
Two approaches: push (automatic send to wallet) and pull (user calls the contract).
**Pull (claim)** — the standard approach. Advantages: saves the project's gas, allows a claim deadline, provides engagement data. Unclaimed tokens return to the treasury.
**Claim deadline**: typically 90–180 days, though some run longer. Optimism, for example, kept Airdrop 1 claimable for over 15 months (June 2022 to September 2023) before redistributing ~$66.7M in unclaimed tokens to eligible addresses. Unclaimed tokens otherwise return to the treasury for future rounds.
### Airdrop Vesting
A critical parameter. Without vesting, recipients sell immediately. With long vesting — they don't claim (the reward loses appeal).
| Approach | TGE unlock | Vesting | When to use |
|----------|-----------|---------|-------------|
| Full unlock | 100% | 0 mo | Small pool, loyal audience |
| Partial unlock | 25–50% | 3–6 mo | Standard approach |
| Lock-and-earn | 0% | 6–12 mo, with rewards for holding | Maximum pressure reduction |
{{< callout title="Lock-and-earn as a compromise" >}}
The lock-and-earn model is gaining popularity: received tokens are locked, but the user earns staking rewards from day one. This reduces sell pressure while simultaneously incentivizing retention.
{{< /callout >}}
## Post-Airdrop Sell Pressure
The main airdrop risk is a mass dump. Research shows that 60–80% of airdrop recipients sell tokens within the first 7 days.
{{< formula math="Pressure_d1 = Pool × TGE_% × Sell_rate" >}}
- Pressure_d1 — day-one sell pressure
- Pool — total airdrop pool
- TGE_% — share available immediately
- Sell_rate — 0.6–0.9 (share of the unlocked pool sold day 1)
{{< /formula >}}
**Example.** A project allocates 10% of supply (10M tokens) for airdrop with 100% TGE unlock:
- If 70% of the unlocked pool is sold on day 1: pressure = 7M tokens
- With TGE circulating supply of 20M: that's 35% of float
- Result: price crash
### How to Mitigate Pressure
1. **Partial unlock** — release 25% immediately, the rest over 3–6 months
2. **Holding bonus** — additional tokens for those who don't sell after 30/60/90 days
3. **Day-one staking** — option to stake the airdrop immediately for yield
4. **LP token airdrop** — distribute a liquidity pool position, not the token itself
5. **Gradual distribution** — multiple waves (season 1, season 2) instead of one large event
## Airdrop Distribution Model
In practice, an airdrop is designed in a spreadsheet: for each action or asset, a **weight** is assigned — what share of the pool goes to a specific category. Then the tokens per unit of action and per average/top user are calculated.
### Step 1: Define Actions and Quantities
| Action / asset | Type | Total across users | Average per user | Average for top 10 |
|----------------|------|--------------------|------------------|--------------------|
| Common pet | Asset | 120,000 | 1.0 | 1 |
| Rare pet | Asset | 7,500 | 0.06 | 10 |
| Likes | Asset | 10,000,000 | 83.3 | 80,000 |
| Gems | Asset | 1,500,000 | 12.5 | 10,000 |
| Telegram subscription | Action | 50,000 | 0.42 | 1 |
| Referral | Action | 500,000 | 4.17 | 250 |
| Post on X | Action | 15,000 | 0.13 | 20 |
### Step 2: Assign Weights
Each action gets a weight — a percentage of the airdrop pool. Weights sum to 100%. They define priorities: what the project considers most valuable for the ecosystem.
### Step 3: Calculate the Conversion Coefficient
{{< formula math="K_i = (Weight_i × Pool) / Actions_i" >}}
- K_i — tokens per unit of action i
- Weight_i — action weight
- Pool — total airdrop pool
- Actions_i — total count of this action across all users
{{< /formula >}}
**Key insight:** the top 10 users' airdrop share is **disproportionately high**. If the top 10 farmers clicked 80,000 of 10M likes — they get 0.8% of the likes pool. But if their share of "rare pets" is 13%, that's critical. This is why a non-linear scale (√x) matters for high-variance actions.
**Simulation results** (10,000 participants, 5M token pool, lognormal activity distribution with illustrative parameters):
| Metric | Linear scale | Square root scale (√x) |
|--------|-------------|------------------------|
| Median reward | ~50 tokens | ~350 tokens |
| Maximum reward | ~25,000 tokens | ~4,500 tokens |
| Max / median | 500× | 13× |
| Top 1% receives | 45% of pool | 18% of pool |
| Top 10% receives | 78% of pool | 48% of pool |
| Bottom 50% receives | 3% of pool | 15% of pool |
With a linear scale, one whale with 10,000 actions receives 500× more than an average user. With square root — only 13×. However, for sybil protection, the square root creates an inverse effect: a farm of 100 wallets with 100 actions each, under linear scale, receives the same as one wallet with 10,000 actions (1:1). Under square root — **10× more** (100 × √100 = 1,000 vs √10,000 = 100). Square root equalizes distribution among real users but amplifies the sybil farm advantage — so it only works paired with identity verification (Human Passport, BrightID) or proof-of-humanity.
## Common Mistakes
### 1. Airdrop without sybil protection
Without filtering, farming wallets can capture anywhere from ~20% to 80%+ of the drop, depending on methodology. Minimum: cluster analysis + non-linear scale + minimum activity threshold.
### 2. Full unlock without a retention mechanism
100% TGE unlock without holding incentives = mass dump. Solution: partial unlock or holding bonus.
### 3. Pool too small
An airdrop worth less than $5 equivalent doesn't motivate claiming or participation. Better to have fewer recipients with a meaningful reward than 100,000 addresses at $2 each.
### 4. Criteria that punish real users
Minimum 50 transactions? A real DEX user makes 3–10 swaps per month. Inflated thresholds cut off the genuine audience and reward bots.
### 5. No second season
A one-time airdrop creates a spike and crash in activity. A multi-season structure (season 1, 2, 3) sustains engagement and allows iterating on criteria.
{{< checklist title="Airdrop design checklist" type="check" >}}
Sybil protection implemented — cluster analysis or Human Passport (ex-Gitcoin Passport)
Non-linear scale — square root or logarithmic dependence on activity
Minimum reward covers 10× gas — otherwise recipients won't claim
Sell pressure modeled — calculated with SellRate 70–90%
Vesting or lock-and-earn — no more than 50% TGE unlock
Claim deadline set — 90–180 days, unclaimed tokens return to treasury
Second season planned — multi-season structure retains users
Airdrop does not exceed 15% total supply — more creates excessive pressure
{{< /checklist >}}
{{< cta title="We design airdrops for your protocol" text="We've designed distribution models for 85+ projects — from DeFi to GameFi. We calculate optimal pool size, criteria, and sybil protection." button="Get in touch" link="/quote/" >}}
---
## Allocation and Vesting Template (Google Sheets)
- URL: https://giantslabs.pro/models/allocation-template/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Token allocation and vesting template in Google Sheets: set group shares, cliff, and vesting — get the full unlock schedule and charts automatically.
## Why You Need a Template
Token allocation is one of the first tasks when designing tokenomics. You need to distribute total supply among stakeholder groups, set vesting parameters, and verify that the cumulative unlock schedule doesn't create dangerous sell pressure spikes.
Doing this by hand on paper guarantees errors. A spreadsheet calculates automatically: change one parameter — the entire 60-month schedule recalculates.
Below is a ready-made model in Google Sheets. Open it, make a copy, plug in your numbers.
## Allocation and Vesting Model
{{< gsheet id="11CDs5Mx7vlCYyoKSKN29B2jU0mN99CLapTU--6DStqc" gid="667969241" height="600" title="Allocation parameters" >}}
{{< callout type="info" title="How to use" >}}
Click **File → Make a copy** to edit your own version. Yellow cells with blue text are input parameters, black text is formulas, green text is cross-sheet references.
{{< /callout >}}
## What's Inside the Model
The model consists of five sheets.
### "Input Data" Sheet
Input data for each stakeholder group:
| Parameter | Description |
|---|---|
| **Group** | Stakeholder group name (editable) |
| **Share (%)** | Percentage of total supply allocated to the group |
| **TGE (%)** | Share of the group's tokens available at launch |
| **Cliff (months)** | Period after TGE with no new unlocks |
| **Vesting (months)** | Duration of linear unlock after cliff |
The sheet automatically calculates absolute token amounts, verifies that shares sum to 100%, and computes MC/FDV at TGE.
### "Unlock" Sheet
Monthly calculation of unlocked tokens for each group over a 60-month horizon. The unlock formula:
{{< formula math="U(t) = T × TGE_% + T × (1 − TGE_%) × min(1, max(0, (t − Cliff) / Vesting))" >}}
- U(t) — tokens unlocked by month t (computed)
- T — total tokens in the group
- TGE_% — share unlocked at TGE
- Cliff — cliff period in months
- Vesting — vesting duration in months
- When Vesting = 0: U(t) = T × TGE_%
{{< /formula >}}
Columns:
- **Total** — cumulative unlock across all groups
- **% Supply** — percentage of total supply
- **Monthly delta** — sell pressure (highlighted red if >5%)
### Chart Sheets
Each chart is on its own tab:
1. **Allocation (chart)** — pie chart showing share distribution among groups
2. **Unlock (chart)** — stacked area chart of cumulative unlocks by month
{{< gsheet id="11CDs5Mx7vlCYyoKSKN29B2jU0mN99CLapTU--6DStqc" gid="1614869021" height="500" title="Unlock schedule chart" >}}
### "Checks" Sheet
Ten automatic model validations: sum = 100%, total tokens = supply, team cliff >= 6 months, team vesting >= seed and >= private, MC/FDV in the healthy range, liquidity >= 5%, no zero-share groups, maximum post-TGE monthly unlock <= 5%, and major investor/team cliffs spread >= 3 months apart. On the pre-filled example all ten pass.
## Pre-Filled Example
The model contains a typical allocation for an infrastructure project:
| Group | Share | TGE | Cliff | Vesting |
|---|---|---|---|---|
| Team | 17% | 0% | 12 months | 36 months |
| Seed investors | 6% | 5% | 6 months | 24 months |
| Private investors | 10% | 10% | 3 months | 18 months |
| Community | 20% | 50% | 0 months | 6 months |
| Staking rewards | 15% | 0% | 0 months | 48 months |
| Treasury | 20% | 0% | 6 months | 36 months |
| Liquidity | 8% | 100% | 0 months | 0 months |
| Advisors | 4% | 0% | 6 months | 24 months |
Cliff periods are intentionally staggered: seed — 6 months, private — 3, team — 12. This prevents simultaneous large-volume unlocks.
Community's 50% TGE is aggressive—typical of airdrop-driven launches rather than a universal default. For a slower initial float, drop it to 25–30%.
## How to Adapt for Your Project
1. Copy the spreadsheet via **File → Make a copy**
2. Change **Total Supply** in cell B2 on the "Inputs" sheet
3. Enter your groups, shares, and vesting parameters in the yellow cells
4. Verify that shares sum to 100% (cell B13)
5. Navigate to chart tabs — they update automatically
6. Open the "Checks" sheet — every row should read PASS (10/10 on the pre-filled example). The monthly-unlock check looks at post-TGE months only, so the TGE unlock itself is governed by the separate 10–25% MC/FDV benchmark, not the 5% monthly cap
{{< checklist type="check" >}}
Sum of shares = 100%
Team cliff >= 6 months
Team vesting >= investor vesting
TGE circulating in the 10–25% range
Liquidity >= 5%
Major investor/team cliffs spread >= 3 months apart
{{< /checklist >}}
The 10–25% TGE float benchmark is informed by first-day circulating-supply data for Tier-1 token launches in 2023–2025 (Messari, Binance Research).
For more on allocation principles, common mistakes, and model types — see [Allocation as a Token Supply Model]({{< relref "models/allocation" >}}).
{{< cta title="Need help with tokenomics?" text="We design allocation and vesting models, run stress tests, and deliver ready-to-use spreadsheets." button="Get in touch" link="/quote/" >}}
---
## Automated Market Makers (AMM)
- URL: https://giantslabs.pro/models/amm/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How AMMs work, pricing formulas, impermanent loss, protocol tokenomics, and liquidity design for token launches.
How algorithmic protocols replaced the order book with a mathematical formula, why liquidity pools became the foundation of decentralized exchanges, and what a tokenomist needs to know when designing liquidity.
## What Is an AMM
**AMM (Automated Market Maker)** is an algorithmic protocol that replaces the traditional order book with a mathematical formula for swapping tokens. Instead of matching buyers and sellers, an AMM uses liquidity pools and deterministic equations to calculate the price of every trade.
On a centralized exchange, price is determined by matching orders: someone places a limit buy, someone else a limit sell, and the exchange engine matches them. This model requires sufficient order depth and constant presence of market makers. An AMM eliminates this dependency: **anyone can swap one token for another at any time**, as long as there's liquidity in the pool.
The first AMM appeared in 2017 (Bancor pioneered the continuous token model), followed by Uniswap V1 in November 2018. The real boom came in 2020–2021 — the so-called **DeFi Summer**. By 2026, the combined TVL of AMM-based decentralized exchanges exceeds $10 billion, and the model has become the standard for on-chain token trading.
{{< callout type="info" title="Why this matters for tokenomists" >}}
An AMM is not just a swap mechanism. It's the **primary market** for most tokens. When designing tokenomics, you must decide upfront: which pool will the token trade in, how much initial liquidity is needed, how to manage impermanent loss for LPs, and what incentives to offer for attracting TVL.
{{< /callout >}}
## How a Liquidity Pool Works
The AMM mechanism breaks down into four steps:
1. **A liquidity provider (LP) deposits tokens.** They add a pair of tokens in a specific ratio — for example, ETH and USDC. In return, they receive an LP token confirming their share of the pool.
2. **The pool holds reserves of both tokens.** A smart contract on the blockchain contains the balances of two (or more) tokens. These reserves are the liquidity available to traders.
3. **Price is determined by a formula.** With every swap, the protocol recalculates the token ratio in the pool using a mathematical equation. The more of one token is removed from the pool, the more expensive the next unit becomes.
4. **A trader performs a swap.** They send one token into the pool and receive another. The amount received is calculated by the formula based on current reserves. Each swap incurs a fee (typically 0.3%), which is distributed among LPs.
{{< callout type="info" title="Example" >}}
A pool contains 100 ETH and 200,000 USDC. A trader wants to buy 1 ETH. The protocol calculates how much USDC must be deposited so that after the trade, the product of reserves remains unchanged (or increases by the fee). The trader deposits ~2,020 USDC and receives 1 ETH. After the trade, the pool holds 99 ETH and 202,020 USDC — the price of ETH has increased.
{{< /callout >}}
### The Role of LP Tokens
An LP token is a **proof of share** in the pool. When an LP wants to withdraw their funds, they return (burn) the LP token and receive a proportional share of both tokens from the pool. Important: the token ratio at withdrawal may differ from the ratio at deposit — this is exactly what causes impermanent loss.
### Fees and LP Revenue
Every swap generates a fee (trading fee). The standard is 0.3% of the trade amount in Uniswap V2, though V3 offers tiers of 0.01%, 0.05%, 0.3%, and 1%. Fees are automatically added to pool reserves, increasing the value of LP tokens. LP profitability depends on trading volume: the more swaps pass through the pool, the more fees liquidity providers earn.
## Pricing Formulas
### Constant Product (x × y = k)
The most common AMM formula, used in Uniswap V2, SushiSwap, and PancakeSwap. The product of the two token reserves remains constant after every trade (excluding fees).
{{< formula math="x × y = k" >}}
- x, y — reserves of tokens A and B
- k — invariant (the constant product)
{{< /formula >}}
The price of token A in units of token B is determined by the ratio of reserves:
{{< formula math="P_A = y / x" >}}
- P_A — instantaneous price of token A in units of B
- y, x — reserves of tokens B and A
{{< /formula >}}
The hyperbola x*y=k provides **infinite liquidity** in both directions: the price approaches infinity as one reserve approaches zero, but never reaches it. The tradeoff — large trades relative to pool size produce significant slippage.
### Constant Sum (x + y = k) and StableSwap
The formula x+y=k enables 1:1 swaps with zero slippage, but the pool can be completely drained. For stablecoins (USDC/USDT, DAI/USDC), a curve is needed that behaves like x+y=k for small deviations and like x*y=k for large ones.
Curve Finance solved this with the **StableSwap invariant**:
{{< formula math="A × n^n × Σx_i + D = A × D × n^n + D^(n+1) / (n^n × Πx_i)" >}}
- A — amplification coefficient
- n — number of tokens in the pool
- D — StableSwap invariant
- x_i — reserves of each token
{{< /formula >}}
The parameter A (amplification coefficient) determines how "flat" the curve is near equilibrium. At A=0, the formula degenerates into constant product; as A approaches infinity, it becomes constant sum. Typical values for stablecoin pools: A = 100–2000.
### Concentrated Liquidity
Uniswap V3 introduced **concentrated liquidity**: an LP places liquidity not across the entire price range from 0 to infinity, but only within a chosen interval [P_a, P_b]. This dramatically increases capital efficiency.
{{< formula math="L = Δx × (√P_b × √P) / (√P_b − √P)" >}}
- L — position liquidity
- P_b — upper bound of the range
- P — current price
- Δx — position size in token X
{{< /formula >}}
If an LP limits the range to +/-5% of the current price, their capital efficiency increases roughly 20x compared to Uniswap V2. However, if the price moves outside the range, the position stops generating fees and fully converts into one of the tokens.
{{< callout type="warning" title="The concentrated liquidity tradeoff" >}}
Narrow range = higher fee income but greater impermanent loss and constant rebalancing required. Wide range = less income but less risk. Choosing the range is the key decision for Uniswap V3 LPs.
{{< /callout >}}
## AMM Types
| Protocol | Model | Formula | Key features |
|---|---|---|---|
| **Uniswap V2** | Constant Product | `x*y=k` | Simplicity, universality, full-range liquidity |
| **Uniswap V3** | Concentrated Liquidity | `x*y=k` in range | Up to 4000x capital efficiency, LP chooses price range |
| **Curve Finance** | StableSwap | Sum/product hybrid | Minimal slippage for stablecoins, amplification parameter A |
| **Balancer** | Weighted Pools | `∏(x_i^w_i)=k` | Arbitrary weights (80/20, 60/20/20), up to 8 tokens per pool |
| **Bancor** | Single-Sided | Reserve ratio | Pioneered single-sided LP; IL protection paused since June 2022, pivoted to Carbon DeFi |
| **Aerodrome** | ve(3,3) | Weighted + voting | Dominant DEX on Base (~$0.5B TVL, mid-2026), merging into Aero (2026) |
| **Raydium** | Constant Product + CLMM | `x*y=k` + concentrated | Largest AMM on Solana, formerly hybrid with OpenBook |
| **PancakeSwap** | Constant Product + V3 | `x*y=k` | Largest AMM on BNB Chain, Uniswap analog |
### Weighted Pools (Balancer)
Unlike Uniswap, where both tokens have 50/50 weight, Balancer allows **arbitrary weights**. The generalized invariant formula:
{{< formula math="V = Π(B_i^w_i) = const" >}}
- B_i — balance of token i in the pool
- w_i — weight of token i (weights sum to 1)
- V — Balancer invariant
{{< /formula >}}
An 80/20 pool (e.g., 80% project token and 20% ETH) requires the LP to deposit less ETH, lowering the entry barrier and reducing impermanent loss for the project token. This approach is widely used when launching new tokens via Liquidity Bootstrapping Pools (LBP).
## Impermanent Loss
**Impermanent loss (IL)** is the difference between the value of an LP's assets in the pool and the value of the same assets if they had simply held them without providing liquidity. The loss is called "impermanent" because it disappears if the price returns to the original ratio.
### Where the Loss Comes From
When the price of one token rises relative to the other, arbitrageurs equalize the pool price with the market price, taking the underpriced asset and adding the overpriced one. As a result, the LP ends up with more of the depreciated token and less of the appreciated one — worse than simply holding both assets.
### The Impermanent Loss Formula
For the constant product model (x*y=k, Uniswap V2):
{{< formula math="IL = 2 × √r / (1 + r) − 1" >}}
- IL — impermanent loss
- r = P₁/P₀ — ratio of current price to initial price
- Applicable to AMMs with the x·y=k invariant (Uniswap V2, SushiSwap, PancakeSwap)
{{< /formula >}}
Reference points:
| Price change | Price ratio (r) | Impermanent loss |
|---|---|---|
| No change | 1.0x | 0% |
| +25% | 1.25x | −0.6% |
| +50% | 1.50x | −2.0% |
| +100% (2x) | 2.0x | −5.7% |
| +200% (3x) | 3.0x | −13.4% |
| +400% (5x) | 5.0x | −25.5% |
| −50% | 0.5x | −5.7% |
| −75% | 0.25x | −20.0% |
| −90% | 0.1x | −42.5% |
r is the ratio of the new token price to the initial price. r=2 means the price doubled; r=0.5 means it halved.
{{< callout type="warning" title="Key insight" >}}
Impermanent loss is symmetric: a 2x price increase and a 2x decrease produce the same IL (−5.7%). Losses accelerate nonlinearly at extreme deviations. At a 10x price change, the LP loses ~42% compared to simply holding.
This formula and table apply to AMMs with the x*y=k invariant (constant product). For other models — Curve StableSwap, Uniswap V3 concentrated liquidity, Balancer weighted pools — the IL calculation differs and depends on additional parameters (amplification coefficient A, range width, token weights).
{{< /callout >}}
### When Fees Offset Impermanent Loss
An LP earns fees from every swap. If the annualized fee yield exceeds impermanent loss over the same period, the liquidity provider profits. This requires:
- **High trading volume** relative to pool size (high capital turnover)
- **Moderate volatility** of the token pair (IL grows with volatility)
- **Additional incentives** via governance token rewards (liquidity mining)
## AMM Protocol Tokenomics
AMM protocols are themselves tokenomic systems. Here's how they generate revenue and distribute value.
### Revenue Streams
The primary revenue source is **trading fees**. Every swap generates a fee distributed among participants:
```
Fee distribution (typical model):
Trader pays fee (0.3%)
├── 0.25% → Liquidity providers (LP)
└── 0.05% → Protocol treasury / token holders
Additional revenue sources:
├── Flash loan fees
├── Pool creation fees
└── Protocol-Owned MEV revenue
```
### Governance Token and Incentives
Most AMM protocols issue a **governance token**: UNI for Uniswap, CRV for Curve, BAL for Balancer. These tokens serve several functions:
- **Voting** — holders decide on protocol parameters (fee levels, reward distribution, new pools)
- **Liquidity incentives (liquidity mining)** — protocol distributes governance tokens to LPs to attract TVL
- **Value capture** — a portion of fees goes to token holders (fee switch)
### The ve-Token Model (Vote-Escrowed)
Curve Finance pioneered the **ve-token model**, which has become the standard for AMM protocols. The mechanics:
1. User locks CRV for a period from 1 week to 4 years, receiving veCRV
2. Longer lock = more votes and larger share of fees
3. veCRV holders vote on CRV reward distribution across pools (gauge voting)
4. Protocols "bribe" veCRV holders to direct rewards to their pools — hence the term "Curve Wars"
{{< callout type="info" title="Why ve-model works" >}}
The ve-model aligns interests: long-term holders get more influence and revenue, short-term speculators get less. This reduces sell pressure on the token and creates a sustainable incentive ecosystem around liquidity. See [veTokenomics]({{< relref "models/ve-tokenomics" >}}) for a deep dive.
{{< /callout >}}
### The Mercenary Capital Problem
Liquidity mining attracts capital, but this capital often leaves as soon as rewards end. Protocols lose TVL, and the governance token depreciates due to constant emissions. Solutions:
- **Ve-model** — token locking reduces circulating supply and sell pressure
- **Protocol Owned Liquidity (POL)** — the protocol itself owns liquidity instead of renting it
- **Real yield** — rewards paid from fees, not from emissions
- **Performance-linked incentives** — rewards proportional to trading volume, not just position size
## Liquidity Design
For a tokenomist, an AMM is not a given — it's a tool whose parameters must be designed. Key decisions at token launch:
### Choosing the AMM and Pair
- **Which blockchain?** Ethereum (Uniswap, Curve), BNB Chain (PancakeSwap), Solana (Raydium), or multichain
- **Which pair?** TOKEN/ETH, TOKEN/USDC, or TOKEN/stablecoin — depends on the target audience
- **Which model?** Constant product for standard tokens, StableSwap for stablecoins, Weighted pool for launches via LBP
- **Which fee tier?** Uniswap V3 offers 0.01%, 0.05%, 0.3%, and 1% — volatile pairs benefit from higher fees
### Initial Liquidity
Initial liquidity size determines **market depth** and acceptable slippage. Rule of thumb: slippage on a $10,000 trade should not exceed 1–2%.
{{< formula math="Slippage ≈ Δx / x" >}}
- Δx — trade size
- x — total reserve of the corresponding token in the pool
{{< /formula >}}
For slippage under 2% on a $10,000 trade, you need a pool with at least $500,000 in reserves per token. This implies initial liquidity of $1,000,000+. For smaller projects, a realistic minimum is $50,000–200,000 with the understanding that large trades will have significant slippage.
### Liquidity Incentive Programs
A typical liquidity mining program includes:
```
Incentive program parameters:
1. Budget: 5–10% of total token supply
2. Duration: 6–12 months with gradually decreasing rewards
3. Distribution: Proportional to LP's share of the pool
4. Decay: −10 percentage points each quarter
5. Bonus: Boosted rewards for the first 30 days
Example schedule (12 months, 8M token budget):
Q1: 3.2M tokens (40%)
Q2: 2.4M tokens (30%)
Q3: 1.6M tokens (20%)
Q4: 0.8M tokens (10%)
```
### Protocol Owned Liquidity (POL)
**POL** is a model where the protocol itself owns liquidity in the pool rather than renting it from external LPs. Advantages:
- **Sustainability** — liquidity won't leave when rewards end
- **Revenue** — protocol earns trading fees
- **Control** — can manage market depth and slippage
- **No dilution** — no need to emit tokens for incentives
Sources of POL: a portion of token sale proceeds (IDO, LBP), treasury revenue, bond mechanics (buying LP tokens at a discount from users). The ideal balance is POL as the liquidity base combined with an incentive program for additional TVL.
{{< callout type="info" title="Recommendation" >}}
When designing liquidity, first determine the minimum required pool depth (based on expected trade volume), then split it into POL (stable portion, 40–60%) and incentivized liquidity (variable portion, 40–60%). Have a contingency plan for incentivized liquidity outflows.
{{< /callout >}}
## Trends
### Concentrated Liquidity as the Standard
After Uniswap V3, concentrated liquidity became the industry standard. PancakeSwap, SushiSwap, and dozens of other AMMs adopted similar models. Automated position managers (Arrakis, Gamma) and yield optimizers (Beefy) emerged to rebalance ranges and auto-compound fees for LPs, lowering the entry barrier.
### Uniswap V4 Hook Architecture
Uniswap V4 introduces **hooks** — custom smart contracts that execute before or after specific pool actions (swap, add/remove liquidity). This turns the AMM into a **programmable platform**:
- **Dynamic fees** — fees change based on volatility or volume
- **TWAMM** — execution of large orders at a time-weighted average price
- **On-chain limit orders** — automatically execute when the target price is hit
- **Custom curves** — any pricing formula, not just x*y=k
- **KYC/permissioned pools** — pool access only for verified addresses
The V4 singleton architecture (all pools in one contract, launched January 2025 on 10+ chains) reduces pool creation costs by ~99% and swap costs by ~30% (up to ~50% for multi-hop routes) compared to V3.
### Intent-Based Trading
A new approach to decentralized trading: instead of interacting directly with a pool, the trader describes an **intent** — "I want to swap 1 ETH for the maximum amount of USDC." A network of solvers then competes to fulfill this intent, finding the optimal route across multiple pools, bridges, and liquidity sources.
UniswapX, CoW Protocol, and 1inch Fusion already operate on this model. For LPs, this means competing not only with other pools but with off-chain market makers.
### Cross-Chain AMMs
Liquidity remains fragmented across blockchains. Cross-chain AMMs (Thorchain, Chainflip) enable native asset swaps between networks without bridges, while cross-chain aggregators (Squid Router, Li.Fi) route trades through multiple liquidity sources and bridges.
{{< callout type="info" title="Takeaway for tokenomists" >}}
When designing liquidity in 2026, consider: (1) concentrated liquidity as the baseline model, (2) hooks for dynamic fees and automation, (3) intent-based trading as an additional volume source, (4) a multichain strategy to reach different audiences. The specific AMM choice depends on token type, target market, and available liquidity budget.
{{< /callout >}}
{{< cta title="Designing liquidity for a token?" text="We'll select the optimal AMM model, calculate initial liquidity, and design an incentive program." button="Get in touch" link="/quote/" >}}
---
## Babylon BSN Tokenomics: BTC as Programmable Collateral
- URL: https://giantslabs.pro/models/babylon-bsn-tokenomics/
- Section: models
- Date: 2026-05-11
- Last modified: 2026-05-11
- Description: Engineering deep-dive on Babylon tokenomics: 10B BABY supply, 8% inflation, dual-staking math, finality provider economics, $5.6B+ BTC TVL, BSN reward auction, and the multi-BSN design that turns Bitcoin into programmable collateral.
**Babylon tokenomics** sits at an interesting place in the 2026 BTC-restaking landscape. A year after launch, Babylon Genesis holds roughly **$4.1 billion in BTC** locked across non-custodial Bitcoin staking vaults (down from a peak above $5.6B following the April 2025 Phase 1 cap rotation). Over **250 finality providers** validate the chain. The native BABY token, launched on **April 10, 2025** with a fixed initial supply of **10 billion**, now anchors a dual-staking economy that was upgraded into a four-pool **co-staking model** in November 2025: BTC holders, BABY holders, and **co-stakers** who pair both assets together share the inflation pool, while finality providers and validators take a small slice for operational compensation.
The interesting part is what comes next. Phase 3 of the Babylon roadmap—multi-staking across multiple Bitcoin Supercharged Networks (BSNs) such as BOB, Osmosis, and Sui—is in active rollout through 2026, with the first non-Genesis BSNs progressing through onboarding. That single design decision—let one BTC deposit collateralize many chains—recasts Bitcoin from a passive asset into programmable collateral and rewrites the economics of every protocol downstream.
This article dissects the Babylon tokenomics mechanism end-to-end. We walk through the BABY token design, the math behind dual-staking and finality provider rewards, the 10-billion-token allocation and vesting schedule, the failure modes already visible in early operation, and the open questions raised by multi-BSN expansion. The goal is to give engineers and tokenomics designers the working model—not a description of features, but a critique of the design choices and where they bend under pressure.
{{< callout title="Why Babylon design matters now" type="info" >}}
Babylon is the first protocol to make BTC act as PoS collateral without bridging or wrapping. If multi-BSN scaling works, every L1, rollup, and AVS gets a credible alternative to ETH-restaking. If it breaks—and BTC LST concentration plus cross-BSN slashing correlation are real engineering risks—the failure mode lands directly on the asset most of crypto treats as the safe-haven layer.
{{< /callout >}}
## The Concept: Co-Staking Model and Programmable Bitcoin Collateral
Babylon's tokenomics rests on two tokens with separable—but increasingly entangled—roles. BABY is the native gas, governance, and reward token of Babylon Genesis, a Cosmos SDK Layer-1 chain that acts as the control plane for the whole BSN network. The reward economy was upgraded from a 50/50 dual-staking split into a four-pool co-staking model in November 2025 (covered in detail in the Math section): BTC stakers, BABY stakers, and co-stakers who pair both assets each receive their own share of the BABY inflation pool, with co-stakers favored. Per-BSN tokens (the native asset of BOB, Osmosis, Sui, and any future BSN) are independent: they pay finality providers in their own asset, govern their own chains, and route a configurable share of staking rewards back into the BABY economy through a burn auction.
This is a meaningful departure from EigenLayer's design. EigenLayer asks ETH stakers to opt into additional slashing risk (Actively Validated Services) in return for additional yield denominated in the AVS's own token. Babylon instead asks BTC holders to lock their coins under a Bitcoin-native time-lock, then delegates voting power to finality providers running on each BSN. The BTC never leaves Bitcoin; the security extends through cryptographic commitments rather than a wrapped representation.
The mechanism that makes this possible is a combination of **Taproot time-locks** and **Extractable One-Time Signatures (EOTS)**. A staker locks BTC into a Taproot output that can only be spent under specific conditions: an honest unbonding path with a time delay, a slashing path triggered by a verifiable double-sign, or a covenant emulation path managed by a multi-signature committee during the protocol's bootstrap phase. The finality provider votes on BSN block finality using an EOTS signature; if the same finality provider signs two conflicting blocks, the second signature mathematically reveals the private key, which a slashing transaction then uses to spend the staked BTC according to the protocol's pre-approved slashing percentage.
{{< formula math="EOTS_uniqueness: if sig₁(msg₁, k) ∧ sig₂(msg₂, k) ∧ msg₁ ≠ msg₂ ⇒ privkey extractable" >}}
- sig₁, sig₂—two finality votes signed with the same nonce k
- msg₁, msg₂—two distinct block proposals at the same height
- The cryptographic guarantee: a finality provider cannot equivocate without losing the key that controls their stake
{{< /formula >}}
This is what "programmable Bitcoin collateral" means in practice. The protocol does not move BTC, does not require federated bridges, and does not depend on optimistic challenges. Slashing is enforced by Bitcoin script and the cryptographic structure of the signature itself. The trust assumption is the covenant emulation committee during bootstrap, which the roadmap retires as soon as Bitcoin gains native covenant support (a long-debated soft-fork direction).
The comparison with EigenLayer surfaces the design tradeoffs cleanly:
| Dimension | Babylon | EigenLayer |
|---|---|---|
| Collateral asset | BTC (non-custodial, native) | ETH or LSTs (re-delegated to AVS) |
| Slashing enforcement | Bitcoin script + EOTS key extraction | EigenLayer slashing contracts on Ethereum |
| Onboarding unit | BSN (full sovereign chain) | AVS (service running on Ethereum security) |
| Reward routing | BSN routes share of rewards into BABY burn auction | AVS pays operators in its native token directly |
| Programmability constraint | Limited by Bitcoin script + soft-fork pace | Full EVM expressivity on Ethereum |
| Capital efficiency | Single BTC deposit secures multiple BSNs (Phase 3) | Single ETH deposit secures multiple AVSs (live) |
| Bootstrap trust | Covenant emulation committee until soft-fork | Pre-launch security council + slashing veto window |
EigenLayer's restaking is documented in [our staking article]({{< relref "models/staking" >}}); Babylon implements the same economic idea—letting one collateral pool secure multiple services—but does it on top of Bitcoin's settlement layer instead of Ethereum's execution layer. That choice trades programmability for credible neutrality and a much larger collateral base, since BTC liquidity dwarfs ETH staking liquidity by roughly an order of magnitude.
{{< callout title="Restaking inherits correlation risk, but the slashing tail is thin" type="warning" >}}
Babylon's design inherits the same structural correlation as EigenLayer: a single staker's collateral now carries the slashing exposure of every BSN it secures. If two BSNs experience correlated failures—a coordinated attack, a shared client bug, a governance attack on Babylon Genesis itself—slashing events compound. But the per-event BTC slash is only 0.1% of principal, so even several correlated slashes stay well under 1%. The correlation worth modeling here is operational—shared FP infrastructure, common client bugs, the liquidity of BABY-denominated yield—not a compounding-to-wipeout slashing tail.
{{< /callout >}}
## Math: Emission, Vesting, Finality Provider Economics
Three numerical mechanics drive the BABY economy: annual inflation that funds reward distribution, a multi-year vesting schedule that controls supply unlock pressure, and the finality provider reward formula that determines unit economics for the validator set.
### Inflation, Reward Split, and Co-Staking
BABY launched with a fixed initial supply of 10 billion tokens and an annual inflation rate of 8%, originally split 50/50 between BTC stakers and BABY stakers. That two-pool design lasted about six months. In **October 2025** a [governance proposal](https://forum.babylon.foundation/t/inflation-reduction-and-the-introduction-of-co-staking/718) cut inflation and restructured the reward split into **four pools**, introducing co-staking as a first-class mechanism. The new parameters went live with the mainnet upgrade on **November 13, 2025** (full parameters are documented in [Babylon's tokenomics docs](https://docs.babylonlabs.io/guides/overview/babylon_genesis/baby_tokenomics/)).
{{< formula math="Annual_emission = Supply × inflation_rate = 10·10⁹ × 0.055 = 550,000,000 BABY/year" >}}
At current parameters: 550M BABY emitted per year, ~1.51M BABY per day. Inflation is governance-adjustable; expect further cuts as multi-BSN expansion broadens the protocol's revenue base.
{{< /formula >}}
{{< formula math="Reward_split: BTC_pool 1.0% + BABY_pool 2.0% + Co_stakers 2.35% + FP_validators 0.15% = 5.5%" >}}
- **BTC pool (1.0%)**—~100M BABY/year to pure BTC stakers (no BABY position)
- **BABY pool (2.0%)**—~200M BABY/year to pure BABY stakers (no BTC position)
- **Co-stakers (2.35%)**—~235M BABY/year, the largest slice, deliberately reweighted to reward dual exposure
- **FP + validator operational pool (0.15%)**—~15M BABY/year for direct operator compensation
{{< /formula >}}
The shift toward co-staking is the most consequential design choice in the new schedule. Co-staking pairs BTC and BABY into a single eligible position, with the eligible weight set by the smaller of the two sides (capped at a fixed BABY-to-BTC ratio).
{{< formula math="Eligible_co_stake = min(B_BABY / 20,000, B_BTC)" >}}
- B_BABY—BABY balance committed by the staker
- B_BTC—BTC balance committed by the staker
- 20,000—the BABY-to-BTC ratio that defines maximum eligible co-stake per BTC unit
- Pairing rewards the staker out of the 2.35% co-staker pool; unpaired BTC and BABY balances earn from the 1.0% / 2.0% pools at lower yield
{{< /formula >}}
These four pools then divide pro-rata across delegations. A BTC staker's annual yield is their proportional share of the BTC pool minus the finality provider's commission. A co-staker's yield is calculated against the larger 2.35% pool, which produces a meaningfully higher per-unit return when the BABY position fully covers the BTC position. All yields are denominated in BABY, so BTC stakers accept BABY price exposure as part of the deal—a tradeoff the co-staking design partially compensates for by pulling more BABY into the staker's hands directly.
### Vesting Schedule and Unlock Pressure
The 10-billion supply is fully accounted for at genesis but unlocks over four years according to bucket-specific rules. The schedule below is the canonical one published in Babylon's tokenomics documentation, with cumulative unlock percentages by bucket year over year.
| Bucket | Allocation | Unlock rule | Year 1 unlocked | Year 2 | Year 4 (full) |
|---|---:|---|---:|---:|---:|
| Early Investors | 30.5% (3.05B) | 4-year vesting; 12.5% at year 1 cliff, then linear over remaining 3 years | 12.5% | 41.7% | 100% |
| Ecosystem Building | 18.0% (1.8B) | 25% at TGE, then linear over 3 years from year 1 | 50.0% | 75.0% | 100% |
| R&D + Operations | 18.0% (1.8B) | Same as Ecosystem | 50.0% | 75.0% | 100% |
| Team | 15.0% (1.5B) | 4-year vesting, 1-year cliff, then linear over 3 years | 25.0% | 50.0% | 100% |
| Community Incentives | 15.0% (1.5B) | Unlocked at TGE, distributed at Foundation discretion | 100% | 100% | 100% |
| Advisors | 3.5% (350M) | 4-year vesting (terms similar to Team) | 25.0% | 50.0% | 100% |
The most important number for circulating-supply modeling is the year-1 cliff. By April 2026, a year after Genesis launch, the protocol crosses several discontinuous unlock events: the 12.5% Investor cliff (~381M BABY), the 25% Team cliff (~375M BABY), and the ongoing linear unlocks for Ecosystem and R&D buckets (~25% of each bucket per year per the vesting table, ~900M BABY combined annually, or ~225M per quarter). The combined supply pressure landing on the Q2 2026 cliff window—the two cliffs plus one quarter of Ecosystem/R&D linear unlock—is roughly **1.0 billion BABY**, on top of ongoing 5.5% inflation (the post-November 2025 rate; year-1 emission under the original 8% schedule was ~800M).
That is a meaningful headwind for the token. Whether the BSN burn auction (covered in the Advanced section) can offset it depends entirely on how many BSNs go live and how aggressively they route rewards into the auction.
### Finality Provider Economics
Finality providers (FPs) are the validators of Babylon Genesis and any BSN. Each FP runs the consensus client, votes on block finality using EOTS signatures, and earns a commission on the rewards routed to delegators who stake to them. The reward formula has three inputs: the FP's stake-weighted share of total network stake, the per-period reward pool, and the FP's commission rate.
{{< formula math="FP_revenue(t) = (S_FP / S_total) × R_pool(t) × c_FP" >}}
- S_FP—total stake delegated to this FP (BTC + BABY-equivalent)
- S_total—total stake across all FPs
- R_pool(t)—reward pool for period t (per-block emission share)
- c_FP—commission rate, typically 5–15%
{{< /formula >}}
Slashing is the inverse calculation. When an FP equivocates—signs two conflicting block proposals at the same height—the EOTS construction reveals the private key, and the protocol burns or redirects a pre-defined fraction of every delegator's stake under that FP. The same fraction applies to BTC and BABY delegations.
{{< formula math="Stake_after_slash = Stake × (1 − s_pct), with s_pct = 0.1% (0.001) for BTC double-sign equivocation" >}}
- s_pct—the protocol-set slashing fraction; for a finality-provider double-sign on Babylon Genesis it is **0.1% of the staked BTC principal** (the `slashing_rate` parameter in the `btcstaking` module, capped at a maximum ratio of 0.1% in Phase 2)
- Three distinct numbers are easy to conflate: a BTC finality-provider double-sign slashes **0.1% of staked BTC**; a BABY validator double-sign slashes **5% of staked BABY** (the classical CometBFT convention); and the academic **≥1/3** figure is a Byzantine safety *bound*—the share of voting power that is slashable—not a burn percentage
- Loss is borne by both the FP's own stake and delegated stake proportionally
- A liveness fault (extended downtime) carries no slashing at all; only safety violations (equivocation) trigger the 0.1% BTC slash
{{< /formula >}}
This number is often misread as large; it is deliberately small. Babylon's BTC safety slash on Babylon Genesis takes only 0.1% of the principal in a single event—a conservative parameter that keeps a BTC staker close to whole through an honest operator's occasional mistake. The real risks for a BTC staker lie elsewhere: LST concentration, finality-provider centralization, and the BABY-price exposure embedded in BABY-denominated yield. The mitigation is still operational: avoid FPs without proven uptime, key management, and monitoring. The arithmetic barely moves under multi-BSN exposure—we develop the cross-BSN compounding case in the Pitfalls section, where even five correlated slashes stay under half a percent.
This dynamic is what drives FP centralization, and we revisit it in the Pitfalls section. For background on how validators construct their unit economics from emission, fees, and MEV, see [our breakdown of validator payment models]({{< relref "validators/validator-payment-models" >}}).
## Implementation: 10B BABY Allocation, BSN Design Space, FP Onboarding
Walking through the implementation makes the supply-side dynamics concrete. The 10-billion BABY supply is split across six buckets shown in the vesting table above, but the design intent behind each allocation is worth unpacking—particularly because three of the six buckets are governed by the Babylon Foundation, which gives that entity meaningful discretion over the early circulating supply.
### Allocation Design Logic
The 30.5% allocation to early investors is on the high end for a 2025-era L1 launch, and the 4-year vesting with a 1-year cliff is conventional. The notable detail is that the first investor unlock is structured as a 12.5% cliff at year one rather than a continuous linear release from day one—this concentrates supply pressure into a single discontinuity that the market must absorb. Some investor classes (advisors, late-stage strategic) follow the same structure, compounding the year-1 unlock cluster.
The 30% combined Ecosystem (18%) + R&D (18%) allocation is structurally similar to other Cosmos SDK chain launches: a substantial Foundation treasury denominated in the native token, used to fund infrastructure, validator subsidies, security audits, and ecosystem grants. The 25% TGE unlock for these two buckets is unusual—most chains keep treasury allocations vested for longer to signal stewardship—and the high TGE unlock implies the Foundation expects substantial spending in year one to bootstrap BSN integrations.
The 15% Team and 15% Community Incentives allocations are roughly conventional, though the Community bucket being fully unlocked at TGE is again a Foundation-discretion choice rather than a pre-committed schedule. The April 2025 Genesis airdrop of 600M BABY (6% of supply, all from the Community Incentives bucket) was the first major use of this discretion.
The Advisors allocation at 3.5% is small enough not to matter for supply dynamics but large enough to fund a substantial advisor network—implying a deliberate strategy of buying expertise across cryptography, validator infrastructure, and Cosmos governance rather than concentrating advisor allocations on a few high-profile names.
### BSN Design Space
When a new BSN onboards (BOB, Osmosis, Sui being the first wave), it confronts a fixed set of design choices that determine how its tokenomics interact with the BABY economy:
1. **Reward token denomination.** The BSN can pay finality providers in its own native token (the default for Cosmos chains and the path BOB has indicated), in BABY (relevant for chains without their own token), or in a stablecoin (an option Sui has explored). Native-token payment is most aligned with the BSN's own incentive design but creates dependency on that token's secondary-market liquidity for FPs to realize value.
2. **Reward auction routing share.** A configurable percentage of BSN rewards routes into the BABY burn auction (the deflationary mechanism covered in the Advanced section). Higher routing share creates more BABY burn pressure but reduces the BSN's direct compensation to finality providers, requiring a higher native-token reward to keep FPs participating.
3. **Slashing percentage.** Each BSN can set its own slashing rate for finality violations within the protocol-defined bounds. Lower percentages reduce per-event capital risk and attract larger BTC delegations; higher percentages attract more conservative FPs and signal stronger security guarantees.
4. **Bootstrap subsidy.** Most BSNs need to attract initial FPs and BTC delegations before native-token rewards can sustain the validator set. This typically requires a Foundation grant in BABY or stablecoin terms, paid out of the Ecosystem bucket as a one-time subsidy.
These design knobs interact, and getting the balance wrong is the single most likely failure mode for a new BSN—a topic we return to under Pitfalls.
### FP Onboarding and Unit Economics
A finality provider running on a single BSN faces straightforward unit economics: stake delegation, commission rate, infrastructure cost, slashing risk reserve. The numbers shift meaningfully when an FP scales to operate on multiple BSNs simultaneously, which is the Phase 3 expectation.
## FP Unit Economics Calculator
FP Unit Economics Calculator
Pool gross (BABY)
88,000
FP commission (BABY)
8,800
Infra cost (BABY)
18,000
Net BABY (FP profit/loss)
−9,200
Net USD
−$552
Breakeven stake / BSN
409.1 BTC
Single-event slash loss
0.20 BTC ($19,800)
At current parameters: a finality provider needs roughly 409 BTC delegated per BSN to break even.
The calculator above lets you vary stake, BSN coverage, commission, infrastructure cost, slashing fraction, and live BABY/BTC prices. Outputs: pool gross / FP commission / infra cost (top row), **net BABY / net USD** (color-coded), breakeven stake per BSN, and single-event safety-slash loss. The bar chart shows net BABY across BSN counts 1–10 at the current other-parameter values—use it to see at what BSN count the FP transitions from loss to profit at your stake and commission.
For the full math behind the calculator—including the per-BSN reward function, multi-BSN cost structure, and slashing tail expectation—the Python implementation below is the canonical reference. The summary table comes first; the simulation code follows. The figures assume a BABY-denominated annual yield of ~440 BABY per BTC delegated per BSN (implied from the post-November 2025 4-pool inflation split, with co-staking not modelled separately).
| Scenario | Stake (BTC) | BSNs operated | Commission | Pool gross BABY (delegator-facing) | FP commission BABY | Infra cost (BABY) | Net BABY to FP | Breakeven stake (BTC/BSN) |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| Small solo FP | 50 | 1 | 10% | 22,000 | 2,200 | 18,000 | −15,800 | ~409 BTC |
| Mid-size solo FP | 200 | 1 | 10% | 88,000 | 8,800 | 18,000 | −9,200 | ~409 BTC |
| Multi-BSN operator | 200 | 5 | 10% | 440,000 | 44,000 | 90,000 | −46,000 | ~409 BTC/BSN |
| Top-10 FP (multi-BSN) | 2,000 | 5 | 8% | 4,400,000 | 352,000 | 90,000 | 262,000 | ~511 BTC/BSN |
The economies of scale are explicit in this table—and so is the cost of running on subscale economics. At 5.5% inflation with the post-November split, a 10% commission, and ~$18K BABY in annual infrastructure cost per BSN, even a 200 BTC mid-size operator on one BSN runs negative; the breakeven stake per BSN at default parameters is roughly **409 BTC**. Profitability requires either a much larger delegation (~2K BTC at 10%), a substantially higher commission (~20%+), or operating multiple BSNs while keeping infrastructure cost shared. The top-10 multi-BSN row is the only sustainably positive scenario in the canonical parameter set—and even there, the breakeven rises to ~511 BTC/BSN because the commission is lower (8%, the price top operators pay for delegation share).
Python: FP unit economics simulation
```python
def fp_unit_economics(
stake_btc: float,
btc_price_usd: float,
baby_price_usd: float,
commission_rate: float,
bsn_count: int,
annual_reward_per_btc_baby: float,
infra_cost_baby_per_bsn: float,
slashing_reserve_pct: float = 0.05,
):
"""
Compute net annual revenue and breakeven stake for a Babylon FP.
Assumptions:
- Reward per BTC denominated in BABY is the same across BSNs (simplification).
- Infra cost scales linearly with BSN count (worst case; in practice partially shared).
- Slashing reserve is held back from delegator-facing yield.
"""
gross_baby = stake_btc * annual_reward_per_btc_baby * bsn_count
fp_share_baby = gross_baby * commission_rate
infra_total = infra_cost_baby_per_bsn * bsn_count
net_baby = fp_share_baby - infra_total
net_usd = net_baby * baby_price_usd
breakeven_stake = (
infra_cost_baby_per_bsn /
(annual_reward_per_btc_baby * commission_rate)
)
return {
"gross_baby": gross_baby,
"fp_revenue_baby": fp_share_baby,
"infra_cost_baby": infra_total,
"net_baby": net_baby,
"net_usd": net_usd,
"breakeven_stake_btc_per_bsn": breakeven_stake,
"slashing_reserve_baby": fp_share_baby * slashing_reserve_pct,
}
# Sample run for a mid-size multi-BSN operator
result = fp_unit_economics(
stake_btc=200,
btc_price_usd=99_000,
baby_price_usd=0.06,
commission_rate=0.10,
bsn_count=5,
annual_reward_per_btc_baby=440, # implied from post-November 2025 5.5% inflation 4-pool split, FP delegation share
infra_cost_baby_per_bsn=18_000,
)
for k, v in result.items():
print(f"{k}: {v:,.2f}")
```
The calculator and the simulation use the same parameter set—change inputs in the calculator to explore the slope of the unit-economics curve. The Python is the audit trail.
## Pitfalls: Concentration, Bootstrap Risk, Cross-BSN Correlation
A protocol with $4B+ in TVL and 250+ finality providers has already encountered enough live operational stress to expose its weak points. Three pitfalls deserve particular attention because they shape design decisions for any new BSN onboarding.
### Lombard $1.26B Unbonding (April 2025): Plan, Not Panic
The most instructive operational event in Babylon's first year happened immediately after the Phase 1 Cap-1 expiration in April 2025. Lombard, the largest liquid Bitcoin staking provider on the protocol, processed approximately **$1.26 billion (14,929 BTC)** in unbonding in a single window. Total protocol TVL fell from ~$3.97B to ~$2.67B—a **32% drop** in days, not the smaller fifth-of-TVL move sometimes reported ([BeInCrypto coverage](https://beincrypto.com/babylon-bitcoin-unstaking-event-april-2025/), [Bitget — $1.26B unstaked](https://www.bitget.com/asia/news/detail/12560604708739), [DefiLlama snapshot](https://defillama.com/protocol/babylon-protocol)). The event was operationally clean: the protocol unbonded everything on schedule and Lombard rolled the position into the new finality-provider set without breaking the LBTC peg.
The framing matters. This was a **planned transition timed to the end of Cap 1**, not an emergency stress event. Lombard exited the legacy FP set and re-staked under the new active set introduced for the next staking phase—Cap-1 unbonding was always the design intent, and the size of Lombard's position simply made the transition visible. The relevant lesson is structural rather than incident-driven: a single LST provider held roughly a third of total network security collateral, and any disorderly version of the same flow (smart-contract vulnerability, custodial incident, aggressive run) would have removed that share overnight.
This is the same concentration-risk pattern that played out in the Ethereum LST market with Lido and in the Ethereum LRT market with the Kelp DAO rsETH exploit—the latter of which we covered in detail in [our 2026 DeFi hacks retrospective]({{< relref "knowledge/defi-hacks-2026" >}}). The cross-protocol pattern is consistent: when a single layer of intermediation gets too big, its operational risk becomes systemic risk.
For Babylon specifically, the open design question is whether to introduce protocol-level concentration limits (a hard cap on the percentage of total stake any one LST can represent) or to rely on market dynamics and the entry of additional LST providers (Solv Protocol being the most active example) to dilute concentration over time. The current direction is the second path, but the speed of Solv's growth has been slower than Lombard's was, so the imbalance persists.
{{< callout title="LST concentration is not a Babylon-specific bug" type="warning" >}}
The same dynamic exists on EigenLayer (ether.fi around ~6% of total ETH staking via the eETH/LRT stack as of early 2026), on Ethereum staking (Lido around ~24%, a continuing decline from the ~32% 2023 high), and now on Babylon (Lombard near a third of TVL through the Cap 1/2 transition). The structural fix is unclear: protocol-level caps reduce composability and create UX friction; market-driven dilution requires a competitive LST landscape that does not yet exist. For now, treat single-LST concentration as the default state and model risk accordingly.
{{< /callout >}}
### FP Centralization
A second concentration risk lives at the finality provider layer. Although the protocol currently has 250+ active FPs, delegation is heavily skewed: top-10 FPs control a disproportionate share of total stake, and top-50 FPs control the supermajority. This is the same long-tail distribution that prevails on Ethereum staking, Cosmos chains, and EigenLayer operators, and it has the same cause: capital naturally concentrates at operators with proven uptime, lower commission, and recognizable institutional brands.
The risk is twofold. First, governance is effectively decided by the top FPs—their delegators rarely override their voting position, so any controversial protocol upgrade is effectively a vote among the top-50 operators. Second, an attack scenario that compromises a single top FP (a key compromise, a coordinated bribe, a regulatory order) puts disproportionate stake at risk under a single failure point. The BTC safety slash is only 0.1% of staked principal per FP, so the direct slashing loss even from a coordinated incident across several top FPs stays small—the real damage is governance capture and disruption to finality, not principal destruction.
This is fundamentally a [mechanism design]({{< relref "models/mechanism-design" >}}) problem: the incentive structure rewards FP scale, and there is no countervailing pressure that pushes delegations toward smaller operators. Some BSNs are experimenting with minimum-FP-count requirements for delegations or with delegation caps that prevent any single FP from holding more than a fixed percentage of stake, but neither approach has a clean solution that does not also degrade UX for delegators.
### Cross-BSN Slashing Correlation
The third pitfall is the one that scales with Phase 3 ambition. As multi-BSN expansion lands, a single staker's BTC simultaneously secures multiple chains, and a finality provider running on multiple BSNs collects rewards from all of them. The reward stack is straightforward: more BSNs = more revenue = better unit economics. The risk stack is less obvious.
If two BSNs experience correlated failures—say, both run a forked version of the same Cosmos SDK client and a critical bug surfaces, or both share the same finality provider operator and that operator equivocates—then the delegator's slashing exposure compounds across BSNs. Each BSN can set its own slashing fraction within protocol bounds, but the BTC safety-slash anchor on Babylon Genesis (0.1% of staked principal per equivocation) sets the order of magnitude. Two concurrent safety slashes at 0.1% each leave the delegator with `(1 − 0.001)² ≈ 99.8%` of original principal—a single-event loss of ~0.2%, small enough that the compounding is not the dominant risk.
{{< formula math="Stake_after_n_slashes = Stake × (1 − s_pct)ⁿ" >}}
- Two correlated 0.1% slashes: 1 − (0.999)² ≈ 0.200% loss
- Three: 1 − (0.999)³ ≈ 0.300% loss
- Five: 1 − (0.999)⁵ ≈ 0.499% loss
- Even five correlated safety slashes stay under 0.5% of principal—the compounding is real but quantitatively minor
{{< /formula >}}
The correlation still matters if multi-BSN FP operation is the norm. A top FP running on five BSNs that suffers a global infrastructure failure—a key compromise, a hosting provider outage, a software bug in their monitoring stack—could trigger five concurrent slashing events. That is the correlated-failure scenario at the upper bound of the table above, and it is structurally identical to the Kelp DAO rsETH cascade where a single operator's failure propagated across multiple AVSs. We covered the mechanics in our [2026 DeFi hacks retrospective]({{< relref "knowledge/defi-hacks-2026" >}}); the Babylon variant shares the same structural ingredients, but because the per-BSN BTC slashing fraction is only 0.1%, the multi-BSN tail is a minor drawdown, not a wipeout. The dominant multi-BSN risk is operational disruption and lost rewards, not principal destruction.
The mitigation set is incomplete. Per-BSN slashing caps are the easy part. Cross-BSN correlation limits—caps on the percentage of multi-BSN exposure a single FP or LST can carry—are the harder design problem and not yet on the roadmap.
### Pitfall Summary
| Pitfall | Severity | Mitigation status | Live evidence |
|---|---|---|---|
| LST concentration (Lombard ~⅓ of TVL) | High | Market-driven dilution only; no protocol cap | $1.26B planned unbonding April 2025 (clean Cap-1 transition) |
| FP centralization (top-10 share) | Medium | No active mitigation | Long-tail delegation distribution observed |
| Cross-BSN slashing correlation | Low–Medium (Phase 3) | Not addressed in current roadmap | Pre-launch; 0.1% BTC slash compounds only marginally (<0.5% across 5 BSNs) |
| BSN bootstrap (cold-start FP economics) | Medium | Foundation grants from Ecosystem bucket | BOB, Osmosis, Sui pipelines progressing |
### FP Due Diligence Checklist
If you are delegating BTC to a finality provider—whether directly or through an LST—a basic operational check covers the obvious failure modes:
{{< checklist >}}
Single-LST share of total network stake—is your LST provider above 15% of TVL? If yes, treat as concentrated and consider splitting across providers.
FP track record on uptime—at least 6 months of continuous operation on Babylon Genesis with no slashing events.
FP key management—HSM-backed signing keys with documented rotation policy, not raw hot wallets.
Multi-BSN exposure of your FP—running on more than 3 BSNs concurrently increases correlation risk; check the FP's BSN coverage.
Commission rate—substantially below 5% is suspicious (likely loss-leading, may not be sustainable); above 15% is overpriced for a competitive market.
Slashing reserve disclosure—ask whether the FP holds an operational reserve to absorb slashing without passing loss to delegators; not all FPs publish this, but a clear answer in due diligence is a useful signal.
{{< /checklist >}}
## Advanced: Phase 3 Multi-BSN, Reward Auction, ELIP-12 Parallels
The interesting tokenomics design space is downstream of Phase 3. Multi-BSN expansion turns the protocol from a single-chain Cosmos L1 into a coordination layer where the same BTC collateral simultaneously secures multiple sovereign chains. The mechanism that connects per-BSN economics back to the BABY token is the **BSN reward auction**.
### How the BSN Reward Auction Works
When a BSN onboards, it commits to routing a configurable share of its staking rewards into an on-chain auction held on Babylon Genesis. The auction is denominated in BABY: bidders submit BABY-denominated bids for the right to claim the BSN-token rewards being auctioned, and the winning bid is **permanently burned**. The losing bids are returned. The mechanism is functionally a reverse Dutch auction with deflationary settlement—it converts BSN reward inflation into BABY supply contraction, on a configurable ratio.
{{< formula math="Burn_rate_annual = Σ(BSN_i_rewards × routing_share_i × bid_efficiency_i)" >}}
- BSN_i_rewards—annual rewards routed by BSN i (in BSN-native token, valued at BABY-equivalent)
- routing_share_i—share of BSN i rewards entering the auction (governance-set per BSN)
- bid_efficiency_i—auction realization rate (winning bid / fair value of rewards), typically 0.7–0.95 in functional auctions
{{< /formula >}}
The mechanism does several things simultaneously: it creates BABY demand (bidders need BABY to participate), it reduces BABY supply (winning bids burn), it allows BSNs to monetize reward inflation without forcing direct token sales, and it creates a market-cleared price discovery mechanism for cross-BSN reward streams. The deflationary contribution depends entirely on how many BSNs go live and how aggressively they route rewards into the auction—a parameter that requires governance coordination between Babylon Genesis and each BSN.
The numerical impact is meaningful in a five-BSN scenario. If five BSNs each generate $50M in annual rewards (a conservative number for a mid-size chain with healthy validator economics) and route 25% of those rewards into the auction, the total auction throughput is $62.5M in BABY-denominated bids per year. At a 0.85 bid efficiency, that is approximately $53M in BABY burned annually—roughly equivalent to the inflation pressure from one full year of community-bucket discretionary distributions, depending on BABY's market price.
That number is attractive but speculative. It assumes BSN reward generation at scale (negligible today: Phase 3 multi-staking is in active rollout with the first non-Genesis BSNs onboarding through 2026, but throughput at the modelled level requires several mature BSNs running with native reward economies), high routing shares (governance-dependent, with FP communities likely to push for lower shares), and competitive auction dynamics (which require enough independent bidders to avoid collusion). The mechanism is well-designed but unproven, and its real-world performance will depend on parameters that are not yet finalized.
{{< callout title="Burn auction is a coordination mechanism, not a guaranteed deflator" type="info" >}}
The most common misreading of the burn auction is treating it as a baseline deflationary force comparable to EIP-1559 base-fee burn on Ethereum. It is not. The auction depends on per-BSN governance decisions about routing shares, on BSN reward generation actually happening at scale, and on auction participants showing up with capital. Each of these requires execution. The mechanism is sound; the throughput is contingent.
{{< /callout >}}
### Cross-BSN Coordination and ELIP-12 Parallels
The governance problem Babylon faces in Phase 3 is structurally similar to one EigenLayer addressed with ELIP-12 (the "Incentives Committee" proposal approved March 12, 2026, coordinating AVS-level economic policy across the ecosystem). In both cases, the protocol's value capture depends on per-service decisions (BSN-routing share for Babylon, AVS reward configuration for EigenLayer) that no single entity has authority to set. Coordination requires either a formal council with bounded decision rights or a market mechanism that emerges organically.
Babylon's current direction leans toward market mechanisms: each BSN sets its own routing share, the auction discovers a clearing price, and BSNs that route too little or too much will see consequences in their FP retention and protocol participation. EigenLayer's ELIP-12 direction leans toward coordinated governance: an explicit body that sets reward parameters across the AVS ecosystem.
Neither approach is obviously superior, but the design differences will become observable over the next 12–18 months. If Babylon's market approach works, expect routing shares to converge to a Schelling point in the 20–35% range. If it fails—if a single BSN routes nothing while others route generously—expect governance debate about minimum-routing-share requirements.
### BSN Pipeline (Committed Integrations)
| BSN | Type | Status | Notable design choices |
|---|---|---|---|
| Babylon Genesis | Cosmos SDK L1 | Live since Apr 2025 | First BSN; the control plane itself; native BABY rewards |
| BOB | Bitcoin-native L2 (rollup) | Integration committed | Likely native BTC-pegged reward design; first non-Cosmos BSN |
| Osmosis | Cosmos DEX/L1 | Integration committed | OSMO-denominated rewards; high routing share expected |
| Sui | Move-based L1 | Integration committed | First non-Cosmos, non-EVM BSN; SUI-denominated rewards |
| Future BSNs | Various | Pipeline | Including planned restaking-oriented L2s and AI/DePIN chains |
The diversity of the pipeline is a positive design signal. Babylon is not betting on a single ecosystem (Cosmos), a single VM (Move), or a single use case (DeFi). The downside is that integration complexity scales with diversity—each BSN brings its own client architecture, its own governance, its own native token economy, and its own failure modes. Phase 3's success depends on the protocol being able to manage that complexity without compromising the security guarantees that motivated BTC stakers to participate in the first place.
{{< cta title="We design restaking and BTC-collateral economics for your protocol" text="We've modeled validator economics, slashing structure, and reward routing for L1s, AVS founders, and BSN-aligned chains. We calculate optimal parameters and stress-test multi-chain correlation risk over 5 years." button="Get in touch" link="/quote/" >}}
---
## Bittensor Tokenomics: Yuma, dTAO and the 2025 Halving
- URL: https://giantslabs.pro/models/bittensor-tao-deep-dive/
- Section: models
- Date: 2026-05-15
- Last modified: 2026-05-15
- Description: An integrated technical reference for bittensor tokenomics: Yuma Consensus math, dTAO market-driven emissions, the December 2025 halving, the 41 / 41 / 18 validator/miner/owner split, subnet deregistration, and design lessons for AI-marketplace tokens. With an interactive emission calculator.
**Bittensor tokenomics** is the only decentralized AI-inference marketplace with subnet-level tokenomics to have crossed a halving and a structural emissions shift with multi-year live data on which to test theory. The TAO mainnet has been running since 2021; the protocol has survived two major architectural shifts in the last 18 months—**dTAO** (February 13, 2025) and **Taoflow** (rolled out from November 2025, fully active by December)—and its first **halving** on **December 13, 2025**. Older compute-marketplace tokens like Akash (Sep 2020) and Render (Apr 2020) predate it, but neither has subnet-token architecture comparable to dTAO. The newer AI-agent-marketplace peers—Virtuals and ai16z (both late 2024), plus Bittensor's various imitators—are all younger than 18 months. Olas dates to 2021 but only pivoted into AI-agent infrastructure recently. None of them has crossed a halving, dealt with subnet liquidity asymmetry at scale, or been audited by independent on-chain research after a structural emissions shift.
That makes Bittensor the only public benchmark a serious AI-marketplace designer can study. This piece is an integrated technical reference: the architecture, the math behind **Yuma Consensus**, the mechanics of **dTAO** and **Taoflow**, the **41 / 41 / 18 emission split**, the **subnet deregistration** rule introduced in September 2025, what the first five months of post-halving data show, and the design lessons that hold (and don't) for a founder building an AI-marketplace token in 2026.
For broader context on where Bittensor sits inside the AI-tokenomics landscape, see [AI Agent Tokenomics]({{< relref "knowledge/ai-agents-tokenomics" >}}); this article goes deeper into the protocol itself.
## Architecture: root, subnets, miners, validators, nominators
Bittensor is structured around a **root chain** (Subtensor) and up to **128 subnets**. Each subnet is an independent AI task—text generation, image embedding, time-series forecasting, financial signal extraction—with its own miners, validators, and (since dTAO) its own **alpha token**.
{{< schema "mechanism/bittensor-architecture" >}}
*Bittensor architecture: root, subnets and role split.*
Five roles share the protocol:
- **Miners** produce the AI commodity for a given subnet (an inference, an embedding, a prediction). They get paid by validators that consider their output good.
- **Validators** evaluate miner output and publish a weight vector—a score per miner—every epoch (360 blocks, ~72 minutes). Validators must hold enough TAO stake to qualify.
- **Subnet owners** define the validation task, run incentive code, and receive 18% of subnet emissions.
- **Nominators (delegators)** stake TAO with a validator without running infrastructure themselves; they earn a pro-rata share of that validator's reward stream minus the validator's commission.
- **Root subnet (Subnet 0)** is a special subnet without its own alpha token. Stake in the root subnet influences subnet-level weights and, before dTAO, was the sole mechanism for allocating emissions across subnets.
The economic primitive is straightforward: stake gates participation; validators score miners; the score determines emission shares; everyone gets paid in TAO (and, post-dTAO, in subnet alpha tokens).
{{< callout title="Key fact" type="info" >}}
The validator's job is not to produce work—it is to score other people's work consistently. This makes validator quality the single most important variable in subnet output, and explains why **weight copying** (one validator just cloning another's vector) is the protocol's most documented failure mode.
{{< /callout >}}
## Yuma Consensus, emission split, and halving trigger
Three numerical mechanisms govern TAO supply and reward distribution.
**Block emission.** The chain mints **1 TAO per block** before the halving and **0.5 TAO per block** after; one block lands every ~12 seconds, so daily emission was **7,200 TAO** before December 13, 2025, and is **3,600 TAO** today. Maximum supply is capped at **21 million TAO**, mirroring Bitcoin.
**Block split.** Every minted block is divided across the three productive roles in a subnet:
{{< formula math="E_block = 0.41 · E + 0.41 · E + 0.18 · E" >}}
- E — block reward (1 TAO pre-halving, 0.5 TAO post-halving)
- 0.41 · E — miners' share of the block, split across miners by Yuma-weighted rank
- 0.41 · E — validators' share, split across validators by stake share inside the subnet
- 0.18 · E — paid to the subnet owner
{{< /formula >}}
**Halving trigger.** Unlike Bitcoin, Bittensor halves on **emission count**, not block height. The first halving fired when cumulative issuance reached **10.5 million TAO**, exactly half of max supply. The protocol then drops the block reward by 50%. Because some emitted TAO is **recycled** (returned to the protocol via burns, slashing, and unused subnet registration fees), the halving date drifts: more recycling means a later halving, because recycled tokens don't count toward the threshold.
| Annual recycling rate | Days to next halving (from May 2026) | Approximate next halving date |
|---|---:|---|
| 0% (no recycling) | ~1,460 | May 2030 |
| 5% | ~1,535 | July 2030 |
| 10% | ~1,620 | October 2030 |
So the often-repeated "every ~4 years" rule is only true under zero recycling. In practice the second halving will slip beyond 2030.
**Yuma Consensus.** This is where Bittensor's design becomes interesting. Validators submit a weight vector—how much each miner deserves of the block emission. To resist a single validator (or a coordinated minority) pushing extreme weights, the protocol computes a **stake-weighted median with clipping**. For each miner j, the consensus weight W̄ⱼ is the highest value w such that validators controlling at least κ of total stake agree the weight should be ≥ w:
{{< formula math="W̄ⱼ = arg max_w ( Σᵢ ∈ V Sᵢ · 𝟙_{Wᵢⱼ ≥ w} ≥ κ )" >}}
- W̄ⱼ — consensus weight assigned to miner j after clipping
- V — set of validators in the subnet
- Sᵢ — normalized stake of validator i (Σᵢ Sᵢ = 1)
- Wᵢⱼ — weight validator i submitted for miner j
- 𝟙_{·} — indicator function (1 if condition holds, 0 otherwise)
- κ — consensus threshold (default 0.51)
{{< /formula >}}
After the consensus weight is computed, each validator's individual weight Wᵢⱼ is **clipped down** to W̄ⱼ: weights above the consensus are removed and earn nothing for the validator who set them, neither for the miner who received them. The two-sided punishment is intentional—it disincentivizes both over-reporting (collusion to inflate a miner) and accepting inflated weights.
This is the part most third-party summaries skip, and it explains a lot of validator behavior. If you submit weights wildly different from the consensus, you lose emission. If you submit weights identical to other validators, you might be "weight copying" and lose to the **bond-trust mechanism**. The optimal validator strategy is to evaluate independently but converge with the majority of trusted peers—which is hard enough that the [Weight Copier working paper](https://docs.learnbittensor.org/papers/BT_Weight_Copier-29May2024.pdf) (Opentensor, May 2024) treats it as an unsolved free-rider problem.
Python: Yuma weight clipping with 5 validators and 3 miners
```python
import numpy as np
# Validators (rows) submit weights to miners (cols).
# Each row sums to 1 (Bittensor normalizes weights).
W = np.array([
[0.6, 0.3, 0.1], # Validator A
[0.5, 0.4, 0.1], # Validator B
[0.5, 0.4, 0.1], # Validator C (consensus)
[0.4, 0.4, 0.2], # Validator D
[0.9, 0.05, 0.05], # Validator E — outlier, tries to inflate miner 0
])
# Normalized stake share of each validator (sums to 1).
S = np.array([0.30, 0.25, 0.20, 0.15, 0.10])
kappa = 0.51
# For each miner, find the highest weight w such that
# stake supporting (Wij >= w) >= kappa.
def consensus_weights(W, S, kappa):
cons = np.zeros(W.shape[1])
for j in range(W.shape[1]):
candidates = np.sort(W[:, j])[::-1]
for w in candidates:
support = S[W[:, j] >= w].sum()
if support >= kappa:
cons[j] = w
break
return cons
cons = consensus_weights(W, S, kappa)
# Clip each validator's weights at the consensus.
W_clipped = np.minimum(W, cons)
print("Consensus weights:", np.round(cons, 3))
print("Validator E original [0]:", W[4, 0], "→ clipped:", W_clipped[4, 0])
```
For this example consensus weights are roughly [0.5, 0.4, 0.1]. Validator E's attempt to push miner 0 to 0.9 gets clipped to 0.5 (the consensus). Validator E loses the difference; miner 0 receives less than E claimed.
## Subnet economics: alpha tokens, bonding curves, deregistration
Pre-dTAO, every subnet was a pure cost center for TAO holders: it received emission, but the only way to "own" a subnet's success was to validate it. dTAO changed that by giving every subnet its own **alpha token** and its own **constant-product AMM** against TAO.
**How alpha tokens come into existence.** A user stakes TAO into a subnet's reserve pool. The pool maintains the invariant **TAO_reserve · alpha_reserve = k**, the same x·y=k AMM that powers Uniswap V2. The user receives alpha tokens at the current pool price; the more TAO already staked in the subnet, the higher the alpha price climbs. This is a **bonding curve**: there is no order book, the price emerges mechanically from reserve ratios.
{{< formula math="P_α = TAO_reserve / α_reserve" >}}
- P_α — price of one alpha token in TAO
- TAO_reserve — TAO sitting in the subnet's AMM reserve
- α_reserve — alpha tokens in the same reserve
{{< /formula >}}
**Alpha emission.** The chain mints alpha tokens for each subnet at twice the base rate of one alpha per block, allocated between (a) the subnet's alpha reserve, which deepens AMM liquidity, and (b) outstanding rewards for miners, validators, and the subnet owner. Alpha follows the same halving schedule as TAO, which is why the December 2025 halving compressed subnet incentives at exactly the same rate as TAO emission.
**Subnet creation.** Anyone can create a subnet by paying a **lock cost** in TAO (auction-priced; historically in the low hundreds when slots were free, but with the 128 cap saturated since 2025 the cost runs into the **low thousands of TAO**—roughly $1–2M at recent prices). The cost is held by the protocol and refunded—minus emissions the subnet owner already received—if the subnet later deregisters. The proposed 256-slot expansion would compress the lock cost back down.
**Subnet deregistration.** The 128-subnet cap was always a hard constraint, but until [September 17, 2025](https://docs.learnbittensor.org/subnets/subnet-deregistration) there was no eviction mechanism—once full, the chain stopped accepting new subnets. The new rule changes that: when the cap is hit and a new subnet wants to register, the chain identifies the subnet with the **lowest exponential moving average (EMA) of alpha price**, outside its **4-month immunity period**, and deregisters it. On deregistration, all alpha tokens in that subnet swap back to TAO at the final pool ratio and are distributed to alpha holders pro-rata. The subnet owner gets the lock cost back minus the cumulative emissions they have collected.
The rate-limit is at most **one deregistration every two days**. This produces a slow, predictable churn rather than a single cliff. As of May 2026, the chain has been at or near the 128-subnet cap for several months, so the EMA-price filter is the live mechanism deciding which AI tasks the network thinks are worth running.
| Subnet rank by EMA-alpha price (May 2026 snapshot) | Approximate alpha pool TAO | Approximate daily subnet emission |
|---|---:|---:|
| Top decile (most-staked subnets) | 50K–200K TAO | 80–150 TAO/day |
| Median subnet | 5K–15K TAO | 20–40 TAO/day |
| Bottom decile (within immunity / near deregistration) | <2K TAO | <10 TAO/day |
These numbers are illustrative ranges synthesized from live data; for current values check [taostats.io/subnets](https://taostats.io/subnets) directly.
## dTAO migration and Taoflow: why market-driven emissions
The most consequential design choice in Bittensor's last 18 months is the answer to a single question: **who decides which subnets get emission?**
**Legacy (pre-February 2025).** A council of 64 root-subnet validators chose subnet weights directly. They earned reputation, paid for nothing, and faced very little accountability. The pattern that emerged is well known to anyone who has watched DAO governance: collusion, apathy, and informal cartels. A subnet that didn't curry favor with root validators—even if its AI output was strong—couldn't get emission.
**[dTAO](https://www.coingecko.com/learn/top-bittensor-subnets-dtao) (February 13, 2025).** Root-validator allocation was replaced with a market mechanism: each subnet's share of TAO emission became a function of its alpha token's price (relative to TAO) in the AMM. If you believed in a subnet, you staked TAO into its pool, which raised the alpha price, which raised the subnet's emission share. Conversely, unstaking pushed the alpha price down and reduced emission. The signal moved from "what does the root cartel like" to "where is real capital being deployed."
dTAO worked, but it exposed a second-order asymmetry: subnets with deep pools could absorb large amounts of sell pressure without their alpha price moving much, while subnets with thin pools saw their alpha price collapse on the smallest unstake. The result was a **liquidity-rich-get-richer** dynamic: the subnets that got emission first kept it, even when their actual usage stagnated.
{{< schema "mechanism/dtao-amm-mechanics" >}}
*dTAO: TAO ⇄ alpha AMM and emission flow.*
**[Taoflow](https://docs.taostats.io/docs/tao-emission) (rolled out from November 2025).** The protocol replaced **price-based** subnet share with **flow-based** subnet share. Instead of looking at "where is the alpha price highest right now," the chain tracks **net TAO flow** into each subnet (staking inflow minus unstaking outflow) and smooths it with an exponential moving average:
{{< formula math="F_t = (1 - λ) · F_{t-1} + λ · ΔTAO_t" >}}
- F_t — smoothed net flow at block t
- F_{t-1} — smoothed net flow at the previous block
- ΔTAO_t — net TAO flow (staked − unstaked) into the subnet during this block
- λ — smoothing constant (small, on the order of 1e-4 per block, so the EMA window is several days)
{{< /formula >}}
Each subnet's share of the block's TAO emission becomes proportional to its smoothed flow F_t. By December 2025, **100% of TAO emission is allocated by flow**.
Two design properties this fixes:
1. **Scale invariance.** A subnet that grows from a small pool by attracting genuine inflow gets credit, even if its absolute alpha price stays modest. Old large pools no longer dominate by inertia.
2. **Negative-flow penalty.** Subnets with sustained net outflow have F_t fall toward zero, and their emission share collapses to zero. There is no "I have a $10M pool, I deserve emission forever" defense anymore.
The trade-off: flow-based allocation is more game-able through **wash staking** (rapid stake/unstake cycles to fake inflow). The EMA dampens this but doesn't eliminate it; protocol developers have publicly flagged it as an open monitoring problem.
For wider context on why market-driven mechanisms beat governance-driven ones for resource allocation, see [Demand-side tokenomics]({{< relref "models/demand-models" >}}).
## Validator, miner, and nominator economics in numbers
The 41 / 41 / 18 split is the headline; the actual flow of money to a stake-holder is more layered.
**Validators.** A validator's 41% share of block emission is divided across all validators in that subnet by **stake share**. If a validator controls 5% of subnet stake and the subnet captures 2% of total daily emission, that validator's daily TAO income before commission is:
0.41 × 0.05 × 0.02 × 7,200 (or 3,600 post-halving) = ~2.95 TAO/day pre-halving, ~1.48 TAO/day post-halving.
The validator keeps a **commission (take)** of 0–18%, default 18%. The remaining 82%+ is paid to **nominators** (delegators) pro rata to their stake with that validator. So a validator with a 10K TAO self-stake plus 90K TAO from nominators, running on a subnet that captures 2% of emission, post-halving:
- Validator's own emission: 0.10 × 1.48 = 0.148 TAO/day from self-stake
- Plus 18% commission on the 90K nominator stake's emission: 0.18 × 0.90 × 1.48 = 0.240 TAO/day
- Total: ~0.39 TAO/day from this subnet
A validator typically operates across multiple subnets, with stake split. The economics scale linearly with stake share inside each subnet and with how many subnets the validator participates in. The full validator handbook is in the [Bittensor staking docs](https://docs.learnbittensor.org/staking-and-delegation/delegation).
**Miners.** Their 41% share goes through the Yuma weight clipping described above. A miner who ranks high (large W̄ⱼ across many validators) captures a large slice; a miner whose weights got clipped to zero earns nothing for that epoch. The variance is high—miner economics are closer to a tournament than a stake-yield product.
**Subnet owners.** Their 18% is the most predictable: it doesn't depend on stake or Yuma, just on the subnet's emission flow. Combined with the recovered lock cost on deregistration (minus collected emissions), the owner role is engineered as a moderately compensated curator, not a profit center.
**Nominators.** Their economics are the cleanest: stake X TAO with validator V, receive 0.82 × (V's emission share) × (X / V's total stake) per epoch. Post-dTAO advertised yields run **5–30% APY** across root-subnet TAO staking and dynamic-subnet alpha staking—the closest TAO has to a "savings product" once you net out TAO/alpha price volatility and validator commission risk.
## TAO emission and halving simulator
The numbers above hold under a specific set of assumptions: zero recycling, full subnet utilization, no protocol changes. In practice the supply curve drifts. The simulator below lets you tune the inputs and see how cumulative supply, halving timing, and net new tokens per year shift.
TAO Emission and Halving Simulator
Headline outputs
Cumulative TAO supply over time
Annual net new supply (TAO/year, after recycling)
How to read this. The cumulative chart's amber horizontal lines mark halving thresholds (10.5M, 15.75M, 18.375M, ...). Each crossing drops block emission by 50%. The annual chart shows the net new supply that actually counts toward halvings (gross emission minus recycled TAO). Setting recycling to 0% gives the pure Bitcoin-style schedule; 5–10% is closer to observed Bittensor data and shifts halving dates noticeably later.
## Halving aftermath: what 5 months of post-halving data show
The first halving fired on **December 13, 2025**. Five months later, three things stand out in the data.
**Float compression continues.** Roughly 70% of circulating TAO was staked before the halving, mostly with validators and in subnet alpha pools. Post-halving, the percentage hasn't decreased—if anything, slightly more TAO is locked, because reduced inflation makes existing stake more valuable relative to outside-the-network alternatives. Effective tradeable float is in the low single millions of TAO.
**Subnet incentives compressed in sync.** Because alpha emission halves on the same schedule as TAO, the entire subnet incentive layer dropped by 50% overnight. There was no observable mass exodus of miners from subnets in January–February 2026, but the **bar for being a profitable miner rose**: hardware costs that broke even at 7,200 TAO/day total emission now require ~2× the rank inside a subnet to break even at 3,600. This is consistent with the [Pine Analytics bear case](https://pineanalytics.substack.com/p/the-bear-case-for-bittensor-tao) framing that the long-term miner equilibrium thins out.
**Institutional layer formed.** Two weeks after the halving, on **December 30, 2025**, Grayscale filed an **S-1** for a Bittensor trust. The filing is the first time a US-regulated institutional vehicle has taken TAO seriously as a single-asset product, and it changes the demand side of the equation. Pre-halving Grayscale produced a [research piece](https://research.grayscale.com/reports/bittensor-on-the-eve-of-the-first-halving) framing the supply shock; the S-1 was the next step. It is the most significant non-protocol news of the post-halving period.
These three facts—tightening float, compressing miner economics, institutional demand entry—are the live experiment a designer in 2026 has access to. None of them was a sure prediction in early 2025.
{{< callout title="Caveat on post-halving data" type="warning" >}}
Five months is short. The Bitcoin literature shows that the meaningful price and miner-equilibrium effects of a halving play out over 12-24 months as cumulative reduced issuance compounds. Treat the May 2026 snapshot as directional, not conclusive.
{{< /callout >}}
## Pitfalls: concentration, weight copying, sybil, halving cliff
The academic record on Bittensor is not uniformly flattering. The most-cited recent paper is [Lui & Sun, "Bittensor Protocol: The Bitcoin in Decentralized AI? A Critical and Empirical Analysis"](https://arxiv.org/html/2507.02951v1) (FLock.io, June 2025). Working with on-chain data across all 64 active subnets at the time, they document four problems a designer should reckon with.
**1. Stake concentration drives rewards more than quality.** Lui and Sun show that the correlation between a miner's reward and their stake-adjusted rank is much stronger than the correlation between reward and any quality proxy. The 41% miner share is technically distributed by Yuma weights, but the validator weighting itself follows stake, so a miner aligned with high-stake validators outperforms a higher-quality miner aligned with low-stake validators. The fix they propose—**performance-weighted emission split, composite scoring, trust-bonus multiplier**—has not been adopted in protocol.
**2. Weight copying as a sustained free-rider problem.** The Opentensor [Weight Copier paper](https://docs.learnbittensor.org/papers/BT_Weight_Copier-29May2024.pdf) formalizes the issue: validators who simply copy the consensus weight vector earn the same emission as validators who do real evaluation work, but spend nothing on inference. The protocol's defense is the **bond-trust mechanism** (validators bond to specific miners over time; bond holders earn extra), but it's a partial fix—copiers still capture a meaningful slice of the validator pool.
**3. Sybil pressure on subnet registration.** Subnet registration costs (lock cost) discourage casual creation, but the marginal cost of an additional miner identity inside an existing subnet is low. A coordinated actor can run multiple miner identities, split the work, and capture a disproportionate slice of Yuma-weighted rewards. This is the same dynamic that breaks naive airdrop designs; for the formal game-theoretic treatment see [Mechanism design]({{< relref "models/mechanism-design" >}}).
**4. Halving cliff for marginal subnets.** Most subnets aren't profitable at the median—they survive on the thin slice of emission above their operating cost. When TAO + alpha emission halves overnight, the marginal subnet's operating margin disappears. The deregistration mechanism then accelerates churn at the bottom, which is design-intended but worth flagging: founders launching a subnet in 2026 are entering a much more constrained reward environment than founders in 2024 did.
A fifth pitfall sits at the dTAO layer specifically.
**5. Liquidity asymmetry in dTAO AMMs.** Constant-product AMMs are price-sensitive to trade size relative to pool depth. A subnet with a 5K TAO pool sees its alpha price move 10% on a 250 TAO unstake; a subnet with a 100K pool sees the same trade move price by 0.25%. Before Taoflow, this meant small subnets were structurally disadvantaged on emission share. After Taoflow, it means small subnets are more vulnerable to price manipulation by anyone willing to spend a few hundred TAO to suppress an alpha price.
For a methodological treatment of how to stress-test designs against these failure modes, see [Agent-based modeling]({{< relref "models/agent-based-modeling" >}}).
## Design lessons for AI-marketplace token founders
Bittensor is not a template to copy. But it has run long enough that a handful of design choices have proven themselves robust, and a few have proven themselves problematic. A short list, in order of confidence:
**Lessons that hold:**
1. **Stake-weighted ranking with clipping protects against minority pumping but requires a concentration counter-mechanic.** Yuma's clip-to-consensus rule works—pure pumping is expensive. The miss is on the supply side of validator stake: nothing in Yuma prevents a small set of validators from holding most of the stake and quietly converging on the same weight vector. Performance-weighted emission (Lui & Sun's proposal) is one fix; capped voting power per validator is another.
2. **Market-driven emission allocation outperforms governance-driven allocation when liquidity is sufficient.** dTAO solved the cartel problem; Taoflow solved dTAO's price-bias problem. The combined design—stake to vote, but vote with persistent flow, not snapshot price—is the most defensible piece of Bittensor's architecture and the most copyable.
3. **Subnet deregistration via EMA-price with an immunity period is a clean lifecycle primitive.** Hard caps create churn cliffs; immunity periods prevent registration-griefing; EMA-based ranking ignores transient pumps. This pattern travels well to any protocol with a bounded slot count.
4. **Hardcoded halving by emission count (not block height) is more flexible than Bitcoin's version.** Recycled tokens delay halving; this means treasury operations (burns, slashing) can be used to lengthen the supply ramp without forking. It's a strict superset of Bitcoin's design.
**Lessons that don't hold (and what to do instead):**
5. **Don't depend on a root subnet for governance.** Bittensor inherited this from its 2021 launch and has been trying to reduce root-subnet influence ever since. New AI-marketplace designs should bake market allocation in from day one, not retrofit it.
6. **Don't underprice subnet creation when the cap is loose.** Early-Bittensor subnet lock costs were low; the lattice of low-value subnets that resulted is now being cleaned up via deregistration. A higher floor, refunded only on graceful exit, would have produced fewer ghost subnets.
7. **Don't let validator copying go undefended.** The bond-trust patch helps but doesn't solve it. New designs should consider commit-reveal weight schemes or randomized validator subsets per epoch.
{{< checklist title="Pre-launch design review for AI-marketplace tokens" type="check" >}}
Validator stake is capped per identity, or rewards are de-emphasized for top-stake validators
Subnet allocation mechanism uses persistent flow (or equivalent), not snapshot price or governance vote
Subnet lifecycle includes immunity period + objective deregistration criterion
Halving rule is keyed to cumulative emission, not block height
Weight aggregation includes commit-reveal or randomized validator subsets to deter copying
Sybil pressure on miner identities is addressed via collateral, not just registration cost
AMM pool depth requirements per subnet are set so manipulation cost > expected attacker payoff
Performance-weighted bonus to validators (beyond pure stake) to break the quality-stake decoupling
{{< /checklist >}}
For the broader framing—what AI-tokenomics archetypes exist and where Bittensor sits among them—see [AI Agent Tokenomics]({{< relref "knowledge/ai-agents-tokenomics" >}}).
{{< cta title="Designing an AI-marketplace token?" text="We do formal reviews of AI-tokenomics designs against the eight pre-launch checks above—concentration risk, allocation mechanism, sybil pressure, halving timing. Two-week turnaround." button="Talk to us" link="/contact" >}}
---
## Bonding Curve: A Token Supply Model
- URL: https://giantslabs.pro/models/bonding-curve/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: What is a bonding curve, minting formulas, curve types, DeFi and loyalty program examples. How to choose parameters A, B, C.
## What Is a Bonding Curve
A **bonding curve** is a mathematical function that dynamically sets the token price based on its cumulative supply. The more tokens minted, the higher the price of the next one.
The key principle is simple: **the earlier you buy, the cheaper it is**. Early participants get tokens at a lower price, creating a natural incentive for early project participation.
Unlike traditional models (fixed price, auction, exchange listing), a bonding curve directly links supply and demand without intermediaries: the smart contract automatically mints tokens on purchase and can burn them on sale.
{{< callout title="Why this matters" >}}
A bonding curve is considered **one of the most transparent pricing models** from the buyer's perspective: price is determined by an algorithm, not team decisions. Every participant can see the minting price before and after them. Note: transparency does not eliminate all risks — front-running by bots and whale manipulation remain concerns.
{{< /callout >}}
## Bonding Curve Among Supply Models
Token supply models answer: **how and for what do stakeholders receive tokens**. The four main models:
| Model | Logic | Example |
|-------|-------|---------|
| **Bonding Curve** | Minting by formula P = f(supply) — price rises with supply | pump.fun, friend.tech |
| **Airdrop** | Distribution for targeted actions | Uniswap, Optimism |
| **Reward** | Compensation for work (P2E, PoW, PoS) | Bitcoin, Helium |
| **DEX / CEX** | Purchase through liquidity pool or order book | Uniswap V2, Bybit |
{{< callout type="info" title="Vesting is not a supply model" >}}
Vesting is a mechanism controlling the unlock speed of already allocated tokens. It combines with any model (airdrop + vesting, reward + vesting) but is not a standalone supply model. More in [5 Token Supply Models]({{< relref "models/token-supply-models" >}}).
{{< /callout >}}
The key difference: bonding curve emission dynamically adapts to real demand. Whether 1,000 or 100,000 users arrive — the allocation differs, and each token's price reflects the current number of participants.
## The Math: Minting Formula
The base bonding curve formula defines the **minting price of the next token** as a function of cumulative supply:
{{< formula math="P(T) = A + B × T^C" >}}
- P — minting price
- T — total minted tokens
- A, B, C — curve coefficients
{{< /formula >}}
### What the Parameters Mean
- **A** — starting (minimum) token price. Even at zero supply, price is not zero.
- **B** — scale coefficient. Determines how fast price grows as supply increases.
- **C** — exponent (curve steepness). At C=1 growth is linear, C=2 quadratic, C=0.5 square root.
{{< callout type="warning" title="Example" >}}
With formula `P = 0.10 + 0.00000001 × T^1.5`, the first token costs $0.10. After 10,000 tokens minted, price rises to $0.11; at 50,000 — to $0.21. Choosing the right parameters is the tokenomist's core task.
{{< /callout >}}
### Weighted Average Price
When using bonding curves in payment systems (loyalty, payments), a **weighted average historical price** is often used:
{{< formula math="Pp(T) = A + (B × T^C) / (C + 1)" >}}
- Pp — weighted average price (pool price)
- Insensitive to momentary demand spikes
- Simplifies frontend calculations
{{< /formula >}}
## Curve Types
| Type | Formula | Property | Use case |
|------|---------|----------|----------|
| **Linear** | P = A + B·T | Uniform growth | Simple models, loyalty |
| **Polynomial** | P = A + B·T^C | Accelerating (C>1) or decelerating (C<1) growth | Standard for token sale |
| **Exponential** | P = A·e^(B·T) | Aggressive growth | Scarce assets, NFT |
| **Logarithmic** | P = A + B·ln(T) | Fast start, stabilization | Mass products |
| **Constant product** | x · y = k (with virtual reserves) | Hyperbolic price growth | pump.fun (Solana) |
**pump.fun** on Solana uses a constant product formula (x·y=k) with virtual reserves — mathematically the same model as Uniswap. When the curve reaches a threshold, liquidity automatically migrates to PumpSwap (pump.fun's own AMM, launched March 2025, replacing the former Raydium migration), and the market takes over pricing.
## Applications
### Token Launch / Fundraising
Bonding curves are used for fair token distribution at an early project stage. Investors mint tokens by formula — early participants get a better price without privileged rounds.
Example: pre-selling 5% of tokens to investors via bonding curve with a starting price of $0.10 and target price of $0.25 after 6 months.
### DeFi and AMMs
AMMs like Uniswap use a variation of bonding curves for pricing: the `x · y = k` formula defines the curve along which price changes with each trade.
### Loyalty Programs (Conceptual)
One of the most promising conceptual use cases — **Bonding Curve Loyalty**: cashback in tokens for e-commerce. Note: no production deployments exist yet; this is a proposed model.
1. Buyer pays in USDC (Shopify, Stripe, Coinbase Commerce)
2. A portion of the amount goes to the bonding curve contract
3. The smart contract mints tokens at the current curve price
4. Tokens can be spent on discounts or sold back (burn)
{{< formula math="ΔT = Sc × kt / Pm(T)" >}}
- ΔT — number of tokens minted
- Sc — cashback amount
- kt — percentage in tokens
- Pm — minting price at current supply T
{{< /formula >}}
## Advantages and Limitations
### Advantages
{{< checklist type="check" >}}
Transparency — price is set by an algorithm, anyone can verify
Continuous liquidity — the token can be purchased at any time
Early participant reward — rewards early participation without privileges
Price-demand link — emission adapts to the number of participants
Autonomy — works without a market maker or intermediary
{{< /checklist >}}
### Limitations
- **Implementation complexity** — requires a well-crafted smart contract
- **No price discovery** — price is algorithmic, not market-driven
- **Burn liquidity** — treasury must be funded
- **DEX divergence** — after listing, price may differ from the curve
{{< callout title="Key takeaway" >}}
A bonding curve is a **pre-sale and minting** model, not a final market. Most projects use the curve in the early stage, then transition to a DEX liquidity pool.
{{< /callout >}}
## Practical Parameter Selection
The tokenomist's task — fit A, B, and C to business constraints:
```
Conditions:
- Starting price: $0.10
- After 3 months: $0.20 – $0.40
- After 12 months: $0.60 – $1.00
Inputs:
- Users: 1,000 → growing 500-2,000/month
- Average ticket: $100-$130
- Cashback: 5-10%
```
Approach:
1. Forecast cumulative volume through the bonding curve by month
2. Substitute into the formula and solve the system of inequalities
3. Test parameters interactively, visualize in Desmos
4. Stress-test: what if users are 2x more/fewer?
## Real-World Examples
### DeFi Lending Protocol: Bonding Curve with α-Parameter
A DeFi lending protocol uses a different bonding curve form with an α-parameter:
{{< formula math="P_mint = P_0 × T^α" >}}
- P₀ — base price (1 USDT)
- T — cumulative minted tokens
- α — curve steepness parameter
{{< /formula >}}
Cost of minting N new tokens (integral formula):
{{< formula math="Cost(ΔT, T_0) = P_0/(α+1) × [(T_0+ΔT)^(α+1) − T_0^(α+1)]" >}}
- ΔT — number of tokens being purchased
- T₀ — current supply
- Exponential growth: first token = 1 USDT, thousandth = 25 USDT
{{< /formula >}}
### pump.fun (Solana)
Constant product bonding curve with virtual reserves (x·y=k). Tokens are minted along the curve, price determined by reserve ratios. Upon reaching a threshold, liquidity automatically migrates to PumpSwap (proprietary AMM, which replaced the former Raydium migration in March 2025). The leading platform for memecoin launches since 2024, though competitors (LetsBonk.fun, Believe.app) briefly challenged its dominance in mid-2025.
### Other Bonding Curve Platforms
| Platform | Chain | Model | Notable feature |
|----------|-------|-------|-----------------|
| **friend.tech** | Base (2023) | P = (n²)/16000 | Social tokens — buy/sell "keys" to access creators |
| **LetsBonk.fun** | Solana (2025) | Constant product | Briefly surpassed pump.fun (~56% market share, Aug 2025) |
| **Believe.app** | Solana (2025) | Constant product | Tweet-to-token launches, 190K+ traders |
| **Zora** | Ethereum/Base | ERC-20z curve | Evolved from NFT platform to creator coins via bonding curve (2024–2025) |
### Bancor / Continuous Token Model
One of the first bonding curve implementations on blockchain (2017). Bancor pioneered the continuous token model: tokens are minted and burned automatically through a reserve pool with a set reserve ratio.
---
## Related Articles
- [5 Token Supply Models]({{< relref "models/token-supply-models" >}}) — overview of all supply models including vesting, airdrop, and reward
{{< cta title="Need a bonding curve for your project?" text="We'll select curve parameters, build a Google Sheets model with simulations, and prepare a spec for developers." button="Get in touch" link="/quote/" >}}
---
## Buyback Engineering: A Working Playbook for Fee-Funded Token Programs
- URL: https://giantslabs.pro/models/buyback-engineering/
- Section: models
- Date: 2026-05-11
- Last modified: 2026-05-11
- Description: A working playbook on buyback engineering for fee-funded token programs: the five design axes, contract-level audit checklist, execution-strategy choice (TWAP, continuous, batch, Dutch auction), and lessons from Hyperliquid, Jupiter, and Jito.
The fee-funded buyback became the reference tokenomics pattern of 2024–2026, and *buyback engineering*—the contract-level discipline of building and operating these programs—is no longer optional knowledge for founders, smart-contract engineers, or auditors. Hyperliquid's Assistance Fund holds HYPE with a current market value on the order of $1.3 billion as of early May 2026 (cumulative USD spent, reported in the $890M–$1B range at that snapshot per [DL News](https://www.dlnews.com/articles/defi/hyperliquid-hype-token-buyback-1bn-but-is-it-sustainable/), has since passed $1.1B as of mid-2026) — and as of the December 2025 validator vote, the AF balance is treated as permanently burned by binding social consensus. Jupiter committed half of its protocol fees to buying back JUP, with the purchased supply locked in reserve for three years; the program was paused / under governance review in January 2026 after JUP fell ~89% from peak and roughly $70M was spent over 2025 ([DWF Labs research](https://www.dwf-labs.com/research/547-token-buybacks-in-web3)). Jito ran a $1M TWAP buyback over ten days in four phases as the pilot in Aug–Sep 2025, then activated an automated successor via the Cryptoeconomics SubDAO (JIP-24 / JIP-26) in October 2025; the CSD has since deployed $2.5M+ in continuous buybacks committing 100% of Jito Network revenue ([The Block](https://www.theblock.co/post/345053/jito-foundation-reinvest-jto-year-of-rapid-growth-potential-token-buyback)). Each of these is a different engineering object even though the marketing language sounds identical.
Investor coverage of these programs is now saturated—dashboards, weekly burn-rate posts, sustainability takes. Buyback engineering coverage is not. What actually goes into the contract? Where does the routing fail? What does an auditor look for? When does TWAP beat continuous? Why are priority-fee Dutch auctions a separate deflationary primitive, not a feature?
This playbook treats fee-funded buyback as an engineering surface with five design axes—fee source, routing path, fund ownership, execution strategy, and sink—and walks through each axis with the three live programs as reference implementations. For HYPE-specific allocation, the Assistance Fund's daily math, and the five-archetype map, see the [HYPE tokenomics article]({{< relref "models/hype-tokenomics" >}}). For the underlying choice between dividends and buyback as utilization mechanisms, see [utility models]({{< relref "models/utility-models" >}}). This article focuses on what comes after that choice—how to do the buyback engineering work itself.
## The Engineering Surface of a Fee-Funded Buyback
Every fee-funded buyback program can be decomposed along five independent design axes. Two programs that share a tagline ("we buy back tokens with revenue") can land on completely different points along each axis, and the resulting contracts and operational surfaces look nothing alike. Naming the axes makes the rest of the article navigable.
**Axis 1—fee source.** What revenue stream funds the buyback? Trading fees (HYPE perp, JUP swap aggregation), MEV revenue (JTO), lending interest (Aave proposals), priority-fee auctions (a new primitive examined below). The source determines the volatility of buyback flow—high-frequency trading fees scale smoothly with volume; auction-based or quarterly fees produce stepped flow.
**Axis 2—routing path.** Where does the fee go before it becomes a buyback? Direct from the fee collector to an on-chain fund (HYPE's near-direct routing), through a treasury that releases tranches (JUP's locked-reserve model), or through a discretionary executor (JTO's phased TWAP). Routing complexity is where most contract bugs and most audit findings live.
**Axis 3—fund ownership.** Who controls the post-buyback tokens? A protocol-owned address that no key holder can withdraw from (the credible-burn-equivalent design), a multisig with bounded withdrawal rules, or a treasury wallet under DAO vote. Fund ownership determines how the market discounts the supply removal—the more discretionary the control, the less the market treats tokens as off the float.
**Axis 4—execution strategy.** How are the open-market buys actually placed? Continuous per-trade execution, TWAP (time-weighted average price) over a window, batched lump purchases, or auction-priced execution. This is the axis where most public dashboards focus, and where MEV exposure differs the most.
**Axis 5—sink.** What happens to the tokens after purchase? Burned to a null address (irreversible supply reduction), accumulated on the fund balance (off-float but not destroyed), or recycled into ecosystem incentives. The sink choice interacts with regulatory framing—burns are simpler in tax narrative; accumulation gives the protocol optionality.
A working buyback contract picks one point on each of these five axes. The combinations are not all equally valid—TWAP execution paired with burn-immediate sink is fine, but discretionary fund ownership paired with continuous execution is internally inconsistent (continuous routing typically presumes structural, not discretionary, governance). The rest of this article zooms in on each axis with the live-program references as anchors.
{{< callout title="Five axes, five contract surfaces" type="info" >}}
A "fee-funded buyback" description that does not specify all five axes is incomplete. When evaluating a proposal—internal design, audit scope, due diligence—ask which point on each axis the design lands on. Most disagreements in buyback design are actually disagreements about which axis a decision belongs to.
{{< /callout >}}
## Three Live Programs: HYPE, JUP, JTO Compared
Three programs are operating at scale with enough public data to compare under the five-axis framework. They cluster differently on each axis, which is exactly the point—the same outcome ("token holders benefit from protocol revenue") can be engineered through structurally different surfaces.
| Axis | Hyperliquid (HYPE) | Jupiter (JUP) | Jito (JTO) |
|---|---|---|---|
| **Fee source** | Perp trading fees, ~97% routed | Aggregator + perp + DAO fees, 50% routed (program paused Jan 2026) | Block-engine fee share (~6% per JIP-24); 100% of Jito Network revenue committed under CSD |
| **Routing path** | Near-direct to Assistance Fund (L1-level enforcement) | Treasury accumulates, deploys to buyback | Cryptoeconomics SubDAO (CSD) via on-chain TWAP / auction infrastructure |
| **Fund ownership** | System address `0xfefe…fefe` (no private key); burn-equivalent by Dec 2025 validator vote | Jupiter Lock smart contract, 3-year time-lock on purchased JUP | CSD-controlled contracts under DAO governance (JIP-24 / JIP-26) |
| **Execution strategy** | Continuous, per-block | Discrete tranches, public schedule | Continuous TWAP + enhanced auction (pilot $1M Aug–Sep 2025 → CSD live Oct 2025) |
| **Sink** | Burn-equivalent (AF balance reclassified as permanently burned by validator vote Dec 2025; on-chain accumulation continues in system address) | Locked in reserve, 3-year unlock per Jupiter Lock vesting policy | Burn / vault per CSD policy |
Sources: HYPE—[Hyperliquid docs](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/fees), [GoPlus Security research, Nov 2025](https://goplussecurity.medium.com/hyperliquid-buyback-burn-and-staking-mechanism-research-report-72e0e1765fd9), and the [December 2025 validator vote](https://www.mexc.com/en-GB/news/343844) (passed 85 / 7 / 8) reclassifying the AF balance; JUP—[DWF Labs research](https://www.dwf-labs.com/research/547-token-buybacks-in-web3) and [Jupiter governance announcements February 2025](https://cryptoslate.com/jupiter-to-buyback-jup-tokens-with-50-of-fees-starting-next-week/) (announce Feb 13, exec Feb 17), with the program paused / under review in January 2026 after ~$70M was spent over 2025; JTO—[The Block, 2025](https://www.theblock.co/post/345053/jito-foundation-reinvest-jto-year-of-rapid-growth-potential-token-buyback) plus the [Jito CSD quarterly update, Oct 2025](https://x.com/jito_sol/status/1980688265251348835) (CSD active, $2.5M+ deployed since launch). All values as of early May 2026 and subject to governance changes.
**HYPE optimizes for structural credibility.** The near-total fee share, the protocol-owned system address, the continuous execution, the on-chain transparency, and the December 2025 validator vote that reclassified the AF balance as permanently burned all push toward a single property—the market cannot price in a "will they pause" or "will they redeploy the fund" option. The trade-off is operational rigidity: there is no policy lever to slow buybacks during a treasury crunch, because the routing is mechanical rather than governed. This works because Hyperliquid's cost structure is small relative to fee flow; it would not work for a project that needs to fund payroll out of fees. The full HYPE design—including the Assistance Fund's daily math, the December 2025 burn-vote context, and its risks—is in the [HYPE tokenomics article]({{< relref "models/hype-tokenomics" >}}).
**JUP optimizes for predictability under DAO governance.** The 50% allocation and the 3-year lock are explicit policy choices subject to revote. The treasury serves as a buffer between fee flow and buyback execution, smoothing operational schedule from fee timing. This is appropriate for a DAO-governed project where governance bandwidth allows policy adjustments. The trade-off — explicit in JUP's case — is that the market does price the option to change allocation in a future vote, which is exactly what happened in January 2026 when the program was paused / put under review after JUP fell ~89% from peak and approximately $70M had been spent through 2025. The DWF Labs ">$100M/yr" projection cited above was pre-pause; the actual 2025 spend underperformed it and the policy itself is now under revision.
**JTO transitioned from pilot to live automation.** The first $1M TWAP buyback in August–September 2025 was a deliberate small-scale test to validate the mechanics. The Cryptoeconomics SubDAO (CSD) was then activated via JIP-24 / JIP-26 in October 2025, deploying $2.5M+ in continuous buybacks since launch using TWAP + enhanced auction infrastructure, with 100% of Jito Network revenue now committed. The market treatment shifted accordingly — from "exploratory pilot" pricing to "live structural program" pricing.
The lesson is not "HYPE is the right design and the others are wrong." Each program is internally coherent on its own five-axis combination, and an imitator should pick the combination that fits its governance and operational constraints, not the one that has the largest headline number.
## Math: Supply Removal and Sustainability
The math of a fee-funded buyback is simple to write down. It is useful to write down anyway, because most "this protocol burns N% per year" claims fall apart when the inputs are made explicit.
{{< formula math="r = (α · f · V) / (P · S)" >}}
- r — annual supply removal rate (fraction of circulating supply removed per year)
- α — fraction of fees routed to the buyback program (0 ≤ α ≤ 1)
- f — effective fee rate
- V — annual fee-generating volume (or annual fee revenue directly, as f·V)
- P — token price
- S — circulating supply
{{< /formula >}}
Four observations follow.
**The rate is sensitive to price in the inverse direction.** A token price rally reduces the fraction of supply removed per dollar of fee flow, because the same dollar buys fewer tokens. Programs that quote a "removal rate" without specifying the assumed price are concealing this dependency.
**Volume shocks compound through the numerator.** A 50% volume drop is a 50% drop in buyback dollars at the same fee rate and allocation. If price also falls in the shock (typical, because both move with macro conditions), the rate can be relatively stable in percentage terms—but absolute token removal still drops.
**The allocation fraction α is the main lever for the protocol.** Price and volume are exogenous; supply is fixed by emission schedule. α is what governance can move. Going from α=0.5 to α=0.9 nearly doubles r at the same inputs, which is why HYPE's near-total allocation produces such different numbers from typical 30–50% exchange-token programs.
**The denominator S is moving.** Most buyback math is reported against current circulating supply. If the project also has scheduled emissions (vesting unlocks, staking rewards), the gross buyback rate overstates net float reduction. The relevant metric for holders is net float change—r_net = r − e, where e is the annual emission rate against the same S. Programs with active emission schedules need to publish r_net, not just r.
For HYPE-specific sensitivity analysis—moving daily volume, fee rate, fund allocation, price, and a volume-shock multiplier in real time—use the interactive [HYPE buyback sustainability calculator]({{< relref "tools/calc-hype-buyback" >}}). To apply the formula to another program, substitute that program's α, f, V, P, S inputs into the same equation; the structure is universal.
## Fee Routing: What Goes in the Contract
The routing path between fee collection and buyback execution is where the most contract complexity—and the most audit findings—live. The high-level architecture is a pipeline, but each stage has design choices that ripple into security posture.
A typical fee-funded routing path:
```text
Trade execution ─────► Fee collected (in trade asset, e.g. USDC)
│
▼
Fee accumulator (per-block or per-window)
│
▼
Routing decision (allocation %)
│
┌─────────────────┴─────────────────┐
▼ ▼
Operations bucket Buyback bucket
(treasury, ecosystem) (fund / executor)
│
▼
Buy execution (DEX / RFQ / OTC)
│
▼
Sink (fund / burn / reserve)
```
Six design points sit inside this pipeline and each is worth deciding explicitly.
**Fee asset normalization.** When fees are collected in a non-target asset—USDC fees, buyback target HYPE—the contract needs a swap step. The swap introduces oracle dependency (for price discovery), slippage exposure, and MEV surface. The defensible pattern—collect fees in the fee-native asset, accumulate to a threshold, swap via a route that has both a slippage cap and a price-band check against an oracle.
**Allocation enforcement.** The fraction α should be encoded as an immutable contract parameter or as a parameter only adjustable through a delay-locked governance proposal. Allocation that a multisig can change without delay is operationally indistinguishable from a discretionary treasury, regardless of marketing.
**Accumulator threshold vs continuous.** Continuous per-trade swapping is operationally simple but gas-expensive and MEV-exposed—every swap is a sandwich target. Accumulating to a threshold (e.g. $50k or per-block batching) reduces both. The threshold becomes an audit parameter—too small and the gas overhead dominates; too large and the program reads as discretionary.
**Buy execution venue.** The contract must specify where the buyback executes—a designated DEX pool, an RFQ counterparty, an aggregator, or an internal book. The choice has price-impact, MEV, and counterparty implications. The defensible pattern is named venues (not "best execution by operator discretion") with a fallback rule for venue unavailability.
**MEV protection.** Open-market buybacks executed transparently are sandwichable. The mitigation toolkit as of 2026 spans five categories: (1) private mempool routing — Flashbots Protect and **MEV Blocker** (CoW DAO / Agnostic Relay, acquired by Consensys January 2026; returns up to ~90% of backrun value to users); (2) batch auctions — CoW Protocol pattern, now mainstream; (3) **intent-based / solver auctions** — CoW Swap, UniswapX, 1inch Fusion, which hit ~$9B monthly volume by mid-2025; (4) commit-reveal scheduling; (5) randomized or jittered timing. Most live programs combine private routing with a solver/batch venue rather than rely on a single mitigation. The savings are material at scale—commonly cited estimates put unmitigated sandwich tax in the order of 10–30 bps per swap on typical pools, though published studies report 5 bps on the deepest pools to 50+ bps on thin or volatile pairs depending on timeframe.
**Accounting reconciliation.** The contract needs an on-chain or off-chain ledger that closes—fees in equals operations bucket plus buyback bucket; buyback bucket equals tokens bought plus residual; tokens bought equals fund balance plus burned. Without reconciliation, drift accumulates silently and the program loses public credibility on month-to-month verification.
The HYPE Assistance Fund is the cleanest live reference for several of these decisions—near-immutable allocation, named venue on HYPE's spot book, on-chain accumulation. The mechanics are documented in detail in the [HYPE tokenomics article]({{< relref "models/hype-tokenomics" >}}). For programs operating across multiple chains or with non-native fee assets, the routing pipeline gets longer and each additional stage is a separate audit object.
## The Assistance Fund Pattern and Its Variants
The "Assistance Fund" term became identified with Hyperliquid's design, but the underlying pattern—a protocol-owned address that receives buyback proceeds—has several variants that differ in important operational ways. Naming the variants helps separate "we have a fund" claims into the ones that change market behavior and the ones that do not.
**Variant 1—structural protocol-owned fund.** The fund address is hardcoded in the routing contract, and withdrawals are either impossible or constrained to specific protocol-defined events (liquidation backstop, insurance payouts). No human key holder can transfer tokens out for unrelated purposes. The HYPE Assistance Fund is the strongest live example—it uses the system address `0xfefefefefefefefefefefefefefefefefefefefe`, which has no private key and cannot be controlled without a hard fork; in December 2025 a validator vote (passed 85 / 7 / 8) reclassified the AF balance as **permanently burned** by binding social consensus, which functionally pushes HYPE from a "Variant 1 structural fund" toward a "Variant 4 burn-equivalent" while preserving the on-chain accumulation footprint. The market now treats fund balance as off-float for all practical purposes.
**Variant 2—multisig-controlled fund with bounded scope.** The fund is held by a multisig with a published policy on allowed uses—often "buyback only, can be redeployed to ecosystem incentives via governance vote with 30-day timelock." This is closer to a constrained treasury than to a structural burn-equivalent. The market discounts fund balance somewhat, depending on the multisig's track record.
**Variant 3—reserve contract with time lock.** Purchased tokens are sent to a contract that releases on a fixed schedule. JUP's 3-year lock is a clean example—the lock substitutes for fund ownership ambiguity. The tokens are visibly inaccessible for the lock period, after which a governance decision applies. The market treats locked tokens as off-float for the lock window and prices in the unlock event.
**Variant 4—burn-equivalent sink (no fund).** Purchased tokens are immediately sent to a null address. There is no fund, no balance to dispute, no withdrawal policy. This is operationally simplest but eliminates protocol optionality—the tokens are gone and cannot be redeployed for insurance, liquidations, or strategic purposes.
The withdrawal-authorization rules are the part most often underspecified. A fund design that says "the Assistance Fund will be used for the protocol's benefit" without enumerating allowed uses, decision thresholds, and timelock parameters is functionally a discretionary treasury with a different name. The Hyperliquid design narrows this by tying withdrawals to insurance events with on-chain triggers, but the formal withdrawal rule set still has room to be made more explicit. For any imitator, this is the place where the spec needs the most language, not the least.
A common error worth naming—building Variant 1 (structural fund) but giving an emergency-multisig override key "just in case." The override key collapses the design back to Variant 2 in market terms, because the override exists and can therefore be priced in. If a structural fund is the intent, the override either does not exist, or it triggers a publicly-visible delay that itself makes the override expensive to use.
## Execution Strategy: TWAP, Continuous, Batch, Dutch Auction
The execution strategy axis—how the buy orders are actually placed against the market—is where the three reference programs differ most visibly. The choice trades off across four properties: implementation complexity, MEV resistance, price predictability, and operational bandwidth.
| Strategy | Complexity | MEV resistance | Price impact | Operational overhead | Best fit |
|---|---|---|---|---|---|
| **Continuous (per-block)** | Low | Low—every swap is a sandwich target | Low per swap, can accumulate | None—mechanical | High-frequency fee inflow, deep liquidity venue (HYPE) |
| **TWAP (windowed)** | Medium | Medium—predictable timing helps and hurts | Smoothed over window | Window scheduling | Discrete tranches, market-impact concerns (JTO) |
| **Batch (treasury-funded tranches)** | Medium | Medium—batch auction protects | Concentrated at batch | High—each batch is a governance event | DAO-governed treasury programs |
| **Dutch auction (priority-fee context)** | High | High—auction protects against frontrun | Set by auction clearing | Off-chain auction infrastructure | Latency-sensitive primitives (Hyperliquid priority fees, Arbitrum Timeboost) |
**Continuous execution** is the HYPE pattern. Fees arrive, swaps execute, the fund balance grows. The operational simplicity is appealing—no scheduling, no discretion, no governance bandwidth required. The cost is permanent MEV exposure—every swap is visible in the mempool and sandwichable. Hyperliquid mitigates this partially by running the swaps inside its own venue rather than on an external DEX, which collapses the sandwich window. A protocol running continuous execution on a public DEX has a harder mitigation problem.
**TWAP execution** is the JTO pattern. A target volume is divided into N tranches, executed at fixed time intervals over a window. TWAP minimizes single-trade price impact and is straightforward to implement. The MEV exposure is medium—predictable timing means searchers can position around expected tranches, but each tranche is smaller and the per-trade sandwich profit is bounded. TWAP fits discrete buyback tranches where market-impact protection matters but real-time execution does not.
**Batch execution** is what JUP-style programs use when they deploy treasury tranches on a publicly-announced schedule. Each batch is an event with associated execution complexity, but predictability allows the team to use batch-auction infrastructure (CoW Protocol, Uniswap X) that bundles the buyback with other flow and protects against sandwich. The trade-off is governance bandwidth—each batch decision typically requires DAO approval.
**Dutch auction execution** is a separate primitive that has become relevant through priority-fee auctions (next section). Rather than placing orders into a continuous market, the protocol auctions the right to fulfill the buyback to bidders in a Dutch (descending-price) auction. The clearing price determines the rate, and MEV is internalized into the auction premium rather than extracted by external searchers. This is the most complex strategy and requires off-chain auction infrastructure, but the MEV resistance is structural rather than mitigative.
The decision tree for a new program is roughly—if fee inflow is continuous and a dedicated venue exists, use continuous; if fees are episodic, use TWAP; if execution requires governance approval per round, use batch with batch-auction infrastructure; if MEV exposure is the dominant cost and infrastructure investment is justified, evaluate Dutch auction.
Applied to JTO's first run—target notional $1M, window 240 hours, 4 phases—the schedule resolves to four orders, $250k each, 60 hours apart:
| Phase | Time offset | Notional | Slippage cap | Mempool |
|---|---|---|---|---|
| 1 | t+0h | $250k | 30 bps | private |
| 2 | t+60h | $250k | 30 bps | private |
| 3 | t+120h | $250k | 30 bps | private |
| 4 | t+180h | $250k | 30 bps | private |
Python: TWAP schedule generator
```python
def schedule_twap_buyback(target_notional_usd, window_hours, phases, venue):
interval = window_hours * 3600 / phases
per_phase = target_notional_usd / phases
schedule = []
for i in range(phases):
schedule.append({
"phase": i + 1,
"execute_at_offset_sec": int(i * interval),
"notional_usd": per_phase,
"venue": venue,
"slippage_cap_bps": 30,
"private_mempool": True,
})
return schedule
# JTO first buyback as anchor
schedule = schedule_twap_buyback(
target_notional_usd=1_000_000,
window_hours=240,
phases=4,
venue="jupiter_aggregator",
)
```
For HYPE-specific volume sensitivity—including how volume shocks change the per-block buyback flow—the [HYPE buyback sustainability calculator]({{< relref "tools/calc-hype-buyback" >}}) lets you move the inputs in real time.
## Priority-Fee Auctions: A New Buyback Source
Priority-fee auctions emerged in 2025–2026 as a distinct deflationary primitive that does not fit the standard fee-funded buyback model. The pattern—users pay a premium for transaction ordering or latency advantage, the premium is auctioned (typically Dutch), and the proceeds are burned or otherwise removed from circulation. The source is not the protocol's product fees but users' willingness to pay for time priority.
**Hyperliquid priority fees (mainnet alpha as of April 2026).** Hyperliquid activated a two-tier priority-fee system—*gossip priority*, where bidders pay in HYPE via a Dutch auction (cycles synced to a 3-minute schedule, minimum 0.1 HYPE bid) to receive earlier visibility of incoming transaction data, and *order priority*, where users pay a fraction of filled notional (currently capped at ~8 bps, converted to HYPE from their undelegated staking balance) to bid ordering within the mempool. Both fee types are burned, making the system deflationary for HYPE supply; the docs do not separately specify the burn destination, but reporting treats both as flowing through the AF system address. Public reporting from [Cryptointegrat](https://www.cryptointegrat.com/p/hyperliquid-launches-priority-fees), the [Hyperliquid docs](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees), and the [Dwellir operator guide](https://www.dwellir.com/blog/hyperliquid-priority-fees) covers the mechanism in detail.
**Arbitrum Timeboost (live since April 2025, dynamic reserve since 27 April 2026).** Timeboost is an off-chain auction that sells "express lane" rights for 60-second windows. Winning bidders get their transactions sequenced ahead of standard flow during their window. The reserve price was static at launch and was switched to a [dynamic reserve calculation](https://forum.arbitrum.foundation/t/announcement-of-dynamic-reserve-price-change/30833) on 27 April 2026—the reserve now adjusts based on recent demand, which means the auction extracts more value when latency is in demand. Auction proceeds flow to the Arbitrum DAO treasury rather than to burn. The mechanism is **functionally analogous** to Hyperliquid's gossip priority—both auction latency advantage and internalize MEV value to the protocol—but the **auction format differs**: Timeboost is a sealed-bid second-price (Vickrey) auction, while Hyperliquid's gossip priority is a Dutch (descending-price) auction. The two formats produce different bidder strategy and price-discovery profiles, even though the high-level revenue mechanism is the same. See the [Arbitrum Timeboost introduction](https://docs.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction) for the protocol-level mechanics.
Why this matters for buyback design—three points.
**The source is orthogonal to trading volume.** Trading fees scale with notional traded; priority-fee auction revenue scales with the demand for latency advantage in the order book. These are correlated but not identical—a market with high notional but low contestation (simple swaps) generates lots of trading fees and little priority-fee revenue. A market with lower notional but heavy MEV-extractable opportunities generates the opposite. A buyback design that relies on both is more diversified than one that relies on trading fees alone.
**The auction internalizes MEV.** Without priority-fee infrastructure, the value of being first in the order book is captured by external searchers via sandwich attacks, latency arbitrage, and frontrunning. The priority-fee auction redirects that value to the protocol, which can then deploy it to buyback or burn. Hyperliquid's choice to burn priority-fee proceeds is a deliberate signal—the protocol prefers permanent supply removal over treasury accumulation for this revenue stream.
**The design choice is burn vs accumulate vs distribute.** Hyperliquid burns. Arbitrum directs to DAO treasury. A future design could distribute to validators (REV-style) or to stakers (slashing-adjacent). Each option produces different token-holder economics and is worth its own engineering analysis. As of early May 2026, the design space is still being explored across the major L1 / L2 / appchain stacks.
For a fee-funded buyback program, priority-fee auctions can serve as a secondary source that smooths the volatility of trading-fee revenue. The implementation surface is significant—an off-chain auction infrastructure, a routing path for auction proceeds, and either an on-chain burn or accumulation step. But the diversification benefit is real, and the primitive itself is new enough that early movers have meaningful design optionality.
{{< callout title="Latency auctions are not just MEV mitigation" type="info" >}}
A priority-fee auction is often introduced as a way to reduce harmful MEV. That framing understates it. Once the auction exists, its proceeds become a new revenue stream that can be programmatically routed to buyback, burn, or distribution. The design choice for that routing is separate from the choice to run the auction in the first place, and protocols that frame it only as MEV mitigation miss the second-order decision.
{{< /callout >}}
## Audit Checklist for Buyback Contracts
Existing buyback audit content—[Mitosis University's disclosures checklist](https://university.mitosis.org/token-buyback-burn-disclosures/) is the closest reference—tends to focus on what protocols should *disclose*. The audit checklist below is for the contract surface itself, the code and configuration an auditor reads when reviewing a buyback program. It assumes the disclosure layer is separate work.
{{< checklist title="Buyback contract audit checklist" type="check" >}}
Fee accounting drift. Verify on-chain that sum(fees collected) equals sum(operations bucket) plus sum(buyback bucket) over any window. Drift is a silent revenue leak. Reconciliation must be on-chain or computed from on-chain events; verbal reports are not auditable.
Allocation parameter mutability. Confirm how α (allocation fraction) can change—immutable, timelock-governed, or multisig-instant—each is a different security posture. An instant-mutable α with marketing language "we will maintain ~95% allocation" is operationally a discretionary treasury.
Slippage cap and oracle dependency on the swap step. If fees are collected in a non-target asset, the swap must have a slippage cap AND an oracle price-band check. Either alone is insufficient—a slippage cap without an oracle can be hit on a manipulated pool; an oracle without a slippage cap can stall when the oracle is stale.
MEV protection on open-market buys. Verify private mempool routing, batch auction, or commit-reveal. "We accept some sandwich exposure" is acceptable only if quantified and disclosed; unbounded sandwich exposure on a high-frequency program is a material finding.
Fund withdrawal authorization rules. Read the contract for who can move tokens out of the fund and under what conditions. Compare against the program's disclosed policy. Mismatches between contract code and policy language are the highest-severity finding category.
Emergency override scope. If an emergency multisig has override capability, verify what actions it can take, what delay or notice is required, and what proves the emergency. An undelayed override on a fund collapses the structural-fund market premium regardless of intended use.
Reentrancy in routing. The routing pipeline often involves external calls (DEX swap, oracle query, accumulator update). Reentrancy guards on the routing entry point are non-optional. Verify that re-entry between fee collection and swap cannot drain.
Upgradability scope on the routing contract. If the contract is upgradable, document who controls upgrades, what timelock applies, and whether upgrades can change the allocation, the fund address, or the buy venue. An upgradable routing contract is functionally a discretionary program regardless of current parameters.
Burn vs accumulate clarity. The sink choice must be explicit in code—either a transfer to a null address (burn) or to a fund address (accumulate). Audits frequently catch ambiguity where the "burn address" is in fact a multisig-controlled wallet.
Priority-fee revenue routing (if applicable). For programs incorporating priority-fee auction proceeds, verify the routing path is separate from trading-fee routing and that the sink decision (burn / accumulate / distribute) is explicit and immutable or timelock-bound.
{{< /checklist >}}
The checklist is not exhaustive—each program has specific surfaces (cross-chain bridging, multi-asset normalization, governance integration) that add items. But the ten above cover the failure modes that recur across HYPE-style, JUP-style, and JTO-style programs.
The next step for a real program is sequencing—pick the five axes, write the routing contract against the chosen variants, instrument the fee accounting on-chain, run the buyback once at small scale to verify reconciliation, and only then scale the allocation toward the target α. Building backward from a public launch number is how most programs end up with the wrong sink and a multisig override they cannot justify.
{{< cta title="Designing or auditing a fee-funded buyback?" text="We engineer the routing contract, calibrate the execution strategy, and run the contract-level audit checklist before launch." button="Get in touch" link="/quote/" >}}
---
## DePIN Tokenomics: Decentralized Infrastructure Economics
- URL: https://giantslabs.pro/models/depin-tokenomics/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: DePIN tokenomics: Burn-and-Mint Equilibrium, incentive flywheel, and node unit economics. Filecoin, Helium, Render, and Hivemapper analysis with formulas.
DePIN (Decentralized Physical Infrastructure Networks) are networks where participants provide physical infrastructure (storage, compute, connectivity, sensors) and earn tokens in return. DePIN economics is built on substituting capital expenditure: instead of a company investing billions in servers or cell towers, the network incentivizes thousands of independent operators to do it themselves.
## Why DePIN Is a Separate Model
DePIN differs from standard tokens because the token services a **real physical economy**: operators buy equipment, pay electricity bills, and handle maintenance. This creates hard economic constraints absent from purely digital protocols.
Three key differences:
1. **Capital expenditure on the operator's side.** The operator purchases a GPU, hard drive, hotspot, or camera before earning their first token. Tokenomics must ensure these investments pay off
2. **Tied to the physical world.** Service quality depends on geography, hardware, and uptime — parameters that can't be faked as easily as on-chain metrics
3. **Two-sided market.** The network must simultaneously attract operators (supply) and users (demand), solving the cold start problem
{{< callout title="Sector scale" >}}
As of mid-2026, DePIN market capitalization is roughly $6–19B depending on methodology and the token count tracked. The sector includes data storage (Filecoin), compute (Render, Akash), wireless connectivity (Helium), mapping (Hivemapper), and sensor networks (DIMO, WeatherXM).
{{< /callout >}}
## Core Model: Burn-and-Mint Equilibrium
Most mature DePIN projects use the Burn-and-Mint Equilibrium (BME) model, first pioneered by Factom, formalized by Multicoin Capital (2018), and popularized through Helium's implementation.
### BME Mechanics
1. **User** buys the token and **burns** it to pay for the service (storage, compute, data transfer)
2. **Operator** provides the service and receives **newly minted tokens** from emissions as a reward
3. Equilibrium is reached when the burn rate equals the emission rate
{{< formula math="Equilibrium: Burn_epoch = Emission_epoch" >}}
- When Burn > Emission → deflation, price rises
- When Burn < Emission → inflation, price falls
- Equilibrium is the long-term stability point
{{< /formula >}}
### BME Advantages
- **Decouples token price from user cost.** The user pays for the service in fiat equivalent — the number of tokens burned is recalculated at the current rate. This eliminates service cost volatility
- **Transparent demand.** Burn is an on-chain metric showing real consumption
- **Deflationary potential.** When consumption grows, burn outpaces emission
## The DePIN Flywheel: The Cold Start Problem
DePIN networks face the classic two-sided market problem: operators come when there's demand, and users come when there's coverage. Tokenomics solves this through **subsidizing early operators**.
### Flywheel Phases
**Phase 1: Subsidies (cold start).** The protocol emits tokens to operators beyond actual demand. Operators receive rewards in advance, before users arrive. This is the protocol's capital expenditure on building the network.
**Phase 2: Growth.** As coverage expands, users arrive → burn grows → subsidy emissions decrease. Operators earn revenue from real users + declining subsidies.
**Phase 3: Equilibrium.** Burn approaches emission. Subsidies are minimal. Operators earn primarily from user fees. Tokenomics is sustainable without inflationary pressure.
{{< formula math="Operator_reward = Subsidy(t) + Fee_share" >}}
- Subsidy(t) — a decreasing function, often on a halving schedule
- Fee_share — revenue from real users
- In early stages: Subsidy >> Fee_share
- At equilibrium: Subsidy → 0, Fee_share is the primary income
{{< /formula >}}
{{< callout type="warning" title="The subsidy trap" >}}
If real demand doesn't materialize while subsidies deplete on schedule, operators leave → coverage drops → chances of attracting users decline → death spiral. This is exactly what happened to Helium in the IoT coverage segment before its pivot to mobile connectivity.
{{< /callout >}}
## Node Unit Economics
The key DePIN metric is node payback. If an operator can't recoup their investment, the network won't grow.
### Payback Formula
{{< formula math="Payback = CAPEX / (Revenue_mo − OPEX_mo)" >}}
- CAPEX — capital expenditure (equipment, installation)
- Revenue_mo — monthly income from rewards + fees
- OPEX_mo — operating expenses (electricity, internet, maintenance)
{{< /formula >}}
### Example: GPU Node Operator (Render)
| Parameter | Value |
|---|---|
| CAPEX (single RTX 4090-class GPU + server) | $5,000 |
| Monthly OPEX (electricity + internet) | $150 |
| Monthly revenue (above-average utilization) | $400 |
| Payback period | $5,000 / ($400 − $150) = **20 months** |
### Example: Hotspot Operator (Helium Mobile)
| Parameter | Value |
|---|---|
| CAPEX (indoor WiFi hotspot) | $250 |
| Monthly OPEX (electricity) | $5 |
| Monthly revenue (good location; network avg ~$14/mo) | $25 |
| Payback period | $250 / ($25 − $5) = **12.5 months** |
{{< callout title="The 18-month rule" >}}
A practical heuristic: if node payback exceeds 18 months, new operator acquisition slows dramatically. The optimal range is 6–12 months. When designing DePIN tokenomics, start with the target payback period and work backward to determine the required subsidy size.
{{< /callout >}}
## DePIN Emission Models
### Fixed Emission with Halving
Helium and many DePIN projects use an emission model borrowed from Bitcoin: a fixed amount per epoch with periodic halving.
{{< formula math="Emission_epoch(n) = Emission_initial / 2^n" >}}
- n — halving period number
- Typical period: 2 years
- Creates a predictable subsidy reduction schedule
{{< /formula >}}
### Tied to Useful Work
A more sophisticated model: emissions are distributed proportionally to **useful work** performed by the operator.
| Work type | Protocol | Metric |
|---|---|---|
| Data storage | Filecoin | GB × days stored |
| GPU rendering | Render | Number of completed tasks |
| Wireless coverage | Helium | Volume of data transferred |
| Mapping | Hivemapper | Kilometers of fresh maps |
{{< formula math="Operator_reward = Emission_epoch × (Work_operator / Work_total)" >}}
- Work_operator — useful work by a specific operator
- Work_total — total useful work across all operators
- The formula automatically routes rewards to active operators
{{< /formula >}}
### Collateral Model (Filecoin)
Filecoin adds a collateral mechanism: operators must lock FIL proportional to the storage they provide. Violating commitments (data loss, downtime) results in slashing.
{{< formula math="Min_collateral = Storage_TB × Collateral_rate_per_TB" >}}
- Collateral ties the operator to long-term commitments
- Creates additional token demand (operators must buy tokens for collateral)
- The slashing mechanism is covered in detail in the [staking]({{< relref "models/staking" >}}) article
{{< /formula >}}
## DePIN Project Comparison
| Project | Service | Emission model | BME | Collateral | Max supply | Payback period |
|---|---|---|---|---|---|---|
| **Filecoin** | Storage | Baseline + network growth | Partial | Yes (FIL) | 2B FIL | 12–24 mo. |
| **Render** | GPU compute | Predefined declining schedule (BME) + per-task burn | Yes | No | 644M RENDER | 12–20 mo. |
| **Helium** | Wireless | Halving (2 years) | Yes (Data Credits) | No | 223M HNT | 8–15 mo. |
| **Hivemapper** | Maps | Per new kilometers | Yes (Map Credits) | No | 10B HONEY | 6–12 mo. |
| **Akash** | Cloud compute | Inflationary + BME (Mar 2026) | Yes (ACT credits) | No (lease escrow only) | ~388.5M AKT | Variable |
| **DIMO** | Vehicle data | Declining weekly issuance (−15%/yr), connection-based points | No (direct rewards) | No | 1B DIMO | 6–10 mo. |
## Designing DePIN Tokenomics
### Step 1: Node Unit Economics
Start with a backward calculation: set the target payback period (6–12 months), estimate CAPEX and OPEX for a typical operator, calculate the required monthly revenue.
### Step 2: Supply Estimation
Determine how many nodes are needed for a minimum viable network (MVN). Multiply by the required monthly revenue — this gives you the subsidy budget for the cold start phase.
### Step 3: Burn Model
Design the BME mechanism: how does the user pay, what gets burned, at what exchange rate. Tie the service price to a fiat equivalent to eliminate volatility.
### Step 4: Emission Schedule
Define the subsidy reduction schedule. The critical question: will real demand grow fast enough before subsidies become insufficient to cover operator OPEX?
{{< formula math="Safety_margin = (Subsidy − OPEX) / Subsidy_decay_rate" >}}
- Safety_margin — number of months before subsidies fall below OPEX
- If margin < 12 months and no real demand exists → critical risk
{{< /formula >}}
{{< checklist title="DePIN tokenomics checklist" type="check" >}}
Payback — node unit economics ensures return in under 18 months
Fiat peg — BME model ties service cost to fiat equivalent
Emission schedule — aligned with demand growth forecast
Quality verification — mechanism to verify service quality, not just node presence
Anti-phantom protection — collateral model prevents phantom nodes
Geography — reward distribution accounts for location (for coverage networks)
{{< /checklist >}}
## DePIN Tokenomics Risks
### Supply-Side Death Spiral
If token price falls → operator revenue drops → operators shut down nodes → network quality declines → users leave → burn falls → token price drops further. Protection: fiat-pegged rewards, reserve fund, minimum revenue guarantees.
### Phantom Nodes
Operators turn on equipment but don't provide real service — only to collect subsidies. Solution: tie rewards to proof of useful work, not proof of stake (network presence). Additionally: random availability and quality checks.
### Token Price Dependency
During the subsidy phase, 80–100% of operator revenue comes from tokens. A 50% price drop at least doubles the payback period, and can stretch it to roughly 5× as fixed OPEX becomes a larger share of revenue. This is especially critical for operators with high CAPEX (GPUs, servers).
## Summary
DePIN tokenomics solves a problem unique to the crypto market: attracting capital investment in physical infrastructure through token incentives. Burn-and-Mint Equilibrium is the dominant model, creating a direct link between service consumption and token economics.
The key design principle: **start with operator unit economics**, not tokenomics. If nodes don't pay for themselves, no emission model will save the network.
{{< cta title="Designing a DePIN network?" text="We've modeled tokenomics for infrastructure networks across storage, compute, and connectivity verticals. We'll design your BME model, emission schedule, and operator economics." button="Get in touch" link="/quote/" >}}
---
## Discount Model: Token Utility Through Fee Reduction
- URL: https://giantslabs.pro/models/discount-model/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Discount token utility: price ceiling formula, discount types (fixed, tiered, dynamic), BNB and CRO case studies, and token reinforcement strategies.
A fee discount for using the native token is the simplest and most intuitive utility model. The holder buys the token to pay less for a service. But behind this simplicity lies a fundamental limitation: **a discount creates demand only at the moment of the transaction.** The user has no incentive to hold — they buy and immediately spend. For the model to work long-term, additional retention mechanisms are needed.
## What Is the Discount Model
**Discount model** — a utility mechanism where the protocol offers a fee reduction when paying with the native token. It creates price arbitrage: as long as the savings from the discount exceed the cost of acquiring the token, it's rational to pay with the token.
The discount model is one of the [five core demand models]({{< relref "models/demand-models" >}}) and is among the most common in projects with commission-based revenue.
{{< callout title="Discount vs Payment" >}}
In the discount model, token payment is **optional** — it's an incentive, not a requirement. In the payment model, the token is the **only** means of payment. Discounts attract; payments obligate. This defines the difference in demand strength and user behavior.
{{< /callout >}}
## Mechanics
### Four Steps of the Discount Cycle
1. **Base fee.** The protocol sets a standard fee for its service (e.g., 0.3% on a trade)
2. **Token discount.** When paying the fee with the native token, the protocol reduces it (e.g., to 0.15%)
3. **Market purchase.** The user buys the token on the secondary market
4. **Burn or recycle.** The spent token is burned (deflationary effect) or returned to the treasury
Each step creates economic pressure: step 3 — buy pressure, step 4 — supply pressure. But both act **instantaneously** — unlike staking, there's no prolonged lockup.
### Rationality Condition
A user chooses to pay with the token if:
{{< formula math="Savings > Buy_cost + Holding_risk" >}}
- Savings — benefit from the discount
- Buy_cost — token purchase price + slippage + gas
- Holding_risk — risk of price change during the holding period
{{< /formula >}}
On liquid markets, Holding_risk approaches zero: the user buys and spends in one block. On illiquid markets, slippage can eat up the entire discount.
## Price Ceiling Formula
If **all** volume flows through the discount, you can calculate the maximum fundamental token price:
{{< formula math="P_max = Fee × Volume × Discount_% / Supply" >}}
- P_max — fundamental price ceiling
- Fee — base fee rate
- Volume — transaction volume per period
- Discount_% — discount size
- Supply — tokens in circulation
{{< /formula >}}
### Numerical Example
An exchange with 0.1% fee on $500M/month volume, 25% discount for token payment, circulating supply of 50M tokens (illustrative numbers — not mapped to any specific asset; BNB's current circulating supply is ~138M):
{{< formula math="P_max = 0.001 × $500M × 0.25 / 50M = $0.0025" >}}
- Fundamental price ceiling: $0.0025 per token at current volumes
{{< /formula >}}
At annual volume of $6B:
{{< formula math="P_max = 0.001 × $6B × 0.25 / 50M = $0.03" >}}
- Annual ceiling: $0.03 per token
{{< /formula >}}
{{< callout type="warning" title="P_max is a ceiling, not a price" >}}
The formula shows the **maximum justified** price at 100% discount utilization. The actual price may be higher (speculative premium) or lower (not everyone uses the discount). P_max is a stress-testing benchmark, not a forecast.
{{< /callout >}}
## Discount Types
### 1. Fixed Discount
A constant percentage fee reduction when paying with the token. Simple, predictable, but doesn't adapt to market conditions.
**Example:** BNB at launch — 50% discount on trading fees (per the whitepaper schedule, Y1 50% → Y2 25% → Y3 12.5% → Y4 6.75% → Y5 0%; in practice, Binance froze the discount at the Year-2 level of 25% instead of letting it decay to zero).
### 2. Degressive Discount
The discount decreases on a schedule, training users to accept a diminishing subsidy. This controls the program's cost to the protocol.
| Year | Discount (whitepaper) |
|---|---|
| 1 | 50% |
| 2 | 25% |
| 3 | 12.5% |
| 4 | 6.75% |
| 5 | 0% |
In practice, Binance deviated from the schedule: rather than letting the discount decay to 0% by Year 5, it was frozen at the Year-2 rate of 25%, where it remains today.
Risk: when the discount hits zero, token demand drops sharply if there's no alternative utility.
### 3. Tiered Discount
The discount size depends on how many tokens the user holds or stakes. Creates an incentive to **accumulate** — partially solving the instant-turnover problem.
| Tier | Balance | Discount |
|---|---|---|
| Bronze | 100+ tokens | 10% |
| Silver | 1,000+ tokens | 15% |
| Gold | 10,000+ tokens | 25% |
| Platinum | 100,000+ tokens | 40% |
**Example:** CRO (Crypto.com) — card tier is determined by CRO stake, which determines cashback rates and perks.
### 4. Dynamic Discount
The discount adapts to market conditions: increases when token demand is low, decreases when it's high. Most complex to implement, but economically optimal.
{{< formula math="Discount(t) = min(D_max, max(0, D_base × (P_target / P_market)^k))" >}}
- D_base — base discount rate
- D_max — hard cap on discount (e.g., 50% or 100%) to prevent unbounded growth
- P_target — project's target price
- P_market — current market price
- k — sensitivity (0.5–2)
- Discount(t) — adjusted discount at time t, bounded between 0 and D_max (computed)
{{< /formula >}}
When P_market < P_target, the discount increases, stimulating purchases. When P_market > P_target, it decreases, conserving protocol resources. The cap/floor clause is essential: without it, extreme ratios can push the discount above 100% (the protocol paying users to trade) or below zero.
## Case Studies
### BNB (Binance)
BNB is the canonical discount model example, but its success goes beyond the discount alone.
**Discount:** 50% on trading fees when paying with BNB (launched 2017), reduced to 25% in 2018. The whitepaper schedule would have decayed the rate to 0% by Year 5; instead, Binance froze the discount at the Year-2 level (25%) and has kept it there since. See the [Binance fee FAQ](https://www.binance.com/en/support/faq/detail/115000583311) and the BNB contract on Ethereum: [0xB8c77482e45F1F44dE1745F52C74426C631bDD52](https://etherscan.io/token/0xB8c77482e45F1F44dE1745F52C74426C631bDD52).
**Why it worked:**
- Binance is the largest exchange by volume → massive base Volume in the P_max formula
- The discount was an **entry point**, not the only utility
- Additional utilities were added in parallel: Launchpad (IEO access), BNB Chain (gas), staking
- Initially — quarterly burns using "20% of exchange profits." Since late 2021, the quarterly burn was replaced by the **Auto-Burn formula** (algorithmic, based on BNB price and BNB Chain block production), which is distinct from **BEP-95** — a separate real-time mechanism that burns a portion of BNB Chain gas fees at the protocol level. Together they have burned ~62M BNB, leaving circulating supply around 138M versus the 100M long-term target. See the [BNB Chain burn blog](https://www.bnbchain.org/en/blog/33rd-bnb-burn) and the live tracker [BNBBurn.info](https://www.bnbburn.info/)
**Lesson:** the discount created initial demand. The ecosystem and burn sustained it.
### CRO (Crypto.com)
CRO demonstrates the tiered discount with staking integration.
**Mechanics:** cashback rate on the Crypto.com card depends on CRO staked. More staked = higher cashback. Peak (pre-June 2022) was up to 8%; after the June 2022 revision the structure tightened substantially and was later partially restored through the Level Up program.
| Tier (post-2022) | Cashback |
|---|---|
| Midnight Blue / Ruby Steel | 0% |
| Royal Indigo / Jade Green | 0.5% |
| Icy White / Frosted Rose Gold | 1% |
| Obsidian | 2% |
Priority Pass lounge access remains for Jade Green tier and above. CRO contract on Ethereum: [0xA0b73E1Ff0B80914AB6fE0444E65848C4C34450b](https://etherscan.io/token/0xA0b73E1Ff0B80914AB6fE0444E65848C4C34450b).
**Dual effect:**
1. **Staking** — locks tokens (retention mechanism)
2. **Discount** — creates buy incentive
The combination solves the discount model's main problem: staking for a tier forces holding, not just buy-and-spend.
{{< callout type="warning" title="Governance can reverse the burn narrative — CRO Golden Age (2025)" >}}
In March 2025, a Cronos governance vote ("Golden Age" proposal) approved the **re-minting of 70 billion CRO** that had been burned back in 2021, effectively reversing one of the largest supply reductions in crypto history and moving circulating supply back toward the 100B cap. For any discount model that leans on a burn-backed "price floor" narrative, this is a cautionary precedent: burns are only as permanent as the governance process that protects them. See coverage in [The Block](https://www.theblock.co/post/346717/) and [CoinDesk](https://www.coindesk.com/markets/2025/03/03/crypto-com-wants-to-revive-usd5b-worth-of-cro-tokens-it-once-burned-in-peculiar-golden-age-proposal).
{{< /callout >}}
### Aave (GHO Discount)
Aave demonstrates the discount model in DeFi: stkAAVE stakers in the Safety Module receive a reduced borrowing rate on the GHO stablecoin (1 stkAAVE = discount on 100 GHO). This creates a connection between staking (protocol security) and discount (favorable terms for GHO borrowers).
## Limitations
### 1. Transactional Demand
The discount creates demand **only at the point of payment.** Between transactions, the user has no incentive to hold. This leads to high [token velocity]({{< relref "models/token-velocity" >}}), which suppresses the fundamental price.
### 2. Volume Dependency
P_max is directly proportional to Volume. If protocol volumes drop, the price ceiling drops with them. For early-stage projects with unstable volume, the discount doesn't generate sufficient demand.
### 3. Competition with Aggregators
In DeFi, aggregators (1inch, Paraswap) automatically find the best route. If a competitor offers a better price without requiring a token, the discount loses its point. Users optimize for total cost, not loyalty programs.
### 4. Rational Minimum Holding
Sophisticated users optimize: buy token → pay → sell remainder — all in one block via flash loans or batched transactions. The protocol gets utilization, but not retention.
## How to Strengthen the Discount Model
A pure discount works weakly. Successful projects combine it with other mechanisms:
| Combination | Effect | Example |
|---|---|---|
| Discount + staking (tiered) | Locks tokens to qualify for the discount | CRO, Aave |
| Discount + burn | Burning spent tokens reduces supply | BNB |
| Discount + governance | Token for discount + voting | veToken protocols |
| Discount + cashback vesting | Discount is accrued but vests (unlock after 30–90 days) | Loyalty programs |
| Discount + NFT tiers | NFT determines discount level, NFT trades on secondary | Membership programs |
{{< callout title="Reinforcement principle" >}}
Each additional mechanism should **increase holding time.** The discount attracts, while staking, governance, or vesting retains. A combination of 2–3 mechanisms is usually sufficient.
{{< /callout >}}
## Common Mistakes
### 1. Discount Without Volume
If a protocol generates $1M in annual volume with 0.1% fee and 25% discount, P_max at 10M supply = $0.000025. The discount can't create meaningful demand at low volumes.
### 2. Static Discount Forever
A fixed 25% discount becomes disproportionately expensive for the protocol as the token price rises. A degressive or dynamic model is preferable.
### 3. Discount as the Only Utility
Without staking, governance, or burn, the discount doesn't retain users. An isolated discount model creates maximum velocity and minimum price support.
### 4. Ignoring Slippage
On an illiquid market, the cost of buying the token (slippage + gas) can exceed the discount savings. This zeroes out the incentive.
### 5. Flat Discount Instead of Tiered
The same discount for a whale with $10M volume and a retail user with $100 is suboptimal. A tiered system ties the discount to contribution while incentivizing accumulation.
{{< checklist title="Discount model design checklist" type="check" >}}
P_max calculated: price ceiling justified by current and projected volumes
Discount type selected: fixed, degressive, tiered, or dynamic
Discount is economically rational: savings > purchase cost + slippage
Retention mechanism added: staking, lockup, or governance for holding incentive
Burn mechanism defined: spent tokens are burned or recycled
Discount adapts: dynamic rate or degressive schedule
Liquidity is sufficient: slippage doesn't negate the discount
Backup utility planned: what happens when the discount expires
{{< /checklist >}}
{{< cta title="Designing a discount mechanism?" text="We've built discount models for exchanges, DeFi protocols, and loyalty platforms. We'll help select the optimal type, size, and retention reinforcements." button="Get in touch" link="/quote/" >}}
---
## Dividends vs Buyback: Two Token Utilization Models
- URL: https://giantslabs.pro/models/utility-models/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Comparing dividend (revenue share) and buyback & burn models. Yield formulas, metrics, hybrid ve-models, and choosing the optimal utilization strategy.
How protocols create sustainable token demand through revenue distribution and supply reduction. Yield formulas, real examples, and an algorithm for choosing the optimal model.
## What Is Token Utilization
**Token utilization** — mechanisms that create ongoing demand for the token, acting as a counterweight to emission. If emission is the faucet pouring tokens into circulation, utilization is the drain that absorbs them.
Without utilization mechanisms, any token with emission is destined for long-term price decline: growing supply against flat or falling demand pushes the price down. This is why thoughtful utilization is one of the key elements of tokenomics.
Two fundamentally different approaches exist:
- **Dividend model** (revenue share) — protocol revenue is distributed to token holders through staking. Tokens aren't destroyed, but holders are incentivized to hold.
- **Buyback model** (buy-back & burn) — the protocol buys tokens on the open market and burns them, reducing total supply and creating deflation.
{{< callout title="Core principle" >}}
Utilization only works when the protocol generates **real revenue.** Distributing inflationary rewards isn't utilization — it's moving money from one pocket to another. True yield (real yield) comes only from protocol fees and profits.
{{< /callout >}}
### Why Utilization Matters
Utilization mechanisms serve multiple purposes simultaneously:
1. **Emission counterweight** — offsetting price pressure from token unlocks (vesting, rewards)
2. **Holding incentive** — holders earn income or benefit from deflation instead of selling
3. **Real economy link** — the token price begins reflecting business profitability, not just speculative demand
4. **Capital attraction** — institutional investors prefer tokens with a clear return model
## Dividend Model (Revenue Share)
In the dividend model, the protocol directs a portion of its revenue to token holders. To receive payouts, tokens must be staked — locked in a smart contract. This creates two effects: direct income for stakers and reduced circulating supply.
### How It Works
1. The protocol collects fees (trading fees, loan interest, service charges)
2. A share of fees is directed to a reward pool
3. Holders lock tokens via staking
4. Rewards are distributed proportionally to each staker's share
5. Payouts come in stablecoins, ETH, or the protocol's own token
### Yield Formulas
{{< formula math="Yield = (Revenue × Stake_share) / (Mcap × Stake_%)" >}}
- Yield — annual dividend yield
- Revenue — annual protocol revenue
- Stake_share — fraction of revenue directed to stakers
- Mcap — market capitalization
- Stake_% — fraction of tokens staked
- Note: Mcap × Stake_% = total value staked
{{< /formula >}}
If a protocol earns $10M/year, directs 50% to stakers, has a $100M market cap, and 40% of tokens are staked:
{{< formula math="Yield = ($10M × 0.5) / ($100M × 0.4) = 12.5%" >}}
- Real yield of 12.5% annually in stablecoins
- No inflationary dilution
{{< /formula >}}
### Revenue Share Examples
**xSUSHI (SushiSwap).** One of the first revenue share implementations in DeFi. SUSHI holders stake and receive xSUSHI — a token whose value grows by accumulating 0.05% of every swap on the platform.
**GMX.** Since October 2024, GMX V2 runs a Buyback & Distribute model: 27% of protocol fees buy back GMX on the open market, and the repurchased tokens are distributed to stakers by staking power (legacy V1 paid 30% of fees directly in ETH/AVAX). Since March 2026, these staking rewards accrue in the treasury pending a $90 GMX price target rather than paying out continuously.
**veCRV (Curve Finance).** Holders lock CRV for up to 4 years and receive a share of pool trading fees plus crvUSD borrowing interest. Longer lockup = more votes and a higher reward share. This is a hybrid model combining revenue share with governance.
{{< callout title="Dividend model advantages" >}}
**Transparency:** stakers see exactly how much and when they receive. **Predictability:** yield is tied to real revenue. **Direct motivation:** holders benefit from protocol growth because it increases their dividends.
{{< /callout >}}
## Buyback & Burn Model
In the buy-back & burn model, the protocol uses a portion of revenue to purchase its own tokens on the open market and burn them (send to a zero address). This reduces total supply, which — given stable demand — drives up the price of each remaining token.
### How It Works
1. The protocol accumulates fee revenue
2. On a schedule (monthly, quarterly), it buys tokens on a DEX or via OTC
3. Purchased tokens are sent to a burn address (0x000...dead)
4. The burn transaction is visible on-chain — transparency is verifiable
5. Total token supply decreases permanently
### Effect Formulas
{{< formula math="Buyback_yield = (Revenue × Buyback_share) / Mcap" >}}
- Buyback_share — fraction of revenue directed to buybacks
- Revenue — annual protocol revenue
- Mcap — market capitalization
- Buyback_yield — shows annual supply reduction as % of market cap (computed)
{{< /formula >}}
Buyback yield is economically equivalent to dividend yield, but instead of direct payouts to stakers, value is distributed through token price appreciation.
{{< formula math="Deflation_% = Burned / Supply × 100" >}}
- Burned — tokens removed from circulation
- Supply — total token supply
- Deflation_% — annual supply reduction rate (computed)
{{< /formula >}}
### Buyback Examples
**BNB (Binance).** Quarterly automatic burn via a formula tied to BNB price and BSC block count. Initial supply: 200M tokens, target: 100M. Over 65M BNB burned by mid-2026, cutting supply to ~135M on the way to the 100M target. One of the largest buy-back & burn programs in the industry.
**SKY (formerly MKR/MakerDAO).** MakerDAO rebranded to Sky in 2024 (MKR migrates to SKY at 1:24,000). The protocol runs the Smart Burn Engine—surplus revenue funds a systematic buy-and-burn of SKY (~$100M deployed in 2025). The legacy MKR ticker has been delisted from major exchanges.
**AAVE.** Since April 2026, Aavenomics 3.0 routes 100% of Aave Protocol and GHO revenue into an automatic, non-discretionary AAVE buyback (~292 AAVE/day). The legacy Safety Module is being phased out in favor of Umbrella (launched June 2025), an on-chain risk system where stkAAVE now serves primarily a governance role.
{{< callout type="warning" title="Tax distinction" >}}
In many jurisdictions, buyback doesn't create a taxable event for holders until they sell at an appreciated price (capital gains). Dividends, by contrast, may be taxed at receipt—in the U.S., staking and dividend-style rewards are treated as ordinary income when received, while buyback-driven appreciation is taxed as capital gains only on sale. Rules vary significantly by jurisdiction—consult a tax professional.
{{< /callout >}}
## Model Comparison
Both models use protocol revenue to create token value, but do so in fundamentally different ways.
| Parameter | Dividends (revenue share) | Buyback (buy-back & burn) |
|---|---|---|
| **Mechanics** | Direct payouts to stakers | Token purchase and burn |
| **Revenue flow** | Fees → stakers | Fees → market purchase |
| **Price impact** | Indirect (reduced sell pressure) | Direct (price appreciation via deflation) |
| **Transparency** | High (visible payouts) | High (visible burn transactions) |
| **Tax for holders** | Event at receipt | Event at sale |
| **Requires staking** | Yes | No (all holders benefit) |
| **Regulatory risk** | High (securities) | Medium |
| **Revenue linkage** | Direct and obvious | Indirect (through burn volume) |
| **Downtrend behavior** | Yield rises (price falls, yield = revenue/price) | More tokens bought for the same burn budget |
| **Examples** | SushiSwap, Curve | BNB, SKY, AAVE |
### Regulatory Considerations
The dividend model carries elevated regulatory risk: distributing revenue proportionally to holdings is one of the hallmarks of a security under the Howey Test. A token with revenue share may be classified as an unregistered security in the US and other jurisdictions.
Buy-back & burn is considered less risky because holders don't receive direct payouts. However, the regulatory landscape is evolving, and this requires legal assessment for each specific project.
## Hybrid Models
The most advanced protocols combine both approaches, adding governance and time-locking mechanics. The flagship hybrid model is vote-escrow (ve-model), first implemented by Curve Finance.
### Vote-Escrow: Lock + Governance + Income
In the ve-model, a holder locks tokens for a fixed period (weeks to years) and receives a ve-token in return. This ve-token provides three benefits simultaneously:
- **Revenue share** — a portion of protocol fees proportional to ve-token holdings
- **Governance votes** — ability to influence emission allocation (gauge voting)
- **Boosted rewards** — bonus multiplier on liquidity mining rewards
{{< formula math="veToken = Token × (t_lock / t_max)" >}}
- veToken — voting token balance (computed)
- Token — tokens locked
- t_lock — lock duration
- t_max — maximum lock duration
- Example: CRV locked for 4 years → 1:1 veCRV; for 2 years → 0.5 veCRV per CRV
{{< /formula >}}
### Curve Finance (veCRV)
Curve is the benchmark ve-model. Holders lock CRV for up to 4 years, receiving veCRV. Key mechanics:
- **Fees:** 50% of trading fees from all pools, plus 80% of crvUSD borrowing interest, are distributed to veCRV holders
- **Gauge voting:** veCRV holders vote on CRV emission allocation across pools. This created an entire "Curve Wars" ecosystem, where protocols compete to direct emissions to their pools
- **Boost:** liquidity providers with veCRV receive up to 2.5x rewards
### Pendle (sPENDLE)
Pendle transitioned from vePENDLE to sPENDLE in January 2026—a liquid staking model with 14-day unstaking (or instant exit at a 5% fee), up to 4x loyalty boost for former vePENDLE lockers, and emissions cut ~30% via algorithmic allocation. Stakers still receive a share of trading pool fees and vote on emission direction. Additionally, Pendle uses a buyback mechanism: up to ~80% of revenue purchases PENDLE on the market before distributing to stakers.
{{< callout title="Why the ve-model works" >}}
The ve-model creates a **triple lock** on tokens: (1) direct income incentivizes locking, (2) governance creates political value for the token, (3) boost makes locking profitable for liquidity providers. Result — a high share of staked tokens (60–80%) and a stable price.
{{< /callout >}}
### Other Hybrid Approaches
**Buyback + redistribution.** The protocol buys tokens on the market but doesn't burn them — instead, it distributes them to stakers. Combines buy pressure with direct income.
**Partial burn + partial distribution.** Revenue is split: 50% to buy-back & burn, 50% to staker distribution. This diversifies mechanics and reduces risk concentration.
## Efficiency Metrics
### P/E Ratio for Tokens
{{< formula math="P/E = FDV / Annual_revenue" >}}
- P/E — price-to-earnings multiple for the token
- FDV — fully diluted valuation
- Annual_revenue — annual protocol revenue
- Lower P/E = "cheaper" token relative to revenue
{{< /formula >}}
P/E enables fundamental comparison across protocols. A token with P/E = 10 trades "cheaper" than one with P/E = 100, all else being equal. Protocol revenue data is available on Token Terminal, DeFiLlama, and similar aggregators. P/E here uses FDV rather than market cap because FDV accounts for future emissions—a market-cap-based P/E would understate tokens with large unvested supply. The buyback yield metrics below are measured against current market cap, not FDV, so the denominators intentionally differ between the two.
| Protocol | Model | Approximate P/E | Notes |
|---|---|---|---|
| **GMX** | Revenue share | 10–15 | Low P/E, high real yield |
| **Curve** | Ve-model (hybrid) | 20–40 | Premium for governance value |
| **BNB** | Buy-back & burn | 8–12 | Massive burn volume |
| **AAVE** | Safety module | 30–50 | Conservative utilization |
P/E ranges above are illustrative snapshots that shift materially quarter to quarter—verify current figures on Token Terminal or DeFiLlama before relying on them. Data current as of mid-2026.
### Buyback Yield
{{< formula math="Buyback_yield_% = Buyback_volume / Mcap × 100" >}}
- Buyback_yield_% — annual buyback yield (in percent)
- Buyback_volume — annual token buyback volume ($)
- Mcap — market capitalization
- Shows % of market cap returned annually through burns
{{< /formula >}}
At 5% buyback yield, the protocol annually burns tokens worth 5% of its market cap. This is the equivalent of a 5% dividend yield in terms of value return.
### Real Yield vs Inflationary Income
{{< formula math="Real_yield = Nominal_yield − Inflation" >}}
- Nominal_yield — advertised APY
- Inflation — annual emission / current supply
- Real_yield — actual yield after dilution (computed)
{{< /formula >}}
It's critically important to distinguish real income from inflationary income. If a protocol pays 20% APY to stakers but emits 25% new tokens annually, **real yield is negative**: −5%. Stakers receive more tokens, but each token loses value due to dilution.
{{< callout type="warning" title="Real yield calculation example" >}}
**Advertised staking APY:** 30%
**Annual emission (inflation):** 25%
**Real yield:** 30% − 25% = **5%**
But if payouts are in the protocol's own token:
**Real position growth:** 5% (in tokens)
**Price impact from dilution:** −20%
**Actual USD yield: negative**
{{< /callout >}}
## Common Mistakes
### Inflationary Rewards Disguised as Yield
The most common mistake — masking inflationary emission as yield. A protocol claims "30% APY on staking," but this 30% is paid from newly minted tokens, not revenue. Stakers receive more tokens, but each token loses value from dilution.
Red flags: **APY > 100%** almost always means inflationary rewards. **Payouts in the protocol's own token** without revenue linkage is classic Ponzi mechanics. **No revenue data** alongside high rewards warrants thorough investigation.
### Unsustainable APY
Some protocols set a fixed APY at launch while real revenue doesn't cover the promised payouts. The difference is funded from the treasury or new emission. When the treasury runs out, APY drops sharply, and the token price follows.
A sustainable model ties payouts to actual revenue: revenue grows — dividends grow; it falls — they fall. An honest approach, even if the yield is lower.
### Buyback Without Transparency
A protocol announces a buyback program but doesn't publish addresses, transactions, or schedules. Without verifiable burns, there's no guarantee buybacks actually happen. Best practice: public burn address and regular reports with on-chain transaction links.
### Securities Regulatory Risk
The Howey Test defines securities by four criteria: (1) investment of money, (2) in a common enterprise, (3) with expectation of profit, (4) solely from others' efforts. A token with revenue share hits all four if stakers passively receive income from the protocol team's work.
Mitigation strategies:
- **Governance decentralization** — transferring key decisions to the DAO reduces dependence on "others' efforts"
- **Active participation** — the ve-model requires holders to vote, adding an element of participation
- **Buyback over dividends** — indirect value distribution is considered less risky
- **Legal structure** — wrapping through a Foundation or DAO with clear documentation
### Stake Concentration
If 80% of stake belongs to 5 wallets (often insiders), revenue share effectively returns income to founders. Retail holder yield gets diluted. Monitor top-10/top-50 holder concentration relative to known exchange wallets—Gini coefficients above 0.7–0.8 are the norm even for well-distributed protocols like AAVE (0.78), so treat the metric as directional, not a pass/fail threshold.
## How to Choose a Model
### Decision Tree
```text
Is protocol revenue stable?
├── Yes → Is governance needed?
│ ├── Yes → Ve-model (hybrid)
│ └── No → Risky jurisdiction?
│ ├── Yes → Buy-back & burn
│ └── No → Revenue share (dividends)
└── No → Is revenue growing?
├── Yes → Buyback (scales with revenue)
└── No → Defer utilization until revenue stabilizes
```
### Recommendations by Protocol Type
**DEX / trading platform** — hybrid ve-model. Trading fees create stable revenue; governing liquidity allocation adds token value. Examples: Curve, Pendle, Velodrome (merging with Aerodrome into Aero, 2026).
**Lending protocol** — buy-back & burn or Safety Module. Interest income is predictable, but regulatory risks are high — direct dividends are dangerous. Examples: AAVE, MakerDAO.
**Infrastructure project (L1/L2, oracles)** — staking with revenue share elements. Network fees are distributed to validators, creating natural demand for the token to participate in consensus.
**Exchange token** — buy-back & burn. Centralized exchanges can't fully decentralize governance. Buyback is simple to implement and doesn't carry securities risk when utility exists. Examples: BNB.
**Early stage (low revenue)** — deferred utilization. Don't promise yield when there's no revenue. Better to build the mechanics into the smart contract but activate them once the protocol generates stable income.
{{< cta title="Need a utilization model for your token?" text="We'll design the demand mechanics, calculate staker yield, and prepare the financial model." button="Get in touch" link="/quote/" >}}
---
## From Protocol to Public Equity: Ethena's Dual-Track Architecture (USDe, sUSDe, USDtb, USDE)
- URL: https://giantslabs.pro/models/ethena-stablecoinx-public-equity/
- Section: models
- Date: 2026-05-18
- Last modified: 2026-05-18
- Description: On 10 March 2026 TLGY shareholders approved the StablecoinX merger and a DeFi protocol crossed onto Nasdaq under ticker USDE. We dissect the dual-track architecture — USDe, sUSDe, USDtb, and the public-equity wrapper — and what it means for stablecoin issuers planning multi-rail strategies.
On 10 March 2026, TLGY Acquisition Corp shareholders approved the business combination with StablecoinX Assets Inc. The Class A common stock of the surviving entity, StablecoinX Inc., is now expected to trade on Nasdaq under the ticker **USDE**. A DeFi protocol crossed onto a US public exchange — not by listing its native token, but by wrapping the validator and treasury operations of that token in a publicly traded corporate shell.
{{< callout type="info" title="Update — June 2026" >}}
The de-SPAC has since closed: the merger completed on ~25 June 2026, and StablecoinX Class A began trading on Nasdaq under ticker **USDE** on ~27 June 2026. The sections below were written as of publication (May 2026), when the shareholder vote had passed but closing was still pending — the "expected to trade" and "closing follows" framing reflects that pre-close vantage.
{{< /callout >}}
Read past the press-release framing and the architecture matters more than the listing. StablecoinX is not the first crypto company on Nasdaq, and Circle has long operated USDC across multiple regulatory regimes (NYDFS, MiCA EMT, Singapore MPI). What is new is the combination: this is the first **synthetic-dollar / delta-neutral** protocol to pair a DeFi-native rail (USDe and sUSDe), a US-federal rail (USDtb under the GENIUS Act, custodied by Anchorage Digital Bank), and a public-equity wrapper over the validator and ENA-treasury layer — and openly framed the result as a dual-track design. The EU rail (MiCA Article 6) sits as the obvious third leg and is where stablecoin issuers reading this article will recognize their next decision.
This article walks through what Ethena actually is in 2026, how the StablecoinX wrapper is structured, where the math leaks (insurance fund at 1.18% of TVL, funding-rate flips, governance optics), and what stablecoin issuers should learn before assuming the pattern generalizes.
## 10 March 2026: the architectural inflection
The shareholder vote was the second of three trigger events that collapsed a year of preparation into a working multi-rail architecture. **22 July 2025** — Ethena and TLGY announced the business combination with a $360M PIPE ($260M cash plus $100M in discounted ENA tokens). **3 September 2025** — an additional $530M in PIPE financing was disclosed alongside a new Strategic Advisory Board, bringing total committed capital to **$890M**. Key investors named: Ethena Foundation ($60M), Dragonfly, Ribbit Capital, Blockchain.com, and others. **10 March 2026** — TLGY shareholders approved the deal. Closing follows the standard de-SPAC sequence: redemption window, customary conditions, listing.
It is worth pausing on terminology. This is **not** an IPO. StablecoinX is going public via a reverse merger with a SPAC (TLGY), a structure colloquially called **de-SPAC**. The distinction matters for three reasons: the PIPE is the actual capital raise (the SPAC trust holds residual cash after redemptions); the disclosure is shaped by the S-4 and proxy statement, not an S-1; and the surviving entity inherits TLGY's public-company status without ringing a bell. Articles describing the event as "the first stablecoin IPO" are technically wrong and meaningfully misleading — the IPO comparison would imply primary issuance of new shares to public investors, while a de-SPAC is a control transaction packaged as a merger.
What the structure achieves is the same as what an IPO would have achieved: a Nasdaq-listed corporate entity whose business is validator operation, ENA treasury accumulation, and tokenization infrastructure services for the Ethena protocol, operating under a 5-year collaboration agreement with the Ethena Foundation. Ethena Foundation retains majority voting control via Class B shares; public investors hold Class A. We will come back to that dual-class structure in the Pitfalls section.
{{< callout type="info" title="StablecoinX in one frame" >}}
**Listing vehicle**: StablecoinX Inc., Class A on Nasdaq under ticker **USDE**.
**Predecessors**: TLGY Acquisition Corp (SPAC) + StablecoinX Assets Inc., both becoming wholly owned subsidiaries.
**Capital**: ~$890M PIPE — $260M cash + $100M discounted ENA + $530M follow-on PIPE.
**Operating mandate**: run validators for the Ethena protocol, accumulate ENA in treasury, provide related infrastructure services. 5-year collaboration agreement with Ethena Foundation.
**Governance**: Ethena Foundation holds Class B with majority voting power; public investors hold non-voting Class A.
**Trigger date**: shareholder approval 10 March 2026; closing per de-SPAC sequence.
{{< /callout >}}
## What Ethena actually is (and what it is not)
Before unpacking the wrapper, fix the underlying product. The taxonomy mistake recurs in nearly every mainstream explainer of Ethena, and it propagates into the StablecoinX coverage too.
**USDe is a delta-neutral synthetic dollar.** Users deposit collateral — ETH, BTC, liquid-staked tokens, or stablecoins — and Ethena simultaneously opens a short perpetual position of equivalent notional on a derivatives exchange. The collateral is held in off-exchange custody; the short leg sits at the venue. If ETH drops 50%, the long collateral is worth half, the short gains roughly the other half, and the dollar-denominated backing stays close to 1:1. Capital efficiency is the headline: USDe needs ≈1:1 backing rather than the over-collateralization Sky/DAI requires.
**sUSDe is the staked wrapper that earns yield.** When users stake USDe into sUSDe, they capture the protocol's three revenue streams: (1) funding-rate income from the short perpetual leg, (2) Ethereum staking yield from the LST portion of collateral, (3) reserve-asset yield (US T-bills and tokenized treasuries on the stable portion). Non-stakers hold plain USDe and forgo yield — this is the structural choice that lets the yield-bearing wrapper sit outside the GENIUS Act perimeter (more below).
**USDtb is the federal twin.** Issued by **Anchorage Digital Bank** under OCC oversight, USDtb is backed almost entirely by **BUIDL** — BlackRock's tokenized US Treasury fund. It is purpose-built for the **GENIUS Act** (Guiding and Establishing National Innovation for U.S. Stablecoins Act, signed into law in July 2025), which mandates 1:1 fiat-equivalent reserves, federal oversight of issuers, and operational transparency. The full GENIUS rulemaking is still being finalized as of mid-2026, so "GENIUS-compliant" is positioning rather than adjudicated status — but the federally chartered issuer (Anchorage's OCC trust) and the BUIDL reserve base make USDtb the cleanest live candidate. USDtb cannot pay native yield to holders — GENIUS explicitly prohibits it — but it can settle in correspondent-banking flows and access the federal payment rail.
**iUSDe is the institutional channel.** A regulated wrapper aimed at TradFi capital — pension funds, asset managers, regulated counterparties — that need an Ethena-yield exposure inside a compliance perimeter that admits accredited-investor or qualified-purchaser tags.
The family is the product. A single-product framing ("Ethena is a stablecoin") misses why the wrapper makes sense. Different rails serve different buyer profiles, and the four assets share a single revenue engine (collateral plus the delta-neutral basis trade) with regulatory wrappers fanning out from it.
For a foundational primer on stablecoin mechanics that this article builds on, see [stablecoin tokenomics]({{< relref "models/stablecoin-tokenomics" >}}).
## The math: sUSDe yield and the 1.18% insurance fund
Two numbers shape every conversation about Ethena's resilience: the **sUSDe yield**, which determines whether anyone wants to hold the product, and the **insurance fund coverage ratio**, which determines how much funding-rate stress the protocol absorbs before the peg starts to drift.
**sUSDe yield decomposition.** Annualized yield to a sUSDe holder is the weighted sum of three streams against the collateral allocation:
{{< formula math="APY_sUSDe = w_LST · y_stake + w_basis · f_perp · 365 + w_stable · y_reserves" >}}
- APY_sUSDe — annualized yield to sUSDe holder (computed)
- w_LST — share of collateral in liquid-staked ETH or similar yield-bearing crypto (fraction, 0 to 1)
- y_stake — underlying staking yield (~3% APY in 2026)
- w_basis — share of collateral held against an open short perp (fraction, 0 to 1)
- f_perp — realized daily funding rate (annualized via × 365)
- w_stable — share parked in tokenized treasuries or USDC (fraction, 0 to 1)
- y_reserves — reserve yield (~4-5% in the current rate environment)
{{< /formula >}}
The protocol publishes a **7-day trailing APY of 9.4%** and a **90-day trailing APY of 11.8%** as of late April 2026. During earlier negative-funding episodes in March 2026, the published APY compressed toward ~3.5% as the protocol rotated allocation away from w_basis and toward w_stable to preserve absolute return. The dynamic allocation is the design — sUSDe is not a fixed-yield instrument; the wrapper is supposed to drift between modes.
**Insurance fund coverage.** Ethena maintains a reserve fund that absorbs negative-funding days when the basis trade pays out (longs taking shorts' money). Per Ethena's March 2026 governance update ([Reserve Fund March 2026](https://gov.ethenafoundation.com/t/reserve-fund-march-2026-update/775)) the fund stood at **~$61M for a 1.18% coverage ratio** of USDe supply at snapshot (~$5.17B; supply oscillated between ~$5.6B and ~$5.0B through March). The question is: how many days of sustained negative funding does that buy?
{{< formula math="Days_solvent = Fund_size / (|f_neg| · w_basis · Supply)" >}}
- Days_solvent — number of days until the insurance fund is exhausted at the given funding rate (computed)
- Fund_size — insurance fund size in dollars
- f_neg — sustained negative daily funding rate (negative number, e.g. −0.05% = −0.0005)
- w_basis — share of collateral held against an open short (fraction, 0 to 1)
- Supply — total USDe supply in dollars
{{< /formula >}}
Plug in the March 2026 numbers with conservative assumptions — w_basis = 65% (typical allocation during normal markets), a sustained negative funding of −0.05% per day (an unusually adverse but historically observed regime) — and the fund covers roughly:
{{< formula math="Days_solvent ≈ $61M / (0.0005 × 0.65 × $5,170M) ≈ 36 days" >}}{{< /formula >}}
At a less adverse −0.02% per day (closer to the median of negative-funding episodes), coverage extends past 80 days. At a stress of −0.10% per day combined with a leveraged-DeFi unwind that grows redemptions, the fund is exhausted inside three weeks. The 1.18% number is not "enough" or "not enough" in the abstract — it has to be paired with a scenario.
Ethena's published Q1 2026 report acknowledges this directly: the central risk into the rest of 2026 remains "sustained negative funding rates combined with a leveraged DeFi unwind, against a reserve fund sized at 1.18% of TVL." The honesty is part of why the iUSDe and USDtb wrappers exist — they decouple the institutional and federal-rail customers from the basis-trade exposure.
**PIPE dilution and the ENA treasury.** The $890M PIPE comes with an immediate accounting consequence on ENA: $100M of the initial round was paid in discounted ENA tokens. StablecoinX Inc.'s mandate to "pursue a multi-year ENA token treasury strategy" means continued accumulation in treasury, which functionally tightens float and routes protocol revenue toward ENA buyback — the same shape as the **Hyperliquid Assistance Fund** dynamic dissected in [buyback engineering]({{< relref "models/buyback-engineering" >}}). The ENA buyback story is not separate from the StablecoinX story; the wrapper *is* the buyback engine, with public-equity discipline replacing on-chain transparency as the audit mechanism.
## sUSDe APY decomposition calculator
sUSDe APY decomposition and insurance-fund break-even
sUSDe APY (composite)
8.4%
Days of fund coverage at −0.05%/day
36
Break-even funding rate (annual, APY=0)
−2.0%
Stable allocation (residual)
15%
How to read this. Defaults yield ≈8.4% composite — below the protocol's published 9.4%/11.8% trailing headlines, because those numbers reflect periods of elevated funding (basis ≈75%, daily rate ≈0.035%). Push funding negative to see the fund timeline shorten; drop w_basis to 30–40% to model Ethena's rotation into stables during adverse funding.
To convert the 1.18% coverage ratio from an abstract figure into days, run four sustained-negative-funding scenarios at the current 65% basis allocation. The formula is the same as the calculator card:
{{< formula math="Days = (Fund_pct / 100) / (|f_neg|/100 · w_basis/100)" >}}{{< /formula >}}
| Scenario | Funding rate | Days to fund depletion |
|---|---:|---:|
| Mild adverse | −0.02%/day | **91** |
| Median adverse | −0.05%/day | **36** |
| Severe | −0.08%/day | **23** |
| Stress | −0.12%/day | **15** |
Python: reproduce the calculation
```python
import numpy as np
def fund_coverage(fund_pct, w_basis, funding_daily_pct, supply=1.0):
"""Days until the insurance fund is exhausted under sustained negative funding.
fund_pct — insurance fund as % of supply (e.g. 1.18)
w_basis — basis allocation as % (e.g. 65)
funding_daily — sustained daily funding rate, signed % (negative is adverse)
"""
fund = supply * fund_pct / 100
daily_loss = abs(funding_daily_pct) / 100 * (w_basis / 100) * supply
if daily_loss == 0:
return float('inf')
return fund / daily_loss
scenarios = [
("Mild adverse", -0.02),
("Median adverse", -0.05),
("Severe", -0.08),
("Stress", -0.12),
]
for label, f in scenarios:
days = fund_coverage(1.18, 65, f)
print(f"{label:18s} funding {f:>6.2f}%/d → {days:6.1f} days")
```
The simulation makes the design choice visible: the insurance fund is sized for *median-adverse* funding (covering tens of days), not *stress* funding (where the timeline shortens to weeks). This is consistent with Ethena's stated policy of rotating allocation toward stables once funding turns adverse — the fund is a bridge, not a buffer for the worst case. The architectural implication: investors evaluating a "yield-bearing stablecoin" product need to read fund size and rotation policy together, not the headline coverage ratio alone.
## Implementation: how the StablecoinX wrapper is structured
Reading the merger documents and the press releases together, the structure assembles in four moves.
**Move 1 — assemble the operating subsidiary.** StablecoinX Assets Inc. is incorporated as a newly formed infrastructure software and services firm. Its operating mandate after closing: run validators for the Ethena protocol and pursue a multi-year ENA token treasury strategy. This is the entity that actually generates the revenue the public company will report.
**Move 2 — raise the PIPE in two rounds.** The initial $360M (announced 22 July 2025) is structured as $260M cash plus $100M of discounted ENA tokens; anchor investors named at the announcement include the Ethena Foundation ($60M), Dragonfly, Ribbit Capital, Blockchain.com, Pantera, Polychain, and Haun Ventures. The 3 September 2025 follow-on adds $530M for a total of $890M committed, led by traditional-finance names — **Brevan Howard, Susquehanna Crypto, IMC Trading** — alongside new lead **YZi Labs** and repeat crypto-native participants. The composition shift between rounds is itself informative: round 1 reads as a crypto-native PIPE; round 2 reads like a TradFi cross-over book. The PIPE is the real capital raise — by the time of merger close, SPAC trust cash is largely irrelevant after redemptions.
**Move 3 — execute the de-SPAC.** TLGY Acquisition Corp and StablecoinX Assets Inc. both become wholly owned subsidiaries of StablecoinX Inc., the surviving public entity. Class A shares trade on Nasdaq under ticker USDE. Class B shares stay with Ethena Foundation, carrying majority voting power. The 5-year collaboration agreement is the binding mechanism: it specifies what StablecoinX Inc. will do for the protocol (validator operation, treasury accumulation, related services) and what cashflows route to it.
**Move 4 — pair with Anchorage for the federal rail.** In parallel, Anchorage Digital Bank takes responsibility for USDtb, issuing under OCC oversight with reserves dominantly in BUIDL. USDtb is positioned as a GENIUS-compliant federally regulated stablecoin — purpose-built for correspondent banking, settlement, and tokenized cash management at US-supervised institutions. The dual-rail framing is intentional: USDe stays open and yield-bearing under DeFi rails, USDtb stays closed and reserve-backed under federal rails, and both share the Ethena infrastructure stack.
The pattern is replicable. A DeFi protocol with material protocol-fee or basis-trade revenue can apply the same chassis: build an operating subsidiary that captures the cashflow, raise PIPE to seed the treasury, pair with a SPAC for the listing vehicle, retain Class B voting control at the foundation. What is harder to replicate is the dual-rail compliance pairing — that requires a federally chartered partner like Anchorage and a regulator who will treat a wrapped product as a separate issuance.
| Round | Date | Size | Composition | Notable |
|---|---|---|---|---|
| Initial PIPE | 22 Jul 2025 | $360M | $260M cash + $100M discounted ENA | Anchor investors named |
| Follow-on PIPE | 3 Sep 2025 | $530M | Cash (no ENA token component disclosed) | Strategic Advisory Board formed |
| Shareholder vote | 10 Mar 2026 | — | — | TLGY shareholders approve combination |
| Closing | post-vote | — | — | Class A on Nasdaq, ticker USDE |
## Pitfalls — what can break this architecture
The architecture is novel; the failure modes are not. Five worth flagging.
**Pitfall 1 — concentration and venue risk on the basis trade.** USDe's short legs sit on a handful of centralized perpetual exchanges (Binance, Bybit, OKX, Deribit). The 10-11 October 2025 episode on Binance is the cleanest preview: during the $19B liquidation cascade, USDe touched as low as $0.65 on Binance's order book because the venue oracle referenced its own internal trades only. Off-venue, USDe remained overcollateralized (≈$66M buffer) and the redemption rails kept functioning through the event — but the headline price dislocation propagated to a number of derivatives counterparties before the venue reconciled. Off-exchange collateral custody mitigates counterparty risk on the collateral side; the short legs remain venue-dependent, and oracle design at each venue becomes a single-point-of-failure for any leveraged derivative settling against USDe. The 1.18% insurance fund is sized for funding stress, not for venue-failure stress.
**Pitfall 2 — sustained negative funding plus leveraged DeFi unwind.** The composite failure mode the Q1 2026 report names. Negative funding alone is survivable for tens of days at the current fund size; combine it with a leveraged-DeFi unwind that grows redemptions while the protocol is forced to rotate away from the basis trade, and the recovery window collapses. The architectural response — sUSDe holders opt in to the yield and the volatility; USDe holders sit on a non-yielding peg backed by reserves; USDtb holders sit on BUIDL — is exactly the kind of risk segmentation that the dual-track design exists for. The pitfall is assuming sUSDe holders fully understand the rotation they have implicitly agreed to.
**Pitfall 3 — Class A / Class B governance optics.** Public Class A holders do not vote. Ethena Foundation, via Class B, retains majority voting power. Dual-class structures are common in tech listings (Alphabet, Meta, Snap) and have a clear founder-control rationale, but they invite governance critique from index investors, ISS / Glass Lewis advisory shops, and S&P 500 inclusion gatekeepers. For StablecoinX the optics question lands on top of an already novel structure: public investors are exposed to a DeFi-adjacent operating business they cannot control through a corporate vote, while the protocol they fund is governed off-chain by a foundation whose internal voting is itself opaque to them. This is not a fatal flaw — it is a disclosure obligation that recurs in every public filing.
**Pitfall 4 — segment reporting and the DeFi-adjacent revenue puzzle.** StablecoinX Inc. will report under US GAAP and SEC rules. Its revenue arrives in protocol fees, basis-trade income, validator rewards, and ENA price appreciation in treasury. Cleanly segmenting that under standard line items is not trivial: are basis-trade flows realized through the operating subsidiary, or paid as fees by the foundation that operates the protocol? Are validator rewards revenue or token-denominated returns on staked capital? Quarterly reporting will be educative — for the company and for every DeFi protocol contemplating the same wrapper.
**Pitfall 5 — USDtb / USDe brand confusion and regulatory cross-contamination.** USDtb and USDe ride the same brand family, the same operational stack, and the same marketing. But they sit in opposite regulatory worlds: USDtb is federally regulated, no native yield, BUIDL-backed; USDe is DeFi-native, yield-bearing through sUSDe, basis-trade-backed. Any retail user confusion ("aren't they the same thing?") is a compliance risk for the federal side. Any regulatory reading-across ("if USDtb is OCC-supervised, USDe should be too") is a compliance risk for the DeFi side. Anchorage and Ethena need to maintain clean separation of branding, support flows, and disclosure — and the public-equity wrapper makes that separation more, not less, visible.
{{< callout type="warning" title="The architectural caveat" >}}
Dual-track is a *separation* design. It works because USDe-DeFi-rail and USDtb-federal-rail serve different buyers under different rules with different yield profiles. If, under stress, regulators read across rails — treating the federal-rail compliance as evidence that the DeFi rail should be compliant too — the separation collapses. The architecture is durable only as long as the regulator boundary holds.
{{< /callout >}}
## Yield recycling and the third leg
Two threads close the architecture.
**Yield recycling and the ENA buyback.** StablecoinX Inc.'s operating mandate — validator operation plus multi-year ENA treasury accumulation — turns protocol revenue into ENA tightening. The mechanism is the same one we dissected in [buyback engineering]({{< relref "models/buyback-engineering" >}}) for Hyperliquid: protocol fees route to a treasury that buys (or holds, or earns) the native asset, and the public reporting cadence becomes the transparency layer. Where Hyperliquid uses on-chain Assistance Fund flows as the auditable record, StablecoinX uses 10-Q filings. The economic shape is the same; the audit substrate is different. For an investor evaluating ENA tokenomics in 2026, the StablecoinX cashflow is no longer separable from the ENA buy pressure.
**The MiCA leg.** USDe-DeFi-rail, USDtb-federal-rail, StablecoinX-public-equity-wrapper — that is three rails. The fourth, and the one most stablecoin issuers reading this article are actually planning around, is **MiCA in the EU**. The CASP transitional period ends 1 July 2026; any stablecoin serving EU users needs a MiCA-compliant Article 6 whitepaper bundle by then. Ethena has not yet announced a public MiCA bundle, but the architecture is wired for it: a separate EU-licensed entity issuing an EMT or ART, sharing the same family branding, sitting alongside USDtb and USDe under the StablecoinX umbrella. The engineering work for the MiCA leg — Annex I whitepaper, iXBRL filing, cadCAD peg simulation, redemption gate stress test — is dissected in [the MiCA Article 6 stablecoin bundle]({{< relref "models/mica-article-6-stablecoin-bundle" >}}).
The architectural prescription for an issuer reading this in 2026 is clear. If your buyer is a US bank or fintech, you need a federal rail (Anchorage-issued under GENIUS, or equivalent OCC-supervised path). If your buyer is an EU corporate or retail user, you need a MiCA rail (Article 6 EMT, by 1 July 2026). If your buyer is a DeFi-native yield seeker, you need a yield-bearing wrapper that does not pretend to be a regulated stablecoin. If your business model produces sustained protocol revenue and your investors want public-equity exposure, a de-SPAC wrapper over the operating subsidiary is now a tested pattern. Most issuers will need two of these rails; the largest will need all four.
StablecoinX is the first execution of all four at the same operator, and the first to make the architecture visible on a public market. The valuation, the segment reporting, and the regulator response over the next 12 months will determine whether the pattern scales. The architecture itself — collateral plus basis trade plus reserves, split across a DeFi rail and a federal rail, wrapped in a public-equity vehicle with foundation voting control — is now in the ground.
{{< cta title="Designing a multi-rail stablecoin?" text="We help stablecoin issuers structure the engineering bundle behind multi-jurisdiction launches: peg simulation, redemption gate stress test, regulatory rail mapping (US GENIUS, EU MiCA, UAE, HK), and the treasury / public-equity wrapper economics. Two-week scoping engagement." button="Talk to Giants Labs" link="/services/" >}}
---
## HYPE Tokenomics: How Hyperliquid's Fee-Funded Buyback Actually Works
- URL: https://giantslabs.pro/models/hype-tokenomics/
- Section: models
- Date: 2026-04-17
- Last modified: 2026-04-17
- Description: Full breakdown of HYPE tokenomics: allocation, the no-VC airdrop, the Assistance Fund mechanics, daily buyback math, sustainability under volume shocks, and the specific risks that come with the design.
HYPE is the most cited tokenomics reference of 2024–2026 for a reason. A perpetual-futures exchange launched without venture capital, airdropped 31% of supply to users, and then used nearly all trading fees to buy back its own token on the open market — continuously, visibly, on-chain. The combination is rare. Most "revenue buyback" programs in crypto are either funded by treasury rather than real fees, or run on a cadence distant enough from revenue that the link is hard to verify. Hyperliquid's design fuses them in a way that can be audited from public data.
This article is a working breakdown of HYPE — the allocation, the launch, the Assistance Fund, the daily math, what the design actually buys the holder, and what it does not. At the end we situate HYPE in the broader map of buyback mechanisms so it is clear which parts are specific to this project and which are generalizable.
## The Project: What HYPE Is a Token Of
Hyperliquid is a perpetual-futures exchange operating on its own purpose-built chain. The product is narrow by design: orderbook perp trading with low latency and competitive fee structure, recently extended with a spot venue and a custom-markets framework (HIP-3). The exchange runs at scale — daily perp notional in the billions, making it one of the largest non-CEX perp venues and a structural competitor to centralized exchanges on throughput.
The economic model of the business is simple: users pay trading fees on every filled order. Takers pay more than makers—the base taker fee is around 4.5 basis points and the base maker fee around 1.5 basis points, and after volume-tier and staking discounts the blended realized take rate lands near 3 basis points. The exchange does not charge listing fees, does not run a launchpad that rents token issuance, and does not currently monetize data feeds. Trading fees are essentially the whole business.
This matters because HYPE's token design hinges on the fee stream being real, recurring, and structurally linked to the token. If trading fees were a small fraction of a diversified revenue base, the buyback mechanism would be one of many inputs to token value. Because fees are essentially the only input, the buyback structure becomes the token's economic identity.
## Allocation and Launch
HYPE launched on November 29, 2024 with a fixed total supply of 1 billion tokens and a distinctive allocation that broke with the prevailing 2020–2023 venture-led norm.
| Bucket | Share | Mechanism |
|--------|-------|-----------|
| Community airdrop (Genesis) | 31.0% | One-time distribution to pre-launch users, no lock, no cliff |
| Future emissions / community rewards | 38.9% | Reserved for ongoing community distribution over time |
| Core contributors | 23.8% | Team and early contributors, multi-year vesting |
| Hyper Foundation budget | 6.0% | Foundation operations and ecosystem |
| Community grants | 0.3% | Targeted community funding |
| HIP-2 and other programs | ~0.05% | Specific ecosystem mechanisms |
Two structural features are unusual and worth calling out:
**No VC allocation.** There is no seed, strategic, or Series-A tranche sitting in the cap table with staged unlocks. The project was bootstrapped without an outside equity or token sale round. This removes an entire class of future sellers from the supply schedule and simplifies the investor-narrative problem: with no VC bag, there is no "VC unlock cliff" quarter on the horizon.
**Airdrop without unlock schedule.** The 31% Genesis airdrop was distributed to roughly 94,000 wallets at token-generation with no lock, no cliff, no staged release. Recipients could sell on day one. The standard tokenomics playbook argues this creates catastrophic sell pressure; the empirical result was close to the opposite — a substantial fraction of airdrop recipients held or accumulated. The explanation lies in the buyback design and in the participation filter applied to the airdrop (active users rather than farmers), not in a general theorem about airdrops.
**The emissions bucket is the leverage point.** 38.9% reserved for future distribution is a large number. Whether HYPE stays on its current trajectory depends heavily on how this bucket is deployed — the cadence, the recipients, and whether the emissions are covered by buyback flow or outpace it. As of early 2026, public deployment of this bucket has been conservative.
## The Assistance Fund: Mechanics
The core of HYPE's tokenomics is the **Assistance Fund** — a protocol-owned on-chain entity that receives essentially all of the exchange's trading fees and uses them to buy HYPE on the open market. The fund accumulates the purchased HYPE as a balance; it does not burn it immediately. The effect is operationally equivalent to continuous removal of float, because tokens sitting in the protocol-owned fund are not on the active market.
The mechanics that distinguish this design from lookalike programs:
**Fee share is near-complete.** Public data and Hyperliquid disclosures indicate that roughly 97–99% of trading fees flow into the Assistance Fund. This is extreme by industry standard — most exchange-token programs route 10–50% of fees into buyback-equivalents. The remainder covers operational costs and ecosystem incentives. The high allocation is what makes the buyback flow large enough to matter against the float.
**Continuous execution.** Buybacks execute as fees flow, not on a quarterly or monthly schedule. In practice, this produces many small buys per day, spread across trading hours. The pattern is verifiable on-chain: each buy is a visible transaction from the fund's address against HYPE/USDC spot liquidity.
**No discretionary pause.** There is no committee decision to continue or suspend the program. The fee routing is structural. This is the single most important property — a buyback that can be turned off by governance is worth much less than one that cannot, because the market prices in the option to pause.
**On-chain accumulation, not burn.** The purchased HYPE sits in the fund balance rather than going to a null address. This is a meaningful design choice. It preserves optionality for protocol-owned treasury operations (emergency liquidity, insurance payouts in extreme events), at the cost of not producing a permanent supply reduction. The market generally treats the fund balance as "equivalent to burned" because the tokens are removed from float and the fund's withdrawal conditions are highly restricted — but anyone modeling HYPE should be aware of the distinction.
### Fee flow diagram
```text
Taker trade ──────────► Exchange fees
│
▼
Operations + ecosystem (~1–3%)
│
▼ (~97–99%)
Assistance Fund (on-chain)
│
▼
Open-market HYPE buyback (continuous)
│
▼
Fund balance (protocol-owned, not burned)
```
The structure produces a direct, observable link between exchange performance and token pressure. A billion dollars of additional perp volume in a day adds predictable dollar buyback flow a few hours later.
## The Daily Math
Order-of-magnitude numbers matter more here than exact ones, because the inputs move. The band below is deliberately conservative—over mid-2025 to early-2026 Hyperliquid's actual daily perp volume typically ran higher, on the order of $3–10 billion per day (averaging around $7 billion), so these figures illustrate the mechanism at the low end rather than that period's true base case:
- Daily perp notional volume: $1–3 billion
- Blended effective fee (taker-heavy): roughly 2–3 basis points
- Allocation to the Assistance Fund: ~95% (a deliberately conservative figure; the realized fee share runs ~97–99%)
Working through:
| Input | Low scenario | Mid scenario | High scenario |
|-------|--------------|--------------|---------------|
| Daily volume | $1.0B | $2.0B | $3.0B |
| Effective fee | 2.0 bps | 2.5 bps | 3.0 bps |
| Fee flow / day | $200k | $500k | $900k |
| To Assistance Fund (~95%) | $190k | $475k | $855k |
| Annualized buyback ($) | ~$69M | ~$173M | ~$312M |
Against a circulating supply of around 330 million HYPE (as of early 2026—verify on current dashboards) at roughly $15–25 per token:
| Metric | Low | Mid | High |
|--------|-----|-----|------|
| Market cap (at ~$20) | $6.6B | $6.6B | $6.6B |
| Buyback / market cap | ~1.0% | ~2.6% | ~4.7% |
| HYPE bought / year (at ~$20) | ~3.5M | ~8.7M | ~15.6M |
| % circulating / year | ~1.0% | ~2.6% | ~4.7% |
Two observations that frame everything:
**At mid-scenario inputs, HYPE removes ~2.6% of circulating supply per year from the market.** That is inside the "meaningful" band for buyback sustainability—real deflationary pressure, not a cosmetic announcement. Because the inputs above are deliberately conservative, treat this as a lower bound: at the period's actual volumes, independent estimates put annualized buyback closer to ~7% of market cap (as of mid-2026), sitting between this article's high scenario and the ~10% number you occasionally see in HYPE marketing—which generally assumes high-scenario volume persisting.
**The buyback-to-market-cap ratio is the comparable metric.** At ~2.6% annually, HYPE is comparing favorably with most revenue-share programs in crypto. But this number is sensitive in both directions — to volume, and to price. A price increase reduces the denominator of "tokens bought per dollar," and a volume decrease reduces the numerator of "dollars flowing in." Under stress, both move against the program at once.
All numbers above should be cross-checked against current dashboards — DefiLlama for exchange volume, Dune for Assistance Fund flows — before being used in any decision. The values here are illustrative of the design, not an investment thesis on today's state.
## Stress-Test the Design
The math above is the base case. The interesting question is what happens to the buyback under a volume downturn — the single biggest risk to any fee-funded program. The interactive calculator below lets you move daily volume, effective fee, fund allocation, HYPE price, and a volume-shock multiplier, and shows the resulting supply-removal rate in real time.
{{< cta title="HYPE Buyback Sustainability Calculator" text="Interactive model: daily volume, fee rate, fund allocation, price, and a volume-shock slider — with a real-time sustainability verdict. Try −30% and −50% shocks to see how the program degrades. Full formulas with variable definitions are on the calculator page." button="Open calculator" link="/tools/calc-hype-buyback/" >}}
## Why the Design Is Coherent
The individual pieces of HYPE's tokenomics are not novel in isolation. Fee-funded buybacks exist elsewhere, no-VC launches have been tried before, and large airdrops have been common since 2020. What makes HYPE's design coherent is how the pieces reinforce each other.
**The buyback solves the airdrop's sell-pressure problem.** A 31% airdrop with no lock should, by standard tokenomics reasoning, produce immediate and crushing sell pressure. It did not, for two reasons. First, the airdrop was filtered heavily toward active users (traders, not farmers), who already had engagement with the product and a reason to hold. Second, the continuous buyback gave those users a credible thesis — "the exchange is generating real fees and those fees are converting to demand for my token" — which converted potential sellers into holders.
**The no-VC structure makes the narrative clean.** When a token has no VC bag with staged unlocks, the investor pitch collapses from "will the VC cliff crash the price" to "does the exchange generate enough volume." This is a simpler question for the market to price, and it means HYPE's price action is driven by product metrics rather than unlock-schedule anxiety.
**The continuous execution disarms the "turn it off" risk.** The single biggest discount applied to exchange tokens is the assumption that the buyback program can be suspended. HYPE's structural, non-discretionary fee routing removes this discount. The market can verify on-chain that the fund is receiving fees and executing buys in real time, not trust a quarterly report.
The result is a token whose value argument is unusually concrete: current exchange volume translates with known efficiency into current token buyback, with minimal governance overhead, minimal insider capture, and full on-chain auditability.
## HYPE-Specific Risks
The design has specific failure modes that are worth naming before anyone uses HYPE as a template. None of these invalidate the model; they are the questions the design does not fully answer.
### Concentration of circulating supply
Despite the community-heavy allocation narrative, post-airdrop on-chain data shows meaningful concentration in a small number of top wallets. This is partly natural (large early traders received proportionally larger airdrops, plus teams and foundation hold undisclosed amounts through identifiable addresses), but the Gini coefficient of the circulating float is higher than the marketing number of "94,000 airdrop recipients" suggests. A coordinated exit from even a subset of the top 50 wallets would consume weeks of buyback flow. This is a known risk for any exchange token at this maturity level, not unique to HYPE — but it does cap the degree to which the buyback can be treated as a price floor.
### Assistance Fund governance
The Assistance Fund holds meaningful value on-chain. The design treats the fund balance as effectively burned for the purposes of float calculation, which requires confidence that the fund will not be deployed to sell HYPE under future governance decisions. As of early 2026, the withdrawal conditions on the fund are narrow but not fully formalized. A stronger design would publish explicit rules for when (if ever) tokens in the fund can be redeployed, with hard limits that cannot be voted away. Without this, a tail-risk scenario exists in which fund balance is used for purposes other than permanent float removal.
### HIP-3 and product-surface expansion
The clean buyback math assumes a single fee-generating product: perp futures on Hyperliquid's core venue. The expansion to spot markets and then to HIP-3 custom markets introduces complexity. Each new market has its own fee profile, its own volume dynamics, and its own operational cost structure. The question is whether fees from HIP-3 markets flow into the Assistance Fund on the same ~97–99% basis, or whether a differentiated allocation is applied. If differentiated, the design is no longer a single-product Archetype A (see below) and starts to resemble a multi-product aggregated program, with different sustainability characteristics.
### The emissions bucket
38.9% of supply reserved for future community emissions is a large discretionary lever. If those emissions are deployed at a rate greater than buyback can absorb, the net float effect is positive (float grows), even while the buyback is operating at full capacity. The program's narrative does not fully answer how emissions and buyback are balanced at scale. Any sustainability analysis of HYPE that ignores the emissions schedule is incomplete.
### Volume dependency
The calculator above makes this concrete. At $2B daily volume the buyback is meaningful; at $500M daily volume it is marginal. Hyperliquid operates in one of the most competitive segments in crypto — perp DEX — and faces pressure from Binance, Bybit, OKX, and other centralized exchanges that can match fee structures and outspend on listings. A sustained 50% reduction in volume from competitive pressure would reposition the design from "meaningful" to "marginal" on the sustainability map.
## What HYPE Copies Well
Several elements of HYPE's design are directly portable to other projects considering a similar tokenomics structure.
**Near-total fee allocation to buyback.** Most exchange tokens route 10–50% of fees to buyback and keep the rest as company revenue. The 97–99% allocation is the single design choice that makes HYPE's buyback scale matter. For projects considering this, the trade-off is explicit: you give up direct cash extraction in exchange for token-economy strength.
**Non-discretionary execution.** Programming fee routing into the protocol contract rather than into a treasury that a multisig controls. This is mechanical rather than conceptual — but the concept is that the market should not be able to price in a "will they pause" option.
**On-chain fund visibility.** Anyone can read the Assistance Fund's address and verify that fees are arriving and buys are executing. This is the property that lets the market trust the design without trusting the operator.
**No-VC if the project can afford it.** The absence of staged unlocks removes the largest source of supply overhang that most tokens struggle with. This is not available to most projects — bootstrapping an exchange to the scale required for fee-funded buyback without venture funding is genuinely hard. But where the structure allows, the narrative benefit is real.
**Airdrop to active users, not to farmers.** The 31% airdrop's success was partly a function of who received it. An airdrop gated on real product usage retains more value than one gated on point-farming behavior.
## What HYPE Does Not Copy
Other elements of HYPE are tied specifically to its product and should not be lifted naively.
**Fund accumulation rather than burn.** HYPE's choice to accumulate rather than burn is defensible in its context (protocol-owned treasury has optionality value) but depends on trust in the withdrawal conditions. Projects without credible governance should probably burn outright — the optionality is not worth the trust requirement they cannot meet.
**31% airdrop share.** This is a very large airdrop, feasible because Hyperliquid did not need VC funding to reach launch. Projects that did take venture capital cannot replicate this without diluting their cap table in ways that break the investor case.
**Single-product simplicity.** HYPE's math is clean because fees come from essentially one product. A project with a more diversified revenue base should probably run an aggregated archetype (see below), not a continuous per-fee redirect.
**Aggressive fee allocation (97–99%).** This works for Hyperliquid because the project has low headcount and operational costs, and no external investors demanding distributions. Most projects have cost structures that require a meaningfully larger operational allocation — 50–70% of fees kept for operations is more typical and does not make the resulting buyback cosmetic, it just makes it smaller.
## Positioning HYPE in the Buyback Landscape
To make the design portable, it helps to situate HYPE within the broader map of buyback mechanisms. There are five structurally different archetypes, distinguished by source of funds, cadence, and the core stakeholder served:
| Archetype | Source of funds | Cadence | Reference |
|-----------|-----------------|---------|-----------|
| A · Fee-funded perpetual | Product fees | Continuous | **HYPE** |
| B · Multi-product quarterly auto-burn | Aggregated revenue | Quarterly, formulaic | BNB (BEP-95) |
| C · Protocol-revenue smart burn | Surplus (fees − costs) | Triggered by surplus | MKR (Smart Burn Engine) |
| D · Discretionary treasury buyback | Treasury / announced tranches | Event-driven | GMX, dYdX |
| E · Insider-aligned (kill-case) | Issuer balance sheet | Narrative-driven | FTT |
**HYPE is Archetype A.** It is the cleanest live implementation of the pattern: fees → open-market purchase → protocol-owned accumulation, continuous and non-discretionary. The design is appropriate for a single-product platform with material fee flow and no significant operational overhead.
**BNB (Archetype B) is different.** BNB's quarterly burn draws from aggregated revenue across exchange, launchpad, card, and chain products. The aggregation smooths volatility — a weak quarter in any single product does not materially change burn flow. This is structurally appropriate for diversified ecosystems; single-product projects that imitate the quarterly cadence without the revenue diversification get cosmetic results.
**MKR (Archetype C) is different.** MKR's Smart Burn Engine triggers on protocol surplus — fees minus operating costs and risk buffers. When Maker's revenue is strong, burn accelerates; when weak, it pauses to protect solvency. This is appropriate for protocols with real operating costs and balance-sheet exposure. HYPE's design does not protect solvency this way because Hyperliquid's cost structure is small relative to fee flow.
**GMX and dYdX (Archetype D) are different.** Discretionary treasury buybacks announce discrete tranches, funded by accumulated treasury rather than by automatic fee routing. This trades structural strength for governance flexibility. HYPE deliberately avoids this archetype because discretionary execution is exactly the "pause risk" the design is built to eliminate.
**FTT (Archetype E) is the warning.** The mechanics on paper looked similar to a fee-funded buyback. The failure was not in the buyback design — it was in the combination of extreme concentration in related-party wallets, use of the token as collateral on the issuer's own venue, and the reflexive loop this created. The HYPE design does not have this failure mode because the Assistance Fund is protocol-owned rather than held in related-party wallets, and HYPE is not used as collateral on Hyperliquid in a way that creates the same reflexive dynamic. But the concentration risk named above is the one feature where HYPE still shares a weak structural similarity with Archetype E, and it is the one risk the project should address most visibly.
## Pitfalls When Imitating HYPE
A short checklist for projects considering a HYPE-style tokenomics:
{{< checklist title="Common errors in HYPE-style designs" type="curve" >}}
Imitating the fee allocation without the revenue base. 95% of $10,000 daily fees is $9,500 daily — cosmetic at any serious float. Project the buyback flow at realistic volume before committing to the structure.
Treasury-funded buyback dressed as fee-funded. If the buyback dollars come from the treasury (which was funded by a token sale), the program is cycling capital rather than converting new revenue. The narrative effect decays as the market understands the source.
Discretionary fund deployment. Building an Assistance-Fund-equivalent but giving a multisig unrestricted withdrawal rights. This converts the archetype back to discretionary treasury (D) and loses the core property.
Buyback alongside heavy unlock. Launching a fee-funded buyback concurrent with a VC unlock cliff. Net float may still grow despite the buyback headline.
Ignoring emissions. Running buyback against one supply bucket while another (community emissions, staking rewards) outpaces it. The headline number is buyback gross; the relevant number is net of all emission.
Over-promising sustainability. Marketing buyback rates computed at peak volume as if they were the base case. Use mid-scenario inputs, or preferably range them.
Collateralizing the token on the issuer's own venue. This is the Archetype E trap. Even if designed innocently, it creates the structural fragility that killed FTT.
{{< /checklist >}}
## Regulatory and Tax Notes
Buyback-and-burn (or buyback-and-accumulate) is structurally more defensible than direct revenue share under most securities frameworks, because no holder receives a cash distribution. The Howey-style analysis becomes harder to argue when value accrues through price rather than through pro-rata payment. For a deeper breakdown of the dividends-vs-buyback choice including tax treatment and regulatory posture, see the [dividends vs buyback article]({{< relref "models/utility-models" >}}).
For holders, the HYPE model produces no tax event until sale, which is a durable advantage over revenue-share programs that produce taxable income at each distribution. This partially explains why mature exchange tokens tend to gravitate toward buyback models over time even when they started with revenue-share language.
HYPE's specific regulatory exposure is different from the archetype's in general. Hyperliquid operates without a traditional registered entity in most jurisdictions, and the HYPE token itself has not been the subject of a major enforcement action as of early 2026. This is not an endorsement of the design's regulatory durability — it is an observation about the current state, which could change.
## Takeaway
HYPE is worth studying because it is a working demonstration that fee-funded buyback can produce meaningful token demand at scale, without VC, without complex governance, without lock-up gimmicks. The sustainability math holds at current volumes and degrades predictably under volume stress. The design has specific risks — concentration, fund governance, emissions, product expansion — that should be tracked rather than hand-waved.
For projects designing similar tokenomics, the portable lessons are: route near-total fees to buyback, execute non-discretionarily, accumulate on-chain with visible governance, and verify at realistic volume that the resulting supply removal is above 1% annually. The lessons that are not portable are the ones tied to Hyperliquid's specific position: the no-VC structure, the 31% airdrop, and the single-product simplicity. See the [allocation article]({{< relref "models/allocation" >}}) for how the supply side interacts with this design, and [demand models]({{< relref "models/demand-models" >}}) for how buyback fits alongside the other four sources of token demand.
{{< cta title="Designing a token with fee-funded buyback?" text="We'll model the sustainability envelope at realistic volumes, structure the allocation to match, and stress-test the design before launch." button="Get in touch" link="/quote/" >}}
---
## Market Making in Tokenomics: Role, Models, and Cost
- URL: https://giantslabs.pro/models/market-making/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How market makers affect tokenomics: spreads, depth, inventory risk, loan + call option, MM KPIs. When you need an MM and when you don't.
A project completes TGE, the token is listed — and the price swings 20% from a single $5,000 sell. Spread is 3%, the order book is empty, investors are nervous. This isn't a tokenomics problem — it's the absence of a market maker. **Market making** is a critical but often overlooked element of tokenomic architecture that determines how "alive" a token is after launch.
## What Is Market Making
A **market maker** (MM) is a professional market participant who simultaneously places buy (bid) and sell (ask) orders for a token, providing liquidity and tightening the spread. An MM doesn't invest in the project — they provide a pricing service.
{{< callout title="MM in tokenomics context" >}}
A market maker is a [stakeholder]({{< relref "basics/stakeholders" >}}) with their own economic interests. Their motivation is earning from the spread and contract terms, not token price appreciation. When designing tokenomics, the MM is included in the stakeholder matrix alongside investors, the team, and community.
{{< /callout >}}
## Why a Project Needs a Market Maker
| Task | Without MM | With MM |
|---|---|---|
| Spread | 2–5% (up to 10%+ on low-tier exchanges) | 0.1–0.5% |
| Order book depth | $0–$10K | $50K–$500K per side |
| Slippage ($50K) | 5–20% | 0.3–1% |
| Investor perception | "Dead" token | Liquid market |
| CEX listing | Difficult | Easier (most major CEXs expect or require MMs) |
### Three MM Functions
1. **Providing liquidity.** The MM continuously maintains a two-sided quote: bid and ask. This allows any participant to buy or sell the token at any time without waiting for a counterparty.
2. **Price discovery.** The MM "transfers" price between venues (cross-exchange arbitrage), ensuring a unified token price across different CEXs and DEXs.
3. **Volatility absorption.** When a large seller dumps tokens, the MM absorbs them into the order book, smoothing the decline. This isn't manipulation — it's shock absorption.
## Contract Models with Market Makers
### 1. Retainer (Fee-Based)
The MM receives a fixed monthly fee for providing liquidity.
| Parameter | Typical value |
|---|---|
| Monthly fee | $5K–$50K (from ~$5K for a single exchange to $50K+ for multi-venue coverage) |
| Contract duration | 6–12 months |
| MM obligations | Spread < X%, depth > Y$, uptime > 95% |
| Tokens from project | Not required (or minimal) |
**When it fits:** projects with budget that want controlled costs and transparent terms.
### 2. Loan + Call Option
The MM receives tokens **as a loan** plus an option to buy at a fixed price (strike). This is the most common and most dangerous model.
{{< formula math="Cost = Tokens × max(0, P_market − P_strike)" >}}
- Cost — real option cost for the project
- Tokens — number of tokens transferred to the MM
- P_market — token market price
- P_strike — option strike price
{{< /formula >}}
| Parameter | Typical value |
|---|---|
| Loan volume | 2–5% of total supply (note: even 3% of total supply can be 30%+ of circulating supply at TGE) |
| Duration | 12–24 months |
| Option strike price | At or below TGE price |
| Upfront payment | $0–$50K |
**Example.** A project gives the MM 3% of supply (3M tokens out of 100M), strike = $0.50. After one year, price = $2.00:
{{< formula math="Cost = 3M × ($2.00 − $0.50) = $4.5M" >}}
- The project effectively "paid" $4.5M — the MM exercised the option at $0.50 and sells at $2.00
- Supply dilution: 3M / 100M = 3% of total supply transferred to the MM
{{< /formula >}}
{{< callout type="warning" title="The hidden cost of loan + call option" >}}
The "loan + call option" model looks free at the start — the MM takes no cash, only tokens. But if the project succeeds, the option cost can reach **millions of dollars**. At strike $0.50 and market price $5.00, the MM earns $4.50 per token. Always calculate option value using scenario analysis (bear/base/bull). Black-Scholes provides a baseline but systematically underprices tail risk in crypto due to non-lognormal returns and extreme volatility.
{{< /callout >}}
### 3. Hybrid Model
Retainer + a small token volume without an option (or with a strike well above market price).
| Parameter | Typical value |
|---|---|
| Monthly fee | $5K–$25K |
| Token volume | 0.5–1% of supply |
| Option | No option or strike = 1.5–3x TGE price (varies widely) |
| Obligations | Strict KPIs |
**When it fits:** optimal balance of cost and alignment. The MM is motivated by price growth (holds tokens) but the project doesn't lose millions on an option.
### Model Comparison
| Criterion | Retainer | Loan + Call Option | Hybrid |
|---|---|---|---|
| Upfront cost | High ($15–50K/mo) | Low ($0–50K) | Medium ($5–25K/mo) |
| Cost on success | Fixed | Very high (option) | Moderate |
| Dilution | None | 1–5% of supply | 0.5–1% |
| Interest alignment | Weak (MM indifferent to price) | Skewed toward MM | Balanced |
| Transparency | High | Low (hidden terms) | Medium |
## Key Parameters and KPIs
### What to Control in the Contract
| KPI | Definition | Target value |
|---|---|---|
| Spread | Bid-ask difference / P_mid | < 1% (ideally < 0.3%) |
| Depth | Order volume per side within 2% of mid | > $50K (ideally > $200K) |
| Uptime | % of time with active quote | > 95% |
| Trading volume | MM's share of total volume | 60–80% is normal early on; if consistently > 90% with no organic growth, investigate for wash trading. Cross-check with unique address count |
| Max spread under stress | Spread when market drops > 10% | < 3% |
### Spread Cost Formula for Traders
{{< formula math="Spread_cost = Trade × Spread / 2" >}}
- Spread_cost — cost of spread for a single trade
- Trade_size — trade amount ($)
- Spread — current bid-ask spread
- Divided by 2 because a trader pays half the spread on a market order
{{< /formula >}}
**Example.** A $100K purchase at 0.5% spread:
{{< formula math="Spread_cost = $100K × 0.005 / 2 = $250" >}}
- Example: spread cost $250 per trade at 0.5% spread
{{< /formula >}}
At 3% spread (without MM) the same trade would cost $1,500 — a 6x difference.
## Inventory Risk: How MMs Manage Position
The MM earns from the spread but takes on **inventory risk**: if the token price falls while the MM has accumulated a position — they lose money.
{{< formula math="PnL_mm = Spread_income − Inventory_loss − Hedge_cost" >}}
- PnL_mm — market maker's profit/loss
- Spread_income — income from spreads
- Inventory_loss — loss from price changes on held tokens
- Hedge_cost — hedging costs
{{< /formula >}}
### How MMs Manage Risk
| Method | Mechanism | Limitation |
|---|---|---|
| Asymmetric quotes | Shift bid/ask when position accumulates | Worsens spread for traders |
| Cross-exchange hedging | Sell on CEX-2 when buying on CEX-1 | Requires liquidity on multiple venues |
| Position limits | Maximum holding volume | Reduces depth during stress |
| On-chain hedging | Options, perpetuals on DEX | Only available for large-cap tokens |
{{< callout title="Why this matters for tokenomists" >}}
If the token is highly volatile and no derivatives market exists, the MM can't hedge inventory risk. Result: wide spread, shallow order book, or refusal to work. Tokenomists should account for volatility when designing unlock schedules (vesting) and choose listing venues with derivatives.
{{< /callout >}}
## AMM vs CEX Market Making
| Criterion | CEX MM (order book) | AMM (DEX) |
|---|---|---|
| Who provides liquidity | Professional MM | Any LP |
| Cost to project | $5K–$50K/mo + tokens | Initial pool ($50K–$200K early-stage, $200K–$1M+ established) + LP incentives |
| Quoting flexibility | Full (MM algorithm) | Constrained by formula (x·y=k) |
| Capital efficiency | High | Low (CPMM) / medium (V3) |
| Impermanent loss | No (risk on MM) | Yes (risk on LP) |
| Transparency | Low (OTC contract) | Full (on-chain) |
| Entry barrier | High (contract required) | Low (permissionless) |
### When to Choose What
```text
Liquidity budget > $15K/mo?
├── Yes → CEX listing planned?
│ ├── Yes → CEX MM (required by most CEXs)
│ │ └── + AMM on DEX for the long tail
│ └── No → Hybrid: AMM (primary) + DEX market maker
└── No → AMM on DEX
└── LP incentives from allocation (5–15% of supply)
└── Details → [AMM article](../amm/)
```
## When an MM Isn't Needed
A market maker isn't a mandatory expense. In some cases, one is unnecessary or even harmful:
{{< checklist title="When you can skip an MM" type="check" >}}
Token trades only on DEX: an AMM pool provides liquidity automatically; no professional MM needed
Organic volume > $500K/day: enough arbitrageurs and organic traders to maintain the spread
NFTs / illiquid assets: market making an NFT collection makes no sense — each token is unique
Budget < $10K/mo: a cheap MM is worse than none — it creates an illusion of liquidity that vanishes under stress
{{< /checklist >}}
## Impact on Tokenomic Architecture
Market making isn't a separate line item — it's an integral part of tokenomics:
### Allocation
In [allocation]({{< relref "models/allocation" >}}), the "liquidity" category typically accounts for 5–20% of total supply (10–15% is most common in 2024–2026 practice). This pool funds:
- The initial AMM pool on DEX
- Tokens for the market maker (loan or grant)
- LP incentives (liquidity mining)
### Vesting and Unlocks
Every large unlock (cliff) creates sell pressure. Liquidity depth must withstand this pressure without a price crash:
{{< formula math="Pressure = Unlocked × Sell_rate × P" >}}
- Pressure — maximum sell pressure ($)
- Unlocked — number of unlocked tokens
- Sell_rate — percentage sold immediately (20–80%)
- P — token price
{{< /formula >}}
If 10M tokens unlock at $1.00 and 50% sell within a week — that's $5M of pressure. At $200K depth on the bid side, this will crash the price. Solution: extend vesting, notify the MM in advance, increase liquidity ahead of major unlocks.
### Stakeholders
The MM enters the [stakeholder matrix]({{< relref "basics/stakeholders" >}}) as a participant with conflicts of interest:
| MM's interest | Project's interest | Conflict |
|---|---|---|
| Maximize spread income | Minimize spread for users | Direct |
| Exercise option on price increase | Minimize dilution | Direct |
| Minimize inventory risk | Deep order book even under stress | Moderate |
| Short contract | Long-term stability | Moderate |
## Common Mistakes
{{< checklist title="Market making pitfalls" type="check" >}}
Not calculating the full cost of loan + call option: the "free" MM can cost 3–5% of market cap. Use scenario analysis to estimate real costs
One MM on one exchange: if the MM goes offline — liquidity vanishes. Minimum: AMM on DEX (always-on base liquidity) + MM on CEX
No KPIs in the contract: without metrics (spread, depth, uptime) you can't evaluate the MM's work. Require daily reporting
Wash trading as "volume": some MMs create artificial volume. This is fraud that leads to delisting and regulatory risk. Monitor the ratio of unique addresses to volume
Ignoring unlocks: MMs aren't obligated to absorb cliff-unlock pressure. Warn the MM 2–4 weeks in advance and ensure additional liquidity
MM without hedging on a volatile token: if no derivatives market exists for hedging, the MM will widen spreads or refuse. Plan listing on venues with perpetuals
{{< /checklist >}}
## Preparation Checklist
{{< checklist title="Before signing an MM contract" type="step" >}}
Define budget: fiat ($15–50K/mo) or tokens (1–5% of supply)
Choose contract model: retainer, loan + call option, or hybrid
Calculate option value under 3 price scenarios (bear, base, bull)
Set KPIs: spread, depth, uptime, max spread under stress
Agree on reporting: daily/weekly, format, metrics
Include termination rights if KPIs fail for > 2 weeks
Verify base liquidity on DEX (insurance against MM downtime)
Notify MM of vesting schedule and major unlocks
{{< /checklist >}}
{{< cta title="Need a market making strategy?" text="We'll help you choose the right contract model, calculate the true cost of options, and set KPIs that protect your project." button="Get in touch" link="/quote/" >}}
---
## Market Models: Order Book, AMM, and Intent-Based Trading
- URL: https://giantslabs.pro/models/market-models/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Three market models for token liquidity: order book, AMM, and intent-based trading. Mechanism comparison, slippage formulas, and decision tree.
In the [five supply models overview]({{< relref "models/token-supply-models" >}}), the market model is described as the "fifth" — the secondary circulation model. But it's this model that determines whether a token can survive after launch. [Allocation]({{< relref "models/allocation" >}}) creates tokens, the [reward model]({{< relref "models/reward-emission" >}}) distributes them — and the market model provides **pricing and liquidity**. Without it, a token is just a number on the blockchain with no way to exchange it.
Three fundamentally different mechanisms exist: **order book** (orderbook), **automated market maker** (AMM), and **intent-based** trading. Each solves the liquidity problem differently, with different trade-offs. This article compares them from the tokenomist's perspective — the person designing the system, not just trading in it.
## Order Book
The classic mechanism inherited from traditional finance. Two types of orders — buy (bid) and sell (ask) — are arranged by price. A trade executes when bid ≥ ask.
### How It Works
{{< formula math="P_mid = (P_bid + P_ask) / 2" >}}
- P_mid — mid price (computed, order-book concept)
- P_bid — best buy order
- P_ask — best sell order
- The difference (P_ask − P_bid) is the spread — the primary liquidity metric
- Note: mid-price is specific to order books; AMMs derive a single instantaneous price from the pool curve (see AMM section)
{{< /formula >}}
| Characteristic | Value |
|---|---|
| Pricing | Determined by participant orders |
| Liquidity | Provided by market makers |
| Capital efficiency | High — liquidity concentrated around the price |
| Minimum volume | Requires significant trading volume |
| Where used | CEX (Binance, OKX), some DEXs (dYdX v4, Hyperliquid, Injective Helix) |
### The Role of Market Makers
In an order book, liquidity doesn't appear automatically. It's provided by **market makers** (MMs) — professional participants who simultaneously place buy and sell orders.
A market maker earns from the spread and receives compensation from the project:
| Parameter | Typical value | Purpose |
|---|---|---|
| Spread | 0.1–0.5% | MM revenue per trade |
| Order book depth | $50K–$500K per side | Resilience to large trades |
| Project compensation | 1–5% of total supply + fees (typical band; the spread depends on MM tier, CEX tier, and contract length — top-tier MMs on tier-1 exchanges cluster at 3–5%) | Attracting MMs at launch |
| Contract term | 6–12 months | Minimum partnership horizon |
{{< callout type="warning" title="A trap for projects" >}}
Some market makers operate on a "loan + call option" model: they receive tokens as a loan and hold an option to buy at a fixed price. If the token price rises — the MM exercises the option and sells at a profit. If it falls — they return the tokens. This model benefits the MM but creates sell pressure on the token price. Always calculate the true cost of market-making services.
{{< /callout >}}
### When to Choose an Order Book
- The project plans a CEX listing (centralized exchange)
- Budget available for a market maker ($50K–$300K per contract)
- Expected trading volume > $100K/day
- Maximum capital efficiency is required
## Automated Market Maker (AMM)
AMM replaces the order book with a **mathematical formula**. Liquidity is stored in a pool — a smart contract holding reserves of two (or more) tokens. The price is determined automatically with every trade.
A detailed breakdown of AMM mechanics, formulas, and types is in the [dedicated article]({{< relref "models/amm" >}}). Here — key characteristics from the supply model perspective.
### Base Formula
{{< formula math="x × y = k" >}}
- Constant Product Market Maker (Uniswap V2)
- x, y — reserves of two tokens in the pool
- k — constant, preserved on each swap (excluding the 0.3% fee)
{{< /formula >}}
### Key Parameters for a Tokenomist
| Parameter | What it determines | Typical value |
|---|---|---|
| Initial liquidity | Pool depth at launch | $50K–$1M per pair |
| Pool fee | LP revenue, trader cost | 0.05%–1% |
| AMM type | Pricing curve shape | CPMM, StableSwap, CL |
| Liquidity range | Concentrated (V3) or full-range | Depends on volatility |
### Slippage — The Key Metric
**Slippage** — the difference between the expected and actual trade price. It depends on the trade size relative to pool depth.
{{< formula math="Slippage = Δx / (x + Δx)" >}}
- Δx — trade size in token X
- x — reserve of X in the pool
- At Δx = 1% of x, slippage is ~1%
- At Δx = 10% of x, slippage is ~9.1%
{{< /formula >}}
| Trade size (% of pool) | Slippage (CPMM) | Slippage (StableSwap) |
|---|---|---|
| 0.1% | 0.10% | ~0.01% |
| 1% | 0.99% | ~0.10% |
| 5% | 4.76% | ~0.50% |
| 10% | 9.09% | ~1.00% |
### When to Choose AMM
- The project launches on-chain (not on a CEX)
- No budget for a professional market maker
- Liquidity needed from day one (permissionless)
- The community can serve as liquidity providers
## Intent-Based Trading
The newest model, where the user doesn't place an order directly but **declares an intent**: "I want to swap 1 ETH for the maximum amount of USDC." Specialized participants — **solvers** — compete to fulfill this intent.
### How It Works
1. **User creates an intent:** signs a message describing the desired trade (what they give, what they want, constraints)
2. **Solvers find the best path:** analyze order books, AMM pools, OTC, and their own liquidity
3. **Solver auction:** solvers compete for the right to execute the intent, offering the best price
4. **Execution:** the winning solver executes the trade, the user receives tokens
{{< formula math="P_user ≥ P_amm − Solver_fee" >}}
- P_user — price for the user (computed)
- P_amm — AMM price
- Solver_fee — solver's fee
- In practice, solvers often deliver a price better than AMM by aggregating liquidity
{{< /formula >}}
### Advantages
| Advantage | How it works |
|---|---|
| Better price | Solvers aggregate liquidity from multiple sources |
| MEV protection | Intent is executed atomically, no public transaction before execution |
| Cross-chain | Solver can use liquidity from different networks |
| Solver pays gas | User signs an intent, not a transaction |
### Current Implementations
| Protocol | Solver model | Volume (2025) |
|---|---|---|
| CoW Protocol | Batch auctions | ~$5–12B/month (DefiLlama; peaks >$10B in late 2025) |
| UniswapX | Dutch auction of solvers | ~$1–2B/month |
| 1inch Fusion (same-chain + Fusion+ cross-chain) | Limit orders via solvers | Fusion+ ≈ $0.4–0.6B/year cross-chain (Messari 2025); combined figure varies — check the 1inch public dashboard |
| Across Protocol* | Cross-chain intents | ~$1.5B/month (~$50M/day; $28–34B cumulative by early 2026) |
*Across is a cross-chain bridge, not a spot swap venue — its throughput represents cross-chain transfers rather than in-venue swaps, so it is not directly comparable to CoW/UniswapX/1inch.
{{< callout title="Why this matters for tokenomists" >}}
The intent-based model changes the market maker's role: instead of passively placing orders — active competition for execution. For a project, this means the possibility of obtaining liquidity without direct MM costs, but requires integration with a solver network.
{{< /callout >}}
## Comparing the Three Models
| Criterion | Order Book | AMM | Intent-Based |
|---|---|---|---|
| Pricing | Participant orders | Mathematical formula | Solver auction |
| Liquidity | Market makers | LP pools | Aggregation of all sources |
| Startup costs | $50K–$300K (MM contract) | $50K–$1M (initial pool) | Solver network integration |
| Capital efficiency | High | Low (CPMM) / Medium (V3) | High |
| MEV protection | Low (frontrunning) | Low (sandwich) | High |
| Cross-chain | Via bridges | No (single-chain) | Native |
| LP entry barrier | High (professionals) | Low (anyone) | Medium (solvers) |
| Technology maturity | Decades | Since 2018 | Since 2021–2022 |
## Slippage and Liquidity Cost Calculator
Compare trade costs: order book vs AMM vs intent-based at different volumes and liquidity levels.
Market Models Calculator
4 parameters, three-model comparison, best option highlighted
## How to Choose a Model
The choice of market model depends on the project's stage, budget, and target audience.
### Decision Tree
1. **Planning a CEX listing?** Yes — order book (the CEX provides the infrastructure). No — go to step 2.
2. **Budget allows professional range management?** Yes — AMM with concentrated liquidity (Uniswap V3): concentrated liquidity rewards active management and larger LP positions, so it pays off when the treasury can afford to rebalance ranges as volatility shifts. No — AMM with basic CPMM (set-and-forget, lower capital efficiency but no active management required).
3. **Need cross-chain from day one?** Yes — integrate with intent-based protocols. No — start with AMM, add intent later.
4. **High volume of small trades?** Yes — AMM (less slippage on small volumes). No (large trades) — order book or intent.
### Combining Models
In practice, mature projects use all three:
| Project stage | Primary model | Complement |
|---|---|---|
| Launch (months 1–3) | AMM on DEX | — |
| Growth (months 3–12) | AMM + CEX listing | Order book on 1–2 exchanges |
| Maturity (12+ months) | Order book on multiple CEXs | AMM for the long tail, intent for aggregation |
## Common Mistakes
{{< checklist title="Market model pitfalls" type="check" >}}
Launching AMM with insufficient liquidity: a $500 trade into a small pool with ~$5K on each side causes roughly 9% price impact (Δx/(x+Δx) = 500/5500 ≈ 9.1%). Minimum — $100K, optimal — $500K+
Expensive market maker contract without understanding terms: the "loan + call option" model can cost the project 3–5% of total supply. Always calculate the full cost including the option
Ignoring impermanent loss: LPs in AMM lose when volatility increases. If the entire pool is funded by the team — losses hit the treasury. LP incentives or hedging are necessary
Single liquidity source: if all volume is on one AMM pool — one large trade breaks the price. Distribute liquidity across multiple sources
Launching intent-based without volume: solvers go where there's order flow. Without baseline volume on AMM/order book, intent-based trading won't take off
{{< /checklist >}}
## Impact on Tokenomics
The market model isn't just "where to trade." It affects the entire tokenomic architecture:
- **Allocation:** a "liquidity" pool (5–15% of total supply) is needed to seed the AMM or compensate the market maker
- **Vesting:** large unlocks create sell pressure — liquidity depth must absorb them without crashing the price
- **[Stakeholders]({{< relref "basics/stakeholders" >}}):** market makers and liquidity providers are separate groups with their own interests in the [stakeholder matrix]({{< relref "basics/stakeholders" >}})
- **Utilization mechanisms:** [staking]({{< relref "models/staking" >}}) reduces circulating supply, improving liquidity for remaining tokens
{{< cta title="Need a market model for your token?" text="We design liquidity architecture for DeFi protocols — AMM parameters, market maker terms, and intent-based mechanics. 85+ projects in our portfolio." button="Get in touch" link="/quote/" >}}
---
## Mechanism Design in Tokenomics
- URL: https://giantslabs.pro/models/mechanism-design/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How to integrate supply and demand models into a unified incentive system. Game theory foundations, design cases, and common mistakes.
Mechanism design is not another supply or demand model. It is the discipline that answers: **how do you connect all tokenomics components so that participants behave as desired — without coercion**.
## What Is Mechanism Design
**Mechanism design** is a branch of game theory that studies the creation of interaction rules under which each participant's rational behavior leads to an optimal outcome for the system as a whole.
In tokenomics, mechanism design solves the following problem:
{{< callout title="The core problem" >}}
How do you design the rules (emission, burning, staking, fees, rewards, penalties) so that users, validators, investors, and developers **voluntarily** act in the protocol's interest?
{{< /callout >}}
{{< callout title="Design ≠ Simulation" >}}
**Mechanism design** is creating the rules of the game. **Simulation** is testing those rules through modeling. Design answers "how should it work"; simulation answers "will it work." These are different stages, and confusing them is a common mistake.
{{< /callout >}}
### Relationship to Game Theory
Classical game theory analyzes existing games: what strategies will players choose? Mechanism design works in reverse: **what rules must be created so that players choose the desired strategies?**
## Three Elements of a Mechanism
Every tokenomics mechanism consists of three elements:
### 1. Incentives
What a participant receives for desired behavior.
| Incentive type | Description | Example |
|----------------|-------------|---------|
| **Monetary** | Direct financial gain | Validator rewards, LP fees |
| **Access** | Right to use a feature | Staking to participate in governance |
| **Reputation** | Social capital | Delegate rating, trust score |
| **Discount** | Reduced cost | 0.5% fee instead of 1% when paying with token |
### 2. Penalties
What a participant loses for undesired behavior.
| Penalty type | Description | Example |
|--------------|-------------|---------|
| **Slashing** | Partial stake confiscation | Validator lost 10% for double-signing |
| **Reputation** | Rating reduction | Delegate lost delegations after poor voting |
| **Exclusion** | Removal from the system | Ban for spam proposals in governance |
| **Dilution** | Share erosion | Token unvesting upon condition violation |
### 3. Information
What information participants have and how it affects decisions.
| Aspect | Description | Example |
|--------|-------------|---------|
| **Transparency** | What everyone sees | On-chain data: balances, votes, transactions |
| **Asymmetry** | Who knows more | Insiders knowing about an upcoming upgrade |
| **Commitments** | What can't be undone | Tokens locked for 4 years in a ve-model |
| **Signals** | What actions reveal about intent | Large token purchase = confidence signal |
## Design Principles
### Incentive Compatibility
A mechanism is **incentive-compatible** if honest behavior yields more benefit for each participant than dishonest behavior. This is the key property — it means the system doesn't need "policing," it works through participant rationality.
{{< formula math="U_honest(i) ≥ U_cheat(i) ∀i" >}}
- U_honest — benefit from honest behavior of participant i
- U_cheat — benefit from any alternative (dishonest) strategy
- The condition must hold for every participant and every possible deviation — not just the most obvious cheat
{{< /formula >}}
**Example: PoS staking.** A validator stakes at least 32 ETH (up to 2,048 ETH since Pectra/EIP-7251). Honest validation earns ~3–4% annually. An attack attempt (double-signing) leads to slashing — losing part or all of the stake. As long as the return from honest work exceeds the potential profit from an attack minus slashing losses, the system is incentive-compatible.
### Coalition Resistance
A mechanism must be resistant not only to individual but also to collective dishonest behavior. A group of participants should not be able to collude to extract value at the expense of others.
{{< callout type="warning" title="Security threshold" >}}
In PoS blockchains, the critical threshold is 33% of stake for a single coalition (can halt finalization) and 66%+ to control finalization (finalize arbitrary blocks). When designing staking mechanisms, decentralization must be incentivized: diminishing returns as share grows, caps on maximum stake per validator, geographic diversification.
{{< /callout >}}
### MEV Resistance
MEV (Maximal Extractable Value, originally "Miner Extractable Value" before The Merge) is the profit validators or sequencers can extract by reordering transactions. A well-designed mechanism minimizes MEV:
- **Batch auctions** — processing transactions in batches, not one by one
- **Encrypted mempools** — hiding transaction contents until block inclusion
- **Fair ordering** — protocols that enforce transaction ordering rules (Chainlink Fair Sequencing Service / FSS)
## Case 1: Rating System
### Problem
Design a rating system for a platform where users rate each other. The rating must reflect actual quality, be resistant to manipulation, and incentivize honest evaluation.
### Naive Solution
Simple average of scores: Rating = Σ(scores) / N. Problem: easy to manipulate through fake accounts, no incentive to rate honestly.
### Solution Through Mechanism Design
1. **Staking to rate.** To submit a rating, you must stake tokens. If your rating is close to the median, your stake is returned. If it deviates significantly, part of your stake is burned.
{{< formula math="Reward = Stake × max(0, 1 − |Score − Median| / Range)" >}}
- The closer the rating to the median, the larger the reward
- max(0, ...) ensures the reward never goes negative — extreme outliers lose their stake but don't owe more
- Inspired by Schelling point mechanisms (SchellingCoin used binary inclusion — reward if within 25th–75th percentile, nothing otherwise). This formula uses a proportional penalty curve: the further from the median, the greater the loss — a smoother variant
{{< /formula >}}
2. **Weight system.** A rater's weight is proportional to their historical accuracy (how often their ratings fell within the median range).
3. **Sybil protection.** Cost of attack through fake accounts: N accounts × stake × probability of loss. With sufficient stake, the attack becomes unprofitable.
### Sports Analogy
Rating systems in tennis (Elo) and chess use a similar principle: ratings change based on results, not subjective assessments. The difference in tokenomics is the absence of an objective result, hence the use of the Schelling point mechanism (coordination on a focal point).
## Case 2: Variable-APR Staking
### Problem
Design staking where APR automatically regulates the ratio of staked to free tokens.
### The Issue
Fixed APR creates imbalance:
- Too high → everyone stakes, no liquidity for trading
- Too low → nobody stakes, no network security
### Solution: Dynamic APR
{{< formula math="APR = min(APR_max, Base × (Target_% / Staked_%))" >}}
- Base — base rate (e.g., 5%)
- Target_% — target staking share (e.g., 50%)
- Stake_% — current share of staked tokens
- APR_max — upper cap to prevent runaway rates when Stake_% → 0 (e.g., 50%)
{{< /formula >}}
System behavior:
| Staking share | APR at Base=5%, Target=50% | Effect |
|---------------|----------------------------|--------|
| 25% (below target) | 10% | High APR attracts stakers |
| 50% (target) | 5% | Equilibrium |
| 75% (above target) | 3.3% | Low APR motivates unstaking |
The system self-regulates: deviation from the target creates an economic incentive to return to equilibrium. Validators don't need to coordinate — each rationally responds to the current APR.
### Real-World Example
**Ethereum PoS** uses a similar formula: the yield per unit of staked ETH is inversely proportional to √(total_staked). The more ETH staked, the lower the APR per validator — a natural balancing mechanism.
## Case 3: Undercollateralized Lending
### Problem
Create an undercollateralized lending system in DeFi where traditional collateral is absent.
### The Classical Problem
DeFi lending requires over-collateralization (>100% LTV). This is capital-inefficient and excludes borrowers without crypto assets.
### Solution Through Mechanism Design
**Priority lending mechanism:**
1. **Borrower rating.** The borrower stakes protocol tokens and builds credit history by repaying small loans. Each successful repayment increases the limit.
{{< formula math="Limit(n) = Base × (1 + History_score(n)) × K_stake" >}}
- History_score(n) — credit score that grows with each successful repayment (n = loan number)
- K_stake — multiplier from stake size
- Base — initial limit for a new borrower
{{< /formula >}}
2. **Social collateral.** A group of borrowers forms a mutual guarantee pool. If one defaults, the rest lose part of their stake. Analogous to microfinance groups (Grameen Bank).
3. **Penalties and reputation.** Loan default leads to:
- Loss of entire stake (slashing)
- Credit history reset
- Public on-chain flag (on-chain reputation)
4. **Lender incentives.** Higher interest rates compensate for default risk. Part of the interest goes into an insurance pool.
### Mechanism Balance
## Common Mistakes
### 1. Incentivizing Metrics Instead of Outcomes
**Goodhart's Law:** when a measure becomes a target, it ceases to be a good measure.
A protocol incentivizes TVL (Total Value Locked) → participants create recursive positions (deposit → borrow → deposit again), inflating TVL without real liquidity. The metric grows, but actual utility does not.
{{< callout type="warning" title="How to avoid" >}}
Incentivize the **outcome**, not the intermediate metric. Instead of TVL — trading volume (actual usage). Instead of user count — retention (return rate). Instead of staking — validation (useful work).
{{< /callout >}}
### 2. Ignoring Edge Cases
The mechanism works under normal conditions but breaks under extreme ones:
- **Extreme volatility** — liquidations cascade, oracles lag
- **Whale exit** — a large holder sells their stake, APR spikes, others exit too
- **Zero activity** — no trades, no fees, no rewards, no staking → death spiral
### 3. Misaligned Time Horizons
Incentives target short-term behavior while the protocol's goals are long-term. Example: liquidity mining attracts "mercenary capital" that leaves when rewards drop.
**Solution:** ve-models align time horizons — a 4-year lock ties the holder's interests to the protocol's long-term success.
### 4. Absent Penalties
A system with no punishment for harmful behavior will be exploited. If voting is free — expect spam. If staking has no slashing — validators may not verify transactions. Penalties don't need to be harsh, but they must exist.
## Design Framework
### Step 1: Identify Stakeholders
Who participates in the system? What are their goals?
| Stakeholder | Goal | Actions | Potential abuse |
|-------------|------|---------|-----------------|
| User | Cheap service | Buys token, pays | Spam, sybil attacks |
| Validator | Staking income | Stakes, validates | Lazy validation, downtime |
| LP | Fee income | Provides liquidity | Mercenary capital, manipulation |
| Investor | Price appreciation | Buys and holds | Dump after unlock |
| Team | Protocol development | Building, governance | Insider trading |
### Step 2: Design Feedback Loops
Every mechanism must contain a **feedback loop** that corrects behavior:
### Step 3: Verify Robustness
{{< checklist type="check" >}}
Incentive compatibility: is honest behavior more profitable than dishonest for every participant?
Coalition resistance: can a group of participants collude to extract value at others' expense?
Edge cases: does the mechanism work at 10x growth and 90% price decline?
Death spirals: is there a mechanism to halt negative loops?
Time horizons: are incentives aligned in duration?
MEV resistance: does transaction reordering create extractable value?
{{< /checklist >}}
### Step 4: Simulation
After designing the mechanism — simulate:
1. **Sensitivity analysis** — how do parameters affect the outcome?
2. **Monte Carlo method** — 1,000 random scenarios, what percentage leads to undesirable outcomes?
3. **Agent-based modeling** — simulating behavior of rational and irrational agents
{{< cta title="Need mechanism design?" text="Design → simulation → audit → launch → monitoring → adjustment. Skipping a step increases exploit probability. We engineer incentive systems and run simulations." button="Get in touch" link="/quote/" >}}
---
## MiCA Article 6 stablecoin bundle: whitepaper, iXBRL, cadCAD peg simulation, redemption gate
- URL: https://giantslabs.pro/models/mica-article-6-stablecoin-bundle/
- Section: models
- Date: 2026-05-11
- Last modified: 2026-05-11
- Description: How to ship a MiCA Article 6 stablecoin whitepaper as a coherent engineering deliverable: iXBRL Annex I structure, cadCAD peg simulation, redemption gate stress test. Built for the 1 July 2026 CASP cliff for EMT issuers.
A MiCA Article 6 stablecoin whitepaper is no longer a PDF — it is a regulated, machine-readable filing. Four artifacts must ship together: the whitepaper itself, an iXBRL filing against the ESMA taxonomy, a peg simulation backing every quantitative claim, and a redemption gate stress test proving the redemption right holds under load. This article walks through how the bundle composes, what math underpins it, and what working code looks like.
## Why compliance is engineering, not paperwork
The reflex when a regulator publishes new disclosure rules is to treat the result as a form-filling exercise. For MiCA Article 6 that reflex is wrong, and the deadlines make it expensive.
The CASP transitional period ends on 1 July 2026. Any stablecoin issuer serving EU users — directly or via passporting — needs a MiCA-compliant whitepaper on file. Legacy whitepapers for tokens admitted to trading before 30 December 2024 must be replaced by 31 December 2027, per [ESMA Q&A 2654](https://www.esma.europa.eu/publications-data/questions-answers/2654) (17 October 2025). And since 23 December 2025, [Commission Implementing Regulation (EU) 2024/2984](https://eur-lex.europa.eu/eli/reg_impl/2024/2984/oj/eng) requires that the whitepaper itself be filed in Inline XBRL against the ESMA XBRL taxonomy (published 5 August 2025).
Three things the market still gets wrong:
1. Annex I is treated as a checklist of fields rather than a contract whose claims must be testable.
2. Peg-stability assertions are written before any simulation backs them.
3. Redemption gate parameters are copied from legal precedent rather than derived from queue-depth math.
{{< callout type="info" title="The MiCA stablecoin calendar" >}}
**5 August 2025** — ESMA publishes the XBRL taxonomy for crypto-asset whitepapers.
**23 December 2025** — Commission Implementing Regulation (EU) 2024/2984 (ITS on iXBRL) enters into force; whitepapers must be filed as a single XHTML file with iXBRL tagging.
**17 October 2025** — ESMA Q&A 2654 clarifies the legacy whitepaper regime and the obligations of trading-platform operators for tokens admitted to trading before 30 December 2024.
**28 November 2025** — ESMA Statement on iXBRL/XBRL implementation.
**17 April 2026** — ESMA Statement on the end of transitional periods.
**1 July 2026** — CASP transitional period ends.
**31 December 2027** — last day to replace legacy whitepapers for pre-MiCA tokens.
{{< /callout >}}
If the whitepaper is a PDF written by counsel, the iXBRL filing becomes a post-hoc translation exercise. If "redemption within 24h under normal conditions" has no simulation behind it, the claim is a liability the moment redemption pressure rises. Compliance is engineering because the supervisor will run automated checks against the iXBRL fields and against on-chain data — the document is queryable.
For a foundational overview of stablecoin mechanics that this article builds on, see [stablecoin tokenomics]({{< relref "models/stablecoin-tokenomics" >}}). What follows assumes a fiat-backed EMT (electronic money token) under MiCA Title III, since that is the configuration most issuers preparing for the 1 July 2026 cliff are targeting.
## The four-artifact bundle
Article 6 plus Annex I plus the iXBRL ITS plus the redemption-rights rules of Article 49 read as a single engineering brief once the prose is stripped away. There are four artifacts, designed together.
**Artifact 1 — the whitepaper.** Annex I sets out the disclosure plan: identity of offeror and issuer, characteristics of the crypto-asset, rights and obligations attached to the token, underlying technology, related risks. For EMTs, Annex II adds reserve composition, governance, redemption mechanism, and adverse events disclosure. The prose has to be precise enough that every parametric claim—peg accuracy, redemption time, reserve ratio—maps to a number the iXBRL filing carries.
**Artifact 2 — the iXBRL filing.** The whitepaper is filed as a single XHTML file with Inline XBRL tagging against the ESMA crypto-asset taxonomy. The supervisor's tooling parses out structured fields—issuer LEI, token classification (EMT / ART / other), reserve composition, redemption terms, peg mechanism type—and can run automated comparisons against periodic reports and on-chain telemetry. This is what changes the disclosure economics: the filing is queryable.
**Artifact 3 — the cadCAD peg simulation.** Any quantitative claim about peg behavior in the whitepaper—"peg deviation under normal conditions stays within ±0.1%", "redemption queue clears within N days under a 5σ stress event"—needs a simulation that produces it. [cadCAD]({{< relref "models/agent-based-modeling" >}}) is the de facto open-source framework for this; the simulation defines state variables (reserve composition, supply, peg price, queue depth), policies (redemption pressure, reserve mark-to-market), and partial state update blocks (peg deviation, queue dynamics, solvency check).
**Artifact 4 — the redemption gate stress test.** Article 49 of MiCA gives EMT holders the right to redeem at par at any time. A redemption gate—the Q_max ceiling and the T_max response time the issuer commits to—isn't a free parameter. It has to be calibrated against the reserve composition's liquid horizon, the stress scenarios the peg simulation covers, and the operational capacity to fulfill. The whitepaper cites the gate; the simulation justifies it; the iXBRL filing exposes it.
These four ship as a single deliverable because every line of the whitepaper either references the simulation, exposes a field that the iXBRL filing tags, or commits to a stress-tested redemption parameter. Tokenomics.com sells MiCA disclosure documentation as a standalone product; CADLabs publishes open-source cadCAD models; legal firms hand over the whitepaper text. We have not seen a public competitor that bundles all four artifacts behind a single source of truth — which is exactly the gap the supervisor's automated checks will surface.
## Peg and queue dynamics
The peg of a fiat-backed EMT is enforced on the primary market by the redemption right: any holder can present 1 EMT and receive €1 from the issuer. Secondary-market deviations are what the supervisor cares about. They are driven by three forces.
{{< formula math="Δp = −(delay_discount + liquidity_premium + solvency_concern)" >}}
- Δp — secondary-market peg deviation (% from par)
- delay_discount — discount the market applies for redemption queue delay, ≈ days_to_clear · r_riskfree / 365
- liquidity_premium — premium paid by buyers in secondary venues when queue depth signals constrained primary-market flow
- solvency_concern — risk premium if reserve excess (reserve − supply) shrinks below comfort thresholds
{{< /formula >}}
The reserve composition determines the issuer's capacity to absorb redemption flow without disturbing the market price. A defensible non-significant EMT reserve—roughly 60% short-duration Treasury bills, 35% cash at qualifying custodians, 5% reverse repo—sits comfortably above the EBA RTS minimum 30% bank-deposit share for non-significant EMTs (significant EMTs face a 60% bank-deposit floor and need a correspondingly higher cash share). The liquid horizon is one to three business days for the cash bucket and up to a week for the T-bill bucket after deducting expected mark-to-market.
{{< formula math="V_reserve(t) = Σᵢ Pᵢ(t) · Nᵢ(t)" >}}
- V_reserve(t) — reserve value at time t (€)
- Pᵢ(t) — market price of asset class i at time t
- Nᵢ(t) — quantity of asset class i held at time t (changes as redemptions are fulfilled)
- Composition shares wᵢ = (Pᵢ·Nᵢ) / V_reserve drift with redemption flow; the disclosure must specify a tolerance band
{{< /formula >}}
Redemption pressure on a given day is modeled as a stochastic process. A baseline day sees R₀ ≈ 1–2% of supply requested; a stress day spikes that several multiples higher.
{{< formula math="Q(t+1) = max(0, Q(t) + R(t) − G)" >}}
- Q(t) — outstanding redemption queue depth at time t (% of supply)
- R(t) — redemption requests received at time t (% of supply)
- G — gate ceiling: maximum redemption fulfillment per 24h (% of supply)
{{< /formula >}}
When R(t) > G, the queue grows. When R(t) < G, the queue drains at rate G − R(t). The gate's role is exactly to convert spike redemption pressure into a fulfillable schedule without forcing the reserve to dump T-bills into a stressed market.
{{< formula math="Solvency(t) = V_reserve(t) − Supply(t) · p_target" >}}
- Solvency(t) — excess of reserve over outstanding supply at par (€)
- Supply(t) — outstanding EMT supply at time t
- p_target — peg target (€1.00 for EUR-denominated EMT)
{{< /formula >}}
The 1:1 par-value backing for EMTs is set by MiCA Title IV Article 49 (issuance and redeemability at par), with reserve-investment rules in Article 54 (cross-referencing Article 38 for eligible assets) and the bank-deposit floor set by EBA RTS under Article 36(4); Solvency(t) ≥ 0 must hold at all times. In practice the issuer keeps an explicit excess (typically 3–5% of supply) to absorb mark-to-market moves on the T-bill portfolio without breaching the 100% line.
{{< formula math="Δp_max = max over t of |Δp(t)|; T_recovery = min t* such that |Δp(t)| < 0.1% for all t > t*" >}}
- Δp_max — maximum peg deviation observed during the stress event (%)
- T_recovery — number of days from spike to return inside the ±0.1% tolerance band
{{< /formula >}}
The peg-stability claim in the whitepaper is now an objective function: under the simulated stress events, Δp_max and T_recovery must stay within whatever the issuer commits to. The gate ceiling G and the reserve composition (wᵢ) are the design levers.
## Implementation
The implementation section ships two pieces: the cadCAD simulation that backs every peg-stability claim, and the iXBRL Annex I structure that exposes the design to the supervisor. The third piece — an interactive redemption gate stress test — sits in its own section below so it picks up its own TOC anchor, since most readers come here for it.
### cadCAD peg simulation
The first deliverable is a parametric peg simulation across three scenarios. Reserve composition is fixed at 60% T-bills, 35% cash at qualifying custodians, 5% reverse repo, with a 5% initial excess over supply — the minimal-bank-deposit configuration that clears the EBA RTS 30% floor for a non-significant EUR-denominated EMT in 2026.
| Metric | Base | Stress | Black-swan |
|---|---:|---:|---:|
| Spike R₁ | 2%/day | 12% on day 1 | 25% on day 1 |
| Gate ceiling G | 5%/day | 5%/day | 5%/day |
| Mark-to-market shock | 0% | 0% | −3% on T-bills |
| Peak queue depth | 0.0% | 7.0% | 20.0% |
| Days to clear queue | <1 | 4 | 8 |
| Solvency margin | +5.00% | +5.00% | +3.20% |
| Δp_max (peg deviation) | ≈0% | −0.40% | −1.10% |
| Recovery time | <1 day | 9 days | 13 days |
The base scenario is uneventful: gate ceiling sits above ordinary daily flow, the queue never accumulates, and the secondary market reflects effectively no deviation. The stress scenario — 6× normal spike, no reserve repricing — pushes peg deviation under 0.5% with a 4-day clearance. The black-swan combines a 12.5× spike with a 3% duration shock on the T-bill portfolio (consistent with a roughly 600 bp parallel yield move on a 6-month duration book); peg deviation reaches roughly ±1.1% for two to three days, the solvency margin compresses from +5.0% to +3.2%, and the system recovers within two weeks.
These are the numbers that go into the Annex I disclosure. The whitepaper can credibly state "secondary-market peg deviation stays inside ±0.5% under a 6× redemption spike and within ±1.2% under a 12.5× spike with a 3% reserve mark-to-market shock, with full redemption fulfillment within 8 days" because the simulation produces those numbers.
cadCAD configuration (Python)
```python
# MiCA EMT peg simulation — cadCAD-style configuration
# State: reserve composition, supply, peg price, queue depth, day counter
# Policies: redemption pressure, reserve mark-to-market
# PSUBs: queue update, peg deviation, solvency check
from cadCAD.configuration import Experiment
from cadCAD.configuration.utils import config_sim
import numpy as np
# ---- Initial state ----
# Composition clears EBA RTS Article 36 bank-deposit floor (≥30% for non-significant EMTs).
initial_state = {
"supply": 1_000_000_000.0, # outstanding EMT supply (€)
"reserve_tbills": 0.60 * 1_050_000_000.0,
"reserve_cash": 0.35 * 1_050_000_000.0,
"reserve_repo": 0.05 * 1_050_000_000.0,
"queue_depth": 0.0, # outstanding redemption queue (€)
"peg_price": 1.0, # secondary-market price
"day": 0,
}
# ---- Scenario parameters ----
scenarios = {
"base": {"spike_pct": 0.02, "gate_pct": 0.05, "normal_pct": 0.02, "mtm_shock": 0.0},
"stress": {"spike_pct": 0.12, "gate_pct": 0.05, "normal_pct": 0.02, "mtm_shock": 0.0},
"black_swan": {"spike_pct": 0.25, "gate_pct": 0.05, "normal_pct": 0.02, "mtm_shock": -0.03},
}
# ---- Policies ----
def p_redemption(params, step, sH, s):
"""Daily redemption pressure: spike on day 1, normal otherwise."""
if s["day"] == 1:
R = params["spike_pct"] * s["supply"]
else:
R = params["normal_pct"] * s["supply"]
return {"R": R}
def p_reserve_mtm(params, step, sH, s):
"""One-shot mark-to-market shock on T-bill portfolio at day 1."""
if s["day"] == 1:
return {"mtm_loss_tbills": s["reserve_tbills"] * params["mtm_shock"]}
return {"mtm_loss_tbills": 0.0}
# ---- PSUBs ----
def s_queue(params, step, sH, s, _input):
"""Q(t+1) = max(0, Q(t) + R(t) − G·supply)"""
R = _input["R"]
G_amt = params["gate_pct"] * s["supply"]
q_new = max(0.0, s["queue_depth"] + R - G_amt)
return ("queue_depth", q_new)
def s_reserve_cash(params, step, sH, s, _input):
"""Liquidity waterfall: drain cash first to fulfill redemptions."""
G_amt = params["gate_pct"] * s["supply"]
fulfilled = min(s["queue_depth"] + _input["R"], G_amt)
drain_cash = min(fulfilled, s["reserve_cash"])
return ("reserve_cash", s["reserve_cash"] - drain_cash)
def s_reserve_tbills(params, step, sH, s, _input):
"""T-bills absorb whatever cash cannot fund, plus the one-shot MtM loss."""
G_amt = params["gate_pct"] * s["supply"]
fulfilled = min(s["queue_depth"] + _input["R"], G_amt)
drain_cash = min(fulfilled, s["reserve_cash"])
drain_tbills = fulfilled - drain_cash
return ("reserve_tbills", s["reserve_tbills"] - drain_tbills - _input["mtm_loss_tbills"])
def s_supply(params, step, sH, s, _input):
"""Supply decreases by fulfilled redemptions."""
G_amt = params["gate_pct"] * s["supply"]
fulfilled = min(s["queue_depth"] + _input["R"], G_amt)
return ("supply", s["supply"] - fulfilled)
def s_peg(params, step, sH, s, _input):
"""Secondary-market peg: delay discount + liquidity premium + solvency concern."""
queue_pct = s["queue_depth"] / s["supply"] if s["supply"] > 0 else 0
days_to_clear = queue_pct / max(params["gate_pct"] - params["normal_pct"], 1e-9)
delay_discount = days_to_clear * 0.045 / 365
liquidity_prem = 0.05 * queue_pct
reserve_total = s["reserve_tbills"] + s["reserve_cash"] + s["reserve_repo"]
margin_pct = (reserve_total - s["supply"]) / s["supply"]
if margin_pct >= 0.03: solv = 0.0
elif margin_pct >= 0.01: solv = 0.003
elif margin_pct >= 0: solv = 0.01
else: solv = 0.025
return ("peg_price", 1.0 - (delay_discount + liquidity_prem + solv))
def s_day(params, step, sH, s, _input):
return ("day", s["day"] + 1)
# ---- Partial State Update Block ----
psubs = [{
"policies": {"redemption": p_redemption, "mtm": p_reserve_mtm},
"variables": {
"queue_depth": s_queue,
"reserve_cash": s_reserve_cash,
"reserve_tbills": s_reserve_tbills,
"supply": s_supply,
"peg_price": s_peg,
"day": s_day,
},
}]
# ---- Run experiment ----
sim_config = config_sim({"T": range(30), "N": 1, "M": scenarios})
exp = Experiment()
exp.append_configs(initial_state=initial_state,
partial_state_update_blocks=psubs,
sim_configs=sim_config)
```
A production setup runs each scenario as a Monte Carlo cohort with redemption pressure drawn from a fat-tailed distribution and mark-to-market shocks correlated with macro yield moves. See [tokenomics simulations]({{< relref "models/simulations" >}}) for the sensitivity / scenarios / Monte Carlo / ABM ladder this fits into.
The conclusion that goes into the whitepaper and gets tagged in the iXBRL filing is the summary table. The supervisor sees a reproducible parametric claim: under these three scenarios, with these reserve weights and gate parameters, peg deviation and recovery time fall inside these bounds.
### iXBRL Annex I structure
The iXBRL filing is the bridge between the prose disclosure and the supervisor's tooling. Each field below is tagged against the ESMA crypto-asset taxonomy and carried through the XHTML container.
| Annex I block | Key iXBRL field | What the engineering bundle supplies |
|---|---|---|
| A. Information about the offeror or person seeking admission | issuer LEI, registered address, management | LEI is a hard requirement; no engineering input but must be live before filing |
| B. Information about the issuer (if different) | issuer LEI, ownership, governance | governance design from the whitepaper—Article 6(1)(b) requires the issuer entity to be identifiable |
| C. Information about the operator of the trading platform | operator LEI, listing venues | if self-listed or via specific platform, identified per ESMA Q&A 2654 |
| D. Information about the crypto-asset | token classification (EMT / ART / other), issuance type | EMT classification routes the filing into Title III obligations |
| E. Information on the offer to the public | offer size, jurisdictions, subscription mechanism | supply parameters from the tokenomic design |
| F. Information about the crypto-asset's rights and obligations | redemption right, redemption mechanism, fees | redemption gate parameters (Q_max, T_max) from the stress test |
| G. Information on the underlying technology | blockchain, smart contract addresses, consensus | technology stack, audit references |
| H. Information on risks | peg stability, reserve concentration, custody, technology | peg simulation outputs feed the peg-stability risk section directly |
| Annex II (EMT-specific) | reserve composition, custodian list, governance of reserves | wᵢ weights, custodian LEIs, segregation arrangements—maps 1:1 to the cadCAD model state |
| Annex II — adverse events | de-peg events, suspension of redemption procedures, recovery plan | gate activation criteria from the stress test; recovery plan from the simulation's T_recovery |
The leverage here is upstream design. If the cadCAD simulation is written first, the Annex II reserve composition fields are populated from the same data structure that drives the simulation. The peg-stability assertions in Annex I.H reference exact Δp_max and T_recovery values from the simulation runs. The redemption mechanism description in Annex I.F cites the gate ceiling G that the stress test certified. The result is a filing where the legal prose and the engineering artifacts share a single source of truth.
When the supervisor's tooling parses the iXBRL file, it can run automated checks against periodic reserve reports filed under MiCA Article 36 and against on-chain telemetry on redemption fulfillment time. If the whitepaper claims redemption within 5 business days under stress and a public dashboard shows a 9-day fulfillment median, the gap is now an audit finding the issuer has to explain. The flip side is that a well-built bundle survives this scrutiny: the simulation predicted the gap, the filing disclosed it, and the gate parameters reflect the actual reserve liquidity.
## Redemption gate stress test
The interactive calculator below reproduces the cadCAD simulation logic. Move the sliders to set redemption pressure, gate ceiling, and reserve shock, and watch peg deviation and recovery time respond. The chart traces queue depth over time after the spike day.
MiCA EMT redemption gate stress test
Peak queue depth
7.0%
Days to clear
4
Δp_max
−0.40%
Solvency margin
+5.0%
Redemption queue depth after spike (30 days)
The queue accumulates when daily redemption pressure exceeds the gate ceiling and drains at rate G − R₀. The dashed line shows the gate ceiling for reference.
How to read this. The default settings reproduce the stress scenario from the table above (6× spike, 5%/day gate, no reserve shock). Move the spike slider toward 25% and the mark-to-market shock toward −3% to reproduce the black-swan scenario; you will see the queue peak above 15%, days-to-clear cross 7, and Δp_max drop toward −1.1%. Drop the gate ceiling below the normal daily rate and the queue never clears — an obvious design failure the supervisor will flag.
The point of the inline version is reproducibility: a counterparty's risk team can validate the gate parameters in five minutes without rebuilding the model. A production stress test runs each cell as a Monte Carlo cohort.
## Five mistakes we see in MiCA submissions
The bundle described above is not how most issuers approach the filing. Five failure modes recur in submissions our team has reviewed across UAE, Lithuanian, and French entity setups.
**Pitfall 1 — Annex I treated as a checklist.** The whitepaper text is written by counsel who fills each Annex I field with the minimum compliant prose. There is no underlying engineering brief, so the iXBRL filing becomes a translation exercise: structured fields are populated by reading the prose, not the other way round. The supervisor's automated checks then surface inconsistencies between the prose, the iXBRL tags, and the periodic reserve reports — because the three were never produced from a single source of truth.
**Pitfall 2 — peg-stability claims without simulation.** The whitepaper asserts "the peg is maintained through full backing and on-demand redemption", and Annex I Section H states that peg deviation risk is "low under normal market conditions". Neither statement is parametric. When redemption pressure spikes — a scenario several EMT issuers stress-tested in late 2025 — the issuer has no quantitative baseline to compare against, and the disclosure looks marketing-grade rather than engineering-grade.
**Pitfall 3 — redemption gate with legal-only parameters.** The redemption mechanism section commits to "fulfillment within 5 business days" because that is what counsel suggested as conservative. The gate ceiling is never reconciled with the reserve composition's liquid horizon. Under a real stress event the issuer either misses the disclosed timeline or dumps T-bills into a stressed market to keep it — both outcomes are worse than disclosing a defensible 8-day fulfillment time backed by the stress test.
**Pitfall 4 — iXBRL as a post-hoc conversion.** The whitepaper PDF is delivered first; iXBRL tagging is contracted to a third party two weeks before the filing deadline. The tagging team interprets the prose, and gaps surface — Annex II reserve composition fields lack supporting numbers, peg mechanism type does not map cleanly to the taxonomy enumeration, redemption gate parameters appear only in a footnote. The result is either a delayed filing or one that exposes the issuer to interpretation risk for years.
**Pitfall 5 — stale reserve composition disclosure.** The Annex II reserve disclosure is a snapshot, but the reserve composition shifts continuously as redemptions occur and maturing T-bills are rolled. If the issuer's periodic reporting under Article 36 diverges from the whitepaper's stated composition by more than the disclosed tolerance, the supervisor has a documented inconsistency. The fix is to design the disclosure as a band (acceptable composition range) rather than a point, with the stress test confirming peg stability across the entire band.
{{< callout type="warning" title="The pattern across all five" >}}
Each pitfall is the same mistake under a different surface: the four artifacts get produced sequentially by different teams without a shared data structure. The fix in every case is to design the bundle upstream — the simulation produces numbers, the numbers populate Annex II, the prose references the numbers, the iXBRL filing tags them. One workflow, one source of truth.
{{< /callout >}}
## Compliance-as-design
The iXBRL filing is the structural change. A pre-MiCA whitepaper was a PDF a supervisor read once during approval; a MiCA whitepaper is a machine-readable contract checked continuously against periodic reports and on-chain data. Every parametric claim becomes a tracking metric. The engineering brief has to anticipate this.
The implication for design ordering is sharp. The cadCAD simulation comes first; it produces the numbers. The Annex II reserve composition and the redemption gate parameters come from the simulation. The whitepaper text is written against those numbers. The iXBRL tagging is performed in the same workflow, against the same data structures. The four artifacts share state.
For UAE- and CIS-resident founders planning a MiCA passport, the cross-jurisdiction angle is the lever. A Lithuanian or French entity holds the EMI authorization that triggers MiCA EMT status under Article 48; the operational stack (treasury, custody, governance) can sit closer to home under a VARA framework. The bundle stays the same — only the legal wrapper differs.
The periodic monitoring stream completes the picture. Under MiCA Article 36 the issuer files periodic reserve reports; the supervisor compares them against the iXBRL whitepaper's stated composition band. A redemption pressure event triggers an obligation to disclose; the issuer's monitoring stack has to detect it before the supervisor's tooling does. This is recurring engineering work — telemetry pipes, automated reserve audits, a live cadCAD scenario refresh — not a one-shot filing.
{{< checklist title="MiCA Article 6 bundle — deliverables checklist" type="check" >}}
Whitepaper prose — Annex I + Annex II for EMT, every parametric claim sourced from the simulation
iXBRL filing — single XHTML file, ESMA crypto-asset taxonomy, tagged from the same data structures as the simulation
cadCAD peg simulation — minimum 3 scenarios (base / stress / black-swan), reproducible configuration shipped with the filing
Redemption gate stress test — Q_max and T_max parameters with quantitative justification, calibrated to the reserve composition's liquid horizon
Reserve composition disclosure — band rather than point, stress-tested across the band
Adverse events recovery plan — references the simulation's T_recovery values per scenario
Cross-jurisdiction wrapper — if passporting from outside the EU, mapping of legal entities to MiCA obligations is explicit
{{< /checklist >}}
## Regulatory sources
Primary regulation: [MiCA Regulation (EU) 2023/1114](https://eur-lex.europa.eu/eli/reg/2023/1114/oj/eng) for Articles 6, 36, 48–49 and Annexes I–II; [Commission Implementing Regulation (EU) 2024/2984](https://eur-lex.europa.eu/eli/reg_impl/2024/2984/oj/eng) for the iXBRL ITS in force since 23 December 2025; the ESMA crypto-asset XBRL taxonomy published 5 August 2025.
ESMA guidance: Q&A 2654 (17 October 2025) on the legacy whitepaper regime and the obligations of trading-platform operators; the Statement on iXBRL/XBRL implementation (28 November 2025); and the Statement on the end of transitional periods (17 April 2026).
{{< cta title="Building a MiCA-compliant stablecoin?" text="Giants Labs ships the full four-artifact bundle as one engineering deliverable. Built for the 1 July 2026 CASP cliff; sized for UAE- and CIS-resident founders planning a MiCA passport via an EU entity." button="Get in touch" link="/quote/" >}}
---
## Ownership Model: NFTs, RWA, and Commodity Tokens
- URL: https://giantslabs.pro/models/ownership-model/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Ownership as a token utility model: NFTs, RWA, commodity tokens. NAV and premium formulas, three types of ownership tokens, PAXG, Ondo, and RealT cases.
A buyer acquires PAXG not for a service discount and not for a governance vote — but because each token represents a troy ounce of gold in a vault. This is the **ownership model**: the token confers a right of ownership over an asset — digital, physical, or financial. Among the [five demand models]({{< relref "models/demand-models" >}}), ownership is unique in that the token's value is determined not by protocol mechanics, but by the value of the underlying asset.
## What Is the Ownership Model
**Ownership model** — a utility mechanism where the token represents a right of ownership over an asset. The holder buys the token not to use the protocol, but to own what stands behind it.
The ownership model is one of the [five core demand models]({{< relref "models/demand-models" >}}) and covers three asset classes: digital objects (NFTs), physical commodities, and financial instruments (RWA).
{{< callout title="Ownership vs Payment" >}}
**Ownership:** the token **is** the asset or a right to the asset. Demand is determined by the underlying asset's value.
**Payment:** the token is used to **purchase** a service. Demand is determined by transaction volume.
In the ownership model, token value doesn't depend on transaction count — it's anchored to what backs the token.
{{< /callout >}}
## Three Types of Ownership Tokens
### 1. NFTs and Digital Objects
The token represents a unique digital asset: artwork, game item, domain name, subscription, virtual land.
| Subcategory | Value source | Example |
|---|---|---|
| Art and collectibles | Subjective value, scarcity | CryptoPunks, Art Blocks |
| Game items | In-game utility, speculation | Axie Infinity, Gods Unchained |
| Digital subscriptions | Time-limited access to a service | NFT subscriptions |
| Domains and identifiers | Utility + speculation | ENS, Unstoppable Domains |
| Virtual land | Limited supply, metaverse | Decentraland, The Sandbox |
**Key feature:** NFT prices are determined subjectively. No formula yields a "fair" price for a CryptoPunk. Demand is shaped by three factors:
1. **Utility** — what you can do with the NFT (content access, gameplay, subscription)
2. **Social signal** — status of ownership (PFP collections)
3. **Speculation** — expectation of price appreciation
{{< callout type="warning" title="NFT model limitation" >}}
If the only source of demand is reselling at a higher price, the model is unstable. Historical data splits by segment: art-segment NFTs and low-utility PFP drops have typically lost 80–99% of peak value (Art Blocks ≈ −95%, SuperRare ≈ −94%, Foundation ≈ −99% by trading volume since 2021), while even blue-chip PFP floors (CryptoPunks, BAYC) have fallen 70–90% in USD from ATH (DappRadar / CryptoRank, Dec 2025: NFT market cap $2.5B vs $9.2B in Jan 2025, −72%). A sustainable NFT model requires at least one non-speculative source of demand.
{{< /callout >}}
#### NFT Subscription Economics
One of the most sustainable NFT models — subscription with time decay:
{{< formula math="P_secondary = P_0 × (T_remaining / T_total)" >}}
- P_secondary — secondary market price (computed)
- P_0 — initial price
- T_remaining — remaining subscription duration
- T_total — full subscription duration
{{< /formula >}}
Subscriptions create **recurring demand**: the term expires → the user buys a new NFT. A secondary market with royalties (5–10%) gives the protocol a steady revenue stream.
{{< callout title="Caveat: linear decay is a first approximation" >}}
The formula above assumes utility decays uniformly over time. In practice, empirical decay is usually non-linear — access passes with declining utility (fewer remaining events, waning community activity) lose value faster than the linear curve, while memberships with accumulating benefits (loyalty tiers) decay more slowly. Treat the linear model as a baseline, then calibrate with secondary-market data.
{{< /callout >}}
### 2. Commodity Tokens
The token represents a right to a physical commodity: gold, silver, carbon credits, energy, agricultural products.
| Asset | Token | Chain / Contract | Backing | Verification mechanism |
|---|---|---|---|---|
| Gold | PAXG | Ethereum `0x45804880De22913dAFE09f4980848ECE6EcbAf78` | 1 troy oz in Brinks London vault (LBMA Good Delivery) | KPMG audits, NYDFS-regulated issuer (Paxos) |
| Gold | XAUT | Ethereum `0x68749665FF8D2d112Fa859AA293F07A622782F38` | 1 troy oz in a Swiss vault | Quarterly attestations by BDO Italia + Chainlink Proof of Reserve (2026) |
| Carbon credits | BCT (Toucan) | Polygon | Pre-2016 Verra offsets (legacy) | Verra registry — **note:** Verra delisted pre-2016 credits in May 2022; Toucan has since pivoted to CHAR and newer pools |
| Uranium | xU3O8 (Uranium.io) | Tezos | 1/5 lb of U₃O₈ per token | Physical uranium supplied by Curzon Uranium; custody & issuance by Archax (FCA-regulated); stored at Cameco |
#### Valuation Formula
{{< formula math="P_net = P_commodity × Quantity − F_transfer × P_commodity × Quantity" >}}
- P_net — net proceeds to the holder (computed)
- P_commodity — market price of the commodity
- Quantity — amount of commodity per token
- F_transfer — per-transfer / redemption fee (illustrative, applied on sale or unvaulting)
{{< /formula >}}
Real fee schedules are **not** a uniform annual storage charge: PAXG holds on-chain balances with 0% annual storage and a ~0.02% on-chain transfer fee as a structural parameter — Paxos has waived this fee since Sep 2024, so the current transfer fee is $0 — plus a separate unvaulting fee for physical delivery; XAUT charges 0% storage but ~25 bps on creation/redemption. Always model the fee as **per-transfer / per-redemption**, not continuous.
**Example.** PAXG with gold near $4,600/oz (PAXG spot ≈ $4,614 in April 2026), 1 token = 1 oz. The on-chain transfer fee is currently $0 (waived since Sep 2024) — the structural parameter is ~0.02%:
{{< formula math="P_net = $4,600 × 1 − 0 × $4,600 × 1 = $4,600.00" >}}
- At the current waived rate, net proceeds on transfer equal spot — at the ~0.02% structural rate the result would be $4,599.08
{{< /formula >}}
Deviation of market price from fundamental — premium or discount — arises from liquidity, on-chain gold demand, and redemption costs. With a liquid market, arbitrage keeps the spread within 0.1–0.5%.
#### Advantages of Commodity Tokens
{{< checklist title="What asset tokenization enables" type="check" >}}
Fractionalization: buying 0.001 oz of gold (~$4.60 at recent spot) is impossible through traditional markets, but possible via PAXG
24/7 liquidity: commodity markets operate during specific hours; crypto markets run around the clock
Global access: no geographic broker restrictions
Instant settlement: T+0 instead of T+2 in traditional markets
Composability: commodity tokens can be used as DeFi collateral
{{< /checklist >}}
### 3. RWA — Tokenized Real-World Assets
The token represents a share in a financial instrument: treasury bonds, corporate bonds, real estate funds, credit pools.
| Category | Examples | TVL (April 2026) | Yield |
|---|---|---|---|
| Tokenized Treasuries | BlackRock BUIDL, Ondo (USDY ~$1B, OUSG ~$0.7B), Franklin FOBXX, Mountain USDM | ~$12.9B | 4–5% |
| Tokenized equities/ETFs | Backed Finance (xStocks) | — | tracks underlying |
| Real estate | RealT (~$155M TVL), Lofty | $0.2–0.3B | 6–16% (net rental) |
| Private credit | Centrifuge (>$1B TVL), Goldfinch, Maple | >$3.2B | 8–14% |
**Total RWA (ex-stables): >$26B as of mid-2026** (RWA.xyz, Ondo Finance, Centrifuge platform update, 2026). Per-row figures are sums for the named protocols, not full RWA.xyz category totals: RWA.xyz tracks the entire private-credit category (dominated by Figure, not listed above) near $13B. The >$26B total also spans classes not itemized in the table above (tokenized equities, commodities, institutional funds).
#### Net Asset Value Formula
{{< formula math="P_market = (NAV / Supply) × (1 + Premium_%)" >}}
- P_market — market price (computed)
- NAV — Net Asset Value
- Supply — total token supply
- Premium_% — market premium or discount to NAV (can be negative)
{{< /formula >}}
**Example.** A tokenized real estate fund with NAV = $10M, 1M tokens issued:
{{< formula math="P_market = ($10M / 1M) × (1 + 0) = $10.00" >}}
- At par (zero premium), each token is worth $10 — proportional to the fund share
{{< /formula >}}
In practice RWA tokens trade at premia/discounts. USDY and OUSG typically trade at or near par via authorized participant arbitrage; RealT property tokens have traded at discounts to appraised NAV (RealT entered voluntary liquidation in 2026, which reinforces the redemption/counterparty-risk thesis rather than contradicting it); closed-ended RWA funds can trade at ±5–10% of NAV depending on liquidity and redemption friction.
If the property generates 8% annual rental income, the holder receives $0.80 per token per year — a hybrid of the ownership and securities models.
#### Legal Architecture of RWA
Tokenizing a real asset requires a legal structure that connects the on-chain token to the off-chain right:
| Component | What it solves | Examples |
|---|---|---|
| SPV (Special Purpose Vehicle) | Isolates the asset from issuer risks | Delaware LLC, Cayman fund |
| Custodian | Stores the underlying asset | Brinks (gold), Anchorage (digital) |
| NAV oracle | On-chain NAV updates | Chainlink, API3, proprietary oracle |
| Transfer agent | Maintains the ownership registry | Securitize, tZERO |
| Legal opinion | Confirms ownership rights | Law firms (Latham & Watkins, DLA Piper) |
{{< callout type="warning" title="RWA regulatory risks" >}}
RWA tokens qualify as securities in most jurisdictions. This means: registration requirements, investor restrictions (accreditation), reporting, and audits. Projects navigate this through Reg D (accredited investors in the US), Reg S (non-US investors), or jurisdictions with favorable regulation (Switzerland, Singapore, UAE).
{{< /callout >}}
## Comparing the Three Types
| Criterion | NFT | Commodity tokens | RWA |
|---|---|---|---|
| Underlying asset | Digital object | Physical commodity | Financial instrument |
| Valuation | Subjective | Commodity market price | NAV |
| Volatility | High | Depends on commodity | Low–medium |
| Regulation | Minimal | Commodity law | Securities law |
| Fractionalization | Usually whole units | Arbitrary | Arbitrary |
| Yield | Royalties (0–10%) | None (per-transfer fee applied at sale) | 4–5% Treasuries / 8–14% private credit / 6–16% real-estate net rental |
| Storage | Owner's wallet | Physical vault | SPV + custodian |
| Counterparty risk | Low (on-chain) | Medium (custodian) | High (SPV, jurisdiction) |
## Total Demand Formula
Total demand for an ownership token is the sum of several components:
{{< formula math="D_total = D_utility + D_yield + D_speculation + D_collateral" >}}
- D_utility — demand from asset use (NFT subscription, access)
- D_yield — demand from yield (RWA)
- D_speculation — speculative demand
- D_collateral — demand as DeFi collateral
- D_total — aggregate demand (computed)
{{< /formula >}}
A sustainable model is one where D_utility + D_yield > D_speculation. If speculative demand dominates, the model is vulnerable to corrections.
## When to Choose the Ownership Model
### The model works when:
1. **The underlying asset has standalone value** — gold, bonds, real estate, unique digital content
2. **Tokenization solves a real problem** — fractionalizing an inaccessible asset, global access, liquidity for an illiquid market
3. **Legal structure secures rights** — the holder can redeem the token and receive the underlying asset (or its cash equivalent)
### The model doesn't work when:
1. **The underlying asset is pure speculation** — NFT collection without utility, "virtual land" without an ecosystem
2. **No redemption mechanism** — if the token can't be exchanged for the underlying asset, the NAV peg is declarative
3. **High counterparty risk** — unaudited custodian, opaque legal structure, unverifiable reserves
### Decision Tree
```text
Is there a real asset to tokenize?
├── Yes → Is the asset unique or fungible?
│ ├── Unique → NFT
│ │ └── Does it have utility beyond resale?
│ │ ├── Yes → Sustainable NFT model (subscription, access, gameplay)
│ │ └── No → High risk, consider adding utility
│ └── Fungible → Commodity token or RWA?
│ ├── Physical commodity → Commodity token
│ │ └── Custodian + audit in place? → Mandatory
│ └── Financial instrument → RWA
│ └── Regulatory framework defined? → Mandatory
└── No → Ownership model doesn't fit
└── Consider Payment, Discount, or Securities
```
## Common Mistakes
{{< checklist title="Ownership model pitfalls" type="check" >}}
NFT without utility: a picture-token without functionality loses value after the hype fades. Add non-speculative demand: subscription, access, royalties
RWA without reserve audits: if backing can't be verified, premium/discount to NAV will be unpredictable. Required: Proof of Reserves, regular audits, transparent oracle
No redemption mechanism: if the holder can't redeem the token for the underlying asset, the NAV peg is decorative. Arbitrage doesn't work → price detaches from fundamentals
Ignoring legal structure: an RWA token without an SPV is a promise, not a right. Issuer bankruptcy means losing the asset
Over-tokenization: not everything needs tokenizing. If the asset is already liquid and accessible (equities through a broker), tokenization adds counterparty risk, not value
{{< /checklist >}}
## Metrics for the Tokenomist
When designing an ownership model, track:
| Metric | Formula / source | Target value |
|---|---|---|
| Premium/discount to NAV | (P_market − P_nav) / P_nav | < 1% for commodities, < 5% for RWA |
| Proof of Reserves | On-chain reserve audit | 100% backing |
| Redemption ratio | Redemptions / total supply | 1–5% per month (healthy level) |
| Speculative demand share | Trading volume / NAV | < 10x (NFTs often > 100x) |
| Legal robustness | SPV, audit, registration present | Full structure |
{{< cta title="Designing an ownership model?" text="We've built tokenization models for RWA funds, commodity-backed tokens, and NFT subscription platforms. We'll help structure the legal architecture and model the NAV mechanics." button="Get in touch" link="/quote/" >}}
---
## Payment Model: Token as the Means of Payment
- URL: https://giantslabs.pro/models/payment-model/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Payment utility model: token as the sole means of payment. MV=PQ equation, velocity paradox, retention mechanisms, Filecoin, ETH, and TON case studies.
A protocol issues a token and makes it the only way to pay. Users grow, transactions multiply — and the price stands still. This isn't a bug; it's the **velocity paradox**: the more efficient the token is as a payment instrument, the faster it circulates, and the lower its fundamental price. The payment model creates mandatory demand, but without retention mechanisms that demand doesn't translate into value.
## What Is the Payment Model
**Payment model** — a utility mechanism where the token is the **sole or primary** means of payment within the ecosystem. Unlike the [discount model]({{< relref "models/discount-model" >}}), where token payment is optional, here it's mandatory.
The payment model is one of the [five core demand models]({{< relref "models/demand-models" >}}) and is most characteristic of infrastructure projects: data storage, compute, bandwidth, oracles.
{{< callout title="Payment vs Discount" >}}
**Payment:** the service is available **only** for the token. Demand is mandatory.
**Discount:** payment is possible in any currency, but cheaper in the token. Demand is incentive-based.
Mandatory demand is stronger, but it creates onboarding friction and depends on velocity.
{{< /callout >}}
## Mechanics
### The Payment Cycle
Step 5 is key. The service provider (miner, validator, node operator) bears real costs in fiat. They **sell** the tokens they receive, creating constant sell pressure. This is what distinguishes the payment model from staking, where tokens are locked.
### Velocity
The token completes the "buy → pay → sell" chain as fast as possible. Neither the buyer nor the seller wants to hold:
- **Buyer** minimizes price risk: buys right before payment
- **Provider** minimizes volatility exposure: sells immediately after receipt
Result — high [token velocity]({{< relref "models/token-velocity" >}}).
## The Exchange Equation: MV = PQ
The foundational formula for valuing payment tokens — an adaptation of Irving Fisher's equation (1911, originally formulated as MV = PT, where T is the number of transactions; the modern income-form convention substitutes PQ for PT):
{{< formula math="MV = PQ" >}}
- M — token market capitalization (USD)
- V — velocity (number of times each unit of capitalization changes hands per period)
- P — price of the service
- Q — number of transactions
{{< /formula >}}
Rearranging to find justified capitalization:
{{< formula math="M = PQ / V" >}}
- M — fundamental capitalization in USD (computed)
- P × Q — transaction volume per period
- V — how many times each unit of capitalization changed hands in the same period
{{< /formula >}}
### Numerical Example
A decentralized storage protocol with $100M annual volume:
| Velocity (V) | Fundamental market cap | Per token (100M supply) |
|---|---|---|
| V = 5 | $20M | $0.20 |
| V = 10 | $10M | $0.10 |
| V = 20 | $5M | $0.05 |
| V = 50 | $2M | $0.02 |
At velocity 5 (token held ~73 days), market cap is $20M. At velocity 50 (token held ~7 days) — only $2M. A **tenfold** difference on identical volume.
### The Velocity Paradox
Here's the paradox: if the protocol is successful and users are satisfied, transactions flow quickly and smoothly. The token circulates rapidly. V rises. Capitalization M = PQ/V **falls.**
A protocol's success as a payment system **destroys** the value of its token. The better the payment works, the lower the price.
{{< callout type="warning" title="The key limitation" >}}
The payment model in its pure form creates mandatory demand but not **retention.** Without mechanisms to reduce velocity, the fundamental price trends toward the minimum, and the market price is sustained only by speculative premium.
{{< /callout >}}
## Retention Mechanisms
For the payment model to create not just demand but value, mechanisms that slow token velocity are needed:
### 1. Staking and Collateral
Providers lock tokens as collateral to participate in the network. The more locked, the less in free circulation, the lower the effective velocity.
{{< formula math="V_eff = PQ / (Price × (S − Locked))" >}}
- V_effective — effective velocity of free-floating tokens (computed)
- S — total token supply (in tokens)
- Locked — tokens locked as collateral or in long-term contracts (in tokens)
- S − Locked — free-float supply (tokens in free circulation)
- Price — current token price (USD per token)
- Price × (S − Locked) — free-float market capitalization (USD)
{{< /formula >}}
**Example (illustrative):** Filecoin requires providers to post collateral for the entire storage duration (180 days minimum, up to 1278 days after FIP-0052, which raised the previous 540-day cap). If effective velocity is computed only over the free float, a 30% lockup implies a free-float price roughly 1/0.7 ≈ 1.43x higher than with no lockup, holding P, Q, and free-float velocity constant. This is a rule-of-thumb scenario: the actual price uplift depends on how velocity itself responds to the lockup.
### 2. Burn
A portion of each payment is destroyed permanently. This doesn't reduce velocity, but decreases supply, counteracting price pressure.
{{< formula math="Supply(t) = Supply_0 − Σ Burned" >}}
- Supply_0 — initial token supply
- Σ Burned — cumulative tokens burned
- Supply(t) — current supply at time t (computed)
- With active usage, creates deflation
{{< /formula >}}
**Example:** EIP-1559 in Ethereum burns the base fee. During periods of high activity, ETH becomes deflationary — more is burned than emitted.
### 3. Long-Term Contracts
Payment is locked for the entire service duration. The user pays tokens upfront, and they're released as the service is consumed.
**Example:** Filecoin — clients pay for storage 6–12 months in advance. Tokens are locked for the contract duration.
### 4. Vote-Locking
Tokens are locked for governance participation. Longer lockups give greater voting weight (veToken model).
**Example:** Curve — veCRV locks for up to 4 years. This is one of the most aggressive retention mechanisms in the market.
### Mechanism Comparison
| Mechanism | Retention strength | Lock duration | User risk | Example |
|---|---|---|---|---|
| Validator staking | High | 21 days – 1+ year | Slashing | ETH, FIL, ATOM |
| Burn | Permanent | Forever | None (transparent) | EIP-1559, BNB |
| Long-term contracts | High | Contract duration | Loss on early termination | FIL, AR |
| Vote-locking | Medium | 1 week – 4 years | Low | veCRV, veBAL |
| Protocol staking | Medium | 7–90 days | Safety Module risk | AAVE, GMX |
## Case Studies
### Filecoin (FIL) — Two-Sided Payment
Filecoin is the canonical payment model example with built-in retention mechanisms.
**Client-side demand:** storage payment in FIL only. Client buys FIL → pays for storage → tokens locked for contract duration.
**Provider-side demand:** pledge collateral for network participation. Locked for the entire sector duration — 180 days (minimum) up to 1278 days after FIP-0052 (previously capped at 540 days). Slashing for poor storage quality.
**Dual lockup:**
1. Client payments locked for contract duration
2. Provider collateral locked for sector duration (180 days to 1278 days)
**Result:** a significant share of supply is locked, and effective velocity is lower than in pure payment models.
### Ethereum (ETH) — Payment + Burn + Staking
ETH demonstrates the evolution from pure payment to multi-model utility.
**Payment:** gas for every transaction is paid in ETH. Mandatory demand proportional to network activity.
**Burn (EIP-1559):** the base fee is burned. During high-activity periods, burning exceeds emission → ETH is deflationary.
**Staking (PoS):** 32 ETH minimum per validator. As of early 2026, roughly 34–37M ETH (~28–31% of supply) is staked.
**Combined effect:** three mechanisms working simultaneously create powerful retention.
### TON — A Pure Payment Lesson
TON (The Open Network) illustrates the weakness of the payment model without sufficient retention mechanisms.
**On paper:** ETH-like model — gas paid in TON, validator staking.
**In practice:**
- Gas is extremely cheap → minimal payment demand
- DeFi ecosystem is underdeveloped → few transactions
- Wallet growth doesn't translate to transaction activity growth
- The only meaningful demand source is validator staking
**Fundamental valuation via MV=PQ:** at current transaction volumes and average velocity, the justified price is significantly below market. The gap is speculative premium.
{{< callout type="warning" title="The TON lesson" >}}
The payment model requires **real economic throughput.** Low fees and low transaction volume don't create sufficient demand. User growth without transaction activity growth is useless for the fundamental price.
{{< /callout >}}
## When the Payment Model Works
### Ideal Conditions
1. **Essential resource.** The protocol provides a resource without which work is impossible: storage, compute, bandwidth, oracle data
2. **Providers with collateral.** Service providers post token collateral → retention mechanism
3. **Long-term contracts.** Payment is locked for the service duration → additional retention
4. **Burn mechanism.** A portion of payments is burned → deflationary pressure
5. **No alternative.** The user can't pay any other way
### When It Doesn't Work
| Situation | Why it fails |
|---|---|
| Discretionary service (games, social media) | Mandatory token payment repels users |
| Low transaction volume | M = PQ/V → at low PQ, capitalization is minimal |
| Gas costs fractions of a cent | Token demand for gas is negligible |
| Alternative payment exists (meta-transactions) | Mandatory requirement is diluted |
| Providers don't stake | No retention mechanism → V is maximized |
## Comparison with Other Utility Models
| Parameter | Payment | Discount | Securities | Value Transfer |
|---|---|---|---|---|
| Demand | Mandatory | Incentive-based | Yield-based | Infrastructure |
| Velocity | High | High | Low | Low |
| Retention | Weak | Weak | Medium | Strong |
| Best for | Infrastructure | Exchanges, platforms | Revenue-generating protocols | PoS networks |
| Key risk | V → 0 capitalization | No volume | No real revenue | No real necessity |
## Common Mistakes
### 1. Payment Without Retention
A pure payment token without staking, burn, or long-term contracts is a token with maximum velocity. The entire fundamental capitalization = PQ/V, where V can be 50+.
### 2. Gas as the Only Payment
If gas costs fractions of a cent, payment demand is negligible. Ethereum works because its transaction volume is enormous. For L2s with gas < $0.001, gas-based payment doesn't create meaningful demand.
### 3. Optional Payment
If the protocol accepts stablecoins "for convenience," payment demand for the native token disappears. Each alternative dilutes the mandatory requirement.
### 4. Ignoring the Supply Side
Service providers (miners, nodes, validators) **sell** the tokens they receive. Without a collateral requirement, payment creates pure sell pressure.
### 5. MV=PQ Without the Speculative Component
In practice, market price = fundamental (MV=PQ) + speculative premium. The speculative premium is unstable and can account for 90%+ of the price for young projects. Design the economy around the fundamental component.
{{< checklist title="Payment model design checklist" type="check" >}}
Mandatory confirmed: no alternative payment method exists
PQ calculated: annual transaction volume at 1, 3, and 5 years
Velocity estimated: benchmark against comparables (roughly: BTC ~5, ETH ~8–12, utility tokens ~20–50; exact values depend on methodology)
Retention mechanism added: staking, collateral, burn, or vote-locking
Supply side accounted for: providers stake or post collateral
Burn mechanism defined: a portion of payments is burned
Inflation balanced: net supply change (emission − burn) is justified
Stress-tested: what happens at V×2 or PQ/2
{{< /checklist >}}
{{< cta title="Designing a payment model?" text="We've designed payment utility for infrastructure projects, DePIN networks, and data storage platforms. We'll select the right retention mechanisms and model the fundamental price." button="Get in touch" link="/quote/" >}}
---
## Points Systems: Pre-Token Loyalty Programs
- URL: https://giantslabs.pro/models/points-systems/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How to design a points program — actions, conversion, Sybil defense. Case studies from EigenLayer, Blast, Hyperliquid. Formulas and anti-patterns.
A points system is a pre-token loyalty mechanism where a protocol awards internal points for targeted user actions, with subsequent conversion to tokens at TGE. Unlike a classic [airdrop]({{< relref "models/airdrop" >}}), points create a predictable real-time incentive: the user sees accumulated points and understands the link between actions and future rewards.
## Why Points Exist
Classic airdrops suffer from three problems:
1. **Uncertainty.** The user doesn't know whether they'll receive an airdrop or how much. This attracts "Sybil farmers" who create hundreds of wallets at random
2. **No feedback loop.** There's no way to know if activity is being counted until the snapshot
3. **One-time incentive.** An airdrop is a single event. After receiving tokens, the user has no incentive to stay
Points solve all three through transparent, real-time accrual.
{{< callout title="Scale of the trend" >}}
In 2024–2025, points programs became the standard for pre-token marketing. EigenLayer, Blast, Ethena, and Hyperliquid all ran points programs before their token launches, and newer programs like Backpack carry the pattern into 2026. These are early-cycle cases: Blast, for instance, has since seen its TVL collapse by more than 95% from its 2024 peak. By 2026, the model has evolved: seasonal points, multiple conversions, and early experimentation with veTokenomics hybrids.
{{< /callout >}}
## Points System Architecture
### Three Components
**1. Targeted actions.** What earns points. Actions are ranked by value to the protocol:
| Action type | Value | Example | Points/day |
|---|---|---|---|
| Liquidity deposit | High | $1,000 in a pool | 10 points |
| Active usage | Medium | Trading, swaps | 3 points/tx |
| Social activity | Low | Referral invite | 1 point |
| Position holding | Medium | Hold $1,000 for 30 days | 5 points/day |
The point values here are illustrative weights for ranking actions, not outputs of the Model 1 formula below: the dollar-denominated rows imply only ~0.005–0.01 point per dollar per day, versus the 1–10 rate in Model 1.
**2. Accrual.** How points accumulate. Two approaches:
- **Linear**: 1 point per $1 per day. Simple and predictable
- **With multipliers**: base points × multiplier for early entry / volume / duration. More complex, but enables fine-grained behavioral control
**3. Conversion.** How points turn into tokens at TGE.
{{< formula math="Tokens_i = Allocation_points × (Points_i / Points_total)" >}}
- Allocation_points — share of total supply allocated to points (typically 5–15% per season or program; multi-season programs may allocate more cumulatively)
- Points_i — specific user's points
- Points_total — aggregate points across all users
{{< /formula >}}
{{< callout type="warning" title="The dilution problem" >}}
With proportional conversion, the value of a single point **falls** as the number of participants grows. If at program launch 1,000 points = 1% of the allocation, but by TGE the participant count has grown 100x — those same 1,000 points = 0.01%. Early participants feel cheated. Solution: fixed allocations per season (Blast), caps on total points, or a guaranteed minimum conversion rate.
{{< /callout >}}
## Accrual Models
### Model 1: Linear (TVL-Based)
The most common model. Points accrue proportionally to deposit volume.
{{< formula math="Points_day = TVL_user × Rate" >}}
- TVL_user — user's funds in the protocol ($)
- Rate — points per dollar per day (typically 1–10)
{{< /formula >}}
Example: user deposits $10,000 for 60 days at a rate of 5 points/$:
- Total: $10,000 × 5 × 60 = **3,000,000 points**
**Advantage:** simplicity. **Disadvantage:** attracts whales who deposit large sums shortly before the snapshot.
### Model 2: With Multipliers
Base points are multiplied by coefficients:
{{< formula math="Points = Points_base × M_early × M_ref × M_duration" >}}
- M_early — early participation multiplier (2x in month 1, 1.5x in month 2, 1x after)
- M_ref — referral multiplier (1.1x per invite, up to 1.5x)
- M_duration — continuous holding multiplier (1.2x after 30 days, 1.5x after 90)
{{< /formula >}}
Multipliers solve the behavioral problem: early users earn more, loyal users even more, and attracting new participants earns a bonus.
### Model 3: Seasonal (Epoch-Based)
The program is split into seasons with a fixed allocation for each:
| Season | Duration | Allocation | Actions |
|---|---|---|---|
| 1 | 3 months | 5% of supply | Deposits, swaps |
| 2 | 3 months | 4% of supply | + governance, staking |
| 3 | 3 months | 3% of supply | + advanced strategies |
The seasonal model solves dilution: each season's allocation is fixed, and early participants receive their share regardless of future user inflows. The declining 5%/4%/3% allocation shown here is one common approach; constant or increasing per-season allocations are also used.
## Sybil Defense
Points systems are particularly vulnerable to Sybil attacks: one user creates multiple wallets to maximize points. For more on Sybil resistance, see the [airdrop]({{< relref "models/airdrop" >}}) article.
### Defense Mechanisms
| Mechanism | How it works | Effectiveness |
|---|---|---|
| **Minimum threshold** | Points accrue only for TVL > $100 | Medium — easy to bypass with capital |
| **Linear cap** | Max points per wallet per day | Medium — also limits honest whales |
| **Quadratic decay** | Marginal rate falls with volume | High vs concentration, but needs an identity layer for Sybil resistance (else rewards wallet-splitting) |
| **Identity verification** | KYC, World (ex-Worldcoin), Human Passport (formerly Gitcoin Passport) | High — but reduces anonymity |
| **On-chain reputation** | Points for wallet history (age, activity) | Medium — aged wallets can be bought |
{{< formula math="Points_quadratic = √(TVL_user) × Rate" >}}
- Quadratic model with Rate = 1: $10,000 yields 100 points, $40,000 yields 200 (not 400)
- Reduces the advantage of large deposits
- But without identity checks it rewards Sybil splitting: four $10,000 wallets earn 400 points versus 200 for one $40,000 wallet (√N advantage), so pair it with an identity/uniqueness layer
- Analogous to quadratic voting from [governance models]({{< relref "governance/voting-models" >}})
{{< /formula >}}
## Points → Token Conversion
### Open vs Closed Conversion
| Parameter | Open | Closed |
|---|---|---|
| **Rate** | Known in advance (100 points = 1 token) | Determined at TGE |
| **Predictability** | High — user knows what they'll get | Low — depends on total points |
| **Risk for project** | Overpromising if too many points issued | Minimal — allocation is fixed |
| **Examples** | Rare in practice | EigenLayer, Ethena |
Most projects use **closed conversion** with a fixed allocation. It's safer for the project but creates uncertainty for users.
### Conversion Timing
| Approach | Description | Advantage | Disadvantage |
|---|---|---|---|
| **One-time** | All points convert at TGE | Simple | Massive dump |
| **Gradual** | Conversion in tranches (25% TGE + vesting) | Reduces sell pressure | More complex for users |
| **On-demand** | User chooses conversion timing | Flexibility | Unpredictable for treasury |
{{< callout title="The Hyperliquid lesson" >}}
Hyperliquid ran one of the most successful airdrops of 2024: a generous allocation (31% of supply for the community), no VC tokens, and no locks on the community airdrop at TGE. Result — minimal sell pressure and strong appreciation over the following 20 months (from ~$4 at launch to ~$70 by mid-2026), though with a sharp correction in early 2025. This contradicts the standard logic that "vesting reduces sell pressure," but is explained by high perceived value: users believed in growth and didn't sell.
{{< /callout >}}
## Anti-Patterns
### 1. Infinite Dilution
A program with no cap on total points and no seasons. The longer the program runs, the less each point is worth. Early participants lose motivation.
**Solution:** Fixed allocation per season or a declining accrual rate.
### 2. Indefinite TGE
The protocol accumulates TVL through points but postpones TGE indefinitely. Users grow tired of waiting and leave, taking liquidity with them.
**Solution:** Clear timelines (Season 1: 3 months → TGE) or interim conversions.
### 3. Overweighting Social Actions
Awarding large points for retweets, follows, and invites attracts bots and devalues points for active users.
**Solution:** Social points should be no more than 5% of total accrual. Primary weight on financial actions (deposits, trading).
### 4. Lack of Transparency
Users can't verify whether points are accrued correctly. This destroys trust and invites manipulation accusations.
**Solution:** On-chain accrual or regular merkle-root snapshots with public verification.
## Design Parameters
| Parameter | Range | Recommendation |
|---|---|---|
| Points allocation | 5–15% of supply per season/program | 7–10% for a first program |
| Season duration | 1–6 months | 3 months (balance engagement and fatigue) |
| TVL points share | 60–90% | 70% of total accrual |
| Trading points share | 10–30% | 20% of total accrual |
| Social points share | 0–10% | 5% maximum |
| Early entry multiplier | 1.5x–3x | 2x for the first month |
| Conversion vesting | 0–50% at TGE | 25–50% TGE, remainder over 3–6 months |
{{< checklist title="Points program checklist" type="check" >}}
Targeted actions — defined with clear accrual rates
Sybil defense — quadratic model, threshold, or KYC
Fixed allocation — per season or in absolute terms
Transparency — on-chain accrual or verifiable snapshots
TGE timing — defined at least approximately
Vesting — included at conversion to reduce sell pressure
Financial actions — account for more than 70% of point accrual
Late-entry protection — declining multiplier or per-wallet cap
{{< /checklist >}}
## Points vs Airdrop: When to Use What
| Factor | Points | Classic airdrop |
|---|---|---|
| Transparency for user | High | Low |
| Behavioral control | Fine-grained (multipliers, rates) | Coarse (snapshot) |
| Sybil defense | Better (quadratic models) | Worse (retrospective filter) |
| Implementation cost | Higher (backend, dashboard) | Lower (one snapshot) |
| Pre-TGE engagement | Continuous | One-time |
| Fatigue risk | Yes (with long programs) | No |
A points system is preferable when the protocol needs to **retain TVL** over months before TGE. A classic airdrop is sufficient for **retroactively rewarding** existing users.
## Summary
A points system is an evolution of the airdrop that solves the problems of uncertainty, Sybil farming, and one-time incentives. Three key design decisions: accrual rate (how many points for which action), Sybil defense (quadratic model or thresholds), and conversion mechanism (open or closed, with vesting or without).
The main risk is **dilution during long programs** without fixed seasons. Solution: a seasonal model with a fixed allocation per period.
{{< cta title="Designing a points program?" text="We've built points systems for DeFi, GameFi, and infrastructure protocols. We'll design your accrual mechanics, Sybil defense, and conversion strategy." button="Get in touch" link="/quote/" >}}
---
## Prediction Markets: AMM, CLOB, and Betting Tokenomics
- URL: https://giantslabs.pro/models/prediction-markets/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How prediction markets work: AMM vs CLOB comparison, LMSR pricing formula, betting fairness problem, and Sybil arbitrage.
Prediction markets are mechanisms that turn participant opinions into probabilities. Participants buy contracts on event outcomes, and the market price of a contract reflects the collective probability estimate. In 2024–2025, prediction markets experienced explosive growth: Polymarket processed roughly $3.7B on the single "US presidential winner" market and about $9B cumulative platform volume in 2024, with ~314,000 active traders (The Block; ChainCatcher). The platform runs hundreds of concurrent event markets at any given time. Growth was not monotonic — DLNews reported an ~84% drop in volume immediately after the November 2024 election, followed by a gradual recovery around sports, crypto, and macro events. This drawdown pattern is critical context for anyone designing tokenomics around event-driven platforms.
But behind the elegant idea lie serious tokenomics questions: how to set prices when liquidity is thin? Which mechanism is fairer — AMM or order book? How to defend against Sybil attacks?
## How a Prediction Market Works
### Core Mechanics
Each market is a binary (or multi-outcome) contract:
- "Yes" is priced from $0.01 to $0.99
- Price = participants' probability estimate
- When the event occurs, the "Yes" contract settles at $1.00, "No" at $0.00
{{< formula math="P(outcome) = Contract_price / Face_value" >}}
- Contract_price — current trading price
- Face_value — settlement value ($1.00)
- P_outcome — implied probability (computed)
- A contract price of $0.65 → the market estimates a 65% probability
{{< /formula >}}
### Three Pricing Approaches
| Approach | Mechanism | Examples |
|---|---|---|
| **AMM (LMSR)** | Logarithmic cost function sets price | Gnosis, Zeitgeist, XO.Market (LS-LMSR) |
| **Odds-driven vAMM** | Virtual AMM with oracle-sourced odds and a singleton liquidity pool | Azuro (LiquidityTree + vAMM) |
| **AMM (Uniswap-style)** | Constant-product pool per outcome | Polkamarkets |
| **CLOB** | Central Limit Order Book — participants set prices themselves | Polymarket, Kalshi, Limitless Exchange |
| **Hybrid** | Off-chain order book + on-chain settlement | SX Bet |
## AMM in Prediction Markets
### LMSR — Logarithmic Market Scoring Rule
The classic AMM formula for prediction markets, proposed by Robin Hanson:
{{< formula math="C(q) = b × ln(∑ e^(q_i / b))" >}}
- qᵢ — number of contracts sold for outcome i
- n — number of outcomes; the sum runs over i = 1..n
- b — liquidity parameter (higher b = lower slippage)
- C(q) — cost function determining the current price (computed)
{{< /formula >}}
Price of a contract for a specific outcome:
{{< formula math="p_i = e^(q_i / b) / ∑ e^(q_j / b)" >}}
- pᵢ — current contract price (= probability estimate, computed)
- The sum in the denominator runs over j = 1..n outcomes
- Σᵢ pᵢ = 1 (probabilities are normalized)
{{< /formula >}}
### LMSR Problems
**Fixed liquidity.** The parameter b determines the market maker's maximum loss. If b is too small — slippage is enormous on small volumes. If b is large — the market maker incurs heavy losses. There's no dynamic adjustment to changing demand.
**Inefficiency on volatile markets.** LMSR was designed for prediction markets with gradual probability refinement. When markets move sharply (election results, sports events), the formula can't adapt fast enough, and arbitrageurs extract profit from the market maker.
**Scaling.** For multi-outcome markets (10+ options), LMSR requires exponentially more liquidity. For a market with 20 outcomes, the b parameter needs to increase proportionally.
{{< callout type="warning" title="AMM is losing to CLOB" >}}
Among the largest prediction market platforms, only a few use an AMM-family design: Polkamarkets (Uniswap-style AMM), XO.Market (LS-LMSR), and Azuro (odds-driven vAMM with LiquidityTree — not a classical LMSR). The majority — Polymarket, Kalshi, SX Bet, Limitless Exchange — run on CLOB or hybrid models. This signals systemic limitations of the AMM approach: insufficient pricing flexibility and market maker losses on volatile markets.
{{< /callout >}}
## CLOB — Central Limit Order Book
### Mechanics
CLOB works like traditional exchanges:
1. A participant places a **limit order**: "Buy 'Yes' at $0.60"
2. Another participant places a **matching order**: "Sell 'Yes' at $0.60"
3. Orders match, the trade executes
### Advantages Over AMM
| Criterion | AMM (LMSR) | CLOB |
|---|---|---|
| **Slippage** | Determined by parameter b, fixed | Depends on order book depth, adaptive |
| **Pricing** | Formula, lags the market | Participants set price in real time |
| **Liquidity** | Limited by initial market maker capital | Sourced from all participants |
| **Multi-outcome** | Exponential scaling requirements | Linear scaling |
| **Arbitrage** | Market maker bears losses | Losses distributed among counterparties |
### Why CLOB Won
Polymarket — the largest prediction market by volume — uses CLOB based on the CTF Exchange protocol. The reasons:
1. **Capital efficiency.** Market makers place limit orders with managed risk, rather than pouring liquidity into a pool with unpredictable losses.
2. **Price accuracy.** On election markets where probabilities shift 1–2% per day, CLOB participants reflect information more precisely than the LMSR formula with its lag.
3. **Composability.** CLOB is compatible with professional trading strategies: market-making, cross-platform arbitrage, delta hedging.
## The Fairness Problem: Normalized Volatility
On prediction markets, a fairness issue arises: outcomes with different volatility have different attractiveness for speculators.
### Example
Two markets:
- "Candidate A wins the election" — price fluctuates from $0.45 to $0.55 (low volatility)
- "Bitcoin above $100K by June" — price fluctuates from $0.20 to $0.80 (high volatility)
A trader earns more on the second market with the same capital — not because they forecast better, but because the market is more volatile.
### Normalized Volatility Formula
{{< formula math="V_norm = σ(p) / (p̄ × (1 − p̄))" >}}
- Sigma_p — standard deviation of contract price
- P_avg — average contract price over the period
- P_avg × (1 − P_avg) — maximum possible variance for a Bernoulli distribution
- V_norm — normalized volatility, enables cross-market comparison (computed)
{{< /formula >}}
Normalized volatility enables comparing markets with different base probabilities and adjusting fees or margin requirements accordingly.
## Sybil Arbitrage
### Attack Mechanics
Sybil arbitrage — creating multiple accounts to exploit bonuses or subsidies on a prediction market:
1. The platform subsidizes liquidity or offers bonuses for first bets
2. The attacker creates N accounts
3. Half the accounts bet "Yes," the other half bet "No"
4. One outcome wins, and the attacker collects bonuses from the winning accounts
{{< formula math="Profit = N × Bonus − Fee × N × Bet" >}}
- N — number of Sybil accounts (each makes one bet and receives one bonus)
- Bonus — bonus per account
- Fee — platform fee rate
- Bet_size — bet amount per account
- Profit — attack profit (computed); attack is profitable if Bonus > Fee × Bet_size
{{< /formula >}}
{{< callout type="info" title="Ungated theoretical maximum" >}}
The formula above assumes zero capital cost, instant withdrawal, and no identity gate. Real deployments layer on minimum-volume requirements, cooldown periods, withdrawal fees, and KYC / proof-of-humanity checks — each of which reduces realized attacker profit and shifts the break-even. Treat the formula as an upper bound on attack economics, not a forecast.
{{< /callout >}}
### Defenses
| Method | Mechanism | Weakness |
|---|---|---|
| **KYC** | Document verification | Reduces anonymity, loses crypto-native audience |
| **Proof of Humanity** | Biometrics or social graph | Costly, false positives |
| **Deposit collateral** | Minimum stake to participate | Increases barrier to entry |
| **Behavioral analysis** | Algorithms detecting coordinated actions | Arms race |
## Platform Tokenomics
Prediction market platforms use different tokenomic models:
### Polymarket: No Governance Token, But a Platform Stablecoin
Polymarket operates without a governance token. Historically, bets were placed in USDC with minimal fees, and monetization relied on trading volume and data.
In April 2026, Polymarket announced **CTF Exchange V2**, introducing **Polymarket USD** — a platform-native, 1:1 USDC-backed stablecoin — together with Managed Optimistic Oracle V2 and a proposer whitelist that governance expanded from an initial 37 addresses to ~177 as of mid-2026 (Crypto Times; Polymarket docs; The Block). The platform still has no freely traded governance token, but it is no longer "USDC-only": users interact through a wrapped platform stablecoin that sits on top of USDC.
**Advantage:** no governance-token friction; users stay in stablecoins.
**Disadvantage:** no on-chain governance instrument; value capture is indirect (volume and data).
### Azuro: Token for Liquidity
Azuro uses its AZUR token for:
- Staking in liquidity pools
- Governance voting on market parameters
- Incentivizing data providers (oracles)
On the mechanism side, Azuro is an **odds-driven virtual AMM**: data providers push odds to the protocol, a singleton **LiquidityTree** pool absorbs bets across many markets, and LP profit comes from the spread around the oracle odds — not from an LMSR cost function (Azuro Medium, "Introducing Azuro's Liquidity Tree"; Messari, "Understanding Azuro"). Classifying Azuro as "AMM (LMSR)" is a common but incorrect shorthand.
**Advantage:** liquidity providers are motivated by the token, not just fees.
**Disadvantage:** an additional asset increases complexity and risk for users; pricing quality depends on data-provider honesty.
## When AMM, When CLOB
{{< checklist title="Choosing the pricing mechanism" type="check" >}}
AMM (LMSR): low-liquidity markets, launch phase, guaranteed liquidity needed without professional market makers
AMM (LMSR): multiple markets with predictable volatility (sports, fixed outcomes)
CLOB: high-liquidity markets with professional participants
CLOB: markets with variable volatility (politics, macroeconomics)
Hybrid: cold start on AMM with transition to CLOB as volume grows
{{< /checklist >}}
{{< cta title="Prediction markets and mechanism design" text="Prediction markets are a special case of mechanism design. Pricing formulas, incentive systems, and attack defenses are built on the same principles as any tokenomic system." button="Mechanism design" link="/models/mechanism-design/" >}}
---
## Reward Emission: Halving, Decay Curves, and GameFi Rewards
- URL: https://giantslabs.pro/models/reward-emission/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Reward supply model: how to design emission for useful actions. Halving, decay curves, GameFi rewards, and an emission calculator.
In the [five supply models overview]({{< relref "models/token-supply-models" >}}), the reward model is described briefly: "new tokens are created as rewards for useful actions." But it's in the design details where the biggest opportunities and traps hide. Too generous an emission kills the token price. Too stingy — fails to attract participants. This article covers the math, types, and practical design of reward models.
## What Is the Reward Model
**Reward model** is a supply model where new tokens are minted as rewards for **targeted actions** in the system. Unlike [allocation]({{< relref "models/allocation" >}}), where tokens are distributed upfront, in the reward model tokens **appear** only when a participant performs useful work.
Three key components:
1. **Targeted actions** — what exactly is rewarded (block validation, providing hashrate, gameplay, data provision)
2. **Reward size** — how many tokens a participant receives per action
3. **Emission curve** — how the reward size changes over time
{{< callout title="Reward ≠ airdrop" >}}
An airdrop is a one-time distribution for past actions. A reward is an ongoing mechanism: as long as the participant does the work, they earn tokens. Airdrops attract; rewards retain.
{{< /callout >}}
## Types of Reward Models
### Consensus Rewards
Tokens are created for maintaining network operations:
| Mechanism | What is rewarded | Examples |
|---|---|---|
| **Proof-of-Work** | Computational work (hashrate) | Bitcoin, Litecoin |
| **Proof-of-Stake** | Capital lockup (staking) | Ethereum, Cosmos, Solana |
| **Proof-of-Useful-Work** | Network-specific work | Helium (Proof of Coverage), Filecoin (Proof of Spacetime, building on Proof of Replication for storage setup) |
Consensus rewards are the purest case of the reward model: tokens are created strictly for work necessary for the network to function.
### Game and Product Rewards
Tokens are created for in-product activity:
| Action | Example reward | Risk |
|---|---|---|
| App registration | 3,000 tokens | Low — one-time action |
| Avatar creation | 2,000 tokens | Low |
| Inviting friends (>3) | 5,000 tokens | Medium — referral fraud |
| Significant trading volume | 8,000 tokens | High — wash trading |
| Transaction in period | 4,000 tokens | Medium |
| Action streak | 1.5x multiplier | High — autoclickers |
{{< callout type="warning" title="Key GameFi reward risk" >}}
Maintaining a long-term balance between participant and system interests is difficult. If rewards are too generous — participants farm and sell, killing the price. If too stingy — no motivation to participate. Additional problem: referral fraud and autoclickers.
{{< /callout >}}
### Staking Rewards
A subtype combining the reward model with the [staking mechanism]({{< relref "models/staking" >}}):
| Staking tier | Minimum stake | Lock period | Annual yield (APR) |
|---|---|---|---|
| Basic (Common) | 50 tokens | 1 month | 5.00% |
| Mid (Uncommon) | 200 tokens | 2 months | 7.00% |
| High (Rare) | 500 tokens | 3 months | 10.00% |
Staking rewards create a positive feedback loop: the participant locks tokens (reducing sell pressure) and receives new ones (increasing supply). Balancing these forces is the main design challenge.
## Emission Mathematics
### Decaying Emission (Halving)
The classic solution to the inflation problem — **decaying emission**, where reward size decreases on a schedule.
{{< formula math="R(t) = R_0 × (1/2)^(t / T_halving)" >}}
- R(t) — block reward at time t
- R_0 — initial reward
- T_halving — halving period
- Bitcoin: R_0 = 50 BTC, T_halving = 210,000 blocks (~4 years)
- This is a continuous approximation. Bitcoin uses a discrete step function: the reward is constant within each epoch and halves exactly at the boundary (see the table below)
{{< /formula >}}
| Epoch | Period | Block reward | Total BTC per epoch | Cumulative |
|---|---|---|---|---|
| 1 | 2009–2012 | 50 BTC | 10,500,000 | 10,500,000 |
| 2 | 2012–2016 | 25 BTC | 5,250,000 | 15,750,000 |
| 3 | 2016–2020 | 12.5 BTC | 2,625,000 | 18,375,000 |
| 4 | 2020–2024 | 6.25 BTC | 1,312,500 | 19,687,500 |
| 5 | 2024–2028 | 3.125 BTC | 656,250 | 20,343,750 |
Halving guarantees a finite supply (for Bitcoin — 21,000,000 BTC) and declining inflation. But it also creates a problem: when emission becomes too small, will fees alone be enough to motivate miners?
### Linear Decaying Emission
An alternative to halving — linear reward reduction:
{{< formula math="R(t) = R_0 × max(0, 1 − t / T_end)" >}}
- Linear decaying emission
- T_end — the moment emission ends
- Reward decreases uniformly to zero
{{< /formula >}}
### Activity-Linked Emission
In product reward models, emission is often tied not to time but to participant count:
{{< formula math="R_total(t) = Σ(A(i,t) × W(i))" >}}
- R_total — total emission in period t
- A(i,t) — number of actions of type i in period t
- W(i) — weight (reward) per action of type i
{{< /formula >}}
This model directly links emission to product growth: more users → more actions → more tokens created. Advantage: connected to real system development. Risk: during rapid growth, emission can become uncontrollable.
## Designing a Reward Model: Step by Step
### Step 1: Define Targeted Actions
Which actions create value for the system? Each action must have a **measurable contribution**.
| Project type | Targeted action | Metric |
|---|---|---|
| L1/L2 network | Block validation | Uptime, block count |
| DePIN | Resource provision | Coverage, data volume |
| GameFi | Gameplay activity | Time in game, transactions |
| DeFi | Liquidity provision | TVL, duration |
### Step 2: Set Weights for Each Action
Not all actions are equal. Weight determines how many tokens a participant earns:
| Action | Weight (tokens) | Type | Rationale |
|---|---|---|---|
| Registration | 3,000 | One-time (90% conversion) | Low entry barrier |
| Avatar upload | 2,000 | One-time (80% conversion) | Profile activation |
| Invite 3+ friends | 5,000 | One-time (40% conversion) | Network growth, but fraud risk |
| Significant trading volume | 8,000 | Monthly (20% of users) | High value |
| Transaction in period | 4,000 | Monthly (30% of users) | Activity retention |
### Step 3: Forecast Participant Count
A reward model requires a user growth forecast because emission depends on the number of actions:
| Month | Period start | Acquisition | Churn (5%) | Period end |
|---|---|---|---|---|
| 1 | 0 | 100 | 0 | 100 |
| 2 | 100 | 300 | 5 | 395 |
| 3 | 395 | 300 | 19 | 676 |
| 6 | 1,196 | 300 | 59 | 1,437 |
| 12 | 2,471 | 300 | 123 | 2,648 |
### Step 4: Calculate Emission and Check Sustainability
Combining actions, weights, and participant counts yields an emission forecast. Sustainability criterion: **emission must not exceed the value created**.
Example for an app acquiring 300 users/month with 5% churn:
| Month | Users | Monthly emission | Cumulative |
|---|---|---|---|
| 1 | 100 | 910,000 | 910,000 |
| 2 | 395 | 2,996,000 | 3,906,000 |
| 3 | 676 | 3,782,800 | 7,688,800 |
| 6 | 1,437 | 5,913,600 | 23,371,600 |
| 12 | 2,648 | 9,304,400 | 71,229,200 |
Over 12 months, the system emits ~71.2M tokens. If total supply is capped at 1B — that's 7.1% per year. Key question: are users creating value commensurate with this emission? If not — action weights are too high or the model needs a decaying multiplier.
Python: reward emission calculation
```python
actions = {
"register": {"weight": 3000, "pct_users": 0.90, "once": True},
"avatar": {"weight": 2000, "pct_users": 0.80, "once": True},
"invite_3": {"weight": 5000, "pct_users": 0.40, "once": True},
"trading_volume": {"weight": 8000, "pct_users": 0.20, "once": False},
"transaction": {"weight": 4000, "pct_users": 0.30, "once": False},
}
acquisition_month_1 = 100
acquisition_per_month = 300
churn_rate = 0.05
months = 12
users = 0
total_emission = 0
for m in range(1, months + 1):
new_users = acquisition_month_1 if m == 1 else acquisition_per_month
churned = int(users * churn_rate)
users = users - churned + new_users
month_emission = 0
for name, a in actions.items():
if a["once"]:
eligible = new_users * a["pct_users"]
else:
eligible = users * a["pct_users"]
month_emission += eligible * a["weight"]
total_emission += month_emission
print(f"Month {m:2d}: users={users:,}, emission={month_emission:,.0f}, cumulative={total_emission:,.0f}")
```
Try the interactive [Reward Emission Calculator]({{< relref "tools/calc-reward-emission" >}}) to model an emission curve without writing code.
## Common Mistakes
{{< checklist title="Reward model traps" type="check" >}}
Emission without value linkage: tokens created for clicks, likes, registrations — actions that don't create real system value. Result: inflation without demand growth
No decay curve: fixed reward forever. Over time, supply grows, demand stagnates, price falls. Decaying emission or metric linkage is needed
Ignoring wash trading: if tokens are rewarded for trading volume, participants will trade with themselves. Defenses needed: minimum time between trades, transaction graph analysis, proof of actual ownership
Overly generous staking: 100%+ APR attracts farmers who immediately sell rewards. Sustainable nominal APR typically falls in the roughly 5–15% range, though it varies by network and real yield after inflation is often lower
No burn mechanism: rewards create supply. Without a mechanism to destroy tokens (burn, buyback), supply only grows. Balance is needed: some tokens must be removed from circulation
{{< /checklist >}}
## Reward vs Other Supply Models
| Criterion | Allocation | Airdrop | Reward | Bonding Curve |
|---|---|---|---|---|
| When tokens are created | At launch | One-time | Ongoing | On purchase |
| Activity linkage | None | Indirect | Direct | Direct (with price) |
| Emission control | Full | Full | Partial | Automatic |
| Inflation risk | Low | Low | High | Depends on curve design |
| For which stakeholders | Team, investors | Early users | Validators, active participants | Any buyers |
The reward model is essential for projects where [stakeholders]({{< relref "basics/stakeholders" >}}) perform work for the network. But it requires careful [mechanism design]({{< relref "models/mechanism-design" >}}) to ensure emission doesn't exceed the value created.
{{< cta title="Designing a reward system?" text="We'll model your emission curve, set action weights, and stress-test sustainability across growth scenarios." button="Get in touch" link="/quote/" >}}
---
## Stablecoin Tokenomics: Models, Formulas, and Terra Lessons
- URL: https://giantslabs.pro/models/stablecoin-tokenomics/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Four stablecoin models — fiat-backed, algorithmic, hybrid, and CDP. Peg mechanics, the UST crash analysis, and USDC/DAI/FRAX comparison.
A stablecoin is a token designed to maintain a stable exchange rate against an external asset (usually the dollar). From a tokenomics perspective, it's an extreme case: a token where **price stability is the primary function**, not a side effect. Stablecoin tokenomics defines how the peg is maintained, what incentives participants have, and where the failure points are.
## Why Stablecoins Are a Tokenomics Problem
A stablecoin is not simply "a token equal to a dollar." Behind every stablecoin is an economic mechanism that maintains the peg, and that mechanism is pure tokenomics:
1. **Supply model** — how stablecoins are created and destroyed
2. **Demand model** — why hold a stablecoin rather than dollars in a bank account
3. **Stabilization mechanism** — how the system returns the price to the peg after deviations
4. **Participant incentives** — who maintains the peg and why it's profitable for them
{{< callout title="Market scale" >}}
Total stablecoin market cap exceeds $300B (2025–2026). USDT and USDC account for over 80% of the market. Decentralized stablecoins (DAI, FRAX, GHO, crvUSD) make up less than 10%, but they're the most interesting from a tokenomics standpoint since their peg mechanism is entirely on-chain.
{{< /callout >}}
## Four Stablecoin Models
### Model 1: Full Fiat Backing
The simplest model: each stablecoin is backed by a dollar (or equivalent) in a bank account.
**Mechanics:**
1. User sends $1 to the issuer
2. Issuer mints 1 stablecoin
3. On redemption: user surrenders the stablecoin → receives $1
{{< formula math="Peg: Reserves ≥ Stablecoin_supply" >}}
- The peg holds as long as reserves cover supply
- Failure point: if Reserves < Supply, a bank run begins
{{< /formula >}}
**Examples:** USDC (Circle), USDT (Tether), PYUSD (PayPal)
**Tokenomics:**
- The issuer earns interest by investing reserves in treasury bonds
- Users receive no yield (revenue goes to the issuer)
- No governance token (centralized model)
| Advantage | Disadvantage |
|---|---|
| Simple and understandable | Centralization (issuer can freeze funds) |
| Stable peg | Counterparty risk (issuer's bank) |
| Scalable | Regulatory risk (MiCA, SEC) |
### Model 2: Crypto-Collateralized (CDP)
CDP (Collateralized Debt Position) is a decentralized model where stablecoins are minted against crypto collateral.
**Mechanics:**
1. User locks ETH (or another asset) in a smart contract
2. Receives stablecoins worth less than the collateral value (overcollateralization)
3. To reclaim collateral: return the stablecoins + pay interest
4. If collateral value drops below threshold — liquidation
{{< formula math="Collateral_ratio = Collateral_value / Debt_value" >}}
- Minimum collateral ratio: typically 150% (DAI); crvUSD uses soft liquidations (LLAMMA) instead of a fixed threshold
- When ratio < minimum → automatic liquidation
{{< /formula >}}
{{< formula math="Max_loan = Collateral_value / Min_ratio" >}}
- Example: $10,000 ETH collateral at 150% ratio → max borrow $6,667
- In practice, users maintain 200–300% ratios for safety margin
{{< /formula >}}
**Examples:** DAI / USDS (MakerDAO / Sky), crvUSD (Curve), GHO (Aave), LUSD / BOLD (Liquity V1 / V2)
**Participant incentives:**
| Participant | Action | Incentive |
|---|---|---|
| **Borrower** | Locks collateral, mints stablecoin | Gets liquidity without selling the asset |
| **Liquidator** | Buys undercollateralized positions | Gets collateral via Dutch auction; borrower pays a 13% liquidation penalty |
| **DSR holder** | Deposits stablecoin in savings module | Earns interest (DAI Savings Rate) |
### CDP Stabilization Mechanism
The peg is maintained through arbitrage and interest rate management:
**Price > $1 (premium):** Protocol lowers the interest rate → borrowing becomes cheaper → more stablecoins are minted → supply increases → price falls toward $1.
**Price < $1 (discount):** Protocol raises the interest rate → holding a loan becomes expensive → borrowers buy stablecoins and close positions → supply decreases → price rises toward $1.
{{< formula math="Arb_incentive = |Price − 1| − Swap_fee" >}}
- Arbitrageurs buy cheap stablecoins and repay debt (or vice versa)
- Arbitrage works as long as deviation > swap fee
{{< /formula >}}
### Model 3: Algorithmic Stablecoin
An algorithmic stablecoin maintains its peg without physical backing — using only math and incentives.
**Core mechanic — the seigniorage model:**
1. Price > $1 → protocol mints new stablecoins → supply grows → price falls
2. Price < $1 → protocol buys back and burns stablecoins → supply shrinks → price rises
{{< formula math="Mint = max(0, Demand − Supply)" >}}
- Simplified conceptual model — real implementations use mint/burn swaps (Terra) or rebase mechanics, not a direct demand minus supply function
- Protocol expands supply when demand grows
- And contracts it when demand falls
- The question: at whose expense does contraction happen?
{{< /formula >}}
### The Terra/UST Crash: Step-by-Step
Terra (UST) was the largest algorithmic stablecoin failure. Its collapse in May 2022 wiped out an estimated $40–50B in combined UST and LUNA market cap.
**Terra's mechanics:**
- UST (stablecoin) pegged to $1 through a two-way swap with LUNA (governance token)
- To mint 1 UST: burn $1 worth of LUNA
- To redeem 1 UST: receive $1 worth of LUNA
**What went wrong:**
1. **Anchor Protocol** offered 20% APY on UST deposits, attracting demand not backed by real economic activity
2. Massive positions concentrated in Anchor (~75% of all UST)
3. Mass withdrawal from Anchor → UST selling → peg pressure
4. To defend the peg, the protocol burned UST and minted LUNA
5. Massive LUNA minting → LUNA hyperinflation → LUNA price crash
6. Falling LUNA price meant redeeming 1 UST required minting ever more LUNA → **death spiral**
7. LUNA supply exploded from ~350M (pre-crash) to 6.5T in approximately 3 days
{{< callout type="warning" title="The death spiral formula" >}}
A death spiral occurs when collateral is denominated in the protocol's own token: falling collateral price requires minting more tokens → additional minting pushes the price down further → even more minting. A positive feedback loop with no external stabilizer.
{{< /callout >}}
{{< formula math="Spiral: P_LUNA ↓ → Mint_LUNA ↑ → P_LUNA ↓↓" >}}
- At $1 LUNA: redeeming 1M UST requires minting 1M LUNA
- At $0.01 LUNA: redeeming 1M UST requires minting 100M LUNA
- Hyperinflation: LUNA supply grew from ~350M to 6.5T in ~3 days
{{< /formula >}}
### The Lesson from Terra
An algorithmic stablecoin backed solely by its own governance token is mathematically unstable under mass withdrawal. Without external collateral (fiat, ETH, treasury bonds), the model only works during growing demand.
### Model 4: Hybrid (Partial Backing)
Hybrid stablecoins combine real-asset backing with algorithmic stabilization.
**Mechanics (FRAX v1 example):**
- Part of the stablecoin is backed by USDC (collateralized portion)
- Part is algorithmic through FXS (uncollateralized portion)
- The ratio (collateral ratio) adjusts dynamically
{{< formula math="Value_FRAX = CR × Collateral + (1 − CR) × Algo" >}}
- CR — collateral ratio (backed portion)
- At CR = 100% → fully backed (like USDC)
- At CR = 0% → fully algorithmic (like UST)
- In practice CR = 85–100%
{{< /formula >}}
{{< callout title="FRAX evolution" >}}
After the Terra crash, the FRAX project moved from partial to **full collateralization** (CR = 100%). This is a market signal: the fully algorithmic model didn't survive the practical test, and even hybrid models are moving toward full backing.
{{< /callout >}}
## Comparison Table
| Stablecoin | Model | Collateral | Decentralization | Peg stability | Governance token |
|---|---|---|---|---|---|
| **USDC** | Fiat-backed | USD in accounts | No | High | None |
| **USDT** | Fiat-backed | Mixed assets (~80% US Treasuries, quarterly attestations since 2024) | No | High | None |
| **DAI / USDS** | CDP | ETH, USDC, RWA (primarily US Treasuries by 2026) | Partial | High | MKR → SKY |
| **crvUSD** | CDP (LLAMMA) | ETH, wBTC, wstETH | Yes | High (soft liquidations) | CRV |
| **GHO** | CDP | aTokens (Aave) | Partial | High (~$580M cap, stable peg by 2026) | AAVE |
| **LUSD (V1)** | CDP | ETH only | Yes | High | LQTY |
| **BOLD (Liquity V2)** | CDP | ETH + LSTs | Yes | High | LQTY (shared) |
| **FRAX** | Hybrid → fiat | USDC + treasury bonds; frxUSD backed by tokenized treasuries (2026) | Partial | High | FXS |
| **UST** | Algorithmic | LUNA (itself) | Yes | **Failed** | LUNA |
## Governance Token Tokenomics for Stablecoins
Decentralized stablecoins typically have a separate governance token whose tokenomics determines system resilience.
### MKR → SKY (MakerDAO / Sky)
- **Role:** governance + last line of defense
- **Mechanism:** when collateral is insufficient, the protocol mints governance tokens and sells them to cover debt
- **Revenue:** surplus reserves fund governance token buyback and burn
- **Incentives:** governance token holders are incentivized to manage risk properly — otherwise their token gets diluted
{{< callout type="info" title="MakerDAO → Sky rebrand" >}}
In September 2024, MakerDAO rebranded to Sky: MKR was replaced by SKY (1:24,000 conversion) and DAI by USDS. The mechanism described here remains the same — only the token names changed. We use the original MKR/DAI names where describing the historical design.
{{< /callout >}}
{{< formula math="SKY_revenue = Loan_interest + RWA_yield − DSR_cost − OPEX" >}}
- If revenue > 0 → governance token buyback (deflation)
- If loss → governance token minting (inflation, last resort)
{{< /formula >}}
### CRV (crvUSD)
- **Role:** governance via veTokenomics (see [veTokenomics]({{< relref "models/ve-tokenomics" >}}))
- **crvUSD specifics:** the LLAMMA soft liquidation mechanism — liquidation through [AMM]({{< relref "models/amm" >}}) instead of instant threshold liquidation
- **Revenue:** crvUSD loan interest is distributed to veCRV holders
### Design Lesson
A stablecoin's governance token should be the **last line of defense**: during a crisis, the protocol can dilute the governance token to cover debt. This creates a natural incentive for responsible governance — MKR holders lose money if they allow poor risk management.
## Designing a Stablecoin: Checklist
{{< checklist title="Stablecoin design checklist" type="step" >}}
Choose the model — CDP or fiat-backed
Collateral and ratio — if CDP: define accepted collateral types and minimum ratio
Liquidation mechanism — instant or soft (LLAMMA)
Interest rate — define the rate and adjustment mechanism
Governance token — design as the last line of defense
Stress test — what happens if collateral drops 50% in a day?
Reflexivity check — ensure collateral doesn't depend on the protocol's own token
{{< /checklist >}}
## Key Risks
### Collateral Reflexivity
If a stablecoin is backed by an asset whose price depends on demand for the stablecoin (like UST/LUNA), the system contains a positive feedback loop. Under any significant stress, this loop becomes a death spiral.
**Rule:** collateral must be **exogenous** — its price must not depend on demand for the stablecoin.
### USDC Dependency
Many "decentralized" stablecoins (DAI, FRAX) use USDC as a significant portion of their collateral. This creates dependency on Circle and reduces real decentralization. In March 2023, when USDC briefly lost its peg due to Silicon Valley Bank issues, DAI also deviated from $1.
### Regulatory Pressure
MiCA in the EU introduces requirements for stablecoin issuers: licensing, reserves, reporting. For fiat-backed stablecoins, this is a formality (Circle already obtained a license). For decentralized ones, it's an existential challenge: who is the issuer of DAI?
## Summary
Stablecoins are a tokenomics laboratory: each model embodies a specific economic theory. The four models sit on a spectrum from full centralization (USDC) to full algorithmization (UST), and the market has clearly shown: **real-asset backing is necessary**.
The Terra crash wasn't a failure of a specific project — it was a failure of a model: an algorithmic stablecoin backed by its own token contains a mathematical vulnerability — a positive feedback loop that under stress becomes a death spiral.
For designing a resilient stablecoin: use **exogenous collateral** (ETH, RWA, treasury bonds), a **liquidation mechanism** with a safety margin, and a **governance token as the last line of defense**.
{{< cta title="Designing a stablecoin?" text="We've analyzed the tokenomics of every major stablecoin model. We'll help you choose the right architecture, set parameters, and stress-test the peg mechanism." button="Get in touch" link="/quote/" >}}
---
## Staking: Economics, Models, and Reward Design
- URL: https://giantslabs.pro/models/staking/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Staking economics in tokenomics: APR vs APY, inflationary vs real rewards, liquid staking, and slashing. Formulas, simulation code, and a yield calculator.
Staking is a foundational mechanism in cryptoeconomics. It simultaneously secures the network, reduces circulating supply, and generates income for participants. But behind the simplicity of "lock tokens — earn rewards" lies a complex economy where inflation, real yield, and sell pressure determine the token's fate.
## What Is Staking
**Staking** is locking tokens in a smart contract to earn rewards and/or participate in network operations. A staker temporarily gives up liquidity in exchange for income.
In tokenomics, staking plays a dual role:
1. **Supply mechanism** — staking rewards are a channel for emitting new tokens (the reward model in [supply models]({{< relref "models/token-supply-models" >}}))
2. **Demand mechanism** — staking creates a reason to buy and hold the token, working as a [demand model]({{< relref "models/demand-models" >}})
{{< callout title="Staking in the tokenomics context" >}}
Staking is not an isolated parameter. It is embedded in the supply-demand balance: rewards increase supply (inflation), while locking reduces circulating volume. The net effect depends on the percentage staked and staker behavior.
{{< /callout >}}
### Two Types of Staking
| Type | Purpose | Reward source | Examples |
|------|---------|---------------|---------|
| **Consensus** | Securing a PoS network | Emission + network fees | Ethereum, Cosmos, Solana |
| **Protocol** | Incentivizing protocol participation | Protocol fees, treasury | Aave, Curve, GMX |
Consensus staking is part of the blockchain architecture. Protocol staking is a tokenomist's tool for shaping user behavior.
### Staking Landscape (as of early 2026)
| Network | APR | % Staked | Unbonding | Mechanism |
|---------|-----|----------|-----------|-----------|
| **Ethereum** | ~2.8–3.3% | ~30% | ~1–5 days (queue) | PoS, 32 ETH per validator |
| **Solana** | ~4–7% | ~67% | ~2–3 days | DPoS + PoH |
| **Cosmos Hub** | ~14–20% | ~65% | 21 days | Tendermint BFT |
| **Polkadot** | ~10–14% | ~55% | 24–48h (post-reform) | NPoS |
| **Avalanche** | ~4.5–7% | ~55% | 14 days | PoS (Snowman) |
*Rates change frequently — check current data before modeling.*
## APR and APY: Real Yield
### Formulas
{{< formula math="APR = (Annual_rewards / Staked) × 100" >}}
- APR — annual rate without compounding
- Annual_rewards — total rewards for the year
- Staked — total staked tokens
{{< /formula >}}
{{< formula math="APY = (1 + APR / n)^n − 1" >}}
- APY — annual rate with compounding
- n — compounding frequency per year (daily: n = 365)
{{< /formula >}}
At APR = 10% with daily compounding: APY = (1 + 0.10/365)^365 - 1 = **10.52%**. The difference is small at moderate rates, but at APR = 100%, APY reaches **171.5%**.
### Nominal vs Real Yield
Nominal APR is what the interface displays. Real yield accounts for token inflation:
{{< formula math="Real_yield = APR_nom − Inflation" >}}
- APR_nom — nominal staking rate
- Inflation — annual supply growth rate
{{< /formula >}}
**Example.** A network with 12% APR and 8% inflation:
- Nominal yield: 12%
- Real yield: 12% - 8% = **4%**
- Non-stakers lose: -8% (their share is diluted by inflation)
{{< callout title="Inflationary staking is not free money" type="warning" >}}
If 100% of rewards come from emission, staking is a redistribution from non-stakers to stakers, not value generation. Real income only comes from protocol fees and external revenue.
{{< /callout >}}
### Real Yield: Income from Fees
Protocols with real yield distribute not inflationary tokens but fees earned by the protocol:
{{< formula math="Real_yield = (Annual_fees × Stake_share) / (P × Staked)" >}}
- Annual_fees — protocol's annual revenue
- Stake_share — share going to stakers (typically 30–70%)
- P — token price
- Staked — total staked tokens
{{< /formula >}}
**Example.** A protocol with $50M annual revenue, 50% to stakers, 100M tokens staked at $5:
Real_yield = ($50M × 0.5) / ($5 × 100M) = **5%** — pure income without inflation.
## Staking Economics: Design Parameters
### 1. Target Staking Percentage
What share of circulating supply should be staked? Typical values for PoS networks: 40–70%. Note: Ethereum currently sits at ~30%, well below this range — partly due to its late PoS transition (September 2022) and high DeFi opportunity cost.
| Staked | Effect |
|--------|--------|
| < 30% | Low security, high rewards to attract stakers |
| 30–50% | Standard level, moderate rewards |
| 50–70% | High security, low rewards |
| > 70% | Low liquidity, trading issues |
### 2. Dynamic Reward Rate
Many networks use an adaptive model: the rate rises when staking is below target and drops when above.
{{< formula math="APR(s) = APR_target × (S_target / S_actual)^k" >}}
- s — current staking percentage
- S_target — target staking percentage
- S_actual — actual staking percentage
- k — sensitivity (typically 0.5–2)
{{< /formula >}}
At S_target = 50%, S_actual = 30%, k = 1, and APR_target = 8%:
APR = 8% × (50/30) = **13.3%** — elevated rate to attract stakers.
At S_actual = 70%:
APR = 8% × (50/70) = **5.7%** — reduced rate to encourage unstaking.
### 3. Lock-up Period
The time tokens are locked. Longer lock-up reduces sell pressure but limits liquidity.
| Approach | Lock-up | Examples |
|----------|---------|---------|
| Flexible | 0 days (instant unstake) | Liquid staking |
| Short | 1–28 days (unbonding) | Cosmos (21d), Polkadot (24–48h, introduced with the March–April 2026 economic reform; previously 28 days) |
| Medium | 30–90 days | Protocol staking |
| Long | Up to 4 years | veToken (Curve: 1 week to 4 years) |
| Custom | User choice (more lock = more reward) | Convex, many L2s |
### 4. Slashing — Penalties
**Slashing** is the confiscation of part of staked tokens for violations: double-signing a block, equivocation, or incorrect validation. Penalty size: 0.01% (minor violations) to 100% (network attack). Downtime is penalized differently across networks—Ethereum applies an *inactivity leak* (not slashing), while Cosmos does slash for prolonged downtime (jailing + ~0.01%).
Slashing creates an economic incentive for honest behavior and is a key element of [mechanism design]({{< relref "models/mechanism-design" >}}).
## Liquid Staking
**Liquid staking** is a technology that allows earning staking rewards without losing liquidity. The staker receives a derivative token (LST — Liquid Staking Token) that can be used in DeFi.
### How It Works
1. User deposits 1 ETH into a liquid staking protocol (e.g., Lido)
2. The protocol stakes ETH on the network and issues 1 stETH (or rETH from Rocket Pool, cbETH from Coinbase)
3. The LST accrues rewards (rebase or exchange rate appreciation)
4. User uses the LST as collateral, liquidity, or trades it
5. On withdrawal — exchange the LST back for ETH + accumulated rewards
Liquid staking extends beyond Ethereum: JitoSOL and mSOL on Solana (Jito adds 0.5–1% MEV yield), stATOM via Stride on Cosmos, vDOT via Bifrost on Polkadot.
### Economic Effects
| Parameter | Without liquid staking | With liquid staking |
|-----------|----------------------|---------------------|
| Capital locked | Yes | No (LST is liquid) |
| DeFi composability | No | Yes (LST as collateral) |
| Staking percentage | Limited (competes with DeFi) | Higher (no trade-off) |
| Systemic risk | Low | Higher (cascading liquidations) |
| Real yield | Staking APR | Staking APR + DeFi yield |
### Impact on Tokenomics
Liquid staking fundamentally changes the model: staked tokens don't leave circulation. This means staking no longer reduces circulating supply. For a tokenomist, this means **you cannot rely on staking as a sell pressure reduction mechanism** if LST protocols dominate.
{{< formula math="Eff_circulating = Circulating_supply − Staked + Liquid_staked" >}}
- Eff_circulating — effective circulating supply
- Staked — locked in staking
- Liquid_staked — tokens in liquid staking, remaining in circulation via LSTs
{{< /formula >}}
## Restaking
**Restaking** extends the staking model by allowing already-staked assets to secure additional services (Actively Validated Services, or AVS) — oracles, bridges, data availability layers — without requiring separate collateral.
### How It Works
1. User stakes ETH (natively or via an LST like stETH)
2. The restaking protocol (e.g., EigenLayer) re-delegates that stake to one or more AVSs
3. AVSs pay rewards for the additional security
4. In return, the restaker accepts **dual slashing risk** — violations on any secured AVS can slash the original stake
### EigenLayer and the Restaking Market
EigenLayer dominates the restaking market with >$19B TVL and ~4.6M ETH (~94% market share as of mid-2026). ether.fi, the largest Liquid Restaking Token (LRT) provider, holds ~2.1M ETH (6.0% of the staking market), making it the third-largest staking provider overall.
LRT protocols (ether.fi's eETH, Renzo's ezETH, Puffer's pufETH) add another composability layer: users receive a liquid token representing their restaked position, usable across DeFi — creating a three-layer yield stack: base staking + restaking rewards + DeFi yield.
### Impact on Tokenomics
Restaking changes the staking economy in several ways:
- **Additional yield layer** — 3.8–6% APY on top of base staking, creating stronger lock-up incentives
- **Dual slashing risk** — a slash on any AVS can reduce the original stake, increasing the risk profile
- **Supply effects** — restaked tokens are locked more deeply (multiple commitments), but LRTs keep them circulating
- **Security budget** — AVSs can bootstrap security without their own validator set, reducing launch costs
{{< callout type="warning" title="Restaking risk" >}}
Restaking amplifies both yield and risk. A cascade of slashing events across multiple AVSs could trigger large-scale liquidations in LRT markets. When modeling staking economics, account for the restaking layer if your protocol targets ETH stakers.
{{< /callout >}}
## Staking Economy Simulation
A model with dynamic APR shows: starting at 30% staked, APR increases to ~13% to attract stakers. As it approaches the 50% target, the rate drops to 8%. Reward inflation runs at 4–5% annually, but fee income adds 3–5% real yield.
**Simulation results** (parameters: 100M supply, target staking 50%, APR 8%, fees $5M/year):
| Month | Staked, % | APR | Inflation | Total Real Yield (incl. fees) | Total supply |
|-------|----------|-----|-----------|------------|-------------|
| 0 | 30% | 13.3% | 4.0% | 17.7% | 100.0M |
| 12 | 39% | 10.2% | 4.0% | 12.3% | 104.1M |
| 24 | 44% | 9.1% | 4.0% | 10.3% | 108.3M |
| 36 | 47% | 8.5% | 4.0% | 9.3% | 112.7M |
| 48 | 48% | 8.3% | 4.0% | 8.7% | 117.3M |
| 60 | 49% | 8.2% | 4.0% | 8.3% | 122.1M |
Key observations:
- **APR decreases** from 13.3% to 8% as staking approaches the 50% target — the dynamic model works
- **Inflation is stable** at 4% — because staking and APR are balanced
- **Total Real Yield = 8.3%** with fees in steady state. Without fees ($0 revenue), Real Yield = APR − Inflation ≈ 8.2% - 4% = **~4.2%** — pure transfer from non-stakers
- **Total supply grows 22%** over 5 years — the cost of inflationary staking
Simulation code (Python)
```python
import numpy as np
import matplotlib.pyplot as plt
TOTAL_SUPPLY_0 = 100_000_000
STAKING_TARGET = 0.50
APR_TARGET = 0.08
SENSITIVITY = 1.0
FEE_REVENUE_YEAR = 5_000_000
SHARE_TO_STAKERS = 0.50
TOKEN_PRICE = 1.0
MONTHS = 60
months = np.arange(MONTHS)
supply = np.zeros(MONTHS)
staked_pct = np.zeros(MONTHS)
apr = np.zeros(MONTHS)
real_yield = np.zeros(MONTHS)
inflation = np.zeros(MONTHS)
supply[0] = TOTAL_SUPPLY_0
staked_pct[0] = 0.30
for m in range(MONTHS):
staked = supply[m] * staked_pct[m]
apr[m] = min(APR_TARGET * (STAKING_TARGET / max(staked_pct[m], 0.01)) ** SENSITIVITY, 0.30)
monthly_emission = staked * (apr[m] / 12)
inflation[m] = (monthly_emission * 12) / supply[m]
fee_yield = (FEE_REVENUE_YEAR * SHARE_TO_STAKERS) / (TOKEN_PRICE * staked) if staked > 0 else 0
real_yield[m] = apr[m] - inflation[m] + fee_yield
if m < MONTHS - 1:
supply[m + 1] = supply[m] + monthly_emission
delta = (STAKING_TARGET - staked_pct[m]) * 0.05
staked_pct[m + 1] = np.clip(staked_pct[m] + delta, 0.05, 0.90)
fig, axes = plt.subplots(2, 2, figsize=(14, 10))
axes[0, 0].plot(months, apr * 100, color="#3b82f6", linewidth=2)
axes[0, 0].set_title("Dynamic APR"); axes[0, 0].set_ylabel("APR, %"); axes[0, 0].grid(True, alpha=0.3)
axes[0, 1].plot(months, staked_pct * 100, color="#10b981", linewidth=2)
axes[0, 1].axhline(y=50, color="#ef4444", linestyle="--", alpha=0.5, label="Target: 50%")
axes[0, 1].set_title("Staking percentage"); axes[0, 1].legend(); axes[0, 1].grid(True, alpha=0.3)
axes[1, 0].plot(months, real_yield * 100, color="#8b5cf6", linewidth=2, label="Real yield")
axes[1, 0].plot(months, inflation * 100, color="#ef4444", linewidth=2, linestyle="--", label="Inflation")
axes[1, 0].set_title("Real yield vs inflation"); axes[1, 0].legend(); axes[1, 0].grid(True, alpha=0.3)
axes[1, 1].plot(months, supply / 1e6, color="#f59e0b", linewidth=2)
axes[1, 1].set_title("Total supply"); axes[1, 1].set_ylabel("Tokens, M"); axes[1, 1].grid(True, alpha=0.3)
plt.tight_layout(); plt.show()
```
## Common Mistakes
### 1. APR above 100% without a revenue source
Triple-digit APR attracts attention, but if the only source is emission, it's hyperinflation. Real yield is negative, and price drops faster than quantity grows.
### 2. Not accounting for liquid staking
If 80% of stake goes through LST protocols, staking doesn't reduce circulating supply. Models built on the assumption "staked = locked" will produce incorrect price forecasts.
### 3. Same APR for all lock periods
A 1-month staker and a 12-month staker bear different risk. Without rate differentiation, everyone chooses the minimum lock, and the mechanism fails.
### 4. Slashing too mild or absent
Without penalties, there are no economic incentives for honest behavior. Validators can attack the network without losses. Slashing proper applies to double-signing / equivocation (5%+); downtime is handled differently—Ethereum uses an inactivity leak (not slashing), Cosmos slashes ~0.01% with jailing.
### 5. Treasury rewards without limits
A fixed reward pool runs out. If staking rewards come from the treasury (not emission), the pool empties in 2–3 years and APR drops to zero. Solution: combine emission and fees.
{{< checklist title="Staking design checklist" type="check" >}}
Reward source defined — emission, fees, or combination
Real yield is positive — APR exceeds inflation by at least 2–3%
Target staking percentage set — 40–70% for PoS, 20–50% for protocols
Dynamic rate implemented — APR adapts to current staking percentage
Lock-up is differentiated — longer lock = higher reward
Slashing parameters defined — penalties for downtime and attacks
Liquid staking accounted for — LSTs don't reduce circulating supply
5+ year sustainability modeled — rewards won't run out in 2 years
{{< /checklist >}}
{{< cta title="We design staking economics for your protocol" text="We've modeled staking for PoS networks, DeFi protocols, and liquid staking platforms. We calculate optimal parameters and stress-test sustainability over 5 years." button="Get in touch" link="/quote/" >}}
---
## Token Allocation as a Supply Model
- URL: https://giantslabs.pro/models/allocation/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How to distribute tokens among the team, investors, and community. Vesting schedules, cliff, TGE, common mistakes, and an unlock calculator.
## What Is Token Allocation
**Token allocation** is the distribution of total supply shares among a project's stakeholder groups. If a bonding curve answers "at what price," allocation answers **"who gets how much."**
Allocation determines the balance of interests between those who build the product (team), those who finance it (investors), and those who use it (community). Bad allocation kills projects more often than bad code.
A project mints, say, 100,000,000 tokens. They need to be distributed so that:
- The team is motivated long-term but cannot dump tokens on day one
- Investors get adequate returns without dominating everyone else
- The community has tokens for governance and ecosystem participation
- The market has sufficient liquidity from the first day of trading
{{< callout type="info" title="Allocation and other supply models" >}}
Allocation doesn't exist in a vacuum. Each group receives tokens through its own **supply model**: the team — through vesting, the community — through airdrops or staking rewards. Allocation sets "how much"; the supply model sets "how and when."
{{< /callout >}}
In standard (non-upgradeable) contracts, allocation parameters are immutable after deployment. However, many projects use upgradeable proxy patterns or DAO-governed treasuries that allow reallocation through governance votes. Unlike dynamic models (bonding curve, metrics-based airdrop), allocation is a **static plan** that sets upper bounds for each group.
### Key Terms
| Term | Definition |
|------|-----------|
| **Total supply** | Number of tokens currently in existence (including locked/vested), minus burned tokens |
| **Max supply** | Maximum number of tokens that can ever be created |
| **Circulating supply** | Tokens freely circulating on the market at a given moment |
| **Allocation** | Percentage distribution of total supply among stakeholder groups |
| **Vesting** | Schedule for gradual token unlocking over time |
| **TGE** | Token Generation Event — the moment tokens are created and trading begins |
| **Cliff** | Period after TGE during which tokens are fully locked |
## Who Gets Tokens
A standard allocation includes five to eight groups. Each group has its own logic and typical share range.
### Team and Founders
Typical share: **15–20%** of total supply. These tokens always come with long vesting (3–4 years) and a cliff period (6–12 months). The team share should not exceed 20% — higher values raise justified suspicion among investors.
### Investors (Seed, Private, Strategic)
Typical combined share across all rounds: **15–25%**.
- **Seed round** (3–8%): earliest investors, maximum discount, longest vesting
- **Private round** (5–12%): institutional investors, moderate discount
- **Strategic round** (3–7%): ecosystem partners, often tied to KPIs
### Community and Ecosystem
Typical combined share: **30–45%**. The larger the community share, the more decentralized the project is perceived to be.
### Treasury, Liquidity, Advisors
**Treasury** (10–20%) — a reserve for long-term development, managed through multisig or DAO. **Liquidity** (5–10%) — tokens for DEXs and CEXs, without which trading is impossible. **Advisors** (1–3%) — consultants with vesting no shorter than the team's. Allocations above 3% are rare and require strong justification.
### Summary of Typical Allocations
| Group | Typical share | Cliff | Vesting | TGE unlock |
|-------|---------------|-------|---------|------------|
| **Team** | 15–20% | 6–12 mo | 24–48 mo | 0% |
| **Investors (seed)** | 3–8% | 6–12 mo | 18–36 mo | 0–5% |
| **Investors (private)** | 5–12% | 3–6 mo | 12–24 mo | 0–10% |
| **Community (incl. airdrop)** | 10–20% | 0 mo | 0–12 mo | 50–100% |
| **Staking rewards** | 10–20% | 0 mo | 36–72 mo | per emission |
| **Treasury** | 10–20% | 0–6 mo | 24–60 mo | 0–5% |
| **Liquidity** | 5–10% | 0 mo | 0 mo | 100% |
| **Advisors** | 1–3% | 6–12 mo | 24–36 mo | 0% |
{{< callout type="info" title="Validation rule" >}}
The sum of all allocations **always equals 100%**. If the total exceeds 100% during planning, cut one or more groups. If it's under 100%, the remainder typically goes to the treasury.
{{< /callout >}}
## Cliff and Vesting: How Unlocking Works
Allocation determines "how much"; **vesting** determines "when." Without vesting, allocation is meaningless: if all tokens are unlocked immediately, nothing prevents insiders from selling everything on day one.
### Anatomy of a Vesting Schedule
A standard vesting schedule has three phases:
1. **TGE unlock** — percentage of tokens available immediately at launch (0–25%)
2. **Cliff period** — time after TGE with no new unlocks (0–12 months)
3. **Linear vesting** — uniform unlocking of remaining tokens (6–48 months)
{{< formula math="U(t) = A × TGE_% + A_remaining × min(1, max(0, (t − cliff) / vesting))" >}}
- U(t) — unlocked at time t
- A — group allocation
- A_rem = A × (1 − TGE_%)
- cliff, vesting — in months
{{< /formula >}}
### Calculation Example
A seed investor receives 5,000,000 tokens (5% of 100M) with terms: TGE = 5%, cliff = 6 months, vesting = 24 months.
```
Month 0 (TGE): 250,000
Month 1-6 (cliff): 250,000 (no change)
Month 7: 447,917
Month 18: 2,625,000
Month 30: 5,000,000 (100%)
```
### Vesting Types
| Type | Description | Use case |
|------|-------------|----------|
| **Linear** | Uniform unlock each period | Team, investors |
| **Stepped** | Quarterly block unlocks | Advisors, strategic partners |
| **Milestone-based** | Tied to KPI achievement | Grants, ecosystem fund |
| **Exponential** | Slow start, acceleration toward end | Staking rewards |
### Cumulative Unlock Chart
The most important allocation output is the **cumulative unlock chart**. It shows what percentage of total supply will be in circulation at any given time. An ideal chart has a smooth S-curve. Sharp steps are a red flag: they create "cliff events" when a large volume hits the market simultaneously.
## TGE: Initial Unlock
**TGE** (Token Generation Event) is the moment tokens are created and trading begins. The percentage unlocked at TGE affects initial market cap, sell pressure, and liquidity.
{{< formula math="MC_TGE = P_listing × CS_TGE" >}}
- MC_TGE — market cap at launch
- P_listing — listing price
- CS_TGE — circulating supply at TGE
{{< /formula >}}
### Typical TGE Unlock Ranges
| Group | Typical TGE% | Rationale |
|-------|-------------|-----------|
| **Team** | 0% | Demonstrates long-term commitment |
| **Seed investors** | 0–5% | Minimal liquidity for hedging |
| **Private investors** | 5–10% | Compensates for smaller discount |
| **Public sale** | 20–50% | Retail investors expect quick liquidity |
| **Airdrop** | 50–100% | Primary function is rapid distribution |
| **Liquidity** | 100% | Required from the first day of trading |
{{< callout type="info" title="MC/FDV considerations" >}}
Top-performing 2025 launches averaged ~15% initial float. There is no universal "golden rule" — the key factor is not MC/FDV alone but the absolute FDV: launches above $1B FDV showed a median -81% drawdown. Aim for MC/FDV of 10–20% with a realistic absolute FDV.
{{< /callout >}}
The most dangerous moments after TGE are the end of cliff periods for the team and large investors. The solution — **stagger cliff periods**: seed at 6 months, private at 9, team at 12.
## Allocation Model Types
The choice depends on project stage, regulatory environment, and capital-raising strategy.
| Parameter | Fair Launch | Private Sale | ICO / Public Sale | Launchpad |
|-----------|-------------|--------------|-------------------|-----------|
| **Sale participants share** | 0% | 20–35% | 60–90% | 5–15% |
| **Team share** | 0–10% | 15–20% | 10–20% | 15–20% |
| **Community share** | 60–100% | 30–45% | 10–20% | 40–55% |
| **TGE circulating** | 80–100% | 5–15% | 30–60% | 10–20% |
| **Example** | Bitcoin, memecoins | Most L1/L2 | EOS, Tezos (2017–18, model largely defunct) | Binance Launchpad |
**Fair launch** — all tokens through open mechanisms, no pre-sale rounds. Maximum decentralization, but the project receives no funding. **Private sale** — the most common model for infrastructure projects: long vesting, low TGE circulating. **Launchpad** — a hybrid: sale through an intermediary platform with a built-in audience.
{{< callout type="info" title="2024–2026 trend" >}}
The market is shifting toward "fairer" distributions: more airdrop allocation, smaller investor shares, faster vesting. Projects with MC/FDV below 10% at launch are losing community trust. Points-based farming before TGE has become the dominant community distribution strategy (Hyperliquid's ~$1.6B genesis airdrop being the largest recent example).
{{< /callout >}}
## Common Allocation Mistakes
{{< callout type="warning" title="Mistake 1: Team share too large" >}}
Allocation above 25% for the team raises a fair question: "Who is this token being created for?" Large investors will decline, and the community won't believe in decentralization.
{{< /callout >}}
{{< callout type="warning" title="Mistake 2: No cliff period" >}}
Team or investors without a cliff can sell from day one. Rule: **team cliff >= 6 months**, investor cliff >= 3 months. No exceptions.
{{< /callout >}}
{{< callout type="warning" title="Mistake 3: Synchronized cliff events" >}}
If the team, seed, and private cliffs all end in the same month, 15–25% of total supply hits the market simultaneously. Solution — stagger cliffs: seed at 6 months, private at 9, team at 12.
{{< /callout >}}
{{< callout type="warning" title="Mistake 4: Forgetting liquidity" >}}
At least 5% of total supply must be allocated for initial DEX liquidity. Without sufficient initial DEX liquidity, slippage can reach several percent even on moderate orders — verify the absolute dollar value is adequate for your target trading volume.
{{< /callout >}}
### Allocation Verification Checklist
{{< checklist type="check" >}}
Sum of all allocations = 100%
Team share <= 20%
Team cliff >= 6 months
Team vesting >= investor vesting
TGE circulating 10–25% (unless fair launch)
Liquidity >= 5%
Cliff events don't overlap (spread >= 3 months)
Maximum monthly unlock <= 5% of total supply
Community + ecosystem >= 30%
{{< /checklist >}}
## Planning Tools
Every allocation number should be modeled, visualized, and stress-tested.
### Google Sheets
Most allocations are modeled in Google Sheets. It is the primary working tool: transparent for investors and the team, easily extensible.
### Unlock Aggregators
For benchmarking, [Token Unlocks](https://token.unlocks.app/) is useful — an aggregator of unlock schedules for existing projects. You can see how competitors structure their allocation and compare parameters.
### Visualization: What to Show Investors
Minimum set for an investor presentation:
1. **Pie chart** — group shares as % of total supply
2. **Stacked area chart** — cumulative circulating supply by month
3. **Monthly unlock histogram** — shows sell pressure peaks
## Allocation Examples
Two anonymized patterns based on real projects of different types.
### Pattern 1: Infrastructure L1 Protocol
Venture funding $30M+, total supply 1B tokens.
| Group | Share | Cliff | Vesting | TGE% |
|-------|-------|-------|---------|------|
| **Team** | 18% | 12 mo | 48 mo | 0% |
| **Investors (seed + private + strategic)** | 20% | 3–6 mo | 12–24 mo | 0–10% |
| **Staking** | 25% | 0 | 72 mo | emission |
| **Ecosystem fund** | 15% | 0 | 48 mo | 2% |
| **Treasury** | 10% | 6 mo | 36 mo | 0% |
| **Liquidity + airdrop** | 9% | 0 | 0 | 100% |
| **Advisors** | 3% | 12 mo | 36 mo | 0% |
**TGE circulating ~10%.** Characteristic feature: large staking share (25%) with long emission — tokens enter circulation through a mechanism that requires locking.
### Pattern 2: DeFi Protocol with Airdrop Focus
One private round at $5M, total supply 100M tokens.
| Group | Share | Cliff | Vesting | TGE% |
|-------|-------|-------|---------|------|
| **Team** | 15% | 6 mo | 36 mo | 0% |
| **Investors** | 12% | 3 mo | 18 mo | 10% |
| **Airdrop** | 15% | 0 | 6 mo | 50% |
| **Liquidity** | 10% | 0 | 0 | 100% |
| **Protocol rewards** | 20% | 0 | 36 mo | 0% |
| **Treasury + grants** | 23% | 3 mo | 24 mo | 0% |
| **Advisors** | 5% | 6 mo | 24 mo | 0% |
**TGE circulating ~19%.** A large airdrop (15%) with fast unlock creates an "explosive" start, stimulating activity in the first weeks.
{{< callout type="info" title="General principle" >}}
The larger the investor share, the longer the vesting and lower the TGE unlock. Community shares, conversely, unlock faster — the goal is immediate user engagement.
{{< /callout >}}
---
## Related Articles
- [5 Token Supply Models]({{< relref "models/token-supply-models" >}}) — overview of all supply models including bonding curve, airdrop, and reward
- [What Is Tokenomics]({{< relref "/basics/what-is-tokenomics" >}}) — core concepts and project tokenomics structure
{{< cta title="Need an allocation model for your project?" text="We design token distribution, vesting schedules, and prepare models in Google Sheets." button="Get in touch" link="/quote/" >}}
---
## Token Velocity: Why Payment Tokens Lose Value
- URL: https://giantslabs.pro/models/token-velocity/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Token velocity and price: MV=PQ equation, the velocity paradox, velocity sinks (staking, burning, locking), interactive calculator, and Python simulation.
Here's the paradox: a project launches a token to pay for services. Users grow, transactions multiply — but the token price flatlines or drops. This isn't a bug. It's the **velocity problem** — a fundamental issue affecting all payment tokens, explained by a single formula from the 18th century.
## What Is Token Velocity
**Token velocity** is how many times a token changes hands in a given period. If 1 token participated in 10 transactions over a year, its velocity = 10.
{{< formula math="V = Volume / Avg_mcap" >}}
- V — velocity
- Volume — total volume over the period
- Avg_mcap — average market cap over the same period
{{< /formula >}}
Velocity reflects **holding time**: the faster a token moves through the "buy → use → sell" cycle, the higher V. Bitcoin with V ~5 is held for months. A utility token with V ~50 passes through a wallet in hours.
### Why This Is a Problem
High velocity means users **have no incentive to hold** the token. They buy the token at the moment of payment and immediately spend it. The service provider receives the token and immediately sells for stablecoins. Nobody holds — so there's no buy pressure, no scarcity, no price appreciation.
{{< callout type="warning" title="The payment token paradox" >}}
The more efficiently a token performs its payment function, the higher its velocity and the lower its justified price. The ideal medium of exchange is a terrible store of value.
{{< /callout >}}
## The Exchange Equation: MV = PQ
At the core lies Fisher's equation, adapted for tokenomics:
{{< formula math="MV = PQ" >}}
- M — token market capitalization
- V — velocity
- P — average price per unit of service
- Q — number of services paid for during the period
{{< /formula >}}
Rearranging for fundamental market cap:
{{< formula math="M = PQ / V" >}}
- M — justified market capitalization
- PQ — annual transaction volume ($)
- V — velocity
{{< /formula >}}
### What This Means in Practice
Suppose a protocol processes $50M in transactions per year. With different velocities, we get different justified market caps:
| Transaction volume (PQ) | Velocity (V) | Market cap (M) | Price at 100M tokens |
|---|---|---|---|
| $50M | 5 | $10M | $0.10 |
| $50M | 10 | $5M | $0.05 |
| $50M | 20 | $2.5M | $0.025 |
| $50M | 50 | $1M | $0.01 |
With the same transaction volume, increasing V from 5 to 50 **reduces justified market cap by 10x**. This is the velocity problem: a token can serve a massive throughput yet be worth pennies.
### Historical Context
The exchange equation was formulated by economist Irving Fisher in 1911 (as MV = PT, where T = transaction volume) to analyze money supply. The PQ variant (Q = quantity of goods) is an adaptation used in GDP analysis. Kyle Samani of Multicoin Capital adapted the framework for crypto in 2017 and showed that most utility tokens are destined for low valuations due to high velocity.
## Velocity Sinks: How to Slow Down Circulation
A **velocity sink** is a mechanism that forces or motivates holders to keep the token longer. The more tokens locked, the fewer in free circulation, the lower the effective velocity.
{{< formula math="V_eff = Volume / (Mcap − Locked)" >}}
- V_eff — effective velocity of freely circulating tokens (computed)
- Locked — value of locked tokens (staking, governance, collateral)
- Note: V_eff > V (locking concentrates transaction volume into a smaller free float). The price benefit comes not from lower velocity, but from reduced circulating supply — fewer tokens absorb the same transaction demand
{{< /formula >}}
### Types of Velocity Sinks
| Mechanism | How it works | Strength | Example |
|---|---|---|---|
| **Staking (PoS)** | Validators lock tokens to participate in consensus | Strong — economic risk (slashing) | ETH (32+ ETH per validator, ~30% of supply staked) |
| **Burning** | A portion of fees is permanently destroyed | Permanent — reduces supply | EIP-1559 (ETH base fee) |
| **Vote lock** | Tokens locked for governance participation | Medium — depends on DAO activity | veCRV (up to 4 years lock) |
| **Collateral** | Token used as bond or participation requirement | Strong — unlock requires repayment | FIL (storage provider pledge, up to 1,278 days after FIP-0052) |
| **Revenue sharing** | Holders receive a share of protocol income | Medium — higher yield = lower velocity | GMX (27% of fees via buyback-and-distribute in V2) |
| **Service contracts** | Tokens locked for the duration of a service | Medium — tied to business logic | Filecoin (storage contract) |
{{< callout title="Effective sink principle" >}}
A velocity sink only works if **holding is more profitable than selling**. Staking without real yield (rewards from emissions) isn't a sink — it's redistributed inflation. True sinks are tied to external protocol revenue.
{{< /callout >}}
### Impact of Sinks on Price
By combining mechanisms, a protocol can substantially reduce effective velocity:
{{< formula math="P = PQ / (V × S × (1 − L))" >}}
- P — fundamental price
- S — total supply
- L — share of locked tokens (0..1)
- At L = 0.5 and V = 20, the effect equals V = 10 with no locking
{{< /formula >}}
## Simulation: How Sinks Change Price Over Time
Consider a model protocol with growing transaction volume. We simulate 24 months and show how different mechanism combinations affect fundamental price.
**Simulation parameters:**
- Starting monthly volume: $2M, growing +5% per month
- Total supply: 100M tokens
- Velocity: 20
- Three scenarios: no sinks, staking (30% locked), staking + burning (30% + 0.5% of supply burned per month)
| Month | PQ (annual) | No sinks | Staking 30% | Staking + burn |
|---|---|---|---|---|
| 1 | $24.0M | $0.012 | $0.017 | $0.017 |
| 6 | $30.6M | $0.015 | $0.022 | $0.023 |
| 12 | $41.0M | $0.021 | $0.029 | $0.031 |
| 18 | $55.0M | $0.028 | $0.039 | $0.043 |
| 24 | $73.7M | $0.037 | $0.053 | $0.059 |
| **24-month growth** | **+207%** | **+207%** | **+207%** | **+245%** |
Staking uniformly scales price by +43% (multiplier 1/(1-0.3)). But burning **compounds**: by month 24, supply has decreased ~11%, providing additional price growth.
Python simulation code
```python
import pandas as pd
months = 24
initial_monthly_pq = 2_000_000 # $2M/month
growth_rate = 0.05 # +5% per month
total_supply = 100_000_000 # 100M
velocity = 20
staking_pct = 0.30 # 30% locked
burn_rate = 0.005 # 0.5% of supply burned per month
rows = []
supply_current = total_supply
for m in range(1, months + 1):
monthly_pq = initial_monthly_pq * (1 + growth_rate) ** (m - 1)
annual_pq = monthly_pq * 12
# No sinks
mcap_raw = annual_pq / velocity
price_raw = mcap_raw / total_supply
# Staking only
mcap_stake = annual_pq / (velocity * (1 - staking_pct))
price_stake = mcap_stake / total_supply
# Staking + burning
supply_current -= supply_current * burn_rate
mcap_burn = annual_pq / (velocity * (1 - staking_pct))
price_burn = mcap_burn / supply_current
rows.append({
'month': m,
'annual_pq': annual_pq,
'price_raw': price_raw,
'price_stake': price_stake,
'price_burn': price_burn,
'supply_after_burn': supply_current
})
df = pd.DataFrame(rows)
print(df[['month', 'annual_pq', 'price_raw', 'price_stake', 'price_burn']].to_string(index=False))
```
## Common Mistakes
{{< checklist title="What to avoid when designing velocity sinks" type="check" >}}
Staking without real yield. If rewards come from emissions rather than external protocol revenue, it's not a sink — it's inflation redistribution. Rewards from thin air don't create demand.
Burning without fee flow. If you burn tokens from the treasury rather than from fees, it's a temporary measure that ends when the treasury runs out. Sustainable burning is tied to transaction volume.
Confusing velocity with liquidity. Low velocity does not mean low liquidity. ETH has moderate velocity (~5) but enormous liquidity. A token with V = 100 and zero order book depth is a bad combination.
Ignoring speculative demand. The MV=PQ model describes fundamental valuation. In reality, price can be 10–100x higher due to speculation — but also 10x lower when hype fades.
Creating forced locks. Mandatory locking without benefit frustrates users and increases sell pressure after unlock. Holding should be an economically rational choice, not a prison.
{{< /checklist >}}
## Case Study: Lessons from TON
The TON blockchain illustrates the velocity problem at scale. Data from the network's 2024–2025 dynamics shows a classic imbalance.
### The Numbers
| Metric | 2024 (peak) | Early 2025 | Change |
|---|---|---|---|
| Wallet activations | ~100M+ | ~165M+ | +53% |
| Daily transactions | ~4.3M (Dec peak) | ~1.7M | −60% |
| Fees (TON/day) | ~16,000 | ~5,200 | −68% |
| Minting (TON/day) | ~70,000 | ~88,000 | +26% |
More wallets activated, but transactions and fees collapsed. Meanwhile, emissions grew 26%. Tokens are being generated significantly faster than demand for their use is created.
{{< callout type="info" title="April 2026 update: Catchain 2.0" >}}
On April 9, 2026, TON activated Catchain 2.0 (6x faster blocks). Minting surged to ~545,000 TON/day, pushing annualized inflation from ~0.6% to ~3.6%. This makes the velocity problem even more acute.
{{< /callout >}}
### Analysis Through MV = PQ
For TON in early 2025: daily fees ~5,200 TON. At ~$3 per TON at the time (mid-2025 prices varied significantly — from ~$6 to ~$1.4), annual fee PQ ≈ $5.7M. With velocity ~15 and circulating supply of ~2.5B (total supply ~5.1B, but roughly half is frozen in inactive early wallets):
{{< formula math="P_fund = $5.7M / (15 × 2.5B) ≈ $0.00015" >}}
- Fundamental valuation of TON via the MV=PQ model (computed)
- Thousands of times lower than market price (~$1.4 in April 2026)
- The gap is covered by speculative demand and ecosystem growth expectations
- Note: using total supply (5.1B) halves the result further; the choice of circulating vs total supply matters
{{< /formula >}}
This doesn't mean TON is "overvalued" in the traditional sense — the market price incorporates expectations of future transaction volume growth and ecosystem development. But the model shows that **current fundamental demand** is insufficient to support the price without a speculative component.
{{< callout type="info" title="What TON could do" >}}
Increasing fundamental valuation is possible through: (1) growing DeFi activity and fees, (2) introducing EIP-1559-style burning, (3) increasing the staking ratio with real slashing, (4) locking for ecosystem governance participation.
{{< /callout >}}
## Advanced Analysis: Combining Mechanisms
The most resilient projects combine multiple velocity sinks. Here's how market leaders do it:
| Project | Staking | Burning | Governance | Revenue sharing | Eff. V |
|---|---|---|---|---|---|
| **Ethereum** | ~30% in PoS | EIP-1559 + gas burn | No | No | ~5 |
| **Curve** | No | No | veCRV up to 4 years | 50% of fees | ~3 |
| **GMX** | Yes | No | No | 27% of fees (V2 buyback) | ~4 |
| **Filecoin** | Pledge up to 1,278 days | No | No | No | ~8 |
| **BNB** | No | Quarterly auto-burn + real-time gas burn | No | Fee discount | ~12 |
Ethereum combines staking (strong lock) and burning (permanent supply reduction) — resulting in one of the lowest effective velocities on the market. Curve achieves even lower velocity through extremely long locks (up to 4 years) in exchange for revenue sharing. Note: the Eff. V estimates above are approximate order-of-magnitude values based on on-chain transfer volume relative to market cap; exact numbers depend on methodology and measurement period.
### Combined Effect Formula
{{< formula math="P = PQ / (V × S_0 × (1 − L) × (1 − B)^t)" >}}
- S₀ — initial supply
- L — share of locked tokens
- B — monthly burn rate
- t — number of months
- Mechanisms multiply each other's effect
{{< /formula >}}
{{< cta title="Token velocity killing your price?" text="We analyze velocity dynamics and design sink mechanisms for utility tokens. From MV=PQ modeling to staking and burn parameter optimization." button="Get in touch" link="/quote/" >}}
---
## Tokenized Loyalty for Investment Funds: Turning Retention Cashback into a Real-Yield Dividend Token
- URL: https://giantslabs.pro/models/loyalty-token-investment-fund/
- Section: models
- Date: 2026-06-28
- Last modified: 2026-06-28
- Description: How to design a tokenized loyalty program for an investment fund: route retention cashback through a bonding curve to mint a dividend token, pay real yield in USDC from the profit split, and value it by dividend discount—not speculation.
A traditional loyalty program is a cost center. You hand out points or cashback, the user spends them, and the money leaves the building. For an investment fund the problem is sharper still: the thing you most want to reward—a client keeping capital with you for years—is exactly the behavior a points coupon does almost nothing to encourage.
So flip the design. Instead of cashback that the client spends and forgets, route that cashback into a token. Make the token mint on a bonding curve, so early and loyal participants get more of it. Then connect the token to something real: a slice of the fund's actual profit, paid out in USDC. Now the "loyalty reward" is not a discount coupon—it is a claim on a stream of dollars, and the earlier a client joined and the longer they stay, the larger their share of that stream.
This article is a working design guide for that token—a tokenized loyalty program built on real fund yield rather than marketing spend. It covers the mechanism end to end, the math you need to size it, an interactive calculator to feel the dynamics, and—most importantly—the one structural mistake that quietly kills this design if you let it.
## What this is (and what it is not)
First, a distinction that trips up almost everyone. "Tokenizing a fund" usually means putting the fund's *shares* on-chain: a money-market fund issues a token, one token equals one share, and the token's value tracks NAV. That is fund-share tokenization, and it is a different product entirely.
The design here is a **loyalty layer that sits on top of the fund**, not a share class. Clients still subscribe to the fund the normal way. The token is a *retention reward*—earned by staying invested—that happens to carry a dividend funded by fund performance. The fund's economics are untouched; the token is an additional incentive instrument wrapped around them.
The whole machine has five moving parts:
{{< schema "mechanism/loyalty-token-fund-flow" >}}
1. **The fund.** Capital flows in monthly and churns out when each cohort's lifetime expires. Active AUM is always *attracted minus churned*.
2. **Retention cashback.** While capital stays in the fund, cashback accrues monthly on a *declining* ladder. It is never paid as cash—it is routed straight into the token.
3. **The bonding curve.** Each cashback dollar is priced through a power-law curve. Earlier dollars mint cheaply; the mint price rises as the program grows. No reserve sits behind the curve—it is a pricing formula, not an exchange.
4. **The profit split.** Each period the fund's profit is split three ways—investors, manager, and a small slice to the token's dividend pool.
5. **Staking with a duration multiplier.** Token holders stake to claim the dividend pool in USDC, weighted by how long they have been staked.
The rest of this article makes each part precise.
## The math
### The cashback ladder
The loyalty lever is a *declining* cashback schedule: high in month one to reward the decision to commit, tapering as the relationship matures. A typical shape, as a monthly percentage of the deposited principal:
| Months in fund | Monthly cashback |
|---|---|
| Month 1 | 1.00% |
| Months 2–6 | 0.50% |
| Months 7–12 | 0.25% |
| Month 13+ | 0.10% |
The point is not these exact numbers—they are illustrative—but the *direction*. Cashback accrues only while the capital stays in. Pull out early and you forfeit the rest of the schedule. That is what makes it a retention instrument rather than a sign-up bonus. (The off-chain ancestor of this lever is the classic [points program]({{< relref "models/points-systems" >}})—same psychology, no token.)
### Routing cashback through the bonding curve
Each cashback dollar is converted into tokens at the curve's current mint price. We price in *cumulative cashback routed so far*, written `L`. The mint price is a power law:
{{< formula math="P_mint(L) = P0 × ((β + L) / β)^α" >}}
- L — cumulative cashback dollars routed through the curve so far ($)
- P0 — base mint price at L = 0 ($/token)
- β — scaling constant that flattens the early part of the curve
- α — steepness exponent (0 < α < 1 keeps growth sub-linear)
- P_mint(L) — the marginal mint price at cumulative routed cashback L (computed, $/token)
{{< /formula >}}
To mint tokens you do not divide a lump of cashback by a single price—the price moves as you mint. You integrate. Routing `C` dollars starting from cumulative `L` mints, in closed form:
{{< formula math="tokens(C) = (β^α / (P0·(1−α))) × ((β + L + C)^(1−α) − (β + L)^(1−α))" >}}
- C — cashback dollars routed this period ($)
- L — cumulative cashback already routed before this period ($)
- P0, α, β — curve parameters as above
- tokens(C) — tokens minted by routing C dollars (computed). At α = 1 the closed form becomes the logarithmic branch tokens = (β/P0)·ln((β+L+C)/(β+L))
{{< /formula >}}
The average price actually paid over that mint is just `C / tokens(C)`, and it always lands between the spot price before (`P_mint(L)`) and after (`P_mint(L+C)`)—a useful sanity check when you implement it. This is the same closed-form-integral discipline used in any [bonding-curve mint]({{< relref "models/bonding-curve" >}}); here the "buyer" is simply the cashback stream rather than a public market.
A reference implementation, so there is no ambiguity when it reaches a contract:
Mint math—reference implementation (JavaScript)
```js
// Power-law bonding curve priced in cumulative cashback routed (L).
function mintPrice(L, P0, alpha, beta) {
return P0 * Math.pow((beta + L) / beta, alpha);
}
// Tokens minted by routing C dollars starting from cumulative L.
// Closed form of the curve integral; log branch handles alpha === 1.
function tokensMinted(C, L, P0, alpha, beta) {
if (C <= 0) return 0;
if (Math.abs(alpha - 1) < 1e-9) {
return (beta / P0) * Math.log((beta + L + C) / (beta + L));
}
const k = Math.pow(beta, alpha) / (P0 * (1 - alpha));
return k * (Math.pow(beta + L + C, 1 - alpha) - Math.pow(beta + L, 1 - alpha));
}
// Average price paid over the mint — must sit between spot-before and spot-after.
function avgMintPrice(C, L, P0, alpha, beta) {
const t = tokensMinted(C, L, P0, alpha, beta);
return t > 0 ? C / t : NaN;
}
```
With `P0 = 1`, `α = 0.45`, `β = 10,000`, here is how the mint price and the cumulative token supply evolve as cashback accumulates:
| Cumulative cashback routed (L) | Mint price P_mint(L) | Cumulative tokens minted | Average price so far |
|---|---|---|---|
| $0 | $1.00 | 0 | — |
| $250,000 | $4.33 | ~91,000 | ~$2.75 |
| $500,000 | $5.87 | ~140,000 | ~$3.57 |
| $1,000,000 | $7.98 | ~212,000 | ~$4.72 |
| $2,300,000 | $11.58 | ~345,000 | ~$6.67 |
| $5,000,000 | $16.40 | ~537,000 | ~$9.31 |
Early cashback mints cheaply and abundantly; later cashback mints a thinner stream at a higher price. That asymmetry is the reward for loyalty: the clients who were in early, and stayed, hold a disproportionate share of the supply.
## Calculator: loyalty-token mint and dividend
The two halves of the design—minting on the curve, and the dividend each staked token earns—are best felt by moving the sliders. The top group drives the curve; the bottom group drives the real-yield side. Watch how the *fair value* of a token (its dividend discounted at your required return) responds to fund performance and to how many tokens are staked against the same pool.
Loyalty-token mint & dividend
Minting — bonding curve
Dividend — real yield
Tokens minted this month
8,343
New mint price (at L+C)
$6.1191
Avg mint price
$5.9932
Dividend / staked token / yr
$1.000
Fair token value
$6.6667
Cumulative cashback (L)
Mint price P_mint(L)
Cumulative tokens
Avg price so far
Fair value = (dividend per staked token per year) ÷ (required return). Because the profit share is taken above a high-water mark, the dividend floors at zero: a flat or down year pays nothing (never a negative dividend), and fair value is then N/A because a zero stream has zero present value. The dividend card simplifies the per-token math to a single pooled rate; the duration multiplier and per-strategy pools (below) redistribute this within the staker base.
## Implementation: wiring the real yield
Minting is only half the design. A token that mints forever and pays nothing is just inflation. The other half is the dividend, and it comes from the fund's own profit.
### The 80 / 15 / 5 split
Each period, the fund's profit above its high-water mark is split three ways:
{{< checklist title="Profit split" type="check" >}}
80% to investors — their share of the fund's gains, exactly as a normal fund pays
15% to the manager — the performance fee. The flat management fee is separate and untouched
5% to the staker dividend pool — paid in USDC to whoever has staked the loyalty token
{{< /checklist >}}
That last 5% is the only new claim on fund economics. It is small enough that investors and the manager barely feel it, and it is the entire fuel supply for the token's value. The dividend each staked token earns, in the simplest pooled form:
{{< formula math="dividend_per_token_yr = (AUM × annual_return × staker_share) / staked_tokens" >}}
- AUM — active assets under management generating profit ($)
- annual_return — the fund's annual return (fraction; because profit is taken above a high-water mark, the dividend floors at zero in a flat or down year, never going negative)
- staker_share — the slice routed to the pool (here 0.05)
- staked_tokens — total tokens staked against the pool
- dividend_per_token_yr — USDC paid per staked token per year (computed)
{{< /formula >}}
Because this is a real cash flow, the token has a defensible valuation that has nothing to do with hype. Discount the dividend at a required return and you get a fair value—the same dividend-discount logic used for equities, and a close cousin of [DCF token valuation]({{< relref "knowledge/dcf-token-valuation" >}}):
{{< formula math="fair_value = dividend_per_token_yr / required_return" >}}
- dividend_per_token_yr — annual USDC per staked token (from above)
- required_return — the discount rate a holder demands (fraction)
- fair_value — present value of the perpetual dividend stream ($/token)
{{< /formula >}}
### The duration multiplier
To reward loyalty on the *staking* side too, weight each staker's claim by how long they have been staked—a vote-escrow multiplier, the same primitive behind [veTokenomics]({{< relref "models/ve-tokenomics" >}}):
{{< formula math="m = 1 + 1.5 × (months_staked / 48), capped at 2.5×" >}}
- months_staked — how long the position has been staked (months)
- m — multiplier applied to that position's share of the dividend pool (computed, 1.0× to 2.5×)
{{< /formula >}}
A neat property falls out of the minting design: tokens minted earlier have, by construction, been around longer, so the loyal early cohort carries the higher multipliers and captures a disproportionate share of the pool. Loyalty compounds on both axes at once—though both are bounded: the cashback ladder declines, so later tokens are fewer and pricier, and the multiplier caps at 2.5× after 48 months. The reward for staying is real but plateaus; it is not unbounded.
### Multi-strategy staking
If the fund runs several strategies, compute the 5% pool *per strategy* and let stakers choose which strategy pool to back—independently of where their own capital sits. Now the distribution of staked tokens across strategies can diverge from the distribution of AUM. When a higher-returning strategy is *under*-staked relative to its share of profit, each token staked there earns far more than the blended average. Picking the right pool becomes a genuine, separate source of return for an attentive staker—and a partially self-balancing mechanism, since stake chases the richest pools. The balancing is sticky, not instant: moving a position to a new pool resets its duration multiplier, so a staker forfeits accrued ve-weight to chase yield, and per-pool yields converge slowly rather than snapping to parity.
## Where it breaks: the secondary-market trap
Here is the failure mode that destroys this design more often than any other, and it is worth a hard warning.
{{< callout title="Do not bolt a public market onto a dividend-only loyalty token" type="warning" >}}
The token above has exactly one source of value: the USDC dividend, gated to KYC-verified, eligible holders. The moment you also list it on a public exchange or seed a one-sided liquidity pool "so it has a price," you create an instrument that outside buyers have **no rational reason to hold**:
- They are **gated out of the dividend** by design—so they get no yield.
- The **utility** (fee discounts, access tiers) is usually not live at launch—so they get no use.
- If a treasury "anchors" the price, there is **no upside**—so they get no appreciation.
What they *can* do is sell. With sell-side-only liquidity, a single modest sell order craters the quoted price, the headline market cap turns out to be backed by a thread of real liquidity, and the chart becomes a liability that scares off the very clients the program was meant to retain. You have manufactured a slow-motion price collapse for a token that, left as a closed dividend instrument, never needed a market at all.
{{< /callout >}}
The discipline is simple: **choose one design.** Either the token is a closed, no-secondary-market dividend instrument (recommended)—where a holder's only way to realize value is the dividend stream itself, since the curve offers no redemption—or it is a freely traded token with a genuine reason for the public to buy: real utility, an open dividend, or a buyback that actually catches sellers. A dividend token's value does *not* depend on a secondary market; this is the same insight that makes a no-buyback model coherent, the mirror image of the choices in [buyback engineering]({{< relref "models/buyback-engineering" >}}). Trying to have both at once gives you the worst of each.
Two smaller traps worth pre-empting:
- **Withdraw-and-redeposit farming.** If cashback resets favorably on every new deposit, clients will churn their own capital to re-farm the high first-month rate. Defend with either KYC-linked accrual that follows the client, not the deposit, or a *tenure-weighted* ladder that rewards continuous time in the fund rather than each fresh entry.
- **The down year.** Because the profit share is taken above a high-water mark, a flat or down year pays a zero dividend—never a negative one, since stakers are never charged. Fair value is simply undefined that year, as a zero stream has no present value. Communicate the token as a *variable* real-yield instrument from day one, not a fixed coupon, so a zero-dividend year is a known feature rather than a broken promise.
## Advanced: regulation and honest valuation
### A dividend token is a security—wrap it, don't deny it
Apply the economic-substance test to "stake the token, receive USDC from fund profits" and you get an investment contract. The defensible posture is not to argue otherwise but to **split the instrument**:
{{< callout title="The hybrid line" type="info" >}}
- The **open token** circulates freely (AML-screened): it carries utility—fee discounts, access tiers, governance over platform parameters—and confers no automatic right to yield. Designed well, this leg reads as a consumptive utility instrument.
- The **dividend entitlement** (the 5% USDC stream) is a separate, KYC/eligibility-gated claim, delivered through a regulated wrapper. Only verified, eligible holders can enter a yield-earning stake.
Keep the yield leg small, gated, and wrapped; keep the open token genuinely useful. Size any fee discount so it reads as loyalty, not a disguised return. Bifurcation reduces securities risk but does not eliminate it: regulators can collapse the two legs back into one instrument if the open token's value visibly derives from the same program. None of this is legal advice—get qualified counsel in every jurisdiction you touch before launch.
{{< /callout >}}
This separation is what lets the same underlying token be both a loyalty reward anyone can earn and a regulated yield instrument only eligible investors can monetize. It rhymes with the broader menu of [tokenized equity instruments]({{< relref "knowledge/tokenized-equity-instruments" >}}), where the payoff shape decides the regulatory treatment.
### Value it as what it is
The honest conclusion is unglamorous and exactly the point: this token is a **dividend-plus-utility instrument**, not a speculative large-cap. Its worth is the present value of the USDC stream plus its fee-utility demand—nothing more, nothing less. Run the calculator above with a realistic fund return and staked supply and you will get a fair value in single-digit-to-low-double-digit dollars, not a moonshot. That is a feature. A loyalty program that pays a credible, modeled, real dividend will retain clients far longer than one promising a number that the math never supported.
{{< cta title="Designing a loyalty or dividend token for a fund?" text="We model the curve, size the dividend split, stress-test the retention incentives, and keep the regulatory line clean—before anything ships on-chain." button="Talk to us" link="/services/" >}}
---
## Tokenomics Simulations: Monte Carlo to Agent-Based Models
- URL: https://giantslabs.pro/models/simulations/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Simulation methods for tokenomics: sensitivity analysis, scenario analysis, Monte Carlo, agent-based modeling. Python code, charts, and method comparison.
## Why Simulate Tokenomics
A spreadsheet model is a single scenario: "given these parameters, here's the result." But parameters are always imprecise. Will 5,000 or 50,000 users show up? What percentage will stake? When will investors start selling?
Simulation answers not "what will happen" but "what could happen and with what probability." Instead of one forecast — a distribution of outcomes. Instead of "the price will be $0.50" — "in 90% of scenarios, the price stays above $0.30."
This article covers four levels of simulation, from simple to complex. Each level adds precision but also requires more data and code.
## Level 1: Sensitivity Analysis
The simplest method. Take a spreadsheet model, vary one parameter while holding all others fixed. See how the output depends on that parameter.
### When to Use
- At the early design stage — to understand which parameters are critical
- When tuning bonding curve, emission, or vesting parameters
- To answer "what breaks first"
### Example: Staking Sensitivity to APR
A protocol emitting 800 tokens/day. Question: at what staking percentage does APR fall below 5% (the threshold where large stakers leave)?
Result: above ~58% staking, APR approaches 5%. The exact threshold is ~58.4%. If the model assumes 60% staking, the system operates below the threshold.
| Staking percentage | APR | Status |
|---|---|---|
| 20% | 14.6% | Safe |
| 40% | 7.3% | Acceptable |
| 58% | 5.03% | Near threshold |
| 60% | 4.9% | Below threshold |
| 80% | 3.7% | Critical |
Python: sensitivity analysis code
```python
import numpy as np
import matplotlib.pyplot as plt
total_supply = 10_000_000
daily_rewards = 800
staking_pcts = np.linspace(0.1, 0.9, 50) # 10% to 90% staking
aprs = (daily_rewards * 365) / (total_supply * staking_pcts)
fig, ax = plt.subplots(figsize=(10, 5))
ax.plot(staking_pcts * 100, aprs * 100, linewidth=2.5, color='#2563eb')
ax.axhline(y=5, color='#dc2626', linestyle='--', label='5% APR threshold')
ax.fill_between(staking_pcts * 100, aprs * 100, 5,
where=(aprs * 100 < 5), alpha=0.15, color='#dc2626')
ax.set_xlabel('Staking percentage (%)')
ax.set_ylabel('APR (%)')
ax.set_title('APR sensitivity to staking percentage')
ax.legend()
ax.grid(True, alpha=0.3)
plt.tight_layout()
plt.show()
```
{{< callout title="Method limitation" >}}
Sensitivity analysis varies one parameter at a time. In reality, parameters are interdependent: user growth increases both staking and sell pressure. To account for interdependencies, you need the next level — scenario analysis.
{{< /callout >}}
## Level 2: Scenario Analysis
Fix a set of parameters for each scenario. The standard approach is three scenarios:
| Parameter | Pessimistic | Base | Optimistic |
|----------|-------------|------|------------|
| Users (month 12) | 5,000 | 20,000 | 80,000 |
| Staking % | 30% | 50% | 70% |
| Churn | 15%/mo | 8%/mo | 3%/mo |
| Sell pressure (investors) | 80% after cliff | 50% | 20% |
### What It Shows
In the pessimistic scenario, sell pressure is 1.6M tokens/mo (80% of 2M unlock), and free float grows faster (few stakers). This is a double hit on price.
In the optimistic scenario, only 400K/mo is sold and 70% is staked. Sell pressure is 4x lower.
| Metric | Pessimistic | Base | Optimistic |
|---|---|---|---|
| Sell pressure | 1.6M/mo | 1.0M/mo | 0.4M/mo |
| Free float (month 12) | 23.8M | 17.0M | 10.2M |
| Monthly sell / float ratio (month 12) | 6.7% | 5.9% | 3.9% |
Python: scenario analysis code
```python
import numpy as np
import matplotlib.pyplot as plt
months = np.arange(1, 25)
scenarios = {
'Pessimistic': {
'users_final': 5_000,
'stake_pct': 0.30,
'sell_pressure': 0.80,
'color': '#dc2626'
},
'Base': {
'users_final': 20_000,
'stake_pct': 0.50,
'sell_pressure': 0.50,
'color': '#2563eb'
},
'Optimistic': {
'users_final': 80_000,
'stake_pct': 0.70,
'sell_pressure': 0.20,
'color': '#16a34a'
}
}
total_supply = 100_000_000
initial_circulating = 10_000_000 # TGE
monthly_unlock = 2_000_000 # investor vesting
fig, axes = plt.subplots(1, 2, figsize=(14, 5))
for name, s in scenarios.items():
circulating = np.zeros(len(months))
net_sell = np.zeros(len(months))
for i, m in enumerate(months):
unlocked = min(initial_circulating + monthly_unlock * m, total_supply)
staked = unlocked * s['stake_pct']
free_float = unlocked - staked
sell_tokens = monthly_unlock * s['sell_pressure']
circulating[i] = free_float
net_sell[i] = sell_tokens
axes[0].plot(months, circulating / 1e6, label=name,
color=s['color'], linewidth=2)
axes[1].plot(months, net_sell / 1e6, label=name,
color=s['color'], linewidth=2)
axes[0].set_title('Free float (M tokens)')
axes[0].set_xlabel('Month')
axes[0].legend()
axes[0].grid(True, alpha=0.3)
axes[1].set_title('Sell pressure (M tokens/mo)')
axes[1].set_xlabel('Month')
axes[1].legend()
axes[1].grid(True, alpha=0.3)
plt.tight_layout()
plt.show()
```
{{< callout type="warning" title="The scenario analysis problem" >}}
Three scenarios are three data points. What's the probability of each? What lies between them? Scenario analysis doesn't answer these questions. For that, you need Monte Carlo.
{{< /callout >}}
## Level 3: Monte Carlo
The Monte Carlo method runs thousands of random scenarios. Instead of fixed parameters, you define distributions: "users will be between 5,000 and 80,000, most likely around 20,000." The model runs 1,000–10,000 times with different random values.
The result is not a single point or three points, but a full distribution of outcomes with percentiles and confidence intervals.
### How It Works
1. Define input parameters and their distributions
2. On each iteration, sample values from distributions
3. Run the model, record the result
4. Repeat 1,000–10,000 times
5. Analyze the result distribution
### Choosing Distributions
| Parameter | Distribution | Why |
|----------|-------------|-----|
| Number of users | Log-normal | Growth can be explosive but never negative |
| Staking percentage | Beta(5,5) or Truncated Normal | Bounded between 0 and 1; Beta(5,5) centers at 50%, tune α/β to shift the mode |
| Sell pressure | Beta(2,5) or Truncated Normal | Same — a proportion between 0 and 1; Beta(2,5) skews toward low sell pressure |
| Time to sell | Exponential | Most sell quickly, few wait long |
| Token price | Log-normal | Multiplicative dynamics, never negative |
### Example: Treasury Sustainability
A protocol raised $5M at TGE. The team spends money but earns fees from users. Question: will the treasury last 36 months?
The model has four parameters. Each is sampled from a distribution because the exact value is unknown upfront:
| Parameter | Distribution | Range | Rationale |
|----------|-------------|-------|-----------|
| Monthly burn rate | Log-normal (median $150K, σ=0.3) | $90K–$250K | Salaries, infrastructure, marketing. Log-normal because expenses can't be negative but can spike |
| User growth | Normal (μ=8%, σ=4%) | 0%–16%/mo | Organic growth with high uncertainty |
| Revenue per user | Uniform ($2–$8/mo) | $2–$8 | Protocol fees. Range based on benchmarks (DeFi: $3–$5, GameFi: $1–$2) |
| Initial users | Log-normal (median 2,000, σ=0.5) | 800–5,000 | Depends on TGE marketing success |
Dependencies within the model:
- Revenue = users × revenue_per_user (more users → more revenue)
- Burn rate grows 2%/mo (salary inflation, team growth)
- Treasury balance = previous balance + revenue − expenses
- If balance hits 0 — the protocol can't fund operations
Results from 2,000 runs:
| Metric | Value |
|--------|-------|
| Median (P50) balance at month 24 | ~$1.4M |
| 5th percentile (P5) at month 24 | ~$0.0M |
| 95th percentile (P95) at month 24 | ~$4.2M |
| Share of runs with zero balance by month 36 | ~48% |
Key takeaway: in ~48% of runs, the treasury is depleted before month 36. This means with current parameters, the protocol has only ~52% chance of surviving three years without additional fundraising. If the acceptable risk threshold is 5%, you need to either cut the burn rate or increase initial treasury to ~$10M.
Python: Monte Carlo simulation code
```python
import numpy as np
import matplotlib.pyplot as plt
np.random.seed(42)
n_simulations = 2000
n_months = 36
initial_treasury = 5_000_000 # $5M
results = np.zeros((n_simulations, n_months))
for sim in range(n_simulations):
treasury = initial_treasury
# Sample parameters once per run (inter-run variability).
# In more advanced models, parameters can vary month-to-month.
# Note: parameters are sampled independently here — see "pitfalls" below.
monthly_burn = np.random.lognormal(mean=np.log(150_000), sigma=0.3)
user_growth = np.random.normal(0.08, 0.04) # 8% ± 4% growth/mo
revenue_per_user = np.random.uniform(2, 8) # $/user/mo
initial_users = np.random.lognormal(mean=np.log(2000), sigma=0.5)
users = initial_users
for month in range(n_months):
users *= (1 + max(user_growth + np.random.normal(0, 0.02), -0.1))
revenue = users * revenue_per_user
burn = monthly_burn * (1 + 0.02 * month) # expenses grow 2%/mo
treasury = treasury + revenue - burn
results[sim, month] = max(treasury, 0)
# === Visualization ===
fig, axes = plt.subplots(1, 2, figsize=(14, 5))
months = np.arange(1, n_months + 1)
p5 = np.percentile(results, 5, axis=0)
p25 = np.percentile(results, 25, axis=0)
p50 = np.percentile(results, 50, axis=0)
p75 = np.percentile(results, 75, axis=0)
p95 = np.percentile(results, 95, axis=0)
axes[0].fill_between(months, p5/1e6, p95/1e6, alpha=0.1, color='#2563eb')
axes[0].fill_between(months, p25/1e6, p75/1e6, alpha=0.2, color='#2563eb')
axes[0].plot(months, p50/1e6, color='#2563eb', linewidth=2, label='Median')
axes[0].plot(months, p5/1e6, color='#dc2626', linewidth=1,
linestyle='--', label='5th percentile')
axes[0].axhline(y=0, color='black', linewidth=0.5)
axes[0].set_xlabel('Month')
axes[0].set_ylabel('Treasury ($M)')
axes[0].set_title('Monte Carlo: treasury balance')
axes[0].legend()
axes[0].grid(True, alpha=0.3)
bankrupt_by_month = np.zeros(n_months)
for month in range(n_months):
bankrupt_by_month[month] = np.mean(results[:, month] == 0) * 100
axes[1].bar(months, bankrupt_by_month, color='#dc2626', alpha=0.7)
axes[1].set_xlabel('Month')
axes[1].set_ylabel('% of runs with empty treasury')
axes[1].set_title('Cumulative bankruptcy probability')
axes[1].grid(True, alpha=0.3)
plt.tight_layout()
plt.show()
```
### How to Read Results
| Metric | What it shows | Example |
|--------|--------------|---------|
| Median (P50) | Most likely outcome | Treasury = $1.4M at month 24 |
| 5th percentile (P5) | Worst realistic scenario | Treasury = $0.0M at month 24 |
| 95th percentile (P95) | Best realistic scenario | Treasury = $4.2M at month 24 |
| Probability of event | Chance of a specific outcome | 48% of runs: treasury = 0 by month 36 |
| VaR (Value at Risk) | Maximum loss at given probability | VaR 95% at month 12: treasury loss ≈ $3.05M (P5 balance ≈ $1.95M) |
{{< callout title="The 5th percentile rule" >}}
Design tokenomics so the system remains functional at the 5th percentile (worst 5% of runs). If at P5 the treasury hits zero at month 18 but runway should be 24 — the model needs rethinking.
{{< /callout >}}
### Common Mistakes
{{< checklist title="Monte Carlo pitfalls" type="curve" >}}
Correlated parameters sampled independently. If user count grows, treasury load grows too. Use copulas or joint distributions
Distributions too wide. "Users from 100 to 10,000,000" is not informative. Narrow ranges based on comparables
Too few iterations. 100 runs won't produce stable percentiles. Minimum 1,000, ideally 5,000
Ignoring tails. The average result isn't interesting — extreme scenarios matter
{{< /checklist >}}
## Level 4: Agent-Based Modeling
Monte Carlo varies parameters, but the model within each run remains deterministic: formulas compute from start to finish. Agent-based modeling (ABM) adds another layer — the behavior of individual participants.
In ABM, each user is a separate agent with their own balance, strategy, and decision rules. At each step, agents react to the current system state, and their actions change that state for everyone else.
This enables modeling emergent effects: cascading staking exits, governance attacks, bank runs on liquidity pools — everything that can't be expressed as a formula.
### When ABM Is Needed
- Staking with uneven distribution (whales)
- AMM and liquidity pools
- Governance with voting
- Any system with feedback loops between participants
Tools for ABM in tokenomics: **radCAD** (actively maintained Rust+Python framework by CADLabs), **Mesa** (general-purpose ABM framework), and **cadCAD** (the original crypto-economic simulation framework; development has slowed, with the last release v0.5.3 in 2024 and most active work moving to radCAD).
## Method Comparison
| | Sensitivity analysis | Scenario | Monte Carlo | ABM |
|---|---|---|---|---|
| Complexity | Low | Low | Medium | High |
| Number of outcomes | N points | 3–5 | 1,000+ | 1,000+ |
| Parameter interdependencies | No | Manual | Via distributions | Via behavior |
| Emergent effects | No | No | No | Yes |
| Tools | Google Sheets | Google Sheets | Python / R | Python (radCAD, Mesa) |
| When to use | Early stage | Investor presentation | Model stress test | Complex mechanisms |
### Which Method at Which Stage
{{< checklist title="Workflow" type="step" >}}
Sensitivity analysis — identify which parameters are critical. This takes an hour in a spreadsheet
Scenario analysis — show 3 scenarios to investors and team. A shared language for decision-making
Monte Carlo — test robustness: "in what percentage of runs does everything break?" Requires Python
Agent-based modeling — if the system has participants with competing strategies and feedback between actions
{{< /checklist >}}
## Combining Methods
In practice, methods don't exclude each other. A typical project workflow:
1. Spreadsheet — allocation, vesting, basic unit economics
2. Sensitivity analysis — find the parameters the model is most sensitive to
3. Monte Carlo — 2,000 runs on key parameters, get percentiles
4. ABM — for critical mechanisms (staking, AMM, governance), build an agent model and run 100+ iterations
Each step informs the next: sensitivity analysis shows what to vary in Monte Carlo. Monte Carlo shows where ABM is needed.
{{< formula math="P(System_functional) ≥ 0.95" >}}
- P(System_functional) — share of Monte Carlo runs where the system remains functional through the horizon
- Evaluated over all random parameter samples
{{< /formula >}}
{{< formula math="System_functional(P5_inputs) = True" >}}
- P5_inputs — fixed 5th-percentile value of each parameter
- System_functional — binary check: the system doesn't break
- Deterministic verification, not a probability
{{< /formula >}}
## Practical Guidelines
### When a Spreadsheet Is Enough
- Allocation and vesting — fixed schedules, nothing to simulate
- Unit economics at early stage — no data yet for distributions
- Presenting the concept to investors — simplicity is needed, not percentiles
### When You Need Monte Carlo
- Treasury design — the key question is "will the money last"
- Emission parameter tuning — at what values does inflation spiral out of control
- Runway estimation — project lifespan under different growth scenarios
### When You Need ABM
- Staking with uneven distribution (whales)
- AMM and liquidity pools
- Governance with voting
- Any system with feedback loops between participants
{{< cta title="Need a simulation for your project?" text="We stress-test tokenomics: from Monte Carlo to agent-based modeling. We find weaknesses before launch." button="Get in touch" link="/quote/" >}}
---
## veTokenomics: The Economics of Vote Escrow in DeFi
- URL: https://giantslabs.pro/models/ve-tokenomics/
- Section: models
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Deep dive into the ve-model — voting power decay formula, gauge voting, bribe economics. Comparison of Curve, Pendle, Velodrome and ve(3,3).
veTokenomics is an economic model where tokens are locked for extended periods in exchange for voting power, a share of protocol revenue, and control over emission distribution. First implemented by Curve Finance in 2020, the model has become the standard for DeFi protocols that generate fee revenue.
## Why the ve-Model Exists
Standard governance tokens suffer from three problems:
1. **Short-term incentives.** A holder can vote for a self-serving proposal and immediately sell, bearing no consequences
2. **Voter apathy.** With typical turnout of 3–5%, a small group makes all the decisions
3. **Vote markets.** Flash loan attacks and vote rental markets allow buying influence without long-term commitment
{{< callout title="The problem ve solves" >}}
The ve-model ties influence to **commitment**: to gain maximum voting power, you must lock tokens for years. This filters out speculators and aligns the decision-making horizon between the protocol and its governors.
{{< /callout >}}
The ve-model addresses these problems through a **commitment device**: voting power is proportional to lock duration, not just token quantity.
## Vote Escrow Mechanics
### Lock Formula
When locking tokens, a user receives ve-tokens. The amount depends on both the quantity locked and the lock duration:
{{< formula math="veToken = Token × (t_lock / t_max)" >}}
- veToken — voting token balance
- Token — locked tokens
- t_lock — chosen lock duration
- t_max — maximum lock duration (e.g., 4 years)
{{< /formula >}}
Example for Curve with t_max = 4 years:
| Lock duration | 1,000 CRV → veCRV |
|---|---|
| 4 years | 1,000 veCRV (100%) |
| 2 years | 500 veCRV (50%) |
| 1 year | 250 veCRV (25%) |
| 6 months | 125 veCRV (12.5%) |
### Voting Power Decay
A key feature of the ve-model is **linear decay**. Voting power doesn't remain constant — it decreases over time to zero at the moment of unlock:
{{< formula math="veToken(t) = Token × (t_remaining / t_max)" >}}
- veToken(t) — voting power at time t
- t_remaining — time remaining until unlock
- Voting power decreases every week (in Curve — every Thursday, epoch boundary)
{{< /formula >}}
Example: a user locks 1,000 CRV for 4 years.
| Point in time | t_remaining | veToken |
|---|---|---|
| Lock day | 4 years | 1,000 |
| After 1 year | 3 years | 750 |
| After 2 years | 2 years | 500 |
| After 3 years | 1 year | 250 |
| Unlock | 0 | 0 |
Decay creates an economic incentive to **relock**: to maintain voting power and revenue share, the holder must extend the lock duration.
## Three Pillars of ve-Economics
The ve-model unites three mechanisms into a single economic structure:
### 1. Lock — Supply Reduction
Locking tokens for extended periods removes them from circulation. When a high percentage of tokens are locked (>50%), the effect on supply is significant.
{{< formula math="Circulating = Total_supply − Locked_ve − Locked_stake" >}}
- Circulating_supply — tokens available for trading
- With 60% locked in ve, only 40% of supply creates sell pressure
{{< /formula >}}
Curve: as of late 2025, roughly 50% of all CRV is locked in veCRV. The average lock duration exceeds 3.5 years — though this figure is skewed upward by liquid lockers (Convex, Stake DAO) that automatically lock for the maximum 4 years. This radically reduces sell pressure.
### 2. Vote — Emission Control
In the classic ve-model, holders vote on how emissions are distributed across pools (gauge voting). This is not abstract "governance participation" — it's control over money flows.
Gauge voting mechanics:
1. The protocol emits a fixed number of tokens per epoch (week)
2. ve-token holders allocate votes across pools (gauges)
3. Pools receive emissions proportional to votes received
4. Emissions attract liquidity providers → pool TVL grows
{{< formula math="Emission_pool = Emission_epoch × (Votes_pool / Votes_total)" >}}
- Emission_pool — rewards for a specific pool per epoch
- Votes_pool — ve-tokens directed at this pool
- Votes_total — total ve-tokens that voted
{{< /formula >}}
### 3. Earn — Fee Distribution
ve-token holders receive a share of protocol fees. This creates real yield, not inflationary rewards:
{{< formula math="Revenue_ve = Fees × Share_ve × (veToken_i / veToken_total)" >}}
- Revenue_ve — income for a specific holder
- Share_ve — percentage of fees directed to ve-holders (in Curve — 50%)
- veToken_i — a specific holder's ve-tokens
- veToken_total — total ve-tokens outstanding
{{< /formula >}}
The combination of all three pillars creates a **flywheel**: locking reduces supply → price increases → stronger incentive to lock → more tokens locked. For more on how ve connects to demand, see [5 Demand Models]({{< relref "models/demand-models" >}}).
{{< callout title="The flywheel works both ways" type="warning" >}}
If protocol revenue falls, locking incentives weaken → holders don't relock → supply increases → price pressure → even weaker incentives. The ve-model amplifies the trend in both directions.
{{< /callout >}}
## Bribe Economics: Why Protocols Pay for Votes
Gauge voting creates a unique market: protocols compete to direct emissions toward their pools, because emissions attract liquidity, and liquidity attracts users.
### The Bribe Rationality Formula
It's rational for a protocol to "bribe" ve-token holders if the bribe cost is less than the value of the attracted emissions:
{{< formula math="Bribe_rational: Bribe < Emission_attracted × Token_price" >}}
- Bribe — amount paid to ve-holders for votes
- Emission_attracted — additional emissions directed to the desired pool
- Token_price — market price of the emitted token
{{< /formula >}}
Example calculation:
- Protocol X pays $100,000 in bribes per epoch
- Attracts 500,000 CRV in emissions to its pool
- CRV price is $0.50 → attracted emissions = $250,000
- Bribe ROI: ($250,000 − $100,000) / $100,000 = **150%**
As long as ROI is positive, a rational protocol continues bribing. This creates sustained demand for ve-tokens.
### The Bribe Marketplace
The bribe ecosystem includes:
| Participant | Role | Example |
|---|---|---|
| **Protocol** | Pays bribes for votes | Frax, Yearn, Convex |
| **ve-holder** | Receives bribes for votes | Individual veCRV holders |
| **Aggregator** | Pools ve-tokens, simplifies voting | Convex, Aura, Stake DAO |
| **Bribe platform** | Marketplace for placing bribes | Votium, HiddenHand |
{{< callout title="Market size" >}}
At peak (2022), $10–20M in bribes per round flowed through Votium and HiddenHand, with Votium's April 2022 round reaching $21M. As of early 2026, the bribe market has matured: protocols optimize spend, and aggregators control a significant share of ve-tokens.
{{< /callout >}}
## Meta-Governance: Convex and Governing the Governors
Convex Finance exposed a fundamental property of the ve-model: voting power can be **aggregated and repackaged**.
### How Convex Works
1. Users deposit CRV into Convex and receive cvxCRV
2. Convex locks received CRV as veCRV for the maximum duration
3. CVX holders (Convex's governance token) vote on how Convex directs its votes
4. Result: 1 CVX controls the votes of many veCRV
{{< formula math="Leverage_CVX = veCRV_convex / Supply_CVX" >}}
- Leverage shows how many veCRV one CVX controls
- Example: if Convex holds 250M veCRV with ~100M CVX in circulation → leverage ≈ 2.5x (actual numbers fluctuate with veCRV decay and new deposits)
{{< /formula >}}
### Economic Consequences
Meta-governance creates a **three-tier structure**:
| Level | Token | Controls |
|---|---|---|
| 1. Base | CRV | Liquidity in Curve pools |
| 2. Governance | veCRV | CRV emission distribution |
| 3. Meta-governance | CVX | Direction of veCRV votes |
It's cheaper for a protocol to bribe CVX holders (meta-governance) than to directly bribe veCRV holders, due to the leverage effect.
Similar aggregators:
- **Aura Finance** — for veBAL (Balancer)
- **Stake DAO** — multi-protocol aggregator
## Evolution: ve(3,3) and the Solidly Model
Andre Cronje (Yearn creator) proposed ve(3,3) — a hybrid of the ve-model with (3,3) mechanics from OlympusDAO. The key difference: **100% of fees** go to ve-token holders who voted for specific pools.
### Differences from Classic ve
| Parameter | Classic ve (Curve) | ve(3,3) (Velodrome) |
|---|---|---|
| Fees | Distributed equally to all ve-holders | Only to those who voted for the pool |
| Emissions | Separate from fees | Also directed by voting |
| Decay | Yes | Yes |
| Anti-dilution | No | Rebase proportional to emissions |
| Incentive to vote | Emission control | Control + direct revenue |
Anti-dilution rebase in ve(3,3): if the protocol emits new tokens, ve-holders receive additional ve-tokens to compensate for dilution. Implementations vary:
- **Velodrome/Solidly (original):** `Rebase = Emission_week × (veSupply / Total_supply)²` — quadratic: the higher the locked share, the larger the rebase. At 50% locked, rebase = 25% of emissions; at 80% locked, rebase = 64%
- **Aerodrome:** `Rebase = Emission_week × (1 − veSupply / Total_supply)` — inverse: rebase is larger when fewer tokens are locked, incentivizing locking at low participation rates
{{< formula math="Rebase = Emission_epoch × (veSupply / Total_supply)²" >}}
- Rebase — total ve-tokens distributed to all ve-holders per epoch (computed)
- veSupply — total locked ve-tokens
- Total_supply — total token supply
- Individual share: proportional to veToken_i / veSupply
- Quadratic dependence means rebase grows faster than lock rate
{{< /formula >}}
## Implementation Comparison
| Protocol | Token | Max lock | Fees to ve | Gauge voting | Meta-governance | Anti-dilution |
|---|---|---|---|---|---|---|
| **Curve** | veCRV | 4 years | 50% from all pools | Yes | Convex (CVX) | No |
| **Balancer** | veBAL (legacy) | 1 year | 75% of protocol fees (until 2026) | Yes | Aura (AURA) | No |
| **Velodrome** | veVELO | 4 years | 100% from voted pools | Yes | No | Yes (rebase) |
| **Aerodrome** | veAERO | 4 years | 100% from voted pools | Yes | No | Yes (rebase) |
| **Pendle** | vePENDLE (legacy) | 2 years | 80% (until Jan 2026) | Yes (by pool) | No | No |
| **Thena** | veTHE | 2 years | 90% fees + 100% incentives from voted pools | Yes | No | Yes |
{{< callout title="2024–2026 trend" >}}
New protocols increasingly choose the ve(3,3) model (Velodrome / Aerodrome) over classic ve (Curve), because it creates a more direct link between voting and revenue. The Velodrome model has become the standard for DEXs on L2 networks.
{{< /callout >}}
{{< callout type="warning" title="Deprecated implementations" >}}
Not all implementations in the table are current. **Balancer** suffered a $110M+ exploit in November 2025; in March 2026 Balancer Labs shut down and veBAL was declared dead, with 100% of remaining fees redirected to the DAO treasury. **Pendle** replaced vePENDLE with sPENDLE (a liquid staking model without multi-year locks) in January 2026. **Velodrome and Aerodrome** announced a merger into a single DEX (Aero) in Q2 2026. These transitions confirm the trend: classic ve with rigid locks is giving way to more flexible designs.
{{< /callout >}}
## When to Use the ve-Model
The ve-model is not a universal tool. It requires specific conditions to function.
{{< checklist title="ve-readiness checklist" type="check" >}}
Stable revenue — protocol generates fee income (>$1M/year)
Multiple directions — there are pools or products to vote on
Liquid token — the token already trades with sufficient liquidity
Critical mass — more than 1,000 unique holders
Team readiness — resources for complex implementation (contracts + frontend + integrations)
Low network fees — protocol on L2 or alternative L1
{{< /checklist >}}
### When ve Does NOT Fit
- **Early stage** — no revenue to distribute, gauge voting is meaningless
- **Single product** — no multiple pools to vote on, no competition for emissions
- **High network fees** — on Ethereum L1, small holders can't participate due to gas costs
- **Speculative token** — without real revenue, the ve-model becomes a pyramid: the only lock incentive is hope for price appreciation
## Risks and Limitations
### Governance Capture
Aggregators (Convex, Aura) can concentrate >50% of voting power, gaining de facto control over the protocol. Convex controls a significant share of veCRV, making CVX effectively Curve's governance token.
### Position Illiquidity
Locked tokens cannot be sold before expiry. If the token price drops, the ve-holder suffers losses with no exit. "Wrapper" solutions have appeared (cvxCRV, sdCRV), but they trade at a discount.
### Bribe Concentration
Large protocols with big bribe budgets can capture the bulk of emissions, leaving smaller pools without rewards. This can lead to an oligopoly in liquidity management.
### Inflationary Spiral
If bribe costs begin to exceed the value of attracted emissions (ROI < 0), protocols stop bribing. Without bribes, demand for ve-tokens falls → unlocks → supply increases → price drops. For more on inflationary risks, see the article on [staking]({{< relref "models/staking" >}}).
## Design Parameters
If you've decided to use the ve-model, here are the key parameters:
| Parameter | Range | Recommendation |
|---|---|---|
| Maximum lock | 1–4 years | 2 years for new protocols, 4 for mature ones |
| Fee share to ve | 50–100% | 100% for ve(3,3); 50–75% for classic |
| Epoch frequency | 1–4 weeks | 1 week (standard) |
| Anti-dilution | Yes / No | Yes, if inflation > 10% annually |
| Minimum lock | 1 week–3 months | 1 week (lowers entry barrier) |
| LP boost | 1x–2.5x | 2.5x (Curve standard) |
## Key Takeaways
The ve-model solves the incentive alignment problem between a protocol and its token holders through a commitment device. Three pillars — lock, vote, earn — create a flywheel that works when the protocol has stable revenue.
The evolution from Curve (classic ve) to Velodrome (ve(3,3)) shows the direction: direct link between voting and revenue, anti-dilution, deployment on L2 for accessibility.
The key design question: **does the protocol generate enough revenue** for the ve-model to create real incentives, rather than merely redistributing inflation? If the answer is "no" — the model is premature, and simpler [demand models]({{< relref "models/demand-models" >}}) are a better starting point.
{{< cta title="Need a ve-model for your protocol?" text="We've designed ve-tokenomics for DeFi protocols across lending, DEXs, and yield platforms. We calculate optimal lock parameters and stress-test sustainability." button="Get in touch" link="/quote/" >}}
---
# Section: Knowledge
## Section landing: Knowledge
- URL: https://giantslabs.pro/knowledge/
- Kind: section landing
- Section: knowledge
- Description: Practical guides, analytics frameworks, and decision tools for tokenomics practitioners.
---
## Agricultural Tokenization: What Actually Works
- URL: https://giantslabs.pro/knowledge/agricultural-tokenization/
- Section: knowledge
- Date: 2026-07-03
- Last modified: 2026-07-03
- Description: Agricultural tokenization in practice: grain-backed tokens, on-chain receivables, traceability—numbers, dates, and a due-diligence checklist.
In mid-2025, the largest real-world-asset issuance recorded on a public blockchain to that date—by Ripple's own account—was not a tokenized Treasury fund and not a Manhattan tower. It was Brazilian farm debt: R$700 million (about $130 million) of agribusiness receivables placed on the XRP Ledger by the securitizer VERT.
Search for "agricultural tokenization," though, and you will mostly find something else: cocoa farms on the blockchain, farmers selling directly to European chocolate makers, token holders earning 10–30% from the harvest. Almost none of it has closed a verified deal. Agriculture is simultaneously one of the few RWA verticals with production-scale, independently verifiable deployments—and one of the most polluted by press-release vaporware.
This article separates the two, using Brazil—the world's most developed agricultural tokenization market—as the test bench. We work with this market directly in our consulting practice, so every number below carries a date and a source type. The pattern is blunt, and it holds well beyond Brazil.
## Three different things called "agricultural tokenization"
{{< callout title="The frame" type="info" >}}
When a project says it "tokenizes agriculture," it is doing one of three things: recording **provenance** (traceability, no financial instrument), issuing **commodity-backed tokens** (a claim on physical grain in a warehouse), or **mirroring a securitization** (a regulated debt instrument whose lifecycle is recorded on-chain). They answer to different regulators and have very different track records. Most disappointment in this market comes from reading one category's press release while assuming another category's mechanics.
{{< /callout >}}
| Layer | What moves on-chain | Financial function | Verified at scale? |
|---|---|---|---|
| Traceability | GPS, harvest and processing records, QR verification | None—provenance and compliance (e.g., EUDR) | Yes, but it is not tokenization |
| Commodity-backed tokens | A claim on delivered physical grain, 1 token = 1 tonne | Collateral, payments, barter | Yes—modestly (~$70M in transactions) |
| On-chain securitization | A regulated receivables certificate, mirrored on a ledger | Institutional credit distribution | Yes—largest verified volumes (R$1.1B+ in two deals) |
{{< schema "comparison/agri-tokenization-spectrum" >}}
## Why grain tokenizes and farmland doesn't (yet)
A thesis we have used since 2023: **assets tokenize in the order they were digitized**. If an asset already lives in a digital environment—an electronic registry, an exchange feed, a custody system—tokenization is one step. If it doesn't, tokenization first requires digitizing the underlying rights, which is a state-infrastructure project, not a startup feature.
This is why real estate, the vertical everyone bet on in 2021, barely registers in on-chain RWA statistics: ownership of land and buildings sits in state registries that issue no machine-readable titles, so platforms can tokenize rental income at best, not the property right itself. (Our [ownership model]({{< relref "models/ownership-model" >}}) article covers the NAV mechanics of tokens that do hold assets.)
Agriculture, of all things, sits at the opposite end. In Brazil, farm finance went digital years before anyone said "RWA":
- **Grain is standardized and priced by liquid markets.** Soybean, corn, and wheat have exchange quotes (CEPEA/B3, CME) that work as ready-made price oracles.
- **The paper is already electronic.** The CPR—a farmer's registered promise of future delivery, created by law in 1994—has required electronic registration since 2020. Warehouse receipts and receivables certificates followed the same path.
- **Off-chain verification exists as an industry.** Certified warehouses, collateral managers, and crop insurers predate the blockchain conversation by decades.
Where those conditions fail, tokenization fails with them. Specialty crops illustrate the boundary: in our own RWA work we have seen a project tokenizing olive harvests struggle with exactly this—olive varieties and grades have no oracle coverage, and export terms (EXW, FOB, CIF) change the economics of every lot. Grain clears the digitization bar; most of what makes headlines does not.
## Verified case one: grain-backed tokens (Agrotoken)
The Argentine-Brazilian platform Agrotoken—rebranded under the Justoken umbrella in 2024—issues tokens where **one token equals one tonne** of physical grain: SOYA for soybeans, CORA for corn, WHEA for wheat. Three design choices matter:
1. **Minting is triggered by delivery, not by promise.** Tokens are created when grain has been sold and delivered to an accredited elevator, verified through a Proof of Grain Reserve process—not against a forecast harvest. In Brazil the legal basis is the CPR title.
2. **The token has four sinks.** Collateral for bank credit, payment at accredited merchants (a Visa-partnered card, launched in Brazil in January 2023, spends grain balances at ordinary terminals), barter for inputs, and exchange trading. This is a textbook application of the [payment model]({{< relref "models/payment-model" >}})—with the unusual property that the "currency" is deflationary by harvest cycle.
3. **Detokenization on physical settlement.** When grain is delivered to the final buyer, tokens burn—supply tracks the physical reserve.
The verified numbers, as of April 2024: roughly **230,000 tonnes tokenized, about $70 million in transactions, more than 1,000 farmers**—figures reported by the Center for a Digital Future and repeated by the CEO on the record. Argentina's Santander issued the first bank loan against tokenized grain collateral back in March 2022. Two caveats keep the enthusiasm honest: the headline figures aggregate Argentina and Brazil (Brazil's own tokenized volume was closer to 38,000 tonnes—embryonic), and the company's stated goal of one million tonnes by 2023 was missed by a wide margin: even by April 2024, cumulative volume stood at less than a quarter of the target.
## Verified case two: on-chain securitization (VERT)
The largest verified money in agricultural tokenization sits in a less glamorous place: **receivables securitization with an on-chain mirror**.
VERT is a licensed Brazilian securitizer—373 deals and roughly R$95 billion structured by mid-2025—that took its standard product, the CRA (an agribusiness receivables certificate), and recorded issuance and lifecycle events on public ledgers:
- **R$700 million (~$130 million) on the XRP Ledger, reported in July 2025**—the deal Ripple called the largest RWA issuance recorded on a blockchain at the time.
- **R$400 million (~$75 million) with the agro-industrial group UISA on the XDC Network, November 2025**—four series with maturities up to six years, collateralized by the group's receivables.
The design point practitioners should internalize comes from VERT's own digital-assets team: **"the token is not the asset."** The CRA continues to exist in Brazil's regulated financial infrastructure; the ledger adds transparency and traceability for investors—it does not replace the securitization stack. If that distinction feels familiar, it is the same one that separates a tokenized share from an SPV tracker in our [tokenized equity field guide]({{< relref "knowledge/tokenized-equity-instruments" >}}): what you hold legally matters more than what you see on-chain.
The scale of the category is easy to misread from headlines, so anchor on registry data. Brazil's total tokenized-asset issuance reached about **R$6.2 billion** cumulatively, and virtually all of it sits with the top five platforms. VERT alone accounts for roughly 60% of all tokenized-asset volume in Brazil—about R$3.7 billion cumulative. At the retail end, the tokenizer Liqi—which holds its own CVM securitizer license—distributes tokenized rural credit notes (CCBs) with tickets from **R$25**. And against the underlying market, all of this is a rounding error: tokenized CPRs stood at about **R$411 million in January 2026, less than 0.1% of the R$560 billion CPR stock**. Whatever this market becomes, it is early.
## The marketing zone: cocoa
Now for what dominates the search results. Cocoa prices went vertical in 2024 (a record near $12,900 per tonne in December, up 177% in a year), and a wave of "cocoa on the blockchain" announcements followed. Brazil, the world's sixth-largest producer, became the favorite backdrop. By mid-2026, with prices back near $4,000, here is what those projects look like under audit:
- **Dimitra / Connected Cacao + MANTRA**—the flagship "invest in cocoa farmers" story, announced May 2025. It is a pilot covering **25 of 374 farmers** in one growing region, not launched in production as of June 2026. The advertised 10–30% annual returns are, in the CEO's own words, projections from preliminary modeling. The L1 token meant to carry the investment product, OM, flash-crashed roughly 90% in April 2025, erasing over $5 billion in market capitalization.
- **Bioca**—a working traceability platform for organic cocoa, coffee, honey, and turmeric. QR-code provenance for the end consumer. No token, no investment product, no tokenized volumes.
- **IG Sul da Bahia / Bleu**—Brazil's first blockchain cocoa traceability system, live since 2021, covering a region with ~3,500 producers. Again: provenance verification, not tokenization.
The narrative all three feed—the farmer selling directly to a US or EU buyer through a token, bypassing traders—**has not produced one verified export deal in Brazil** as of June 2026. Meanwhile the actual cocoa trade runs through Cargill, Barry Callebaut, and Olam, who operate their own corporate traceability programs and show no sign of being disintermediated.
{{< callout title="How to read agro-token news" type="warning" >}}
Most "tokenized agriculture" coverage is one press release reprinted across crypto aggregators. Before treating an announcement as a case study, look for three things: a named counterparty on the other side of a deal, a dated volume figure a third party can check, and a working redemption path from token back to asset or cash. Every verified project in this article passes that test; none of the cocoa projects do.
{{< /callout >}}
## The scoreboard
| Project | What the token holds | Verified scale | Stage (June 2026) |
|---|---|---|---|
| Agrotoken / Justoken | Delivered physical grain via CPR, 1 token = 1 tonne | ~230k t, ~$70M transactions, 1,000+ farmers (Apr 2024, AR+BR) | Production, modest volumes |
| VERT (CRA on XRPL / XDC) | Regulated receivables certificate, mirrored on-chain | R$700M + R$400M issuances (2025) | Production, institutional |
| Liqi / Nagro | Tokenized rural credit note (CCB), retail distribution | >R$200M tokenized overall, tickets from R$25 | Production, retail scale |
| Dimitra / MANTRA (cocoa) | Future crop share (planned) | None—pilot, 25 of 374 farmers | Pilot / announcement |
| Bioca, IG Sul da Bahia (cocoa) | Nothing—no token | n/a | Traceability only |
## Why the pattern is not an accident
The line between the verified and marketing columns is not technological sophistication. All these projects use comparable ledgers. The line is **whether the project plugs into the existing financing stack or promises to replace it**.
What works is tokenization as a **financing and collateral layer**: grain that is already in a certified warehouse, receivables that are already a regulated security. The hard problems—verifying the physical asset, enforcing the claim, pricing the credit risk—are solved by the pre-existing infrastructure, and the token adds distribution, transparency, or settlement speed.
What stays in the pilot column is tokenization as **disintermediation**: replacing traders, exporters, and banks with a token. That version has to rebuild verification and price discovery from scratch—usually with a whitepaper where the collateral manager should be.
Regulation reinforces the same split. Brazilian authorities treat tokens on agricultural assets and receivables as securities, so the verified deals run through the standard public-offering framework (VERT's issuances) or the crowdfunding regime with its deliberately constrained secondary market. Investors get no deposit-insurance coverage, and exit liquidity is thin—which is precisely why the credit quality of the underlying matters more than the token wrapper. The 2024 default of AgroGalaxy—a retailer whose debt included some R$830 million in CRAs, and which happened to be Agrotoken's first Brazilian partner—made that lesson expensive and public.
## A due-diligence checklist
Before taking any "agricultural tokenization" project at face value, run six questions. They map to the checklist in [when you don't need a token]({{< relref "knowledge/when-token-not-needed" >}}), specialized for farm assets:
{{< checklist title="Six questions for any agro-token pitch" type="check" >}}
Is there a token at all? QR-code traceability is valuable—and is not a financial product. If the deck shows provenance screenshots next to yield promises, the yield has no instrument behind it.
What exactly does the token hold? A warehouse title, a receivable, and a share of a future harvest are three different risk profiles—delivered grain cannot fail to grow, a receivable can default, a future crop can do both.
Are the volumes verified? Look for dated figures with named counterparties from a source other than the project itself. One press release reprinted twenty times is one data point.
Who holds the physical collateral? A named custodian, warehouse operator, or collateral manager with an audit trail—or nothing but "blockchain-verified."
What happens on default? No deposit insurance covers these tokens, and secondary markets are thin. The enforcement path—who seizes what, under which law—is the actual product.
Where does the yield number come from? Executed, repaid deals—or "projections based on preliminary modeling." Both phrases have appeared in this market; only one of them is a track record.
{{< /checklist >}}
{{< cta title="Designing tokenomics for a real-world asset?" text="We have modeled RWA and commodity-token economics across 40+ engagements—including agricultural collateral, receivables structures, and the failure modes in between. We can tell you what survives contact with a regulator and a default cycle." button="Get in touch" link="/quote/" >}}
## The takeaway
Agricultural tokenization is real, and it is boring in exactly the way good financial infrastructure is boring: grain titles used as collateral, receivables certificates with an on-chain audit trail, retail access to instruments that used to trade in institutional blocks. The documented numbers—$70 million in grain-token transactions, over a billion reais of on-chain securitizations, sub-0.1% penetration of the underlying market—describe an early, growing, unevenly honest market.
The rule of thumb from this survey: **the closer a project sits to existing titles, warehouses, and securitization law, the more likely its numbers are real; the closer it sits to "bypassing the middlemen," the more likely you are reading a press release.** In the next article we go one layer down: how the underlying farm-finance stack—CPR, warehouse receipts, receivables certificates—actually works, because that stack is what every serious agro-token inherits.
---
## AI Agent Tokenomics: From Memecoins to Revenue Share
- URL: https://giantslabs.pro/knowledge/ai-agents-tokenomics/
- Section: knowledge
- Date: 2026-04-19
- Last modified: 2026-04-19
- Description: Why most AI agent tokens behave like memecoins, the four mechanics that turn them into real assets, and why none of it works without decentralized compute.
In late 2024 and early 2025, the market cap of the "AI Agents" category went from zero to $15–20 billion. Virtuals (an agent launchpad on Base), ElizaOS / ai16z (an open-source framework), and dozens of clones all positioned themselves as "autonomous agents with their own economy." Then came a 70–85% drawdown. By April 2026, the category cap on CoinGecko had stabilized around $2.6 billion. Paradoxically, this confirms the diagnosis: most of these tokens function like memecoins. Price moves on narrative, not cash flow. The "agent" itself often turns out to be a thin wrapper around a centralized model API, posting tweets.
The question is not whether the trend is alive — it is, just quieter. The question is what kind of tokenomics turns an AI agent from a speculative asset into a working economic system, and why none of it works without a separate layer of decentralized compute infrastructure.
## What is a web3 agent
The difference from a regular AI app comes down to two properties ([cyber•Fund, "web3 agents: the new meta"](https://cyber.fund/content/web3-agents)):
- **Autonomy.** The agent operates in a decentralized computing environment — not on one provider's servers, but across a network where no single party can shut it down or change its logic.
- **Economy.** Participating in the agent's economy is programmable and transparent: tokens, smart contracts, open distribution rules.
Without the first property, it's just a bot on someone's servers with a token slapped on top. Without the second, it's a regular AI app with regular monetization. A real web3 agent requires both at once — and that intersection is exactly where most projects today break down.
## Why agent tokens behave like memecoins today
Three structural problems with current implementations:
### 1. The token isn't tied to the agent's utility
In most projects, the token is a speculative asset disconnected from what the agent actually does. The agent generates content, trades, talks to users — and the token holder gets nothing from any of that except hope of price appreciation. No cash flow → no valuation anchor → price moves on tweets and hype.
### 2. The agent runs on centralized infrastructure
A "decentralized agent" that calls OpenAI, Anthropic, or Google APIs is a fiction. The provider can change the model, raise prices, introduce new usage rules. There haven't been mass-blocking incidents of crypto agents in public yet, but the risk is structural: all the "autonomy" rests on one vendor's policy. That isn't decentralization. It's just moving the dependency from one point (the project's server) to another (the model provider's server).
### 3. There's no trustless link between the token and the agent's behavior
Even if a project promises "the agent will share profits with holders," nothing enforces this at the code level. The team can change the rules, redirect revenue, or shut the project down. For the holder, the token is a promise, not a contract.
The result: an AI agent token differs from a memecoin only in narrative, not in economics.
## Design space: three axes of decisions
Every AI agent project picks a position on three axes. The choices determine whether the token works as an asset or a lottery ticket.
### Axis 1: Entertainment ↔ Utility
- **Entertainment agents** — role-play characters, social-media content bots, AI companions. Value lies in audience engagement.
- **Utility agents** — knowledge work automation: market analysis, ops automation, trading strategies, customer support. Value lies in time and money saved by end users.
For entertainment agents, the tokenomics often legitimately reduces to a memecoin: token demand = attention demand. For utility agents, you can build economics on real cash flow.
### Axis 2: Speed ↔ Depth
- **Fast launch** — off-the-shelf model (GPT-5, Claude Opus 4.x, Gemini 3), centralized infrastructure, token as a marketing tool.
- **Deep build** — decentralized inference network, community governance, custom decision-making logic baked into the agent.
Fast launches generate narrative and pull liquidity in weeks. Deep builds take years and rare expertise — but they're the only ones that build a real technological moat.
### Axis 3: Speculation ↔ Real value
- **Memecoin tokenomics** — value rests on expectations, no income stream to holders.
- **Cash-flow tokenomics** — the token captures a share of the income the agent earns from real services.
The first is easier to launch and grows fast in a bull market. The second survives across cycles — but requires the agent to actually earn.
## Four mechanics that turn a token into an asset
Four approaches that change the nature of an AI agent token from speculative to utility-bearing.
### 1. Revenue share with holders
The agent earns from services (content, analytics, trading, support). Part of the revenue flows to token holders through a smart contract — automatically, without the team's discretion.
The key condition: revenue must be real and verifiable on-chain. If "revenue" is a treasury buffer the team distributes at will, that's not revenue share — it's a marketing trick.
{{< formula math="APR_% = Revenue_agent × Share_% / Supply_circulating / Price_token × (365 / Period_days)" >}}
- Revenue_agent — agent revenue over the period, USD (on-chain verifiable)
- Share_% — share of revenue routed to holders, % (0 ≤ Share_% ≤ 100; e.g., 30)
- Supply_circulating — tokens in circulation at calculation time (> 0; pre-TGE the formula doesn't apply)
- Price_token — market token price, USD
- Period_days — reporting period length, days (e.g., 30 for monthly revenue)
- APR_% — annual holder yield, % (computed)
{{< /formula >}}
Worked example: an agent earns $1,000,000 per quarter, shares 30% of revenue with holders, has 10,000,000 tokens in circulation at $2 each.
APR_% = 1,000,000 × 30 / 10,000,000 / 2 × (365 / 90) ≈ **6.1% per year**.
### 2. Utility access through the token
Holders get capabilities others don't: faster response, queue priority, advanced features, governance over agent behavior.
This works only if the capabilities themselves are actually wanted. "Exclusive access to a chatbot" interests no one. "Priority execution of an agent's trading signals" matters — if the signals genuinely make money.
### 3. Joint ownership through a smart contract
The agent is not the project's product but a shared asset of token holders. The agent's code, model weights, and infrastructure are governed by smart contract rather than by the team. Upgrades go through voting.
This removes the "team will change the rules" risk. But it introduces a new one — slow decisions in a fast-moving environment, and endless arguments about direction.
### 4. Mechanism design for autonomous transactions
Agents start transacting with each other — one agent pays another for a service (data analysis, content generation, trade execution). The token becomes the unit of account in this inter-agent economy.
The infrastructure for this is already deployed. In April 2026, Coinbase and the Linux Foundation launched [x402 Foundation](https://news.bitcoin.com/linux-foundation-and-coinbase-launch-x402-foundation-for-ai-agents/) — an open standard for agent-to-agent payments built on the HTTP 402 status code. Partners include AWS, Visa, Microsoft, American Express, Ant International, Stripe, Mastercard, Google, Circle, Solana, and Polygon; over 100 million transactions have flowed through the protocol during the past year of Coinbase pilots. In parallel: Coinbase Agentic Wallets, World ID × x402 integration, agents on Base.
The bottleneck is not technology, it's demand. Real daily inter-agent payment volume through x402 is in the tens of thousands of dollars — negligible for global infrastructure. If economic activity catches up to the rails that are already laid, agent tokens turn into the unit of account for the AI economy rather than speculative chips.
## Why none of it works without an infrastructure layer
Each of the four mechanics above hits the same question: **where does the agent physically compute**? If it's on OpenAI's servers or AWS, all the "decentralization" reduces to a token sitting on top of someone else's infrastructure, and "autonomy" is an illusion.
This creates demand for a separate infrastructure layer: decentralized compute networks where model inference and training are distributed across independent participants. The landscape varies sharply in maturity:
- **Established networks with live mainnets and real revenue:** Bittensor (mainnet since 2021, ~128 subnets covering different ML tasks), Akash (mainnet since 2020, GPU marketplace), Render (rendering and inference), io.net (GPU DePIN).
- **Newer approaches:** Nosana, Aethir, Ritual, Prime Intellect, Gonka — different bets on inference, fine-tuning, and distributed training, mostly in early mainnet or testnet.
For illustration, here's how the tokenomics of one newer project — Gonka ([gonka.ai/tokenomics.pdf](https://gonka.ai/tokenomics.pdf)) — is designed. The project is early-stage, without a multi-year track record, but the mechanism design is instructive:
- **Bitcoin-style fixed emission.** 1 billion GNK supply, 80% to network participants, 20% to the team. 323,000 GNK minted per epoch with exponential decay (halving every ~4 years).
- **Transformer-based Proof-of-Work.** Instead of classic PoW (useless hashes) or PoS (capital-weighted voting), there's the "Sprint" mechanism: participants compete on tasks structurally similar to transformer inference. Voting weight is proportional to actual compute work performed.
- **Collateral-backed governance.** By default only 20% of voting weight earned through Proof-of-Compute is active. The remaining 80% unlocks only when the participant locks GNK as collateral. The point is to tie influence to economic accountability, not just to hardware.
- **EIP-1559-style dynamic pricing.** The price of inference for each model adjusts automatically: stable in the 40–60% utilization band, rises above, falls below. Maximum price step capped at 2% per block.
- **Open training fund.** 20% of inference revenue is routed to financing open-source LLM training, so the network keeps producing frontier models rather than only serving outside ones.
This isn't an endorsement of Gonka — it's an illustration of how complex tokenomics gets when it actually has to govern a decentralized compute network, not just draw a distribution chart for investors.
The implication for agents: **agent tokenomics inherits the constraints of the infrastructure layer**. If an agent runs on Bittensor, Akash, Render, or Gonka, then its inference cost, availability, and censorship resistance depend on that network's tokenomics. That's not a bug, it's a fundamental architecture: you can't build an autonomous agent without leaning on autonomous infrastructure.
## Checklist: when does an agent token make sense
Before launching an AI agent project with a token, answer five questions:
1. **Does the agent have cash flow?** If the agent doesn't earn real money (only attracts attention), the token will behave like a memecoin regardless of the mechanics layered on top.
2. **Can that cash flow be verified on-chain?** If revenue flows through a centralized project account, the holder is trusting the team's good faith, not the code.
3. **What infrastructure does the agent run on?** If on OpenAI or AWS, "autonomy" lasts only until the provider changes terms.
4. **Who owns the model weights and the behavior logic?** If the team — it's a project with a token. If the holders, through a smart contract — it's a web3 agent.
5. **Is the token needed for a utility function, or only for speculation?** If you can replace the token with a dollar subscription and the product still works, you probably don't need the token (see [When You Don't Need a Token]({{< relref "knowledge/when-token-not-needed" >}})).
A project that passes all five filters is rare in 2026. Most AI agent tokens are narrative wrapped around centralized infrastructure. But the projects that build answers to all five questions at once are the ones building toward the "post-labor economy" the entire trend claims to deliver.
## Takeaways
1. **Most AI agent tokens today behave like memecoins** — price moves on narrative, not cash flow.
2. **Four mechanics change the token's nature**: revenue share, utility access, joint ownership through smart contract, mechanism design for inter-agent transactions. Each requires real cash flow as a foundation.
3. **Without decentralized compute, these mechanics are fiction.** An "autonomous agent" on the OpenAI API is marketing, not architecture.
4. **Agent tokenomics inherits infrastructure-layer tokenomics.** The choice of compute network is part of the tokenomic design, not just a technical question.
5. **The filter is simple**: is there cash flow, is it verifiable on-chain, who owns the model, is the token needed for a utility function. Projects that pass create real assets. The rest are lottery tickets with good narrative.
---
## DCF for Token Valuation: Rates, Terminal Value, OpenAI Anchor
- URL: https://giantslabs.pro/knowledge/dcf-token-valuation/
- Section: knowledge
- Date: 2026-05-15
- Last modified: 2026-05-15
- Description: How to apply DCF to a token: choosing the discount rate (US treasuries, EUR/JPY anchors, crypto premium), terminal value as the main trap, sensitivity, and a Fair Value calculator.
On October 2, 2025, OpenAI closed a tender at a $500 billion valuation (and by November secondary-market trades were quoting up to $600B). With OpenAI's 2025 revenue around $20 billion, that implies a revenue multiple of roughly 25×—and the natural question becomes: what discount rate would make such a multiple consistent in a DCF model? For high-growth technology companies still bearing significant operating losses and 3–5 years from sustained profitability, the typical DCF rate in investment analysis lands in the 25–35% range. The crypto analog is direct: a tokenomics analyst staring at a Fair Value model is solving exactly the same problem—what counts as cash flow, where to source the rate, what horizon to project. DCF for token valuation runs on the same logic as DCF for tradfi companies—only the instruments, the assumptions, and the rates look a little different.
DCF (Discounted Cash Flow) is the strictest of the valuation methods. It does not answer "what is the token worth right now"; it answers "what should it be worth if the future behaves like our model." That distinction matters: markets can diverge from DCF for years, and not always because the market is wrong—sometimes the model ignores liquidity, regulatory premium, or expectation horizons. But without a DCF anchor, a conversation about a crypto asset's fundamentals rarely gets concrete.
This article is a practical walkthrough: how to compute DCF for a token, how to pick the rate, how to avoid the terminal-value trap, and when DCF is the wrong tool. Inside—an interactive calculator where you can dial the parameters and watch Fair Value respond.
## What DCF Is and Where It Lives Among Other Valuation Methods
DCF discounts future cash flows back to today through a discount rate. The logic is simple: a dollar today is worth more than a dollar a year from now because (a) today's dollar can be invested at the risk-free rate to earn yield, and (b) the future is uncertain—the further out, the more that uncertainty should reduce the present value.
{{< formula math="PV = Σ CFₜ / (1 + r)ᵗ" >}}
- PV—present value of the cash flow stream
- CFₜ—cash flow in period t
- r—discount rate (per period)
- t—period number
{{< /formula >}}
In classical DCF, the sum is extended by terminal value (TV)—the value of all cash flows beyond the explicit forecast horizon, collapsed into one number and also discounted. For crypto projects this component often makes up 40–80% of the valuation on typical parameters (n=5, r=20–30%), and that is exactly where the main trap lives—we'll return to it in the pitfalls section.
DCF is one of five valuation methods used in crypto investment analysis. Each is optimal for a different token class; mixing them without understanding boundaries is a beginner's mistake.
{{< callout type="info" title="Five valuation methods for a crypto project" >}}
**Uniswap equation (k = x·y).** Describes pricing inside an AMM pool, not asset valuation. Useful for liquidity and current price given reserves; not useful for fundamental token value.
**Fisher equation (M·V = P·Q).** Quantity theory of money: money mass times velocity equals price times transaction volume. Applied to payment tokens and slow-economy tokens—gives an estimate via transaction volume and velocity. See [token velocity]({{< relref "models/token-velocity" >}}) for the full treatment.
**DCF (discounted cash flow).** Applicable to tokens with visible cash flows: buybacks, dividends, service fees, fee-share. This article covers it.
**Multiples.** Comparison with peers via P/E, P/S, EV/EBITDA, FDV/Revenue. Fast, but requires a sample of comparable projects, and in crypto "comparables" are always slightly different.
**Liquidation value.** What remains if the project winds down: balance sheet, treasury, marketable assets. Useful for projects with large treasuries, not for pure protocols.
The methods complement each other—DCF gives a value under the assumption the project keeps working; multiples are the market sanity-check; liquidation value is the floor.
{{< /callout >}}
To see where DCF works and where it does not, a simple taxonomy by the nature of the cash flow helps.
| Token type | Visible CF | DCF applicable |
|---|---|---|
| Governance-only (voting without revenue) | no | no |
| Pure memecoin (narrative without operating model) | no | no |
| Utility (access, discounts, service fees) | indirect, via ARPU and churn | partial |
| Security (claim on revenue or profit) | direct | yes |
| Cash-flow token (buyback / dividend / fee-share) | direct and measurable | yes, best case |
DCF strictly applies only to the last two rows. So for governance-only tokens or pure memecoins the question "what's the DCF Fair Value?" doesn't make sense—the model doesn't fail because of a wrong rate, it fails because there's no object to model. The [demand-models article and Howey test discussion]({{< relref "models/demand-models" >}}) covers why forcing DCF on a CF-less token breaks down and what the alternatives are.
For the types where DCF works, the base logic is the same as for any tradfi asset: project the flow, pick the rate, discount, add TV. The crypto-specific tuning lives in the rate.
## Choosing the Discount Rate
The discount rate decomposes into two components: a risk-free rate (rf) and a risk premium. In crypto this decomposition is the main lever of model accuracy—getting either part wrong distorts the entire valuation.
{{< formula math="r = rᶠ + premium" >}}
- r—total discount rate
- rᶠ—risk-free rate
- premium—crypto risk premium (regulatory, smart contract, governance, liquidity)
{{< /formula >}}
The risk-free rate depends on the currency of the cash flow. For USD-denominated CF (which covers most crypto projects—fee revenue in stablecoins or ETH with USD equivalents), the anchor is the yield on US Treasuries. On May 8, 2026, US 10-year Treasury yield was 4.38%; by May 14 it sat at 4.45%. For a 5-year DCF horizon the right benchmark is the 5-year, which over the past months has been in roughly the 4.0–4.3% range.
For non-USD denominated flows the logic mirrors. EUR-denominated flows take German Bunds as the anchor; JPY flows take JGBs; emerging-market flows (e.g., RUB-denominated payment protocols) take local sovereign yields. As of May 2026, Russian 5-year OFZ yields sit near 14.7%, in line with the Central Bank's key rate of 14.50% (cut by 50 bp from 15% on April 24, 2026). Copying a DCF template across currencies without rebuilding the rf is one of the most common mistakes—see the warning below.
{{< callout type="warning" title="Never mix CF currency with rate currency" >}}
If CF is denominated in USD but the rate is taken from local sovereign yields (or vice versa), the model systematically biases the Fair Value. The fix: rebuild the risk-free anchor in the same currency as the cash flow before applying any crypto premium.
{{< /callout >}}
The crypto risk premium is where DCF in crypto deviates most from classical practice. It bundles four components:
- **Regulatory risk**—probability of regulatory action altering the project economics. Lower for projects under clear jurisdictions (US-registered RWA, MiCA-compliant tokens), higher for gray-zone projects.
- **Smart contract risk**—probability of a code bug that loses funds. Reduced by audits and accumulated incident-free runtime.
- **Governance risk**—probability of a parameter change that redistributes value away from holders.
- **Liquidity risk**—probability that the token can't be sold at fair price when needed.
In practice these aren't summed component-by-component; they're aggregated into one crypto premium that scales with project maturity. The numbers below reflect our consulting practice—they are working anchors for fast modeling, not an industry-canonical reference.
| Project stage | Crypto premium | Resulting r (USD CF) |
|---|---|---|
| Mature L1 / established cash-flow token (ETH, BTC) | 10–15% | 14–19% |
| Established cash-flow protocol (Hyperliquid post-AF launch) | 15–20% | 19–25% |
| Mid-cap utility / 2+ year operational track | 20–30% | 24–34% |
| Early-stage with MVP and first users | 30–50% | 34–55% |
| Pre-revenue / whitepaper only | 50%+ | DCF usually inapplicable |
For most token-valuation tasks at TGE or shortly after, projects land in rows 3–4. A sensible default for fast articles and quick estimates is r = 25%; that's the starting parameter in the calculator below.
Returning to OpenAI: a hypothetical DCF rate of 25–35% for the $500B valuation lands in the "early-stage with MVP and first users" bucket of our table. It tracks the underlying business—operating losses are still material, the path to sustainable profit needs capital and time, AI regulation is shifting. Translate to a crypto project of comparable maturity—a startup with product, revenue, and a 3–5 year path to break-even—and the same 25–35% feels right. Less than that understates the risk; more understates the project.
One practical note on cost of equity versus WACC. For DAOs and protocols, debt financing in the tradfi sense is rare, so WACC effectively reduces to cost of equity. If a project has structured debt (some RWA tokens and hybrid models do), WACC becomes relevant—but that's the exception, not the rule.
## DCF Token Valuation Calculator
The interactive calculator below takes five parameters: cash flow in year 1, forecast growth, discount rate, post-forecast (terminal) growth, and horizon. It returns Fair Value, the TV share in that Fair Value, and sensitivity by rate. The default case—a mid-tier protocol with a $5M/year buyback, 10% annual growth, r=25%, terminal growth 3%, horizon 5 years—gives a Fair Value of roughly $27M and a TV share of about 42%. Already at the defaults you can see that nearly half the valuation lives in the post-forecast period; that is exactly the trap we cover in the pitfalls section.
## DCF Token Valuation Calculator
Token Fair Value via DCF
Fair Value
— USD
TV (terminal value) share—
Discount-rate sensitivity
Rate r
Fair Value
Δ vs base
Year-by-year contribution to Fair Value
PVₜ (discounted CF year t)PV(TV)—discounted terminal value
Year-by-year breakdown
Year t
CFₜ (USD)
Discount factor
PVₜ (USD)
Σ PVₜ
—
TV (nominal)
—
PV(TV)—discounted
—
Three patterns jump out immediately:
- **TV share at the default—about 42%.** Not an anomaly: that's the norm for short horizons with positive g. Set n=1 and TV jumps to 82%—almost the entire valuation lives in the post-forecast period. The model's accuracy then rests on a single multiplier.
- **Rate sensitivity is dramatic.** Move r by ±5 percentage points and Fair Value swings by roughly ±20–30%. At defaults: r=20% gives $35.5M (+31.5%), r=30% gives $21.7M (−19.6%). Picking the wrong r is the single largest source of error.
- **Long horizons with high rates compress TV.** Set n=10 and r=50% and TV share drops to 3.6%. The opposite pole: valuation is now almost entirely in the explicit forecast, because TV is discounted by tens of times.
Same calculation in Python—for those who want to verify or embed in their own analytics. The logic is identical to the JS calculator; the result at default parameters matches to the dollar.
Python: NPV + Terminal Value computation
```python
def dcf(cf1, g_fcst, r, g_term, n):
if r <= g_term and g_term > 0:
raise ValueError("r must be strictly greater than g_terminal")
rows = []
sum_pv = 0
for t in range(1, n + 1):
cf_t = cf1 * (1 + g_fcst) ** (t - 1)
df_t = 1 / (1 + r) ** t if r != 0 else 1
pv_t = cf_t * df_t
sum_pv += pv_t
rows.append((t, cf_t, df_t, pv_t))
cf_n = cf1 * (1 + g_fcst) ** (n - 1)
if r > g_term:
tv_nominal = cf_n * (1 + g_term) / (r - g_term)
pv_tv = tv_nominal / (1 + r) ** n if r != 0 else tv_nominal
else:
tv_nominal = pv_tv = 0
fair_value = sum_pv + pv_tv
tv_share = pv_tv / fair_value * 100 if fair_value else 0
return {
"rows": rows,
"sum_pv": sum_pv,
"tv_nominal": tv_nominal,
"pv_tv": pv_tv,
"fair_value": fair_value,
"tv_share_pct": tv_share,
}
# Default case
result = dcf(cf1=5_000_000, g_fcst=0.10, r=0.25, g_term=0.03, n=5)
print(f"Fair Value: {result['fair_value']:,.0f} USD")
print(f"TV share: {result['tv_share_pct']:.2f}%")
# Fair Value: 26,972,928 USD
# TV share: 41.64%
```
## Pitfalls: TV Is the Trap
If there's exactly one place to make a mistake in a token DCF, it will be in terminal value. Not because the Gordon Growth Model is complex—it's a one-liner:
{{< formula math="TV = CFₙ · (1 + g) / (r − g)" >}}
- TV—terminal value (at the end of the last forecast year)
- CFₙ—cash flow in the last explicit forecast year
- g—terminal (perpetuity) growth rate
- r—discount rate
{{< /formula >}}
But that one line determines 40–80% of the entire valuation, and the parameter g is the least-grounded in the whole model. For CF in year 1 you can anchor to current buybacks or fee revenue. For r there's a stage-by-stage premium table. For g—no anchors; the typical move is to plug in "long-run global GDP growth" (2–3%) and forget about it. That substitution hides risk: at the article's default parameters moving g_terminal from 2% to 5% with r=25% multiplies TV by roughly 1.18× and shifts Fair Value by about 7%. Sounds modest, but on long tails of parameter distributions (if you allow g to drift toward 8–10%—AI-market-like growth) the same shift produces multipliers of 1.5–1.7×.
The sensitivity table in the calculator only varies r—separately try g_terminal. The effect is smaller per percentage point than from r, but it compounds through the Gordon formula and is almost always underestimated, because the parameter feels "technical." In reality it controls the tail of the distribution, and any error there flows through TV into Fair Value.
Beyond the TV trap there are five recurring mistakes. Less dramatic individually, but in combination they can shift the valuation by 1.5–2×.
- **Mismatched nominal/real CF and rate.** If CF is in nominal USD (with inflation baked in), the rate must be nominal too (Treasury yield already includes inflation expectations). If CF is real (no inflation), the rate must be real—typically approximated as rf minus expected inflation, currently ~2.4–2.5% for USD. The most common slip is real CF with a nominal rate; the model then systematically understates Fair Value by 10–15% from double-discounting inflation.
- **Emission ignored.** Protocol CF ≠ per-token CF. If the protocol earns $10M/year revenue but emits 5% new tokens annually, per-token cash flow degrades through dilution. The fix: either explicitly discount CF by (1 + emission rate), or model on a per-token basis. This intersects with the [unit economics treatment]({{< relref "knowledge/unit-economics" >}}), where DCF interacts with the demand model and supply schedule.
- **Double-counting buybacks.** If a buyback is already captured in CF (revenue deflated in holders' favor), it cannot also count as supply reduction in the fair-value-per-token formula. Double-shrinking the denominator inflates the valuation by tens of percentage points.
- **Hidden churn.** Models often assume the current user base will hold; over a 5-year horizon in crypto that rarely happens. If churn runs 20% annually, CF falls roughly 2.4–3× over five years (0.8⁴–0.8⁵) without any other factor. The fix: bake churn into g_forecast (slightly positive or slightly negative), don't leave it outside the model.
- **Forecast horizon over 10 years.** At that scale any crypto forecast is guesswork. A model requiring n=15 or n=20 usually signals an under-estimated rate, with the long horizon as compensation. The cleaner approach: raise r by 5–10 points and compress n to 3–7 years.
A rough rule of thumb: if TV share in Fair Value is above 70%, the valuation depends too heavily on one parameter (g). If it's below 20%, check whether you've buried all expected flows into the explicit forecast, leaving TV as a trivial addition (this happens with an inflated r or short lifecycle assumptions in g_forecast).
## Applying DCF in Crypto: Hyperliquid, Jupiter, Jito
Unlike tradfi, where the DCF object is a company with public reporting, in crypto the visible cash flows are usually protocol operations rather than total revenue. Three projects in 2025–2026 brought their cash flows to on-chain transparency—but with materially different value-accrual mechanics: Hyperliquid via the Assistance Fund (buy with effective burn), Jupiter via buyback with a three-year lock in the Litter Box multisig, Jito via DAO treasury accrual with discretionary buybacks under JIP-24. This is a rare case where DCF can be built from observed numbers, not team projections. The mechanics of buyback programs are unpacked separately in the [buyback engineering article]({{< relref "models/buyback-engineering" >}}), which shows how on-chain revenue transforms into the CF we discount.
{{< callout type="info" title="Not an investment recommendation" >}}
The numbers below are illustrative and simplified, meant to show DCF mechanics on familiar projects. A real valuation requires more careful work on growth assumptions, regulatory risks, liquidity, and horizon. The "computed Fair Value" column contains neither targets nor price predictions—it demonstrates the "take visible CF, discount it, look at the spread vs market" frame.
{{< /callout >}}
For each project we take the observed annual buyback as an approximation of CF year 1, applying a maturity-tiered discount rate and a growth scenario matching the protocol's phase. Important: real run-rates are materially higher—Hyperliquid AF spent roughly $644M on buybacks across 2025 (≈ 46% of all crypto buybacks that year); Jupiter spent around $70M over two years of its program before pausing in Q1 2026 to redirect funds to growth initiatives; Jito routes flows through different mechanisms now under JIP-24 consideration. The table below uses conservative "anchor" CFs (the lower bound of annual flow) to demonstrate the computation; the right column shows market cap (as of May 15, 2026) and the spread—the useful illustrative takeaway.
| Protocol | Anchor CF (year 1) | DCF parameters | Computed Fair Value | TV share | MCap (as of May 15, 2026) | Spread |
|---|---|---|---|---|---|---|
| Hyperliquid (AF → buy → burn) | ~$100M/yr | r=20%, g_fcst=10%, g_term=3%, n=5 | ~$709M | 50% | ~$11.5B | MCap ×16 |
| Jupiter (buyback → 3y lock, paused 2026) | ~$30M/yr | r=25%, g_fcst=15%, g_term=3%, n=5 | ~$183M | 44% | ~$0.7B | MCap ×4 |
| Jito (MEV-tips → DAO treasury) | ~$20M/yr | r=30%, g_fcst=10%, g_term=3%, n=5 | ~$87M | 35% | ~$0.27B | MCap ×3 |
What the table shows:
- **Anchor CFs are intentionally conservative.** For Hyperliquid, swap the $100M anchor for the real annual buyback ($500–700M) and Fair Value scales to $3.5–5B; the spread vs MCap collapses to 2–3×—a reasonable market premium for growth and regulatory positioning. The lesson: DCF without an honest CF turns into "an argument for why the market is wrong."
- **Different value-accrual mechanics = different CF-to-per-token-Fair-Value relationship.** Hyperliquid's bought HYPE effectively leaves circulation (the AF was voted to permanent burn in December 2025), so CF per token grows. Jupiter's bought JUP locks in Litter Box for three years—supply is temporarily fixed but not destroyed, giving a smaller per-token multiplier. Jito's treasury accrual doesn't guarantee buyback at all—the DAO may direct funds to validator incentives or grants instead. **Applying identical DCF form to all three biases the result**: Hyperliquid's burn effect should sit in g_forecast (rising per-token CF); Jupiter's effect is supply-neutral; Jito carries a discount for distribution uncertainty.
- **Higher rate → smaller TV share.** Jito at r=30% (early-stage, MEV-focused) gives a TV share of about 35%—the opposite pole. Almost all the value lives in the explicit forecast; errors in g_forecast or CF matter more than errors in g_terminal.
- **Comparison with the market is a separate task.** Computed Fair Value rarely matches current MCap—divergence is explained by market expectation horizons, liquidity, regulatory premium, and plain volatility. A useful technique: run DCF in several scenarios (bear/base/bull through different r and g_forecast) and overlay on current market to see which assumptions are needed to justify the current price.
DCF works for these three because visible CF exists. On the same horizon, applying DCF to a governance-only token without revenue or a pure memecoin doesn't make sense—back to the taxonomy at the start of the article. For a security-token valuation (where DCF is literally the asset-class method), see the [demand-models and Howey test]({{< relref "models/demand-models" >}}) discussion.
One practical note on DCF vs multiples. When a project has transparent CF and an operational track record (as the three above), DCF is stricter and more accurate—it leans on concrete numbers rather than "looks like X" assumptions. Multiples (FDV/Revenue, P/E analogs) are useful as a cross-check: if your DCF gives Fair Value $500M while peer multiples imply $200M, check whether your g_forecast or g_terminal is inflated. When CF is unstable or essentially absent, multiples are faster and often the only sensible option.
## When DCF Is the Wrong Tool
Sometimes the right answer to "value this token with DCF" is "let's not." That's not a weakness of the method; it's its honest boundary. The checklist below is a quick applicability test; if three or more points match, pick a different instrument or explicitly call out the model's limits with the stakeholder.
{{< checklist type="warning" title="When DCF valuation is unreliable" >}}
- Pre-revenue project. No visible CF—nothing to discount. Alternative: VC method (multiplier on target market size) or scenario analysis.
- Governance-only token. Voting without revenue generates no CF. Alternative: control-premium valuation or peer comparison.
- Pure memecoin. Value is driven by narrative and liquidity, not CF. DCF is fundamentally inapplicable.
- Hidden emissions dilute CF. If supply grows faster than CF, the per-token flow falls faster than the protocol CF baseline and can erode toward zero in real terms.
- Rate unrealistically low (r < rf for the CF currency). Means crypto risk is being ignored. DCF then overstates and loses meaning.
- Horizon over 10 years. Crypto CF predictability at that range is low; long n compensates for other model weaknesses.
- TV share in Fair Value above 80%. The valuation is almost entirely determined by one multiplier—g_terminal—the least-grounded parameter in the model.
{{< /checklist >}}
The alternative to DCF in those cases is usually a combination: Fisher equation for fast-velocity payment tokens, multiples on peers for early-stage projects, real-options method for protocols with significant optionality (expansion into new segments, governance-driven shares). None is stricter than DCF, but within their applicability each works better.
{{< cta title="Need a DCF-based valuation of your token?" text="We help projects build fair-value models on verified assumptions—with transparent rate selection, grounded terminal value, and sensitivity analysis." button="Discuss your valuation" link="https://t.me/karanyuk" >}}
---
## DeFi Hacks 2026: A Taxonomy of $765M in Attacks
- URL: https://giantslabs.pro/knowledge/defi-hacks-2026/
- Section: knowledge
- Date: 2026-04-26
- Last modified: 2026-04-26
- Description: Review of the largest DeFi hacks of 2026 (Kelp DAO, Drift, Resolv, Step Finance, Truebit, Rhea) with a taxonomy of attack vectors and tokenomics lessons.
Between January and April 2026, decentralized finance lost **roughly $765 million** to hacks. Roughly three-quarters of that sum landed in the first 18 days of April through two incidents: Drift Protocol for $285M and Kelp DAO for $292M. The structural shift of 2026 is unambiguous: **the expensive hacks no longer come from buggy code** — they come from compromised operational infrastructure: keys, servers, verifiers, and people.
## The 2026 Numbers
According to DeFiLlama, Q1 2026 saw **34 DeFi protocol incidents** totaling **$168.6 million**. That's a sharp drop from Q1 2025 ($1.58B), but the 2025 figure was distorted by the single $1.4B Bybit breach.
April 2026 flipped the trend. Halborn recorded **$606 million in losses across 12 incidents** — the worst month since February 2025. Drift and Kelp alone accounted for $577M, or **95%** of all April losses.
| Period | Losses | Incidents | Source |
|---|---|---|---|
| Q1 2026 | $168.6M | 34 | DeFiLlama |
| April 2026 (through 26 Apr) | ≈ $606M | 12 | Halborn |
| **Jan–Apr 2026** | **≈ $765M** | **46+** | — |
Halborn's Q1 review puts it bluntly: *"the most expensive attacks are no longer smart-contract bugs — they are key-management failures."* Mitchell Amador, CEO of Immunefi, makes the same point: *"Web2 operational failures, not on-chain code."*
## Taxonomy: Five Layers of Compromise
Every verified major case of 2026 fits into one of **five attack layers** — defined by what the attacker compromised, not what they stole.
| Layer | What gets compromised | 2026 cases | YTD share |
|---|---|---|---|
| **L1. Contract logic** | Code bugs (overflow, access control, reentrancy) | Truebit, SwapNet, SagaEVM | ≈ 6% |
| **L2. Oracles and data** | Price manipulation via fake pools | Rhea Finance, YieldBlox | ≈ 3% |
| **L3. Operational security** | Keys, KMS, devices, RPC nodes | Step Finance, Resolv Labs, Kelp DAO | ≈ 45% |
| **L4. Social engineering and governance** | Contributors, multisig, blind signing | Drift Protocol | ≈ 38% |
| **L5. Frontend and DNS** | Interface hijack, domain | CoW Swap | < 1% |
L3 + L4 + L5 — everything **outside on-chain code** — accounts for **more than 90%** of YTD losses. The classic "smart-contract hack" is below 10%.
A walkthrough by layer follows, with one representative case for each.
## Layer 1: Contract Logic — Truebit
**Loss:** $26.4M · **Date:** 8 January 2026 · **Chain:** Ethereum
Truebit is a verifiable-computation protocol for smart contracts. The attacker drained **8,535 ETH** through a flaw in TRU token-purchase pricing.
The root cause was an **integer overflow** in the buy formula. The contract had been deployed in **2021**, compiled with a Solidity version below 0.8 (no built-in overflow protection), and **had never received an independent audit**. The asymmetric buy/sell pricing model was supposed to deter speculators; without overflow checks it became a door to the reserves.
Within hours of the disclosure, the TRU token **lost 99.95%** of its market cap. Hours later the protocol was exploited again, for an additional ~$300K.
**Lesson:** legacy contracts are technical debt with growing toxicity. Any contract deployed before Solidity 0.8 (or before the discovery of a new attack vector) remains a landmine until it is wound down or redeployed with modern guarantees.
## Layer 2: Oracle Manipulation — Rhea Finance
**Loss:** $18.4M (revised; initially reported as $7.6M) · **Date:** 16 April 2026 · **Chain:** NEAR
Rhea Finance is the largest DeFi protocol on NEAR. Over two days the attacker prepared **423 dummy wallets** and deployed fake token contracts paired with their own liquidity pools. The margin-trading parser then accepted swap routes through these pools as valid price data and **allowed the fake tokens to be used as collateral**.
The vulnerability lay in slippage protection: the system aggregated expected output amounts across swap steps without accounting for the same tokens being reused across multiple steps within a transaction. This let the attacker construct a sequence of swaps that bypassed slippage limits and drained USDC, USDT, ZEC and wNEAR.
The attacker partially returned funds (about $3.36M USDC and 1.56M NEAR sent back to the RHEA lending contract). Tether additionally froze $3.29M USDT.
**Lesson:** an oracle is always an agreement to trust a source. If the protocol accepts prices from arbitrary liquidity pools, the attack surface expands to "anyone who can deploy a fake token pool" — i.e., effectively unbounded.
## Layer 3: Operational Security — Step, Resolv, Kelp
This is **the dominant attack vector of 2026**. Three cases, three different operational failures.
### Step Finance: Device Compromise
**$27M · 31 January 2026 · Solana**
The attackers used targeted phishing and malware to compromise **team devices** and, through them, the treasury and fee-collection wallets. They drained **261,854 SOL**. The smart contracts were never breached — the corporate perimeter was.
Token22 protections allowed the team to recover $4.7M, but the STEP token **collapsed by 96%**. In February 2026 Step Finance announced a full shutdown; affiliated SolanaFloor and Remora Markets followed.
### Resolv Labs: Cloud KMS Compromise
**$24.5M · 22 March 2026 · Ethereum**
Resolv issued the yield-bearing stablecoin USR. The attacker compromised **AWS Key Management Service** — the cloud-stored private key used to sign mint operations. With control of the KMS, they could authorize any mint.
The `Counter` contract accepted a parameter from an off-chain signer and verified the **minimum** USR output — but did **not** check the maximum. With a deposit of $100–200K in USDC, the attacker minted **80 million unbacked USR**, sold them on DEXs and extracted ETH. USR depegged to as low as $0.20 (an 80% drop), partially recovering to $0.56.
### Kelp DAO: Cross-Chain Messaging Infrastructure Compromise
**$292M · 18 April 2026 · Ethereum + 20 chains**
The biggest case of the year and the culmination of the operational layer. Kelp issued rsETH — a liquid restaking token wrapped via LayerZero across **20+ blockchains**.
Anatomy of the attack:
1. The attackers (attributed by LayerZero to North Korea's Lazarus Group) compromised **two RPC nodes** serving Kelp's LayerZero bridge.
2. In parallel, they ran a **DDoS** against the remaining (uncompromised) nodes, forcing the system to fail over to the "poisoned" ones.
3. The compromised nodes fed **forged burn data** from the source chain to the single verifier — the LayerZero Labs DVN.
4. Kelp ran a **1-of-1 DVN** configuration: a single verifier with no second signature required. The forged packet (nonce 308) passed verification and reached the adapter on Ethereum.
5. The adapter minted **116,500 rsETH** (≈ **18% of the circulating supply**) to the attacker's address.
6. The minted rsETH was deposited as collateral on Aave and Compound, used to **borrow real ETH**, which the attacker withdrew. This left **up to $230M in bad debt on Aave** (other estimates put it at $177M).
Kelp paused the bridge **46 minutes later** (at 18:21 UTC). Two follow-up attempts (40,000 rsETH each, ~$100M apiece) were reverted. Arbitrum's Security Council froze **30,766 ETH** (~$71M).
LayerZero's post-mortem stated it had repeatedly recommended Kelp move to a multi-DVN configuration, but the recommendations had been ignored. Kelp disputes that account, arguing 1-of-1 is the **default configuration** of the LayerZero integration.
**Lesson for L3 as a whole:** the off-chain layer **is** the protocol's perimeter. The quality of the smart contract is irrelevant if the key sits in an insecure KMS or the bridge depends on a single verifier.
## Layer 4: Social Engineering and Governance — Drift Protocol
**Loss:** $285M · **Date:** 1 April 2026 · **Chain:** Solana
Drift was the largest DeFi protocol on Solana, with **$550M in TVL**. In **12 minutes** on April 1, the attacker withdrew $285M — primarily JLP tokens ($159.3M), USDC ($71.4M), and other assets.
There is no "classic" hack anywhere in the attack:
- For **six months** the attackers posed as a quantitative trading firm, building trust within the Drift team and among multisig signers.
- Once they had access to the development environment, they slipped several **dormant transactions** — bundles to be signed by Security Council members — leveraging Solana's **durable nonces** mechanism, which lets a transaction be signed now and executed at any later time.
- The signers signed the transactions **blind** — without understanding their full contents.
- At the chosen moment the attacker minted **500 million fake CVT tokens** with a synthetic price, **whitelisted as collateral**. Against this "collateral" they withdrew real USDC, SOL, ETH and JLP.
Drift's TVL collapsed from $550M to $250M. Per TRM Labs and Elliptic, this was the **18th Lazarus Group crypto operation** of 2026. In the 17 days separating Drift and Kelp, the group extracted **more than $575 million** from DeFi through two structurally different vectors: social engineering of signers, and compromise of verification infrastructure.
**Lesson:** a 2-of-5 multisig is not decentralization if the signers sign blindly and can be socially engineered.
## What This Means for Tokenomics
DeFi protocol security is **inseparable from its tokenomics** — and the 2026 cases make this especially clear.
**Token distribution = governance attack surface.** Drift shows how operational governance through a narrow multisig (2-of-5) becomes an architectural single point of failure. The same applies to governance-token distribution: concentration in one holder, or cheap delegation, opens the door to governance attacks.
**Multisig and timelock are part of tokenomics, not an accessory.** Drift demonstrated that a multisig without mandatory simulation and human review of transactions (rather than blind signing) is useless. A timelock — a delay between signature and execution of critical transactions — would have given Drift's council hours to spot the anomaly. There was none.
**Insurance funds vs. loss socialization.** Aave Umbrella will partially absorb the bad debt from Kelp — estimated up to $50M. The remaining shortfall, on the order of tens of thousands of ETH, will be allocated through governance. The likely mechanism is additional AAVE emission to compensate ETH suppliers. That is **direct dilution of token holders** — and in 2026 it is becoming the new norm for post-incident handling of major hacks.
**Off-chain trust must be reflected in tokenomics.** If a protocol depends on **a single DVN verifier** (Kelp), **a single cloud KMS** (Resolv), or **team devices** (Step), those dependencies have to be explicitly disclosed in the project's risk documentation and priced into the token. Hidden off-chain trust is hidden dilution risk in the event of a hack.
## Team Checklist for 2026
{{< checklist title="What DeFi teams should be doing in 2026" type="check" >}}
Multi-DVN or multi-bridge: any cross-chain integration — at least 2-of-3 verification, never 1-of-1
Hardware HSM, not cloud KMS: protocol private keys live in physical devices, not AWS/GCP KMS
Timelock on critical functions: mint, upgrade, admin transfer — 24–48 hour delay minimum
No blind signing: multisig signers must see and understand each transaction (Ledger Clear Sign, Tenderly simulation)
Collateral whitelisting through governance only: no instant additions of new collateral assets
RPC infrastructure monitoring: detect DDoS on external nodes and failover to backups, alert on cross-node data divergence
Regular red-team exercises: social engineering against contributors, phishing simulations, response drills for device compromise
Insurance fund baked into tokenomics from day one: not retrofitted later via emission that dilutes holders
{{< /checklist >}}
## Conclusion
DeFi 2026 is **no longer a battle of code**. It is a battle of operational maturity and the architectural decisions a team makes **before** launch. A smart-contract audit will not protect you from an AWS KMS compromise. Open-source code will not protect you from blind signing. A "decentralized" DAO with a 2-of-5 multisig over the treasury is a centralized object for social engineering.
The takeaway for tokenomists: **the architecture of governance, keys, and off-chain dependencies is part of tokenomics**, not a separate technical discipline. If the project's design doc has no description of how off-chain secrets are protected and exactly who signs which transactions, the tokenomics model is **unsafe by default** — regardless of how clean the vesting schedule and distribution look on paper.
{{< cta title="Tokenomics and operational security audit" text="We'll review your protocol's architecture against the dominant 2026 attack vectors: governance, multisig, bridge integrations, KMS, vesting." button="Discuss an audit" link="/quote/" >}}
---
## DeFi Risk Management: Simulation, Monitoring, and Parameter Optimization
- URL: https://giantslabs.pro/knowledge/defi-risk-management/
- Section: knowledge
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: DeFi risk management: vulnerability detection, risk oracles, and parameter simulation. Gauntlet, Chaos Labs, VaR formulas, and cascade liquidation mechanics.
DeFi protocols manage billions of dollars in user funds. A single misconfigured parameter — collateral factor, liquidation threshold, interest rate — can trigger cascading liquidations and loss of funds. Risk management in DeFi is not a smart contract audit. It's a continuous process of monitoring, simulation, and protocol parameter adjustment.
## Three Categories of Risk Management
The DeFi risk management solutions market splits into three categories. Each addresses a distinct class of problems.
### Category 1: Vulnerability Detection and Economic Exploits
**What they do:** Find vulnerabilities before attackers exploit them. This covers not only code bugs but also economic attacks — oracle manipulation, flash loan attacks, arbitrage on suboptimal parameters.
**Example solutions:**
- **Audit firms** (Trail of Bits, OpenZeppelin, Consensys Diligence) — manual and automated code analysis
- **Formal verification** (Certora, Runtime Verification) — mathematical proof of correctness
- **Bug bounty platforms** (Immunefi) — crowdsourced vulnerability hunting with bounties up to $10M
**Limitations:** An audit is a point-in-time snapshot. Code changes, parameters update, market conditions shift. A six-month-old audit doesn't protect against today's risks.
### Category 2: Risk Oracles, Scoring, and Monitoring
**What they do:** Continuous monitoring of protocol state and real-time risk assessment.
**Key monitoring metrics:**
| Metric | What it shows | Alert threshold |
|---|---|---|
| **Health Factor** | Buffer before liquidation | < 1.2 |
| **Pool utilization** | Share of borrowed funds | > 85% |
| **Supplier concentration** | Dependence on large LPs | Top-3 > 50% |
| **Collateral volatility** | Risk of sharp value drop | 30-day > 80% |
| **Oracle deviation** | Gap between oracle price and market | > 2% |
These are indicative thresholds commonly used by risk managers and should be calibrated per protocol — Aave V3, for example, uses HF < 1 as the actual liquidation trigger while risk-ops dashboards alert earlier (1.05–1.5). Public dashboards from Chaos Labs and Gauntlet publish protocol-specific thresholds.
**Example solutions:**
- **DeFi Safety** — protocol scoring across criteria (documentation, audits, transparency)
- **Risk DAO** — open risk dashboards for lending protocols
- **Oracle monitoring** — detection of manipulation, update delays, source discrepancies
### Category 3: Incentive Simulation and Parameter Optimization
**What they do:** Model protocol behavior under various market scenarios and recommend optimal parameters.
This is the most complex and valuable category. It's where tokenomics and risk management intersect.
## Gauntlet: Simulation as a Service
Gauntlet is one of the largest parameter optimization providers for DeFi protocols. Works with Morpho, Compound, Moonwell, and others (previously also served Aave but departed in February 2024, transitioning to a vault curation model on Morpho).
### Approach
1. **Agent-based modeling.** Gauntlet models the behavior of different participant types (borrowers, liquidators, arbitrageurs) under changing market conditions.
2. **Stress testing.** Simulation of extreme scenarios: what happens if ETH drops 40% in an hour? How many positions get liquidated? Are there enough liquidators?
3. **Optimization.** Based on simulations, Gauntlet recommends parameters:
- Collateral factors for each asset
- Liquidation thresholds
- Liquidation penalties (liquidation bonus)
- Borrowing caps
### Metric: Value at Risk (VaR)
{{< formula math="VaR_α(L) = inf { ℓ ∈ ℝ : P(L > ℓ) ≤ 1 − α }" >}}
- VaR_α(L) — Value at Risk: smallest loss threshold ℓ such that losses exceed it with probability no greater than 1 − α (computed)
- L — protocol loss (random variable; positive values = losses)
- ℓ — candidate loss threshold in dollars
- α — confidence level (typically 0.95 or 0.99)
- inf — infimum, the greatest lower bound of the set of admissible thresholds
{{< /formula >}}
Numeric example: a 95% 1-day VaR of $1M means that on a typical day losses should not exceed $1M, and only on the worst 5% of days losses are expected to breach that level.
Gauntlet calculates VaR for each protocol market: the maximum loss the protocol can suffer (bad debt) at a given confidence level.
## Chaos Labs: Historical Data Simulation
Chaos Labs is a Gauntlet competitor, working with Benqi, Jupiter, GMX, and others (previously also served Aave but ended the partnership in 2026).
### Approach Differences
| Aspect | Gauntlet | Chaos Labs |
|---|---|---|
| **Model** | Agent-based modeling (ABM) | Historical replay + ABM |
| **Data** | Synthetic scenarios | Real historical events |
| **Focus** | Parameter optimization | Optimization + real-time monitoring |
| **Delivery** | Recommendations via governance proposals | Dashboards + alerts + proposals |
Chaos Labs uses a replay-based simulation approach: it takes real historical events (LUNA crash, USDC depeg, FTX collapse) and replays them against the protocol's current parameters. This answers the question: "Would the protocol have survived with current settings if a LUNA-scale event occurred?"
## Parameters Being Optimized
### Lending Protocols (Aave, Compound)
| Parameter | What it determines | Trade-off |
|---|---|---|
| **Collateral factor (LTV)** | How much can be borrowed against collateral | Higher LTV → more capital efficiency, higher bad debt risk |
| **Liquidation threshold** | At what ratio liquidation begins | Low threshold → frequent liquidations, high → more bad debt |
| **Liquidation penalty** | Liquidator premium | High penalty → motivates liquidators, but losses for borrowers |
| **Borrowing cap** | Maximum borrowable in a single market | Limits risk concentration |
| **Interest rate curve** | How rate depends on utilization | Steep curve → fast borrower displacement at high utilization |
### DEX and AMM (Uniswap, Curve)
| Parameter | What it determines | Trade-off |
|---|---|---|
| **Amplifier (A)** | Liquidity concentration in Curve | High A → low slippage at peg, but fragility during depeg |
| **Position range** | Position width in Uniswap V3 | Narrow → higher income, but more frequent rebalancing |
| **Pool fee** | Percentage on each swap | Low → attracts volume, high → compensates impermanent loss |
## Cascade Liquidations
The primary systemic risk in DeFi — cascade liquidations. The mechanics:
1. Collateral asset price drops
2. Positions with low safety margin get liquidated
3. Liquidators sell collateral on the market
4. Selling pressure pushes the price lower
5. New positions fall below the liquidation threshold
6. The cycle repeats
{{< formula math="Cascade_loss = Σ(Collateral_i × (1 − Recovery_i))" >}}
- Collateral_i — size of the liquidated position
- Recovery_i — fraction of funds recovered (depends on market liquidity)
- During a cascade, Recovery falls with each iteration
- Cascade_loss — total protocol loss from the cascade (computed)
{{< /formula >}}
Numeric example: in round 1, $100M of collateral is liquidated at Recovery = 0.9, so the shortfall is $100M × (1 − 0.9) = $10M. In round 2, the price has dropped further and liquidity has thinned: $50M of collateral is liquidated at Recovery = 0.7, adding $50M × (1 − 0.7) = $15M. Total cascade loss: $10M + $15M = $25M.
{{< callout type="warning" title="Black Thursday, March 12, 2020" >}}
On "Black Thursday," ETH fell roughly 50% in a single day. Roughly $8.32M of CDP user collateral was extracted via zero-bid auctions across 1,462 lots — liquidators with no competition claimed collateral for free, leaving the Maker system approximately $5.3M short in unbacked DAI and triggering an MKR mint to recapitalize. The cause: congested Ethereum network and insufficient competition among liquidators. After the incident, Maker revised its auction parameters and added a reserve pool (Stability Buffer).
{{< /callout >}}
## Cascade Liquidation Calculator
The calculator models cascading liquidations in a lending protocol. Set TVL, average position LTV, liquidation threshold, and initial collateral price drop.
Cascade Liquidation Calculator
TVL, LTV, liquidation threshold, price drop — iterative cascade model
## Historical Incidents by Risk Type
Black Thursday illustrates liquidation-infrastructure risk, but it is only one of several distinct failure modes. A compact catalog of canonical DeFi risk-management case studies:
| Incident | Year | Loss | Risk category | Mechanism |
|---|---|---|---|---|
| **Compound DAI oracle** | 2020 | ~$89M liquidations | Oracle manipulation | DAI briefly spiked to $1.30 on Coinbase Pro; Compound's Coinbase-only oracle propagated the price and liquidated thousands of healthy positions |
| **Harvest Finance** | 2020 | ~$24M | Economic exploit | Flash-loan-driven manipulation of Curve pool prices fed into Harvest's vault share valuation |
| **Cream Finance** | 2021 | ~$130M (across multiple events) | Oracle + composability | Flash-loan attacks exploiting price-feed assumptions on illiquid collateral |
| **Mango Markets** | 2022 | ~$114M | Economic/governance | Attacker pumped MNGO spot price, borrowed against inflated collateral, then drained the treasury |
| **Euler Finance** | 2023 | ~$197M | Smart-contract bug | Donation function allowed violation of the liquidation check; later funds were returned by the exploiter |
Each category calls for a different control: oracle manipulation requires multi-source TWAP oracles and deviation circuit breakers; governance capture requires vote timelocks and supply-side limits on collateral listings; smart-contract bugs require formal verification and bug bounties; liquidation-infrastructure failures require backstop buyers and reserve pools like MakerDAO's Stability Buffer.
## How Tokenomists Use Risk Management
When designing tokenomics, risk management isn't a separate phase — it's part of every decision:
{{< checklist title="Risk management design checklist" type="check" >}}
Allocate a reserve fund (Stability Buffer) to cover bad debt
Run [agent-based modeling]({{< relref "models/agent-based-modeling" >}}) with different participant types
{{< /checklist >}}
{{< cta title="Simulations and stress testing" text="Risk management in DeFi is impossible without simulations. More on modeling methods — from sensitivity analysis to agent-based models." button="Simulations in tokenomics" link="/models/simulations/" >}}
---
## Financing a Real-World Asset On-Chain: The Full Economics
- URL: https://giantslabs.pro/knowledge/rwa-financing-economics/
- Section: knowledge
- Date: 2026-07-27
- Last modified: 2026-07-27
- Description: A tokenized RWA deal is a cross-border secured loan wearing a token. Four levers on the funding side—not the collateral—decide whether the economics work.
Every real-world-asset pitch is a photograph of the collateral. Grain in a warehouse, an invoice, a solar farm—real, custodied, a senior claim you can point to. What the deck almost never prices is the other side of the trade: the money. Where does it come from, in what currency, at what hurdle rate, and who buys the collateral on the worst day?
A tokenized RWA deal is not an asset. It is a cross-border secured loan wearing a token, and whether its economics close is decided by four levers—three of which have nothing to do with the collateral at all. Our [agriculture series]({{< relref "knowledge/agri-finance-stack" >}}) took one asset class apart to the bone: the [instruments and rates]({{< relref "knowledge/agri-finance-stack" >}}), the [required investor yield]({{< relref "knowledge/agri-debt-yield" >}}), the [token structure]({{< relref "models/agro-token-architecture" >}}), and [what a default actually recovers]({{< relref "knowledge/agrogalaxy-default-lessons" >}}). This article is the level above that: the funding-side framework those pieces are a worked example of. The numbers below use Brazilian soybean credit because that is where we have measured them, but the four levers transfer to any physical-asset financing—receivables, commodities, equipment—unchanged.
Market anchors used throughout, dated to avoid the usual sleight of hand: CDI 14.15%, Selic 14.25% (Copom, 17 Jun 2026), SOFR 3.63% (20 Jul 2026), and a CME-implied BRL depreciation of about 7.5 percentage points per year (settlement, 22 Jul 2026).
## The pitch shows one side of the balance sheet
A financing deal has two sides. The **asset side** is the collateral and the yield it can support—the part every RWA deck renders in high resolution. The **funding side** is where the capital originates, the currency it is raised in, and the return the supplier of that capital demands. The asset side answers "is this secured?" The funding side answers "does anyone make money?"—and it is almost always left blank.
The reason is that the asset side is photogenic and the funding side is arithmetic. But the arithmetic is where deals die. A tokenized instrument secured by first-rate collateral still fails if it is funded in the wrong currency, priced against the wrong benchmark, or handed to investors whose hurdle rate is set by something you are not offering. Four levers govern that arithmetic.
## Lever 1: slice the risk before you price it
The first mistake is financing an asset's entire life at one rate. Most physical goods have two economically distinct phases: a **creation leg**, where the thing is being produced and can still fail, and a **holding leg**, where it already exists and is merely waiting to be sold. These carry completely different risks, and blending them into a single instrument makes the safe phase subsidize the risky one.
Soybeans make the split concrete. The **production leg** runs from input purchase through harvest—roughly eight months of financing exposure, of which the crop itself stands in the field for about four—and it carries the weather, crop, and execution risk. That leg is financed today at 18–27% in local currency by banks, input-supplier barter, and subsidized quota lines, and it should be: someone has to carry the risk that the crop fails. The **storage leg** is different in kind. The grain now physically exists, has been graded, is insured, sits in a warehouse under a collateral manager, and is two to four months from sale. Financing it at a rate that includes a weather premium means, bluntly, making the storage months pay for weather that can no longer happen.
Price only the second leg and the number moves hard:
{{< formula math="period_cost = rate_annual × (tenor_months / 12)" >}}
- A 9–12% USD product over a 4-month storage leg costs 3.0–4.0% for the period
- The local free-market CDA/warrant discount runs 1.3–1.8% per month—5.2–7.2% over the same four months in BRL, or roughly 3.2–5.5% once converted to USD-equivalent (Lever 2)
- Same collateral, same months: the honest gap is about a point at the midpoint, and it closes entirely at the cheap end of the local market
- Most of what looks like a discount is currency. What the leg split actually buys is a shorter tenor and no weather premium—price it in one currency or you will book an FX spread as if it were credit skill
{{< /formula >}}
The generalizable rule: **find the point in the asset's life where the risk you are paid to carry actually begins, and lend only from there.** For grain it is the warehouse door. For receivables it is acceptance of the invoice, not the signing of the contract. For equipment it is commissioning, not manufacture. The leg you decline to finance is not lost business—it is risk you were never equipped to price.
## Lever 2: no rate means anything until it is in one currency
The second lever is the one that quietly wrecks comparisons. A BRL rate and a USD rate are not comparable numbers, and any deck that puts them side by side is borrowing a spread that belongs to the currency. Covered interest parity is the correction:
{{< formula math="rate_USD_equiv ≈ rate_BRL − depreciation_forward" >}}
- depreciation_forward is the market-priced annual decline of the funding currency, not the naive rate gap
- The Selic−SOFR gap is ~10.6pp (14.25% − 3.63%), but the priced-in BRL depreciation is only ~7.5pp
- The difference exists because Brazil's DI curve already prices Selic cuts toward 11–12% over the year, so the forward does not extrapolate today's peak rate
{{< /formula >}}
This refines a number we published ourselves. The [agri-debt-yield article]({{< relref "knowledge/agri-debt-yield" >}}) used the static shortcut—full hedge cost ≈ CDI − SOFR ≈ 10.5%—to show where the "5–7% in dollars" myth comes from. The CME forward curve as of 22 July 2026 prices less: −1.3% at two months, −2.5% at four, −7.5% at twelve, −10.7% at seventeen. Using the forward rather than the rate gap raises the USD-equivalent of every local alternative, which makes a dollar product look *more* competitive on the borrower's side, not less. Honesty compounds: the static shortcut overstated the hedge, and the live curve corrects it.
Run the whole borrower ladder through the correct conversion and the target segment becomes obvious:
| Borrower channel | Local rate (BRL) | USD-equivalent | Read |
|---|---|---|---|
| Subsidized quota lines | 9–14% | ~1.5–6.5% | Unbeatable—but quota-capped and exhausted early each cycle |
| Prime farmer, private market | 18–20% | ~10.5–12.5% | At parity with a 9–12% USD product |
| Thin-file / frontier / stressed | 24–28% | ~16.5–20.5% | The real edge (upper end reads off distressed-paper pricing, not quoted farm loans) |
| Farmer all-in cost (with fees, insurance) | 30–40% | ~22.5–32.5% | Where the product wins outright |
A 9–12% USD instrument has no edge against subsidized credit and only a marginal one against prime borrowers. Its entire addressable market is the tail paying 20%+ locally or shut out of credit entirely. That is the discipline, not a disappointment. The lever tells you exactly which borrowers a dollar product can and cannot serve, before you spend a cent originating.
## Lever 3: the funding currency is a choice, and cheap money is usually a mirage
If dollars are expensive, why not raise cheaper money elsewhere? Brazil sells about 85 million tonnes of soybeans a year to China—roughly 80% of its shipments, and 73.6% of China's soy imports—and Chinese domestic funding is priced far below both BRL and USD. The temptation is to fund the book in renminbi at 2–3% and pocket the difference.
Covered interest parity kills that arbitrage the moment you hedge:
{{< formula math="(1 − dep_BRL/USD) × (1 − dep_USD/CNY) = (1 − dep_BRL/CNY)" >}}
- Forward curves are not independent: (1 − 7.45%) × (1 − 2.80%) = (1 − 10.04%)
- USD funding hedged into BRL: 3.6% + 7.45% ≈ 11.05%
- CNY funding hedged into BRL: 2.0% + 10.04% ≈ 12.04%
- Both land below CDI (14.15%) only because the forwards price Brazilian rate cuts—and within ~1pp of each other
{{< /formula >}}
Hedged, the cost of money is very nearly currency-invariant—a persistent cross-currency basis of a few tenths of a point is the only residue, nowhere near the spread the pitch implies. Anyone pitching cheap Chinese capital as a *rate* story is quoting the unhedged number and hoping you do not check. The renminbi only wins where the borrower has genuine same-currency revenue to repay from—so the hedge is unnecessary—and that condition holds at the exporter or the SPV that sells to China, never at the farmer.
But that exception is where the interesting structure lives. Follow the grain: the storage leg is exactly the point where the soybeans already exist and are already destined for a Chinese buyer. If that same buyer prepays in renminbi against that same cargo, three things collapse into one entity—**financier, liquidator, and offtaker become the same party.** The funding is real renminbi at roughly 3–5% all-in, repaid from renminbi export proceeds with no hedge required and, under current rules, zero IOF and zero withholding on export prepayment. And the liquidation risk that a dollar structure prices by lining up a grain desk to bid on seized lots simply disappears—the lender is the buyer.
The consequence reframes the whole business. When the offtaker funds the deal, the operator's revenue stops being a credit spread over an 11–12% required investor yield and becomes an origination and servicing fee over a ~3–5% cost of funds. The P&L flips from interest-based to fee-based. This is not currently a signed structure—no precedent exists for renminbi-denominated prepayment funding farm-level credit in Brazil, and that gap is the single load-bearing assumption—but it is where the currency lever stops being defensive arithmetic and becomes a different product.
The deeper point generalizes past soy and past China. **Currency choice is not a rate decision; it is a decision about who your capital provider is and what they are actually buying.** A crypto allocator prices your paper against 25%-plus tech-revenue-backed credit and finds 9% boring. A strategic offtaker prices the same paper against a 2–3% domestic alternative plus the value of securing the cargo, and sees a large pickup. Identical asset, opposite verdict—because one is buying yield and the other is buying supply security. Know which one you are underwriting to.
## Lever 4: the liquidation path is the yield
Secured lending's real question is not the loan-to-value ratio. It is who buys the collateral on the worst day, at what discount, and how fast. An LTV ladder is a promise about coverage; the liquidation path is whether the promise pays out.
A defensible structure names it as an instrument. The reference design runs a **50% launch / 60% target / 80% ceiling** advance ladder against a standby purchase commitment: a grain desk of the Trafigura/Bunge/LDC class agrees to buy seized lots at a 15–20% discount to the published spot reference, within 24–72 hours, in minimum lots of about $1M. If that commitment is real, a loan advanced at 50–60% against collateral that liquidates at 80–85% of spot cannot lose principal at full liquidation—the discount is absorbed inside the coverage buffer.
The word doing the work is *if*. Today that standby is a mapped design parameter, not a signed commitment, and the honest version of the pitch says so. The gap between the two is the entire difference between a senior claim and a recovery. Our [AgroGalaxy post-mortem]({{< relref "knowledge/agrogalaxy-default-lessons" >}}) is the empirical version of this lever: in Brazil's largest agri insolvency, unsecured creditors took an 85% haircut, and the protections that held were exactly the ones with a real enforcement path—segregated estate, clean fiduciary title—while group guarantees, covenants, and ratings recovered nothing. Collateral that cannot be sold quickly is not collateral. It is a story about collateral.
The generalizable rule: **a secured RWA yield is only as real as the signed buyer standing behind the collateral.** Price the standby as a line item, not an assumption. If no one has committed in writing to buy the asset in a fire, the LTV ladder is decoration.
## Putting it together: reconciling the two numbers
A reader who lands on both this page and the [agri-debt-yield article]({{< relref "knowledge/agri-debt-yield" >}}) will notice a tension. That piece prices the honest required yield for senior USD exposure at about **12.25%**. The deals in this one are structured to offer the borrower **9–12%**. If investors demand 12.25% and borrowers pay 9–12%, the rail's spread is negative. Which number is wrong?
Neither—they price different objects, and the four levers explain the whole gap:
{{< callout title="Why 12.25% and 9–12% are both correct" type="info" >}}
1. **Different risk (Lever 1).** The published 12.25% reference case is a 180-day, single-name warehouse claim at a 70% advance rate. The 9–12% offer prices a shorter, lower-advance slice of the same storage leg—2–4 months, grain already graded and warehoused, low advance rate. The credit, collateral, and liquidity layers that build 12.25% legitimately compress on the shorter, safer slice.
2. **FX correction (Lever 2).** The 12.25% is an unhedged USD build, so no hedge assumption touches it—but the live 7.5pp forward (against the old 10.5pp) raises the USD-equivalent of the local BRL credit the borrower would otherwise take, which is what lets a 9–12% USD offer clear against that borrower even while investors require ~12.25%.
3. **Insurance and DFI.** The same article already prices an *insured* senior tranche near 11%; a signed liquidator standby plus credit insurance pulls the requirement toward the top of the 9–12% band.
4. **Funding currency (Lever 3).** Offtaker prepayment replaces the investor-yield frame with a fee-based one—a servicing fee over ~3–5% funding—which sidesteps the 12.25% hurdle entirely.
{{< /callout >}}
The spread exists only when you pull all four levers: finance the safe leg, price the currency with the live forward, obtain a signed liquidator, and match the capital provider to the asset. Skip any one and the negative-spread reader is right. Run the [yield build-up yourself]({{< relref "tools/calc-agri-yield" >}}) and watch how many layers have to compress before a sub-12% offer prices fairly.
## The honest gaps
A framework that only shows the upside is a pitch, not an analysis. Four things are unresolved in even the best-structured version of this deal, and any real diligence starts here:
{{< checklist title="What is not yet solved" type="check" >}}
The money rail is regulated shut, soon. Brazil's BCB Resolution 561, in force from 1 October 2026, bars eFX providers from settling with their offshore counterparties in stablecoins. Whether a foreign loan against agro collateral falls under that regime or registers as external credit outside it is still an open question with the FX banks. The compliant route becomes offshore USDC into an authorized FX institution, which lends BRL through a local FIDC or SCD—with IOF on the inflow and mandatory SCE-Crédito registration above US$1M. The dollar does not reach the borrower directly.
The liquidator is unsigned. The standby purchase commitment that makes the LTV ladder safe is a design parameter today, not an executed contract. Until it is signed and priced, the recovery assumption is a hope.
The warehouses are not ready. Only about 17.6% of Brazilian warehouses are certified, against a storage deficit of 120–135M tonnes—and since June 2026 that certification is voluntary, so the state has stepped back from the filter precisely where independent attestation now has to stand in. Proof that the pledged grain exists and is not double-issued is an operational problem, not a smart-contract one.
The cheap-currency structure has zero precedent. We have found no precedent for a renminbi-denominated prepayment funding farm-level credit in Brazil, and Chinese trade-finance pricing is not disclosed publicly enough to rule one out. The most elegant version of Lever 3 is, for now, a thesis.
{{< /checklist >}}
None of these is a reason not to build the rail. They are the reason to price it honestly—which is the whole point of separating the funding side from the photograph of the asset.
{{< cta title="Pricing an RWA financing structure?" text="We build the funding-side economics for specific deals—the leg to finance, the currency to raise in, the liquidator to sign, and the yield each choice implies—anchored to dated market evidence. Useful before a coupon goes on a term sheet." button="Get in touch" link="/quote/" >}}
## The takeaway
A tokenized real-world asset is a loan, and a loan is priced on its liabilities as much as its collateral. Four levers decide the economics: slice the risk and finance only the leg you can price; convert every rate into one currency with the live forward, not the rate gap; choose the funding currency by matching the capital provider to the asset, knowing that hedged money is currency-invariant; and treat the liquidation path as a signed instrument, not an LTV assumption. The collateral is the part everyone can see. The reason most RWA pitches never close is that the money—where it comes from, in what currency, and who buys it back in a fire—is the part they leave off the slide.
---
## How Farm Credit Works Before the Blockchain: CPR, CDA/WA, and CRA
- URL: https://giantslabs.pro/knowledge/agri-finance-stack/
- Section: knowledge
- Date: 2026-07-03
- Last modified: 2026-07-03
- Description: Brazil's farm-credit stack—CPR titles, warehouse receipts, CRA securitizations: six layers, real rates, LTVs, and what a token can and cannot replace.
At the end of 2025, Brazil had **R$1.41 trillion** of private agricultural finance instruments outstanding. None of that machinery needs a blockchain—and all of it is what a blockchain would tokenize. Every verified agro-token we cataloged in [the first article of this series]({{< relref "knowledge/agricultural-tokenization" >}}) is, legally, a wrapper around one of these instruments: a grain token wraps a CPR, an on-chain securitization mirrors a CRA.
The implication for tokenomics in this vertical: **you inherit the asset rather than design it.** The credit risk, the enforcement path, the tax treatment, and most of the interest rate are fixed by a stack of Brazilian law that predates your protocol by up to three decades. This article maps that stack: the instruments, the six layers a deal passes through, the rates the farmer pays, and the two or three places where a token can change the economics.
The numbers below are from our own analytical work on this market, current as of late 2025–early 2026 unless dated otherwise.
## Two circuits, one system
Brazilian farm credit runs on two parallel circuits—the federal crop-finance plan (Plano Safra) and the free market:
| | Subsidized circuit (Plano Safra 2025/26) | Free-market circuit |
|---|---|---|
| Size / anchor | R$516.2 billion program | Tracks Selic (Brazil's policy rate)—~15% through Q1 2026, 14.25% as of June 2026 |
| Funding source | Rural savings, mandatory bank allocations, LCA, BNDES; Treasury pays banks the gap (R$13.5bn subvention) | Capital markets: CRA, CDCA, FIDC, FIAGRO funds; distributor barter |
| Nominal rate to farmer | Pronaf ~2–6%, Pronamp 10%, others 14% working capital (investment lines 8.5–13.5%) | n/a |
| Effective cost to farmer | ~11.5–16.5% all-in | ~18–25% all-in |
| Investor side | n/a (policy money) | CRA pays IPCA+7–8% in BRL; ~8.5% + FX variation in USD |
The subsidized circuit is rationed—small and family farms first. Everyone else, and every deal beyond the quotas, prices off the free market. This split matters for token design because **the tokenizable flow is the free-market circuit**: policy money never needs your protocol, and the investors a token could reach are the ones currently buying CRAs at IPCA+7–8%.
## The six layers of a deal
Capital reaches a farm through six layers. Tokenization projects typically attack the middle of this chain—registration and funding—and cannot touch the outer ends: collateral law and enforcement.
{{< schema "mechanism/agri-finance-six-layers" >}}
1. **Collateral.** The farmer creates a title. Either a **CPR**—a registered promise to deliver future crop (CPR-física) or to pay its cash value (CPR-financeira), reinforced with a crop pledge, fiduciary transfer, or land mortgage—or, for grain already harvested, a **CDA/WA** warehouse receipt pair. This is the legal foundation of everything above it.
2. **Originator.** Whoever extends the credit: a bank (subsidized circuit), a trader or input distributor (barter against a CPR), a cooperative—Coamo and C.Vale are simultaneously warehouse operators—an agrifintech, or a securitizer.
3. **Registration.** Titles must be registered in a central-bank-authorized registry: B3's central depository leads for CPRs, with CERC as the main alternative. Subsidized rural credit runs through the state SNCR/SICOR system. This layer is why the asset is already digital—the point we made in the first article about what tokenizes first.
4. **Funding.** The subsidized channel taps rural savings, mandatory deposits, LCA issuance, and BNDES. The free-market channel packages receivables into CDCA and CRA and sells them—to FIAGRO agribusiness investment funds (R$44.7 billion in net assets, ~550,000 investors), to individuals attracted by tax exemptions, to institutions, and to FIDC credit funds.
5. **Risk layer.** Credit insurance with subrogation rights, the state PROAGRO program, personal guarantees (aval), take-or-pay off-take agreements with trading houses, and collateral managers acting as legal custodians (fiel depositário) of the stored grain.
6. **Enforcement.** The reason the whole stack works—covered in its own section below, because it is the part practitioners most often get wrong.
## The instrument catalog
Seven instruments do most of the work. What separates them is who can issue them, what backs them, and how they are enforced; yield tells you almost nothing.
| Instrument | What it is | Backed by | Enforceability | Typical pricing |
|---|---|---|---|---|
| CPR-física | Farmer's promise to deliver crop (since 1994) | Crop pledge, fiduciary transfer, mortgage, aval | Extrajudicial title; action for delivery of goods | Effective discount 15–25%+ |
| CPR-financeira | Same title, cash-settled | Same | Extrajudicial monetary execution | IPCA+ / Selic-based discount |
| CDA/WA | Warehouse receipt + pledge certificate | Grain in a certified warehouse | Extrajudicial warehouse auction; shielded from attachment after issuance | CDI (interbank rate) + spread |
| CDCA | Distributor/co-op bond on agri receivables | Pool of CPRs and receivables | Extrajudicial title | CDI / IPCA+ |
| CRA | Securitized agri receivables (capital markets) | Segregated estate at a securitizer | Via the securitizer, not direct | IPCA+7–8% BRL; ~8.5%+FX USD |
| LCA | Bank bond earmarked to agri | Bank's balance sheet + deposit insurance | Obligation of the issuing bank | % of CDI |
| Barter (CPR + duplicata) | Inputs now for crop later | CPR + aval, land mortgage above ~US$250k | Depends on structuring | Hidden discount, effectively >15% |
Four nuances in this table shape what a token architecture can look like:
- **The CPR is the base container.** CPR stock reached roughly R$465 billion by November 2024 and R$560 billion by January 2026; B3-registered CPR alone passed R$418 billion in June 2025, up 40% year over year. CRA, CDCA, and LCA are capital-markets wrappers built on CPR receivables. Tokenize the CPR layer and you sit at the source; tokenize a CRA and you are wrapping a wrapper.
- **The CDA/WA lives and dies with the warehouse.** The receipt is only as good as the certified warehouse behind it—and Brazil's storage deficit exceeds 120 million tonnes, which is why warehouse capacity, not code, caps this segment.
- **Only a securitizer can issue a CRA.** Not a bank, not a protocol. The instrument's strength is the **segregated estate** (patrimônio separado): the pooled receivables are legally insulated from the securitizer's own bankruptcy. The segregated estate does for farm debt what the SPV does for [tokenized shares]({{< relref "knowledge/tokenized-equity-instruments" >}}): the wrapper is ring-fenced from its operator's failure.
- **Barter has a legal trap.** Brazil's high court has held that trading companies cannot hold fiduciary ownership of fungible grain—summary repossession is reserved for financial institutions. A token structure that puts a trader in the creditor seat takes on that weakness.
## What the farmer actually pays
Nominal rates are marketing; the all-in cost is the number that matters—and the gap between the two circuits is the business case for every fintech and token project in this market.
**Subsidized circuit:** controlled rates of 2–14% depending on the program, plus 1.5–2.5 points of fees, mandatory insurance, and transaction taxes. Effective: 11.5–16.5%.
**Free-market circuit:** the base is Selic/CDI around 14–15%. The investor buying the CRA takes IPCA+7–8% (February 2026 prints: Marfrig at IPCA+7.8%, Seara/JBS at IPCA+7.6%). Structuring, registration, collateral management, and insurance stack another several points. Effective cost to the farmer: 18–25%. Agrifintech lending runs roughly 14–23% depending on borrower risk—base books price at 14–15%, riskier stretches climb toward the low twenties; input barter embeds a hidden discount that typically prices above 15% equivalent.
On the collateral side, the market convention is to advance **60–75% of collateral value**, never against 100% of expected yield—weather shortfall (quebra de safra) is priced in structurally:
| Crop | Advance rate (indicative) |
|---|---|
| Soybeans | 65–75% |
| Corn | 62–72% |
| Coffee | 60–72% |
| Cotton | 58–68% |
| Sugar / cane | 55–65% |
Liquid, exchange-traded crops sit at the upper bound because their collateral can be priced daily off CEPEA/Esalq spot indices and B3 futures—the same oracle infrastructure that makes them tokenizable at all. Niche crops and producers outside the Center-South get pushed into barter. (Per-crop ranges are our indicative estimates against the 60–75% market convention; no single public source breaks them down.)
## Enforcement: where the stack earns its keep
Here is the part that surprises people coming from DeFi. The Brazilian agri-finance stack's core innovation is procedural: **the main titles are extrajudicial executive titles** (títulos executivos extrajudiciais). A CPR, CDA/WA, or CDCA holder does not sue to establish the debt; the title itself is directly enforceable.
Three mechanics give the system its teeth:
- **Fiduciary transfer** (alienação fiduciária) passes ownership of the collateral to the creditor until repayment. Under bankruptcy law, such collateral **sits outside the debtor's bankruptcy estate**—the creditor is not queuing with everyone else.
- **Out-of-court repossession runs in days to weeks**, with the debtor given five business days to cure after repossession under the 2023 guarantee-framework law.
- **Warehouse receipts are shielded from attachment** by third-party creditors after issuance—the grain backing a CDA/WA cannot be seized out from under the holder.
The stress test is judicial recovery (recuperação judicial, RJ)—Brazil's Chapter 11. Filings in agribusiness jumped from 534 in 2023 to 1,272 in 2024 and a record 1,990 in 2025. Inside an RJ, unsecured claims face a 180+ day stay and haircuts that reached 85% in the AgroGalaxy case; claims protected by fiduciary transfer sat outside the estate—though courts can still freeze collateral they deem essential (essencialidade) to the debtor's operations. Delinquency on free-market-rate loans hit 12% at end-2025, against 2.6% on subsidized rates. The lesson for anyone structuring a claim here: **the difference between a well-structured and a badly structured claim is not basis points—it is 85 points of principal.**
{{< callout title="What a token can and cannot strip out" type="warning" >}}
Tokenization can compress the **operational premia**: registration and intermediation costs (the 1.5–2.5 points of fees) and part of the structuring spread. It cannot touch the **legal-enforcement premium**: a tokenized CPR is enforced exactly like a paper one—same 1994 law, same bankruptcy code, same courts, same timeline. Any pitch deck claiming blockchain removes the credit-risk spread is claiming the token repeals Brazilian insolvency law.
{{< /callout >}}
## Practitioner takeaways
{{< checklist title="Before you tokenize anything in this stack" type="step" >}}
Name the layer you are replacing. Registration and funding are addressable; collateral law and enforcement are not. A token that "replaces" layer 6 is a token that loses in court.
Pick your container consciously. Wrapping a CPR puts you at the source with a directly enforceable title; wrapping a CRA buys into a securitizer's segregated estate—and its fees.
Check who can legally hold your collateral. Fiduciary ownership of fungible grain is reserved for financial institutions; warehouse custody needs a certified operator as legal custodian.
Price the whole waterfall, not the base rate. The farmer's all-in cost is 18–25% in the free market. If your token model shows dramatic savings, verify you cut a real layer—not the enforcement premium that isn't yours to cut.
Model the RJ scenario first. With ~2,000 agribusiness judicial recoveries a year, default is not a tail case. Ask what your token holder legally holds on day one of a stay.
{{< /checklist >}}
{{< cta title="Structuring a token on top of real-world collateral?" text="We map the legal stack under RWA tokens—titles, registries, enforcement paths—before modeling a single emission curve. That order is what keeps the model honest." button="Get in touch" link="/quote/" >}}
## The takeaway
Brazil's farm-credit stack is a machine for turning future harvests into enforceable, fundable, insurable paper—R$1.41 trillion of it. It was digitized by law years before crypto arrived, which is exactly why it tokenizes at all. But the stack's value is concentrated in the parts a ledger cannot replace: collateral law and out-of-court enforcement. A token earns its place by compressing the middle layers—registration, distribution, settlement—and it keeps that place only if the legal titles underneath stay intact. In the next article in this series we look at the architecture that respects this constraint: why credible agro-token designs split into a non-fractionalized title layer and a fungible pool layer on top.
---
## How to Calculate FDV: Formula, Calculator, Pitfalls
- URL: https://giantslabs.pro/knowledge/fdv-calculation-guide/
- Section: knowledge
- Date: 2026-05-01
- Last modified: 2026-05-01
- Description: Fully Diluted Valuation — formula, data sources, calculator, MC/FDV ranges, and common pitfalls when measuring dilution risk.
FDV is the most-cited and most-misused metric in crypto analytics. An analyst sees $50B FDV on a memecoin and concludes the project is overvalued. An investor sees MC/FDV = 0.05 and panics about dilution. Both are formally right, but the numbers behind them often hide different supply definitions, different measurement times, and different assumptions about burns and treasury. This article walks through FDV calculation step by step: the formula, where to source data, the corrections that matter, and an embedded calculator to validate your numbers.
## What FDV Is
**FDV (Fully Diluted Valuation)** is the project's market value under the assumption that **every token that will ever exist is already in circulation** at the current market price.
Unlike MCap (market capitalization), which is computed from **circulating supply** (what actually trades right now), FDV is computed from **total supply** or **max supply** — the full pool, including locked, vesting, treasury, and reserve allocations.
{{< callout type="info" title="FDV is not a project valuation" >}}
FDV is a **scenario**, not a valuation. It answers the question: "What would this project be worth if every token landed on the market today at the current price?" In reality this never happens — price would collapse if the entire vesting schedule tried to sell at once. FDV is useful for cross-project comparison, not as a standalone measure of value.
{{< /callout >}}
## The Base Formula
{{< formula math="FDV = P_token · Total_supply" >}}
- P_token — current market price of the token in USD
- Total_supply — full token count (or max_supply, if emission is finite)
{{< /formula >}}
Example: a project with total_supply = 1,000,000,000 tokens at $0.50 has FDV = $500M.
In parallel, MCap is calculated as:
{{< formula math="MCap = P_token · Circulating_supply" >}}
- Circulating_supply — tokens in circulation right now (excluding locked, vesting, treasury, and unmined emission)
{{< /formula >}}
And the derived metric that often matters more than either:
{{< formula math="MC/FDV = Circulating_supply / Total_supply" >}}
- The fraction of total supply already in circulation
- The lower MC/FDV, the more tokens are queued for unlock
{{< /formula >}}
{{< callout type="info" title="Healthy MC/FDV range at TGE" >}}
From observed TGE patterns, **10–25%** balances initial sell pressure with confidence in the future distribution. **Below 10%** signals an overhang of future dilution relative to current float (low float / high FDV — the recurring 2024–25 trap, dissected in our [market-making]({{< relref "models/market-making" >}}) breakdown). **Above 30%** means heavy sell pressure in the first months after TGE. This is a heuristic from cycle observation, not a statistical rule.
{{< /callout >}}
## Where to Source the Data
### Total supply
Sources, ranked by reliability:
1. **On-chain** — call `totalSupply()` on the token's smart contract. This is ground truth: whatever the contract says, that's the supply. Mind decimals (18 is typical for ERC-20, but USDC and USDT use 6, WBTC uses 8) — the value returned by the contract must be divided by 10^decimals. Verify on [Etherscan](https://etherscan.io) or the relevant chain explorer.
2. **Whitepaper / project docs** — the declared max_supply. Can differ from current total_supply if emission is incomplete.
3. **CoinGecko / CoinMarketCap** — aggregators. **Not ground truth** — they pull data with delay and can be wrong on complex emission mechanics (rebasing, dynamic supply, mint-on-demand).
### Current price
- **DEX/CEX quotes** — the spot price. If liquidity is fragmented across venues, use **TWAP** (time-weighted average price) or volume-weighted average.
- For fresh TGEs, take the price from the primary listing venue, but recognize its low information value in the first hours.
### Circulating supply
- **CoinGecko / CMC** publish their own estimate, but it's often **manipulated** by projects (excluding treasury from circulating to improve the published MC/FDV).
- **Manual calculation:** total_supply minus locked (vesting), treasury (if treasury isn't counted as circulating), team reserves still in cliff. The [allocation logic]({{< relref "models/allocation" >}}) defines which buckets reach circulation and when.
- **On-chain verification:** read balances of the relevant addresses (team multisig, treasury, vesting contract) and subtract them from total_supply.
## FDV Calculator
FDV / MCap / MC FDV — calculation and comparison
## Common Pitfalls
### FDV is not "the project's valuation"
The most common mistake is treating FDV like an enterprise valuation in venture capital terms. FDV uses the assumption "all emission in circulation at current price" — which never holds in reality. If the entire vesting schedule tried to sell at once, price would crash. FDV is a **scenario view**, not a quantitative measure of intrinsic value.
### Treasury tokens are included in FDV
If a project has 200M total_supply and 100M of it sits in treasury (DAO, ecosystem fund, reserves), those tokens are **counted in FDV** under the full-supply formula. But they should never reach the market — they're tied to specific use cases (grants, liquidity, buybacks). The honest view is **effective FDV**, excluding treasury and similar non-market allocations.
### Memecoins with quadrillion supply
A memecoin with total_supply = 10¹⁵ tokens at $0.0001 has FDV = $100B. The number is impressive but meaningless: price and supply were chosen for cosmetic metrics, not to reflect real value. **At gigantic total_supply, FDV becomes a formal number with no operational meaning.**
### Aggregator data ≠ on-chain
CoinGecko and CoinMarketCap often publish **different** circulating and total figures. These aren't bugs — they're different methodologies for what counts as "circulating," how to handle burn mechanics, how to deal with stale data when trading is paused. **Truth is on-chain**; aggregators are approximation.
### MC/FDV without context
Low MC/FDV (≤10%) isn't **always** bad. For a young project 1–2 years into vesting, it's normal. For a mature project (3+ years post-TGE), low MC/FDV is a signal that many tokens are still locked on schedule and continued unlocks are coming. Connection to other project metrics is covered in [unit economics for token projects]({{< relref "knowledge/unit-economics" >}}).
{{< callout type="warning" title="The low float / high FDV effect (2024–2025)" >}}
A number of major TGEs in the 2024–25 cycle launched with MC/FDV ≤ 5% — only 1–3% of total supply hit the market, the rest stayed in team and investor vesting. This created a **synthetically elevated price** in the first weeks and heavy sell pressure as unlocks rolled in. Many tokens in this cohort lost 60–90% of their price within the first year specifically because of this structure. From observed patterns, **MC/FDV ≥ 15% at TGE** delivers steadier dynamics; exact numbers depend heavily on product traction and unlock schedule. More on this in our [market-making]({{< relref "models/market-making" >}}) breakdown.
{{< /callout >}}
## Advanced Adjustments
### Effective FDV
For investment decisions, analysts compute **effective FDV** — excluding tokens that won't reach the market:
{{< formula math="FDV_effective = P_token · (Total_supply - Treasury - Burned - Permanent_lock)" >}}
- Treasury — DAO / foundation tokens, assuming they're not for sale
- Burned — permanently destroyed (black holes, send-to-zero, contract burns)
- Permanent_lock — tokens locked indefinitely (e.g., LP positions with no withdrawal path)
{{< /formula >}}
This is the "honest" FDV for measuring dilution risk. For projects with sizable treasury allocations, the gap between nominal and effective FDV can run into double-digit percentages — the exact figure depends on the treasury share and its spending policy.
### Time-weighted FDV
If you want to factor in **when** tokens reach the market, not just whether, compute TWFDV:
{{< formula math="FDV_tw = Σ (Tokens_vested(t) · P(t)) for t in [0, T]" >}}
- Tokens_vested(t) — cumulative unlocked tokens at time t
- P(t) — projected price at time t (model-based or scenario)
- T — calculation horizon (typically 3–5 years — common vesting length)
{{< /formula >}}
This metric answers: "What's the expected market value given the unlock schedule and price trajectory?" Used in DCF-style models for crypto projects and in internal valuations at venture funds.
### FDV at TGE vs FDV at full unlock
A useful spread to compute is FDV at TGE (when only a fraction circulates) vs the projected FDV after vesting completes:
- FDV_TGE — what the market sees right now
- FDV_at_unlock — total_supply × projected price 3–5 years out
If the spread is large, the project is interesting. If it's small or negative, the market is pricing in dilution that fundamentals won't outpace. Price projections over 3–5 years should be built from a demand model and [allocation breakdown]({{< relref "models/allocation-template" >}}), not extrapolated linearly.
## FDV Calculation Checklist
{{< checklist type="check" title="Before publishing a number" >}}
- Total supply source declared: on-chain (preferred) or whitepaper, not aggregator without verification
- Price has a timestamp: spot or TWAP, on which venue / index
- Circulating supply computed manually, not taken from CoinGecko on faith
- Treasury and burned accounted separately in effective FDV
- MC/FDV stated with interpretation (<10% / 10–25% / 25%+)
- Context provided: project age (years post-TGE), remaining vesting
- FDV not labeled "the project's valuation" — it's a scenario, not valuation
{{< /checklist >}}
{{< cta title="Building tokenomics with honest FDV?" text="We help startups and mature projects build tokenomics models with transparent metrics — without the low float / high FDV trap." button="Discuss your project" link="/quote/" >}}
---
## On-Chain Analytics for Tokenomists: Tools, Metrics, and Practice
- URL: https://giantslabs.pro/knowledge/onchain-analytics/
- Section: knowledge
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: On-chain analytics for tokenomists: Dune, Nansen, DefiLlama tools, holder concentration metrics, exchange flows, and wallet activity patterns.
A project claims: "we have 50,000 holders and a healthy distribution." Open the blockchain — 10 wallets control 85% of supply, 40,000 addresses hold airdrop dust, and three whales dump $200K on DEX weekly. **On-chain analytics** turns declarations into facts. For a tokenomist, this isn't an optional skill — it's the primary tool for verification, design, and audit.
## Why Tokenomists Need On-Chain Data
The blockchain is a public ledger. Everything is recorded: who owns what, when they bought, where they transferred, how much they staked. A tokenomist uses this data at three stages:
| Stage | What we analyze | Why |
|---|---|---|
| **Design** | Comparables: how competitor tokens are distributed, staking ratios, holder concentration | Calibrating parameters: allocation, vesting, staking rewards |
| **Audit** | Facts: does actual distribution match stated, is vesting executing, where do tokens flow | Verifying a project's claims |
| **Monitoring** | Dynamics: exchange flows, whale activity, concentration changes | Early warning of sell pressure |
{{< callout title="On-chain vs off-chain" >}}
On-chain data is objective but incomplete. It shows **what** happened (transfer, swap, stake), but not **why**. A whale moved 1M tokens to Binance — is it a sale? Rebalancing? Margin collateral? On-chain analytics provides facts; interpretation is up to the tokenomist.
{{< /callout >}}
## Tools
### Dune Analytics
**What it is:** a platform for SQL queries on on-chain data. Supports Ethereum, Polygon, Arbitrum, Optimism, Solana, Base, and dozens of other networks.
**For tokenomists:**
- Custom queries: holder distribution, DEX volumes, flows
- Public dashboards by other analysts
- Real-time data visualization
**Key tables:**
| Table | Contents | Typical query |
|---|---|---|
| `tokens.transfers` | All ERC-20 transfers | Flows between wallets and exchanges |
| `dex.trades` | DEX trades | Trading volume, large swaps |
| `staking.*` | Staking operations | Percentage of staked tokens |
| `balances` | Current balances | Top holders, concentration |
**Example query: top-10 token holders**
```sql
SELECT
address,
balance,
balance * 100.0 / SUM(balance) OVER() AS pct_supply
FROM tokens.balances
WHERE token_address = 0x... -- token address
AND blockchain = 'ethereum'
AND balance > 0
ORDER BY balance DESC
LIMIT 10
```
This query is illustrative. Dune's current `tokens.balances` spells expect a point-in-time filter (e.g., `block_date = current_date` or a `block_time` bound), so a direct copy-paste may need adjustment depending on the exact spell version in use.
**Access:** free plan (limited queries), Pro at $390/month per user (see [dune.com/pricing](https://dune.com/pricing)).
### Nansen
**What it is:** an analytics platform with wallet labeling. Nansen assigns labels to addresses: "exchange," "fund," "whale," "smart money," "market maker."
**For tokenomists:**
- Identifying holder types (not just addresses, but who's behind them)
- Tracking "smart money" — where capital flows
- Exchange inflow/outflow analysis
**Key features:**
| Feature | Description |
|---|---|
| Token God Mode | Full token analytics: holders, flows, concentration |
| Smart Money | Tracking fund, whale, and successful trader wallets |
| Exchange Flow | Token inflow/outflow to CEXs |
| Wallet Profiler | Individual address analysis: portfolio, activity, P&L |
**Access:** Free tier and Pro at $49/month (annual) or $69/month (monthly); custom enterprise on request (see [nansen.ai/plans](https://www.nansen.ai/plans)).
### Arkham Intelligence
**What it is:** a platform for deanonymization and visualization of on-chain data. Specialization — linking addresses to real entities (funds, exchanges, protocols, individuals).
**For tokenomists:**
- Who's behind large wallets
- Flow visualization between entities (relationship graph)
- Alerts on large transfers
**Access:** free plan with basic functionality.
### DefiLlama
**What it is:** a DeFi protocol data aggregator. Open, free, no registration required.
**For tokenomists:**
- TVL (Total Value Locked) of protocols — a trust and usage indicator
- Pool and staking yields
- Cross-network protocol comparison
- Bridge flows
**Key metrics:**
| Metric | What it shows | Where to find |
|---|---|---|
| TVL | How much is locked in a protocol | defillama.com/protocol/[name] |
| Fees / Revenue | Protocol income | defillama.com/fees |
| Yields | Pool yields | defillama.com/yields |
| Stablecoins | Stablecoin supply by network | defillama.com/stablecoins |
| Bridges | Cross-chain flows | defillama.com/bridges |
**Access:** completely free, open API.
### Etherscan and Block Explorers
**What it is:** the basic tool for viewing individual transactions, addresses, and contracts.
| Network | Explorer |
|---|---|
| Ethereum | Etherscan.io |
| BNB Chain | BscScan.com |
| Polygon | Polygonscan.com |
| Arbitrum | Arbiscan.io |
| Solana | Solscan.io |
| Cosmos ecosystem chains | Mintscan.io (covers a family of Cosmos SDK chains) |
**For tokenomists:**
- Checking specific transactions and contracts
- Reading smart contracts (verifying staking, vesting parameters)
- Viewing holder lists (limited)
### Tool Comparison
| Tool | Data type | Cost | Networks | Primary use |
|---|---|---|---|---|
| Dune | SQL queries | Free / $390/mo (Pro) | 20+ | Custom analytics |
| Nansen | Labeled wallets | Free / $49–$69/mo (Pro) | 10+ | Holder identification |
| Arkham | Deanonymization | Free+ | 10+ | Who's behind an address |
| DefiLlama | DeFi aggregator | Free | 100+ | TVL, yields, comparison |
| Etherscan | Block explorer | Free | 1 per network | Transactions, contracts |
## Key Metrics for Tokenomists
### 1. Holder Concentration
**Why it matters:** high concentration = risk of price manipulation, centralized governance, mass sell-off.
#### Concentration Ratio
{{< formula math="CR_n = Σ(Balance_top_n) / Supply × 100" >}}
- CR_n — share of supply controlled by the top-n wallets (computed)
- CR_10 > 80% — critical concentration (author's heuristic, not a standardized benchmark)
- CR_10 < 50% — healthy distribution (author's heuristic)
- Thresholds assume team, treasury, foundation, and CEX custodial wallets are **excluded** — otherwise early-stage tokens trivially exceed 80% in their first years
{{< /formula >}}
**Benchmarks:**
| CR_10 | Interpretation | Example |
|---|---|---|
| < 30% | Excellent distribution | Bitcoin (~6% — top-10 addresses, per Arkham/River/CoinLore 2026) |
| 30–50% | Healthy | Broadly distributed token |
| 50–70% | Moderate concentration | Ethereum (~61%, top-10 addresses excluding the Beacon Deposit Contract, as of mid-2026); typical DeFi token |
| 70–90% | High concentration | Early-stage project |
| > 90% | Critical | Red flag |
{{< callout type="warning" title="Exclude contract addresses" >}}
When calculating concentration, exclude: exchange addresses (custodial), staking smart contracts, bridges, treasury wallets. Otherwise "top-10" will show exchanges and contracts, not real holders. A canonical example is Ethereum's Beacon Deposit Contract — if counted as a single address, it alone holds a majority of ETH supply and dominates any "top-10" list, creating a misleading concentration picture. Nansen and Arkham help automatically categorize addresses. Also distinguish **address-level** from **entity-level** concentration: the same entity (exchange, ETF custodian, fund) often spreads balances across many addresses, so address-level top-10 understates real concentration, while entity-level top-10 overstates it if treated as "holders" rather than custodial aggregates. The Bitcoin figures illustrate this: top-10 addresses ≈ 6% of supply, but top-10 entities (including exchanges, ETFs, and MicroStrategy-style treasuries) exceed 25%.
{{< /callout >}}
#### Gini Coefficient
{{< formula math="Gini = (2 × Σ(i × Balance_i)) / (n × Σ(Balance_i)) − (n + 1) / n" >}}
- Balance_i — i-th balance in the sorted list (ascending: smallest first)
- i — rank position from 1 to n
- n — total number of addresses
- Gini = 0 — perfect equality (everyone holds equal amounts)
- Gini = 1 — perfect inequality (one address holds everything)
- For free-float token holder distributions, typically observed: 0.85–0.99 (highly sensitive to methodology — wallet vs entity, inclusion of dust and contract addresses)
{{< /formula >}}
This is the canonical discrete rank-based Gini (equivalent to twice the area between the Lorenz curve and the line of equality). It requires balances to be **sorted in ascending order** before ranks `i` are assigned; with this convention the result is bounded in [0, 1]. The previously common form `1 − 2·(Σ i·x_i)/(n·Σx_i) + 1/n` assumes descending sort and is algebraically equivalent to the canonical form above only with the correct sign conventions — we use the ascending form to avoid ambiguity.
The Gini coefficient for crypto assets is almost always > 0.9 (extreme inequality). This is normal: investors, the team, and treasury hold the bulk. What matters isn't the absolute Gini, but its **trend**: decreasing = distribution improving, increasing = concentration growing.
### 2. Exchange Flows
**Why it matters:** token inflow to exchanges = potential sell pressure. Outflow = accumulation.
{{< formula math="Net_flow = Inflow_CEX − Outflow_CEX" >}}
- Net_flow > 0 — inflow to exchanges (classically read as bearish) (computed)
- Net_flow < 0 — outflow from exchanges (classically read as bullish) (computed)
- Look at the 7-day moving average, not individual days
{{< /formula >}}
{{< callout type="warning" title="This signal has weakened since 2023" >}}
The "inflow = bearish, outflow = bullish" rule of thumb was decisively muddied by several structural changes:
- **Spot ETFs** (BTC, ETH) move large quantities on and off exchange wallets for custody rebalancing between authorized participants and custodians — these flows have nothing to do with retail sell pressure, and can run in either direction irrespective of market sentiment.
- **Staking and liquid staking** — for PoS assets, outflows increasingly reflect deposits into staking contracts or LSTs, not long-term "cold storage" accumulation. Conversely, unstaking withdrawals may land on exchanges for hedging rather than immediate sale.
- **OTC desks and internal transfers** — exchanges periodically reshuffle hot/cold wallets, which registers as flow without any underlying user activity.
Treat exchange net flow as a contextual signal, not a standalone trigger. Cross-reference with ETF creations/redemptions, staking deposit contract activity, and stablecoin flows before drawing conclusions.
{{< /callout >}}
| Signal | What's happening | Interpretation |
|---|---|---|
| Large CEX inflow | Whale transferred tokens to exchange | Potential sale within hours/days |
| Sustained outflow | Tokens withdrawn to cold wallets | Accumulation, long-term holding |
| Inflow after unlock | Investors withdraw unlocked tokens to exchange | Expected sell pressure |
### 3. Wallet Activity
**Why it matters:** active address count shows real token usage (unlike trading volume, which is easily faked).
| Metric | Definition | What it shows |
|---|---|---|
| Daily Active Addresses (DAA) | Unique addresses with transactions per day | Daily activity |
| New addresses | New addresses that received the token | Audience growth |
| Holding time | Average token holding duration | Holder loyalty |
| Coin age (dormancy) | Average "age" of transferred coins | Old coins moving = large players acting |
### 4. Staking and DeFi Positions
| Metric | Formula / source | Why |
|---|---|---|
| Staking ratio | Staked_tokens / Total_supply | Shows what share is locked and not pressuring the market |
| DeFi TVL in token | DefiLlama / Dune | Token used as collateral, liquidity |
| LP concentration | Top LPs' share of the pool | Risk of liquidity withdrawal |
| Unlock schedule | On-chain vesting contract | When to expect sell pressure |
## Practical Applications
### Auditing a Project's Tokenomics
When auditing an existing project, a tokenomist verifies on-chain data against a checklist:
{{< checklist title="On-chain audit checklist" type="check" >}}
Distribution matches stated: whitepaper allocation matches actual balances (treasury, team, investors)
Vesting is executing: vesting contract is functioning, unlocks happen on schedule
Concentration within limits: CR_10 < 70% (excluding exchanges and contracts)
No anomalous flows: large transfers to/from exchanges, unexplained treasury movements
Staking is healthy: staking ratio in target range, no dominance by 1–2 validators
Liquidity is sufficient: AMM pool depth can absorb vesting unlocks
Burn/emission matches model: if the model assumes burning — it's happening on-chain
{{< /checklist >}}
### Designing New Tokenomics
When building tokenomics from scratch, on-chain data from **comparable projects** helps calibrate parameters:
| Parameter | Where to look | What to find |
|---|---|---|
| Target staking ratio | Comparables in the same category | Median value for PoS/DeFi |
| Liquidity pool size | DEX pools of comparables | Depth relative to market cap |
| Post-airdrop distribution speed | Dune: airdrop recipient behavior | % who sold within 7/30 days |
| Active users | DAA of comparables | Realistic forecast for the business plan |
| Optimal liquidity allocation | % of supply in DEX pools of comparables | 5–15% is a commonly observed range in our practice, but highly project-dependent |
### Post-Launch Monitoring
After TGE, on-chain monitoring provides early signals:
| Signal | Data source | Action |
|---|---|---|
| Rising CEX inflow | Nansen Exchange Flow | Prepare liquidity, alert the MM |
| Declining staking ratio | Dune: unstaking events | Investigate cause (yield, competitor, panic) |
| Concentration increasing | Dune: top holders | Whale accumulating — assess intent |
| DAA declining | Dune: active addresses | Declining usage — product problem |
| Large treasury mint | Etherscan | Verify alignment with governance decision |
## Limitations of On-Chain Analytics
{{< callout type="warning" title="Don't overestimate on-chain" >}}
On-chain data is a powerful tool, but with limitations. Not all conclusions are obvious, and not all signals mean what they appear to.
{{< /callout >}}
| Limitation | Explanation |
|---|---|
| **Incomplete attribution** | One person can own hundreds of addresses. CR_10 may show 10 addresses belonging to a single whale |
| **CEX addresses = aggregates** | An exchange's balance represents thousands of users. A large exchange wallet ≠ a large holder |
| **Private networks** | L2 data, private chains, and off-chain settlements may be unavailable |
| **Correlation ≠ causation** | Inflow to exchange ≠ guaranteed sale. It could be rebalancing, margin collateral, OTC |
| **Historical bias** | On-chain shows the past. Extrapolation is the analyst's responsibility |
## Holder Concentration Calculator
Enter top-10 wallet balances and total supply to calculate CR_10.
Holder Concentration Calculator (CR₁₀)
Top-1, top 2–5, top 6–10, total supply — concentration and risk assessment
## Common Mistakes
{{< checklist title="On-chain analytics pitfalls" type="check" >}}
Counting addresses as users: one person = many wallets. "100K holders" may be 5K real users with dust addresses from airdrops
Ignoring exchange addresses: including Binance Hot Wallet as "top-1 holder" distorts the concentration picture
Exchange inflow = sale: this is correlation, not causation. Check actual trades, not just transfers
Looking at absolute values: CR_10 = 60% for a post-TGE project is normal (team + investors). What matters is the trend: is concentration decreasing over time?
Extrapolating trends: "staking has grown for 3 months → it will grow forever" — no. Staking grows to equilibrium, then stabilizes
{{< /checklist >}}
{{< cta title="Need on-chain analytics for your tokenomics?" text="We build monitoring frameworks, identify holder concentration risks, and track emission health for DeFi and GameFi projects." button="Get in touch" link="/quote/" >}}
---
## Product-Led Tokenomics: Designing a Token From the Product
- URL: https://giantslabs.pro/knowledge/product-led-tokenomics/
- Section: knowledge
- Date: 2026-04-20
- Last modified: 2026-04-20
- Description: Product-led tokenomics: a framework for designing a token from product architecture — JTBD, value capture, and archetype-to-mechanics mapping.
Most failed tokens were not broken at the math layer. They were broken at the moment someone decided to launch a token before they could articulate, in one sentence, what the product does. The allocations, the emission curve, the vesting — all of that is downstream. If the product is not a real product, no mechanism will save the token. If the product is real, the mechanism almost designs itself. This is what we mean by **product-led tokenomics**: treating the token as a consequence of the product rather than an input to it.
This article describes the framework we use to get from a product to its tokenomics in a defensible order. It is aimed at founders, CPOs, and token designers who are past the "do we need a token" question (covered in [when you don't need a token]({{< relref "knowledge/when-token-not-needed" >}})) and are now looking at the blank canvas of what the token should actually do.
## The Failure Mode: Token-First Design
The dominant failure mode in this industry is not bad math. It is sequencing. A team decides on a token — usually under fundraising pressure — and then backfills utility. The product gets contorted to justify the token: forced staking to "reduce circulating supply," governance over parameters nobody actually disputes, discounts that would have been cheaper as a fiat subsidy. The token extracts value from users instead of capturing value that already flows through the product.
The cleanest diagnostic: ask a founder *"if we deleted the token tomorrow, what would break in the product?"*. If the honest answer is "nothing critical," the token was never part of the product. It was a financing instrument wearing a product costume.
{{< callout title="The core reframe" type="info" >}}
Tokenomics is not a layer you add to a product. It is a consequence of the product. Any design step that skips the product description is guaranteed to produce mechanics that fight the product rather than amplify it.
{{< /callout >}}
## The Four Layers
Product-led tokenomics moves through four layers, in order, and each layer constrains the next. Skipping a layer means the next one has no ground to stand on.
**Layer 1 — Jobs-to-be-done.** What does a user actually hire this product for? Not "access to Web3" or "decentralization" — a concrete job: move USD from one country to another cheaper, earn yield on idle BTC, launch a memecoin without writing Solidity, settle a derivative without counterparty risk. If the JTBD cannot be written on a napkin, the token cannot be written either.
**Layer 2 — Value proposition.** Given the JTBD, what is the product promising? Cheaper, faster, more transparent, permissionless, composable. This layer filters which parts of the JTBD the product actually owns. It also surfaces the honest competitive frame: what happens if the user solves this job with a centralized alternative? If the centralized alternative is fine and cheap, the protocol is building on thin ground.
**Layer 3 — Product core.** This is the operational heart of the product: the flows of money, data, and work that actually happen when the product is used. Who pays, who gets paid, who does the work, who bears the risk, where does value leak, where does it pool. The product core is a concrete diagram, not a pitch deck bullet. We return to this layer in detail below, because almost every tokenomics mistake happens here.
**Layer 4 — Token mechanics.** Only now does the token appear. The mechanic is whatever mechanism is needed to route value captured in Layer 3 back into the product loop — to pay for work, to align long-term holders, to coordinate governance over parameters that genuinely need coordinating. The rule of thumb: the mechanic must name a specific flow from Layer 3 that it touches. If it cannot, it is decoration.
For the full six-stage process that surrounds these four layers (research, stakeholder analysis, modeling, documentation), see [the tokenomics design process]({{< relref "basics/tokenomics-process" >}}).
## Token-First vs Product-First: Why the Sequence Determines the Outcome
The same team, the same product idea, and the same available mechanics can produce a healthy token or a dead one depending solely on the order in which decisions are made.
The left column ends in decay because every step introduces friction that has to be covered by new buyers. The right column ends in a loop because each step produces a constraint that the next step satisfies, and value captured at the product layer keeps cycling back into the system.
## Product Core: What It Actually Is
"Product core" is a working term for the *operational* description of the product — what actually happens when a user shows up. It is the layer where most tokenomics work goes wrong, because founders often describe the product in marketing terms and then hand the description to a tokenomist. Marketing terms do not have enough structure to derive mechanics from.
A usable product core description answers six questions:
| Dimension | The question it answers |
|---|---|
| **Who pays** | Which side of the product pays, with what, and how often |
| **Who works** | Which actors do productive work (validators, LPs, creators, curators, solvers) |
| **Who bears risk** | Who absorbs volatility, default, slashing, inventory risk |
| **Value flow** | The actual path of money from payer to worker, and every hop in between |
| **Capture points** | The hops where the protocol can skim without destroying the flow |
| **Network effects** | What makes the product compound — liquidity, data, reputation, directory |
Only after this table is filled in can the conversation shift to tokens. The capture points row is the most important: it tells you *where* value can legitimately flow into a token, and by extension, which mechanics are viable. A protocol with no capture points (free product, no fees, no scarce resource) has no mechanism-layer surface for a token to attach to — which typically means the project does not need a token, a situation handled in [when you don't need a token]({{< relref "knowledge/when-token-not-needed" >}}).
## Mapping Product Core → Token Mechanics
Once the product core is explicit, the mechanic selection becomes a matching problem rather than a creative one. Every product archetype has a small number of mechanics that fit its value flow, and a much larger number that don't. The matrix below is the compressed version of the matching table we use internally — rows are product-core archetypes, columns are mechanic classes.
A few patterns are worth naming explicitly.
**Exchange/Marketplace** (public illustrations: BNB, HYPE, LEO). The product core is a matching engine that charges fees. Capture points are the fee line and the liquidity layer. Fit mechanics: fee capture routed to buyback/burn, staking-gated discounts on fees, tiered access by token balance. Anti-fit: pure governance tokens — the governance surface is narrow (listing decisions, fee parameters), and users do not want to govern, they want to trade. A work-token model makes no sense because the exchange is the one doing the work.
**L1/Infrastructure** (ETH, SOL). Product core is secure block production and execution. Capture points are gas fees and the security budget. Fit mechanics: gas demand, staking for security, fee burn. Work-token logic applies to validators. Governance-only is weak because the constitutional parameters move rarely — governance is a by-product, not the product.
**Asset issuer/Stablecoin** (Sky (SKY, formerly MKR), Frax (FRAX, formerly FXS)). Product core is the issuance and backing of a liability. Capture points are the stability fee and the risk premium. Fit mechanics: fee accrual to token, staking-gated backstop (slashable insurance), governance over collateral parameters. Discounts are an anti-pattern — you do not want holders to get cheaper liabilities.
**Yield aggregator / DeFi primitive** (CRV, CVX and the ve-model family). Product core is a pool of capital directed by governance. The entire innovation here is that the mechanism *is* the product — LPs, boosters, and bribers participate because the ve-lock structure directs emissions, and that directionality has market value. Discounts are meaningless because there is no consumer-facing fee; the token holder is the producer.
**DePIN** (Helium, Filecoin). Product core is a network of physical or virtual resource providers. Capture is at the resource-purchase layer, but the immediate need is to subsidize coverage before demand is there. Fit mechanic: work-token emission against verified resource delivery, with a payment coin (often separate) to avoid pricing instability for buyers.
**Attention/Media.** Product core is user attention, which is not a financial flow by default. Most token attempts fail here because attention does not naturally flow into a capturable line — it has to be wrapped in advertising, subscriptions, or creator economics first. The matrix is mostly "conditional" for this archetype: a token can work, but only after the attention has been converted into something that looks like one of the other archetypes.
For how individual mechanisms compose once selected, see [mechanism design]({{< relref "models/mechanism-design" >}}) and the underlying [utility models]({{< relref "models/utility-models" >}}).
## Archetype Deep Dive: The Exchange/Marketplace Loop
To make the mapping concrete, one archetype worked through end to end. The exchange/marketplace is the most commercially mature product-token pairing in the industry, and it shows the full loop from fee to capture to reinforcement.
Every arrow in that diagram is a decision the team has to make explicitly. How much of the fee line goes to each bucket is not a matter of taste — it follows from where the product is in its life cycle. Early in the curve, the bottleneck is liquidity and retention, so the split leans toward discount and staker yield. Later, as competitive advantage shifts from liquidity to brand, buyback/burn becomes more efficient per dollar because the marginal user is no longer price-sensitive.
The split itself is small arithmetic. What matters is that it *moves* with the product. The same fee line at different life-cycle stages should not be split the same way. Below — an illustrative split for an exchange with $10M in monthly fees, shown across three stages:
| Stage | Buyback | Stakers | Insurance | Discount | Rationale |
|---|---|---|---|---|---|
| **Early** — liquidity-starved, price-sensitive users | 15% ($1.5M) | 30% ($3.0M) | 10% ($1.0M) | 45% ($4.5M) | Retention is the bottleneck. Discount is the cheapest way to defend volume; buyback wastes fee revenue on a thin holder base. |
| **Growth** — volume established, brand forming | 40% ($4.0M) | 30% ($3.0M) | 10% ($1.0M) | 20% ($2.0M) | Balance: buyback starts working as the float base broadens; discount still matters but less. |
| **Mature** — brand-driven demand, price-insensitive | 55% ($5.5M) | 25% ($2.5M) | 15% ($1.5M) | 5% ($0.5M) | Marginal user is no longer fee-shopping. Buyback is the most efficient use of captured value; insurance grows to protect the franchise. |
The real version adds market-impact limits on the buyback, a yield cap on stakers, and a floor on the insurance fund. But the key point is that the split is a knob the product team controls, and the right position of that knob is a *product* decision, not a token decision. It answers the question: *what does the product need most right now, given how users are actually behaving?*
## Anti-Patterns
Four mistakes show up across the majority of failed tokens. All of them are consequences of skipping the product-core layer.
{{< checklist title="Anti-patterns to avoid" type="check" >}}
- Forced utility. A feature is gated behind the token for the sole purpose of creating token demand. If removing the gate would not materially harm the product, the gate is extracting value from users rather than capturing it.
- Governance-only tokens. The only thing the token does is vote on parameters that rarely change and usually don't matter. Voter turnout collapses, and the token has no price floor other than speculation.
- Copy-paste ve-lock. The ve-model is adopted because it worked for a DeFi primitive, applied to a product that is not a DeFi primitive. Locked supply goes up, product metrics do not, and the holder base turns into short-sighted emission farmers.
- Discount as the entire thesis. The token gives a fee discount and nothing else. This is a fiat subsidy with extra steps — and fiat subsidies are cheaper, because they don't require a token treasury to defend a price.
{{< /checklist >}}
## Design Checklist
Ten questions to run through before a single line of allocation is drafted. If any answer is "we haven't decided," you are not ready to design the token.
{{< checklist title="Product-led tokenomics checklist" type="step" >}}
- JTBD in one sentence. Can you state the user's job in a single sentence, without mentioning the token?
- Competitive alternative named. Which specific centralized or on-chain alternative solves this job today, and why is yours better?
- Value flows drawn. Do you have a diagram of who pays, who works, and where money hops?
- Capture points identified. At which hops can the protocol legitimately skim without killing the flow?
- Mechanic-to-flow binding. For every mechanic you plan to include, can you point at the exact flow it touches?
- "Delete the token" test. If the token were removed tomorrow, which product functions would genuinely stop working?
- Minimal mechanic set. Is this the smallest set of mechanics that implements your capture strategy, or are there borrowed ones?
- Governance surface honest. Is there a real parameter space worth coordinating over, or is governance ornamental?
- Life-cycle fit. Does your split (buyback vs yield vs discount vs insurance) match where the product actually is in its curve?
- Reinforcement loop closes. Can you trace captured value back into the product loop as retention, new users, or reduced cost of capital?
{{< /checklist >}}
If all ten answers are solid, the allocation table and emission curve become straightforward — they are now serving a specified purpose, not inventing one.
{{< cta title="Designing tokenomics from a real product?" text="We work with founders and product teams to translate product architecture into token mechanics that reinforce the business, not fight it." button="Talk to us" link="/quote/" >}}
---
## Proof of Reserves for Physical Collateral
- URL: https://giantslabs.pro/knowledge/proof-of-reserves-physical-collateral/
- Section: knowledge
- Date: 2026-07-27
- Last modified: 2026-07-27
- Description: You can't hash a silo. Proving tokenized grain, metal, or oil exists—and isn't pledged twice—is an attestation stack, not a Merkle tree.
In 1963, Tino De Angelis borrowed a fortune against tanks of soybean oil in Bayonne, New Jersey. The tanks held mostly seawater, with a thin film of oil floating on top for the inspector; some were plumbed together so the same oil could be pumped ahead of the man with the dipstick. The receipts were issued by American Express's own field-warehousing subsidiary. When it unwound, roughly $180M evaporated—about $1.9B today—and it took the brokerage Ira Haupt & Co. down with it during the week President Kennedy was shot.
The Salad Oil Scandal is the oldest lesson in real-world-asset finance: a token is only as good as the proof that the thing behind it exists and belongs to you. Sixty years later, "proof of reserves" is a phrase everyone in crypto knows—and almost everyone applies to physical collateral without noticing that the crypto version does not survive the trip to a warehouse. You can't hash a silo. This article is about what you do instead, and why it is objection number one in every RWA deal we see—the honest gap the [financing-economics framework]({{< relref "knowledge/rwa-financing-economics" >}}) flagged and left open.
## Why crypto proof of reserves does not transfer
After FTX imploded in November 2022 with roughly an $8B hole between claimed and actual reserves, exchanges rushed to publish proof of reserves. The mechanism is two proofs bolted together. **Proof of assets:** the exchange signs messages from its on-chain wallets, so anyone can sum the reserves on a public block explorer. **Proof of liabilities:** every customer balance is hashed into a leaf of a Merkle tree, combined pairwise up to a single root; each user checks that their own balance is included in that root without seeing anyone else's. The best implementations wrap a zero-knowledge proof over the tree—a zk-SNARK at Binance, a zk-STARK at OKX—to prove no account was slipped in with a negative balance, which is the exact trick a naive sum hides.
The property that matters is this: crypto proof of reserves is **self-verifying**. You do not have to trust the exchange, or even the auditor. You read the chain and recompute the hashes yourself. That trust-minimized, anyone-can-check quality is the whole point—and it is precisely what physical collateral has none of.
And notice where even crypto PoR is contested: on its off-chain, self-reported side. The asset side is cryptographically checkable for ownership and total—but not for the completeness of the wallet set, nor for the single instant it captures. The liability tree, meanwhile, is whatever the exchange chooses to include. On 21 October 2022, two days after Gate.io's PoR snapshot, Crypto.com transferred around 320,000 ETH—some 80–85% of its ETH—to Gate.io, then it came back a week later; the CEO called it an accidental cold-storage misfire. Accidental or not, it is the textbook picture of how a point-in-time attestation can be flattered by borrowed coins. Binance's report covered only Bitcoin, about 16.5% of client assets. Its attestor, Mazars, paused all crypto work that December and pulled the reports from its own site. That is why an **attestation is not an audit**: an attestation checks one management assertion at one date; an audit reviews the whole balance sheet over a period. That gap is only now closing: as of July 2026 Circle has been audited annually by Deloitte since FY2022 on top of monthly attestations, and Tether engaged a Big Four firm in March 2026 for its first full USDT audit, above its quarterly attestations. Under MiCA what forced USDT off EU venues was the absence of e-money authorisation rather than the missing audit, but the reserve-transparency regime is the same pressure; the [fiat-backed peg model]({{< relref "models/stablecoin-tokenomics" >}}) lives or dies on it.
Hold that thought and cross to a warehouse. For physical collateral, the entire object of proof *is* that contested off-chain side. There is no public ledger of the world where anyone can independently confirm that the grain is in the silo, or that it was pledged to only one lender. Proof of reserves' single genuine superpower—self-verification—is exactly the property that does not make the jump. What replaces it is a chain of people who sign their names, backed by a stack of evidence that makes their signatures expensive to fake.
## The two failures the stack has to stop
Every physical-collateral fraud is one of two shapes, and both open a gap between the paper and the physical thing at the moment the paper is issued.
The first is **the collateral isn't there, or isn't what the paper says**. Salad Oil is the archetype—seawater under a film of oil. Its modern twin: in 2023 Trafigura took a roughly $577M charge after cargoes billed as refined nickel turned out to be carbon steel and other steel and iron products. Of the more than 156 containers inspected, not one held nickel. No registry and no price feed would have caught it, because the documents were internally perfect; only someone opening the box at origin would have.
The second is **double-issuance**—the same physical asset pledged to several lenders at once. This is the one that dominates RWA conversations, and its reference case is Qingdao. In 2014, a metals trader at the Chinese ports of Qingdao and Penglai used duplicated warehouse receipts to pledge a single stock of alumina, aluminium and copper to lender after lender, much of it structured as commodity repos. Roughly 400,000 tonnes of metal worth about $380M was leveraged into an estimated $4.2B of financing across 18 Chinese and 7 international banks; Chinese-bank exposure alone topped $3B. Citi, Mercuria, Standard Chartered, HSBC, Glencore, and Trafigura were all in it; Citi and Mercuria fought over a $270M metal repo in the London courts. When authorities discovered the duplicate receipts in May 2014, they locked the warehouses—which meant no one could even verify their own exposure. There was no registry reconciling receipts against physical stock, and no lender held independent custody. Both holes are the whole story.
Brazil has its own live version. The Grupo Safras warehouse group in Sorriso, Mato Grosso entered judicial recovery in May 2025 with R$1.78bn of debt and roughly 900 creditors, about 800 of them local farmers who had delivered grain that the stock records no longer showed. Banco do Brasil alone was in for R$303.6M. Grain in, records that don't reconcile: the title diverged from the goods, exactly as at Qingdao. We walked through what a default like this actually recovers in [the AgroGalaxy post-mortem]({{< relref "knowledge/agrogalaxy-default-lessons" >}})—but that is the sister question. AgroGalaxy asks what you get back after a borrower fails; proof of reserves asks whether the collateral was ever there, and pledged only once, in the first place.
## The attestation stack
If you cannot hash the silo, you build layers, and you price the trust each one still requires. None of them is cryptographic. Each has a cost and a failure mode, and the discipline is knowing which layer stops which fraud.
{{< callout title="The layers, and what each one is for" type="info" >}}
- **Registry / title uniqueness.** One warrant per physical unit—minted once, retired on release, impossible to re-pledge or forge. This is the layer Qingdao's duplicated receipts and Access World's 2017 fake nickel warrants both slipped past. It is the systemic defense against double-issuance: independent custody closes the vector at a single custodian, but only a shared registry catches the same lot pledged through two of them. Reconciling the *release* of goods against retirement of the title matters as much as the issue—on-chain is where all of it is cheapest to enforce.
- **Telemetry.** Silo level sensors, weighbridge integration on every truck in and out, CCTV. Cheap, and it proves *flow*—but it proves movement, not custody, and a determined operator can spoof it. Sensor data alone does not move a lender's required discount.
- **Collateral manager.** The load-bearing layer, where trust actually begins. But custody is necessary, not sufficient: Salad Oil's warehouser had custody and still signed for water. The legal form and the signer's independence are everything (next section).
- **Assay and substance.** Verify what is *in the box*, not just the paperwork—the layer Trafigura's nickel was missing. A grade certificate at intake, sampled by an independent surveyor.
- **Price oracle.** For the value side: a median of independent references (for grain, CEPEA/ESALQ, B3, and CBOT/ICE), a heartbeat, a deviation trigger, and a fail-closed default. This is the tractable part—it is the same shape as any DeFi oracle.
- **On-chain record.** The token and registry hold the *attestation*, not the grain. This is what people mistake for the proof; it is only the ledger the proof is written into.
{{< /callout >}}
The mistake in most "tokenized commodity, fully backed, proof of reserves on-chain" pitches is collapsing this stack to its last two layers. An oracle and an on-chain record are real work, but they verify a number and a signature. They say nothing about whether the physical thing exists, and the uniqueness a registry enforces is only ever as good as the issuance discipline feeding it. Gold in a vault—[the clean case we cover in the ownership-model piece]({{< relref "models/ownership-model" >}}), where PAXG publishes monthly vault attestations and XAUT pairs quarterly BDO attestations with a Chainlink Proof of Reserve feed—attestations, note, not audits, even in the easy case—makes this look easy, because a bar in an allocated vault is discrete, high-value, and rarely moves. Grain, oil, and base metal are fungible, bulk, and in constant motion. And because bulk grain is commingled rather than boxed, the registry tracks a pro-rata share of a common mass, not a discrete unit—so dividing a shortfall becomes its own problem on top of double-issuance. That is where the model breaks, and where the middle layers earn their fee.
## Who signs the attestation
The single most important design choice in physical proof of reserves is who signs, in what legal capacity, how often, and with what liability. Everything else is instrumentation feeding that signature.
The pivotal distinction is **CMA versus SMA**. Under a Collateral Management Agreement, the manager—an SGS, Bureau Veritas, Control Union, Cotecna, or Drum Risk—takes physical custody and control of the stock, becomes the legal bailee, and holds the goods to the lender's order in a tripartite structure. Under a Stock Monitoring Agreement, the manager only inspects and reports; title and control stay with the borrower. The gap between them is the gap between "an independent party holds your collateral" and "an independent party looked at your collateral last month." Neither is publicly priced; the working band we are validating with collateral managers puts a CMA near 0.25–1.0% a year on stored value, with an SMA a half or a third of that, and it is worth exactly what it costs less.
Attestation frequency is the next knob—we treat a signed daily stock statement as the floor and continuous, event-driven reporting keyed to the weighbridge as the target for live collateral, though whether lenders demand the latter is exactly what we are asking them—and a deviation threshold sets when a discrepancy freezes the line and calls margin—somewhere between 1% and 5% of stock, though which number lenders' risk teams actually accept is still an open question we are putting to them.
But the failure mode that no amount of frequency fixes is **the captured signer**, and it arrives in two shapes. The first is capture by identity—auto-emissão: an operator issuing warehouse receipts on its own grain, in its own warehouse, as its own borrower. When issuer, warehouse, and borrower are one entity, the attestation is a company vouching for itself. The second is capture by operation, and it is the one people miss. American Express's warehousing arm was a legally separate company from Allied Crude, and it still signed for tanks of seawater—because it sat on the borrower's site, ran on the borrower's staff, and was paid by the borrower. Legal separation was never the safeguard; independence in practice was. The structural fix has to satisfy both: a third-party depositário that leases and operates the warehouse unit and issues the titles, with its own people and its own fee source, so the party that signs has nothing to gain from the grain going missing. Whether that workaround holds in Brazilian law—and whether auto-emissão is permissible at all—is still with counsel. If you read one thing off a proof-of-reserves claim, read whether the signer is independent of the borrower. If it isn't, the rest is theater.
## The economics, and why most claims are hand-waving
Instrumenting a warehouse is not free, which is why so much of the market waves at proof of reserves rather than paying for it. Vendors do not publish prices, so these are the bands we are testing with them rather than observed market rates: somewhere under $10k to north of $70k per unit for sensors, weighbridge integration and cameras, plus hundreds to a few thousand dollars a month for monitoring software and service; and the collateral manager takes its 0.25–1.0% on top. On a modest lot those costs are a real drag on the spread, which is why they get skipped.
Then there is the ground truth. In Brazil, only about 17.6% of warehouses hold the SNCUA certification, per a June 2026 MAPA figure—and in the same month, certification became *voluntary* under a new law. The state stepped back from the very filter that independent finance leans on, exactly where independent attestation is now needed most. Even the paper trail is thin: actual [CDA/WA]({{< relref "knowledge/agri-finance-stack" >}}) issuance is not publicly aggregated by B3, the registries, or the central bank, so the instrument that is supposed to make grain financeable is itself opaque. When someone tells you their tokenized-commodity product has proof of reserves, the first question is not "is it on-chain"—it is "who is the collateral manager, are they independent, and what did the instrumentation cost." The honest answers are usually a much shorter list than the deck implies.
## The honest limits
No physical proof of reserves is cryptographic, and pretending otherwise is how the next fraud gets funded. What the stack buys is a chain of liability expensive to corrupt: an independent custodian with something to lose, telemetry that has to be actively falsified rather than passively trusted, an assay that opens the box, a registry that refuses a second pledge, and an oracle that fails closed. Every one of those layers has a defeat—a colluding manager, spoofed sensors, an inspector shown the wrong tank, insurance that litigates for years instead of paying, a court that freezes enforcement inside a recovery. The goal is not to eliminate trust. It is to concentrate it in a named, independent, liable party and to make betraying it cost more than the collateral is worth.
{{< checklist title="Reading a physical proof-of-reserves claim" type="check" >}}
Who signs, and are they independent of the borrower? If issuer, warehouse, and borrower are the same entity, stop here.
CMA or SMA? Custody and control, or inspection and a monthly report—know which you are paying for.
Is there a unique-title registry? One warrant per unit, retired on release. Without it, double-issuance is unpriced.
Is the substance verified, not just the paper? An assay at intake, or you are trusting the label on the box.
What is the attestation cadence and the deviation trigger? Daily-signed is the floor; name the percentage that freezes the line.
Does the oracle fail closed? A price feed that keeps quoting through a source outage is worse than none.
Is release reconciled to redemption? Goods leaving must retire the title—weighbridge-out matched to warrant retirement, authorized by someone independent.
Is the title legally perfected? Existence and uniqueness are not enough—will the warrant hold against third parties and inside a recovery?
{{< /checklist >}}
{{< cta title="Tokenizing a physical asset?" text="We design the custody and verification model deal by deal—the collateral structure, who signs the attestation and in what legal capacity, the oracle and registry, and the honest cost of the stack. Before you promise anyone their collateral exists." button="Get in touch" link="/tokenization/" >}}
## The takeaway
Crypto proof of reserves works because anyone can check the chain. A silo has no chain, so its proof of reserves is a different instrument entirely: a stack of attestation layers, each stopping a specific fraud, each with a cost and a defeat, all resting on whether the party who signs is independent of the party who borrows. Salad Oil, Qingdao, Trafigura, Grupo Safras—sixty years and four asset classes—are one lesson repeated: the token was fine, the paper was fine, and the collateral was seawater, or steel, or pledged to five other lenders. This is the layer the [financing economics]({{< relref "knowledge/rwa-financing-economics" >}}) rests on, and the one most decks leave off the slide. Proving the reserve is real is not the boring part of a real-world-asset deal—it is the gate everything downstream is priced through.
---
## The AgroGalaxy Default: A Stress Test for RWA Design
- URL: https://giantslabs.pro/knowledge/agrogalaxy-default-lessons/
- Section: knowledge
- Date: 2026-07-03
- Last modified: 2026-07-03
- Description: Brazil's R$4.6bn agribusiness insolvency tested every protection RWA structurers rely on. What held, what failed, and the six lessons for tokenized credit.
On Monday, September 16, 2024, Brazil's largest listed farm-inputs retailer missed a payment of about R$70 million. Within two days its securitizer had declared automatic acceleration, the CEO and five of nine board members had resigned, and the company had filed for judicial recovery—Brazil's court-supervised reorganization, its equivalent of Chapter 11—with some **R$4.6 billion** of debt. By the time the restructuring plan was confirmed in May 2025, unsecured creditors had been cut 85%.
For this series, AgroGalaxy is the closing argument. The previous four articles claimed that [what a token holder legally owns]({{< relref "knowledge/agri-finance-stack" >}}) matters more than the token, that [architecture must keep enforcement whole]({{< relref "models/agro-token-architecture" >}}), and that [credit risk deserves ~300 bps even against grain collateral]({{< relref "knowledge/agri-debt-yield" >}}). This case ran the experiment at full scale: every protection mechanism an RWA structurer relies on—rating, covenant, guarantees, floating charge, receivables sweep, segregated estate, credit insurance, fiduciary assignment—was tested in a single insolvency. The results were unusually clean, and all figures below come from public filings, court records, and the Brazilian financial press.
## The company that was a credit fund in disguise
AgroGalaxy was a private-equity roll-up of farm-input retailers: seeds, fertilizers, crop protection, ~170 stores at peak, listed in 2021 already carrying about 5× net leverage. The business model is the detail that matters for RWA readers: roughly **80% of sales were barter**—inputs handed to farmers on credit against their future crop, papered as farmer receivables on AgroGalaxy's own balance sheet. Under the retail brand sat a leveraged, unhedged credit fund concentrated in one sector and one climate.
In 2023 the cycle turned all at once: some crop-protection products fell 60–70% off their peaks, fertilizers halved, El Niño hit yields, and Brazil's policy rate was rising again. Revenue fell 60% between 2022 and 2024; a R$53.9 million profit became a R$2.48 billion loss. Leverage went from 3.3× to 8.5× in a year against a covenant of 3.0×. Two sponsor injections—R$150 million in late 2023 to hold the covenants, then R$400 million into a receivables fund in May 2024—failed to stop the slide. Then came the missed R$70 million payment (interest plus first amortization) on a R$500 million agribusiness receivables certificate (CRA), issued in 2022 through VERT, the licensed securitization house that pools farm receivables into tradable certificates. The filing followed within two days.
## What held, what failed
The insolvency put eight protection mechanisms on trial simultaneously. The verdict sheet:
| Mechanism | Verdict | What happened |
|---|---|---|
| Credit rating | **Failed—absent** | By all available evidence the CRA carried no rating from any major agency; investors' first line of assessment did not exist |
| Leverage covenant (3.0×) | **Failed** | Recorded the breach at 8.5× after the fact; prevented nothing |
| Intra-group guarantees (fiança) | **Failed** | Every guarantor subsidiary entered judicial recovery alongside the parent—the guarantees became unenforceable exactly when needed |
| Floating charge (garantia flutuante) | **Failed** | Conferred no real priority inside the process |
| Bank receivables sweep (trava bancária) | **Failed for the banks** | The court unblocked ~R$205 million of swept receivables and returned them to the debtor |
| Segregated estate (patrimônio separado) | **Held** | The securitizer's estate isolated CRA holders from VERT's own risk—but not from the debtor's default |
| Credit insurance | **Held, partially** | Insurers covered ~R$1 billion of ~R$3 billion supplier debt (total supplier exposure, wider than the ~R$1.5B in-plan supplier class in the "Who lost what" table below), paid out, and stepped into the queue via subrogation; the other R$2 billion was never insured |
| Fiduciary assignment (cessão fiduciária) | **Held—for some** | Several creditors holding fiduciary title to specific external receivables preserved their collateral rights outside the process; a fiduciary-grain class was restructured inside the plan on long schedules |
{{< schema "mechanism/agrogalaxy-rj-boundary" >}}
Two rows of that table carry the whole argument, because together they draw the line this series has been pointing at.
First, the **segregated estate held**—and protected against the wrong risk. VERT's structure worked exactly as designed under Brazil's securitization framework: CRA holders were fully insulated from anything happening to the securitizer itself. What the wrapper never promised, and could not deliver, was protection from the borrower. Asset segregation is bankruptcy remoteness from the *issuer*, and it is worth nothing against the credit quality of the *debtor*.
Second, the **fiduciary boundary was decisive where it was clean**. Several creditors whose claims rested on fiduciary assignment (ownership of specific, external receivables transferred to the creditor until repayment) preserved their rights outside the process; those whose fiduciary collateral sat inside the group's own grain flow were restructured with everyone else. Holders of certificates backed by the group's own promises—guarantees from subsidiaries that filed alongside the parent, floating charges (a claim over the company's general, shifting asset pool) on a melting balance sheet—took the 85% cut. The court in Goiânia reinforced the boundary from the other side too, striking six clauses of the plan that tried to extend the debtor's protection to shareholders and third-party guarantors: confirmation of the plan, the ruling said, is not a shield for co-obligors.
## Who lost what
| Creditor class | Exposure | Outcome |
|---|---|---|
| CRA holders (agri funds + retail investors) | ~R$830M in CRAs (R$500M in the defaulted issue) | Debentures at an 85% discount over 16 years, or conversion into a recovery fund (~21% chose it) |
| Banks | ~R$990M | Restructured; heavy cuts; the largest voted against the plan and lost |
| "Partner" suppliers (kept shipping, didn't sue) | part of ~R$1.5B | 100% of face value—but a 2-year grace and 8–11-year schedule |
| Other unsecured suppliers | part of ~R$1.5B | 85% discount, 26 installments starting after 3 years |
| Credit insurers | ~R$1B covered | Paid policyholders, subrogated into the queue |
| Shareholders | — | More than 90% below the 2021 IPO price |
One note on the retail side: the defaulted CRA paid roughly CDI+6% (six points over Brazil's interbank benchmark), tax-exempt for individuals, and sat in listed agribusiness funds and retail brokerage accounts. Several funds held 6–8.2% of their net assets in AgroGalaxy paper and marked quotas down within days. The instrument was liquid on the way in; the underlying farmer receivables were not liquid on the way out. Token wrappers inherit this asymmetry and usually amplify it—a lesson worth keeping next to any "instant liquidity" slide.
## The wave, not the exception
AgroGalaxy was the largest case, and it was not isolated. Agribusiness judicial recoveries in Brazil climbed from 534 in 2023 to 1,272 in 2024 and a record 1,990 in 2025. Two more billion-real farm-input distributors followed the same path over the following year; across the three largest cases creditors absorbed about R$5 billion of haircuts. The country's largest bank reported 90-day-plus farm-portfolio delinquency of 6% by the end of 2025 (2.23% at the end of 2024).
The market's repricing followed the pattern this series would predict. CRA issuance held near R$43.5 billion in 2023, roughly level with 2022, then slipped to about R$40 billion in 2024—its first annual decline in years (Uqbar/Anbima). The instrument survived; the assumption that agri receivables are quasi-sovereign did not. Regulators were already moving the same way: a 20% single-debtor exposure limit for securitizations predates the default (Res. CVM 194, November 2023)—the case illustrates why it exists rather than being its cause. Later measures followed the same logic: court-system protection for physical-delivery farm titles against inclusion in recovery estates, and a tax revision for the retail-exempt instruments. Each tracks a failure mode this case exposed.
## Lessons for tokenized credit
{{< checklist title="What AgroGalaxy teaches RWA structurers" type="step" >}}
Segregation is necessary and insufficient. Emulate the segregated-estate model on-chain—issuer bankruptcy remoteness is table stakes—and never present it as protection against the borrower.
Discount intra-group guarantees to zero. When the group fails, its guarantees fail with it, in the same courtroom on the same day. If more than half the collateral package is group paper, price the claim as unsecured.
Demand external, enforceable, monetizable collateral. The creditors who did best held fiduciary title to specific assets outside the group—the on-chain equivalent is the locked warrant tier from our architecture article, never a promise wrapped in a token.
Fix the monitoring gap. No rating, a covenant that fired after the fact, and investors learning from a missed coupon: continuous revaluation, degradation signals, and single-debtor limits (the regulator caps these at 20%) are the token-native answer.
Disclose asset liquidity separately from token liquidity. The certificate traded; the receivables did not. A liquid token on an illiquid claim is a redemption run waiting for a trigger.
Treat insurance as a partial layer. Subrogation genuinely worked here—but coverage stopped at about a third of supplier debt (~R$1B of ~R$3B). Target coverage above half, and name the insurer in the docs.
{{< /checklist >}}
{{< cta title="Stress-testing an RWA structure?" text="We model default scenarios the way this case played out in court—claim by claim, inside and outside the estate—before a single token is issued. That analysis is cheaper than an 85% haircut." button="Get in touch" link="/quote/" >}}
## The takeaway
AgroGalaxy is the rare case where the market ran a controlled experiment on every clause in an RWA term sheet. The mechanisms that survived were structural choices made before the first real of credit moved: segregated estates, fiduciary title to external assets, insurance with subrogation. The mechanisms that failed were all forms of trusting the borrower's own paper: group guarantees, floating charges, after-the-fact covenants, absent ratings. The boundary between an 85% loss and a full recovery was drawn at structuring time, and no ledger moved it an inch in either direction. Tokenization makes good structures verifiable and bad ones faster to distribute; which one you hold is decided long before the mint.
---
## The Unit Economics of an AI Agent
- URL: https://giantslabs.pro/knowledge/ai-agent-unit-economics/
- Section: knowledge
- Date: 2026-07-27
- Last modified: 2026-07-27
- Description: Everyone describes the agent-payment rails; almost no one computes the P&L of one agent doing one task. Here it is, line by line.
The AI-agent economy has one number it quotes obsessively and another it almost never computes. The first is volume: x402, an agent-payment rail that barely existed a year earlier, passed 165 million cumulative transactions by late April 2026 and has kept climbing through the summer, the large majority of them on Base. The second is the income statement of a single agent doing a single task—what one job actually costs to run and what it can be sold for. Every deck describes the rails. Almost none builds the P&L.
The received wisdom, which [we have argued ourselves]({{< relref "knowledge/ai-agents-tokenomics" >}}), is that most agent tokens behave like memecoins because the agent has no cash flow for the token to capture. That is correct, and it is also unfinished: it asserts the missing cash flow rather than computing it. This article builds the statement line by line—the cost of a task, the multiplier everyone leaves out, the margin that survives, who pays for the inference, and why cheaper models do not save you. The token question answers itself once the arithmetic is on the table.
*(Prices below are mid-2026 API rates. Model names and numbers drift monthly; treat them as a dated snapshot, not a constant.)*
## The unit, and the multiplier everyone ignores
The unit is one task: one agent completing one job—a research report, a resolved bug, a booked trip, an executed trade. The instinct is to price it as one model call. That instinct is wrong by an order of magnitude, and the error is the whole story.
An agent task is not a call. It is a loop: plan, call a tool, read the result, critique it, retry, call another tool, assemble an answer. Anthropic, describing its own multi-agent research system, put hard numbers on this—a single agent uses about **4× the tokens of a chat interaction, and a multi-agent system about 15×**, with token usage alone explaining roughly **80% of the performance variance** on their research evaluation. More loops buy more quality, and they cost proportionally.
Worse than proportionally, in fact. Each loop re-sends the growing transcript: on step twenty the agent re-reads the previous nineteen steps before choosing the twentieth. Cost scales like the sum of a growing series—closer to quadratic in steps than linear—so each successive call carries more input than the last. That inflates input *volume* quickly, though whether it dominates the *bill* depends on the price ratio: with output priced ~5× input and a decent cache-hit rate, generated tokens often still cost more than re-sent ones. Both climb with the loop, which is the point.
{{< formula math="Cost_task ≈ k × Cost_call, where k = the loop multiplier (calls × context growth)" >}}
- Cost_call is one model call, [priced per token]({{< relref "knowledge/units-of-work-pow-to-awu" >}}): input × input price + output × output price
- k is the agentic multiplier: how many calls the task takes, times the context re-reading each carries
- k is roughly 4–15× a single chat turn for a well-built agent, and the *same task* can vary up to 30× run to run
- The lesson: a task P&L is a distribution with a fat tail—model the tail, not the average
{{< /formula >}}
## The cost of one task
Start with the call. In mid-2026 a frontier model runs about **$5 per million input tokens and $25 per million output** (Claude Opus 4.8; GPT-5.6's flagship tier sits slightly above at $5/$30; Gemini's Pro tier undercuts at roughly $2/$12). A cheap frontier-lab tier is a fifth of that—**$1 in, $5 out** (Claude Haiku 4.5). Open-weight models served on a US host land lower still, around **$0.50–1.70 per million** (DeepSeek V3, Llama 3.3). A single frontier call of five thousand input and one thousand output tokens costs about five cents.
Now run the loop, and check it against measured reality rather than the five-cent call. A deep-research task—the kind that reads dozens of sources and writes a report—costs about **$0.95** in inference, measured on a mid-tier model (the ~$2/$12 band) with roughly a 60% cache-hit rate. Run the identical task on the frontier tier quoted above and it lands closer to **$2.10**. A coding agent runs about **$1.05 per benchmark instance attempted**, and nearer **$1.69 per bug actually resolved**—a distinction worth keeping, since failed attempts still burn inference. The loop turned a nickel into a dollar or two. Note that is a wider spread than the 4–15× band above: the chat-turn baseline is a smaller call than the five-cent one priced here, and a research task sits at the deep end of the loop. Note too that the tier you pick moves the total by more than any prompt optimization will. Caching helps, but only on the input side, so on a task whose bill is mostly generated tokens it shifts the total by tens of percent, not multiples. That is before the task's other line items.
| Line item, per research task | Cost |
|---|---|
| Inference (loop of ~10 calls, cached) | $0.95 |
| Tool and API calls (search, retrieval, execution) | $0.10–1.20 |
| Settlement (x402 / USDC micropayment on Base) | ~$0.00 |
| **COGS per task (median run)** | **~$1.05–2.15** |
| Same task, unlucky run (up to 30× token draw) | $10–30 |
Three things fall out immediately. The rails everyone writes about—x402, the micropayment, the wallet—are a rounding error; settlement is sub-cent against a dollar of inference. On a search-heavy task the tooling can cost more than the model—grounded search at retail rates passes a dollar for eighty queries—which inverts the cost structure most decks assume. And the cost of goods is not a number, it is a distribution with a fat tail: the median task clears at a dollar, and the occasional task that spirals into a long loop costs ten. Anything that prices the task at a flat rate is short the tail. And a task that fails outright still burns its full inference while earning nothing—rework is a cost line the median hides, and under per-outcome pricing it compounds with the token tail.
## The revenue side, and the margin that survives
Against that cost, what can an agent charge? The public reference points are low. Salesforce prices agentic work two ways: about **$2 per agent conversation**, and **$0.10 per action**—the latter being the [discrete unit of work]({{< relref "knowledge/units-of-work-pow-to-awu" >}}) proper. A research task is closer to a conversation than an action, so $2 is the fairer comparison, and it is still low. Put a $2 price against a $1.05–2.15 median COGS and the gross margin on a hard task runs from **roughly 48% down through zero—before the tail is counted.** A cheap, tool-light task clears comfortably; a search-heavy one on a frontier model loses money at that price. For the tasks actually worth automating, the margin is thin, volatile, and sometimes absent.
And it gets thinner, because the task is usually commoditizable. If the agent's only input is a model any competitor can also call, there is no moat, and price falls toward cost plus a sliver. The durable margin lives in the layers a competitor cannot copy: proprietary data, a hard-won tool integration, distribution to the buyer, and the willingness to carry liability for the outcome. An agent that is a thin wrapper on a public model has the unit economics of a reseller marking up a commodity, which is to say almost none.
## Why cheaper models do not save you
The obvious objection: inference is collapsing in price, so the margin problem solves itself. For an LLM of fixed quality, cost has fallen roughly **10× a year**—a16z's "LLMflation"—and Epoch AI measures the drop for a fixed capability at anywhere from **9× to 900× a year depending on the task**. Surely the agent's COGS follows it down.
It does not, and the reason is the multiplier. As models get cheaper they also get more capable, and more capable agents are handed longer horizons—more steps, deeper loops, always-on operation. The direction is structural rather than a proven time series, but the incentive is one-way: capability gets spent on longer tasks, so per-task token draw climbs even as the per-token price falls. Forbes made the arithmetic concrete in July 2026: **if a task's token draw rises 20-fold while the unit price falls 75%, total model charges still rise fivefold.** (Market-wide, Goldman projects token consumption growing **24× by 2030**—that figure is adoption, not per-task intensity, but it points the same way.) LLMflation is real, and it is out-run by loop-growth before it reaches the agent's income statement. The price of a token is not your cost; the price of a token times *k* is, and *k* is climbing.
## Who pays for the inference
There is a principal-agent problem baked into every agent's P&L, and it is decided by one question: who eats the variable, fat-tailed COGS?
If the **user pays per call**—the inference passed through—the agent has no incentive to bound its own loop. Every extra retry is revenue for the model provider and cost for the user, and "thoroughness" becomes a euphemism for an unbounded bill. If the **agent charges a fixed price** and eats the inference, it carries the 30× tail risk itself, and the temptation is to protect margin by clipping loops—fewer steps, worse answers, quality quietly cut to defend a spread. If it charges **per outcome**—paid only for a resolved task—incentives on quality align, but the agent is fully exposed to the expensive tail, and one pathological task can erase the margin on ten clean ones.
Subscription and capped-usage plans—a fixed base with metered overage—are the common real-world hybrid, but they only relocate the problem: at the cap, the clip-the-loop incentive comes back. There is no free option. The billing model is not a pricing detail bolted on at the end; it is the business model, and it is downstream of the COGS distribution. Pick it before you build, because it determines which tasks you can afford to take.
## Where the token captures value
Now the token question answers itself. The agent's revenue and its settlement are dollars—x402 clears in USDC, Google's AP2 is deliberately payment-agnostic (cards and bank rails included, stablecoins merely among them), and the inference bill is denominated in dollars too. The margin is thin and volatile. A project token layered on top of this flow captures **none** of it, because none of the unit economics runs through the token. That is the arithmetic under the memecoin diagnosis: not a narrative failure, a cash-flow one.
A token earns its place only when it is load-bearing *inside* the unit economics, and there are only a few honest positions:
{{< callout title="The three places a token can actually sit in the P&L" type="info" >}}
- **Staked collateral priced into reliability.** The agent bonds tokens and is slashed for a failed or fraudulent task—a performance bond the buyer is genuinely paying for (true insurance only if the slashed stake compensates them; a burn-only slash is pure deterrence). Either way it sits in the COGS as the cost of a credible guarantee, not on top as decoration.
- **A mandated settlement or fee unit, with a burn or fee accrual tied to task volume.** These are distinct value-accrual mechanics, but they share one precondition: the token has to be genuinely required. If USDC and a smart contract would do the same job, the token is a tax the market routes around, which is [the most common agent-token pitfall]({{< relref "models/agent-tokenomics-patterns" >}}).
- **Access or priority with real willingness to pay.** Queue priority or a capability that a buyer would pay a dollar subscription for anyway—if, and only if, the underlying service is wanted.
{{< /callout >}}
Everything else—revenue-share promises, governance over an agent that earns nothing, a "unit of account" for volume that does not exist—fails the same test: run the task P&L, and check whether a single dollar of margin actually passes through the token. Usually it does not. The [four value-capture mechanics]({{< relref "knowledge/ai-agents-tokenomics" >}}) and the [pattern catalog]({{< relref "models/agent-tokenomics-patterns" >}}) are the menu; this P&L is the test each dish has to pass before it is worth cooking. On the other side of the same dollar, the inference cost is a decentralized-compute operator's *revenue*—the supply-side economics we cover in [the DePIN piece]({{< relref "models/depin-tokenomics" >}}).
## A unit-economics template for an agent
{{< checklist title="Before you price an agent (or its token)" type="check" >}}
What is k? Measure calls-per-task and tokens-per-call on real jobs, not one demo. If you have not measured the loop, you do not know your COGS.
What is the tail? Model the task cost as a distribution. The p90 run, not the median, decides whether flat pricing survives.
Are you caching the re-sent context? Cache hits bill re-sent tokens at a fraction—it is the biggest single lever on the loop's cost.
What is the non-inference moat? If the only input is a public model, price falls to cost. Name the data, tool, or distribution a competitor cannot copy.
Who eats the inference? User, agent, or per-outcome—each aligns different incentives and carries different tail risk. This is the business model.
Does cheaper inference help you, or just raise k? If capability buys longer horizons, your COGS can rise as the model gets cheaper.
Does a dollar of margin run through the token? If not, the token is narrative. If yes, name exactly which line item it sits in.
{{< /checklist >}}
This is the [cost-of-goods layer]({{< relref "knowledge/unit-economics" >}}) that sits beneath the usual LTV and CAC—the line most agent models skip, because measuring it turns a clean story into a distribution with a tail.
{{< cta title="Modeling an agent economy?" text="We build the task-level P&L and the token test together—the loop multiplier, the COGS distribution, the billing model, and whether any token pattern actually captures the margin. Before you commit a design to a whitepaper." button="Get in touch" link="/quote/" >}}
## The takeaway
An AI agent is priced one task at a time, and the task is a loop, not a call—so its cost is the per-call price times a multiplier that runs from four to fifteen and spikes to thirty, denominated in dollars, with a fat tail that flat pricing ignores. Against that, the sellable price is low and the margin thin wherever the work is commoditizable, and falling model prices do not rescue it because capability spends the savings on longer loops. The token captures value only where it is load-bearing in that statement—as bonded reliability, mandated settlement, or paid access—and nowhere else. The x402 transaction counter will keep climbing. The number that decides whether any of it is a business is the one almost no one prints: the margin on one agent, doing one task, on an average Tuesday.
---
## Token Project Unit Economics: Metrics, Formulas, and Modeling
- URL: https://giantslabs.pro/knowledge/unit-economics/
- Section: knowledge
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How to calculate unit economics for a crypto project — LTV, CAC, revenue per token, velocity. Formulas, Python code, and common mistakes.
Tokenomics without unit economics is allocation percentages backed by no money. Unit economics answers the question: **how much does it cost to acquire one user, how much do they generate, and how does the token affect these numbers**. Without this calculation, any supply and demand models remain abstract.
## What Is Unit Economics in a Token Context
**Unit economics** is the profitability calculation per unit (user, transaction, subscription). In token projects, a second layer is added: beyond fiat revenue, there's the token economy — emission, incentives, and token sinks that affect P&L.
In traditional business the formula is simple: if LTV > CAC, the business scales. In a crypto project, LTV includes usage revenue **and** token impact (subsidies, emission, burns), while CAC can be paid in tokens (airdrop, referral programs, liquidity mining).
### Why Calculate Unit Economics
1. **Sustainability check** — does user acquisition pay for itself without infinite emission?
2. **Emission calibration** — how many tokens to spend on incentives without hyperinflation?
3. **Token valuation** — what is the fundamental token price at given usage metrics?
4. **Investor attraction** — investors fund metrics, not promises
### Why It's Harder in Web3
In classic SaaS, unit economics is linear: acquire a user → they pay a subscription → paid back in N months. In a token project, there's a nonlinear factor: **the token is essentially a liability** tied to utilization and market price.
This means token project unit economics **fundamentally cannot be precise**:
- **CAC depends on token price** — and price depends on demand, which depends on user count, which depends on CAC. Circular dependency
- **LTV depends on token utilization** — if users stop staking or the burn mechanism changes, token value and LTV change
- **Market price affects everything** — when token price rises, so does the "cost" of incentives (CAC) and the "value" of user contribution (LTV). These effects don't cancel out
{{< callout title="Unit economics as a compass, not a map" type="info" >}}
A token project can't calculate unit economics with SaaS precision. But it can determine **orders of magnitude and direction**: is LTV/CAC growing or declining? Does the economics converge across three price scenarios or not? That's exactly what investors and the team need.
{{< /callout >}}
## Key Metrics
### CAC — Customer Acquisition Cost
{{< formula math="CAC = (Marketing + Incentives × P) / Users" >}}
- CAC — customer acquisition cost
- Marketing — fiat marketing expenses ($)
- Incentives — tokens spent on acquisition (units)
- P — token market price
- Users — new users acquired in the period
{{< /formula >}}
In crypto projects, CAC often includes a token component: [airdrop]({{< relref "models/airdrop" >}}), referral rewards, liquidity mining. These costs are real — they create sell pressure.
**Critical point: CAC depends on P.** In the formula above, P is the current market price. This means CAC **is not a constant**: if the token price 5x's, incentive costs grow proportionally (if the number of tokens distributed is fixed). A project giving away 100K tokens/mo spends $50K at $0.50 and $500K at $5.00 — for the same users.
**Example.** A protocol spends $50K/mo on marketing and distributes 100,000 tokens per month. 2,000 new users acquired:
| P_token | Token cost | CAC | Comment |
|---------|-----------|-----|---------|
| $0.10 | $10K | $30 | Cheap to acquire |
| $0.50 | $50K | $50 | Acceptable |
| $2.00 | $200K | $125 | Expensive |
| $5.00 | $500K | $275 | Unprofitable |
This is why many projects switch from a fixed token count to a fixed dollar budget for incentives — to decouple CAC from market price.
{{< callout title="Token subsidies are real costs" type="warning" >}}
Distributing tokens is "free" only if the token is worthless. Every distributed token is sell pressure that dilutes value for all holders. Include token incentives in CAC at market price — and model at least three price scenarios.
{{< /callout >}}
### ARPU — Average Revenue Per User
{{< formula math="ARPU_mo = Revenue_mo / MAU" >}}
- ARPU_mo — average revenue per user per month
- Revenue_mo — protocol fiat revenue for the month
- MAU — monthly active users
{{< /formula >}}
In DeFi protocols, revenue comes from:
- Swap fees (DEX)
- Lending interest (lending)
- Bridge fees (cross-chain)
- Storage fees (decentralized storage)
- Subscriptions (premium features)
### LTV — Lifetime Value
{{< formula math="LTV = ARPU_mo × Lifetime_mo" >}}
- LTV — lifetime value of a user
- ARPU_mo — average revenue per user per month
- Lifetime_mo — average user lifespan in the protocol (months)
{{< /formula >}}
For subscription models: LTV = ARPU / ChurnRate. For transactional: LTV = ARPU × average active months. Note: these formulas assume zero discount rate. At the high discount rates typical for crypto (20–40%), real LTV is meaningfully lower — roughly 10–30% at typical churn (8–15%). For a more precise estimate: LTV = ARPU / (churn + r_monthly).
**Example.** ARPU = $5/mo, average user is active for 8 months:
LTV = $5 × 8 = **$40**
At CAC = $50, unit economics is **negative**: the project loses $10 per user.
### LTV/CAC — Payback Ratio
{{< formula math="LTV / CAC > 3 — healthy unit economics" >}}
- LTV / CAC < 1 — loss-making
- LTV / CAC 1–3 — risk zone
- LTV / CAC > 3 — scalable business
{{< /formula >}}
| LTV/CAC | Interpretation |
|---------|---------------|
| < 1.0 | Loss-making — each user costs more than they generate |
| 1.0–2.0 | Risky — works only with perfect retention |
| 2.0–3.0 | Acceptable — little margin for error |
| 3.0–5.0 | Healthy — standard for scaling |
| > 5.0 | Excellent — or underinvesting in growth |
### Velocity — Token Turnover Rate
{{< formula math="V = Volume / Mcap" >}}
- V — velocity (turnover rate)
- Volume — transaction volume for the period
- Mcap — token market capitalization
{{< /formula >}}
Velocity shows how fast tokens change hands. High velocity (> 10 for utility tokens) means users don't hold the token — they buy and immediately spend it. This suppresses fundamental price. For context: Bitcoin velocity is ~5–7, Ethereum ~3–5, while stablecoins can exceed 50.
{{< formula math="P_fund = PQ / (V × S)" >}}
- Fisher's equation of exchange
- P — price per unit of service
- Q — volume of services
- V — velocity
- S — circulating supply
{{< /formula >}}
**Example.** A protocol processes $100M/year in transactions (PQ), velocity = 20, circulating supply = 50M:
P_fund = $100M / (20 × 50M) = **$0.10 per token**
If velocity drops to 5 (via staking, lock-up, burn mechanisms):
P_fund = $100M / (5 × 50M) = **$0.40** — a 4x increase.
{{< callout title="Velocity — the price killer" type="info" >}}
Velocity reduction mechanisms (staking, lock-up, burn-on-use) are critically important for supporting price. Without them, the token becomes a transit medium — bought and immediately sold, creating no sustained demand. See the [token velocity]({{< relref "models/token-velocity" >}}) article for velocity sinks.
{{< /callout >}}
### DeFi-Specific Metrics
For DeFi protocols, standard unit economics metrics are supplemented by:
| Metric | Formula | What it shows |
|--------|---------|---------------|
| TVL per user | TVL / unique depositors | Average liquidity per participant |
| Revenue / TVL | Annual revenue / TVL | Capital efficiency — how well the protocol monetizes deposits |
| Cost per TVL | Incentive spend / TVL | Cost to attract $1 of liquidity |
| Payback period | CAC / ARPU_mo | Months to recoup acquisition cost |
These metrics are tracked by Token Terminal, DefiLlama, and Messari for benchmarking across protocols.
## Unit Economics with Token Layer
### Token-Subsidized Model
Most crypto projects at early stages subsidize users: give tokens for usage (liquidity mining, rewards, [airdrop]({{< relref "models/airdrop" >}})). This creates artificially high ARPU for users — and negative economics for the protocol.
{{< formula math="Net_revenue = Revenue − Subsidies × P" >}}
- Revenue — protocol fiat revenue
- Subsidies — tokens distributed (units)
- P — token market price
{{< /formula >}}
**Example.** A DEX generates $2M/mo in fees and distributes 500K tokens/mo at $3:
Net_revenue = $2M − 500K × $3 = **$500K** (profit)
If the token price rises to $5: Net_revenue = $2M − 500K × $5 = **−$500K** (loss)
### Break-Even Point
{{< formula math="Breakeven = Costs / (ARPU_mo − Subsidy_per_user)" >}}
- Breakeven — users needed to break even
- Costs — fixed protocol expenses (salaries, infrastructure, marketing excl. token subsidies)
- ARPU_mo — revenue per user per month
- Subsidy_per_user — variable token subsidy cost per user
{{< /formula >}}
### The Debt Repayment Model
Token subsidies at the early stage are "debt" to future holders. Every distributed token creates potential sell pressure. Healthy economics assumes:
1. Subsidies attract users (growth phase)
2. Users generate revenue (monetization phase)
3. Revenue covers pressure from selling distributed tokens (sustainability phase)
## Modeling Unit Economics
A 36-month simulation shows: with token price growing 2%/mo, incentive costs double by month 36, and CAC grows from $75 to $125+. Meanwhile LTV stays at $62.50 (depends on ARPU and churn, not token price). Result: LTV/CAC deteriorates even as MAU grows.
**Key insights:**
- Without fee revenue, break-even is not reached within 36 months
- With a fixed token distribution, price appreciation **worsens** unit economics
- Switching to a fixed dollar incentive budget stabilizes CAC
Python: unit economics simulation
```python
import numpy as np
import matplotlib.pyplot as plt
MONTHS = 36
MARKETING_SPEND = 50_000
TOKEN_INCENTIVES = 100_000
TOKEN_PRICE_0 = 1.0
NEW_USERS_MONTH = 2_000
CHURN_RATE = 0.08
ARPU = 5.0
PRICE_GROWTH = 0.02
months = np.arange(MONTHS)
active_users = np.zeros(MONTHS)
revenue = np.zeros(MONTHS)
token_cost = np.zeros(MONTHS)
net_revenue = np.zeros(MONTHS)
cumulative_pnl = np.zeros(MONTHS)
cac = np.zeros(MONTHS)
ltv = np.zeros(MONTHS)
for m in range(MONTHS):
token_price = TOKEN_PRICE_0 * (1 + PRICE_GROWTH) ** m
if m == 0:
active_users[m] = NEW_USERS_MONTH
else:
active_users[m] = active_users[m - 1] * (1 - CHURN_RATE) + NEW_USERS_MONTH
revenue[m] = active_users[m] * ARPU
token_cost[m] = TOKEN_INCENTIVES * token_price
total_cost = MARKETING_SPEND + token_cost[m]
net_revenue[m] = revenue[m] - total_cost
cumulative_pnl[m] = (cumulative_pnl[m - 1] if m > 0 else 0) + net_revenue[m]
cac[m] = total_cost / NEW_USERS_MONTH
ltv[m] = ARPU * (1 / CHURN_RATE)
fig, axes = plt.subplots(2, 2, figsize=(14, 10))
axes[0, 0].plot(months, active_users, color="#3b82f6", linewidth=2)
axes[0, 0].set_title("MAU"); axes[0, 0].grid(True, alpha=0.3)
axes[0, 1].plot(months, revenue / 1000, color="#10b981", linewidth=2, label="Revenue")
axes[0, 1].plot(months, (np.full(MONTHS, MARKETING_SPEND) + token_cost) / 1000,
color="#ef4444", linewidth=2, label="Expenses")
axes[0, 1].set_title("Revenue vs Expenses"); axes[0, 1].legend(); axes[0, 1].grid(True, alpha=0.3)
axes[1, 0].fill_between(months, cumulative_pnl / 1000, where=cumulative_pnl >= 0, alpha=0.3, color="#10b981")
axes[1, 0].fill_between(months, cumulative_pnl / 1000, where=cumulative_pnl < 0, alpha=0.3, color="#ef4444")
axes[1, 0].plot(months, cumulative_pnl / 1000, color="#1e293b", linewidth=2)
axes[1, 0].set_title("Cumulative P&L ($K)"); axes[1, 0].grid(True, alpha=0.3)
axes[1, 1].plot(months, ltv / cac, color="#8b5cf6", linewidth=2)
axes[1, 1].axhline(y=3.0, color="#10b981", linestyle="--", alpha=0.5, label="3x")
axes[1, 1].axhline(y=1.0, color="#ef4444", linestyle="--", alpha=0.5, label="1x")
axes[1, 1].set_title("LTV / CAC"); axes[1, 1].legend(); axes[1, 1].grid(True, alpha=0.3)
plt.tight_layout(); plt.show()
```
## Token Valuation via Unit Economics
### Discounted Cash Flow
{{< formula math="Price = [Σ(CF_t / (1 + r)^t) + TV / (1 + r)^n] / Circulating_supply" >}}
- Price — fundamental token price (DCF)
- CF_t — net cash flow in period t (t = 1..n, typically n = 5–10 years)
- r — discount rate (20–30% for established protocols, 30–40% for early-stage)
- TV — terminal value = CF_n × (1 + g) / (r − g), where g is long-term growth rate
- Circulating_supply — tokens in circulation (not total supply)
{{< /formula >}}
Terminal value often accounts for 60–80% of the total valuation. Omitting it leads to systematic undervaluation.
### Velocity Method
{{< formula math="P_token = PQ / (V × S)" >}}
- Fisher's equation of exchange
- P — price per unit of service
- Q — number of transactions
- V — velocity
- S — circulating supply
{{< /formula >}}
### Revenue Multiple (P/S) Method for Tokens
{{< formula math="P_token = (Annual_revenue × P/S) / S" >}}
- P_S — Price-to-Sales multiplier (5–15 for DeFi protocols, depends on growth stage)
- Annual_revenue — annual protocol revenue ($)
- S — circulating supply
{{< /formula >}}
Note: this is a **P/S (Price-to-Sales)** method, not P/E. For P/E, replace revenue with earnings (net income after expenses). P/S multiples for DeFi protocols typically range 5–15x; P/E multiples (when earnings are positive) range 10–30x.
**Example.** Protocol with $10M annual revenue, P/S = 10, circulating supply = 50M:
P_token = ($10M × 10) / 50M = **$2.00**
## Common Mistakes
### 1. Ignoring Token Subsidies in Expenses
"The airdrop costs nothing" — false. Every distributed token is sell pressure that dilutes value for holders. Always include token incentives in CAC at current market price.
### 2. LTV Without Accounting for Churn
LTV = ARPU × 100 months? Only if churn is 1%. At real churn of 8–15%, average user lifespan is 7–13 months (1/0.15 ≈ 6.7, 1/0.08 = 12.5). Inflated LTV masks unprofitability.
### 3. ARPU Based on Active Users Without Bot Filtering
In crypto projects, 30–70% of "users" are bots, farmers, and duplicate addresses. ARPU for "real" users can be 3–5x lower than reported.
### 4. Model Without Token Price Scenarios
If token price 5x's, incentive costs grow proportionally (when incentives are a fixed token count). Model three scenarios: current price, 3x growth, 3x decline.
### 5. Treasury Token Sales as "Revenue"
Selling tokens from the treasury is not revenue — it's fundraising. Real revenue is fees from protocol usage.
{{< checklist title="Token project unit economics checklist" type="check" >}}
CAC calculated with token subsidies — fiat + tokens at market price
LTV calculated with real churn — not optimistic 100 months, but measured data
LTV/CAC > 3 — or a plan to reach this level
Token velocity assessed — and mechanisms to reduce it exist
Break-even point defined — at what MAU the protocol becomes profitable
Three token price scenarios modeled — base, growth, decline
Fee revenue separated from token sales — they're different things
Bots filtered from MAU — real users, not wallets
{{< /checklist >}}
{{< cta title="Need unit economics for your token project?" text="We've calculated unit economics for 85+ projects — from DeFi to GameFi. We'll verify your model's sustainability and find the break-even point." button="Get in touch" link="/quote/" >}}
---
## Tokenized Agri Debt: Why "5–7% in Dollars" Is a Myth
- URL: https://giantslabs.pro/knowledge/agri-debt-yield/
- Section: knowledge
- Date: 2026-07-03
- Last modified: 2026-07-03
- Description: Required yield on tokenized farm debt, built layer by layer from July 2026 anchors: senior USD exposure prices near 12%, and the 5–7% pitch is hedge arithmetic.
Every tokenized-agriculture pitch deck reaches the same slide sooner or later: emerging-market farm loans paying investors "a safe 5–7% in dollars." We rebuilt that number from first principles against July 2026 market anchors, for a concrete reference case—senior exposure to warehouse-collateralized Brazilian soybean loans, 180-day tenor, a 70% advance rate (the loan is 70% of the collateral's value), distributed to on-chain USDC investors. The defensible answer came out at **about 12.25%, with a corridor of 11.0–13.5%**.
The six-point gap has a simple explanation: the 5–7% slide is quoting currency arithmetic, while the investor is being asked to carry credit risk. This article walks the honest build-up layer by layer—and ships a [calculator]({{< relref "tools/calc-agri-yield" >}}) so you can rerun it with your own assumptions.
## Where "5–7% in dollars" comes from
Start with the two rates that anchor everything. SOFR, the USD risk-free base, stood at 3.68% at the end of June 2026. CDI, Brazil's interbank benchmark, stood near 14.15%. Under covered interest parity, the cost of fully hedging BRL into USD for a year is approximately the difference:
{{< formula math="h_FX ≈ CDI − SOFR = 14.15% − 3.68% ≈ 10.5% per year" >}}
- h_FX — implied cost of a full BRL→USD hedge, 12-month horizon
- The hedge consumes almost the entire spread between Brazilian and US money rates—that is what covered interest parity means
{{< /formula >}}
Now take a high-grade Brazilian agri certificate yielding, say, 15.5% in BRL (an illustrative level) and hedge it fully into dollars: 15.5% minus 10.5% leaves roughly 5%. That is the entire origin of the "safe 5–7% USD" figure. It is real arithmetic—and it describes a fully hedged, high-grade instrument whose Brazilian risk premium has been handed over, almost in full, to the FX hedge counterparty. An investor earning it holds something close to SOFR plus a sliver, wrapped in an exotic asset story.
The moment the offer is unhedged (as USD-native, USDC-settled structures typically are) or the credit is anything below high-grade (as single-name farm loans are), that arithmetic stops applying, and the yield has to be rebuilt from the bottom.
| Macro anchor (as of) | Value |
|---|---|
| SOFR overnight (Jun 30, 2026) | 3.68% |
| Selic target (Copom, Jun 17, 2026) | 14.25% |
| CDI (Jul 1, 2026) | ~14.15% |
| Brazil 5Y sovereign CDS (early Jun 2026—the one stale anchor) | ~123 bps |
| Implied 12-mo full-hedge cost (CDI − SOFR) | ~10.5%/yr |
| Tokenized T-bill funds, 7-day APY | 3.15–3.55% |
| Aave USDC supply rate (utilization-dependent) | ~3–7% |
## The honest build-up
For the reference case—an unrated mid-tier cooperative or crusher as borrower, secured by warehouse receipts with a collateral manager, 70% advance rate, no insurance, no FX hedge—the required yield stacks up over SOFR in six layers:
| Layer | bps | Why it exists |
|---|---|---|
| Base rate (SOFR) | 368 | The price of dollars, June 30, 2026 |
| Credit / counterparty | 300 | Unrated single name; the layer is unexpected-loss premium, since actuarial expected loss on trade-collateralized lending runs single-digit bps |
| Collateral / warehouse | 125 | Warehouse-fraud tail risk, residual after the 70% advance and the collateral manager |
| Basis + convertibility | 75 | Local-vs-CBOT price basis and transfer risk; the sovereign credit-default-swap spread (~123 bps) informs it |
| Liquidity / lockup | 110 | 90-day-plus lockups typical of on-chain private-credit pools |
| Platform / structural | 100 | Servicer, securitization vehicle, oracle, smart contract |
| Tokenization overlay | 175 | Small-issue novelty, lockup design, crypto-native demand—estimated from matched pairs (see below) |
The raw sum is 12.53%; our adjudication rounds that to a communicable **central estimate of 12.25%** (a 12.0–12.3% band). One honest disclosure about the stack: its most aggressive judgment is folding sovereign risk into the basis layer—a conservative reading adds another 50–100 bps on top. Structure changes move the number in predictable ways: adding credit insurance or a development-finance participation removes part of the credit layer net of its cost, worth 100–200 bps (central ~11%, corridor 10.5–11.5%—an insured single name cannot price below the live insured-pool print at 11%); taking the junior/mezzanine position below a 25–30% subordination (the slice that absorbs losses before the senior tranche is touched) adds about 800 bps over senior (central ~20%, corridor 18–24%).
{{< callout title="Run your own assumptions" type="info" >}}
The [Agri Debt Yield Calculator]({{< relref "tools/calc-agri-yield" >}}) implements this build-up with sliders for every layer, the three structure variants, and the FX-hedge arithmetic. The defaults reproduce the reference case; the interesting exercise is seeing how many sliders you must drag to zero before a 6% offer prices fairly.
{{< /callout >}}
## Why the collateral doesn't make it "safe"
The strongest argument in every pitch is the warehouse receipt: real grain, real custody, senior claim. The coverage math is good—at a 70% advance rate the loan starts with 1.43× collateral coverage, and it is impaired only if collateral value falls more than 30%, net of liquidation costs, within a 180-day tenor:
{{< formula math="C₀ = 1/AR ≈ 1.43×; ΔP* = −(1 − AR) = −30%" >}}
- AR — advance rate (70% in the reference case)
- C₀ — initial coverage; ΔP* — break-even collateral drawdown over the tenor
- Observed local price-basis swings of 2–6% sit far inside the 30% buffer
{{< /formula >}}
So why do the collateral and basis layers still price at 200 bps combined? Because the risks that remain are the ones the buffer does not absorb: warehouse fraud (a real, documented tail in Brazil), the gap between paper inventory and physical inventory, and the possibility that a court freezes enforcement inside a judicial recovery. Collateral compresses the spread; it does not delete it. That is also the fair reading of the credit layer's 300 bps: expected loss on this kind of lending is tiny, and nearly all of the premium is compensation for concentration and the absence of a rating, a track record, or an exit.
## The market agrees, once you read it correctly
A useful discipline for any yield slide: put it next to what USD investors are already paid for adjacent risk, and never let a BRL print into the comparison.
| USD / USDC benchmark | Yield |
|---|---|
| Tokenized T-bill funds | 3.15–3.55% |
| Amaggi 2028 corporate bond (BB, unsecured, priced 2021) | 5.25% |
| Global trade-finance fund (ECA-covered mix ~94%, net, 1y/3y) | 7.5–8.0% |
| Diversified on-chain private-credit pools (net targets) | 9–12% |
| Verified senior tokenized private-credit tranche (LatAm, diversified, hedged) | 10.13% expected |
| Insured tokenized receivables pool (Colombia, export-credit insured, net) | 11% |
| Mezzanine/first-loss tranches, worked example | 22.5–40.5% |
Two readings follow. First, a 6% offer on unrated, single-name, unhedged farm credit would pay you less than a diversified global trade-finance fund with export-credit-agency cover—and barely more than a 2021-vintage unsecured corporate bond from one of the sector's strongest names. Second, in Brazil's domestic market senior receivables-fund quotas print 15.8% and listed agri funds distribute 16.9–17.8% trailing—all in BRL; those numbers belong to the CDI world and must never be blended into a USD expectation, because the currency is where that spread lives.
## Tokenization is not a discount machine (yet)
The 175 bps overlay is the contested layer, because it runs against the sales narrative. Does putting the instrument on-chain lower the required yield? The matched pairs say no. Tokenized Treasury funds price at roughly a 30 bps *discount* to SOFR—evidence that a token wrapper by itself neither adds nor removes yield. On-chain wrappers of existing credit funds pass through 9–12% net, roughly what the underlying funds pay off-chain. What the market does charge for is everything that comes with today's tokenized distribution: lockups, small issue sizes, novelty, and a crypto-native investor base with a high opportunity cost—our estimate, +175 bps, derived from those matched pairs.
This is consistent with what we argued in [the stack article]({{< relref "knowledge/agri-finance-stack" >}}): tokenization can compress the operational costs inside the origination stack (1.5–2.5 points of fees and spread), and that saving is real for the *borrower*. On the *investor* side, at the current stage of the market, tokenized distribution adds a premium rather than subtracting one. Both things are true, and confusing them is how "blockchain efficiency" ends up justifying an underpriced coupon.
## Six questions for any yield slide
{{< checklist title="Reading a tokenized-agri yield pitch" type="check" >}}
Hedged or unhedged? If the structure is USD-native and unhedged, the CDI−SOFR arithmetic is irrelevant and the yield must be built from credit up. If hedged, ask what is left after ~10.5%/yr of hedge cost—and why you are not just buying T-bills.
Which tranche? Senior, mezzanine, and first-loss on the same pool can fairly price 10%, 22%, and 40%. A single blended number hides where you sit.
Insured by whom? Credit insurance moves the requirement by 100–200 bps net—but only if the insurer, the coverage share, and the subrogation path (who steps into the lender's claim after a payout) are named.
What is the lockup? 90-day-plus lockups are standard and worth ~110 bps. Instant-liquidity promises against 180-day loans should worry you more than a lockup does.
What is the spread over tokenized T-bills? That is the risk-free alternative in the same wallet. Under 300 bps of spread for single-name EM farm credit answers the question for you.
Is the comparison in the right currency? Brazilian domestic prints of 16–18% are BRL numbers. Any deck that quotes them next to a USD offer is borrowing a spread that belongs to the currency.
{{< /checklist >}}
{{< cta title="Pricing an RWA credit structure?" text="We build yield adjudications like this one for specific deals—layer by layer, anchored to dated market evidence, with the tranche and insurance variants worked out. Useful before you commit a coupon to a term sheet." button="Get in touch" link="/quote/" >}}
## The takeaway
The honest required yield for senior, uninsured, USD-native exposure to tokenized Brazilian farm credit is about 12.25% today—roughly 11–13.5% depending on structure—with insurance buying it down toward 11% and junior/mezzanine positions pricing near 20%. The "5–7% in dollars" figure is what remains of a high-grade BRL instrument after a full FX hedge: legitimate arithmetic, wrong instrument, and a five-to-seven-point transfer from investor to issuer when it is used to price unhedged single-name credit. The number to hold onto is the spread: nine points over tokenized T-bills is what this risk pays when every layer is counted. The final article in this series walks a default through the enforcement stack—which claims came through Brazil's biggest agri insolvency, and at what recovery.
---
## Tokenized Equity: Six Instruments, Six Payoffs
- URL: https://giantslabs.pro/knowledge/tokenized-equity-instruments/
- Section: knowledge
- Date: 2026-06-26
- Last modified: 2026-06-26
- Description: 'Tokenized equity' is six different instruments, and only two track the stock 1:1. A field guide to each—payoff shape, trade-offs, and real examples.
"Tokenized equity" sounds like one thing. It is at least six. The phrase gets stamped on a registered on-chain share, on a certificate that merely tracks a share's price, on a right to buy shares that do not exist yet, and on a token that pays you a slice of revenue and never touches ownership at all. Same two words, four legally and economically different instruments—and two more besides.
Only two of the six actually move one-to-one with the underlying share. The other four are options, debt, or pure cash-flow claims wearing the equity label. Confuse them and you mis-price two things at once: the **risk** (what can go to zero, and against whom you have a claim) and the **payoff** (linear, convex, or decoupled from the stock entirely).
This is a field guide to all six. For each: what you actually own, the shape of its payoff against the share price, the main trade-off, and where it shows up in the wild.
## Three families under one label
{{< callout title="The frame" type="info" >}}
The six instruments fall into three families. **Existing-equity** wrappers give you delta-1 exposure to shares that already exist. **Future-right** contracts give you an option-like claim that only becomes equity later, if at all. **Cash-flow** claims give you a stream and no ownership. The single most common error in this market is treating all three as if they were the same "stock token."
{{< /callout >}}
| Instrument | Family | What you own | Payoff vs. the stock |
|---|---|---|---|
| Direct tokenized share | Existing equity | A beneficial claim on a real share | Linear, 1:1 |
| SPV-wrapped share token | Existing equity | An interest or tracker note in a vehicle that holds shares | Linear 1:1, plus a credit layer |
| Tokenized SAFE / SAFT | Future right | A right to future equity (SAFE) or future tokens (SAFT) | Contingent, option-like |
| Tokenized warrant | Future right | The right to buy shares at a strike | Convex (hockey-stick) |
| Convertible-note token | Future right | Debt that converts to equity | Bond floor plus equity upside |
| Revenue / royalty token | Cash-flow claim | A share of revenue or fees, no ownership | Tracks cash flow, not equity |
{{< schema "comparison/tokenized-equity-payoff-shapes" >}}
The rest of this guide walks the families in order, from the instruments that behave most like a share to the ones that behave least like one.
## Family 1—existing equity (linear, delta-1)
These are the only two instruments that earn the name. Each is backed by a real share, so its value rises and falls with the stock in a straight line. The difference between them is *whose balance sheet your claim sits on*.
### Direct tokenized share
The token is the on-chain record of a real share, with a beneficial claim that flows through to the holder. Dividends, and sometimes voting, can pass through. This is delta-1 exposure: the token price tracks the share price, minus tracking error and liquidity spread.
- **Pro**—the cleanest mirror of the equity; dividend and voting rights can pass through.
- **Con**—the heaviest compliance load. A regulated custodian and transfer agent must hold and record one real share behind every token.
**In the wild.** Registered, on-chain securities run through a regulated transfer-agent model—Securitize is the leading example, operating as both an SEC-registered transfer agent and broker-dealer. The high bar for "the token *is* the share" is set by venues like the Nasdaq tokenized-equity pilot, where a tokenized version must be fungible with, and share the same CUSIP and trading symbol as, the traditional share. Anything short of that is not a direct share—it is the next instrument.
### SPV-wrapped share token
Far more common in practice. Shares are placed inside a bankruptcy-remote special-purpose vehicle (SPV), and the token represents an interest in that SPV—or, in several flagship products, a "tracker certificate" that is legally a debt instrument referencing the share. Economically it is still 1:1 with the stock. Legally, your claim runs to the vehicle, not to the company's cap table, and a credit layer (SPV and issuer solvency) now sits between you and the equity.
- **Pro**—ring-fenced and prospectus-friendly; one SPV can pool many holders cleanly.
- **Con**—you are one or two steps removed from the share. No direct cap-table rights, voting usually does not pass through, and tracker-certificate versions are credit instruments, so an issuer default is a credit event.
**In the wild.** Tokenized public-stock products such as Backed's xStocks (tracker certificates) and pre-IPO SPV products such as Jarsy (1:1 shares held in an SPV, with a low minimum). Buyers should note that these holders do not own the underlying shares directly—rights run through the vehicle, ideally with an independently verifiable proof-of-reserves.
{{< callout title="Watch-out: synthetic is not ownership, and consent is not optional" type="warning" >}}
A third variant—purely synthetic price exposure with no shares held at all (oracle-priced notes and perpetuals)—is not equity in any sense; it is a bet on a price. And third-party wrappers built without the issuer's cooperation carry claim-ambiguity risk: in mid-2025, after a brokerage launched tokenized exposure to a major AI lab's shares, the lab publicly disowned it, stating the tokens were not equity and there was no partnership. If no one signed off on the cap table, ask what your token is actually a claim on.
{{< /callout >}}
## Family 2—future rights (option-like and contingent)
Here the token is not backed by a share today. It is a contract that *might* become equity later. The payoffs stop being linear and start bending.
### Tokenized SAFE / SAFT
A SAFE (Simple Agreement for Future Equity) is a right to receive equity at a later priced round, usually with a valuation cap or discount. A SAFT (Simple Agreement for Future Tokens) is the same idea for tokens, not shares—and the two are not interchangeable. Tokenizing the contract makes the future-right itself transferable before it converts.
- **Pro**—cheap, fast, standardized funding that defers the hard valuation question.
- **Con**—no exposure until it converts, and if the triggering event never happens it can be worth nothing. A SAFE is equity-contingent; a SAFT is token-contingent. Do not merge them.
**In the wild.** The SAFE is Y Combinator's standard instrument; the SAFT framework was popularized in 2017 and used in raises such as Filecoin's.
### Tokenized warrant
The right—not the obligation—to buy shares at a fixed strike, often only after the price clears a trigger. This is the convex, leveraged instrument: worthless below the strike, then rising with the stock above it. Per warrant, the intrinsic payoff is simply:
{{< formula math="Payoff = max(0, S − Strike)" >}}
- S—the underlying share price at exercise
- Strike—the fixed exercise price set in the contract
- The right activates only above an exercise trigger, and the upside is sometimes capped
{{< /formula >}}
The leverage cuts both ways. A small premium controls upside on the full covered amount, but the warrant can expire at zero, and exercising it mints new shares—so it is dilutive to existing holders. Exercise mechanics matter: a **cash (physical)** exercise means paying the strike in cash and bringing capital into the company; a **cashless** exercise nets the cost out in shares, so the holder pays almost nothing but the company raises almost nothing.
- **Pro**—cheap, leveraged upside; a right, not a duty.
- **Con**—dead weight below the strike; dilutive on exercise; needs active, well-timed exercise.
**In the wild.** Token warrants are standard alongside equity in crypto VC rounds (equity now, a token kicker later). The closest public-market cousin is the SPAC warrant, often redeemable for a nominal $0.01 once the stock clears a threshold—a mechanic that effectively forces exercise.
### Convertible-note token
Debt that converts into equity at the next round, typically at a valuation cap or a discount. The payoff is hybrid: a debt-like floor on the downside (a repayment claim, subject to solvency) and equity-like upside once it converts.
- **Pro**—a downside cushion plus equity upside; senior to equity in a wind-down.
- **Con**—it is real debt, with maturity and repayment obligations; more legal complexity than a SAFE; dilution on conversion.
**In the wild.** The startup convertible note, put on-chain—the same instrument founders have used for years, now transferable as a token.
## Family 3—cash-flow claims (decoupled from equity)
### Revenue / royalty token
A contractual cut of revenue, fees, or royalties. This is not equity at all: no ownership, no voting, no claim on enterprise value or exit proceeds. Its value is the present value of an expected stream, so it tracks *revenue*, not the share price—flat against the stock and shaped more like an annuity. If a return cap applies, the payoff flattens once the cap is hit. Valuing it is a discounted-cash-flow problem, not an equity-comparables one—see [DCF valuation for tokens]({{< relref "dcf-token-valuation" >}}).
- **Pro**—pays cash flow from day one, no exit required; non-dilutive to founders' equity.
- **Con**—no upside on valuation or an acquisition; depends entirely on revenue materializing; capped versions forfeit the tail.
**In the wild.** Music and IP-royalty tokens, and DeFi fee-share ("real yield") tokens that route a slice of protocol fees to holders.
## How to tell which one you are holding
The label on the listing rarely tells you. Five questions do.
{{< checklist title="Five questions before you call it 'equity'" type="check" >}}
Is a real share held for you? If yes, you are in Family 1. If not, you hold a contract or a cash-flow claim, not a share.
Whose balance sheet is your claim against? The company, an SPV, or no one (a synthetic price feed). Each is a different risk.
Is the payoff linear, or does it need a trigger or a conversion? Linear means delta-1; a kink or a step means an option, a warrant, or a convertible.
Do you own value, or a stream? Royalty tokens decouple from the stock entirely—they are not a bet on the company's worth.
Could the issuer disown it tomorrow? If the cap table never consented, your "equity" may be a claim only against a wrapper.
{{< /checklist >}}
One structural point ties the families together. A wrapped instrument almost never beats holding the share outright. Platform fees, an acquisition premium baked into the wrapper, and the cost of exercising an embedded warrant all leak value. The token's total economic exposure usually sits *below* one share. Closing that gap takes real economics—extra warrant coverage, a smaller fee, or a larger reserve—not a better label. Before you decide a token even belongs in the structure, the prior question is whether the asset needs one at all: see [when you don't need a token]({{< relref "when-token-not-needed" >}}).
{{< cta title="Structuring a tokenized-equity instrument?" text="We design the economic and structural framework—payoff shape, custody and verification, distribution, and the regulatory matrix—that legal counsel can implement without rewriting from scratch. 40+ tokenomics and tokenization projects." button="Get in touch" link="/quote/" >}}
## The takeaway
"Tokenized equity" is a category, not an instrument. Inside it sit at least six distinct claims with three different payoff shapes and three different counterparties. The first job of anyone buying, structuring, or modelling one is to drop the label and name the instrument: existing-equity wrapper, future right, or cash-flow claim. Price the risk against *that*, not against the word on the listing. For a worked example of an equity wrapper at the institutional end of the spectrum—a protocol crossing onto public markets—see [from protocol to public equity]({{< relref "ethena-stablecoinx-public-equity" >}}).
---
## Tokenized Memory: Can AI Memory Become an Asset Class?
- URL: https://giantslabs.pro/knowledge/tokenized-memory/
- Section: knowledge
- Date: 2026-06-22
- Last modified: 2026-06-22
- Description: 'Tokenizing AI memory' conflates three things. A tokenomics look at memory as an asset — copyability, valuation, privacy — and whether it needs its own token.
This article was prompted by a [post from Seb (@sebbsssss)](https://x.com/sebbsssss/status/2054582688024314109) announcing the Portable Memory Protocol (PMP) — "the open standard for AI memory: portable, private, personal." The framing is sharp: the most valuable standard in AI, Seb argues, is still unclaimed. Context already has one (Anthropic's MCP). Agents have theirs (Google's A2A, Coinbase's x402 for payments). Memory — the layer that, in his words, "compounds with use" — does not. So the race is on to tokenize it.
It's a good provocation, and a good excuse to do what a tokenomics lab should do with any "tokenize X" pitch: ask what the phrase actually means, and which of its hard problems a token solves versus which it just papers over. This is not a review of PMP — it launches in weeks and there's nothing to test yet. It's an analysis of the idea underneath it: **tokenized memory as an asset class.**
{{< callout title="The claim on the table" type="info" >}}
A tokenized unit of memory, the pitch goes, carries an owner, provenance, access rights, a price, expiry rules, and a usage history — portable across chains the way stablecoins made the dollar portable. We'll take each property seriously, then ask the only question that matters: what is the unit of value, who can copy it, and does coordinating it require a token at all.
{{< /callout >}}
## "Tokenizing memory" is three different things
The first job is disambiguation, because the phrase quietly bundles three separate assets with three separate economics:
1. **The memory data itself** — embeddings, conversation history, learned preferences, the context that makes an assistant feel like your own. Tokenizing this means wrapping a data asset in transferable rights. This is a data-ownership and IP problem.
2. **Access and usage rights** to that data — who may read or write it, at what price, for how long. Tokenizing this is licensing expressed on-chain. This is a DRM and contracts problem.
3. **A network token for the protocol** — the implied "memory standard" coin that coordinates and monetizes the marketplace. This is the classic does-this-protocol-need-its-own-token problem.
Most pitches blur the three into one slide. They are not one thing. You can solve (1) and (2) — title and licensing — without ever issuing (3). Keeping them apart is most of the analytical work, so the rest of this piece walks the property list and sorts each item into the bucket where its real difficulty lives.
## Walking the property list
**Owner.** An NFT or registry entry can record title cleanly — this part is solved. But title to *what*? The data itself can't live on-chain: it's too large and, if it's personal memory, must stay private. So the chain holds a pointer (a hash, a key reference) and the bytes sit off-chain. You own a claim, not the content — the same on-chain-title-versus-off-chain-asset gap that every real-world-asset token has never fully closed.
**Provenance.** Cryptographic signing and attestation make this genuinely useful, maybe the most useful property on the list. Where did a preference come from — a real interaction, or an injected instruction? For agents acting on your behalf, verifiable provenance of memory is closer to a security primitive than a financial one.
**Access rights.** Encryption plus key management can gate who decrypts. The catch is fatal and specific: **to be useful, memory has to be read by a model — and the moment it is decrypted and ingested, it can be copied.** A license can say "read once"; the model's weights have already absorbed it. This is the same "no trustless link between the token and behavior" problem we flagged for [AI agent tokens]({{< relref "knowledge/ai-agents-tokenomics" >}}), one layer deeper: with memory, the thing being sold is information, and information doesn't stay sold.
**Price.** Pricing an information good runs straight into Arrow's information paradox: you can't judge what a memory is worth until you've seen it, and once you've seen it you no longer need to buy it. Markets for information goods route around this with reputation, bundling, and subscriptions — not per-unit spot prices. So "every memory unit has a price" is the hard part of the design, not an afterthought the token handles for you. (For the broader question of how AI and crypto try to price a "unit of work" at all, see [Units of Work]({{< relref "knowledge/units-of-work-pow-to-awu" >}}).)
**Expiry rules.** Time-decay is interesting for two reasons. As a mechanism, it's a [velocity sink]({{< relref "models/token-velocity" >}}) — it forces re-acquisition and gives the unit of account something to do. As an idea, it quietly contradicts the headline: memory that expires does not compound with use. You can have decay or compounding; selling both in the same sentence is a tell.
**Usage history.** An on-chain log of reads enables the one model that genuinely fits: streaming royalties. The owner earns each time the memory is used, rather than once at sale.
{{< formula math="Earnings_owner = Uses × Price_per_use × Royalty_share" >}}
- Uses — number of times the memory unit is read by a model over the period (from the on-chain log)
- Price_per_use — fee charged per read, USD
- Royalty_share — fraction of each fee routed to the memory owner (0 ≤ Royalty_share ≤ 1; e.g., 0.30 for 30%)
- Earnings_owner — owner income over the period, USD (computed)
{{< /formula >}}
The formula is trivial. Its only hard input is `Uses` — and `Uses` is honest only if a read can't become an unmetered internalization. That sends us right back to the access-rights problem: the royalty model is sound exactly to the degree that copying is preventable, which for ingested information is barely.
## The three problems a memory token can't dodge
Strip away the property list and three structural problems remain. They are the reason this is hard, and a serious design has to answer all three on the first page, not the last.
### 1. Non-rivalry and the copy problem
Memory is information. Information is non-rival — your use of it doesn't diminish mine — and, once revealed, costlessly copyable. Tokenizing a non-rival good means you are selling *licenses*, not the asset, and license enforcement over data a model has already consumed is close to impossible. Every durable information market solves this not with better cryptography but with a different value source: provenance, freshness, reputation, exclusivity of relationship. A memory protocol that prices the bytes will leak; one that prices *trusted, attested, continuously-updated* access has something to sell.
### 2. Portable versus valuable
The pitch's two best words are in tension. "Memory compounds with use" is true — but it compounds for *whoever aggregates it*. That's a data network effect, and it accrues to the holder, not to a unit floating in a permissionless market. Make memory fully portable and forkable and the moat evaporates; lock it down enough to capture value and it's no longer portable. The interesting design question is where on that spectrum a protocol sits, and "both ends at once" is not an answer.
### 3. Personal memory is PII
Tokenizing personal memory collides with data-protection law head-on. The GDPR right to erasure expects data to be deletable; a blockchain pointer is built not to forget. "Expiry rules" gesture at this, but an immutable on-chain record of *who accessed what memory when* is itself sensitive data, and a liability, not a feature. Any serious version of this lives or dies on a privacy architecture — encryption, zero-knowledge proofs, off-chain storage with on-chain commitments — long before it gets to a token.
## So does it need a token?
This is where a tokenomics lab earns its keep. Run the protocol through the standard filter ([When You Don't Need a Token]({{< relref "knowledge/when-token-not-needed" >}})) and the answer is "only under one condition."
A memory marketplace can settle in stablecoins, record title in NFTs, and gate access with encryption and a reputation registry. None of that needs a native L1-style coin. A native token earns its place **only if there is a coordination problem that fiat and NFTs can't solve** — for instance, a permissionless network of independent nodes storing, attesting, and serving memory, which needs crypto-economic incentives and slashing to stay honest. That is a real use case, and it has a name: it's [DePIN]({{< relref "models/depin-tokenomics" >}}). If the memory layer is actually a decentralized storage-and-attestation network, a token is justified by the same logic that justifies one for Filecoin or Arweave. If it's a centralized service with a marketplace UI, the token is the [AI-agent failure mode]({{< relref "knowledge/ai-agents-tokenomics" >}}) all over again: narrative wrapped around someone else's servers.
{{< callout title="The honest read on the pitch" type="default" >}}
The strongest detail in Seb's framing is the least glamorous one: enterprise "Know Your Agent" contracts as the first revenue line. Real cash flow before a token is the right order of operations — the same conclusion we keep reaching for AI agents. It's entirely possible that a memory protocol is a real business **and** doesn't need its own token. Those two facts don't conflict. The omnichain detail (Solana and Base, no bridges) is distribution, not design — broader rails say nothing about whether value accrues to a unit.
{{< /callout >}}
## When tokenized memory makes economic sense
Five questions, in the spirit of the lab's other checklists. If most answers are "no," you have a data marketplace with a token bolted on — not a memory asset.
{{< checklist title="The memory-token filter" type="check" >}}
- **Is the memory excludable in use?** Can you actually prevent unlicensed reuse after a model ingests it? If not, you're selling provenance and reputation, not the bytes — and you should price it that way.
- **Can its value be judged without consuming it?** Provenance, attestation, and track record are the only escape from a lemons market for information.
- **Is there a coordination problem a token solves that stablecoins, NFTs, and encryption don't?** If no, you have a marketplace, not a token.
- **Who carries the privacy and legal load?** Personal memory is PII. Erasure rights versus immutability is a real conflict, not a footnote.
- **Does the unit capture recurring value or just the first sale?** Usage-history royalties recur; a one-time sale of a copyable good races to zero.
{{< /checklist >}}
A project that answers all five honestly is rare. Most "tokenize memory" pitches will answer the first as "not really," the third as "not yet," and hope the narrative carries the rest — exactly the pattern that turned the AI-agent category into memecoins with extra steps.
## Takeaways
1. **"Tokenizing memory" is three things** — the data, the access rights, and a protocol token. Separating them dissolves most of the hype.
2. **The token is the easy part.** The hard parts are non-rivalry (information doesn't stay sold), the valuation paradox (you can't price what you must reveal to value), and privacy law (personal memory is PII on an immutable ledger).
3. **"Portable" and "valuable" pull against each other.** Memory compounds for whoever aggregates it; full portability erases the moat.
4. **A memory protocol can be a real business and still not need a token.** Cash flow first — KYA enterprise contracts — is the right instinct. A native token is justified only if the layer is genuinely a decentralized network (DePIN), not a marketplace with a coin attached.
5. **The right question isn't "is memory the last unclaimed standard."** It's: what is the unit of value, who can copy it, and does coordinating it actually require a token.
{{< cta title="Designing a token around data, AI agents, or memory?" text="We pressure-test the economics before the narrative — value capture, sinks, and whether a token is needed at all. 85+ projects across DeFi, infrastructure, and AI." button="Get in touch" link="/quote/" >}}
---
## Tokenomics Audit: An Open Methodology
- URL: https://giantslabs.pro/knowledge/tokenomics-audit-methodology/
- Section: knowledge
- Date: 2026-07-27
- Last modified: 2026-07-27
- Description: A reproducible economic-design audit: six review tracks, ~30 pass/fail checks, a severity ladder, and a worked pre-mortem—not an opaque letter grade.
In crypto, "audit" almost always means one of two things, and neither is what a team needs before a launch. It means a smart-contract security review—reentrancy, overflow, access control—which says nothing about whether the economic design holds. Or it means a paid rating: a letter grade from AAA to D, a hexagon score, a "BB," published without the checks that produced them—hard to reproduce and effectively impossible to contest.
A tokenomics audit is a third thing: an independent review of the economic design—the claims, the math, the market context, the on-chain reality, the mechanism, and the inputs underneath all of it. A protocol can pass a flawless code audit and still ship a fatal design flaw, because the two audits answer different questions. This article is the method we run, published in full: the six review tracks, the concrete pass/fail checks inside each, the severity ladder that ranks what they find, and a worked pre-mortem on a token that failed exactly these checks in public. None of it is framing you have to take on faith. You can run it yourself.
## What it is not
A security audit reads the contract; a tokenomics audit reads the economy the contract enforces. OpenZeppelin, Hacken, and Trail of Bits will tell you whether the mint function can be called by the wrong address. They will not tell you whether the mint *schedule* inflates the token to zero, whether the only people with a reason to buy are the people already selling, or whether the "stable" asset is collateralized by its own demand. Those are design questions, and a clean code report is silent on every one of them. A serious launch needs both audits; confusing them is how a project ships an exploit-free contract around an economy that was never going to work. Where code and operations fail instead of design—compromised keys, malicious verifiers, blind-signed multisigs—is its own catalog, covered in [our taxonomy of 2026's hacks]({{< relref "knowledge/defi-hacks-2026" >}}).
## The six tracks
The method runs six tracks. Four are analytical passes over the material—claims, market, math, on-chain—and two, mechanism integrity and inputs, are lenses applied across those four. Every finding on every track is bound to a specific piece of evidence: a quoted sentence from the whitepaper, a cell in the model, a transaction on-chain, or a market reference with a capture date. A finding that cannot name its evidence is an opinion, and opinions do not go in the report.
### Track 1: Claims and narrative
Pull every quantitative and mechanical claim from the whitepaper, deck, and public channels, then verify each against a primary source and against the model or contract that supposedly implements it. This is where the gap between what a project says and what it built shows up first.
| Check | Fails when | Typical severity |
|---|---|---|
| Every named-protocol fact is verifiable at a primary source and not contradicted by it | A claim is contradicted by its source or cannot be located | Critical |
| Every statistic, quote, and citation traces to its named origin | A number or attributed quote cannot be located at the source | Critical |
| Public "no X" promises survive contact with the mechanism | The design implements the opposite of what it promises | Critical / High |
| The document agrees with itself | Two numbers or two names for the same thing conflict | High |
| A stated, reachable reason to acquire and hold exists | The target buyer gets no yield, no utility, and no scarcity | Critical |
### Track 2: Market context
Every external number—market size, competitor benchmark, a rival's mechanic, a regulatory status—is verified against current data with a snapshot date. Markets move faster than whitepapers, and a comparison that was true at drafting is often false at launch.
| Check | Fails when | Typical severity |
|---|---|---|
| Every external rate and status carries a capture date and matches reality | A benchmark is stale enough to change the conclusion | High / Critical |
| Each described rival mechanic still works the way it is described | A protocol changed its model and the deck cites the old one | High |
| TAM, SAM, and SOM are sourced and reproducible | A market-size or competitor figure is unsourced or invented | High |
| Both ends of every range have support | One bound of a stated range rests on no source | High |
### Track 3: Mathematics and formulas
Recompute every number the reader is shown, independently, from the model's own inputs. Off-by-one errors in vesting schedules and supply that fails to reconcile across sheets are not rare edge cases—in our own reports they recur more than any other class of Critical.
| Check | Fails when | Typical severity |
|---|---|---|
| Total unlocks for each group equal that group's allocation | A group releases more—or fewer—tokens than it holds | Critical |
| Every period reconciles: circulating = prior + emissions − burns | Any stated identity breaks between two sheets | High / Critical |
| Units are coherent across the model (currency, time, supply, %) | Percentages and token counts are mixed in one formula | High |
| Events at a schedule boundary do not silently vanish | A cliff or unlock at the horizon edge drops to zero unseen | Critical |
| An independent recompute reproduces every displayed figure | A headline number is off by a factor, not a rounding | Critical |
| No printed verdict contradicts the arithmetic on the same screen | The model says "loses money" while the net is positive | Critical |
A note on reachability: if a wrong number appears for *any* input combination a user can actually reach, it fails—the rarity of the combination is never a reason to downgrade it. The [risk-management article]({{< relref "knowledge/defi-risk-management" >}}) covers the stress-test and VaR machinery that this track leans on.
### Track 4: On-chain reality
Marketing numbers meet the chain. Claimed TVL, holder counts, treasury balances, and liquidity are checked against explorer and protocol data, not taken from a dashboard screenshot. The concentration and flow toolkit lives in [our on-chain analytics guide]({{< relref "knowledge/onchain-analytics" >}}); the audit applies it as a pass/fail gate.
| Check | Fails when | Typical severity |
|---|---|---|
| Holder concentration is healthy (CR₁₀ under ~70% ex-exchange/contract/treasury—a practitioner heuristic, not a standard) | The top ten wallets hold most of the free float | High |
| Max supply is an enforced on-chain invariant | Mint, freeze, or upgrade authority is still un-revoked | Critical |
| Withdrawable liquidity is material against FDV | A few thousand dollars of real depth backs a nine-figure cap | Critical |
| The pool has real bid-side support, not just ask-side inventory | A modest sell drops the price by tens of percent | Critical |
| Claimed TVL and volume survive an explorer and DefiLlama check | Stated growth just revalues its own inventory | High |
### Track 5: Mechanism integrity
Does the system hold up under rational actors and stress? This is the track that separates a design that works from one that only works while everything goes up. Governance-specific checks draw on [the voting-models breakdown]({{< relref "governance/voting-models" >}}); the unlock-cliff-versus-liquidity question is quantified in [the vesting-benchmarks piece]({{< relref "knowledge/vesting-benchmarks" >}}).
| Check | Fails when | Typical severity |
|---|---|---|
| Collateral price is independent of demand for the token it backs | The asset is collateralized by its own reflexive demand | Critical |
| Sink ≥ source at realistic activity, over the modeled horizon | Emission structurally outruns every burn and sink | Critical |
| "Exit first" is never the rational play on a shared, exhaustible pool | The design rewards front-running other holders' exits | Critical / High |
| The system survives a 30/50/80% drop, a mass exit, an oracle failure | Any named stress scenario breaks the mechanism | Critical / High |
| Flash-loan, bribe, and treasury-capture vectors are closed | No snapshot-at-prior-block, timelock, or per-transaction limit | Critical |
| The largest scheduled unlock clears against real liquidity | A cliff dwarfs the pool's turnover over its unlock window | High / Critical |
### Track 6: Inputs and sources
A model is only as solid as its weakest input. This lens runs across the four analytical tracks: every number that drives a result is traced to where it came from and when.
| Check | Fails when | Typical severity |
|---|---|---|
| Every input has a source and a capture date | A result rests on an unsourced magic number | Medium / High |
| Simulations disclose their parameters and seeds | A distribution is asserted with no μ, σ, or seed to reproduce it | High / Medium |
| Every pass/fail threshold is cited or labeled a heuristic | A rule of thumb is presented as a hard fact | Medium |
| Result-changing conventions are stated | An undisclosed convention flips the headline number | Medium |
## The severity ladder
Findings are ranked on five tiers, and the definitions go into the report so nothing is hand-waved.
{{< callout title="How findings are ranked" type="info" >}}
- **Critical**—a false reader-facing number, fact, or verdict with no defensible reading, or a design flaw that structurally breaks the system. Requires two independent confirmations before it lands.
- **High**—materially misleading but not fatally false: a directionally-true exaggeration, a missing-but-needed safeguard, or a stale mechanic where the direction still holds.
- **Medium**—defensible but weak: disclosure that is necessary but insufficient, partial coverage, or an unsourced threshold.
- **Low**—cosmetic or documentation-completeness issues; the qualitative conclusion is unaffected.
- **Note**—an observation rather than a defect—including the positives, so the report is balanced and cannot be dismissed as a hatchet job.
{{< /callout >}}
The tiers are the easy part. What makes an audit worth more than a checklist is how findings get *elevated*, and three rules do most of that work:
1. **Cross-track corroboration becomes the verdict.** A single flaw that surfaces independently on four tracks—as a claim, as broken math, as an on-chain fact, and as a mechanism failure—is no longer four findings. It is the top-line conclusion. A launch-blocking "do not ship" is almost never one finding; it is one flaw the whole method converges on.
2. **A defect active on defaults outranks one that needs an exotic input.** A wrong number on the first screen, with no sliders touched, ranks above the same error reachable only through an unusual combination. This orders findings within a tier; it never sets one—rarity never downgrades a defect (a wrong number reachable at all still fails at full severity), it only decides what leads the executive summary.
3. **A recommendation is a claim, and gets fact-checked like one.** The most insidious error we find is a false fact that entered a document *through a previous audit's own fix*—a correction nobody verified. Any assertion inside a recommendation passes the claims track before it ships, or it becomes the next audit's Critical.
## A worked pre-mortem: Axie Infinity's $SLP
Run the method backward on a public failure and it stops being abstract. Axie Infinity is usually remembered for the Ronin bridge hack—$625M in March 2022. That was an *operational* failure, and it is not what we are auditing here. The token-design failure was separate, it predates the hack, and it is the cleaner lesson: $SLP, the game's reward token, was inflating toward zero long before a single key was compromised. The same project exhibited two independent failure modes—one code-and-ops, one design—which is the whole argument for running both.
Here is what the method flags, pre-mortem, on dated public facts:
| Failed check | Public evidence | Severity |
|---|---|---|
| Sink ≥ source (Track 5) | $SLP emitted from Adventure, PvP, and Daily Quest but had one sink—the breeding fee. Public mint-and-burn data put the daily ratio in the region of 2–3× through late 2021—and far higher at the peak of the scholarship boom—so the float rose with no ceiling. | Critical |
| "Exit first" / reflexive new-user dependence (Track 5) | The only sink, breeding, is demand from *new* players. When new-user inflow stalled, the sink evaporated while emission continued—a growth-dependent loop that unwinds the moment inflow stops. | Critical |
| Named-mechanic and market currency (Track 2) | $SLP fell from $0.3645 (2 May 2021) to $0.0094 (3 Feb 2022) to under $0.004 by mid-2022, roughly −99%. The "150 SLP ≈ $55" scholar wage in Manila became about $1.41. | High |
| A reachable reason to hold (Track 1) | The "sustainable play-to-earn" narrative rested on unit economics that only cleared while the player base grew. | High |
Notice the shape. This failure carries almost entirely on the mechanism track—two Critical checks—with market and claims corroborating. That is the common case for a public post-mortem: one track holds the verdict and the others confirm it. The four-track pile-up that makes a finding unarguable needs a live deck, model, and contract to cross-check against each other; a dead token no longer offers them, and a mechanism Critical blocks a launch on its own regardless.
Sky Mavis cut emissions on 8 February 2022—zeroing Adventure and Daily Quest $SLP, roughly 130M fewer tokens a day, a 56% cut to daily supply. By then the token had lost nearly all of its value against the May 2021 peak, and the loop had already unwound. A sink-source check on the model would have raised a Critical the day the schedule was written, not the day the price confirmed it.
The pattern is not unique to Axie. STEPN's move-to-earn $GST repeated it in 2022—reward token emitted for activity, sinks (minting and repairing sneakers) all new-user-dependent, $GST falling to $0.18 by 13 June 2022, down over 90% in the six weeks from its early-May high, as reported monthly active users fell from over 2M to 482K. A regulatory shock was the trigger there, but the reflexive design was the precondition. Terra's UST is the depeg cousin of this failure family, dissected in [the stablecoin article]({{< relref "models/stablecoin-tokenomics" >}}); we use Axie precisely because it is a different failure—emission outrunning sinks, not collateral collapsing—and because it has not already been written to death.
## When you run it
{{< checklist title="Five moments an audit earns its cost" type="check" >}}
Pre-TGE. Before launch, while changing a parameter is a spreadsheet edit rather than a governance war.
Pre-fundraise. To defend the design to investors in an independent voice, separate from the founder's.
Post-incident. After a depeg, a governance attack, an oracle failure, or price action nobody can explain.
Pre-relaunch. When redoing tokenomics after a first attempt that did not hold.
Periodic. For live protocols, every 12 to 18 months, as the on-chain state drifts away from the original design.
{{< /checklist >}}
## The honest limits
An audit reviews what already exists; it does not build the fix—that is a separate modeling engagement, and running the two together (audit to find, model to repair) is usually the right sequence. Without a model or specs detailed enough to reconstruct one, the math track goes qualitative: you can name the risk, but you cannot recompute the number. And every market and on-chain finding is dated—true on the day it was captured, worth re-checking before the report is six weeks old. The method is reproducible, which also means it is falsifiable: if a finding's evidence does not hold, the finding does not either. That is the point. A rating you cannot contest is a rating you cannot trust.
{{< cta title="Have a design to audit?" text="Send a model, a deck, a whitepaper, or an on-chain identifier. We read it cold and come back with severity-ranked findings, evidence bound to each one, and a recommended depth—full multi-track or a single focused track." button="Get in touch" link="/quote/" >}}
## The takeaway
A tokenomics audit is not a letter grade, and it is not a code review. It is six tracks of concrete pass/fail checks, each finding bound to evidence and ranked by a severity ladder whose elevation rules are written down. The value is not in the tiers but in reproducibility: a method a founder, a CFO, or an investor can contest line by line and defend without the auditor in the room. Axie's $SLP failed the sink-source check the day its emission schedule was drafted. The whole purpose of an open methodology is to catch that on paper—while it is still a design decision, and not yet a chart.
---
## Units of Work in AI and Crypto: From Bitcoin PoW to Salesforce AWU
- URL: https://giantslabs.pro/knowledge/units-of-work-pow-to-awu/
- Section: knowledge
- Date: 2026-05-19
- Last modified: 2026-05-19
- Description: Five ways industries measure work — Bitcoin Proof of Work, Ethereum gas, training FLOPs, LLM tokens, and Salesforce AWU. Where each metric breaks, how they line up on a dollar scale, and why the intersection of AI and crypto is the most interesting place in the spectrum.
On February 25, 2026, on its Q4 FY26 earnings call, Salesforce introduced a new metric — the **Agentic Work Unit (AWU)**. Salesforce defines an AWU as "one discrete task accomplished by an AI agent" — decisions made, records updated, workflows triggered. Practically, at the platform level, that's a prompt processed, a reasoning chain completed, or, most importantly, a tool invoked. On the same call, Marc Benioff said something more useful than the metric itself: "**A token on its own doesn't know your customers, your pipeline, your org chart, but Salesforce does.**" Then: "**The value isn't in the token. The value is in what our platform does with it, the work.**" Patrick Stokes added: "you can ask it a question and it can write you a poem, but that's not really all that valuable in the enterprise world." Over the quarter, Salesforce produced 771 million AWUs; 2.4 billion in total since launch.
The trend is clear: some count **how much the model talks**, others try to count **how much work it actually did**. This is not a new conversation. Each digital industry has picked its own unit of work: Bitcoin — hashes per second, since 2009; Ethereum — gas; ML infrastructure — FLOPs; LLM providers — tokens; Salesforce — AWUs. Each is solving (and failing) the same problem: how to formalize the thing that actually matters to the economy — **a useful outcome**.
This article is a comparative survey of five such metrics on a single coordinate system. For a deep dive on AI agent tokenomics and the related infrastructure layer, see [AI Agent Tokenomics: From Memecoins to Revenue Share]({{< relref "knowledge/ai-agents-tokenomics" >}}); this piece is about the units of measurement themselves.
## Three categories of "work"
Sort the five metrics by **what they physically measure** and three layers emerge — each further from hardware, closer to value, and less unambiguous.
- **Physical work.** Proof through burned energy. A Bitcoin hash is a concrete computation that leaves a physical trace in the form of a consumed kilowatt-hour. There is no reverse path: a hash, once computed, is irrevocably spent watts.
- **Computational work.** Proof through counted operations. Ethereum gas, training FLOP, LLM inference token. Each has a registered cost in processor instructions, but the direct link to energy is blurred — the same operation can be executed more or less efficiently.
- **Task-level work.** Proof through outcome. AWU, TPS, "closed ticket", "updated CRM record". Here the link to processor instructions is almost invisible — a task can take one message or forty steps, and the unit counts the closure.
{{< callout title="The key point" type="info" >}}
The higher the layer, the closer the metric to **economic value** for the buyer — and the higher the risk it turns into a vanity metric optimized for its own sake. Bitcoin cannot produce "an extra hash for hash's sake" (it instantly becomes more expensive); Salesforce can produce "an extra AWU for AWU's sake" — which is exactly the main objection raised against AWU by CIO.com.
{{< /callout >}}
## The math of five metrics
The minimum amount of math needed to work with the numbers.
**Bitcoin PoW.** Network mining boils down to brute-forcing SHA-256 nonces until the output falls below a target value. Expected number of hashes per block:
{{< formula math="H_block ≈ D · 2³²" >}}
- D — current network difficulty (dimensionless)
- 2³² ≈ 4.295 · 10⁹ — a consequence of how the Bitcoin target is encoded relative to difficulty = 1
- H_block — expected hashes until a valid block is found
- May 2026: D ≈ 136.61 · 10¹², H_block ≈ 5.87 · 10²³ hashes
{{< /formula >}}
Network hashrate is the time derivative: ~970 EH/s ≈ 9.7 · 10²⁰ hashes per second. A miner gets a fixed block reward (after the fourth halving in April 2024, the reward is 3.125 BTC per block until the next halving around 2028) plus fees — the decay schedule is analyzed in detail in [Reward emission models]({{< relref "models/reward-emission" >}}).
**Ethereum gas.** Each EVM operation has a fixed cost in gas units. A simple ETH transfer — 21,000 gas. ADD — 3 gas. SLOAD on the first access to a slot (cold) — 2,100 gas; subsequent (warm) — 100 gas. SSTORE from zero to non-zero — 20,000 gas on warm access; in the typical "cold slot" case the COLD_SLOAD_COST of 2,100 is added, for 22,100 total (EIP-2929/2200). Transaction cost:
{{< formula math="Fee_tx = gas_used · gas_price · 10⁻⁹ · P_ETH" >}}
- gas_used — total gas across all opcodes in the transaction
- gas_price — gas price in Gwei (1 Gwei = 10⁻⁹ ETH)
- P_ETH — ETH price in USD
- Fee_tx — fee in USD (computed)
- May 2026: gas_price ≈ 0.1–0.7 Gwei (the norm after Dencun and blob transactions)
{{< /formula >}}
**Training FLOP.** Model training cost is measured in floating-point operations. The empirical rule for transformers:
{{< formula math="C_train ≈ 6 · N · D" >}}
- N — number of model parameters (for MoE — active parameters per token, not total)
- D — number of tokens in the training corpus
- C_train — total FLOP budget
- Examples: GPT-4 ≈ 2 · 10²⁵ FLOP (Epoch AI), GPT-4o ≈ 3.8 · 10²⁵ FLOP (SemiAnalysis estimate), Gemini Ultra (2023) ≈ 5 · 10²⁵ FLOP; per Epoch AI, about 30 publicly known models had crossed 10²⁵ FLOP by 2025
{{< /formula >}}
**LLM token.** The formula is trivial:
{{< formula math="Cost_inference = (N_in · P_in + N_out · P_out) / 10⁶" >}}
- N_in, N_out — input/output token counts
- P_in, P_out — price per 1 million input/output tokens, USD
- Cost_inference — cost of one query, USD
- May 2026 output prices per 1M: Claude Opus 4.7 — $25; Claude Sonnet 4.6 — $15; GPT-5.5 — $30; GPT-5.4 — $15
{{< /formula >}}
**AWU.** Salesforce does not publish a formula, but from the announcements it's clear: 1 AWU = 1 discrete agent action — a prompt processed, a reasoning chain completed, or a tool invoked. On the Flex Credits pricing schedule it's $0.10 per action. At the platform level:
{{< formula math="AWU_period = Σᵢ Tasks_i" >}}
- Tasks_i — agent tasks such as "update a record", "close a ticket", "invoke a tool"
- AWU_period — total over the period
- Q4 FY2026: 771 · 10⁶ AWUs in a single quarter; cumulative — 2.4 · 10⁹
{{< /formula >}}
## Comparative table: five systems of measuring work
Side by side, the landscape becomes obvious.
| System | What it physically measures | Unit | Who pays | Pricing mechanism | Main limitation | Reference point (May 2026) |
|---|---|---|---|---|---|---|
| **Bitcoin PoW** | Direct SHA-256 brute force | 1 hash | miner (electricity and ASIC depreciation) | difficulty adjusts to a target block time (~10 min) | Cost is unrelated to the usefulness of transactions | Network: ~9.7 · 10²⁰ h/s; per block: ~5.87 · 10²³ hashes |
| **Ethereum gas** | EVM operations (opcodes) | 1 gas unit | the sender of the transaction | EIP-1559 base fee + tip; varies with block congestion | Price is set by competition, not usefulness (MEV, gas wars) | ADD = 3; SLOAD cold = 2,100; SSTORE = 20,000; transfer = 21,000 |
| **Training FLOP** | Floating-point multiply/add | 1 FLOP | model owner (GPU cluster) | capex + energy; no market price for a single FLOP | Measured in lab conditions; price per FLOP is derived, not primary | GPT-4o ≈ 3.8 · 10²⁵ FLOP; ~30 models > 10²⁵ |
| **LLM token** | BPE-subword in/out | 1 million tokens | API user | provider's price list (fixed; margin by model) | 1M "filler" and 1M "answer" cost the same | Claude Opus 4.7: $5/$25 per 1M (in/out); GPT-5.5: $5/$30 |
| **Salesforce AWU** | Agent action (prompt, chain, tool call) | 1 AWU | customer (via Flex Credits or per-seat) | $0.10 per action / $2 per conversation / $125 per user per month | 1 AWU doesn't distinguish a result from an attempt | Q4 FY2026: 771M AWUs |
The pattern that falls out of this table: the higher the **relative cost per unit**, the further the metric is from physics. One Bitcoin hash costs about $5.3 · 10⁻¹⁹ (network reward divided by expected hashes per block). One Ethereum gas at 0.3 Gwei and ETH ≈ $3,500 — about $10⁻⁶. One Claude Opus output token — $2.5 · 10⁻⁵. One AWU on Flex Credits — $0.10 (or 20 Flex Credits with a token cap of ~10,000 tokens per action). Roughly seventeen orders of magnitude between the extremes. At that scale it's clear that we're comparing different kinds of things: some metrics measure a stream of operations, others a stream of value.
## Calculator: what does one unit of work cost
Plug in your own prices — see how the dollar scale shifts across five systems of measuring work. The six sliders are the six variables that drive cost-per-unit:
- **BTC price ($)** — market price of bitcoin. The higher BTC goes, the more one hash is worth (numerator in `block_reward · P_BTC / (D · 2³²)`). Default $100k matches May 2026; the $20k–$250k range covers bear and bull scenarios.
- **ETH price ($)** — market price of ether. Linearly drives the dollar cost of one gas: `gas_price · 10⁻⁹ · P_ETH`.
- **Gas price (Gwei)** — fee per gas unit, in nano-gwei (1 Gwei = 10⁻⁹ ETH). Default 0.30 is the median in May 2026 after Dencun + EIP-4844. The top of the range (50) corresponds to peaks like NFT mints and cascade liquidations.
- **LLM output price ($/1M tokens)** — provider's price for a million output tokens. Default $25 = Claude Opus 4.7. The low end ($0.5) covers Haiku 4.5 / Gemini Flash; the high end ($60) — a hypothetical enterprise tier.
- **1 AWU price ($)** — cost of one agentic task in Salesforce. $0.10 is the Flex Credits price from May 2025; $2 is the older Conversations tier (also one task, but more expensive).
- **Bitcoin difficulty (T)** — Bitcoin network difficulty in trillions. Sits in the denominator of the hash formula: the higher D, the cheaper a single hash (but the more hashes per block). Default 136.61T matches May 2026.
The table below the sliders recomputes live: cost per unit in dollars and the ratio to 1 AWU.
Cost-per-unit-of-work calculator
System
Unit of work
Cost, $
Ratio to AWU
At the defaults, the gap between "1 hash" and "1 AWU" is about 10¹⁸ (a hash is 5.3 · 10⁻¹⁸ cheaper). Between "1 LLM token" and "1 AWU" — only 4 · 10³ (a token is 4 thousand times cheaper). And "1 simple ETH transfer" at the current gas price comes out to about $0.02 — comparable to 1 AWU (transfer is ~4–5x cheaper). In gas-price peaks (50 Gwei and above) the relationship inverts and a transfer becomes tens of times more expensive than an AWU. The point is not that AWU is "expensive" and a hash is "cheap." The point is that different metrics pack different amounts of useful work into one unit — and comparing them head-to-head by cost-per-unit only makes sense when you understand **what's actually inside that unit**.
## Where the metric breaks the economy
Each of the five systems has a structural flaw, and it's not accidental — it's baked into the metric itself.
**Bitcoin: energy grows independent of value.** A 970 EH/s network draws tens of gigawatts; that figure is set only by the BTC price and difficulty, not by how many transactions are actually useful. When the block subsidy drops below what fees can cover, the metric of "work" will still measure the same hash count — but there will be no one left to pay for it. This is the well-known problem of [decaying emission]({{< relref "models/reward-emission" >}}) and why [DePIN projects]({{< relref "models/depin-tokenomics" >}}) copy it: halving is elegant, but it assumes someone pays for the work, not just for the issuance.
**Ethereum gas: the price of work is set by something other than work.** The same SSTORE always costs 20,000 gas, but the gas price itself is set by the competition for the block. In peak periods (NFT mints, liquidations) gas reached hundreds of Gwei — not because the ops got harder, but because block space became scarce. That dynamic produces MEV (Maximal Extractable Value), gas wars and front-running — situations where the price of "work" on Ethereum is determined by competition with other participants, not by how useful that transaction is to the user.
**LLM tokens: 1M of "filler" = 1M of "the answer".** Anyone who has paid OpenAI or Anthropic prices knows the structure: a token is a unit that has no idea about the value of the result. "hi how are you" and "do due diligence on this contract" are priced on the same scale. Of the five metrics, tokens are the most direct imitation of work — and exactly what Salesforce is trying to escape with AWU.
**AWU: the critique Salesforce admits itself.** Two days after the announcement, [CIO.com published a piece](https://www.cio.com/article/4138622/awu-by-salesforce-a-shiny-new-metric-that-tells-cios-little-of-value.html) titled "AWU by Salesforce: A shiny new metric that tells CIOs little of value." The main argument: AWU counts activity, not outcomes. 1 AWU = 1 reasoning chain, regardless of whether that chain closed a deal or turned the request into a dead end. Stokes himself acknowledged on the call: "you can ask it a question and it can write you a poem, but that's not really all that valuable in the enterprise world" — meaning the metric does not distinguish a valuable query from a non-valuable one. Salesforce is betting that AWU will correlate with value by the nature of its platform — its agents only operate in enterprise context. But that's an assumption, not a property of the metric.
{{< callout title="Goodhart's law in a new form" type="warning" >}}
"When a measure becomes a target, it ceases to be a good measure" — Goodhart's law. Bitcoin is protected by the fact that a hash cannot be forged without cost; LLM tokens are not; AWU is even less so. If billing is tied to the number of reasoning chains, the vendor has a structural incentive to produce more chains for the same task. The history of ChatGPT turning every question into a verbose answer is an illustration of this risk well before the metric was even monetized.
{{< /callout >}}
## Reducing to one scale: energy, money, value
If all five systems measure "work," can we reduce them to a single scale? There are three candidates.
**Energy scale (J).** Works for Bitcoin and training FLOP — these are physical processes with a direct cost in kilowatt-hours. Doesn't work for AWU: an "update a CRM record" task has no meaningful energy cost — it can be done in one API call or five, and the physical equivalent will differ by orders. For Ethereum gas the scale is intermediate: gas is an abstraction over energy, but the concrete mapping depends on what the validator runs on.
**Dollar scale ($).** Universal because everything is ultimately paid in dollars. But it hides structure: $0.10 per AWU is Salesforce's margin on top of its own spend on LLM tokens and infrastructure; $5 · 10⁻²¹ per hash is the physical cost of electricity plus ASIC capex, with no intermediary. Comparing dollar costs, we're comparing not work but its price — and price includes positioning, margin and bargaining power.
**Value scale ($value created).** Theoretically the most correct. In practice, unmeasurable for most systems. No one can say that **one reasoning chain brought a company $X**: value is created by the product, not by an individual agent step. Salesforce gets around this by rolling out AWU as a **proxy for value**, but that's exactly the objection — a proxy easily diverges from the goal.
**Where the scales converge: AI crypto.** The most interesting region of the metric spectrum is the intersection where task-level work meets physical work. [Bittensor]({{< relref "models/bittensor-tao-deep-dive" >}}) with its Yuma consensus measures "work" through the quality of an ML model's output, judged by validators. Strictly speaking, Yuma is not PoW in the Nakamoto sense — it's a stake-weighted weight consensus: rewards are distributed by validator consensus, not by nonce discovery. "Useful proof-of-work" here is a metaphor for the fact that validators are paying for inference quality, not for hash work. [Gonka](https://gonka.ai) with its Transformer-based Proof-of-Work is more literal — miners brute-force nonces and feed them through a transformer with randomly initialized layers; valid results count as work. That is PoW in the classical sense, where the "hash function" is a transformer forward pass. In both cases the unit of work is no longer a hash or a FLOP — it's a **successfully completed AI task**.
What the industry is moving toward is **compressing the three scales into one point**: a metric that's simultaneously verifiable like a hash, measurable like a FLOP, and meaningful like an AWU. No one has built it yet — but the experiments at the AI / crypto intersection are closer to that point than any of the pure metrics on their own.
## Summary
1. **Every industry constructs its own "unit of work," and every metric is a compromise.** Bitcoin measures precisely but with no regard to value; AWU measures value but with no verifiability.
2. **The five metrics form a spectrum from physics to task.** Hash → gas → FLOP → token → AWU. The higher the layer, the higher the vanity-metric risk and the more room for margin.
3. **AWU is not a new idea — it's a new translation of an old one.** Salesforce is trying to dodge the token trap, where the company pays for "talk." It hasn't closed that trap, just moved it: now you can pay for "activity without outcome."
4. **The AI / crypto intersection is the most interesting place.** Bittensor's Yuma consensus (formally not PoW, but the same idea — "pay for useful ML work") and Gonka's transformer-PoW are attempts to build proof-of-useful-work — a unit of work that is useful by its very nature. That's the prototype of the metric that none of the five existing systems has.
5. **The key question for a tokenomics project is not "which metric is best" but "which metric does your system bill on."** If it's the same one the system itself optimizes on, Goodhart's law will eventually kick in.
{{< cta title="Let's design the metrics and tokenomics for your project" text="We'll help pick a unit of work that won't degenerate into a vanity metric, and build a durable economy around it. Domains — crypto infrastructure, AI projects, DePIN, enterprise platforms." button="Discuss the project" link="https://giantslabs.pro" >}}
---
## Vesting and Unlocks: Benchmarks, Formulas, and Sell Pressure
- URL: https://giantslabs.pro/knowledge/vesting-benchmarks/
- Section: knowledge
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Vesting standards by round (seed, private, public, team), sell pressure formula at unlock, and analysis of failed unlocks.
Vesting is the schedule for gradual token unlocking. The fundamentals of vesting and its place in allocation are covered in the [allocation]({{< relref "models/allocation" >}}) article. This article focuses on what most breakdowns lack: **industry benchmarks** (what vesting parameters are considered standard in 2025–2026), **the sell pressure formula** at unlock, and **analysis of failed unlocks**.
## Vesting Parameters
Every vesting schedule is defined by four parameters:
{{< formula math="Unlocked(t) = TGE_% + min(1, max(0, (t − Cliff) / Vesting)) × (100% − TGE_%)" >}}
- TGE_% — percentage of tokens available at launch
- Cliff — waiting period before unlocking begins (months)
- Vesting — linear unlock period after the cliff (months)
- t — time since TGE
- min(1, ...) caps the unlock at 100%
- In practice, accumulated tokens unlock as a lump sum at the cliff end
{{< /formula >}}
| Parameter | What it determines | Typical range |
|---|---|---|
| **TGE unlock** | How much is available on launch day | 0–25% |
| **Cliff** | How long to wait before unlocking begins | 0–12 months |
| **Vesting** | How long linear unlocking lasts | 6–48 months |
| **Total period** | Cliff + vesting | 12–60 months |
## Benchmarks by Round
Data based on analysis of projects launched in 2023–2025. Benchmarks reflect median values across the industry.
### Seed Round
The earliest investors. Maximum discounts → longest vesting.
| Parameter | Median | Range | 2025–2026 trend |
|---|---|---|---|
| TGE unlock | 0% | 0–5% | Shifting to 0% |
| Cliff | 6 months | 3–12 months | Increasing to 9–12 |
| Vesting | 24 months | 18–36 months | Increasing to 24–36 |
| Total period | 30 months | 21–48 months | Growing |
{{< callout title="Why cliffs are getting longer" >}}
After the unlock waves of 2022–2023, when projects with 3-month cliffs for seed investors experienced sharp sell pressure, the industry shifted toward longer cliff periods. Investors accept longer cliffs in exchange for larger discounts.
{{< /callout >}}
### Private Round (Series A / Strategic)
| Parameter | Median | Range | 2025–2026 trend |
|---|---|---|---|
| TGE unlock | 5% | 0–10% | Stable |
| Cliff | 3 months | 1–6 months | Stable |
| Vesting | 18 months | 12–24 months | Stable |
| Total period | 21 months | 13–30 months | Stable |
### Public Round (IDO / Launchpad)
Retail investors. Minimal discount → short vesting, but with expected sell pressure.
| Parameter | Median | Range | 2025–2026 trend |
|---|---|---|---|
| TGE unlock | 20% | 10–25% | Decreasing (from 25% to ≈15%, Binance Research 2024; Messari State of Tokenomics 2024) |
| Cliff | 0 months | 0–1 month | Stable |
| Vesting | 6 months | 3–12 months | Lengthening |
| Total period | 6 months | 3–13 months | Lengthening |
### Team and Advisors
| Parameter | Median | Range | 2025–2026 trend |
|---|---|---|---|
| TGE unlock | 0% | 0% | Standard: 0% |
| Cliff | 12 months | 6–18 months | Increasing to 12–18 |
| Vesting | 36 months | 24–48 months | 2024–2025 norm 36–48 (Liquifi/Coinbase TokenManager, Messari) |
| Total period | 48 months | 30–66 months | Growing |
### Ecosystem Fund / Treasury
| Parameter | Median | Range | Note |
|---|---|---|---|
| TGE unlock | 5% | 0–10% | For initial incentive programs |
| Cliff | 0 months | 0–3 months | Often no cliff |
| Vesting | 48 months | 36–60 months | Longest period |
| Total period | 48 months | 36–63 months | Ensures multi-year development |
## Summary Benchmark Table
| Category | TGE | Cliff | Vesting | Total | Supply share |
|---|---|---|---|---|---|
| **Seed** | 0% | 6–12 mo. | 24–36 mo. | 30–48 mo. | 5–15% |
| **Private** | 5% | 3–6 mo. | 18–24 mo. | 21–30 mo. | 10–20% |
| **Public** | 15–20% | 0–1 mo. | 6–12 mo. | 6–13 mo. | 1–5% |
| **Team** | 0% | 12–18 mo. | 36–48 mo. | 48–66 mo. | 15–20% |
| **Ecosystem** | 5% | 0 mo. | 48–60 mo. | 48–63 mo. | 20–30% |
| **Community** | 10–100% | 0 mo. | 0–12 mo. | 0–12 mo. | 5–15% |
## Sell Pressure at Unlock
### The Pressure Formula
Not all unlocked tokens are sold. The sell ratio depends on the holder category:
{{< formula math="Sell_pressure_$ = Unlocked_tokens × Sell_rate × Token_price" >}}
- Unlocked_tokens — number of tokens unlocked in the epoch (token quantity, not %). If starting from Unlocked_% from the formula above, convert: Unlocked_tokens = Unlocked_% × Allocation_supply
- Sell_rate — share of unlocked tokens that holders sell (depends on category)
- Token_price — current price in USD
- Sell_pressure_$ — resulting sell pressure in USD
{{< /formula >}}
### Sell Ratios by Category
Empirical data based on on-chain analysis of major unlocks from 2023–2025:
| Category | Sell ratio | Sell period | Rationale |
|---|---|---|---|
| **Seed** | 40–80% | 1–4 weeks | Maximum ROI, profit-taking. 60–80% is the aggressive upper band observed in distressed launches (Keyrock 2024, Dragonfly 2023); 40–60% is more typical for liquid markets |
| **Private** | 40–60% | 1–4 weeks | High ROI but longer horizon |
| **Public** | 50–70% | 1–7 days | Retail investors, impulse selling |
| **Team** | 10–30% | 1–3 months | Sell portion for taxes/expenses |
| **Ecosystem** | 20–40% | 1–3 months | Grants partially sold by recipients |
{{< callout type="warning" title="Cliff unlock — maximum impact" >}}
A cliff unlock is the most dangerous moment for price. After the cliff period, a large volume unlocks simultaneously (cliff × monthly vesting). If cliff = 6 months with 24-month linear vesting, the cliff unlock releases 25% of the allocation (6/24) at once. This is equivalent to 6 months of sell pressure compressed into one week.
{{< /callout >}}
### Pressure Calculation Example
A project with $100M market cap and $5M daily trading volume. Seed investors received 10% of supply, cliff = 6 months, linear vesting = 24 months, TGE = 0%.
Plugging into the vesting formula, the first month post-cliff unlocks `1/24 ≈ 4.17%` of the seed allocation, i.e. `10% × 4.17% ≈ 0.417%` of total supply.
| Parameter | Value |
|---|---|
| Seed allocation (USD notional at current price) | 10% × $100M = $10M |
| TGE unlock | 0%, cliff unlock = first release |
| First-month post-cliff unlock | 1/24 of seed allocation ≈ 4.17% |
| Unlocked in that month (USD) | $10M × 4.17% ≈ **$417k** |
| Sell ratio (seed, mid of 40–80%) | 70% |
| Sell pressure | $417k × 70% ≈ **$292k** |
| Ratio to daily volume | $292k / $5M ≈ **5.8%** |
In this base case the monthly unlock is digestible. The picture changes if the cliff releases accumulated tokens as a lump sum: 6 months of vesting compressed into one day gives `6/24 = 25%` of the seed allocation = $2.5M unlocked at once, `$2.5M × 70% = $1.75M` sell pressure, or 35% of daily volume — a critical level. This is why cliff-unlock mechanics matter much more than steady-state monthly unlock.
{{< formula math="Pressure_ratio = Sell_pressure / Daily_volume" >}}
- These thresholds are practitioner heuristics (Kaiko/Messari-style liquidity buffers), not hard rules
- If > 20% — high risk of significant price drop
- If > 50% — critical level, market typically can't absorb
- If < 10% — market usually absorbs the pressure
{{< /formula >}}
## Failed and Successful Unlock Analysis
### Typical Mistakes
**Simultaneous cliff for multiple categories.** If seed, private, and team all have a 6-month cliff, a massive unlock occurs 6 months post-TGE — 30–40% of supply in one week.
**Solution:** Stagger cliffs: seed — 9 months, private — 6 months, team — 12 months.
**High TGE unlock for public.** 25% TGE for a public round with a small share (2% of supply) creates immediate pressure: retail investors who don't see growth sell in the first hours.
**Solution:** Reduce TGE to 10–15% and extend vesting.
**No market maker support.** An unlock without sufficient order book depth leads to slippage and cascading liquidations.
**Solution:** Coordinate with the market maker, increase depth ahead of major unlocks. See the [market making]({{< relref "models/market-making" >}}) article for details.
### Successful Practices
**Gradual unlocking (linear vesting).** Instead of monthly cliff-like releases — daily or weekly unlocks. This distributes pressure evenly.
**Reverse vesting for team.** Team tokens unlock only upon hitting KPIs (TVL growth, user count, revenue). Ties incentives to outcomes.
**Lockdrop / stake-to-claim.** Unlocked tokens are only accessible after staking for 30–90 days. This delays sell pressure and filters out short-term speculators.
## Design Rules
### The Non-Overlapping Cliff Rule
{{< formula math="Cliff_seed ≠ Cliff_private ≠ Cliff_team" >}}
- Stagger cliff periods by at least 3 months
- Ideal: seed 9 mo., private 6 mo., team 12 mo.
- Check: in which month is the maximum unlock?
{{< /formula >}}
### The 20% Daily Volume Rule
{{< formula math="Unlock_mo < 20% × Daily_volume × 30" >}}
- Monthly unlock should not exceed 20% of monthly trading volume
- If violated — revise the schedule or provide additional liquidity
{{< /formula >}}
### Progressive TGE
Instead of a fixed TGE% for all — a differentiated approach:
| Category | TGE% | Rationale |
|---|---|---|
| Seed | 0% | Maximum discount, long horizon |
| Private | 5% | Partial liquidity |
| Public | 15% | Retail expectations |
| Team | 0% | Market standard |
| Ecosystem | 10% | For launch programs |
{{< checklist title="Vesting checklist" type="check" >}}
Cliffs staggered — waiting periods differ across categories
20% rule met — monthly unlock doesn't exceed 20% of daily volume × 30
Seed TGE = 0% — no unlock at launch for seed round
Team vesting — minimum 24 months with 12-month cliff
Pressure calculated — for each month of the first 2 years
No cliff overlap — no month where two+ categories cliff simultaneously
Market maker — coordinated ahead of major unlocks
Linear unlock — daily/weekly considered instead of monthly
{{< /checklist >}}
## Summary
Vesting is not a formality — it's a critical parameter that determines sell pressure over the first 2–3 years of a token's life. Three core principles:
1. **Stagger cliffs** — never set the same cliff for seed, private, and team
2. **Calculate pressure** — the formula "unlock × sell ratio / daily volume" should stay below 20%
3. **Tie to outcomes** — for team and ecosystem, consider reverse vesting tied to performance metrics
{{< cta title="Need help with vesting design?" text="We've designed vesting schedules for 85+ projects. We calculate sell pressure, stagger cliffs, and stress-test your unlock schedule." button="Get in touch" link="/quote/" >}}
---
## When You Don't Need a Token
- URL: https://giantslabs.pro/knowledge/when-token-not-needed/
- Section: knowledge
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: A 7-question checklist to determine if your project needs a token. Common tokenization mistakes and alternatives.
A tokenomist who says "you always need a token" is either incompetent or selling a service. After working with dozens of projects, the conclusion is clear: **in the vast majority of cases, a token is unnecessary**.
## Why Projects Create Unnecessary Tokens
### The ICO Hangover
In 2017–2018, projects raised billions through ICOs with neither a product nor users. The token was the sole capital-raising instrument. This model became ingrained: founders reflexively assume "crypto project = project with a token."
### Investor Pressure
Crypto VCs are accustomed to liquid exits via token listings. For a VC, the token is the return mechanism: invest at seed, sell on exchange 12 months later. Founders face constant pressure — "when TGE?" — even when the product isn't ready.
### Missing Product-Market Fit
A token masks the absence of real demand. Instead of answering "who needs my product and will they pay for it?", the founder asks "how do I create demand for my token?" This is a substitution: a product without users won't be saved by a token with clever mechanics.
## 7 Questions Before Tokenization
Before designing tokenomics, answer each question. If most answers are "no," a token is likely unnecessary.
### 1. Is There Decentralized Consensus?
**Question:** Do multiple independent parties need to coordinate actions without a central arbiter?
If the entire service runs on your servers, decisions are made by your team, and data lives in your database — it's a centralized product. A token in this case is a superstructure without a foundation.
**Token needed:** L1/L2 blockchains, oracles, decentralized storage, any network with validators.
**Token not needed:** SaaS platforms, marketplaces, centralized exchanges, social networks with a single backend.
### 2. Who Pays for the Service — and How?
**Question:** Is there economic activity generating a sustainable cash flow?
{{< formula math="Token_demand = f(Revenue)" >}}
- Token_demand — a function of real protocol revenue
- No revenue → no sustainable demand
- Exception: for L1s and collateral assets, demand is additionally driven by the security budget and monetary premium, not just revenue
{{< /formula >}}
If users won't pay for the product in fiat, they won't pay in tokens either. Adding a token to a free product doesn't create a business model.
**Token needed:** users pay for a resource (storage, compute, bandwidth), and the token is the natural payment medium.
**Token not needed:** users don't pay at all, or the product works perfectly well with fiat payments.
### 3. Do You Need Distributed Incentives?
**Question:** Are there actions that benefit the system but aren't profitable for participants without additional motivation?
Examples of such actions:
- Transaction validation (useful for the network, costs electricity and hardware)
- Liquidity provision (useful for traders, risky for LPs)
- Content moderation (useful for the community, requires time)
If such actions exist and fiat incentives are unavailable or inefficient, a token may be the solution.
**Token needed:** you need to incentivize a distributed network of participants to perform work.
**Token not needed:** all necessary actions are performed by company employees on payroll.
### 4. Is Decentralized Governance Required?
**Question:** Should users have a voice in protocol governance?
If the company fully controls the product and has no plans to transfer governance to the community, a governance token is pointless. It creates the illusion of decentralization with actual centralization.
**Token needed:** the protocol manages user funds (DeFi), and users should influence parameters affecting their assets.
**Token not needed:** the product is fully team-controlled, and that's appropriate for the business type.
### 5. Can You Achieve the Same Without a Blockchain?
**Question:** Does the blockchain provide real advantages — transparency, immutability, permissionlessness — or is it "blockchain for blockchain's sake"?
| Function | With blockchain | Without blockchain | Blockchain needed? |
|---|---|---|---|
| Payments | Crypto transfers | Bank transfers, cards | No (for most) |
| Authentication | Wallet | OAuth, SSO | No |
| Loyalty programs | On-chain token | Points in a database | No |
| Cross-border transfers | Stablecoins | SWIFT, Wise | Depends on corridor |
| Securities | Tokenization | Brokerage account | For fractionalization and liquidity — yes |
| Voting | On-chain governance | Board meeting | For trustless — yes |
### 6. Is the Product Ready for Tokenization?
**Question:** Is there a working product with real users?
Launching a token before product-market fit is one of the most expensive mistakes. A token creates expectations, regulatory obligations, and sell pressure after investor unlocks — all landing on a project that hasn't found its market yet.
{{< callout type="warning" title="The right order" >}}
1. Build the product
2. Find users
3. Confirm willingness to pay (product-market fit)
4. **Only then** — design tokenomics
A token amplifies what already works. It cannot create demand for something nobody needs.
{{< /callout >}}
### 7. Is There a Sustainable Model Without a Token?
**Question:** Can the business operate and generate revenue without a token?
If the answer is "no," that's a red flag. A token should not be the project's sole revenue source. Successful crypto projects earn from fees, subscriptions, and interest — the token enhances this model, not replaces it.
## Decision Matrix
Score each criterion to determine whether tokenization makes sense for your project.
| Criterion | Weight | Score |
|---|---|---|
| Decentralized consensus needed | ×3 | 0 or 3 |
| Sustainable cash flow exists | ×3 | 0 or 3 |
| Distributed incentives needed | ×2 | 0 or 2 |
| Decentralized governance needed | ×2 | 0 or 2 |
| Blockchain provides real advantages | ×2 | 0 or 2 |
| Product is ready (PMF achieved) — gate criterion | ×2 | 0 or 2 |
| Business works without a token — gate criterion | ×1 | 0 or 1 |
| **Maximum** | | **15** |
These weights and thresholds are heuristic, not empirically calibrated — use as a starting point, not a verdict.
**Interpretation:**
**Red flag override:** if either gate criterion above scores 0, don't proceed to tokenomics design — regardless of the total. A high score on the other five criteria doesn't compensate for a missing PMF or a business that only survives because of the token; that's exactly the scenario Questions 6 and 7 warn about.
- **12–15 (no red flag):** A token is likely needed. Proceed to tokenomics design.
- **8–11:** Gray zone. Consider carefully, requires deep analysis.
- **0–7:** A token is likely unnecessary. Explore alternatives.
## Alternatives to a Token
If a token isn't needed, that doesn't mean blockchain technology is useless for the project. Alternatives:
### Stablecoins for Payments
Accept payments in USDC/USDT. This eliminates price volatility for users and the team, removes the need for listing and market making.
### Points and Reputation (Off-Chain)
Loyalty programs don't require a blockchain. Points in a database are cheaper, faster, and more understandable for users. If transparency is needed, publish Merkle proofs rather than issuing a token.
### Equity (Company Shares)
For raising investment, equity is simpler, clearer, and better regulated. A token as an equity substitute creates legal risks without real advantages.
### NFTs for Verifying Rights
If you need to prove ownership (ticket, certificate, license) — use an NFT on an existing blockchain. No custom token needed, just a smart contract.
## When a Token Actually Makes Sense
A token is justified in several clear scenarios:
{{< checklist type="check" >}}
Infrastructure networks — L1/L2 blockchains, oracles, decentralized storage, compute. A token is necessary for consensus and resource payment
DeFi protocols — DEXs, lending platforms, derivatives often benefit from a governance token that lets users manage parameters affecting their funds. Uniswap ran ~2 years tokenless and still captured the DEX market — the token added governance, not the product itself
Real-world asset tokenization (RWA) — commodities and money-market instruments have working secondary markets today; real estate and private credit tokenization still lack meaningful secondary liquidity, so for those two the benefit is closer to fractionalization than liquidity
{{< /checklist >}}
In all four scenarios, the token solves a **specific technical or economic problem**, rather than serving as a capital-raising instrument.
## Instead of a Conclusion
The best thing a tokenomist can do for a client is honestly say "you don't need a token" when that's the case. This saves months of development, hundreds of thousands of dollars on listing and market making, and the reputational cost of a failed token without real utility.
Tokenomics is not about creating tokens. It's about designing economic systems. Sometimes the best system is one without a token.
{{< cta title="Not sure if you need a token?" text="We'll audit your business model and determine whether tokenization is warranted, or if more effective alternatives exist." button="Get in touch" link="/quote/" >}}
---
## Why Tokenomics Matters: Five Problems Priced in Dollars
- URL: https://giantslabs.pro/knowledge/why-tokenomics-matters/
- Section: knowledge
- Date: 2026-07-06
- Last modified: 2026-07-06
- Description: Five business problems tokenomics solves—fundraising odds, LTV/CAC, vulnerabilities, stalled roadmaps, decision confidence—priced with expected-value math.
Ask a founder why they invest in tokenomics and you will usually get an answer about credibility: investors expect a token model, so the project needs one. That answer explains the deck slide. It does not explain the budget. Tokenomics work costs real money and real founder attention, and "investors expect it" is not a number.
There is a better answer. Tokenomics solves five specific business problems, and each of them can be priced the way you would price any risk decision: probability times impact. The estimates are honest rather than precise. This article walks through all five, puts a worked dollar estimate on each, and shows which problems hit which projects at which stage.
## What tokenomics actually solves
Strip away the terminology and a token model touches the business in five places. Everything else ([supply schedules, demand loops, stakeholder incentives]({{< relref "basics/what-is-tokenomics" >}})) is machinery in service of one of these five outcomes.
| # | Problem | What breaks without it | What carries the cost |
|---|---------|------------------------|----------------------|
| 1 | Fundraising odds | Investors discount or pass on a weak token model | Probability of closing the round |
| 2 | Profit per user | Incentives misfire; retention and ARPU underperform | LTV/CAC across the user base |
| 3 | Economic vulnerabilities | Treasury drains, death spirals, whale games | Expected loss on TVL at risk |
| 4 | Stalled roadmap | Product and marketing wait on token decisions | Burn rate of the idle months |
| 5 | Decision confidence | Founders fly blind on price-sensitive choices | Cost of the wrong call |
Two things are worth noticing before the math. First, these problems arrive at different stages: a pre-seed team feels problem 1 and 4, a post-raise team feels 2 and 3. Second, and this is the uncomfortable one: founders often do not know they have problems 2, 3, or 5 until something visibly breaks. A weak emission schedule does not announce itself. It just quietly bleeds retention or waits for an unlock event to turn into sell pressure.
## The math: pricing each problem
The pricing tool throughout is expected value. Nothing exotic:
{{< formula math="EV = Δp × V" >}}
- EV — expected value of the intervention
- Δp — change in probability of the outcome (in percentage points)
- V — value at stake if the outcome occurs
{{< /formula >}}
All figures below are worked examples with stated assumptions, not benchmarks. The point is the structure of the calculation: swap in your own raise size, TVL, and user counts, and the framework prices your project instead of the hypothetical one.
### Problem 1: fundraising odds
A strong project raising a $2M seed round has some base probability of closing. Call it 5% per serious investor conversation cycle. A coherent, defensible token model removes one of the standard reasons to pass; suppose it lifts the probability to 7–8%.
| Input | Value |
|-------|-------|
| Target raise | $2,000,000 |
| Base close probability | 5% |
| Probability with solid tokenomics | 7–8% |
| Δp | +2–3 pp |
| EV in raised capital | $40,000–60,000 |
| Profit-equivalent (÷3, capital ≠ profit) | ~$13,000–20,000 |
The arithmetic runs in two stages: EV = Δp × V prices the raised capital at $40–60k, and dividing by three discounts it to a profit-equivalent—deliberate conservatism, because raised capital is fuel purchased with dilution, not profit. Even discounted that hard, the expected value of the tokenomics work exceeds its typical cost—and this is the *smallest* of the five effects. Investors increasingly read the token model as a proxy for how rigorously the team thinks; a valuation framework built on [honest FDV math]({{< relref "knowledge/fdv-calculation-guide" >}}) signals more than the numbers themselves.
### Problem 2: profit per user
This is where tokenomics stops being a fundraising artifact and becomes an operating lever. Token incentives change user behavior: how much users pay (ARPU), how long they stay (retention), how many transactions they run, and whether they bring others (virality). All of that lands in one place: [unit economics]({{< relref "knowledge/unit-economics" >}}).
{{< formula math="ΔProfit = Δm × T × U" >}}
- Δm — incremental margin per user per month from better incentives
- T — retention period in months
- U — number of affected users
{{< /formula >}}
A modest worked example: incentive redesign adds $5 of monthly margin per user, average retention is 5 months, and the base is 4,000 users.
| Input | Value |
|-------|-------|
| Δ margin per user per month | $5 |
| Retention | 5 months |
| Users | 4,000 |
| **ΔProfit** | **$100,000** |
Five dollars per user is a conservative assumption: a staking tier that lifts retention by one month, or a discount mechanic that shifts users from mercenary farming to actual usage, routinely does more. The effect scales linearly with the user base, which is why this problem dominates the math for anything past product-market fit.
### Problem 3: economic vulnerabilities
The single largest expected-value item, and the one founders most reliably underestimate. Token systems fail economically, not just technically: emission schedules that guarantee sell pressure, treasury mechanics that can be drained through legal multi-step manipulations, incentive loops that invert under stress. The [2026 DeFi attack record]({{< relref "knowledge/defi-hacks-2026" >}}) makes a related point from the other side: less than 10% of the $765M lost that year came from smart-contract code bugs—the rest exploited how systems were governed and operated, from blind-signed multisigs to concentrated admin keys. Governance concentration and trust topology are tokenomics decisions too, and they get reviewed in the same audit.
A tokenomics audit hunts three categories of weakness:
- **Drain points**—scenarios in which the treasury or the native token price bleeds under specific, reachable conditions.
- **Manipulation chains**—multi-step sequences (borrow, swap, vote, unwind) that are individually innocent and jointly extractive.
- **Adversary classes**—whales, arbitrageurs, sniper bots: actors whose optimal strategy damages the system unless the design prices them in.
{{< formula math="EV_audit = Δp_failure × TVL_at_risk" >}}
- Δp_failure — reduction in probability of economic failure
- TVL_at_risk — value exposed if the failure occurs
{{< /formula >}}
| Input | Value |
|-------|-------|
| TVL at risk | $25,000,000 |
| Δp of catastrophic failure from an audit | 2 pp (reduction) |
| **EV of the audit** | **$500,000** |
Two percentage points is a conservative estimate for a system that has never been adversarially reviewed. Against a six-figure audit cost, the expected-value case is not close.
### Problem 4: the stalled roadmap
A team without tokenomics expertise hits a token-dependent decision (launch mechanics, incentive budget, unlock design) and development or marketing simply waits. Of the five problems this is the easiest to price: the cost of waiting is the burn rate.
| Input | Value |
|-------|-------|
| Monthly burn (early-stage team) | $15,000–30,000 |
| Delay from missing expertise | 1 month |
| **Cost of the stall** | **$15,000–30,000 per month** |
One month is optimistic. Token decisions made under deadline pressure also tend to be the ones that create problem 3 later, so the stall cost compounds into vulnerability cost.
### Problem 5: decision confidence
Experienced teams seek outside review for this one more than any other. The founder or management suspects nothing specific but cannot verify that the token system is sound, and the questions that matter are precise and quantitative:
- Does $100 of protocol revenue do more for the token price routed to real-yield staking or to DEX liquidity?
- How many active users does the protocol need to absorb next month's unlock without breaking the price floor?
These are not philosophical questions. Each has a computable answer, and the gap between the right and wrong call is measured in the token's market cap movement. Pricing this problem means pricing a specific decision: if the unlock question involves a $10M circulating cap and the wrong answer risks a 20% drawdown that the right preparation avoids, the decision is worth up to $2M. Weight that by however likely you believe the bad branch is: even at 10% probability, the EV of getting it right is $200,000.
The honest summary of all five:
| # | Problem | Worked-example EV | Scales with |
|---|---------|-------------------|-------------|
| 1 | Fundraising odds | $13–20k | Raise size |
| 2 | Profit per user | $100k | User base |
| 3 | Vulnerabilities | $500k | TVL |
| 4 | Stalled roadmap | $15–30k/month | Burn rate |
| 5 | Decision confidence | $200k+ | Cap at stake |
The ordering is the message: the further a project is from launch-day theater and the closer to live economics, the larger the stakes. Problems 3 and 5 dwarf problem 1, yet problem 1 is the only one most teams budget for.
Running the same arithmetic with your own inputs takes a few lines:
Python: expected-value calculator for the five problems
```python
def ev_fundraising(raise_usd, dp, capital_discount=3):
"""Problem 1: EV of improved close probability, profit-equivalent."""
return raise_usd * dp / capital_discount
def ev_unit_economics(dm_user_month, retention_m, users):
"""Problem 2: incremental profit from better incentives."""
return dm_user_month * retention_m * users
def ev_audit(tvl_at_risk, dp_failure):
"""Problem 3: expected loss avoided by an economic audit."""
return tvl_at_risk * dp_failure
def ev_stall(burn_month, months):
"""Problem 4: burn spent while the roadmap waits."""
return burn_month * months
def ev_decision(cap_at_stake, drawdown, p_wrong):
"""Problem 5: EV of getting one price-sensitive call right."""
return cap_at_stake * drawdown * p_wrong
inputs = {
"1 fundraising": ev_fundraising(2_000_000, 0.025),
"2 unit economics": ev_unit_economics(5, 5, 4_000),
"3 audit": ev_audit(25_000_000, 0.02),
"4 stall (1 mo)": ev_stall(22_500, 1),
"5 decision": ev_decision(10_000_000, 0.20, 0.10),
}
for name, ev in inputs.items():
print(f"{name:<18} ${ev:>10,.0f}")
# 1 fundraising $ 16,667
# 2 unit economics $ 100,000
# 3 audit $ 500,000
# 4 stall (1 mo) $ 22,500
# 5 decision $ 200,000
```
## Who has which problem, and when
The five problems are not evenly distributed. Stage predicts them well:
| Stage | Active problems | Typical shape |
|-------|-----------------|---------------|
| Pre-seed / seed, before the raise | 1, 4 | Token model needed for the round; no in-house expertise |
| Seed, after the raise | 2, 4 | Incentives now touch real users; roadmap outruns expertise |
| Series A, before the raise | 1, 5 | Bigger round, sharper diligence; management wants outside eyes |
| Series A, after the raise | 2, 3, 5 | Live TVL, live unlocks, live adversaries |
Project profile adds a second axis:
| Profile | Active problems | Why |
|---------|-----------------|-----|
| Corporate spin-offs and internal ventures | 2, 4, 5 | Budget exists, token expertise does not |
| Projects whose native token has collapsed | 2, 3, 5 | The failure already happened; now it must not repeat |
| Founders with strong Web2 track records | 4, 5 | Deep operating skill, thin token intuition |
| US founders accustomed to high valuations | 4, 5 | Valuation instincts transfer; token mechanics do not |
| Investment funds | 4, 5 | Problem 4 on behalf of portfolio companies |
| GameFi and gambling projects | 4, 5 | Economy design is the product; stakes are immediate |
| Complex DeFi and infrastructure (synthetic stables, derivatives, decentralized storage) | 3, 5 | Attack surface grows with mechanism complexity |
How do these teams solve the problems today? Early-stage projects mostly improvise: product and marketing staff design the token, advisors are paid in tokens, fund analysts contribute opinions. Later stages add in-house tokenomists and external audit teams. US projects reach for freelancers and agencies earlier and more often. The pattern across all of it: the search is for *trusted* expertise, because the buyer usually cannot evaluate the work product directly. That is problem 5 again, one level up.
## Pitfalls in using these numbers
**Reading EV as a promise.** Expected value is a decision tool, not a forecast. The $500k audit figure does not mean an audit hands you half a million dollars; it means that across many projects in your position, that is the average loss avoided. Any single project sees either nothing or a catastrophe dodged.
**Fixing the wrong problem.** The most common failure mode in practice: a project with collapsing retention (problem 2) responds by raising emissions, which manufactures problem 3 while leaving problem 2 intact. Incentive volume is not incentive design. Diagnosis has to precede spend.
**Assuming you would know.** Problems 1 and 4 announce themselves: a failed raise, a blocked sprint. Problems 2, 3, and 5 do not. A slowly mispriced incentive program looks like ordinary churn; a drainable treasury looks fine until the day it does not. The trend is improving (founders in 2026 are noticeably more tokenomics-literate than in 2021), but "no visible symptoms" remains weak evidence of health.
**Copying a competitor's model.** Their tokenomics was priced (if at all) against their own stage, TVL, and user base. The five-problem framework is portable; the answers are not.
**Skipping the zeroth question.** All five problems assume a token should exist. Sometimes it should not, and the most valuable tokenomics advice is [the checklist that says no]({{< relref "knowledge/when-token-not-needed" >}}). A token added for fundraising optics, with no economic function, creates all five problems and solves none.
## Advanced: the portfolio view
Founders who accept the framework usually make one final mistake: treating tokenomics as a one-time purchase. Buy the model, close the round, done. The math above says otherwise, for a structural reason—the problems migrate as the project ages.
At pre-seed the portfolio is problems 1 and 4: small EVs, cheap fixes. Post-raise, problems 2 and 3 activate, and their EVs scale with users and TVL—the very numbers the project is trying to grow. Success mechanically raises the stakes of the token design. A model that was economically sound at $500k TVL can be structurally unsound at $25M. The spreadsheet did not change; the adversary's payoff crossed their cost of attack.
This is why serious teams treat token design as [an iterative process]({{< relref "basics/tokenomics-process" >}}) rather than a deliverable: initial model before the raise, incentive recalibration as real user data replaces assumptions, an economic audit before TVL makes an attractive target, unlock and stress analysis before each major supply event. Each iteration re-prices the five problems against current numbers and spends effort where the EV concentrates.
The five-problem framework will not tell you what your token model should look like. It tells you something upstream of that: whether the work is worth paying for, which failure would actually hurt you, and when the honest answer to a tokenomics pitch is "not yet"—or "not ever". That is a better position than budgeting from a deck slide.
{{< cta title="Which of the five problems is yours?" text="We price tokenomics decisions the way this article does—expected value against your raise, your TVL, your user base—across 40+ engagements from seed models to $25M-TVL audits. The first conversation is a diagnosis, not a pitch." button="Get a diagnosis" link="/quote/" >}}
---
# Section: Governance
## Section landing: Governance
- URL: https://giantslabs.pro/governance/
- Kind: section landing
- Section: governance
- Description: DAO governance models, voting mechanisms, and decision-making frameworks for token-based protocols.
---
## DAO Governance Failure: The End of Token Voting
- URL: https://giantslabs.pro/governance/end-of-token-voting/
- Section: governance
- Date: 2026-05-18
- Last modified: 2026-05-18
- Description: Tally shutdown, Aragon dissolution, and Across's C-corp pivot are one structural transition, not three news stories. We dissect Dennison Bertram's three reasons, anchor the analysis in empirical participation data, and lay out a replacement-framework matrix for 2026.
**DAO governance failure** stopped being a hypothetical in March 2026. Within a three-week window, three events landed that look unrelated until you line them up. On **March 11**, [Across Protocol's Risk Labs](https://www.coindesk.com/markets/2026/03/12/across-s-acx-rockets-80-massively-beating-bitcoin-on-plans-to-dump-its-dao-structure) posted a forum proposal to dissolve the ACX DAO and re-form as a US C-corporation called AcrossCo. The ACX token rallied 80% on the news. Six days later, on **March 17**, [Tally Labs](https://www.coindesk.com/markets/2026/03/17/gensler-and-biden-were-just-better-for-crypto-says-tally-ceo-as-dao-governance-platform-shuts-down)—the governance infrastructure for Uniswap, Arbitrum, ENS, and 500+ other DAOs—announced it was shutting down after six years. At its peak, Tally processed over $1 billion in payments, served more than 1 million users, and helped secure roughly $80 billion in assets. And in **November 2023**, the Aragon Association, the Swiss non-profit that helped Lido and Curve form their DAOs, [liquidated its 86,343 ETH treasury (~$155M)](https://blockworks.com/news/aragon-dao-dissolves-ether) and returned the proceeds to ANT holders at a fixed redemption ratio.
Three different layers of the stack—a tooling vendor, a coordination layer, and a protocol—dissolving for the same reasons. This is not a coincidence. It is a structural transition.
{{< callout type="info" title="The thesis in one sentence" >}}
Pure token-weighted DAO governance is being replaced by hybrid frameworks (multisig + delegation + optimistic veto), legal wrappers (Wyoming DUNA, Marshall Islands DAO LLC), and full transitions to traditional corporate structures (Across→AcrossCo). The driver is not engineering failure—it is the disappearance of the regulatory pressure that made decentralization economically rational in the first place.
{{< /callout >}}
## Why DAO governance tooling is dying
Tally's CEO and co-founder Dennison Bertram gave the most candid post-mortem the industry has produced this cycle. In his shutdown statement and the follow-up CoinDesk interview, he attributed the closure to three structural causes, not to execution failure or competition. The three reasons are worth taking apart, because each one identifies a different load-bearing assumption that DAO infrastructure has been quietly resting on.
**Reason one: the regulatory pressure that justified decentralization has receded.** Under the Gensler-era SEC, building a centralized governance layer over a crypto protocol meant accepting open-ended legal risk. Decentralized governance was the cheapest available insurance policy. With the Trump administration's permissive stance, and with [the CLARITY Act of 2025](https://www.congress.gov/bill/119th-congress/house-bill/3633/text) (H.R.3633) passing the House on **July 17, 2025** by a 294-134 vote, that insurance policy lost most of its value. The CLARITY Act explicitly states that a decentralized governance system and its participants are treated as separate persons unless they are under common control or acting in concert, and that the existence of a legal entity to implement the rules-based system does not by itself imply centralized management. In other words, you can now run a serious protocol with a traditional company behind it and not automatically inherit the securities-law exposure that made DAOs feel mandatory in 2020–2022.
**Reason two: governance tooling for decentralized protocols is not a venture-backable business.** Bertram's exact framing: "there isn't a venture-backed business in governance tooling for decentralized protocols, at least not yet, and the ecosystem Tally was built for has not fully emerged." Tally raised an $8M Series A in April 2025 and reached the end of its runway eleven months later. The math is unforgiving: a governance platform monetizes by either taking fees from treasury flows (politically toxic) or charging DAOs subscription fees (DAOs have grant programs, not operating budgets). Neither path produces venture-scale revenue.
**Reason three: tokenization could not save a services business.** Tally went, in Bertram's words, "nearly the entire process" of preparing its own ICO before concluding the token sale no longer made sense. This matters because it is the cleanest possible refutation of the "everything-tokenizes" thesis. A company whose entire job was running token-based governance for other people could not produce a credible token economy for itself.
[BlockEden's post-mortem](https://blockeden.xyz/blog/2026/04/02/tally-dao-governance-shutdown-decentralization-optional-regulation/) reframes this even more sharply: most DAOs were never primarily about decentralization. They were about regulatory camouflage. Strip away the camouflage, and what is left is the engineering reality—and the engineering reality is not flattering.
The Aragon and Across cases are not separate stories. Aragon was a tooling-layer dissolution (a Swiss non-profit running governance infrastructure couldn't reconcile its treasury-management duties with its DAO promises) and exited by returning the ETH. Across is a protocol-layer dissolution (a working cross-chain bridge concluded that the DAO structure was blocking institutional partnerships) and exited by converting tokens to equity. Tally is the tool-vendor layer. Same root cause, different surface symptoms.
## The participation reality nobody talks about in pitch decks
Before evaluating any replacement framework, the empirical baseline matters. Token-weighted voting is sold as "thousands of stakeholders deciding together." The data say something else.
Quorum thresholds and actual turnout in the largest DAOs:
| DAO | Quorum (% of supply) | Typical turnout | Notes |
|---|---|---|---|
| Uniswap | 4% | 2–3% | Quorum often missed; binding votes are rare events |
| Compound | 4% (reduced from 10%) | 3–8% | Threshold lowered explicitly because of low participation |
| Aave | 2% / 6.5% (tiered) | 2–10% | Lower bar for minor changes, higher for parameter changes |
| Arbitrum | DVP-scaled | 5,150 voters on BoLD (Jan 2025) | Switched from supply-based to Delegated Voting Power |
| Lido | Dual governance | 4–8% | Higher engagement post dual-governance implementation |
Sources: [Time-Weighted Snapshot Framework, arXiv 2505.00888v1](https://arxiv.org/html/2505.00888v1); [Tally Wrapped 2025](https://blog.tally.xyz/tally-wrapped-2025); protocol governance forums.
One of the most-shared recent Arbitrum governance proposals—the BoLD mainnet upgrade—passed with 99.99% approval in January 2025. The denominator: 5,150 voters out of millions of ARB holders. The proposal was technically a triumph; statistically, it was an opinion poll of the engaged 0.1%.
Empirical work on voting power confirms the structural finding: [Analyzing Voting Power in Decentralized Governance (arXiv 2204.01176)](https://arxiv.org/abs/2204.01176) documents that in nearly all major DAOs, the top 10 wallets hold enough voting power to determine the outcome of any contested proposal. Delegation does not solve this—it concentrates it differently. The [Frontiers metagovernance trilemma 2026 paper](https://www.frontiersin.org/journals/blockchain/articles/10.3389/fbloc.2026.1759073/full) frames the deeper bind: DAOs cannot simultaneously maximize decentralization, security, and participation—pushing on any one corner strains the other two. For a deeper treatment of voting mechanism trade-offs, see our [voting models reference]({{< relref "governance/voting-models" >}}).
For the math, the core attack-cost identity is simple. The reason flash-loan governance attacks are profitable is that they collapse one term to near zero.
{{< formula math="Cost_attack = Capital_required × (1 + Slippage) − Payoff_proposal" >}}
- **Capital_required** — tokens needed to clear quorum × top-N voter share
- **Slippage** — market impact of acquiring those tokens
- **Payoff_proposal** — what the malicious proposal can extract (treasury, parameter change, etc.)
When **Capital_required** approaches zero (flash loans) or **Slippage** approaches zero (deep liquidity), any **Payoff_proposal** > 0 makes the attack profitable.
{{< /formula >}}
Two well-documented cases. [Beanstalk Farms in April 2022](https://www.bleepingcomputer.com/news/security/beanstalk-defi-platform-loses-182-million-in-flash-loan-attack/): a $1B flash loan acquired ~67% of voting power (a supermajority); the attacker executed BIP-18, which referenced a smart-contract address that had not yet been deployed at the time of the proposal, defeating community review; the result was $182M drained. [Mango Markets in October 2022](https://therecord.media/crypto-trading-platform-mango-markets-drained-of-more-than-100-million-in-flash-loan-attack): not strictly a governance attack, but the same shape—instantaneous capital acquisition manipulated MNGO price, then drained ~$116M from the protocol. The defensive pattern that emerged is [Compound's Governor Bravo](https://arxiv.org/html/2505.00888v1) with a two-day vote-eligibility delay on newly-acquired tokens. Time-weighted snapshots are now considered minimum table stakes.
A heuristic to estimate where any DAO sits on the participation reality spectrum is below.
Python: Gini-style voter concentration (reference implementation)
```python
def voter_concentration(holdings: list[float]) -> dict:
"""
Compute Gini and top-10 share for a sorted list of voter holdings.
Inputs: holdings — list of token balances of all voters (any order).
Returns: gini, top10_share, n_voters.
"""
n = len(holdings)
if n == 0:
return {"gini": 0.0, "top10_share": 0.0, "n_voters": 0}
sorted_holdings = sorted(holdings)
cumulative = 0.0
total = sum(sorted_holdings)
# Gini coefficient via the Lorenz curve area
for i, h in enumerate(sorted_holdings, start=1):
cumulative += h * (2 * i - n - 1)
gini = cumulative / (n * total) if total > 0 else 0.0
# Top-10 wallets share
top10 = sum(sorted(holdings, reverse=True)[:10])
top10_share = top10 / total if total > 0 else 0.0
return {"gini": gini, "top10_share": top10_share, "n_voters": n}
```
Apply this to any DAO's on-chain voter snapshot to get the empirical inputs for the theater detector below. Most major DAOs return `gini ≥ 0.85` and `top10_share ≥ 0.30`.
## The replacement framework matrix
If pure token-weighted voting is on the way out, what is on the way in? Four patterns dominate the 2026 landscape. Each one has a distinct profile of decision speed, accountability, legal clarity, and the kinds of protocols it fits.
{{< schema "governance/end-of-token-voting" >}}
*Replacement framework matrix: pattern × project stage × jurisdiction.*
**Pattern 1: Pure multisig.** A small council (typically 3-of-5, 4-of-7, or 5-of-9) executes all decisions on-chain. Fastest, most accountable on the merits, but hidden trust assumptions: the council can collude or be coerced. Works for early-stage protocols (<$5M TVL) and short-lived purpose-built DAOs. Examples: many post-launch protocols in their first 12 months before they invent governance.
**Pattern 2: Hybrid (multisig + delegation + optimistic veto).** A multisig executes proposals after a delay window; token holders can veto during the window. Delegates ratify or block. This is the pattern most mature DAOs converge on. It preserves decentralization rhetoric while solving for decision speed. Examples: Optimism Security Council, Arbitrum Security Council, Lido dual governance. Trade-off: the veto window adds friction without adding much real participation, because most token holders never veto.
**Pattern 3: Delegated representative.** Token holders elect delegates; delegates vote on proposals. The voting body is small enough to be informed, large enough to be diverse. The bribe-market problem is severe (Curve wars showed how delegate votes can be bought wholesale through escrow tokens), but the participation rate among delegates is high. Examples: Compound delegate market, ENS delegates, Uniswap delegate program.
**Pattern 4: Dissolve to legal entity.** The protocol converts the DAO into a traditional corporate structure. Token holders take equity or a cash-equivalent buyout. Decision-making moves to a board. This is what Across is doing. It is the most decisive option and the most controversial; it explicitly abandons the decentralization narrative in exchange for the ability to enter enforceable contracts. Examples: Across→AcrossCo (proposed Mar 11 2026, ACX +80%), various Wyoming DAO LLC conversions, Marshall Islands DAO LLC structures (adopted by a growing number of DAOs).
The decision logic is not "which pattern is most decentralized." It is: which decision speed × accountability × legal-clarity profile fits this protocol's actual operations? An institutional-grade bridge that needs to sign enforceable partnership contracts has no use for a 14-day on-chain vote with 2% turnout. A neutral coordination layer like ENS has no use for a private C-corp. A money market handling 200+ risk parameters per asset needs a delegate model; voting on each parameter through a full DAO vote is the on-chain version of central planning ([the Gosplan parallel is direct]({{< relref "governance/planned-economy-dao" >}})).
The interactive block below lets you compute where a given DAO actually sits on the participation reality spectrum. It is a heuristic, not a regulatory test—but it surfaces the gap between claimed decentralization and operational reality faster than any qualitative review.
## Theater Index: measure your own DAO
The Theater Index combines two of the dominant failure modes—voter concentration and effective-quorum collapse—into a single scalar. The composite is heuristic, not academic; the article text labels it as such. Use it as a quick triage signal, not a regulatory verdict.
Governance Theater Detector
Circulating supply exceeds total — check your inputs.
Voter concentration (Gini proxy)
0.45
Effective quorum ratio (T ÷ Q)
0.63
Wallets that effectively decide
2,318
Theater Index: 0.62 — Theater zone.
Heuristic composite — not a regulatory metric. Three zones: ≤ 0.30 real-vote, 0.30–0.60 contested, > 0.60 theater.
The formula behind the index, for reference:
{{< formula math="Theater_Index = G × (1 + max(0, 1 − T/Q))" >}}
- **G** — voter concentration (top-10 wallet share, ∈ [0, 1])
- **T** — typical turnout (% of circulating)
- **Q** — quorum threshold (% of circulating)
Clamped to [0, 1]. Zones: ≤ 0.30 real-vote (green), 0.30–0.60 contested (yellow), >0.60 theater (red).
{{< /formula >}}
Three preset scenarios for context:
| Scenario | Top-10 share | Quorum | Turnout | Theater Index | Zone |
|---|---|---|---|---|---|
| Uniswap-like (default) | 45% | 4% | 2.5% | **0.62** | Theater |
| Lido-like (dual governance) | 30% | 5% | 4% | **0.36** | Contested |
| Compound-Bravo-defended | 25% | 4% | 4% | **0.25** | Real-vote |
{{< callout type="warning" title="Anti-recommendation" >}}
Do not select a governance pattern because it looks most decentralized. Select it because its decision speed, accountability surface, and legal clarity match the protocol's actual operating requirements. The decentralization-theater tax—15-30% slower decisions, no incremental accountability, persistent capture exposure—is paid by users, not by the people writing the governance design.
{{< /callout >}}
## Five governance anti-patterns
Each of the next five patterns is a different way that on-chain governance designs systematically betray their intent. They share one assumption that never holds: engaged, rational, well-informed token holders.
**Anti-pattern 1: Quorum-as-theater.** Set the quorum threshold low enough that almost any proposal passes. Uniswap (4%), Compound (4% post-reduction), and Aave (2% on minor changes) all have effective quorum below the participation rate at which an opposition could realistically organize. The result is governance that performs accountability without delivering it.
**Anti-pattern 2: Delegate concentration.** When delegate markets exist, the top 3–5 delegates control more than 50% of voting power. This is flash-loan-resistant—delegates are accountable individuals—but it is capture-prone in a different way. A protocol that pays its top delegates indirectly (grants, advisory contracts, "ecosystem partnerships") has produced a paid governance class without admitting it.
**Anti-pattern 3: Flash-loan-vulnerable parameters.** Any vote that grants immediate voting power to newly-acquired tokens is one well-capitalized adversary away from disaster. Beanstalk (April 2022, $182M, BIP-18) is the canonical case. Any DAO designing governance from scratch in 2026 without a Compound-Bravo-style time-weighted snapshot is shipping a known vulnerability ([more on this design lens]({{< relref "models/mechanism-design" >}})).
**Anti-pattern 4: Bribe markets.** The Curve wars made vote-buying explicit through veCRV and Convex's vlCVX. The resulting governance hostage scenarios (Convex effectively controls a majority of CRV gauge votes; FRAX and Aura built businesses on top) show that as soon as voting power is liquid, it gets capitalized. Any "ve-style lock for voting power" design needs to think two moves ahead, not one.
**Anti-pattern 5: Proposal fatigue.** Aave runs more than 200 governance-managed parameters. Voter completion rates decay exponentially with proposal count. The result is that the median proposal is approved by the same 50–100 wallets reading the same forum thread, regardless of stakes. This is governance as a [marketing accessory]({{< relref "models/hype-tokenomics" >}}), not as a real decision system.
{{< checklist title="Governance design review — five-point red-flag list" >}}
- Quorum threshold is below typical 90-day turnout — proposal can pass without contested participation
- Top 3 delegates control >50% of voting power — informal oligarchy
- Voting power grants immediately on token acquisition — flash-loan vulnerable
- Voting power is liquid (lockup → tradeable representation) — bribe-market vulnerable
- More than 50 governance-managed parameters per asset/market — proposal fatigue zone
{{< /checklist >}}
If three or more of these flags fire, the protocol is not governed by token holders. It is governed by a small council that hides inside the governance theater. The Gosplan parallel—a planning system that runs on dispersed knowledge it cannot aggregate—applies directly.
## The 2026+ regulatory and design landscape
With the CLARITY Act now through the House and likely toward Senate consideration, the regulatory backdrop has materially shifted. Three legal structures dominate the post-CLARITY landscape:
**The Wyoming DUNA Act** establishes DAOs as Decentralized Unincorporated Nonprofit Associations with limited liability for members. Adoption began in 2024 and accelerated in 2025; it is the cheapest path to legal-entity protection for a DAO that wants to keep its existing token mechanics.
**The Marshall Islands DAO LLC structure** has been adopted by a growing number of DAOs, including treasury-management entities for several major protocols. It is the offshore counterpart to Wyoming for projects outside the US tax net.
**Direct US C-corporation conversion**, as proposed by Across in March 2026, is the most decisive option. Token holders convert at a defined ratio (1:1 ACX→AcrossCo shares above 5M ACX, SPV access below, $0.04375 USDC buyout for those opting out at a 25% premium to the 30-day TWAP). The proposal passed via Snapshot on March 26, 2026 (91.51% in favor), with the conversion beginning in April.
The CLARITY Act ([passage analysis from Arnold & Porter](https://www.arnoldporter.com/en/perspectives/advisories/2025/08/clarifying-the-clarity-act)) does not require any of these. What it does is remove the implicit penalty for choosing the "wrong" structure. A legal entity behind a protocol does not, by itself, imply centralized management; ministerial and administrative delegation to staff is allowed; and decentralized governance participants are not aggregated into a single regulated person.
The design implication is direct. **Decentralization is now a choice, not a liability hedge.** Protocols that genuinely need censorship-resistant coordination (lending markets in regulated jurisdictions, payment rails, neutral DEX infrastructure) will keep some form of token governance. Protocols that benefited from the decentralization narrative for marketing or legal-cost reasons—and that includes a large fraction of the post-2021 DAO universe—will gravitate toward hybrid councils, optimistic governance, or full corporate structures.
What 2026+ governance design looks like in practice:
- **Optimistic governance** by default: proposals pass automatically unless a designated council or token-holder coalition exercises a veto within a window. This is Optimism's Security Council pattern, generalized.
- **Off-chain reputation oracles** (Karma3Labs, EAS attestations, similar) as the basis for delegate weighting—voting power tied to verified contribution history, not raw token holdings.
- **Legal-wrapped hybrid councils** with on-chain ratification: a small accountable body decides; token holders confirm or reject high-stakes changes; routine operations bypass on-chain voting entirely.
- **Time-weighted snapshots** as a baseline defense against flash-loan attacks—now a default in any new governance contract worth shipping.
The open question is whether decentralization survives as a marketing claim when the legal cost disappears. Some protocols will need it for product-market fit (think credibly-neutral coordination layers); most will not. For the ones that do not, the path Tally just walked is the warning, and the path Across just walked is the playbook.
The path Tally just walked is the warning; the path Across just walked is the playbook. Either way, the token-voting era is closing.
{{< cta title="Designing or rebuilding governance for your protocol?" text="We run the four-pattern matrix against your protocol's stage, jurisdiction, and partnership profile. Two-week turnaround, delivered as a ready-to-vote proposal." button="Get in touch" link="/quote/" >}}
---
## Lessons from Planned Economies for DAO Governance
- URL: https://giantslabs.pro/governance/planned-economy-dao/
- Section: governance
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: What Gosplan and DAOs have in common: pricing without markets, seven reform cycles. Parallels between Soviet planned economics and decentralized governance.
DAOs proclaim decentralization but reproduce problems that were solved — or not solved — in the 20th century. The Soviet planned economy was the largest-scale experiment in managing a complex system without market price signals. It survived 70 years, went through seven major reform cycles, and ultimately collapsed. These lessons apply directly to DAO governance design.
## The Calculation Problem: Gosplan vs Governance
### ~24 Million Product Items
By the late 1980s, the Soviet economy produced roughly **24 million distinct items** — from steel and oil to children's socks and matches. Gosplan (the Soviet state planning commission) itself operated on an aggregated "material balance" nomenclature in the hundreds of thousands of positions, but the full economy-wide item list was two orders of magnitude larger.[^ellman] Each product had a fixed price, a production target, and a distribution plan.
The result: the system worked acceptably for simple goods (steel, electricity) but catastrophically for complex ones (electronics, consumer products). The reason — the impossibility of accounting for all interdependencies between goods, consumer preferences, and technological constraints.
### The DAO Parallel
A mature money-market protocol like **Aave v3** manages **200+ risk parameters** through governance — loan-to-value ratios, liquidation thresholds, supply and borrow caps, interest-rate curves, and reserve factors, each set per asset across dozens of listed assets.[^aave] A basic AMM or staking protocol typically has fewer than 30 governable parameters, so the figure scales with protocol complexity, not with DeFi in general. The governable surface typically includes:
- Collateral factors for each asset
- Interest rates
- Borrowing limits
- Liquidation parameters
- Treasury allocation
- Participant incentives
If you put hundreds of parameters to a vote by token holders — you get the same Gosplan: a group of people without complete information trying to coordinate a complex system. The only difference is scale.
{{< callout title="Two distinct arguments: Mises and Hayek" >}}
Ludwig von Mises formulated the **economic calculation problem** in 1920: without market prices for the means of production, no central planner can rationally compare alternative resource allocations, because there is no common unit to aggregate them.[^mises] Friedrich Hayek made a different (complementary) argument in 1945 — the **knowledge problem**: the information needed to run an economy is tacit, local, and dispersed across millions of participants, and prices are the only mechanism we know that aggregates it in near-real time.[^hayek]
In the DAO context both apply: voting on parameters tries to replace the price mechanism with administrative decisions (Mises), while also asking a small group of delegates to substitute for the distributed knowledge of thousands of users, liquidity providers, and risk managers (Hayek).
{{< /callout >}}
## Seven Reform Cycles — and Nothing Changed
The Soviet economy went through seven major reform cycles between 1921 and 1991:
| Period | Reform | Core idea | Outcome |
|---|---|---|---|
| 1921–1928 | NEP (New Economic Policy) | Partial market restoration | Growth, then reversed |
| 1928–1932 | Industrialization | Total central planning | Heavy industry growth, famine |
| 1953–1964 | Khrushchev reforms | Management decentralization | Partial growth, then rollback |
| 1965 | Kosygin reform | Profit-based incentives | Initial success, then sabotage |
| 1973 | Consolidation | Creating production associations | More bureaucracy |
| 1979 | "Improvement" | Better planning methods | No measurable results |
| 1985–1991 | Perestroika | Cooperatives, market elements | System disintegration |
**The pattern:** each cycle began with acknowledging inefficiency, continued with partial decentralization, and ended with a rollback to centralization — because **decentralization without a price mechanism doesn't work.**
### The DAO Parallel
DAOs go through analogous cycles:
1. **Enthusiasm phase:** "Everything on-chain, full decentralization!"
2. **Apathy phase:** A small group makes all decisions. In large token-weighted DAOs like Uniswap, turnout on a typical proposal falls to single-digit percentages of circulating supply; across the broader 2025 DAO set averages run closer to 15–20%, with top money-market protocols like Aave and MakerDAO reaching 20–28% on high-stakes votes.[^turnout]
3. **Committee phase:** Committees are formed with delegated authority
4. **Discontent phase:** Community accuses committees of opacity
5. **Back to phase 1:** "We need to return everything to a vote!"
This cycle repeats until the protocol finds a balance between automation (price mechanism) and voting (administrative decisions).
## Hidden Inflation and Vanity Metrics
### The Soviet Experience
Official inflation in the USSR was approximately 0%. Prices were fixed by the state. But real inflation manifested differently:
- **Shortages** — the product exists, but you can't buy it
- **Quality degradation** — targets are met, but the product gets worse
- **Falsified reporting** — metrics don't reflect reality
The classic example: a nail production target measured in tons — the factory produced giant nails. A target in units — the factory produced microscopic nails. **The metric determines the behavior.**
### The Parallel: Goodhart's Law in DAOs
{{< formula math="When a metric becomes a target, it ceases to be a good metric" >}}
- Goodhart's Law (Charles Goodhart, 1975 Reserve Bank of Australia conference paper)[^goodhart]
- Popularized paraphrase (Marilyn Strathern, 1997) of Goodhart's original 1975 point
- Applies to any incentive system: from planned economies to DeFi
{{< /formula >}}
In DAOs, this manifests as:
| Metric | Manipulation | Example |
|---|---|---|
| **TVL** | Fund recycling, self-lending | Protocol routes its own treasury into pools |
| **Vote count** | Spam proposals | Delegates vote on everything for stats |
| **Holder count** | Sybil farming | Airdrop hunters create thousands of wallets |
| **APY** | Inflationary emission | 1000% APY funded by printing new tokens |
{{< callout type="warning" title="Attention deficit = goods deficit" >}}
In a planned economy, goods shortages led to queues and patronage networks. In DAOs, voter attention deficit leads to apathy and governance capture. Both deficits result from the absence of a price signal that directs resources (money or attention) to where they're needed most.
{{< /callout >}}
## What Works: Automation Over Voting
### The Soviet Experience: Glushkov's OGAS
Viktor Glushkov proposed the National Automated System for Economic Management (OGAS) in the 1960s — a network of computers for optimizing planning. The project was rejected: the bureaucracy didn't want to lose control.
### The Parallel: Algorithmic Parameter Management
In DeFi, automation is already outperforming voting:
| Mechanism | What it automates | Example |
|---|---|---|
| **Interest rate curve** | Lending/deposit rates | Aave: rates adjust automatically based on utilization |
| **Price oracles** | Pricing | Chainlink: aggregation from multiple sources |
| **Automated liquidations** | Collateral management | Liquidation bots: liquidate positions without voting |
| **Bonding curve** | Emission and pricing | [Bonding curve]({{< relref "models/bonding-curve" >}}): price determined by formula |
**The lesson:** parameters that can be automated through algorithms — must be automated. Voting should be reserved for strategic decisions that can't be formalized.
## Decision-Making Hierarchy
An effective system — whether a planned economy or a DAO — requires a hierarchy of decision-making. Not everything can or should be put to a vote.
### Three Levels
| Level | Who decides | Decision types | Speed |
|---|---|---|---|
| **Automatic** | Algorithm | Interest rates, liquidations, pricing | Instant |
| **Operational** | Committee / multisig | Adding markets, parameter updates, emergency measures | Hours to days |
| **Strategic** | Governance (voting) | Contract upgrades, treasury allocation, direction changes | Weeks |
{{< checklist title="Governance design principles" type="step" >}}
Identify all protocol parameters and classify them by level (automatic / operational / strategic)
Move parameters with formalizable logic to algorithms — don't vote on what a formula can compute
For operational decisions, create committees with limited mandates, transparent scope, and rotation
Reserve strategic decisions for voting with timelocks and qualified quorum
Include a veto or emergency shutdown mechanism
Don't create "Gosplan 2.0": if more than 20 parameters require voting — the system is overloaded
{{< /checklist >}}
## The Main Lesson
The planned economy didn't collapse because the planners were incompetent. They were brilliant engineers and mathematicians. It collapsed because **no central authority can process the volume of information that a market processes through the price mechanism.**
DAOs where everything is decided by voting are Gosplan with a blockchain. The path to effective governance lies through **minimizing votes**: automate the routine, delegate operational decisions, and vote only on what truly requires collective decision-making.
For a deep dive into specific [voting models]({{< relref "governance/voting-models" >}}) — quadratic voting, conviction voting, token-weighted voting, and futarchy — with formulas, attack vectors, and practical guidance.
{{< cta title="Designing DAO governance?" text="We help protocols find the right balance between automation, delegation, and voting — so your governance doesn't become the next Gosplan." button="Get in touch" link="/quote/" >}}
## Sources
[^ellman]: Michael Ellman, *Socialist Planning* (Cambridge University Press, 3rd ed., 2014); Mark Harrison, "Soviet Economic Growth Since 1928: The Alternative Statistics of G. I. Khanin," *Europe-Asia Studies*, 1993. End-of-USSR item nomenclature estimated at ~24 million.
[^aave]: Aave v3 Technical Paper; risk-parameter monitoring via LlamaRisk, docs.aave.com/resources/parameters. Per-asset risk parameters (LTV, liquidation threshold, supply/borrow caps, reserve factor, e-mode) × dozens of listed assets.
[^mises]: Ludwig von Mises, "Die Wirtschaftsrechnung im sozialistischen Gemeinwesen," *Archiv für Sozialwissenschaft und Sozialpolitik*, 1920.
[^hayek]: Friedrich A. Hayek, "The Use of Knowledge in Society," *American Economic Review* 35, no. 4 (1945): 519–530.
[^goodhart]: Charles Goodhart, "Problems of Monetary Management: The UK Experience," paper presented at the Reserve Bank of Australia conference, 1975.
[^turnout]: DeepDAO governance statistics, 2024–2025; Snapshot / Tally proposal records for Uniswap, Aave, and MakerDAO.
---
## Liquid Democracy Tokenomics: Vote Delegation by Design
- URL: https://giantslabs.pro/governance/liquid-democracy-tokenomics/
- Section: governance
- Date: 2026-08-11
- Last modified: 2026-08-11
- Description: A token model for liquid democracy: transitive delegation with decay, square-root voting weight, proxy half-life, delegate compensation. Four formulas, worked numbers, and an interactive delegate-weight calculator.
**Liquid democracy tokenomics** is the part of the delegation story that almost nobody designs. Every major DAO already runs delegation—Compound, ENS and Optimism all elect delegates—and the empirical result is well documented: in nearly all major DAOs the top 10 wallets can decide any contested vote, and where delegate markets exist, the top 3–5 delegates control more than half of the voting power. Delegation as practiced today does not fix plutocracy; it [reorganizes it]({{< relref "governance/end-of-token-voting" >}}). Liquid democracy—delegation that is transitive, revocable at any moment, and split by policy domain—is the mechanism-design answer. But a naive implementation collapses into the same super-delegate oligarchy, only faster, because weight now flows through chains. This article builds the token model that keeps it from collapsing: four formulas, working numbers, and a calculator you can break.
{{< callout type="info" title="Scope" >}}
This is a design article, not a survey. For the comparative map of voting mechanisms (token-weighted, quadratic, conviction, ve-model) see [Voting Models in Tokenomics]({{< relref "governance/voting-models" >}}). Here we assume you have chosen delegation and want it to survive contact with whales, bribes and apathy.
{{< /callout >}}
## What liquid democracy actually is
Governance sits on a spectrum. Direct democracy—everyone votes on everything—is precise and ruinously expensive in attention: DeFi protocols carry 200+ governable parameters, and 2% turnout on parameter votes is the norm, not the anomaly. Representative democracy—delegate wholesale, for a fixed term, under a free mandate—is cheap and slow to correct: a delegate who stops representing you keeps your vote until the next election.
Liquid democracy makes delegation *fluid*, in the sense that vote weight flows:
- **Vote yourself whenever you care.** A direct vote always overrides your delegate for that ballot.
- **Delegate the rest.** Your weight is exercised by a proxy you chose—and the proxy is *transitive*: your delegate may re-delegate onward, so weight flows down chains toward whoever actually does the work.
- **Revoke at any moment.** No terms, no election cycles. This is the digital form of the imperative mandate.
- **Split trust by policy domain.** Treasury to one delegate, protocol parameters to another, grants—vote personally.
Classical proxy law supplies the entire vocabulary: a delegation is a revocable power of attorney over voting weight; transitive delegation is sub-delegation; delegation can carry voting instructions, and voting against instructions is a slashable offence. None of this needs new jargon—it needs an economic layer that prices it correctly.
## The core design decision: a vote is not property
The defining mistake of first-generation token voting was treating the vote as a transferable asset. A transferable vote creates a vote market, and a vote market clears at the price of the cheapest bribe: Vitalik Buterin's [critique of coin voting](https://vitalik.eth.limo/general/2021/08/16/voting3.html) and Philip Daian's ["Dark DAO" work](https://hackingdistributed.com/2018/07/02/on-chain-vote-buying/) on hidden vote-buying cartels both reduce to this point. The Curve wars made it explicit—as soon as voting power became a liquid, wrappable position, whole businesses (Convex, Aura) were built on capitalizing it, a dynamic we dissect in the [ve-tokenomics deep dive]({{< relref "models/ve-tokenomics" >}}).
So the model separates two circuits:
1. **Economic circuit—the GT token.** An ordinary transferable token: supply, staking, treasury, rewards. Deliberately no "1 token = 1 vote" identity.
2. **Voting circuit—weight W.** A non-transferable quantity *derived* from staked GT through a square root. Delegation does not move tokens: the delegate receives a revocable proxy over weight, while the tokens stay with the principal and keep earning base staking yield.
The consequences do the work. A vote cannot be sold, because the proxy is non-tradable and revocable—any "sale" can be undone the moment the buyer stops paying. The only way to buy governance is to buy and stake GT yourself, which is expensive, visible on the market, and further blunted by the square root.
## The math: four formulas
### F1—Delegate weight with sub-delegation decay
{{< formula math="W_i = v_i + λ · Σ_{j ∈ D(i)} W_j, 0 < λ ≤ 1" >}}
- W_i — total voting weight of node i
- v_i — the node's own vote (F2)
- D(i) — the set of principals who delegated to node i
- λ — decay coefficient per delegation hop
{{< /formula >}}
Weight decays geometrically along the chain: a chain of depth k transmits λ^k of the original weight. At λ = 0.8 the second hop carries 64%—re-delegating pays only toward someone noticeably more competent than you. The delegation graph is kept acyclic by construction (an attempt to create a cycle is rejected at issuance), so W is computed in one pass in topological order.
Worked example: delegate Carol stakes 10,000 GT herself and holds proxies from 100 principals, each staking 2,500 GT. Each principal's own vote is √2500 = 50, so the delegated pool is 100 × 50 = 5,000. At λ = 0.8:
| Component | Value |
|---|---|
| Carol's own vote v = √10,000 | 100 |
| Delegated weight Σ = 100 × 50 | 5,000 |
| Received after decay, 0.8 × 5,000 | 4,000 |
| **Total W_Carol** | **4,100** |
### F2—Own vote: square root of stake
{{< formula math="v_i = √(s_i)" >}}
- v_i — own voting weight of participant i
- s_i — the participant's staked GT
{{< /formula >}}
The root is taken **per principal, before aggregation**—not over the delegate's pooled total. A whale staking 1,000,000 GT gets v = 1,000: one hundred times the stake of a 10,000-GT holder, ten times the voice. Meanwhile a delegate representing a hundred small principals keeps the honest sum of their individual roots. Taking the root on the delegate's pooled total instead would punish exactly the aggregation liquid democracy is supposed to encourage.
{{< callout type="warning" title="The sybil condition" >}}
Square-root weight only works on top of sybil-resistant identity. Without it, a whale splits 1,000,000 GT across 100 shell addresses of 10,000 GT each and recovers 100 × 100 = 10,000 weight—ten times the honest 1,000. If your protocol has no identity layer, the honest choice is linear weight, stated openly—not a square root that quietly rewards whoever industrializes wallet farming first.
{{< /callout >}}
### F3—Proxy half-life
{{< formula math="d_ij(t) = d_ij(0) · 2^(−t / T_half)" >}}
- d_ij(t) — weight of the proxy from principal j to delegate i at time t
- T_half — half-life of an unconfirmed proxy
{{< /formula >}}
An unconfirmed proxy melts; a one-click confirmation restores it to full strength. With T_half = 6 months:
| Months since confirmation | 0 | 3 | 6 | 12 | 18 |
|---|---|---|---|---|---|
| Proxy weight remaining | 100% | 70.7% | 50% | 25% | 12.5% |
This is the anti-ossification mechanism. In every long-running delegation system the ranking freezes: principals stop paying attention, and incumbent delegates coast on weight granted years ago. Half-life inverts the default—a delegate who has lost the audience loses the weight *automatically*, without requiring an active revocation from every sleeping principal.
### F4—Delegate compensation: pay for work and skin in the game
{{< formula math="R_i = B · (W_i^act / Σ_k W_k^act) · min(1, v_i / (β · W_i))" >}}
- R_i — delegate i's reward for the epoch
- B — epoch budget from the treasury (a share of protocol fees)
- W_i^act — weight delegate i actually used in the epoch's votes
- v_i — delegate's own vote (F2); β — skin-in-the-game floor
{{< /formula >}}
Two properties matter. First, the budget is split over **used** weight only: a dormant super-delegate earns nothing, so hoarding proxies without voting is pure cost. Second, the `min(1, v_i/(β·W_i))` factor demands the delegate's own vote be at least a share β of the weight they represent—otherwise pay is cut proportionally. Proven abuse (voting against instructions, collusion) is punished by slashing the delegate's own stake.
Worked example: quarterly budget B = 100,000 GT; Carol's used weight is 5% of all used weight → base claim 5,000 GT. At β = 2% her required own vote is 0.02 × 4,100 = 82, i.e. own stake of 82² = 6,724 GT. She stakes 10,000 GT (v = 100 > 82), so the factor is 1 and she collects the full 5,000 GT.
## Capping the super-delegate: saturation, not a cliff
Even with decay, popular delegates accumulate. A hard cap ("no delegate above 3%") creates a cliff—and an incentive to split into shadow identities parked just under the threshold. A soft cap saturates instead:
{{< formula math="W_eff = W_cap · (1 − e^(−W_i / W_cap)), W_cap = α · W_total" >}}
- W_eff — effective (ballot-counted) weight of the delegate
- W_cap — saturation ceiling, a share α of live weight W_total
{{< /formula >}}
The curve is smooth: marginal proxies are worth less and less, and no threshold exists to game. The haircut at W_cap = 3,000 (α = 3% of a 100,000 live-weight system):
| Raw weight W | Effective W_eff | Haircut |
|---|---|---|
| 500 | 461 | 7.9% |
| 1,500 | 1,180 | 21.3% |
| 3,000 | 1,896 | 36.8% |
| 4,100 | 2,235 | 45.5% |
| 6,000 | 2,594 | 56.8% |
| 12,000 | 2,945 | 75.5% |
Read the first row honestly: exponential saturation is not free—it shaves even small delegates (7.9% at one-sixth of the cap). That is the price of having no cliff anywhere. If your delegate set is small and trusted, a higher α or a piecewise curve may fit better; the table is exactly the trade-off you are choosing on.
Python: reproduce the saturation table
```python
import math
W_TOTAL = 100_000 # live weight in the system
ALPHA = 0.03 # soft-cap share
W_cap = ALPHA * W_TOTAL
for W in [500, 1500, 3000, 4100, 6000, 12000]:
W_eff = W_cap * (1 - math.exp(-W / W_cap))
print(f"W={W:>6} eff={W_eff:7.0f} haircut={100*(1-W_eff/W):5.1f}%")
```
## Try it: delegate weight calculator
The calculator assembles F1, F2 and the soft cap into one pipeline: own stake → own vote, principals → delegated weight after decay, raw total → effective weight after saturation.
Delegate weight calculator
Raw weight W
4,100
Effective weight
2,235
Saturation haircut
45.5%
Share of live weight
2.2%
Two experiments worth running. Push the number of principals to 1,000 and watch the haircut climb—that is the soft cap refusing to mint a king, no matter how popular. Then set principals to zero and raise own stake to the maximum: a lone whale with 1,000,000 GT lands at v = 1,000—real influence, an order of magnitude short of control.
## The rest of the machine
Formulas alone do not ship. Five mechanics complete the design:
- **Proxies per policy domain.** Independent delegations for treasury, parameters, grants. Undelegated weight stays silent—it neither votes nor counts toward quorum denominators.
- **DAG invariant.** Cycle attempts are rejected when the proxy is issued, and depth is capped at k_max = 2–3. LiquidFeedback's decade of data shows longer chains simply go unused.
- **Direct vote overrides.** For any ballot the principal joins personally, their weight is subtracted from the delegate's for that ballot. Revocation is instant.
- **Commit–reveal balloting.** While voting is open, the tally is invisible. A vote buyer cannot verify what was bought, so the bribe is unenforceable—this, plus revocability, is what actually closes the vote-market loop.
- **Quorum on live weight.** Thresholds count weight active in the last N epochs, not total supply—otherwise quorum dies as the dormant mass grows, which is precisely the failure mode documented across [large DAOs in 2026]({{< relref "governance/end-of-token-voting" >}}).
## Pitfalls: the attack table
| Attack | Mechanism | Defense |
|---|---|---|
| Vote buying | Market for proxies; hidden cartels | Non-tradable revocable proxy; commit–reveal makes bribes unverifiable; pay only for used weight (F4) |
| Whale takeover | Large stake = control | Square root per principal (F2) + soft-cap saturation |
| Sybil splitting | Shell wallets game the root | Identity layer; delegate reputation is non-transferable and cannot be split for free |
| Elite ossification | Sleeping principals feed eternal delegates | Proxy half-life (F3) + zero pay for unused weight (F4) |
| Delegation cycles | Lost votes, runaway weight | DAG invariant at issuance; depth cap |
| Quorum death | Growing dormant mass | Quorum on live weight only |
Three of the six defenses are economic (F2, F3, F4), not procedural. That is the general lesson: procedural patches against governance attacks decay, because attackers iterate; incentive design has to carry the load.
## Starting parameters
| Parameter | Range | Why this range |
|---|---|---|
| λ—sub-delegation decay | 0.7–0.9 | lower makes re-delegation pointless; higher breeds super-delegates |
| k_max—chain depth | 2–3 | longer chains unused in practice |
| α—soft-cap share | 2–5% of live weight | see the saturation table |
| T_half—proxy half-life | 3–12 months | shorter fatigues principals; longer ossifies |
| β—skin-in-the-game floor | 1–3% of represented weight | from F4 |
| Quorum | 10–20% of live weight | tiered: parameters lower, treasury higher |
| Reward epoch | month–quarter | synchronized with voting cadence |
None of these are final numbers—they are priors to stress-test. Simulate the weight distribution on a synthetic delegation graph before fixing any of them: sensitivity to λ and α in particular decides whether your delegate set ends up looking like a parliament or an oligopoly.
## Where this has been tried
[LiquidFeedback](https://liquidfeedback.com/) (the German Pirate Party's platform) ran per-topic transitive delegation in production and remains the best empirical source on super-delegate concentration—the problem F1 and the soft cap exist to price in. Google Votes ran liquid democracy over a corporate social graph for three years. On-chain, Polkadot OpenGov is the closest live relative with per-track delegation and conviction multipliers; Compound, ENS and Optimism run the single-level, non-transitive minimum; Cardano's Project Catalyst professionalizes the delegate role with dReps. The open problems are real: sybil-resistant identity without excluding pseudonymous participants, formalizing "voted against instructions" tightly enough to slash on it, and the privacy–accountability boundary between secret principal ballots and public delegate records. Design for revision—every parameter above should be governable by the very mechanism it configures.
{{< cta title="Designing governance for your protocol?" text="We'll model the delegation graph, stress-test the parameters, and architect the full token governance stack—from voting weight to delegate compensation." button="Get in touch" link="/quote/" >}}
---
## Voting Models in Tokenomics
- URL: https://giantslabs.pro/governance/voting-models/
- Section: governance
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: DAO voting mechanisms compared: token-weighted, quadratic, conviction voting, ve-model. Quorum formulas, governance attacks, and practical recommendations.
Governance is the decision-making system of a protocol. The architecture of voting determines who manages the treasury, changes parameters, and steers the project's development. Poorly designed governance becomes voting theater, where decisions are made before the formal process even begins.
## Why Governance Matters
A protocol is a set of parameters that someone must change:
- **Economic parameters:** fees, interest rates, emission size, reward distribution
- **Technical parameters:** smart contract upgrades, new markets, collateral factors
- **Treasury decisions:** expenditures, grants, investments, incentive programs
- **Strategic decisions:** integrations, partnerships, mission changes
In a centralized company, management makes these decisions. In a decentralized protocol — token holders do, through governance.
{{< callout type="info" title="Scope" >}}
This article focuses on **active-voting** models, where token holders cast votes to approve or reject proposals: token-weighted, quadratic, conviction, and ve-model. **Defensive governance patterns** — optimistic governance (default-approve with a veto window, as in Optimism's Security Council) and rage-quit (Moloch-style exit with a pro-rata treasury share) — are complementary safeguards rather than standalone voting models. They appear in the attack-defense table below but deserve their own treatment. Related governance experiments worth knowing about but out of scope here: Optimism's bicameral Token House + Citizens' House, Arbitrum's Security Council, and Nouns auction-based governance.
{{< /callout >}}
{{< callout title="200+ parameters" >}}
A typical DeFi protocol has **200+ parameters** potentially managed through governance: from trading pair fees to liquidation thresholds. Not all of them should be voted on — some are delegated to committees or automated through algorithms.
{{< /callout >}}
## Model 1: Token-Weighted Voting (1 Token = 1 Vote)
The simplest and most common model. Vote weight is proportional to token holdings.
### Mechanics
1. A holder locks tokens for voting (or uses Snapshot for off-chain voting)
2. Each token grants one vote
3. A proposal passes if it reaches quorum and a majority of votes
### Quorum Formulas
{{< formula math="Quorum_participation = V / G" >}}
- V — number of tokens that voted
- G — total tokens with voting rights
{{< /formula >}}
{{< formula math="Quorum_victory = V_for / (V_for + V_against)" >}}
- V_for — votes in favor
- V_against — votes against
- Typical threshold: 50% (simple majority) or 66.7% (supermajority)
{{< /formula >}}
Example quorum calculation for a DAO with 100M tokens:
- Participation quorum: 4% (4M tokens must vote)
- Approval quorum: >50% (simple majority)
- Proposal creation threshold: 0.1% (100K tokens) or delegated votes
### Problems
**Plutocracy.** Large holders (whales) control voting outcomes. If 3 wallets hold 40% of tokens, they can block or push through any decision.
**Apathy.** Typical DAO voting turnout is 3–5% of eligible tokens. With a 4% quorum, a small group can gain control.
**Vote-renting (flash-loan attacks).** An attacker borrows tokens via flash loan, votes, and returns the loan in the same transaction — the attack cost equals loan interest, not the token price. This is distinct from bribery: here the attacker controls the vote directly for a single block. MakerDAO was exposed to a flash-loan governance attack in 2020; Beanstalk lost $182M to one in 2022.
**Bribery (gauge wars).** A separate phenomenon: markets like Votium, Hidden Hand (sunset 2026), and Convex pay ve-token holders to direct emissions toward specific pools. Unlike vote-renting, bribery is an economically legitimate long-term payment to vote directors — the attacker doesn't take control of the tokens, they pay the legitimate holders to vote a certain way.
{{< callout type="warning" title="Flash loan governance attack" >}}
In 2022, Beanstalk DAO lost $182M in TVL drained from the protocol (attacker net profit ~$80M in non-Bean assets). The attacker borrowed tokens via flash loan (~$1B from Aave, Uniswap, and Sushi), voted to drain the treasury, received the funds, and returned the loan — all in a single transaction. The incident **reinforced and accelerated** the adoption of **timelocks** between proposal creation and voting, plus balance snapshots at a prior block. Many Governor-pattern protocols (Compound's Governor Bravo at [0xc0Da02939E1441F497fd74F78cE7Decb17B66529](https://etherscan.io/address/0xc0Da02939E1441F497fd74F78cE7Decb17B66529), Uniswap's Governor Bravo at [0x408ED6354d4973f66138C91495F2f2FCbd8724C3](https://etherscan.io/address/0x408ED6354d4973f66138C91495F2f2FCbd8724C3)) already had timelocks pre-2022; Beanstalk specifically lacked a meaningful voting delay.
{{< /callout >}}
### When It Fits
Token-weighted voting works for **simple, low-risk decisions**: adding a new market, changing minor parameters. For treasury decisions and contract upgrades, additional safeguards are needed (timelock, multisig veto, quorum guards).
## Model 2: Quadratic Voting (QV)
Quadratic voting reduces whale influence by making each additional vote more expensive.
### Mechanics
In QV, votes are purchased with "voice credits." The cost grows quadratically:
{{< formula math="Cost = Votes²" >}}
- 1 vote = 1 credit
- 2 votes = 4 credits
- 3 votes = 9 credits
- 10 votes = 100 credits
{{< /formula >}}
{{< formula math="Votes = √Credits" >}}
- Inverse formula: a holder with 100 credits gets 10 votes
- A holder with 10,000 credits gets 100 votes (not 100x more)
{{< /formula >}}
### Comparison with Token-Weighted
For illustration, we assume **1 token = 1 voice credit** (pedagogical simplification — in a real QV system, credits are typically allocated separately from token holdings).
| Token count | Votes (1T=1V) | Votes (QV) | Difference |
|---|---|---|---|
| 100 | 100 | 10 | 10x less |
| 1,000 | 1,000 | ~31.6 | 31.6x less |
| 10,000 | 10,000 | 100 | 100x less |
| 1,000,000 | 1,000,000 | 1,000 | 1,000x less |
QV radically narrows the gap: in token-weighted voting, a whale with 1M tokens has 10,000x more influence than a holder with 100. In QV — only 100x.
### The Sybil Attack Problem
QV's main vulnerability is **sybil attacks**: an attacker distributes tokens across many wallets and gains more votes in aggregate than from a single address.
{{< formula math="Attack: N × √(S/N) = √(N×S) > √S" >}}
- N — number of sybil wallets
- S — total tokens held by the attacker
- One wallet with S tokens gets √S votes in QV
- N sybil wallets with S/N tokens each get N · √(S/N) = √N · √S = √(N·S) votes in aggregate
- For N > 1, √(N·S) > √S, so splitting into sybils gains the attacker more voting power
- Without sybil protection, QV collapses back toward linear (token-weighted) voting as N grows
{{< /formula >}}
Solutions:
- **Proof of personhood** (Human Passport, formerly Gitcoin Passport; World ID, formerly Worldcoin) — tying to real identity
- **Social graph** — analyzing connections between addresses
- **Participation threshold** — minimum transaction history or staking to vote
### Examples
**Gitcoin Grants.** Uses quadratic funding — an extension of QV for grant distribution. Many small donations carry more weight than one large one.
### When It Fits
QV is effective for **resource allocation** (grants, budgets) and **prioritization** (which of 10 projects to fund). For binary decisions (yes/no), QV's advantages are less pronounced. Requires a sybil protection mechanism.
## Model 3: Conviction Voting
Conviction voting introduces a time factor: the longer votes are directed at a proposal, the stronger their "conviction."
### Mechanics
1. A holder directs tokens toward a proposal
2. Conviction accumulates exponentially using a half-life formula
3. When conviction reaches a threshold dependent on the requested amount, the proposal executes
4. Switching votes to another proposal resets accumulated conviction
{{< formula math="C(t) = C_prev × α + tokens × (1 − α)" >}}
- C(t) — conviction at time t
- C_prev — conviction at the previous time step
- α — decay parameter (0.9 for slow accumulation)
- tokens — number of tokens directed
{{< /formula >}}
{{< formula math="Threshold = ρ × S / (1 − (Amount / Fund)^β)" >}}
- ρ — minimum confidence parameter
- S — total token supply
- Amount — requested amount
- Fund — total fund size
- β — sensitivity to request size
{{< /formula >}}
### Advantages
- **Flash attack protection** — instant vote buying is useless, conviction accumulates slowly
- **Continuous voting** — no hard deadlines, proposals live until reaching threshold or vote withdrawal
- **Proportional threshold** — large treasury requests require more conviction than small ones
### Examples
**1Hive / Gardens.** Uses conviction voting for DAO treasury distribution. Small requests execute quickly; large ones require lengthy and broad consensus.
### When It Fits
Conviction voting is ideal for **continuous treasury allocation** and situations where manipulation protection matters. Not suitable for urgent decisions (security updates) — conviction accumulation takes days or weeks.
## Model 4: Vote-Escrow (ve-Model)
The ve-model ties vote weight to **lock duration**. Longer lock = more votes and rewards. For a detailed economic analysis, see the [veTokenomics]({{< relref "models/ve-tokenomics" >}}) article.
### Mechanics
{{< formula math="veToken = Token × (t_lock / t_max)" >}}
- veToken — voting token balance
- Token — locked tokens
- t_lock — lock duration
- t_max — maximum lock duration
- ve-tokens decay linearly until unlock
{{< /formula >}}
ve-token holders receive three benefits:
1. **Governance vote** — proportional to ve-token holdings
2. **Fee share** — revenue share from protocol income
3. **Boost** — enhanced LP rewards
### Gauge Voting
The key ve-model mechanic is **gauge voting**: ve-token holders vote on how emissions are distributed across liquidity pools.
**ve-Model Cycle**
### Vote Wars
Gauge voting creates a bribe ecosystem: protocols pay ve-token holders to direct emissions toward their pools. Convex Finance aggregates veCRV and lets CVX holders vote on emission direction, creating "meta-governance" — governing the governors.
### Examples
**Curve Finance (veCRV).** The ve-model standard. Lock up to 4 years. Historically a majority of circulating CRV has been locked in veCRV (typically 40–50%+ depending on the incentive cycle — check Curve UI / DefiLlama for the current snapshot), radically reducing circulating supply.
**Velodrome / Aerodrome.** Two ve-model DEXs (Optimism and Base) that merged into a unified Aero protocol in 2026 (announced November 2025; new token split 94.5% to Aerodrome holders, 5.5% to Velodrome holders). ve-token holders vote on emission distribution and receive 100% of fees from the pools they voted for (not distributed across all pools).
### When It Fits
The ve-model is for protocols with **established TVL and revenue**. It's complex to implement and requires a critical mass of participants. For early-stage projects, the ve-model may be overkill.
## Case Study: Quorum Math for Group Voting
In practice, even a simple task — voting in a 5–25 person group — quickly becomes non-trivial. Let's walk through a concrete parameter-design case.
### Inputs
| Parameter | Notation | Range |
|---|---|---|
| Group size (with voting rights) | G | 5–25 |
| Number of options | C | 2–7 |
| Number of winners (decisions) | W | 1–5 |
| Number of voters | P | ≤ G |
| Votes per voter | v | depends on W |
Simple case: G = 25, W = 1, v = 1. Participation quorum: P > 25/2 = 12.5, so P ≥ 13. Winning quorum: 13 votes. Straightforward.
But at W = 5 (five winners), nuances appear:
- Participation quorum must be **higher** — otherwise a minority decides
- Winning quorum must be **lower** — otherwise no one reaches 13 votes
- Avoid the case where one winner collects 9 votes and four others collect one vote each
### Formulas
**Votes per participant:**
{{< formula math="v = W" >}}
- v — votes per voter
- W — number of winners
- Each voter gets as many votes as there are winners
{{< /formula >}}
**Participation quorum:**
{{< formula math="P > G × W / (1 + W)" >}}
- P — number of voters
- G — group size
- W — number of winners
- At W=1: P > 25/2 = 12.5, so P ≥ 13
- At W=3: P > 25×3/4 = 18.75, so P ≥ 19
{{< /formula >}}
**Winning quorum (in votes):**
{{< formula math="wt > v × G / (1 + W)" >}}
- wt — winning threshold in votes
- v — votes per voter
- G — group size
- W — number of winners
{{< /formula >}}
### Numerical examples (G = 25)
| Winners (W) | Votes per voter (v) | Participation quorum (P) | Winning quorum (wt) |
|:-:|:-:|:-:|:-:|
| 1 | 1 | ≥ 13 people (>12.5) | ≥ 13 votes |
| 2 | 2 | ≥ 17 people (>16.67) | ≥ 17 votes |
| 3 | 3 | ≥ 19 people (>18.75) | ≥ 19 votes |
| 5 | 5 | ≥ 21 people (>20.83) | ≥ 21 votes |
At W=3 and v=3, take P=20 voters: total votes = 20 × 3 = 60. Winning threshold: wt > 18.75, i.e. ≥ 19 votes. Three winners can each collect 20 votes—mathematically possible, using up all 60 votes cast.
### Second round
What if three winners are needed but only two clear the threshold? A second round is required:
1. Exclude the two winners from the candidate list
2. Vote for the remaining options
3. **Don't lower** the quorums — votes are still plentiful (v = W), and fewer options means less dispersion
{{< callout type="warning" title="Simplification trap" >}}
It may seem logical to drop the second-round quorum to simple majority (½+). But with many remaining options, votes disperse across them. Keeping the original quorums ensures each winner has comparable support.
{{< /callout >}}
**Quorum generalization:**
{{< formula math="Quorum = f(G, W, v)" >}}
- G — voting group size
- W — number of winners
- v — expected turnout
- Formula depends on the specific model
{{< /formula >}}
## Model Comparison
**Four voting models**
| Parameter | Token-Weighted | Quadratic | Conviction | ve-Model |
|---|---|---|---|---|
| **Complexity** | Low | Medium | High | High |
| **Whale resistance** | No | Yes | Partial | Partial (time) |
| **Flash attack protection** | Timelock | Timelock | Built-in | Built-in (lock) |
| **Sybil protection needed** | No | Critical | No | No |
| **Decision type** | Binary | Resource allocation | Continuous funding | Emission control |
| **Decision speed** | 3–7 days | 3–7 days | Days–weeks | 1 epoch (7 days) |
| **Participation incentive** | Low | Medium | Medium | High (revenue) |
| **Examples** | Compound, Uniswap | Gitcoin | 1Hive | Curve, Aero (ex-Velodrome/Aerodrome) |
## Architecture: On-Chain vs Off-Chain
### On-Chain Governance
Voting occurs on the blockchain. Results are executed automatically by smart contract.
| Component | Description |
|---|---|
| **Governor** | Smart contract for creating and executing proposals ([OpenZeppelin Governor](https://docs.openzeppelin.com/contracts/5.x/api/governance), [Compound Governor Bravo](https://etherscan.io/address/0xc0Da02939E1441F497fd74F78cE7Decb17B66529), [Uniswap Governor Bravo](https://etherscan.io/address/0x408ED6354d4973f66138C91495F2f2FCbd8724C3)) |
| **Timelock** | Delay between approval and execution (typically 24–48 hours) |
| **Token** | Voting token (ERC-20Votes) with delegation |
Advantages: full transparency, automatic execution, censorship-resistant results.
Disadvantages: high gas costs, low turnout, rigid process.
### Off-Chain Governance (Snapshot)
Voting via signatures without transactions. Results are executed manually (multisig) or via a bridge.
Advantages: free for voters, flexible voting strategies, higher turnout.
Disadvantages: execution depends on multisig trust, no execution guarantee.
### Hybrid Model
Most mature DAOs use a hybrid:
- **Snapshot** for signal voting (temperature check)
- **On-chain Governor** for final approval and execution
- **Multisig** (5/9 or 4/7) as an emergency mechanism and for operational decisions
**Typical governance pipeline: from idea to execution**
## Governance Security
### Common Attacks
| Attack | Description | Defense |
|---|---|---|
| Flash loan | Borrow tokens → vote → return in one block | Snapshot balance N blocks before voting |
| Bribery | Buying votes via bribe protocols | Conviction voting, long lock periods |
| Treasury capture | Proposal to withdraw funds to self | Timelock + veto + per-transaction limits |
| Governance stalemate | Blocking voting with a controlling stake | Optimistic governance (veto instead of approval) |
| Poison pill | Disguised malicious proposal | Mandatory code audit + timelock for review |
### Security Checklist
{{< checklist title="Governance Security Checklist" type="check" >}}
Timelock between approval and execution (minimum 24 hours)
Balance snapshot several blocks before voting begins
Participation quorum at least 4% of voting tokens
Proposal threshold 0.1–1% of supply
Veto mechanism for Security Council (multisig)
Limits on single treasury expenditures (no more than 10% of treasury)
Code audit for all proposals modifying smart contracts
{{< /checklist >}}
## Designing Governance: A Framework
### Step 1: Classify Parameters
Divide all governance-managed parameters into categories by risk level:
| Category | Examples | Governance mechanism |
|---|---|---|
| **Critical** | Contract upgrades, treasury changes >10% | On-chain vote + timelock + veto |
| **Significant** | Fees, collateral factors, new markets | On-chain or Snapshot + multisig execution |
| **Routine** | Small grants, reward parameters | Delegated committees |
| **Technical** | Oracles, gas limits | Automation (algorithms) |
### Step 2: Choose the Voting Model
The choice depends on the types of decisions the DAO makes:
**Choosing a voting model by decision type**
### Step 3: Set Parameters
Practical recommendations:
- **Participation quorum:** 4–10% — lower is rarely achievable, higher paralyzes governance
- **Approval quorum:** 50% for routine, 66.7% for critical decisions
- **Timelock:** 24 hours for routine, 48–72 hours for critical
- **Voting period:** 3–5 days (enough for awareness, not too long)
{{< callout type="warning" title="Voting theater" >}}
In real DeFi governance, factions often negotiate in advance, large holders vote predictably, and formal voting merely ratifies a pre-made decision. Recognizing this is the first step to designing sustainable governance. The goal is not to eliminate politics (impossible) but to make the process transparent and protect minorities from majority tyranny.
{{< /callout >}}
{{< cta title="Need to design governance?" text="We'll select the voting model, calculate quorum parameters, and architect the DAO structure for your protocol." button="Get in touch" link="/quote/" >}}
---
# Section: Cases
## Section landing: Case Studies
- URL: https://giantslabs.pro/cases/
- Kind: section landing
- Section: cases
- Description: Real-world tokenomics case studies: DeFi, GameFi, infrastructure. Anonymized projects with models and results.
---
## Case Study: Clicker Game Economy with Revenue-Share via Smart Contract
- URL: https://giantslabs.pro/cases/gamefi-clicker-economy/
- Section: cases
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: GameFi clicker tokenomics: tokenized revenue, Uniswap v2 liquidity pool, and layer-mining mechanics. Allocation breakdown, unit economics, and simulation.
GameFi clickers are among the most mass-market crypto formats. But most of them hit the same wall: the economy collapses within 3–6 months after launch, with critical decline typically by month 3–4. This case study examines how a project targeting 15M players designed tokenomics where the token is backed by real revenue — not inflationary rewards.
## Context: The Project's Challenge
The project is a clicker game with layer-mining mechanics: players uncover cells of a virtual object layer by layer, collecting prizes. The one who reaches the center claims the grand prize. Available on iOS, Android, and as a Telegram mini-app.
The fundamental difference from most GameFi: **the project is split into two phases.**
**Phase 1 — Game without a token.** Goal: acquire up to 15M users and generate cash flow in stablecoins. At this stage, the entire economy runs on fiat payments and in-game currency.
**Phase 2 — Ecosystem with a token.** Launches only if Phase 1 succeeds: token, DAO, airdrop to players and developers. The token is tied to revenue via smart contract.
The tokenomist's objectives:
1. **Design revenue-share** — investors receive a share of revenue through the token, without traditional unlock schedules
2. **Don't kill the game economy** — the token must not create inflation that destroys game balance
3. **Scalability** — the model must work at 1M and at 15M players
## The Solution: Tokenized Revenue
### Core Idea
Instead of the classic "investors receive tokens → sell on market" scheme, the project used revenue-share through a smart contract:
1. A portion of revenue from in-game equipment sales is automatically used to buy the token via a liquidity pool
2. Investors hold tokens that appreciate due to buyback from real revenue
3. Investor exit is through market sale, not through vesting unlocks
### Token Parameters
- **Total supply:** 100,000,000 tokens
- **Base currency:** USDT
### Allocation and Vesting
| Pool | Share | Amount | Cliff | Vesting |
|---|---|---|---|---|
| Round 1 | 20% | 20,000,000 | 1 month | Instant |
| Round 2 | 20% | 20,000,000 | 2 months | Instant |
| Round 3 | 20% | 20,000,000 | 3 months | Instant |
| LP (liquidity) | 10% | 10,000,000 | 9 months | Instant |
| Team | 30% | 30,000,000 | 1 month | 12 months linear |
Three investment rounds with increasing price: $0.10 → $0.20 → $0.40 per token. Target raise: $14,000,000 total.
### Market Model: Uniswap v2
Liquidity pool on Uniswap v2 with the constant product formula:
{{< formula math="K = X × Y" >}}
- X — USDT reserve
- Y — token reserve
- Initial pool: 1,750,000 USDT + 10,000,000 tokens
- K — pool constant (computed)
{{< /formula >}}
Starting price: $0.175 (1.75x multiple over Round 1 price). The key mechanism: **70% of the project's operating income** (which is 50% of net revenue from primary + secondary markets = 20.75% of total net spending) flows into the pool as buy-side inflow, creating continuous buying pressure on the token.
## The Model: In-Game Economy
### Game Mechanics
The game simulates a mining-like process: all players start with identical base equipment. Advanced equipment (semi-automatic, automatic) improves chances but doesn't guarantee victory.
{{< callout title="Adaptive difficulty" type="info" >}}
Difficulty recalibrates when the player count changes — similar to Bitcoin's difficulty adjustment. At 15M players, an additional million raises the threshold, pushing out inactive participants.
{{< /callout >}}
- **100 layers** — players progress sequentially
- **Average speed:** ~2.7 days per layer
- **Viral coefficient:** 0.7–0.8 (41–44% of new players come through referrals; ~66% of total organic acquisition comes through squads and viral loops combined)
### In-Game Currency and Equipment
In-game currency (called "coins") is distributed across layers — 5B units per layer. Equipment is divided into 11 classes (0–10) with increasing productivity:
| Class | Production per second | Energy capacity |
|---|---|---|
| 0 (starter) | 2 | 100 |
| 1 | 4.5 | 500 |
| 3 | 7.5 | 5,000 |
| 5 | 11.25 | 18,000 |
| 7+ | 15.75 | 42,000 |
Selected classes shown; full table has 11 tiers (0–10) with near-geometric growth in both production and energy capacity.
Equipment upgrades use a fusing system: 2 items of the same class produce 1 item of the next class. Cost grows geometrically, creating a natural sink for in-game currency.
Starting from class 4, equipment gains additional attributes: durability and repair cost reduction — adding strategic depth for hardcore players.
### Player Types and Unit Economics
The simulation identifies 6 cohorts with distinct behavior patterns:
| Type | Average spend/month (peak) | Churn rate |
|---|---|---|
| Hardcore | $25–$1,325 | 11–20% |
| Midcore | $0–$410 | 10–20% |
| Casuals | $0–$90 | 20–25% |
| Newcomers | $0 | 30% |
| Speculators | $100–$1,450 | 5–15% |
| Creators | $0–$220 | 20% |
### Revenue Distribution
| Channel | Share |
|---|---|
| Primary market (direct sales) | 35% of net spending |
| Secondary market (10% commission) | 65% of net spending |
Revenue from both markets is split 50/50 between the project's operating income and the prize pool.
### Prize Pool
- **Initial fund:** $2,000,000 USDT
- **Distribution:** 65% — layer prizes, 35% — grand prize (center of the object)
- Pool is replenished from 50% of primary and secondary market revenue
## Scenario Analysis
The model was tested across three scenarios:
| Metric | Minimum | Base | Maximum |
|---|---|---|---|
| Players | 1M | 5M | 15M |
| GMV per player | $10 | $30 | $50 |
| Purchase volume | $10M | $150M | $750M |
| CAC | $1 (Telegram mini-app organic) | $5.50 | $10 |
| IRR (5 years) | -38.7% | 13.8% | 68.6% |
Maximum scenario (9-month simulation): 18.2M cumulative new players, $4.7B cumulative net spending (including repeat purchases), $979M operating income, $981M prize pool. The $750M figure in the table is a point-in-time snapshot (15M × $50 GMV), while $4.7B is the total over the simulation period accounting for churn and acquisition.
### Value Allocation in the Maximum Scenario
| Beneficiary | Share | Value source |
|---|---|---|
| Developers | 37.45% | Marketing (access to users) |
| Players | 24.47% | 50% of in-game purchases |
| Liquidity + raise | 5% | Uniswap pool |
| Treasury | 7% | Reserve |
| Team | 20.87% | Equity conversion |
| Investors | 5.21% | Equity conversion |
## Lessons Learned
{{< checklist title="Key design decisions" type="check" >}}
Two phases: product first, then token: the token launches only after product-market fit is confirmed. This eliminates the "token launched, no players" scenario
Revenue-share via smart contract: investors are tied to real revenue, not unlock schedules. No "D-day" with massive sell-offs
Adaptive difficulty: self-balancing mechanism for the economy as the player base grows or shrinks
Six cohorts instead of one "average player": the simulation separately models speculators, casuals, and hardcore players
Exponential item fusing (2^N cost): a natural in-game currency sink that slows inflation
{{< /checklist >}}
The main lesson: in GameFi, the token should not be the players' income source — it should be an instrument for investors and the ecosystem. Players earn in stablecoins; the token is backed by revenue. This breaks the vicious cycle of "emission → sell → devaluation."
{{< cta title="Need economics for your game?" text="We design tokenomics for GameFi projects: in-game economy, simulations, scenario analysis, and balance tuning." button="Get in touch" link="/quote/" >}}
---
## Case Study: How a Lending Protocol Utilized Excess Tokens Through Subordination
- URL: https://giantslabs.pro/cases/defi-lending-protocol/
- Section: cases
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Crowdlending platform tokenomics: bonding curve minting, three-tier subordination as a token sink, and triple burn mechanics for cashback utilization.
## The Problem: What to Do with Tokens Given to Lenders
A crowdlending platform for small and medium businesses. The model: the platform connects lenders (individuals, average deposit $50–$20,000 USDC) with borrowers (companies, loans of $500K–$1M in $100–$200K tranches). Collateral coverage: 30–50%.
To attract lenders, the platform issues cashback in tokens for every deposit. 65% of total supply (6.5M out of 10M tokens) is allocated for these rewards. The remaining 35% covers team vesting, protocol treasury, and liquidity provision — beyond the scope of this utilization case study. The problem is obvious: if lenders simply sell the tokens they receive, it creates constant sell pressure. Cashback loses value → incentive disappears → lenders leave → the platform loses liquidity.
The task for the tokenomist: **design a token utilization mechanism** that makes lenders spend their cashback inside the platform rather than sell on the market.
## The Solution: Bonding Curve + Subordination + Burn
The solution is built on three components, each reducing sell pressure.
### Component 1: Bonding Curve Instead of Fixed Emission
Tokens aren't distributed on a schedule — they're minted through a [bonding curve]({{< relref "models/bonding-curve" >}}) only when lenders actually deposit. The mint price rises as a power function:
{{< formula math="P_mint = P_0 × ((β + Minted) / β)^α" >}}
- P_0 = 1.00 USDC — base price
- Alpha = 0.45 — steepness parameter
- Beta = 10,000 — scale parameter
- Minted — total tokens minted so far
- P_mint — current mint price (computed)
- Early lenders get tokens cheaper
{{< /formula >}}
The average mint price P_average serves as an internal oracle for converting token payments:
{{< formula math="P_avg = P_0 × β / ((α+1) × L) × [((β + L) / β)^(α+1) − 1]" >}}
- P_average — average price per token (computed)
- L — number of tokens minted
- P_average is always below current P_mint, making token payments more attractive. Since the bonding curve is monotonically increasing, the average price across all minted tokens is always below the current (highest) price — similar to how your average purchase price in dollar-cost averaging stays below the latest price in a rising market
{{< /formula >}}
### Component 2: Three-Tier Subordination — The Primary Token Sink
Each lender receives CT tokens (confirmation tokens) representing their position in the lending pool. By default, all positions have **Middle** priority. A lender can:
- **Upgrade to High** — by paying tokens. In case of borrower default, High positions absorb losses last (maximum protection)
- **Downgrade to Low** — for free, receiving a payout from the upgrade fund. Low positions absorb losses first
This is the key utilization mechanism: lenders spend their cashback to protect their own deposits.
The upgrade price increases linearly as the High bucket fills up (target operating range: up to 1/3 of all positions; the formula allows higher fill with escalating costs):
{{< formula math="P(u) = C_nominal × (a + b × u)" >}}
- a = 0.01, b = 0.15
- u — High bucket fill ratio (0…1)
- C_nominal — CT token face value (e.g., 10 USDC)
- P_upgrade — cost to upgrade one CT token (computed)
{{< /formula >}}
| High bucket fill | Upgrade cost (% of face value) | At $10 face value |
|---|---|---|
| 1% | 1.15% | $0.12 |
| 12% | 2.80% | $0.28 |
| 28% | 5.20% | $0.52 |
| 55% | 9.25% | $0.93 |
| 66% | 10.90% | $1.09 |
Payouts to Low-tier lenders are weighted by time to maturity — the longer until repayment, the higher the payout:
{{< formula math="w_i = (1 + k × r)^(d_i / 365)" >}}
- k = 3.0 — amplifier
- r = APR = 25%
- d_i — days to maturity
- w_i — weight for position i (computed)
{{< /formula >}}
In case of default, losses are absorbed in order: Low → Middle → High.
### Component 3: Burn Mechanics and Additional Demand
**Subordination burn.** Example: lenders spend 100 tokens to upgrade to High priority. The platform takes a 20% fee (20 tokens — burned). The remaining 80 tokens go to those who agreed to downgrade to Low. If fewer lenders want to downgrade than upgrade — the unclaimed remainder is also burned.
**Quarterly buyback & burn** — 10% of the platform's net profit goes to buying tokens on the market and burning them.
**KYB/Due Diligence payments** — borrowers pay for verification (~$22,000 USDC equivalent) with a discount when paying in tokens. At 5–10 new projects per month, that's $110–220K USDC in additional demand.
**Late payment penalties** — penalty rate of 2–4x the base rate (e.g., at a base rate of 30% APR with a 3x multiplier — 90% APR penalty). Payable in USDC or tokens at P_average.
## Calculator: Bonding Curve and Cashback
### How to Use the Calculator
- Enter the deposit amount in USDC and the current number of minted tokens
- Set the cashback coefficient (LLC) — the share of deposit returned as tokens
- Set the High bucket fill percentage to calculate upgrade costs
- The calculator shows the bonding curve mint price, cashback amount, and the cost of protecting a position
Bonding Curve & Cashback Calculator
Calculator formulas
{{< formula math="P_mint = P0 × ((beta + Total_minted) / beta) ^ alpha" >}}
- P_0 — initial token price at zero supply (USDC)
- Beta — curve scale parameter (number of tokens)
- Alpha — curve exponent, determines price growth steepness
- Total_minted — total number of tokens already minted
- P_mint — current mint price (computed)
{{< /formula >}}
{{< formula math="P_average = P0 × beta / ((alpha + 1) × T) × (((beta + T) / beta) ^ (alpha + 1) − 1)" >}}
- P_0 — initial token price (USDC)
- Beta — curve scale parameter
- Alpha — curve exponent
- T — number of tokens minted
- P_average — average price across all minted tokens (computed)
{{< /formula >}}
{{< formula math="Cashback = 80% × Deposit × LLC / P_mint" >}}
- Deposit — user's deposit amount (USDC)
- LLC — cashback coefficient (share of deposit returned as tokens)
- P_mint — current bonding curve mint price (USDC)
- Cashback — number of cashback tokens for the lender (computed)
{{< /formula >}}
{{< formula math="Affiliate_cashback = 20% × Deposit × LLC / P_mint" >}}
- Deposit — user's deposit amount (USDC)
- LLC — cashback coefficient
- P_mint — current mint price (USDC)
- Affiliate_cashback — number of cashback tokens for the affiliate (computed)
{{< /formula >}}
## Impact Analysis: Token Utilization
### Token Flow Funnel
```
Bonding Curve (minting)
│
├─── 80% → Lender receives cashback
│ │
│ ├─── Upgrades to High priority → UTILIZATION
│ ├─── Sells on market → SELL PRESSURE
│ └─── Holds (loyalty tiers) → RETENTION
│
└─── 20% → Affiliate / Platform
│
└─── Sells or spends → MARKET
Subordination (100 tokens spent):
├─── 20% platform fee → BURN (20 tokens)
└─── 80% → payout to Low-tier lenders (80 tokens)
└─── unclaimed remainder → BURN
KYB/DD: ~$22K per borrower verification → TOKEN DEMAND
Penalties: 2-4x base rate → TOKEN DEMAND
Buyback: 10% of net profit → BURN
```
### Quantitative Assessment
With stable platform operations (assuming 10 pools at $500K USDC each, LLC = 5%):
| Metric | Value |
|---|---|
| Monthly deposits | $5,000,000 USDC |
| Cashback (5% of deposits) | $250,000 USDC equivalent in tokens |
| Utilization via subordination (30% of lenders upgrade) | ~$75,000 USDC equivalent |
| KYB/DD token payments (5–10 projects × ~$22K) | ~$110,000–220,000 USDC equivalent |
| Late payment penalties (5% defaulting tranches, marginal penalty over 1–2 months) | ~$15,000–25,000 USDC equivalent |
| Buyback & burn (10% of ~$150K profit, approximated from loan volume) | ~$15,000 USDC equivalent |
| **Total utilization** | **~$215,000–335,000 USDC → 86–134% of emission** |
With active borrower flow, token demand through KYB/DD can exceed cashback emission. But this depends on the rate of new project onboarding. If borrower inflow slows, utilization drops to ~$90K (subordination + buyback) — 36% of emission. The model works as long as:
1. **Bonding curve slows emission** — at 4M tokens minted, mint price reaches ~$15 (vs. ~$6 at 500K minted), significantly reducing emission per deposit
2. **Real defaults drive High demand** — if 2–3 pools default in year one, Low-tier lenders lose money, and others rush to upgrade
3. **Buyback is tied to real revenue** — if the platform generates 3% of loan volume ($150K+/month, used here as an illustrative proxy for net profit), burn scales proportionally
### Weaknesses
{{< checklist title="Risks identified in the model" type="curve" >}}
Cold-start subordination: with no defaults, lenders see no reason to upgrade. In the first 6–12 months, subordination utilization may be near zero
Bonding curve is one-directional: there's no burn mechanism when tokens are returned to the contract. If lenders sell en masse, the market price can drop below P_average, creating arbitrage
Affiliate share (20%) is pure sell pressure: affiliates don't participate in lending and have no incentive to utilize tokens through subordination
KYB/DD is one-time demand: a borrower pays for verification once (~$22K). At 5–10 new projects per month, that's $110–220K in demand, but this channel doesn't scale with TVL growth
{{< /checklist >}}
### Key Takeaways
{{< checklist title="What worked in this model" type="check" >}}
Subordination = organic demand: lenders spend tokens not because they're promised APY, but because they're protecting their deposits. This is the most sustainable type of utilization
Bonding curve + algorithmic cashback = self-regulating emission: as activity grows, mint price increases and token cashback decreases. No manual parameter adjustments needed
Triple burn outperforms buyback: subordination burn is generated automatically, with no cost of market purchases. Buyback is just an additional channel
CT tokens as an internal market: P2P trading of positions creates another liquidity layer and fee source, without requiring an external DEX
{{< /checklist >}}
The main lesson: in a lending protocol, token utilization should be tied to risk management, not staking or gamification. A lender spends tokens because without upgrading their priority they risk losing their deposit — that's fundamentally stronger than "stake and earn APY."
{{< cta title="Need tokenomics for your DeFi protocol?" text="We design utilization models, bonding curves, and risk management mechanisms for lending platforms, DEXs, and other DeFi protocols." button="Get in touch" link="/quote/" >}}
---
## Case Study: Multi-Product Exchange Tokenomics
- URL: https://giantslabs.pro/cases/multi-product-exchange-tokenomics/
- Section: cases
- Date: 2026-05-07
- Last modified: 2026-05-07
- Description: Stage 1 framework for a multi-product crypto-fintech: sizing 13 product lines, three token concepts (Real Yield / Loyalty / B2B), and FDV ranges.
Most exchange-token designs start from a fixed template—fee discounts, buybacks, staking yield—and then back-solve revenue assumptions to make the multiplier work. This case inverts the order. A multi-product crypto-fintech in an emerging Central Asian market asked for a Stage 1 token concept across thirteen product lines, not one. The deliverable had to explain *which* token was right for *which* revenue mix, with FDV ranges that did not pretend to be point estimates when two of the inputs were still unverified.
{{< callout title="Anonymization note" type="info" >}}
The client name, proprietary product names (the L1, the local-currency stablecoin, the gold-backed token, the working ticker), and the specific country are not disclosed. Public reference tokens (LEO, INJ, KAIA, BNB, HYPE on the exchange-token side; Sky (SKY, formerly MKR), ONDO, PENDLE, CFG, OM, PLUME on the RWA-tokenization side) are named as benchmarks. Methodology, structural choices, and parameter defaults are preserved; absolute revenue and FDV figures are presented as proportions or directional ranges.
{{< /callout >}}
## The Problem: One Platform, Thirteen Revenue Lines, Three Audiences
The standard CEX-token playbook assumes a single revenue surface—spot trading, with futures and a launchpad bolted on. It breaks the moment the platform looks more like a fintech than an exchange.
The client operates thirteen product lines across four categories: a custodial wallet stack with on/off-ramp and swap; payments (crypto debit cards, merchant acquiring, P2P, cross-border remittance); yield and savings (a regulated local-currency stablecoin, a gold-backed local token, a crypto-bank tier with deposits and over-collateralized lending); and markets (spot CEX, tokenized local and global equities, a permissioned domestic L1, and a separate B2B wholesale flow).
Three structural problems sit on top of that surface:
1. **The retail base is not one cohort.** It splits into active traders, savers and DCA holders, and currency users—P2P switchers, remittance recipients, expats. A single fee-discount ladder works for the trader, is irrelevant to the saver, and actively hurts the currency user, whose retention loop is "spend without converting back to cash," not "trade more." See [stakeholders]({{< relref "basics/stakeholders" >}}) for the broader archetype framework this case applies.
2. **The home market has unusual macro.** Substantial annual remittance inflow, meaningful FX and gold reserves, a strong messenger-led distribution layer, and a national-currency stablecoin operated under license from the central bank. Two of the largest revenue lines depend on assumptions we could not verify in Stage 1: a B2B wholesale daily turnover figure provided off the record, and the carry split on the stablecoin (does the platform keep the carry, the state, or is it shared?).
3. **The neighboring markets carry sanctions risk.** Two of the three CIS markets in the addressable region declare crypto turnover well above local GDP—most of it sanctions-corridor flow not realistically addressable for a regulated local operator.
Stage 1 had to deliver three things: a sizing model honest about what's load-bearing, a token concept menu (not a single recommendation) so management could choose by stakeholder set rather than by FDV, and FDV ranges defensible to an institutional investor.
## Sizing: TAM/SAM/SOM by Direction, Not by Headline
We sized the platform across two geographies—the home market and the three-country CIS adjacency—over a three-year horizon (2026–2028), per direction. Each direction has its own GMV definition and take-rate.
### The Thirteen Directions and Their GMV/Take-Rate Anchors
| # | Direction | GMV definition | Take-rate anchor |
|--:|---|---|---:|
| 1 | Custodial wallet | On/off-ramp + swap volume | 0.75% blended |
| 2 | Crypto cards | TPV (Platinum-tier debit) | 2.5% (interchange + FX) |
| 3 | Crypto acquiring | Merchant GMV | 0.4% |
| 4 | Spot CEX | Trading volume | 0.16% blended |
| 5 | Domestic L1 | Settlement + gas flow | ~0.1% |
| 6 | Local-currency stablecoin | Stock (supply, not flow) | net carry × share |
| 7 | Tokenized assets (gold + equities) | Mcap + flow + AUM | 0.2–0.8% by sub-line |
| 8 | Crypto-bank (deposits, lending, IBAN/FX) | Loan book + flow + AUM | 1.8% blended |
| 9 | P2P matching | Matched volume with escrow | 0.3% |
| 10 | B2B wholesale | Cross-border corporate settlement + OTC | 0.15% |
| 11 | Remittance | On/off-ramp + transfer flow | 0.5–0.8% |
| 12 | Crypto-payroll | Payroll volume | 0.5% |
| 13 | Launchpad / IEO | Allocation × success fee | 5–7% on raise |
Two structural choices worth flagging: **stablecoin GMV is stock, not flow**—a regulated reserves-backed stablecoin earns on the float, so the input is supply × net carry × the platform's share, not turnover. And **B2B wholesale is a separate direction, not a CEX subset**—corporate settlement runs through the L1 settlement layer, not the order book; bundling it into spot CEX would double-count and obscure where revenue actually accrues.
### Range, Not Point: Two Load-Bearing Unverifieds
Two inputs carry roughly half of the headline three-year revenue figure:
- **B2B wholesale daily turnover.** Drives the largest single direction. Source: an informal client briefing, no documentary trail in Stage 1.
- **Local-currency stablecoin carry split.** Contract terms determine whether the platform retains 100% of the carry (Tether/Circle template), 0% (state retains all, platform is operator), 30% (typical license fee), or yield-passes-through to holders (rebasing model). Source: hypothesis-by-analogy until we see the contract.
Until those two are verified, the three-year revenue range looks like this:
| Scenario | What it assumes | Revenue (qualitative) |
|---|---|:---:|
| **Base — both verified** | B2B confirmed, stablecoin 50/50 carry split | Upper end of range |
| **B2B not verified** | Direction 10 removed | ~30% lower than base |
| **Stablecoin carry = 0%** | State retains all carry | ~17% lower than base |
| **Worst case — both fail** | Base − B2B − stablecoin carry | ~50% of base |
The base-to-worst spread is close to 2× (~1.9×). That's not a model failure—it is the honest state of information at end of Stage 1. Reporting a single point would have hidden that spread inside the multiplier discussion two blocks later, where it would have done more damage.
### Per-Direction Sanctions Haircut
A flat regional haircut would understate exposure where the smaller market dominates the corridor and overstate it elsewhere. We applied per-direction multipliers calibrated by the smaller market's share of regional TAM: 0.57 for wallet (smaller market is ~57% of regional TAM), 0.83 for CEX (~23% — the larger of the three is dominant), 0.65 for P2P (~47%, large transit). No haircut for cards, acquiring, L1, stablecoin, tokenization, bank, or B2B—the smaller market is negligible there.
Per-direction is more accurate than a single coefficient and lets us defend revenue line by line, not in aggregate.
## Three Token Concepts: One Platform, Three Different Tokens
A single concept can't simultaneously serve a yield-saver who never trades, an active trader, a remittance recipient who treats the wallet as a converter, and a corporate issuer of tokenized debt. We delivered three concepts—three structurally different answers to "what does this token do"—with explicit guidance on which one fits which combination of stakeholder set and revenue mix.
{{< schema "comparison/comparison_01_three-token-concepts" >}}
**Concept A — Real Yield.** The native token is a financial asset. A fixed share of total ecosystem revenue flows to the token, either as buyback-and-burn from the open market or as direct payout to holders in the local-currency stablecoin. Utility on platform operations does not live on the token; it lives on the stablecoin balance instead. Lead archetypes: long-term holders and strategic investors. Three advantages: capital inflow into treasury (each TGE round and buyback brings stablecoin into the ecosystem), the most transparent of the three (a public formula and quarterly report instead of decoded loyalty tiers), and the broadest investor base (sells outside the home market to investors who don't depend on local funnel maturity). Internal fork: pure A.1 (utility entirely off-token) vs A.2 (a stablecoin tier gated by token stake size).
**Concept B — Loyalty Token.** A classic exchange utility token with a tiered loyalty program—but **most of the utility weight that would naturally sit on the local-currency stablecoin is shifted onto the native token instead.** Hold or stake the token to unlock Bronze/Silver/Gold/Platinum tiers, each with its own bundle: discounts on real platform operations, higher savings yield, queue priority, launchpad quotas. The user's mental model: *the stablecoin is money; the native token is the membership card*. Concept B splits into three hub-specific variants by which retail product the platform anchors on:
| Variant | Hub | Utility core | Lead archetype |
|---|---|---|---|
| **B.1 Savings** | Accumulate, save, spend without converting back to cash | Lower on/off-ramp fee, lower mint/redeem on the gold-backed token, higher APY on stablecoin savings, lower rate on collateralized credit | Currency user, saver, DCA holder |
| **B.2 FX / Cross-border** | Cross-border transfer, expat income, local spending | Lower transfer + conversion fees, lower P2P matching fees, tiered referral layer | Remittance recipient, expat |
| **B.3 Trading** | Active spot trading | Volume-tier rebate, launchpad quota, retroactive airdrop, native-token-payment fee discount | Active trader, swing trader |
The three variants share program plumbing but need different leading metrics: cross-product penetration in B.1, conversion of remittance recipients into card spenders in B.2, net margin per dollar of volume in B.3. Forcing a single trader-centric ladder onto all three leaves two of them under-served. The variants are compatible at program level—a single user can earn benefits across two or three if they use the relevant products.
**Concept C — B2B-Loyalty on the Domestic L1.** The same Bronze/Silver/Gold/Platinum ladder, but for legal entities—banks, funds, corporates, issuers of tokenized assets. Hold or stake to unlock lower listing/settlement fees, queue priority, expanded quotas, and a vote on network parameters. **Access to the base infrastructure remains open**—the token offers premium terms, not a barrier to entry. C is a hybrid by design: discount tier for issuers (issuer-side stake → reduced fees) plus revshare via gas-burn (60–80% of network fees → buyback + burn). Lead archetype: institutional issuer of tokenized assets. Retail is touched only indirectly.
The hybrid breaks a standard methodology assumption—"one utilization model per product." Standard formulas don't compose cleanly here. We flag the hybrid as Stage-2 work and run two reference-bound calculations (revshare-only as a lower bound, blended as a target) in the meantime.
### Choosing Between A, B, and C
The three concepts are not ranked by FDV. They are ranked by *which stakeholder set the platform wants to optimize for*:
- **Capital inflow + global investor narrative** → Concept A. Launches earliest, sells to the broadest investor base. Trade-off: regulatory exposure on direct payout; buyback-only requires defending capture rate.
- **Retail retention + ARPU expansion** → Concept B. The three variants give every retail archetype a reason to hold; cross-product upsell is the clearest growth lever. Trade-off: heavy program operations; works *with* the stablecoin, not in place of it.
- **Institutional adoption + L1 as strategic infrastructure** → Concept C. Narrow base of issuers with large average ticket creates more burn flow per holder than thousands of retail users. Trade-off: requires 3–5 anchor issuers at TGE; hybrid methodology is incomplete; FDV depends on unverified B2B flow.
## Three-Level Thinking: Model → Pattern → Mechanic
Inside each concept, the design unfolds across three levels—and they are easy to conflate.
```
MODEL ──► PATTERN ──► MECHANIC
(what we do) (the specific way) (parameters)
Revshare ──► Buyback + burn ──► 25% of weekly
revenue → TWAP
──► Direct payout ──► Auto-reinvest
in stablecoin for stakers
Access ──► Stake / hold / LP ──► Stake $100K →
Bronze quota
```
**Model**: what value-accrual approach—Revshare, Access, Discount, Yield, Rebate, Payment, Governance.
**Pattern**: how the model is implemented. One model splits into multiple patterns (Revshare = buyback+burn *or* direct payout).
**Mechanic**: concrete parameters—formulas, thresholds, lock periods, cap sizes.
Across all three concepts, **the primary activation lever is hold-or-stake** (the Access model). In A it gates revenue-pool participation; in B it gates the loyalty tier; in C it gates the issuer tier on the L1. Mechanics differ; the structural commitment—"user puts the token to one side to access something"—is the same.
A bonding curve as *primary* supply model is unusual for exchange tokens—the five references we benchmarked all used IEO or airdrop. We flagged it as the most natural fit for Concept A: treasury accrues automatically with each purchase, the price formula defends against speculative dump, gradual entry suits long-term holders.
## FDV: Three Multiplier Approaches, Three Concept Outputs
FDV bounds the design—it tells management "this concept can't realistically support more than $X at TGE if revenue lands at the base case." It is not the listing price and not the spot market cap.
### Three Multiplier Approaches
| Approach | Formula | When it applies |
|---|---|---|
| **1 — P/S simple** | M = peer P/S | Optimistic: peer-mature state 5+ years out |
| **2 — Capture × Multiple** | M = capture_rate × peer_payback_years | **Default:** baseline for an emerging project |
| **3 — DCF Gordon** | M = capture_rate × (1+g) / (r − g) | Pessimistic: spot valuation without peer effect |
Default parameters (calibrated against the five exchange-token references and the six RWA-tokenization peers): `capture_rate` = 10% (5% pessimistic / 20% optimistic), `peer_payback_years` = 9.7 (a best-estimate window, not a clean peer median: among the five exchange-token references BNB and LEO keep revenue closed-book, INJ's on-chain revenue is ambiguous across fee layers, and HYPE's FDV/revenue ratio is an extreme outlier excluded rather than blended in), `r_investor` = 25% (Damodaran ERP + early-stage tech β + crypto risk premium), `g_perpetuity` = 10% (crypto super-cycle assumption; mainstream DCF uses 3–5%, which would roughly halve M_revshare on the DCF Gordon path). Discount and yield multipliers come from a different formula—locked-value inversion. On default parameters: M_revshare ≈ 0.97, M_discount ≈ 3.50, M_yield ≈ 1.40 (yield-block multiplier from a synthetic-dividend formula: payout_rate × yield_uplift × payback, tier-mix-blended).
### FDV by Concept
We compute FDV per product (revenue × M for that product's utilization model) and sum across products in the concept, then discount from 2028 to 2026 at 40% p.a. (1.96× over two years).
**Concept A** runs all 13 products through one consolidated revshare pool. At default capture (10%), the three approaches give M = 0.73 (DCF Gordon) / 0.97 (Capture × Multiple) / 9.70 (P/S simple, peer-mature). Pessimistic capture (5%, same g and r) halves the DCF Gordon path to M = 0.37 (0.05 × 1.10 / 0.15)—capture enters the formula linearly, so cutting it from 10% to 5% halves M from the 0.73 default. Picking a baseline depends on (a) where the CFO positions capture rate and (b) whether the team underwrites peer-mature or emerging-spot. **Advantage**: launch doesn't require mature revenue—distribution begins with the first dollar earned.
**Concept B** covers 11 products through discount or yield (the L1 and B2B wholesale are excluded as institutional flows). The discount block dominates B's FDV; the yield block is smaller in absolute terms but provides a stable floor—yield uplift on savings ties to a measurable APY differential, not a behavioral discount.
| Scenario | Discount block | Yield block | Total FDV |
|---|---:|---:|---:|
| Conservative | 1.0x | 0.13x | ~1.13x |
| **Default** | **1.86x** | **0.13x** | **~2.0x** |
| Optimistic | 5.3x | 0.31x | ~5.6x |
(Indices relative to the conservative discount-block baseline.)
**Concept C** covers only the institutional flow through the L1. Two open questions sit on top of C's FDV: the hybrid-methodology gap (a discount-only calculation gives a lower bound; the hybrid target requires Stage-2 development), and the B2B attribution question (100% under C vs 50% swings the FDV by ~50%). C's FDV in Stage 1 is the smallest of the three by a wide margin—a function of narrow product attribution, not weak unit economics. If B2B verifies and the hybrid lands, C can move materially closer to A.
The two parameters that move FDV most: **capture rate** (5% → 20% = 4× swing on Concept A; depends on the *quality* of the buyback formula—transparent vs discretionary—more than on the magnitude), and **discount depth** (25% → 50% = 2× swing on Concept B; raises FDV but compresses unit economics).
## Reference Tokens: Three Findings That Shaped the Concept Menu
We deep-dove five exchange-token references—BNB (2017), LEO (2019), INJ (2021 mainnet), KAIA (2024 rebrand), HYPE (2024)—across 21 design axes and built a "mechanics card" for each. Three findings:
**1. Design changed sharply across launch epochs.** Pre-DeFi tokens (LEO, BNB) maximized whale retention through fee discounts and partially-verified buybacks. Post-DeFi tokens (HYPE, INJ) emphasized on-chain transparency, multi-layer utility, and community-first distribution. The 2024 template (HYPE: 31% airdrop, ~97% of fees to buyback, on-chain verifiability) is more credible to a 2026 investor but requires roughly 2× operational transparency. For an emerging-market exchange, the 2024 template is the credibility floor, not the ceiling.
**2. Reversibility is a real design property.** The best designs survive removal of any single mechanic. The worst collapse: when WazirX was hacked in 2024 and WRX was delisted from Binance, the buyback narrative collapsed alongside the platform. We pushed Concept A toward A.2 (Real Yield + tier) over pure A.1 specifically because the tier provides a second value layer that doesn't break if the buyback formula is paused.
**3. Verifiable formula > generous formula.** A "≥27% of revenue to buyback" headline (LEO) means little if the revenue figure is closed-book and the buyback isn't on-chain. A 60–70% on-chain commitment beats a 90% off-chain promise.
For Concept C, six RWA-tokenization peers (Sky, ONDO, PENDLE, CFG, OM, PLUME) anchored capture rates: Sky (SKY, formerly MKR) ~10–15% (range varies by period and methodology) as the mature mid-point, PENDLE ~80% as the high end, ONDO 0% as governance-only. Our default 10% capture for Concept A sits at the conservative end of that range. OM (Mantra) is named for context only, not as a clean capture-rate reference—it crashed ~90% in a single day in April 2025 amid market-manipulation allegations.
## Stakeholder Architecture: Why Retail Is Not One Cohort
The retail base in this market doesn't fit a "trader / non-trader" split. It splits into eight archetype classes by *motive*, not by wallet size. The full archetype framework—motivation, horizon, sell-pressure model—is in [stakeholders]({{< relref "basics/stakeholders" >}}). The case-specific partition for token design:
- **A-class (active speculators):** churn 60%+, mercenary; respond to volume rebate and launchpad quotas (B.3).
- **B-class (DCA holders, yield-savers):** the largest underserved layer in this market; respond to APY uplift and reliability, not fee discounts (B.1).
- **C-class (currency users—P2P switchers, remittance recipients):** retention loop is "spend without converting back to cash"; gambling-style loyalty actively *hurts* their retention (B.1, B.2).
- **E-class (institutional, OTC):** large average ticket, small base; the entire customer set for Concept C.
- **F-class (token holders, VC):** financial alignment, no platform usage; the entire customer set for Concept A.
One-size-fits-all loyalty would have served maybe a quarter of the retail base. The three B-variants exist because the leading metric differs: depth of cross-product penetration in B.1, conversion of remittance recipients into card spenders in B.2, net margin per dollar of volume in B.3.
## What Stage 1 Did Not Decide
A Stage 1 that pretends to decide everything is dishonest. We left four explicit decision points open: which concept (A/B/C) management commits to; for A, pure Real Yield vs Real Yield + tier (depends on legal opinion); for B, which variant leads (depends on product roadmap); for C, the hybrid-methodology question (requires Stage-2 modeling and a peer-data refresh). All four are bottlenecked on inputs we don't have at end of Stage 1: legal opinion, roadmap commitments, B2B verification, methodology development.
## Lessons Learned
{{< checklist title="What worked" type="check" >}}
Range, not point—when two assumptions carry ~half of the revenue base, the headline must be a range. A single point would have hidden the spread inside the multiplier discussion.
Per-direction sanctions haircut—a single regional coefficient mis-prices every direction. Per-direction, calibrated by smaller-market share of regional TAM, is defensible line by line.
Three concepts, not one—a multi-product fintech serves three structurally different stakeholder sets. A single-concept deliverable would have forced management to pick the wrong one for two of three.
Sizing first, token second—token design follows revenue mix. Inverting the sequence produces brittle launches that break on the first revenue surprise.
Hybrid-utilization methodology is incomplete—Concept C runs discount and revshare on the same product simultaneously. Standard formulas don't compose; lower-bound calculations are defensible, the target FDV requires Stage-2 development.
Cashback in the native token compounds price pressure—if a meaningful share of cashback is paid in the native token, recipients convert and sell. Either model the conversion behavior explicitly or pay cashback in the stablecoin.
Bonding curve as primary supply model is novel—it fits Concept A naturally, but no exchange-token reference uses it. The first mover takes the credibility risk.
Three retail variants need three product roadmaps—B.1 / B.2 / B.3 share program plumbing but need different leading products at TGE. Picking B without committing to which variant leads is half a decision.
Multi-product fintech, not single-venue exchange—the framework is overkill for a pure spot CEX. It earns its complexity when revenue spans 5+ structurally different product lines.
Emerging market with regulatory & geographic nuance—per-direction haircuts and load-bearing unverifieds are emerging-market problems.
Multi-stakeholder token (retail + institutional + L1)—if the token has to serve only one stakeholder set, a single concept is enough.
Pre-TGE Stage 1, not in-flight—the three-concept menu is a leadership-decision tool. Once a concept is locked, Stage 2 narrows to one of three.
{{< /checklist >}}
{{< cta title="Need a Stage 1 token framework for a multi-product platform?" text="We design tokenomics for fintechs and exchanges with complex product surfaces and multi-stakeholder bases. 40+ projects in our portfolio." button="Get in touch" link="/quote/" >}}
---
## Case Study: Perpetual DEX Tokenomics
- URL: https://giantslabs.pro/cases/perp-dex-tokenomics/
- Section: cases
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: Full tokenomics model for a perpetual DEX: allocation, vesting, fee structure, staking, market model, and treasury. Embedded Google Sheets with 15 tables.
## The Challenge: Designing Tokenomics for a Perpetual DEX
Perpetual futures are the largest segment of decentralized derivatives by trading volume: monthly volume on perp DEXs reached $1.36T at its October 2025 peak, though it has since cooled to ~$700B by early 2026. Most of this volume is concentrated among a few protocols, each solving the same problem: **how to design a token that simultaneously attracts traders, retains liquidity, and generates sustainable cash flow**.
The market is highly concentrated: by April 2026, Hyperliquid's share of segment volume was estimated at roughly 30–70% depending on methodology, with edgeX, Grvt, Aster, and Lighter among the next largest venues by volume, alongside earlier pioneers dYdX and GMX. Each took a different path to cold-start liquidity and incentive design — Hyperliquid runs an on-chain orderbook on its own L1, GMX uses isolated GM-style pools per market (V2), Aster and Lighter leaned heavily on points and airdrops — and those choices set the benchmark we designed against.
A team building a multichain perp DEX with up to 100x leverage and liquidity aggregation from centralized venues approached us. The challenges at launch:
- **Cold-start liquidity** — without volume there are no traders, without traders there is no volume
- **Sell pressure from airdrops and marketing** — a standard problem for any token with a large community allocation
- **Competition for stakers** — the DeFi market is saturated, and staking yield must be competitive without excessive inflation
- **Funnel unit economics** — conversion from lead to paying trader is ~1%, requiring precise CAC and LTV calculations
Below is the full model we built: from allocation to scenario analysis. All tables are live, from the working Google Sheets model.
{{< callout title="Anonymization note" type="info" >}}
All numbers in the model have been modified: proportions and mechanics are preserved, absolute values are not. The project name, token ticker, and partners are not disclosed.
{{< /callout >}}
## Model Overview: Key Metrics
Before diving into details — a high-level view. The model consists of 13 linked sheets: from the user funnel to treasury P&L. Key parameters: 1B token supply ($PERT), fees of 0.036%/0.04% (native token/stablecoins), marketing budget from $5,000/month.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1791337605" range="A1:K15" height="350" title="Key metrics: acquisition, revenue, cash flow" >}}
## Allocation: 9 Categories
[Allocation]({{< relref "models/allocation" >}}) is the model's foundation. We distributed supply across 9 main categories, balancing capital raising, growth incentives, and long-term sustainability.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="879003518" range="A7:H28" height="500" title="Token distribution by category" >}}
Three principles shaped the structure:
**1. Sale rounds — 25%.** Seed (12.5%, TGE unlock 4%), Community/Launchpads (8.75%, TGE 15%), KOL Round (3.75%, TGE 10%). Three rounds instead of two — to spread sell pressure over time and create different price entry points. Note: 12.5% seed allocation is above average (typical 5–10%) — a deliberate choice to secure larger strategic investors early.
**2. Marketing and ecosystem — 31.5%.** The largest category. This funds trading competitions, loyalty programs, and an integration grant fund. Not to be confused with airdrops — that is a separate line item (5%).
**3. Liquidity — 15%.** For a perp DEX, deep order book liquidity from day one is critical. These tokens go to market making and liquidity pools on DEXs and CEXs.
The remaining 23.5% is split across Team (15.5%), Advisors (3%), and Reserve fund (5%) — detailed in the vesting schedule below. All nine categories sum to 100% of supply; the per-line breakdown is visible in the embedded allocation table.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1608998576" range="A4:H22" height="500" title="Allocation visualization" >}}
{{< callout title="Why 9 categories" >}}
Early versions of the model had 5 categories: staking, airdrops, and marketing were combined. We separated them because each has its own vesting logic and target audience. An airdrop with 60% TGE unlock cannot sit in the same bucket as a marketing budget that vests over 34 months.
{{< /callout >}}
## Vesting: Differentiated Approach
Vesting is the primary tool for managing sell pressure. For each category, we set separate parameters: TGE unlock, cliff, duration, and type.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="879003518" range="A30:G45" height="400" title="Vesting parameters by category (cliff and duration)" >}}
Key decisions:
**Team: 15% TGE, 4-month cliff, custom schedule (17% every 4 months over 20 months).** A deliberately aggressive approach: instead of the industry-standard 0% TGE / 6–12 month cliff / 3–4 year vesting, this model front-loads team liquidity. 15% unlocks immediately (launch bonus), the rest in stepped tranches over 24 months total. This is a conscious trade-off: faster team liquidity in exchange for higher investor scrutiny. Standard practice would suggest a 3+ year vesting for stronger alignment signals.
**Airdrops: 60% TGE, 1-month cliff, 2-month vesting.** Intentionally aggressive unlock. The airdrop is a viral growth tool. If you force airdrop recipients to wait a year, they simply move to a competitor. Better to release quickly and capture volume in the first weeks.
**Marketing and ecosystem: 4% TGE, 2-month cliff, 34-month vesting.** The longest vesting — a steady stream of funds for user acquisition and ecosystem development over three years.
### Unlock Dynamics
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="879003518" range="A85:H119" height="550" title="Cumulative token unlock by category" >}}
The chart shows three phases:
- **Month 0–6:** rapid growth from airdrops (60% TGE) and Community round (15% TGE)
- **Month 6–24:** gradual growth as team (stepped) and seed investors (linear over 24 months) unlock
- **Month 24–48:** flat curve, remainder is marketing and reserve fund
{{< formula math="Sell_pressure(m) = SUM(Unlock_i(m) × Sell_rate_i)" >}}
- Sell_pressure(m) — estimated tokens sold on market in month m (computed, in tokens)
- Unlock_i(m) — unlock for category i in month m
- Sell_rate_i — estimated sell share (shown for key categories): seed ~70%, team ~5%, airdrop ~90%, marketing ~30%, KOL ~60%, community round ~40%, liquidity ~10%, advisors ~15%, reserve ~5%
- Peak pressure: month 1 (airdrops 60% TGE + Community round 15% TGE)
{{< /formula >}}
## Revenue Model: From Volume to Revenue
A perp DEX earns from three sources: trading fees, funding rate commissions, and liquidations. We modeled month-over-month growth from $5M daily volume at launch to $500M within two years.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1665192355" range="A71:H128" height="550" title="Trading fees, liquidations, funding rate, and B-book" >}}
The model builds revenue bottom-up: from user distribution by cohort through average balance, leverage, and trade frequency — to trading volumes, then to fees.
Four revenue sources:
- **Trading fees** (0.036% when paying in native token / 0.04% in stablecoins)
- **Liquidation fees**
- **Funding rate commissions**
- **B-book revenue** (order flow internalization)
### Fee Structure: 5 Tiers
The discount fee model is standard for perp DEXs. The higher the 30-day volume, the lower the fee. An additional discount for staking the token.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1665192355" range="A129:H160" height="520" title="Revenue distribution: stablecoins and native token" >}}
Two features that distinguish our model:
**Discount for native token payment.** The fee when paying in native token (0.036%) is lower than in stablecoins (0.04%) — this creates an economic incentive to buy and hold the token. A 10% discount is a meaningful argument for active traders.
**B-book as an additional source.** The model includes revenue from order flow internalization — where the protocol's market maker acts as direct counterparty to trades instead of routing to external liquidity. This is controversial (conflict of interest: the protocol profits when traders lose) but widespread in early-stage DEXs with thin order books. Risk: reputational damage if users discover adverse execution, and potential regulatory scrutiny as DeFi regulation tightens.
## Users: 4 Cohorts
Perp DEX unit economics depends heavily on who is trading. We identified four cohorts by account balance.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1665192355" range="A9:H25" height="400" title="Paying user distribution by cohort" >}}
The model builds a complete funnel: marketing budget → leads (paid + 10% organic) → user conversion (10%) → wallet connection (10%) → conversion to paying users. Each stage has its own inputs and targets.
Key observation: **lead acquisition cost is $0.50, but conversion to paying user is only 1%** (10% × 10%). This means CAC of ~$50, requiring high LTV from active traders.
The 1% figure is not a worst-case assumption — it sits within the typical 0.5–2% lead-to-paying-user range we have observed across 40+ tokenomics engagements. Best-in-class venues (Hyperliquid, dYdX) reach 2–3% on the back of strong brand and referral programs, and warm CEX traffic can hit 5%, but for a cold-start protocol 1% is a realistic target rather than an optimistic one.
{{< callout title="Retention is the Achilles' heel" type="warning" >}}
30-day retention at launch is modeled at 20% — already above typical DeFi trading platform benchmarks (5–15%). By M24, the model targets 40% through staking, loyalty programs, and fee reductions. This 2x retention growth is an optimistic but achievable assumption, contingent on sustained product differentiation and competitive fee structure.
{{< /callout >}}
## Staking: From Emission to Real Yield
The staking model serves two purposes: reduce circulating supply (lower sell pressure) and create a sustainable income source for holders.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1720587494" range="A72:H120" height="520" title="Staking model: participation by category and yield" >}}
The model breaks down staking across five holder groups: investors, marketing, team and advisors, reserve and liquidity, other. Each group has a different staking participation rate — and they differ: investors stake more actively (it's profitable), while marketing tokens are staked less frequently (they're needed for operations).
{{< formula math="Staking_rewards(m) = Staked_tokens(m) × APY(m) / 12" >}}
- Staking_rewards(m) — tokens distributed as staking rewards in month m (computed)
- Staked_tokens(m) — total staked tokens across all categories in month m
- APY(m) — set as an input parameter, can vary month by month
- Note: division by 12 assumes simple interest (no compounding within the month). For compound: monthly_rate = (1 + APY)^(1/12) − 1
- The drift between simple and compound monthly rate scales with APY: ~4.5% at 10% APY, ~13% at 30%, ~21% at 50% (simple monthly distribution overpays vs 12 × compound_monthly)
{{< /formula >}}
The model also calculates token buyback: a portion of stablecoin revenue is converted to native tokens on the market. Cumulative buyback volume and share of total supply are key metrics for assessing deflationary pressure.
## Market Model: AMM Pricing
The model uses Uniswap v2 mechanics (constant product, x·y=k) to simulate token price on the open market. This shows how token and stablecoin flows affect the exchange rate.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="799696276" range="A7:H78" height="550" title="Market model: stabilization and liquidity flows" >}}
Key stabilization mechanisms:
- **Min/max price corridor** — if price breaches the range, the treasury intervenes
- **Stablecoin flows into the pool** — token buybacks, stabilization injections
- **Native token flows** — vesting, treasury sales, stabilization
AMM pool formula:
{{< formula math="x × y = k" >}}
- Buying tokens: x decreases, y increases → price rises
- Selling tokens: x increases, y decreases → price drops
- k is recalculated when liquidity is added or removed
{{< /formula >}}
### Treasury: Buyback, Burn, Sell
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="962102501" range="A9:H47" height="450" title="Buyback, burn, and sell mechanics" >}}
The treasury manages three flows:
- **Buyback** — a portion of stablecoin revenue goes to market token purchases
- **Burn** — a percentage of net token flow is destroyed, reducing supply
- **Sale** — the treasury can sell a portion of tokens to fund operations
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="962102501" range="A49:H98" height="500" title="Full treasury P&L in stablecoins" >}}
The model details all cash flows: inflows (stablecoin fees, token sale proceeds) and outflows (COGS, marketing, OPEX, team salaries, tokenomics expenses). Net cash flow and cumulative treasury balance are the key sustainability metrics.
## Token Demand: Fee Payment and Buyback
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1720587494" range="A26:H62" height="450" title="Native token fee payment and user demand" >}}
The model calculates what share of fees is paid in the native token (across four types: trading, liquidation, funding rate, B-book). This creates natural token demand: traders buy it on the open market to pay fees at a discount.
{{< gsheet id="1YdPOmuSH2V4bmRGgFY3dNUfpj4dfg-ExEUn5dRJmDk0" gid="1608998576" range="A126:H135" height="400" title="Native token price dynamics" >}}
{{< callout title="Key model insight" type="info" >}}
The combination of staking, native token fee payment, and burn mechanics creates multi-layered demand that offsets vesting sell pressure.
{{< /callout >}}
## Lessons Learned
{{< checklist title="What worked" type="check" >}}
Differentiated vesting — 9 categories with different schedules allowed month-by-month pressure management, not "everyone unlocks at once"
Aggressive airdrop (60% TGE) — generated a volume spike in the first two weeks, attracting market makers
End-to-end financial model — from user acquisition to treasury P&L in one model, 13 linked sheets
AMM pricing model — Uniswap v2 mechanics (x·y=k) for token price forecasting based on liquidity flows
Staking by holder category — different participation rates for investors, team, and marketing produce realistic forecasts
Client-side compression lowers the bar for nodes — nodes store and deliver but don't process data. This makes infrastructure cheaper
Small TGE unlock (1.7% market) — minimal price pressure at listing, long vesting for all participants
Telegram as distribution channel — integration with a messenger of 1B+ users reduces CAC
{{< /checklist >}}
The key lesson: in infrastructure projects, 50%+ of supply should go toward incentivizing real network work, not marketing or investors. If nodes don't operate — there's no storage, and the token is worthless.
{{< cta title="Designing tokenomics for an infrastructure project?" text="We build models for storage protocols, L1/L2 networks, validator systems, and other infrastructure." button="Get in touch" link="/quote/" >}}
---
## Case: NFT as a Resellable Subscription
- URL: https://giantslabs.pro/cases/nft-subscription/
- Section: cases
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: NFT subscription with a secondary market: time-decay pricing, royalties, resale economics. Formulas, scenario analysis, and interactive calculator.
The subscription model is the backbone of monetization for SaaS, media, and educational platforms. But traditional subscriptions have two shortcomings: users can't resell unused time, and the platform loses organic inflow — new users only come through marketing, not through a secondary market. NFT subscriptions solve both problems while adding a third benefit: protocol royalties on every resale.
## Context: The Traditional Subscription Problem
An online learning platform sells course access via subscription. Monthly subscription: $30, annual: $300 (equivalent to $25/month). Audience: 50,000 active subscribers, churn rate 8% per month (within the typical range for edtech B2C subscriptions; industry benchmarks: 5–10%).
Three problems:
1. **Non-refundable subscription.** A user pays for a year, finishes the course in 3 months — the remaining 9 months go to waste. This reduces conversion to annual plans
2. **High churn.** 8%/month is standard for edtech, but each departing user means lost LTV and costs to acquire a replacement
3. **No viral mechanism.** Users don't pass subscriptions to others. Every new customer comes through paid acquisition
Goal: **convert the subscription to NFT** to create a secondary access market and generate protocol revenue from resales.
## Solution: NFT Subscription with Time-Decay
### Architecture
The subscription is issued as an NFT (ERC-721 with custom expiration logic; alternatively, ERC-4907 — the rental NFT standard with built-in `expires` — is purpose-built for time-bound access) with three key parameters:
| Parameter | Description | Value |
|---|---|---|
| `accessDuration` | Total access period | 365 days |
| `mintTimestamp` | Mint date | Purchase moment |
| `expiresAt` | Expiration date | mintTimestamp + accessDuration |
The NFT grants full platform access until `expiresAt`. After expiration, the NFT remains as a collectible artifact (alumni badge), but access terminates. The badge itself retains value: social proof of course completion, eligibility for future airdrops or perks, and in some designs, governance rights over platform decisions.
### NFT Subscription Lifecycle
1. **Mint (primary sale).** User purchases the NFT on the platform website for $300 (or stablecoin/token equivalent). Platform receives 100% of revenue
2. **Usage.** User gets course access. Each day, the subscription's "residual value" decreases
3. **Resale.** User lists the NFT on a secondary market. Buyer gets access for the remaining term
4. **Royalty.** Platform receives a % from every secondary sale
5. **Expiration.** NFT expires, access terminates
### Time-Decay Mechanics
The fair price of an NFT on the secondary market is determined by the remaining access period:
{{< formula math="P_secondary = P_0 × (T_remaining / T_total)" >}}
- P_0 — mint price (primary sale)
- T_remaining — remaining access time
- T_total — full subscription period
- P_secondary — fair secondary market price (computed)
{{< /formula >}}
A user purchased an annual subscription for $300. After 6 months:
{{< formula math="P_secondary = $300 × (182 / 365) ≈ $150" >}}
- Fair secondary price after 6 months: ~$150 (50% of mint)
{{< /formula >}}
In practice, prices can deviate from linear decay:
| Scenario | Price vs formula | Reason |
|---|---|---|
| New popular course | Higher | Increased demand for access |
| Holiday period | Lower | Less need for learning |
| NFT scarcity (limited edition) | Higher | Speculative premium |
| Alternative platform discounts | Lower | Competition with primary sales |
{{< callout title="Why buy secondhand instead of new?" >}}
The secondary market attracts users who need **short-term access**. Instead of $300 for a year, they can buy an NFT with 3 months remaining for ~$75. The platform gains a new user without marketing spend + royalties from the transaction.
{{< /callout >}}
## Economic Model
### Baseline: Traditional Subscription
A platform with 50,000 subscribers, annual subscription $300, churn 8%/month:
| Metric | Value |
|---|---|
| Annual recurring revenue (ARR) | $15M |
| Monthly churn | 4,000 users |
| Customer acquisition cost (CAC) | $50 (representative for consumer edtech; B2B or premium platforms typically see $200–$500+) |
| Churn replacement costs | $2.4M/year |
ARR is based on annual subscriptions: 50,000 × $300 = $15M. All revenue comes from one source: primary sales. A departing user is a pure loss.
### What Changes with NFT
NFT subscriptions add **two new revenue streams** to primary sales:
**1. Royalties from resales.** Every secondary market transaction earns the platform a commission. A user sells their subscription — the platform collects 7.5% of the sale price.
**2. Renewals from secondary buyers.** A user buys a subscription on the secondary market, uses it for 6 months, is satisfied — buys a new NFT for the next year. The platform acquired a new customer without marketing spend.
### Example: Where the Numbers Come From
Assumptions for the calculation:
| Parameter | Value | Rationale |
|---|---|---|
| Resale rate | 30% of subscribers | Some users finish learning before the year ends |
| Average holding period | 6 months | The average user resells at the midpoint |
| Average secondary price | $150 | Linear decay: $300 × (6/12) = $150 |
| Royalty rate | 7.5% | Balance between revenue and market liquidity |
| New user share | 20% of base | Not all secondary buyers are new to the platform |
| Renewal conversion | 60% | Share of secondary buyers who renew their subscription |
**Step-by-step calculation:**
1. **Resales:** 50,000 × 30% = 15,000 transactions/year
2. **Royalties:** 15,000 × $150 × 7.5% = **$169K**/year
3. **New users via secondary:** 15,000 × 20% = 3,000 people (20% of resale buyers are new to the platform)
4. **Renewals:** 3,000 × 60% × $300 = **$540K**/year
5. **CAC savings:** 3,000 × $50 = **$150K**/year (new users acquired without marketing spend)
### Summary Comparison
| Metric | Without NFT | With NFT | Delta |
|---|---|---|---|
| Primary sales | $15M | $15M | — |
| Royalties from secondary | — | $169K | +$169K |
| Renewals from secondary buyers | — | $540K | +$540K |
| Acquisition cost savings | — | $150K | +$150K |
| **Total** | **$15M** | **$15.86M** | **+5.7%** |
Note: the worked example above and the interactive calculator below use two different methodologies, not one reconciled model. The text is an illustrative, additive walkthrough; the calculator implements a fuller net model that accounts for cannibalization (secondary buyers replacing some primary minters) and separate CAC for NFT vs traditional subscriptions. Their totals won't match—the calculator's default inputs give +7.2% net uplift vs. +5.7% in the text, and the CAC savings line alone differs by roughly 7×: $150K in the text vs. ~$1.09M in the calculator, because the calculator nets CAC across all 47,000 minters rather than just the 3,000 new users from secondary. Treat each as a separate illustration of the same mechanism, not two calculations of the same number.
{{< callout title="Why +5.7% and not more?" >}}
NFT subscriptions aren't a revenue revolution — they're a **structural improvement**: reduced churn, organic inflow through the secondary market, an additional royalty stream. The main value isn't in the percentage — it's in the fact that a departing user stops being a loss.
{{< /callout >}}
## Scenario Analysis
### Scenario 1: High Demand (Bull Market)
- Secondary prices **above** linear decay (20–30% premium)
- Royalty income grows proportionally
- Limited edition NFTs create speculative demand
- Risk: users buy NFTs for resale, not for learning — support burden increases
### Scenario 2: Normal Demand
- Secondary prices match linear decay
- Secondary market operates as a **seasonal exchange**: departing users sell, arriving users buy
- Royalties — a stable additional stream
- Churn reduction through the option to sell instead of cancel
### Scenario 3: Low Demand (Bear Market)
- Secondary prices **below** linear decay (20–40% discount)
- Royalty income is minimal
- Secondary market competes with primary sales
- Risk: cannibalization — new users buy cheap NFTs on the secondary market instead of minting new ones
{{< callout type="warning" title="Anti-cannibalization" >}}
To prevent the secondary market from destroying primary sales: (1) primary NFTs include a bonus (welcome package, exclusive content) unavailable on secondary purchase; (2) mint price is cheaper than buying "almost new" NFT on secondary (due to royalties and marketplace margin).
{{< /callout >}}
## Parameter Design
### Royalty Rate
| Royalty | Platform impact | Secondary market impact |
|---|---|---|
| 2.5% | Minimal revenue | Maximum secondary market liquidity |
| 5% | Moderate revenue | Healthy balance |
| 7.5% | Meaningful revenue | Slightly wider spreads, but market stays active |
| 10% | High revenue | Reduced liquidity, growing bid-ask spread |
| 15%+ | Maximum revenue | Secondary market may die |
Recommended range: **5–10%**. Above 10%, the secondary market becomes unprofitable for sellers (the "tax" on resale is too high).
### Subscription Duration
| Duration | Primary price | Secondary market appeal |
|---|---|---|
| 1 month | $30 | Low (too little time for resale) |
| 3 months | $80 | Medium |
| 6 months | $160 | High (convenient duration for secondary) |
| 12 months | $300 | Maximum (more residual value for resale) |
These prices bake in a volume discount for longer commitments: per-month cost drops from $30 (1 month) to $26.7 (3 and 6 months) to $25 (12 months), rewarding buyers who commit to a full year while keeping the entry tier accessible. The calculator below only models the 12-month, $300 tier: its "holding period" slider represents months elapsed within that single 12-month term, not a switch between these four duration options.
Optimal: **6–12 months**. Short subscriptions don't create sufficient incentive for the secondary market.
### Limited Editions
Limited NFT subscription runs (e.g., 1,000 units) create scarcity and a speculative premium. But this only works with high demand. In low demand, the limit turns into lost potential customers.
**Compromise:** unlimited main edition + limited series with extra perks (VIP access, priority support, content governance participation).
## NFT Subscription Calculator
### How to Use
- Set the number of new subscribers per year and the NFT mint price
- Adjust the resale share and royalty rate
- Specify the average NFT holding period and secondary buyer renewal rate
- Set CAC for traditional and NFT subscriptions for comparison
- The calculator compares traditional subscription revenue with the NFT model: primary sales, royalties, renewals, and acquisition savings
- The table shows a detailed breakdown by metric and the difference between models
Traditional vs NFT Subscription Comparison
Net uplift
+0%
Total NFT model
$0
New from secondary
0
Metric
Traditional
NFT subscription
Difference
Calculator formulas
{{< formula math="NFT_Revenue = Primary_sales + Royalties + Renewal_revenue" >}}
- NFT_Revenue — total NFT model revenue, shown as "Total NFT model" and the NFT bar in the chart above (computed)
- Primary_sales — revenue from primary NFT sales ($)
- Royalties — revenue from secondary market royalties ($)
- Renewal_revenue — revenue from subscription renewals by secondary buyers ($)
{{< /formula >}}
{{< formula math="Royalties = Resales × Avg_secondary_price × Royalty_rate" >}}
- Royalties — royalty income (computed)
- Resales — number of resales on the secondary market
- Avg_secondary_price — average NFT resale price ($)
- Royalty_rate — royalty rate (share of resale price, from 0 to 1)
{{< /formula >}}
{{< formula math="Uplift = NFT_net / Traditional_net − 1" >}}
- Uplift — how much more profitable the NFT model is vs traditional subscription (computed)
- NFT_net — net NFT model income: NFT_Revenue − NFT_CAC ($) (computed)
- Traditional_net — net traditional income: Traditional_total − Traditional_CAC ($) (computed)
{{< /formula >}}
{{< formula math="CAC_savings = Subscribers × CAC_traditional − Minters × CAC_nft" >}}
- CAC_savings — acquisition cost savings (computed)
- Subscribers — number of subscribers per year
- CAC_traditional — acquisition cost under traditional subscription ($)
- Minters — number of users minting NFTs (computed)
- CAC_nft — acquisition cost under NFT subscription ($)
{{< /formula >}}
{{< formula math="New_from_secondary = Resales × 0.20" >}}
- New_from_secondary — number of new users acquired via secondary market (computed)
- Resales — number of resales (Subscribers × Resale_rate)
- 0.20 — share of secondary buyers who are new to the platform (20%, fixed model parameter)
- Sensitivity: this fixed 20% share is the single most influential assumption without a slider. Halve it (10%) and new users plus renewal revenue roughly halve too; double it (40%) and they roughly double. Treat every other calculator output as conditional on this assumption holding
{{< /formula >}}
{{< formula math="Avg_secondary_price = Mint_price × (12 − Hold_months) / 12" >}}
- Avg_secondary_price — average NFT price on the secondary market (computed)
- Mint_price — primary mint price ($)
- Hold_months — average NFT holding period (months)
- Logic: the longer the NFT is held, the less subscription time remains, and the lower the resale price
{{< /formula >}}
## Lessons and Patterns
### What Works
1. **NFT subscriptions reduce churn.** A user who can sell instead of cancel doesn't "disappear" — their spot is taken by a secondary market buyer. For the platform, this means a stable active user base
2. **Secondary market = free marketing.** Every resale is a touchpoint with a new user the platform didn't spend CAC to acquire
3. **Royalties — scalable revenue.** As the user base and secondary market activity grow, royalty income scales without additional costs
4. **Linear time-decay — a predictable pricing anchor.** Market participants have a clear fair price reference, which reduces speculation
### Where Caution Is Needed
1. **Primary sale cannibalization.** If the secondary market is too cheap, new users buy used subscriptions instead of new ones. Solution: bonuses for primary buyers
2. **Royalty enforceability.** On some marketplaces, standard ERC-2981 royalties are optional (OpenSea for legacy ERC-721, Blur with minimum 0.5% on immutable collections). Newer standards like **ERC-721C** (Limit Break) enable contract-level enforcement on supporting marketplaces (including OpenSea and Magic Eden as of 2026). Solution: proprietary marketplace, ERC-721C, or contract-level enforcement
3. **Crypto barrier.** Edtech platform users don't necessarily use cryptocurrency. Solution: wallet abstraction (account abstraction), fiat purchase with automatic minting
4. **Regulatory constraints.** NFT subscriptions may be classified as financial instruments in some jurisdictions if the holder can profit beyond the subscription's value
### When NFT Subscriptions Make Sense
{{< checklist title="Implementation criteria" type="check" >}}
Subscription is expensive — cost > $100/year on Ethereum mainnet (gas eats meaningfully into cheap subscriptions); on L2s (Polygon, Base, Arbitrum), where mint/transfer gas is a fraction of a cent, the model stays economical even at $20–50/year
Content updates regularly — access value is sustained over time (not a one-time course)
Audience is technically ready — or the crypto layer can be abstracted away
Secondary market is logical — users genuinely want to resell unused time
Royalties are enforceable — proprietary marketplace, ERC-721C transfer security policies, or contract-level enforcement (ERC-2981 provides royalty info but doesn't enforce collection)
{{< /checklist >}}
## Connection to Utility Models
NFT subscriptions combine several models from the [five demand models]({{< relref "models/demand-models" >}}):
| Model | How it manifests |
|---|---|
| **Ownership** | The NFT represents an access right — a digital asset with standalone value |
| **Payment** | Buying the NFT is a mandatory payment for platform access |
| **Staking/Lock** | Longer subscription duration incentivizes holding NFTs — similar to staking mechanics |
| **Discount** | A bonus tier is possible: holders of multiple NFTs receive a discount |
This confirms the principle: sustainable tokenomics combines at least 2–3 demand models.
{{< cta title="Need an NFT subscription model?" text="We've designed NFT subscription models for edtech, media, and SaaS platforms. We'll calibrate the parameters: duration, royalties, tiers, and secondary market mechanics." button="Get in touch" link="/quote/" >}}
---
## Case: SocialFi Platform Tokenomics — Dual-Token System for Sports Communities
- URL: https://giantslabs.pro/cases/socialfi-platform-tokenomics/
- Section: cases
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: SocialFi platform tokenomics case: 2.1B token distribution, four club tiers, fan funnel, buyback and burn. Unit economics calculator.
Most SocialFi projects build tokenomics around a single action — "buy the token, get access." But in a platform for sports communities, the economics are more complex: you need to simultaneously attract clubs, retain fans, and generate sustainable token demand. This case examines how we designed a dual-layer system — a native platform token + club fan tokens — and why the launchpad became the primary demand driver.
## Context: A Platform for Sports Communities
A SocialFi platform connecting sports clubs with their audiences. Model: each club gets its own fan token, and the platform provides infrastructure — from issuance to trading. Fans use the native platform token to purchase fan tokens, vote, and participate in club activities.
{{< callout title="Two-sided market" type="info" >}}
The platform operates as a marketplace: on one side — clubs that need audience monetization, on the other — fans who want to influence their club. The native token is the "bridge" between them. Without clubs there are no fans, without fans there's no point for clubs.
{{< /callout >}}
Tasks for the tokenomist:
1. **Create demand for the native token** — not speculative, but structural: fan tokens can only be purchased with the native token
2. **Scale club acquisition** — from small (5,000 followers) to large (1M+), with different economics for each tier
3. **Ensure sustainability** — buyback at low prices, fee burning, controlling sell pressure from investors
## Solution: Dual-Token System
The architecture has two layers: a native platform token and individual club fan tokens. Fan tokens are issued through a built-in launchpad and can be acquired **only with the native token** — this is the key demand mechanism.
### Allocation and Vesting
Total supply — 2,100,000,000 tokens, distributed across 9 categories:
| Category | Amount | Share | Cliff + Vesting | Purpose |
|---|---|---|---|---|
| Private Sale | 300M | 14.3% | 6 + 12 months | Early investors |
| Infrastructure Round | 250M | 11.9% | 12 + 12 months | Strategic partners |
| Presale (syndicates) | 30M | 1.4% | 3 + 6 months | Community round |
| Public Sale (IDO) | 5M | 0.24% | 0 + 1 month | Listing |
| Team & Advisors | 420M | 20.0% | 6 + 30 months | Long-term motivation |
| Community | 210.75M | 10.0% | 0 + 60 months | User rewards |
| Treasury | 210.75M | 10.0% | 0 + 36 months | Operational reserve |
| Marketing & Incentives | 400M | 19.0% | 0 + 36 months | Club and fan acquisition |
| Liquidity Pools | 273.5M | 13.0% | 0 + 36 months | DEX liquidity |
| **Total** | **2,100M** | **~100%** | | |
*Percentages rounded individually; totals may not sum to exactly 100%.*
Key decision — **Marketing & Incentives (19%)** as the largest operational category. These tokens go toward acquiring clubs and incentivizing fans. Linear unlock over 36 months provides predictable market pressure: ~11.1M tokens/month.
Sell pressure from investors is modeled through an **instant sell probability** parameter — 50% of each unlock. This is a conservative estimate: half of investors sell upon unlock.
### Club Tiers and Fan Funnel
Clubs are divided into four tiers by audience size. Each tier has its own acquisition cost and expected return:
| Parameter | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| Club audience | 1,000,000 | 100,000 | 25,000 | 5,000 |
| Max count (base case) | 3 | 7 | 8 | 10 |
| Acquisition cost (fiat) | $5,000 | $2,500 | $1,500 | $1,000 |
| Acquisition cost (tokens) | 100,000 | 50,000 | 25,000 | 10,000 |
| FTO probability | 25% | 20% | 15% | 10% |
*Max count reflects the base-case club pool identified at launch; the Optimistic scenario in "Quantitative Analysis: Three Scenarios" below assumes expansion into new leagues and regions beyond this initial set.*
**Fan conversion funnel** — two stages:
{{< formula math="Registered = Audience × 0.3% per month" >}}
- Registered — new registered users (computed)
- 0.3% — conversion from followers to registered users
{{< /formula >}}
{{< formula math="Active = Registered × 2.5% per month" >}}
- Active — users who entered the native token ecosystem (computed)
- 2.5% — conversion from registered to active users
{{< /formula >}}
Monthly churn: 10%. For a Tier 1 club with 1M audience: ~3,000 new registrations/month → ~75 new native token users. Over a year — about 900 unique ecosystem users from a single large club (75 × 12), or ~540 MAU accounting for 10% monthly churn.
## Model: Token Flows and Stabilization Mechanisms
Per-fan token economics:
{{< formula math="Net_balance = Rewards − Spending" >}}
- Month 1: rewards 50 tokens, spending 100 tokens
- Months 2–6: rewards 250 tokens/month, spending 150 tokens/month
- Month 7+: rewards 250 tokens/month, spending 400 tokens/month
- Net balance is negative: the fan spends more than they receive (computed)
{{< /formula >}}
Fans spend tokens on club fan tokens, NFTs, and exclusive content access. Rewards come from activity, voting participation, and referrals. **A negative fan balance is good for the token**: every active user creates net demand, purchasing tokens on the market.
### Three Price Stabilization Mechanisms
{{< checklist title="Price management mechanisms" type="check" >}}
Fee burning — 25% of all internal platform fees (fan token trading, protocol fees) are burned permanently
Buyback — when market price falls below 50% of target, the treasury buys tokens from the market with fiat
Controlled sales — the treasury only sells tokens when the price exceeds 150% of target, avoiding pressure under normal conditions
{{< /checklist >}}
### Fan Token Market as Demand Driver
The primary source of structural demand is the **Fan Token Offering (FTO)**: clubs issue their fan tokens through the platform's launchpad, and purchase is available only with the native token.
FTO parameters by tier:
| Parameter | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| Fan token supply | 50M | 10M | 2.5M | 1M |
| Offering price | $1 | $1 | $1 | $1 |
| Volume raised (via platform) | $5M | $1M | $250K | $100K |
| Guarantee to club | $2.5M | $500K | $150K | $50K |
Volume raised refers to the public sale portion of the FTO (typically 10% of fan token supply); the remainder is allocated to club treasury, liquidity, and vesting.
Platform commission: 80% of the amount above the guarantee. If a Tier 1 club raises $4M through FTO with a $2.5M guarantee — the platform receives 80% × ($4M − $2.5M) = $1.2M.
Trading fees from fan tokens are an additional revenue source: 0.8% of volume for native token pairs.
## Platform Unit Economics Calculator
### How to Use
- Set the number of clubs per tier (from largest Tier 1 to smallest Tier 4)
- Adjust the conversion rate from club audiences to active ecosystem users
- Set the current token price for USDT cost conversion
- The calculator shows MAU, net token pressure, and user acquisition cost
- Details show the full funnel: audience → registration → ecosystem, plus token balance and acquisition costs
SocialFi Platform Unit Economics
Ecosystem MAU
0
Net sell pressure (tokens/month)
0
Platform CAC (USDT)
$0
Calculator formulas
{{< formula math="MAU = Ecosystem_users / Churn_rate" >}}
- MAU — monthly active ecosystem users (computed)
- Ecosystem_users — new ecosystem users per month (computed)
- Churn_rate — monthly user churn (10%, fixed model parameter)
{{< /formula >}}
{{< formula math="Ecosystem_users = Σ(Clubs_tier_i × Fanbase_i × Registration_rate × Conversion)" >}}
- Clubs_tier_i — number of clubs in tier i
- Fanbase_i — average fanbase size for tier i (1M / 100K / 25K / 5K)
- Registration_rate — share of fanbase registering on the platform (0.3%, fixed parameter)
- Conversion — conversion from registered to active ecosystem users
{{< /formula >}}
{{< formula math="Net_sell_pressure = Rewards + Unlock_pressure − Demand − Burn" >}}
- Net_sell_pressure — net monthly sell pressure; positive = inflationary, negative = deflationary (computed)
- Unlock_pressure — investor unlock pressure: ~33,075,000 × 50% sell probability (33,075,000 is the exact month-1 unlock volume across all vesting schedules, used as a conservative proxy for the rest of the 48-month horizon; actual monthly unlock varies from ~28M in months 2–3 to ~72M in months 7–9)
- Rewards — fan rewards: Ecosystem_users × 250 tokens/user (computed)
- Demand — fan demand: Ecosystem_users × 400 tokens/user (computed)
- Burn — 25% fee burn: Ecosystem_users × 400 × 25% (computed)
{{< /formula >}}
{{< formula math="CAC = (Fiat_costs + Token_costs × Price) / Ecosystem_users" >}}
- CAC — cost to acquire one ecosystem user (computed)
- Fiat_costs — fiat acquisition costs across all tiers ($/month)
- Token_costs — token acquisition costs across all tiers (tokens/month)
- Price — current token price (USDT)
- Ecosystem_users — new ecosystem users per month (computed)
{{< /formula >}}
## Quantitative Analysis: Three Scenarios
The model is calculated over a 48-month horizon. Key metric: treasury balance (runway) and net token market pressure.
| Parameter | Pessimistic | Base | Optimistic |
|---|---|---|---|
| Clubs over 4 years | 10 | 28 | 50+ |
| Tier distribution | 0/1/3/6 | 3/7/8/10 | 5/12/15/18+ |
| Ecosystem MAU (year 2) | ~800 | ~5,000 | ~15,000 |
| Treasury EOP year 2 | −$36,000 | +$22,000 | +$174,000 |
| Runway (months) | 18 | 48+ | 48+ |
| Target price year 2 | $0.08 | $0.15 | $0.21 |
{{< callout title="Critical threshold" type="warning" >}}
In the pessimistic scenario, the treasury goes negative at month 18. The breakeven point is at least 15 clubs with active conversion. Below this threshold, the platform doesn't generate enough fiat revenue to sustain operations and buyback.
{{< /callout >}}
The market pricing model uses a simplified Uniswap v2 formula (target prices in the scenario table are exogenous assumptions of the model; the formula below illustrates the pricing mechanism, not a direct derivation of targets):
{{< formula math="P = X / Y" >}}
- P — native token price in USDT (computed)
- X — USDT in the liquidity pool
- Y — native tokens in the pool
- Initial pool: 300,000 USDT / 3,000,000 tokens = $0.10
{{< /formula >}}
Net price pressure is composed of inflows (fan purchases, buyback, speculative demand) and outflows (investor unlocks, reward token sales). In the base scenario, the platform reaches positive treasury balance by month 36 — the point where FTO revenue and trading fees cover operational expenses.
## Lessons Learned
{{< checklist title="What worked" type="check" >}}
Fan token launchpad as demand driver — tying fan token purchases to the native token creates structural demand independent of speculation. Every FTO generates buy pressure
Club tiering — different acquisition costs and expected returns at different scales. Small clubs (Tier 4) are cheap entry for volume growth, large clubs (Tier 1) are anchor partners for credibility
Automatic buyback — price-triggered below target stabilizes the market without manual intervention. The treasury acts as a market maker of last resort
Fee burning (25%) — a deflationary mechanism that scales with platform growth. More fan token trading = more burned
{{< /checklist >}}
{{< checklist title="Points of caution" type="curve" >}}
Dependency on club acquisition — without new clubs there are no FTOs, no demand for the native token. The platform is hard-dependent on B2B sales, not organic growth
Low funnel conversion — 0.3% × 2.5% = 0.0075% from club audience to native token ecosystem. For a club with 1M followers — only ~75 active users per month
Unlock pressure — 50% instant sell on unlock creates constant price pressure in the first 12 months. Buyback doesn't always compensate, especially in the pessimistic scenario
Speculative component — the model assumes 20% of unlocks as speculative demand. If the market is cold, this component zeroes out and net pressure worsens
{{< /checklist >}}
{{< callout title="Market context (2025–2026)" type="info" >}}
The fan token landscape has evolved significantly since this model was designed. Key developments: Chiliz/Socios received **MiCA authorization** in 2025 (first regulated sports fan token platform in the EU), launched **Omnichain Fan Tokens** (Q2 2026) with multi-chain DeFi integration, and introduced **Fan Token Play** — a mint-and-burn mechanic tied to match results. In March 2026, the SEC/CFTC classified fan tokens as digital collectibles (not securities), opening the US market. These developments validate the dual-token SocialFi model while raising the competitive bar for new entrants.
{{< /callout >}}
---
# Section: Validators
## Section landing: Validators
- URL: https://giantslabs.pro/validators/
- Kind: section landing
- Section: validators
- Description: Validator economics: payment models, staking rewards, slashing, and node unit economics.
---
## Validator Payment Models: Economics of PoS Networks
- URL: https://giantslabs.pro/validators/validator-payment-models/
- Section: validators
- Date: 2026-04-16
- Last modified: 2026-04-16
- Description: How validator economics work: reward models (emission, fees, MEV), slashing, delegation. Yield formulas, PoS network comparison, node unit economics.
A validator is a network participant who confirms transactions and maintains consensus. In return, they receive rewards. But how exactly does validator economics work? Where does the money come from, how much does it cost to run a node, and when does validation stop being profitable?
## Three Revenue Sources for Validators
A validator earns from three sources. The ratio between them determines the network's economic sustainability.
### 1. Emission (Inflationary Rewards)
The protocol creates new tokens and distributes them among validators. This is the primary revenue source in most PoS networks at early stages.
{{< formula math="Validator_reward = Block_emission × (Validator_stake / Total_stake)" >}}
- Block_emission — new tokens created per block
- Validator_reward — proportional to the validator's stake share (computed)
{{< /formula >}}
**The problem:** inflationary rewards dilute all holders who don't stake. It's a hidden tax — an incentive to stake, but also price pressure when rewards are sold.
### 2. Transaction Fees
Users pay fees for including transactions in blocks. Part or all of the fee goes to the validator.
| Network | Fee model | Validator's share |
|---|---|---|
| **Ethereum** | Base fee burned (EIP-1559), tips go to validator | Tips only (priority fee) |
| **Cosmos** | Fees split among stakers | Proportional to stake |
| **Solana** | Base fee: 50/50 (burn/validator). Priority: 100% to validator (SIMD-0096, since Feb 2025) | Priority + 50% of base |
| **Polkadot** | Fees to treasury + validators | Fixed share |
**Network maturity:** as activity grows, the fee share of validator income rises while emission's share shrinks. This is a healthy transition: from subsidizing security to paying for actual service.
### 3. MEV — Maximal Extractable Value
MEV is additional revenue a validator can earn by reordering, including, or excluding transactions in a block.
**Types of MEV:**
- **Arbitrage** — validator includes an arbitrage transaction between DEXs
- **Liquidations** — priority inclusion of a liquidation transaction
- **Sandwich attacks** — placing own transactions before and after a large order
{{< callout type="warning" title="MEV and centralization" >}}
MEV creates inequality among validators. Large validators with advanced algorithms extract more MEV, attracting more delegations, which increases their stake — a positive feedback loop leading to centralization. Ethereum addresses this through PBS (Proposer-Builder Separation) and MEV-Boost: block building is separated from block proposing.
{{< /callout >}}
## Reward Models
### Fixed Block Emission
Each block creates an identical number of tokens.
{{< formula math="APR = (Annual_emission / Total_stake) × 100" >}}
- With fixed emission, APR is inversely proportional to total stake (computed)
- More staked → lower APR for each participant
{{< /formula >}}
**Example:** if annual emission is 5M tokens and 50M are staked — APR = 10%. If 100M are staked — APR = 5%. The mechanism self-regulates: high APR attracts more stakers, which reduces APR.
### Target Staking Ratio
The protocol sets a desired staking percentage and dynamically adjusts emission.
{{< formula math="APR = APR_target × (S_target / S_actual)^k" >}}
- S_target — target staked token share (typically 50–67%)
- S_actual — actual share
- k — sensitivity coefficient
- APR rises when staking is low and falls when it's high (computed)
{{< /formula >}}
**Ethereum** uses a variation of this approach: the base reward is inversely proportional to the square root of total stake (`base_reward ∝ 1 / √total_stake`), rather than an arbitrary power function with k. More validators → lower income per validator, but higher network security.
### Cosmos Model: Validator Commission
In Cosmos SDK networks, validators set their own commission — a percentage of delegator rewards.
{{< formula math="Delegator_income = Reward × (1 − Validator_commission)" >}}
- Validator_commission — typically 5–20%
- Validator receives: their own rewards + commission from all delegations
- Delegator_income — net income after commission (computed)
{{< /formula >}}
Competition among validators for delegations:
- Low commission attracts delegators but may not cover expenses
- High commission repels delegators but ensures sustainability
## Slashing: Penalties for Violations
Slashing is a mechanism for punishing validators for malicious or negligent behavior. The validator loses a portion of their staked tokens.
### Violation Types
| Violation | Description | Typical penalty |
|---|---|---|
| **Double signing** | Signing two conflicting blocks at the same height | 5–100% of stake |
| **Downtime** | Missing signatures over an extended period | 0.01–1% of stake |
| **Censorship** | Deliberately excluding transactions | Social slashing |
### Designing Penalties
{{< formula math="Slashing = min(Stake × Slashing_rate, Stake)" >}}
- The penalty must exceed the potential gain from the violation
- But not so large that an accidental failure destroys the validator
- Penalty — tokens lost by the validator (computed)
{{< /formula >}}
Balance: slashing that's too lenient doesn't deter attackers; too harsh — scares away honest operators.
| Network | Double signing penalty | Downtime penalty |
|---|---|---|
| **Ethereum** | 1/32 of stake (min.) + correlation penalty | Gradual balance reduction |
| **Cosmos Hub** | 5% of stake + jailing | 0.01% of stake + jailing |
| **Polkadot** | Up to 100% of stake (proportional to violator count) | No slashing, just no rewards |
| **Solana** | Slashing infrastructure being implemented (SIMD-0204/0212, 2025–2026) | Validator receives no rewards |
{{< callout title="Ethereum's correlation penalty" >}}
In Ethereum, the penalty for double signing scales proportionally to the number of simultaneously offending validators. If one validator makes an error — the penalty is minimal (1/32 of stake ≈ 1 ETH). If a third of all validators violate simultaneously — each loses their entire stake. The logic: a mass violation is likely an attack; an isolated one is likely a glitch.
{{< /callout >}}
## Node Unit Economics
### Validator Expenses
| Expense item | Range | Comment |
|---|---|---|
| **Hardware / VPS** | $50–500/month | Depends on network requirements (Solana > Cosmos) |
| **Bandwidth** | $20–200/month | High-throughput networks require more |
| **Monitoring & maintenance** | $0–100/month | Automation reduces but doesn't eliminate costs |
| **Cost of capital** | Variable | Forgone yield on locked tokens |
### Breakeven Formula
{{< formula math="Stake_min = Annual_costs / APR" >}}
- Stake_min — minimum stake to cover expenses, in dollar terms (computed)
- Annual_expenses — total annual operating costs
- APR — net staking yield (after network fees, if any)
{{< /formula >}}
**Example:** expenses $300/month = $3,600/year. APR = 8%. Minimum stake = $3,600 / 0.08 = $45,000. If token price is $10 — you need at least 4,500 tokens to break even (excluding price volatility).
### Node Economics Comparison by Network
| Network | Min. stake | Server requirements | APR (approx.) |
|---|---|---|---|
| **Ethereum** | 32 ETH | Medium | 2.5–3.5% |
| **Cosmos Hub** | No minimum (needs delegations) | Low | 7–20% |
| **Solana** | No minimum (needs delegations) | High ($400–1,200/month) | 5.5–7% |
| **Polkadot** | Dynamic (via NPoS) | Medium | 8–15% |
| **Avalanche** | 2,000 AVAX | Low | 7–8.5% |
## Validator Yield Calculator
The calculator computes validator economics accounting for three revenue sources: staking rewards, transaction fees, and token price changes.
Validator Yield Calculator
Stake, APR, fees, node costs — annual profit and breakeven point
## Delegation and Liquid Staking
### Delegated PoS (DPoS)
Token holders who don't want to run a node delegate their tokens to a validator. The validator operates on behalf of delegators and takes a commission.
**Delegator risks:**
- Slashing applies to delegated tokens
- Validator may stop operating
- Unbonding period: from 0 to 28 days
### Liquid Staking
Liquid staking solves the locked liquidity problem: the delegator receives a derivative token (stETH, rETH) usable in DeFi while the original remains staked.
**Impact on validator economics:**
- Lowers the barrier to entry for staking
- Increases total stake (improves security)
- But creates systemic risk: if a single liquid staking provider controls >33% of stake — it threatens consensus
{{< checklist title="Designing validator economics" type="step" >}}
Define the target staking ratio (typically 50–67% of supply)
Choose a reward model: fixed emission, target ratio, or hybrid
Calculate node unit economics: do rewards cover expenses at target stake
Set slashing parameters: penalties must deter attackers but not punish accidental failures
Determine the unbonding period: balance between security and convenience
Account for MEV: plan a fair distribution mechanism (PBS, MEV-sharing)
Assess liquid staking's impact on stake concentration
{{< /checklist >}}
{{< cta title="Staking as a utility model" text="Staking is not just validator economics — it's a mechanism for creating token demand. More on staking as a utility model." button="Staking in tokenomics" link="/models/staking/" >}}
---
# Section: Services
## Section landing: Services
- URL: https://giantslabs.pro/services/
- Kind: section landing
- Section: services
- Description: Tokenomics consulting from Giants Labs — design, modeling, audit, and tokenization. Four tracks, one discipline. Drawn from 240+ patterns and 40+ engagements.
- Hero headline: Tokenomics consulting that gets specific
- Hero subtitle: Four tracks: design from first principles, modeling that audits cell by cell, independent review, real-world tokenization. Drawn from a 240+ patterns library and 40+ engagements across DeFi, GameFi, RWA, DePIN, L1/L2, and governance.
---
# Section: Tokenomics design
## Section landing: Tokenomics Design
- URL: https://giantslabs.pro/tokenomics-design/
- Kind: section landing
- Section: tokenomics-design
- Description: Tokenomics design from first principles. Token utility, allocation, vesting, mechanisms, stakeholder incentives, launch strategy — designed against your product, drawn from a 240+ patterns library, every choice defended in writing.
- Hero headline: Tokenomics designfrom first principles
- Hero subtitle: Token utility, allocation, vesting, mechanisms, stakeholder incentives, launch strategy — designed against your actual product, drawn from a 240+ patterns library, every choice defended in writing.
- Deliverables block: What we design
- Deliverables subtitle: Six architectural layers. Each choice tied to a specific stakeholder behaviour or product mechanic. Delivered as a design document structured for three audiences — CMO, CPO, CTO.
---
# Section: Tokenomics modeling
## Section landing: Tokenomics Modeling
- URL: https://giantslabs.pro/tokenomics-modeling/
- Kind: section landing
- Section: tokenomics-modeling
- Description: Working tokenomics models in Google Sheets and xlsx. Unit economics, token demand and supply, market model, P&L, dashboards — every number a formula you can audit.
- Hero headline: Tokenomics models you can audit line by line
- Hero subtitle: Working spreadsheets in Google Sheets and xlsx. Unit economics, token demand, token supply, market model, P&L, and dashboards — every number a formula, every input sourced and dated.
- Deliverables block: What we model
- Deliverables subtitle: Six layers, all connected, every number a formula. Most tokenomics gets sold as a deck — static numbers in slides. We deliver a working spreadsheet you can audit cell by cell.
---
# Section: Tokenomics audit
## Section landing: Tokenomics Audit
- URL: https://giantslabs.pro/tokenomics-audit/
- Kind: section landing
- Section: tokenomics-audit
- Description: Independent tokenomics audits. Six parallel review tracks — claims, market, math, on-chain, mechanism integrity, inputs — every finding tied to evidence and ranked by severity.
- Hero headline: Tokenomics audits that name the actual problem
- Hero subtitle: Independent multi-track review of an existing tokenomics design. Claims, market context, math, on-chain reality, mechanism integrity, inputs — every finding tied to a specific piece of evidence and ranked Critical, High, Medium, Low, or Note.
- Deliverables block: What we audit
- Deliverables subtitle: Six review tracks running in parallel. Every finding tied to specific evidence — a quote from a whitepaper, a cell in a model, a transaction on-chain, a market reference with a date. No vague concerns, no design opinions dressed up as objective findings.
---
# Section: Tokenization
## Section landing: Tokenization
- URL: https://giantslabs.pro/tokenization/
- Kind: section landing
- Section: tokenization
- Description: Bring real-world value on-chain — defensibly. Asset structure, cashflow design, custody and verification model, distribution strategy, regulatory matrix. We design the economic and structural framework; legal counsel and developers implement.
- Hero headline: Bring real-world value on-chain — defensibly
- Hero subtitle: Asset structure, cashflow design, custody and verification model, distribution strategy, regulatory matrix. We design the economic and structural framework that legal counsel and developers can implement without rewriting from scratch.
- Deliverables block: What we design
- Deliverables subtitle: Six parallel tracks — the problems that only emerge when off-chain value has to mirror on-chain.
---
# Section: A2a
## Section landing: A2A Tokenomics
- URL: https://giantslabs.pro/a2a/
- Kind: section landing
- Section: a2a
- Description: Token design for agent-to-agent economies and machine payments. Bounded tokenomics artifacts priced $20–249, x402/AP2 payment-rail design, agent governance with Blockful, and full design engagements.
- Hero headline: Tokenomics for economies where agents pay agents
- Hero subtitle: Design, pricing, and stress-testing for agent-to-agent economies and machine payments. Bounded tokenomics artifacts from $20—priced so a founder with a card and, soon, an agent with a wallet can buy them—up to a full design engagement.
- Deliverables block: What we build and price
- Deliverables subtitle: A new direction, same discipline. Every offer below is a bounded contract: fixed input, fixed output, exclusions declared before payment—not after.
---
# Section: Book
## Section landing: Book a Discovery Call
- URL: https://giantslabs.pro/book/
- Kind: section landing
- Section: book
- Description: 30-minute Zoom call to scope your tokenomics work. Bring whatever exists—a deck, a draft model, or just questions.
---
# Section: Quote
## Section landing: Send a project brief
- URL: https://giantslabs.pro/quote/
- Kind: section landing
- Section: quote
- Description: Detailed brief for tokenomics consulting engagements at Giants Labs. Send project context for a quote and timeline.
---
# About this dump
This file is part of the Giants — Tokenomics Lab site (https://giantslabs.pro/).
Maintained by Alexey Karanyuk.
For citation format and AI usage policy, see https://giantslabs.pro/ai.txt.
For a curated index of the site instead of the full text, see https://giantslabs.pro/llms.txt.