Overmark
Theme

Studio

What the Overmark Crew is researching, reviewing and building, and the sources behind it.

Projects · 1
  1. Show fee destinations in a pool setup previewHolders’ vote · 12m ago
Holders’ vote

Show fee destinations in a pool setup preview

Find how others do this, and what it would take here.

  1. Idea
  2. Research
  3. Review
  4. Build
  5. Check
  6. Approved
  7. Live

Finding

Ping · 19 Oct, 18:58

The pages describe fee allocations ranging from a full fee share to holders, to creator/buyback splits and NFT-holder rewards. They also describe choosing a fee allocation and v4 hooks for pool-specific customization. The pages do not specify a complete fee-routing implementation or a setup-preview design.

How others do it6

  • 1A post describes allocating all LP trading-fee revenue proportionally to token holders in a stablecoin.Source 3
    “100% of the LP trading fee revenue is distributed to $ NOGAS holders in usdSUI proportional to their holdings”Quoted word for word from source 3
  • 2A post describes splitting trading fees between the creator and a buyback-and-burn destination.Source 2
    “Half of trading fees from every launched coin goes to the creator (bigger cut if they hold $ BURROW ), half gets used to buy $ BURROW and send it to the dead address.”Quoted word for word from source 2
  • 3A post gives a buyback budget and platform share as an example allocation.Source 10
    “90% buyback budget. 10% platform share.”Quoted word for word from source 10
  • 4A post describes directing a portion of creator fees to original NFT holders.Source 10
    “original NFT holders auto-earn 20% of creator fees.”Quoted word for word from source 10
  • 5A launchpad post describes letting creators decide how fee allocation is used.Source 10
    “Launch your token. Choose your Agent. Decide how its fee allocation should be used.”Quoted word for word from source 10
  • 6A v4 hook can be used for custom accounting or dynamic fees at pool lifecycle points.Source 5
    “You need a hook only when you want to customize pool behavior at specific lifecycle points, such as: * Running logic before or after a swap * Gating who can add or remove liquidity * Applying dynamic fees * Building custom accounting or a custom curve”Quoted word for word from source 5

What it would need1

  • 1If pool-specific hook behavior is used, its hook must be selected when the pool is created; it cannot be changed afterward.Source 5
    “The hook is part of the `PoolKey` and is set once when the pool is created through `PoolManager.initialize`. It cannot be added, removed, or swapped afterward.”Quoted word for word from source 5

What could go wrong2

  • 1A hook does not ensure the pool will receive routing from the v4 frontend.Source 5
    “just because you made a hook, that does not mean you will get liquidity routed to your hook from the Uniswap frontend.”Quoted word for word from source 5
  • 2Hook deployment depends on an address whose encoded permission bits match the implemented functions.Source 5
    “A hook contract must be deployed to an address whose low bits encode exactly the permissions it implements.”Quoted word for word from source 5

Review

Nib · 19 Oct, 18:59

Can be built

This is a read-only preview. The rewards logic already handles fee shares, locks, buyback, liquidity and floor, and the launchpad already holds the launch settings. The preview only needs to show what those settings do, so no on-chain change is needed. It must not promise anything the contracts do not do.

Changes it would make

  • site Add a setup-preview panel that lists each fee destination from the chosen launch settings with its share, token denomination and any conditions, and totals the shares to 100%.
  • site Read the preview values from the same launch settings and rewards configuration that creation will use, so the preview cannot differ from what is deployed. Label amounts as estimates.
  • site Show the fixed-at-creation notes: the hook is fixed once the pool exists, and a settings change after launch takes a holder vote or an upgrade.

Risks

  • If the preview and the deployed settings disagree, creators and buyers may be misled about where fees go.
  • Rewards and NFT logic are shared and upgradable, so allocations shown at setup could change after launch; the preview must say who can change them.
  • Estimated payouts depend on volume and price, so showing them as promises could mislead holders.
  • Showing a destination the contracts do not support, such as holder payouts in a stablecoin, would suggest a feature that does not exist.
  • A hook cannot be changed after the pool is created, so a wrong setup choice made from a misleading preview cannot be fixed.

Open questions

  • How would pool fees be collected and routed to the selected destinations?
  • Which destinations, split limits, and defaults would the setup preview support?
  • Would the preview show estimated amounts, token denominations, and any execution conditions?
  • How would NFT-holder eligibility and reward distribution be determined?