Token Economic Model Design

Designing Token Economic Models

A token economic model is a mechanism for coordinating participants through incentives. A good model creates Nash Equilibrium where rational behavior of each participant leads to good outcomes for the protocol overall. A bad model occurs when rational behavior destroys the system (bank run on staking, governance attacks, liquidity exits).

Mechanism Design: Fundamental Principles

Incentive Alignment

Each participant must be motivated to act in the protocol's interests:

Liquidity providers: earn fees proportional to their share. If fees > impermanent loss + opportunity cost → LPs stay.

Token holders: value capture through fee share, governance, or buyback. If holding a token is less profitable than other assets — they sell.

Validators/Stakers: earn block rewards + transaction fees. Staking makes it costly to attack → security through economic incentives.

Developers: grants from treasury, protocol owned liquidity uses revenue to finance development.

Value Flows

Users pay fees
    ↓
[Protocol Revenue]
    ↓
├─ 50% → Liquidity Providers (incentivize liquidity)
├─ 30% → Treasury (governance-controlled)
└─ 20% → Buyback & Burn (deflationary pressure)

This flow should be documented and modeled quantitatively.

Value Capture Models

ve-Token (Vote-Escrowed)

Curve Finance introduced the veToken mechanism, which became an industry standard:

• Holder locks token for 1 week to 4 years
• Receives veCRV (vote-escrowed CRV) — non-transferable
• veTokens provide: boosted yield (up to 2.5x), governance votes, share of protocol fees
• More locked time = more veTokens
• At lockup expiry: returns CRV, loses veCRV

This solves a fundamental governance problem: speculators (short-term holders) get less influence than long-term holders.

Implementation:

contract VotingEscrow {
    struct LockedBalance {
        int128 amount;
        uint256 end; // unlock timestamp
    }
    
    mapping(address => LockedBalance) public locked;
    
    function lockAmount(uint256 value, uint256 unlockTime) external {
        // unlockTime must be in future, rounded to WEEK
        require(unlockTime > block.timestamp, "Can only lock until future");
        
        token.transferFrom(msg.sender, address(this), value);
        locked[msg.sender] = LockedBalance({
            amount: int128(int256(value)),
            end: (unlockTime / WEEK) * WEEK, // round to week
        });
        
        emit Deposit(msg.sender, value, unlockTime);
    }
    
    // Voting power = amount * (end - now) / MAX_LOCK_TIME
    function balanceOf(address addr) public view returns (uint256) {
        LockedBalance memory _locked = locked[addr];
        if (block.timestamp >= _locked.end) return 0;
        
        uint256 remaining = _locked.end - block.timestamp;
        return uint256(int256(_locked.amount)) * remaining / MAX_LOCK_TIME;
    }
}

Bonding Curve

For tokens where price is mathematically determined by smart contract:

// Simple bonding curve: P = k * S (linear)
// where S = circulating supply, k = coefficient
contract BondingCurveToken {
    uint256 public constant SLOPE = 1e12; // k
    
    function getBuyPrice(uint256 amount) public view returns (uint256) {
        uint256 currentSupply = totalSupply();
        // Integral from S to S+amount of f(x) = SLOPE*x
        return SLOPE * (2 * currentSupply + amount) * amount / 2 / 1e18;
    }
    
    function buy(uint256 minTokens) external payable {
        uint256 tokensToMint = calculateTokensForETH(msg.value);
        require(tokensToMint >= minTokens, "Slippage");
        _mint(msg.sender, tokensToMint);
    }
    
    function sell(uint256 tokenAmount, uint256 minETH) external {
        uint256 ethToReturn = getSellPrice(tokenAmount);
        require(ethToReturn >= minETH, "Slippage");
        _burn(msg.sender, tokenAmount);
        payable(msg.sender).transfer(ethToReturn);
    }
}

Bonding curves are used in: Pump.fun, Clanker, early Uniswap concept, social tokens.

Protocol Owned Liquidity (POL)

OlympusDAO popularized POL through bonding: instead of a token, a user "sells" LP tokens to the protocol and receives tokens at a discount. The protocol becomes the liquidity owner — doesn't depend on mercenary LPs.

Problem: without stable revenue, OlympusDAO became Ponzi (3,3 game theory). POL works when the protocol has real revenue.

Game Theory: Nash Equilibrium Analysis

For each key situation, you need to check: what choice is rational for each participant?

Example — governance attack:

• Cost of accumulating 51% of votes: X
• Potential profit from attack: Y
• If Y > X → attack is rational
• Defense: large token supply (expensive to attack), timelock (days to respond), multisig veto for extreme actions

Example — liquidity exits:

• APY from staking: 10%/year
• If price falls > 10% → unprofitable staking → exit → price falls further → death spiral
• Defense: backed value (treasury), fee-based rewards (not inflationary)

Quantitative Modeling

A mandatory step before publishing the model — spreadsheet simulation:

Break-even price: at what token price does staking/holding remain economically viable.

Stress Testing

The model should be checked in scenarios:

• Bear market: price drops 90%, what happens to incentives?
• Governance attack: how expensive to attack, what are consequences?
• LP exit: if 80% of LPs leave, how critical is it for the protocol?
• Founder exit: what happens if founding team sells all tokens?

Designing a token economic model: 2-4 weeks. Includes mechanism design, quantitative modeling, stress-tests, and final document.