Add v4 fee tier families and part-2 activation via tiered adapter swap - #150
Open
ccashwell wants to merge 4 commits into
Open
Add v4 fee tier families and part-2 activation via tiered adapter swap#150ccashwell wants to merge 4 commits into
ccashwell wants to merge 4 commits into
Conversation
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.
jtriley2p
reviewed
Jul 23, 2026
| // 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 |
Collaborator
There was a problem hiding this comment.
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 ..
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two governance proposals targeting Friday July 31, plus the contract additions they ship:
Both are implemented as a fee controller swap: the prereq script deploys a fresh, fully configured
V4FeeAdapter+V4FeePolicypair per chain ("tiered" generation) and hands authority to governance. Each proposal action is then a singlePoolManager.setProtocolFeeController(tieredAdapter)per chain — no configuration calldata crosses a bridge. Follows the documented replacement sequence indocs/V4FeePolicy-governance-guide.md(setPolicy/controller last → no zero-fee window).Contract changes (
src/)V4FeeAdapter.batchSetPoolOverride/batchClearPoolOverrideV4FeePolicy.batchSetFamilyDefault/batchClearFamilyDefaultInvalidFeeValueon the adapter to carry(poolId, feeValue)so a mid-batch revert identifies the offending entryNew 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
Validation
0x58e28b95a2ee57c4E90613AFce9e8CCEED3aB1E8) as sender. Deployer is gas-funded on all 12 chains.forge test --isolate(matches CI); only the two V4 snapshot files differ from main.Not in this PR / remaining
.records/DeployTieredV4FeeInfra.json)Description.soltimeline sections + final gov-team copy edithookAssignments)