Plate 00 · Overview

One token. A catalogue of behaviours. The holders decide which one is live.

morph is an ERC-20 on Ethereum with a single Uniswap v4 pool. What a trade costs, and whether a slice of it is burned or set aside, is not fixed at launch — it is elected, one epoch at a time, by the people who hold the token.

Three behaviours are compiled into the pool's hook when it is deployed. Each one is a small, self-contained rule about what happens during a swap. Exactly one of them is active at any moment, and a holder vote decides which.

That is the entire mechanic. There is no second token, no staking contract, no emissions schedule. The interesting object is the pool itself: a market whose rules are a standing decision rather than a constant.

Active module DynamicFee · index 1
Epoch n
Vote weight read from opened epoch n
Fig. 00.1 — the specimen in each of its three forms. One body: the geometry is a single surface whose shape is a blend of three functions, so an election does not swap one model for another, it moves every point on the object. Epochs are shown relative (n, n + 1) because nothing is deployed and there is no chain to read.

§ 00.1How it works, in three steps

Hold MORPH, and delegate it to yourself

Voting weight comes from a checkpoint, not from the balance sitting in your wallet at the moment you vote. A single delegate(yourAddress) call turns your balance into counted weight; after that, every transfer you make writes a new checkpoint automatically.

Vote once per epoch for one module

Each epoch you may cast one ballot for one of the three catalogued modules. The weight applied is the weight you had at a snapshot taken before the epoch opened — so buying in the middle of an epoch does not buy a vote in it.

The epoch rolls, and the winner goes live

Once the window closes, anyone can call finalizeEpoch(). The module with the most weight becomes the active module for the next epoch, and a fresh snapshot is taken for the next round of voting. If nobody voted, the module already running stays.

§ 00.2The catalogue

Three entries, fixed in this order at deployment. The catalogue number is the on-chain index a vote refers to.

Registry — as constructed
No.ModuleEffect on a trade
MOD-00 BurnOnSell 3% of the MORPH paid into a sell is taken by the hook and burned. Buys are untouched.
MOD-01 DynamicFee An asymmetric pool fee: 1% on buys, 3% on sells. The fee goes to the liquidity position, not to the hook.
MOD-02 BuybackSkim 1% of the ETH paid into a buy accrues to the hook. Sells are untouched.

Read the full entry for each module →

§ 00.3What a vote can and cannot do

A vote moves an index. That is the whole of its power.

The registry is written once, in the hook's constructor, into a private array that is never written again. There is no function anywhere in the contract that adds a module, replaces a module, or points the hook at new code — not for a voter, not for the deployer, not for anyone. A ballot for an index outside the range [0, 3) reverts.

This is worth being precise about, because "governance can change the token's behaviour" usually describes an upgradeable proxy, and an upgradeable proxy is a promise that new code will not be malicious. morph makes no such promise, because it has no such door: the three behaviours you can read today are the only three that will ever run. Governance chooses among them; it cannot author a fourth.

§ 00.4The token

MORPH is a fixed-supply ERC-20: 1,000,000,000 tokens, all minted once in the constructor. There is no mint function afterwards, so supply can only ever fall — the BurnOnSell module removes tokens permanently when it is active.

Holding it does two things. It is a position in the pool's asset, and it is a vote on how that pool behaves. Those are not separate products; the second is the reason the first is unusual. A holder who wants supply to shrink argues for MOD-00. A holder who wants the deepest liquidity argues for MOD-01, which routes the fee to the position rather than the hook. Every epoch, that argument is settled by weight and the market trades under the answer.

That is the demand case, stated plainly and without a forecast: the token is the ballot for a live market's rules. Full token plate →

Registration status — not deployed

Nothing described here is live. There is no contract address, no pool, no liquidity, and nothing to buy. The contracts exist as source and a local test suite.

When the pool is deployed, the token address, the hook address and the pool link will be published on the token plate. Anything claiming to be MORPH before then is not.