Token economic design is one of the most underappreciated attack surfaces in decentralized systems. A protocol can pass multiple rounds of code audit — no reentrancy bugs, no integer overflows, no access control gaps — and still be economically devastated by design choices made in a pitch deck before a single line of Solidity was written.

A protocol can pass multiple audits with airtight contracts and no obvious exploits, because audits validate code correctness, not economic soundness. A perfectly secure contract can still be economically fragile. Many failures are not “code bugs” but incentive failures — economic design can be exploited through arbitrage, manipulation, liquidity attacks, governance capture, or oracle games.

This article is about how auditors evaluate token economic design as a first-class security concern — and why the discipline of tokenomics security is fundamentally different from traditional smart contract auditing.

The Audit Mindset Shift: Economics as Attack Surface

Traditional smart contract auditing asks: does the code do what it says? Tokenomics security auditing asks a more adversarial question: given that the code does exactly what it says, how can rational actors extract value in ways that destroy the protocol?

Tokenomics design flaws are typically intricate and elusive, posing significant challenges for general security audits. When malicious entities exploit these flaws, the resulting losses can be staggering — and when several vulnerabilities persist within a tokenomic structure, their combined risks can intensify, exponentially increasing the chances of unauthorized benefits.

Strong tokenomics is not a pitch deck. It is a security system. Auditors who treat token design as an afterthought — something the economics team handles separately — will consistently miss the most consequential attack vectors in modern DeFi.

The core mental model: tokenomics defines incentives, incentives shape behavior, and behavior in adversarial systems becomes strategy. When incentives are misaligned, exploitation isn’t an exception — it’s the expected outcome.

1. Vesting Contract Vulnerabilities

Vesting schedules exist to align long-term incentives. Vesting is an essential mechanism in tokenomics, enabling the gradual and controlled release of tokens — reducing volatility and stabilizing the market while aligning stakeholder interests with the project’s goals for long-term engagement.

But the contract that enforces a vesting schedule is itself an attack surface. Projects must ensure proper auditing and security of the smart contracts used for vesting — any flaws or vulnerabilities in these contracts can compromise the vesting process and investor trust.

The most common vesting contract vulnerabilities auditors look for:

Missing schedule validation: Audit findings from real vesting contracts include missing vesting schedule timing checks and missing period verification — allowing schedules to be set with zero-duration cliffs or overlapping unlock windows.

Reentrancy on claim: When a vesting contract calls transfer() before updating internal state, a recipient contract can re-enter claim() and drain tokens beyond their allocation. The fix is always CEI (Checks-Effects-Interactions) ordering or a reentrancy guard.

Admin override without timelock: Many vesting contracts include an admin revoke() function — legitimate for employee vesting, catastrophic when applied to investor allocations without a timelock. Immutable contracts are crucial because they guarantee that the contract’s logic cannot be altered after deployment, reducing the risk of internal manipulation.

Access control on privileged functions: Access control vulnerabilities occur when functions lack proper permission checks, allowing unauthorized users to execute privileged operations like transferring ownership, minting tokens, or modifying critical parameters. In vesting contracts, this typically manifests as an unprotected setSchedule() or extendCliff() function.

Here is a minimal, annotated vesting contract illustrating both the correct pattern and common vulnerability points:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/access/Ownable2Step.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

/**
 * @title SecureVesting
 * @notice Linear vesting with cliff. Illustrates correct patterns and
 *         annotates common vulnerability sites.
 *
 * AUDIT SURFACE:
 *   - schedules[].cliff must be validated > block.timestamp at creation
 *   - schedules[].end  must be > cliff (zero-duration schedules bypass linear math)
 *   - revoke() has a 2-step owner transfer guard — but should ALSO have a timelock
 *     for investor-facing deployments
 *   - claim() uses CEI ordering to prevent reentrancy
 */
