Skip to content

Add v4 fee tier families and part-2 activation via tiered adapter swap - #150

Open
ccashwell wants to merge 4 commits into
mainfrom
ccashwell/v4-part2-and-families
Open

Add v4 fee tier families and part-2 activation via tiered adapter swap#150
ccashwell wants to merge 4 commits into
mainfrom
ccashwell/v4-part2-and-families

Conversation

@ccashwell

Copy link
Copy Markdown
Member

What

Two governance proposals targeting Friday July 31, plus the contract additions they ship:

  1. Part 2/2 activation — activates v4 fees on Celo, Soneium, Worldchain, X Layer, and Zora
  2. Part-1 family upgrade — adds the new opt-in families on Ethereum, Arbitrum, Base, BNB Chain, Polygon, OP Mainnet, and Robinhood Chain

Both are implemented as a fee controller swap: the prereq script deploys a fresh, fully configured V4FeeAdapter + V4FeePolicy pair per chain ("tiered" generation) and hands authority to governance. Each proposal action is then a single PoolManager.setProtocolFeeController(tieredAdapter) per chain — no configuration calldata crosses a bridge. Follows the documented replacement sequence in docs/V4FeePolicy-governance-guide.md (setPolicy/controller last → no zero-fee window).

Contract changes (src/)

  • Added V4FeeAdapter.batchSetPoolOverride / batchClearPoolOverride
  • Added V4FeePolicy.batchSetFamilyDefault / batchClearFamilyDefault
  • Modified InvalidFeeValue on the adapter to carry (poolId, feeValue) so a mid-batch revert identifies the offending entry

New fee configuration (script/proposal-7/FamilyConstants.sol)

Per the decision thread (#pod-gov-acp 7/22): 12 self-opt-in tier families, family ID == flag bit, IDs 20–31 → 10, 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000 pips per direction. Plus a native-math opt-in rule (bit 255 → family 255). Rule priority: aggregator first (unchanged), tiers descending (multi-tier signal resolves to the highest), native-math last. 14 rules total (max 32).

Safety

  • Onchain parity checks: the prereq reads the live original policy and asserts the tiered policy reproduces it exactly (buckets, agg rule + defaults, all stable-pair fees, hook assignments) before ownership transfer. Config drift fails the deployment, not the vote.
  • Soneium/Worldchain/X Layer/Zora have no original deployment (records confirm) — parity auto-skips; the tiered pair is their first fee infra. Celo's never-activated original becomes an inert orphan.
  • Fees already pushed to PoolManagers are identical under the tiered policy → no retrigger needed at execution.

Validation

  • Full prereq simulation green on all 12 chains against live forks, using the intended deployer address (0x58e28b95a2ee57c4E90613AFce9e8CCEED3aB1E8) as sender. Deployer is gas-funded on all 12 chains.
  • Gas snapshots regenerated with forge test --isolate (matches CI); only the two V4 snapshot files differ from main.

Not in this PR / remaining

  • Prereq broadcasts (deployers to populate .records/DeployTieredV4FeeInfra.json)
  • Seatbelt PR entries once records exist
  • Description.sol timeline sections + final gov-team copy edit
  • Any new hook whitelist additions that land before the prereqs run (one-line adds to hookAssignments)

Adds the batch functions requested in PR #133 review:
- V4FeeAdapter.batchSetPoolOverride / batchClearPoolOverride
- V4FeePolicy.batchSetFamilyDefault / batchClearFamilyDefault
- InvalidFeeValue on the adapter now carries (poolId, feeValue) so a
  revert mid-batch identifies the offending entry

Gas baselines regenerated with forge test --isolate to match CI.
…tiered adapter swap

Deploys a fully-configured tiered adapter+policy per chain (prereq), so
each governance action is a single setProtocolFeeController call:
- Prop.PartTwoActivation: celo, soneium, worldchain, xlayer, zora
- Prop.PartOneUpgrade: ethereum, arbitrum, base, bnb, polygon, optimism, robinhood

Tiered config replicates the live original deployment (parity-checked
onchain in the prereq where one exists) and adds 12 self-opt-in fee tier
families (10-1000 pips, IDs/bits 20-31) plus a native-math opt-in flag
rule (bit 255).

Deployment generations are named original/tiered rather than V1/V2 to
avoid confusion with Uniswap protocol versions.
Part 2/2 completes the chain rollout deferred from part 1 (GovernorBravo
10-action limit) and notes the tier families included in the newer
config. The family upgrade description explains the controller-swap
rationale and guarantees no currently-charged fee changes. Both carry
the tier appendix (IDs/bits 20-31, 0.1bp-10bp). Drafts for gov team
review; timeline sections omitted until posting dates are set.
// moment the proposal repoints the PoolManager. Compare against live original state,
// not this script's inputs, so config drift shows up here and not in production.
//
// Part-2 chains have no original deployment — the tiered deployment is the first fee

@jtriley2p jtriley2p Jul 23, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: celo was already deployed, so this it correct for every part 2 network except celo

i'd just add Part-2 chains (with the exception of Celo) have no original deployment ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants