$MORPHEPE/docs
morphepe@nebuchadnezzar:/usr/share/doc$ man morphepe

$MORPHEPE token mechanics

A plain description of how the token, the hook and the governance rounds work. This page describes the intended design. Where something is not live yet, it says so.

version 0.1-draftnetwork Ethereum · Uniswap V4status pre-launch · unaudited

01Overview

$MORPHEPE is an ERC-20 token traded in a Uniswap V4 pool. The pool's hook does not have fixed behaviour. It runs one program at a time, and the program can be replaced.

Two processes change how the pool behaves:

  • Déjà vu, every 30 minutes: an automated agent swarm adjusts numeric parameters (fee level, fee split, anti-snipe window) inside fixed limits. No code changes.
  • The choice, at random intervals of 1 to 5 hours: the swarm proposes a new program, independent reviewers check it, and holders have 30 minutes to veto it. If it is not vetoed, the hook loads it.

The token contract itself never changes. Its address, supply and balances stay the same whatever program is loaded.

02Architecture

The system is made of four onchain components and one offchain one.

componenttyperesponsibility
MorphepeTokenERC-20 + ERC20VotesFixed supply of 1,000,000,000. No mint function, no owner. Vote checkpoints are used to measure veto weight.
MorphepeHookUniswap V4 hookFixed address, registered in the pool key. Holds every hook permission the system may need and forwards each call to the active program.
Programmodule contractImplements one fee strategy (burn, vault, LP boost…). It can only act through the interface the hook exposes to it.
ProgramRegistrygovernance contractStores proposals, reviewer signatures and veto votes, executes approved rounds and schedules the next one.
Swarmoffchain agentsRead market data, submit parameter pulses and draft program proposals. They hold narrowly scoped keys.

Why a fixed hook that delegates

In Uniswap V4 the hook address is part of the pool's identity, and the hook's permissions are encoded in the low bits of that address. A pool cannot switch to a different hook contract. $MORPHEPE keeps one hook for the life of the pool and changes what it delegates to.

// simplified call path for every swap
PoolManager.swap()
  └─ MorphepeHook.beforeSwap()      // fixed address
       └─ registry.activeProgram()  // e.g. BuybackBurnHook
            └─ program.beforeSwap(params) // bounded by the hook

03Swap fee and distribution

Every swap pays a dynamic fee. The fee level and the way it is split are parameters, so they can move on each déjà vu, but only inside the bounds below. The bounds are constants in the hook and cannot be changed by any role.

parameterboundsmax change per pulse
swap fee0.30% – 3.00%±0.25 percentage points
burn share0% – 60% of the fee±10 points
LP share20% – 80% of the fee±10 points
review bounty10% – 30% of the fee±5 points
anti-snipe0 – 10 blocks after launch or a program change±2 blocks

The three shares always add up to 100%. A pulse that breaks this rule, or any bound, reverts.

  • Burn: used to buy back $MORPHEPE and send it to a dead address, so supply only goes down.
  • LP: paid to liquidity providers in the pool.
  • Review bounty: accumulates in the registry and pays the reviewers who check each proposed program.

Example

A 1 ETH swap with the fee at 1.00% and a 30 / 50 / 20 split:

FEE0.0100 ETH
BURN 30%0.0030 ETH
LP 50%0.0050 ETH
BOUNTY 20%0.0020 ETH

04Déjà vu: parameter pulses

Every 30 minutes the swarm may submit one pulse. A pulse only changes the parameters from section 3. It cannot change code, the active program or any address.

  1. The swarm reads volume, volatility, sell pressure and MEV activity for the pool.
  2. It calls setParams() with new values.
  3. The hook checks the bounds, the per-pulse limits and the 30 minute rate limit.
  4. The new values are queued and take effect after a 5 minute notice, so traders can see them before they apply.
function setParams(Params calldata p) external onlySwarm {
    require(block.timestamp >= lastPulse + 30 minutes);
    require(withinBounds(p) && withinStep(current, p));
    require(p.burn + p.lp + p.bounty == 100);
    queued = p; effectiveAt = block.timestamp + 5 minutes;
}

If the swarm submits nothing, the current parameters stay in place.

05The choice: program rounds

A round is the only way to change the active program. Rounds happen at random intervals between 1 and 5 hours, measured from the end of the previous round.