contract SecureVesting is Ownable2Step, ReentrancyGuard {
    IERC20 public immutable token;

    struct Schedule {
        uint128 total;      // Total tokens allocated
        uint128 claimed;    // Tokens already withdrawn
        uint64  cliff;      // Unix timestamp: no tokens before this
        uint64  start;      // Vesting start (may be < cliff)
        uint64  end;        // Vesting end: 100% unlocked
        bool    revoked;
    }

    mapping(address => Schedule) public schedules;

    event ScheduleCreated(address indexed beneficiary, uint128 total, uint64 cliff, uint64 end);
    event TokensClaimed(address indexed beneficiary, uint128 amount);
    event ScheduleRevoked(address indexed beneficiary, uint128 returned);

    error CliffInPast();
    error EndBeforeCliff();
    error ZeroAllocation();
    error NothingToClaim();
    error AlreadyRevoked();
    error ScheduleExists();

    constructor(address _token) Ownable(msg.sender) {
        token = IERC20(_token);
    }

    /**
     * @notice Create a vesting schedule for a beneficiary.
     * @dev    VULNERABILITY SITE: Missing input validation here is the most
     *         common finding in vesting audits. Always validate cliff > now
     *         and end > cliff.
     */
    function createSchedule(
        address beneficiary,
        uint128 total,
        uint64  cliff,
        uint64  end
    ) external onlyOwner {
        // ✅ Validate temporal ordering
        if (cliff <= block.timestamp)   revert CliffInPast();
        if (end   <= cliff)             revert EndBeforeCliff();
        if (total == 0)                 revert ZeroAllocation();
        if (schedules[beneficiary].total != 0) revert ScheduleExists();

        schedules[beneficiary] = Schedule({
            total:   total,
            claimed: 0,
            cliff:   cliff,
            start:   uint64(block.timestamp),
            end:     end,
            revoked: false
        });

        // Pull tokens from owner into escrow at schedule creation
        token.transferFrom(msg.sender, address(this), total);

        emit ScheduleCreated(beneficiary, total, cliff, end);
    }

    /**
     * @notice Claim all currently vested tokens.
     * @dev    CORRECT PATTERN: CEI ordering prevents reentrancy.
     *         ❌ VULNERABLE PATTERN would be:
     *           token.transfer(msg.sender, claimable);
     *           schedule.claimed += claimable;   // state update AFTER external call
     */
    function claim() external nonReentrant {
        Schedule storage s = schedules[msg.sender];
        uint128 claimable = _vestedAmount(s) - s.claimed;
        if (claimable == 0) revert NothingToClaim();

        // ✅ Effects before Interactions
        s.claimed += claimable;

        // Interaction last
        token.transfer(msg.sender, claimable);

        emit TokensClaimed(msg.sender, claimable);
    }

    /**
     * @notice Revoke a schedule, returning unvested tokens to owner.
     * @dev    AUDIT NOTE: In investor-facing deployments, this function MUST
     *         be gated behind a Timelock contract (e.g., 48–72 hour delay).
     *         Without a timelock, a compromised owner key can rug investors
     *         even with "correct" code.
     */
    function revoke(address beneficiary) external onlyOwner {
        Schedule storage s = schedules[beneficiary];
        if (s.revoked) revert AlreadyRevoked();
        s.revoked = true;

        uint128 unvested = s.total - _vestedAmount(s);
        if (unvested > 0) token.transfer(owner(), unvested);

        emit ScheduleRevoked(beneficiary, unvested);
    }

    function _vestedAmount(Schedule storage s) internal view returns (uint128) {
        if (s.revoked || block.timestamp < s.cliff) return 0;
        if (block.timestamp >= s.end) return s.total;

        // Linear interpolation between cliff and end
        uint64 elapsed  = uint64(block.timestamp) - s.cliff;
        uint64 duration = s.end - s.cliff;
        return uint128((uint256(s.total) * elapsed) / duration);
    }
}

The Cliff Manipulation Attack

The cliff is where most economic attacks on vesting originate. Consider a protocol that sets a 12-month cliff for team tokens. Cliff vesting requires a full waiting period before any unlock, often followed by gradual releases, while graded vesting unlocks portions incrementally from the start or after milestones.

If the cliff timestamp is stored as a mutable parameter — and the owner can call setCliff(block.timestamp) without constraint — the entire alignment mechanism collapses. An auditor must verify that cliff parameters are either immutable post-deployment or gated behind governance with a timelock delay that exceeds the minimum cliff length itself.

Example failure modes include: infinite inflation with no burn causing supply to grow faster than demand and price crashes, or all tokens vesting at once causing massive sell pressure and liquidity drain.

2. Token Distribution and Concentration Risk

Distribution design determines governance power distribution before a single vote is cast. If three wallets control 51% of voting power, governance is centralized. If early investors unlock billions while retail holds very little, manipulation risk is high.

