Token Development: ERC-20, Tokenomics, Vesting

"ERC-20 is simple" — phrase that precedes problems. Basic transfer is straightforward to write. But a token that doesn't collapse from inflation in six months, governance works as designed, and vesting can't be bypassed through delegation tricks — that's engineering.

ERC-20: What's Under the Hood

ERC-20 standard has nine functions. Complexity starts with extensions:

ERC-20Permit (EIP-2612) — gasless approve via signature. User signs permit(owner, spender, value, deadline, v, r, s) off-chain, spender calls permit() + transferFrom() in one transaction. Removes separate approve step. Risk: signature can be intercepted — need deadline and nonce checking.

ERC-20Votes (EIP-5805) — snapshot balances for governance. Checkpoint system stores balance history by block number. getPastVotes(address, blockNumber) returns balance at proposal creation, not current. Prevents flash loan governance: can't borrow tokens and vote in one transaction.

Rebasing tokens (stETH, Ampleforth) — balanceOf changes automatically through internal shares ratio. High integration complexity: most DeFi protocols don't work correctly with rebasing without non-rebasing wrapper.

Fee-on-transfer tokens — percentage cut on every transfer. Breaks AMM calculations: pool receives less than expected. Uniswap v2/v3 don't support natively — needs special pair/router.

Tokenomics: Where Math Becomes Economy

Tokenomics isn't Excel table summing to 100%. It's incentive model that either works long-term or creates selling pressure killing the project.

Emission Schedule and Inflation

Fixed supply (Bitcoin model) — deflation through burn mechanics or just limited new tokens. Fits store-of-value or utility tokens with limited demand for new supply.

Inflationary model (Ethereum post-Merge, Curve) — new tokens generated to incentivize participants. Need balance: emission should be <= value captured by protocol. If protocol earns $100k/month but emission is $500k/month in market value — constant selling pressure inevitable.

Halving schedules (Bitcoin-style) — decreasing emission over time. Creates predictability but requires utility token adoption to grow compensating for falling rewards.

Supply Distribution

No universal formula. Principle: no single entity >33% voting power at launch. Otherwise governance is fiction.

Vesting Contracts: Details Matter

Linear vesting with cliff is standard for team and investors. cliff is the period after TGE with zero availability. After cliff: linear unlock until duration.

Typical implementation errors:

Revocable vesting without timelock — owner can revoke immediately. Compromised owner or bad faith team = all unvested tokens revoked. Solution: revocation through multisig + governance vote.

Cliff doesn't block governance rights — with ERC-20Votes, recipient can delegate voting power from day one even if tokens aren't unlocked. Need explicit separation of voting power and claim logic.

No emergency pause — if vesting contract vulnerability discovered, need ability to pause claims. Pausable + timelock on unpause.

Liquidity Bootstrapping

Launch mechanics are critical. Three main approaches:

Balancer LBP (Liquidity Bootstrapping Pool) — temporary Balancer pool with high initial token weight (90/10 project-token/USDC) that automatically decreases to 50/50 over days. Creates downward price pressure preventing bot buys at one price. After LBP liquidity moves to permanent pool.

Fjord Foundry — specialized platform for LBP and fair launches. Less operational overhead than direct Balancer integration.

Uniswap v3 with limited range — add liquidity in narrow range around initial price. High capital efficiency but requires active range management.

TWAMM (Time-Weighted AMM) — mechanics for gradual large-order sales without slippage. Paradigm proposed, implemented in FraxSwap.

Governance Tokens and Voting Mechanics

OpenZeppelin Governor is the standard on-chain governance implementation. Modular: GovernorVotes for counting, GovernorTimelockControl for timelock execution, GovernorSettings for adjustable parameters.

Quorum is minimum percentage of supply for voting validity. Too high = apathy failure (can't reach quorum). Too low = whale capture. Compound set quorum at 400k COMP (4% supply) — rarely achieved without coordination.

Flash loan governance attack — attacker borrows tokens via flash loan, delegates to self, creates proposal or votes, returns tokens. ERC-20Votes with block-based snapshot completely blocks this: must have tokens at snapshot creation moment, not voting moment.

Delegation — small holders often don't vote. Liquid delegation (like Optimism) lets delegate voting power to addresses without transfer. Critical for protocols with many passive holders.

Token Development Stack

Contracts: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Tokenomics audit: Python models with emission/demand simulation, cadCAD for complex systems modeling

Deployment and management: Foundry scripts, Gnosis Safe for treasury, OpenZeppelin Defender for automation

Analytics: Dune Analytics for on-chain metrics, Token Terminal for protocol revenue

Process

Tokenomics design — supply model, allocation, emission schedule, vesting. Stress-test scenarios (bear market, whale exit, governance capture attempt).

Contract development — ERC-20 + extensions, vesting, governance. Foundry fuzz tests on vesting calculations, governance thresholds.

Audit — special attention on governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — choose mechanics, set parameters, monitor first 24 hours.

Post-launch — monitor supply distribution via Dune, governance participation metrics, treasury management.

Timelines

• ERC-20 with permit and basic governance: 2–3 weeks
• Vesting contract with revocation and cliff: 2–4 weeks
• Full governance (Governor + Timelock + Token): 4–7 weeks
• Token + LBP + governance + vesting: 8–14 weeks