1 · SCANswarm ranks live V4 hook strategies
2 · PROPOSEprogram address + code hash + rationale
3 · REVIEW2 of 3 reviewer signatures
4 · VOTE30 min window, blue pill = veto
5 · EXECUTEhook loads the new program
6 · SCHEDULEnext round in rand(1h, 5h)

Proposal

The swarm submits the address of an already deployed program contract, the hash of its runtime code and a short rationale. Programs are rewritten from the strategy they copy. Code from other projects is never deployed as is.

Review

Three independent reviewers inspect the program. The proposal moves to the vote only if at least two of them sign an approval (EIP-712 signature bound to the code hash). If fewer than two approve, the round ends and nothing changes.

Vote

Holders then have 30 minutes. Doing nothing counts as accepting the proposal (the red pill). Holders who disagree vote blue pill. If blue pill votes reach 10% of total supply, the proposal is vetoed.

Voting weight is read from ERC20Votes checkpoints at the block the proposal was created. Tokens bought or borrowed after that block do not count, which prevents flash-loan vetoes.

Execution and scheduling

When the window closes without a veto, anyone can call execute(). The registry points the hook to the new program and draws the time of the next round from block.prevrandao:

nextRound = block.timestamp + 1 hours + (block.prevrandao % 4 hours);
Note. prevrandao can be slightly influenced by a block proposer. That is acceptable for scheduling, because the time of a round does not move funds. It is not used for anything that pays out.

06Programs

The initial set. New programs are added only through rounds.

programhookwhat it does
CONSTRUCTBaseHookPlain fee and split, no extra logic. The audited default and the only emergency fallback.
BURN-FUBuybackBurnHookConcentrates the burn share into bursts when buy pressure is high.
ZIONFeeVaultHookHolds the LP share in a vault that holders can claim from each epoch.
KEYMAKERLPBoostHookWeights LP rewards toward long-lived, wide-range positions.
EMPAntiMEVHookRejects same-block sandwich patterns and raises fees for detected bots.
THE ORACLEVolatilityFeeHookSets the fee from realised volatility, block by block, within the bounds.

07Roles and permissions

No single key can both propose and approve. Each role is a separate address with a narrow scope.

rolecancannot
Swarmsubmit pulses; create proposalsapprove its own proposals; exceed bounds; touch funds
Reviewers (3)sign approvals; 2 of them can trigger a revert to CONSTRUCTpropose programs; change parameters; deploy code
Holdersveto a proposal during its windowvote with tokens acquired after the proposal block
Anyonecall execute() after a window closesexecute before the window ends or after a veto

08Safety limits

These hold whatever program is loaded:

  • No role can mint tokens, change balances or replace the token contract.
  • No role can withdraw pool liquidity. LP tokens are locked at launch.
  • Fee and split bounds are constants in the hook.
  • Programs run with a gas limit. A program that reverts or runs out of gas falls back to CONSTRUCT behaviour for that swap, so swaps never get stuck.
  • Two reviewers can revert the hook to CONSTRUCT at any time. This can only load the audited base program, never new code.
Risk. Uniswap V4 hooks are complex, and a bug in the hook or a program could affect swaps or fees. The contracts will be audited before launch. An audit lowers risk but does not remove it.

09Glossary

Program
A contract that implements one fee strategy. The hook runs exactly one at a time.
CONSTRUCT
The base program, loaded at launch and on every emergency revert.
Déjà vu
A parameter pulse. It happens every 30 minutes and never changes code.
The choice
A round that can replace the active program, every 1–5 hours at random.
Red pill
Accepting a proposal. It is the default if holders do nothing.
Blue pill
Vetoing a proposal. It needs 10% of supply.
Swarm
The group of automated agents that monitors the pool and drafts changes.
Review bounty
The fee share that pays reviewers for checking programs.

10Status and disclaimers

  • Pre-launch. The contracts described here are not deployed yet and have not been audited. Numbers on the main site are a live simulation.
  • Subject to change. Parameters, bounds and timings may change before deployment. The deployed contracts are the final reference.
  • Reviewers. The review layer is designed for independent AI agent reviewers such as IMD agents. Which reviewers take part will be confirmed before launch.
  • No promise of return. $MORPHEPE is a memecoin. It has no intrinsic value and gives no right to profits. Nothing here is financial advice.
  • Parody. Independent community project, not affiliated with Warner Bros., The Matrix, Matt Furie, identity.md, Claus Network or Uniswap.