Auditors model distribution scenarios across multiple unlock horizons — typically TGE (Token Generation Event), 6-month, 12-month, and 36-month snapshots — and calculate the Gini coefficient of circulating supply ownership at each checkpoint. A distribution with a Gini above 0.85 at TGE+12 months is an immediate red flag.

Evaluating the initial token allocation across team, investors, community, treasury, and ecosystem funds is essential — checking for excessive insider allocation and assessing whether vesting schedules are properly structured.

The supply concentration attack path is straightforward: insiders with large allocations and short cliffs can coordinate to exit simultaneously near unlock dates, front-running retail. If the large percentage of tokens allocated to the team and advisors were available immediately without a vesting period, holders could instantly sell their tokens on the market. Even with a cliff, a coordinated post-cliff dump remains a dominant strategy when the incentive to hold is purely speculative.

3. Emission Schedule Exploits

Emission schedules govern how many new tokens enter circulation over time. Unsustainable emission schedules create constant sell pressure and erode token value — but beyond general economic pressure, poorly designed emission contracts create precise exploit windows.

The core risk: emission contracts that are parameterizable by governance can be exploited through governance capture. An attacker who acquires sufficient voting power can vote to change emission rate parameters, directing newly minted tokens to addresses they control.

Here is an emission contract that illustrates both a secure baseline and the critical parameterization risk:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Capped.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";

/**
 * @title EmissionController
 * @notice Epoch-based emission with hard cap and rate-change timelock.
 *
 * AUDIT SURFACES:
 *   1. MINTER_ROLE must be held by a governance-controlled address,
 *      NOT an EOA. A compromised EOA with MINTER_ROLE can print to cap.
 *   2. emissionRate changes must be timelocked — immediate rate changes
 *      allow governance to front-run a vote with a rate spike.
 *   3. epochReward recipient list must be immutable or governance-gated.
 *      A mutable recipient allows redirecting emissions post-capture.
 *   4. Hard cap validation in mint() prevents arithmetic from exceeding
 *      max supply even if emission math has an overflow bug.
 */
contract EmissionController is AccessControl {
    bytes32 public constant MINTER_ROLE    = keccak256("MINTER_ROLE");
    bytes32 public constant GOVERNOR_ROLE  = keccak256("GOVERNOR_ROLE");

    IERC20Mintable public immutable token;

    uint256 public constant EPOCH_DURATION   = 7 days;
    uint256 public constant MAX_EMISSION_RATE = 500_000e18; // 500k tokens/epoch absolute ceiling
    uint256 public constant RATE_CHANGE_DELAY = 2 days;     // ⚠️ AUDIT: must exceed proposal timelock

    uint256 public emissionRate;             // Tokens minted per epoch
    uint256 public pendingEmissionRate;      // Queued new rate
    uint256 public pendingRateActiveAt;      // Timestamp when pending rate activates

    uint256 public lastEpochTimestamp;
    address public emissionRecipient;        // Treasury / distributor

    event EmissionMinted(uint256 epochIndex, uint256 amount, address recipient);
    event EmissionRateQueued(uint256 newRate, uint256 activeAt);
    event EmissionRateApplied(uint256 newRate);

    error EpochNotComplete();
    error RateExceedsMaximum();
    error RateChangeNotReady();
    error RecipientZeroAddress();

    constructor(
        address _token,
        address _recipient,
        uint256 _initialRate
    ) {
        require(_initialRate <= MAX_EMISSION_RATE, "Initial rate exceeds cap");
        require(_recipient != address(0),           "Zero recipient");

        token             = IERC20Mintable(_token);
        emissionRecipient = _recipient;
        emissionRate      = _initialRate;
        lastEpochTimestamp = block.timestamp;

        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(GOVERNOR_ROLE,      msg.sender);
        _grantRole(MINTER_ROLE,        msg.sender);
    }

    /**
     * @notice Trigger emission for the current completed epoch.
     * @dev    Permissionless — anyone can call once per epoch.
     *         This prevents a centralized keeper from censoring emissions.
     */
    function emitEpoch() external {
        if (block.timestamp < lastEpochTimestamp + EPOCH_DURATION) {
            revert EpochNotComplete();
        }

        // Apply pending rate if timelock has elapsed
        if (pendingRateActiveAt != 0 && block.timestamp >= pendingRateActiveAt) {
            emissionRate      = pendingEmissionRate;
            pendingRateActiveAt = 0;
            emit EmissionRateApplied(emissionRate);
        }

        uint256 amount = emissionRate;
        lastEpochTimestamp += EPOCH_DURATION; // ✅ Fixed-step to prevent drift

        // ✅ AUDIT: mint() on a capped token will revert if hard cap exceeded
        token.mint(emissionRecipient, amount);

        emit EmissionMinted(
            (block.timestamp - lastEpochTimestamp) / EPOCH_DURATION,
            amount,
            emissionRecipient
        );
    }

    /**
     * @notice Queue an emission rate change. Takes effect after RATE_CHANGE_DELAY.
     * @dev    VULNERABILITY WITHOUT THIS DELAY: governance can pass a proposal
     *         in the same block as emitEpoch(), spiking emissions before any
     *         holder can react or the change can be observed.
     */
    function queueEmissionRateChange(uint256 newRate) external onlyRole(GOVERNOR_ROLE) {
        if (newRate > MAX_EMISSION_RATE) revert RateExceedsMaximum();

        pendingEmissionRate = newRate;
        pendingRateActiveAt  = block.timestamp + RATE_CHANGE_DELAY;

        emit EmissionRateQueued(newRate, pendingRateActiveAt);
    }

    /**
     * @dev Cancel a pending rate change (e.g., if governance reverses).
     */
    function cancelPendingRateChange() external onlyRole(GOVERNOR_ROLE) {
        pendingRateActiveAt = 0;
        pendingEmissionRate = 0;
    }
}

interface IERC20Mintable {
    function mint(address to, uint256 amount) external;
}

The critical audit point is the MINTER_ROLE assignment. When functions lack proper permission checks, unauthorized users can execute privileged operations like minting tokens or modifying critical parameters — weak or missing access control mechanisms have enabled numerous breaches, from governance attacks to complete protocol compromises.

If MINTER_ROLE is held by a simple EOA, that account’s compromise — through phishing, key exfiltration, or social engineering — immediately grants unlimited mint access up to the cap. Without a mint freeze, the possibility of unforeseen or unauthorized token creation could arise, risking inflation or security breaches.

The Epoch Timestamp Drift Attack

A subtle emission exploit: contracts that use lastEpochTimestamp = block.timestamp (rather than lastEpochTimestamp += EPOCH_DURATION) allow accumulated drift. A keeper who delays calling emitEpoch() by even a few hours per epoch can accumulate “free” epochs over a year, calling the function multiple times in rapid succession to drain accrued emission windows. The fix — incrementing by a fixed constant rather than assigning block.timestamp — closes this window entirely.

4. Vote Escrow (veToken) Lock Manipulation

The “vote escrowed” (ve-) token model was pioneered by Curve, starting from their native governance token CRV. The kicker is that holders need to lock (stake) CRV to utilize it. Rather than treating every token holder equally at every moment, it gives more weight to capital that accepts illiquidity and remains exposed to the protocol’s future — voting power usually decays over time and often controls gauge-based reward allocation, which is why ve systems sit at the center of emissions, boosts, and bribe markets.

The design elegance creates an equally elegant attack surface.

Lock Duration Manipulation

In Curve’s implementation, Curve features a decay element meaning that the total veCRV held by a user decreases linearly, encouraging constant lockups for maximum yields. The security assumption is that decaying voting power maps to declining economic exposure. The vulnerability: any actor who can repeatedly re-lock (extending their lock duration) near proposal snapshots can maintain maximum voting weight indefinitely at the cost of illiquidity — a cost that becomes irrelevant if the expected governance capture payoff exceeds it.

Auditors examine:

  • Whether re-lock calls update the snapshot block used for voting power
  • Whether there is a minimum lock increment to prevent micro-extensions used to stay at maximum weight
  • Whether voting power is calculated at proposal snapshot or at vote cast time (snapshot-at-cast allows same-block lock manipulation)

The Voting Power Desync Bug

A bug in one protocol allowed people to vote, claim bribes, and then change their vote after the fact — emissions in the initial weeks were enormous, disappearing practically overnight as investors pulled liquidity and the protocol died.

This is the veToken equivalent of a reentrancy attack: voting power is consumed (vote is cast), reward is claimed, then the consumed action is reversed (vote is changed). The invariant that “claiming bribe rewards for epoch N implies your vote for epoch N is finalized” must be enforced at the contract level, not assumed.

5. Bribe Market Security

Bribe markets are the emergent consequence of veToken design. Bribes in DeFi are payments offered to token holders or vote holders in exchange for using their governance power in a particular way. If a vote controls something valuable, that vote itself becomes valuable, and markets will usually form around it.

Many DeFi systems were designed so governance tokens would align long-term users with the protocol — yet the moment a vote decides where token emissions go, which pool receives incentives, or whether a proposal passes, the vote stops being just a governance right. It becomes a cash-flow right.

Voting behaviour follows bribes set by higher-level protocols, and the cost per vote varies depending on how it is acquired. Research demonstrates that voting markets such as Votium largely determine the outcome of fortnightly votes held by Convex Finance — and protocols like Frax Finance play a central role even though they directly lock relatively few tokens with Curve, instead indirectly locking tokens through yield aggregators and purchasing voting weight through voting markets.

From a security perspective, bribe markets introduce:

Aggregator concentration risk: If managing locks, votes, claims, and optimization is operationally annoying, users often delegate to an aggregator — the aggregator becomes the practical owner of governance leverage. Bribe markets then become easier, because buyers prefer dealing with a large block of influence rather than thousands of small wallets.

Griefing via underpaying: An attacker can place very small bribes on many gauges simultaneously, splitting vote allocation across economically meaningless pools, diluting emissions from the attacker’s target gauges without ever needing to accumulate tokens.

Bribe contract reentrancy: Bribe distribution contracts that iterate over voter lists and call arbitrary claim() functions on recipient contracts are vulnerable to reentrancy. The bribe contract must process each claim as an isolated state transition.

Epoch boundary manipulation: Bribe protocols typically use fixed epoch windows. A briber who places a bribe one block before epoch close and votes in the same transaction can claim a disproportionate share of the epoch’s rewards relative to their contribution period.

6. Inflation via Minting Authority Compromise

Mint freeze authority is the technical privilege that allows an entity — often a smart contract or multisig wallet — to disable the minting of new tokens, permanently or temporarily. When this authority is not properly structured, compromise of the minting key is economically equivalent to an infinite print vulnerability.

The taxonomy of minting authority failure modes:

PatternRisk LevelDescription
EOA holds MINTER_ROLECriticalSingle key compromise = unlimited mint
2-of-3 multisig (hot keys)HighPhishing of 2 signers = unlimited mint
Governance-controlled mintMediumGovernance capture = authorized mint to attacker
Capped + timelockedLowRequires capture + waiting period
Immutable supplyNoneNo minting possible post-deploy

Supply defensibility protects token holders from surprise inflation events. Auditors must map every code path that results in _mint() being called and verify the access control chain all the way to its root. An upgradeable proxy pattern with a UPGRADER_ROLE held by an EOA is functionally equivalent to a minting backdoor — the upgrade itself can introduce an unrestricted mint() function.

The governance path is equally dangerous: DAO governance for upgrades isn’t inherently more secure than centralized control — it’s differently secure. A small team making unilateral decisions is vulnerable to key compromise, while a DAO is resistant to single points of failure but vulnerable to plutocracy, voter apathy, and flash-loan governance attacks.

7. Tokenomics and Governance Security

The relationship between token distribution and governance security is direct and often underestimated. Governance systems are only as decentralized as the initial token distribution permits.

Flash Loan Governance Attacks

Governance attacks occur when an entity acquires a significant voting share — often via flash loans — to manipulate decisions, such as altering protocol rules or draining treasuries. These attacks exploit the unique feature of flash loans, which allow users to borrow substantial amounts of cryptocurrency without collateral, provided that the loan is returned within the same transaction block.

Token-weighted voting is susceptible to flash loan governance attacks, where attackers borrow tokens momentarily to acquire voting authority and forward destructive proposals. To prevent such attacks, Compound’s Governor Bravo introduced a two-day wait for votes on recently acquired tokens — a system that has successfully dropped governance takeover rates.

Plutocracy and Concentration

Governance tokens are often not used as intended and may be harmful to the security of DeFi platforms — users often do not use governance tokens to vote, voting rates are negatively correlated with gas prices, and voting is very centralized.

The more tokens a user holds, the more voting power they possess — this can lead to scenarios where entities with large token holdings, such as whales or venture capitalists, can sway decisions in their favor, potentially sidelining the interests of smaller token holders.

From an audit perspective, the token distribution schedule is a governance attack timeline. A project with 40% insider allocation and a 12-month cliff has a predictable governance capture window at month 12 — the moment insiders are fully liquid, they can either sell (price impact) or consolidate (governance capture). Auditors must model both paths.

Proposal Lifecycle as Attack Vector

Low voter turnout (under 15% of circulating supply participates), short proposal lifecycles (under 48 hours from submission to execution), no cooldown on bridged tokens before voting eligibility, and timelocks under 24 hours between proposal passage and execution are all conditions that individually represent risks — and several major DAOs match multiple of these criteria simultaneously.

The governance parameter checklist for auditors:

  • Snapshot block vs. vote-cast block: Snapshot-at-proposal-creation is more secure than snapshot-at-vote-cast
  • Quorum threshold relative to circulating supply: Not total supply — tokens locked in vesting contracts cannot vote
  • Timelock duration vs. bribe epoch length: Timelock must exceed bribe epoch to prevent just-in-time capture
  • Proposal threshold: The minimum tokens required to submit a proposal gatekeeps spam but also gatekeeps legitimate minority voices
  • Cancellation authority: Who can cancel a malicious proposal, and is that authority itself vulnerable to capture?

8. Economic Design as Audit Surface (Even When Code Is Correct)

This is the crux of tokenomics security: design choices that are fully intentional and correctly implemented can still be exploited. The code is not the vulnerability. The design is.

To ensure the integrity and security of DeFi projects, smart contract audits with a keen focus on tokenomic design are imperative — these audits extend beyond code review and into the intricate economic incentives underlying these systems.

Consider these design-level vulnerabilities with no corresponding code bug:

The liquidity bootstrapping trap: A protocol launches with high early emissions to bootstrap liquidity. Yield farmers enter, provide liquidity, and farm emissions. When emissions decay (by design), rational farmers exit simultaneously. The protocol’s liquidity collapses not because anything malfunctioned — but because the emission decay schedule was legible to every participant. Attempting to incentivize liquidity providers through high APY rewards in a native token creates extreme sell pressure and dilution of the supply.

The governance death spiral: Protocol loses value → governance token price falls → cost of governance attack falls → rational actors drain treasury → protocol loses more value. Bad tokenomics kills projects slowly — then suddenly. Stress-testing incentives, emissions, governance capture, and reflexive “death spiral” dynamics before they ship is essential.

The token sink insufficiency: A protocol’s tokenomics relies on staking, burning, or locking to offset emissions. If the designed sinks are optional (users can choose not to participate), the sink utilization rate is an adversarial variable, not a constant. At low protocol TVL, sinks underperform, emission pressure dominates, price falls, staking yield becomes less attractive, sinks underperform further. Auditors must model this feedback loop at 10%, 25%, and 50% sink participation rates.

The oracle-tokenomics coupling risk: When a protocol’s emission rate, collateral ratio, or liquidation threshold is indexed to the protocol’s own token price, that token becomes an oracle manipulation target. Depressing the token price via a short position can trigger emission increases or collateral reductions that themselves accelerate price decline.

The Tokenomics Audit Checklist

Structured tokenomics audits should evaluate:

Emissions, unlocks, liquidity depth and slippage, fee accrual, and governance thresholds should all be modeled, surfacing pressure points and trade-offs.

  1. Supply schedule analysis: Total supply, circulating supply at each time checkpoint, vesting unlock calendar
  2. Concentration analysis: Gini coefficient at TGE and at each major unlock date; Nakamoto coefficient of governance
  3. Emission sustainability: Emissions vs. protocol revenue; break-even participation rate for staking sinks
  4. Governance capture cost: Minimum capital required to capture governance at current market prices
  5. Cliff manipulation scenarios: Can cliff or end timestamps be modified post-deployment? By whom? With what delay?
  6. Minting authority chain: Full access control trace from _mint() to ultimate controller
  7. veToken invariants: Is voting power at snapshot or vote-cast? Can the same power be used for multiple epochs?
  8. Bribe market edge cases: Epoch boundary claims, vote-change-after-claim, aggregator concentration
  9. Death spiral modeling: Price → governance cost → treasury drain feedback loop
  10. Oracle-tokenomics coupling: Which protocol parameters are indexed to the native token price?

Defensive Design Patterns

Auditors should not only find vulnerabilities — they should recognize design patterns that constrain the attack surface from the outset:

Immutable schedules: Vesting schedules that cannot be modified post-deployment, even by governance, eliminate the cliff manipulation surface entirely at