Timelock Updates

ReferralStorageTimelock.setHandler removes the delay for any IHandlerTarget, not just ReferralStorage. If this timelock is ever made gov/admin of some other handler-gated contract, the multisig can bypass the usual 24 hour handler flow there too. This broadens the scope of the timelock from "referral storage only" change.

Consider shrinking the contract to:

• keep only referral-specific methods and variables
• narrow setHandler so it can only target the intended ReferralStorage
• remove non-referral vault / GLP / token admin functions

The newly deployed Avalanche ReferralStorageTimelock at 0x370a34F6200770d79b54080150B61C0326208Ac5 is not configured identically to the currently live Avalanche referral governor.

In particular the old live Avalanche referral governor 0xa252b87040E4b97AFb617962e6b7E90cB508A45F returns maxMarginFeeBasisPoints = 500 but the new ReferralStorageTimelock returns maxMarginFeeBasisPoints = 40.

The deployment script comment is also inconsistent with the configured value, suggesting this may be an unintended config drift: 40, // maxMarginFeeBasisPoints 5%

While the intended use of this contract appears to be referral administration only, the contract still inherits broader timelock functionality such as fee and leverage-related operations. As a result, this mismatch creates avoidable configuration ambiguity and could produce unexpected behavior if the contract is later used beyond referral actions.

Confirm whether the Avalanche value 40 was intentionally chosen.

If the goal is to preserve existing behavior of the live referral governor, update the deployment/configuration to match the current live value 500.

The newly deployed Timelocks on Arbitrum are configured with glpRewardRouter = 0x159854e14A862Df9E39E1D128b8e5F70B4A3cE9B, while the active reward router is 0x5E4766F932ce00aA4a1A82d3Da85adf15C5694A1 and feeHandler = 0x7cC506C8d711C2A17B61A75bd082d2514160baAd, while the active fee handler is 0x7EB417637a3E6d1C19E6d69158c47610b7a5d9B3.

This should not affect the intended use of the timelocks for payments and referral handling. However, if a related function like unstakeAndBurnGlp is ever used, the call may revert or operate against an outdated contract, causing unexpected behavior.

Update the timelock configuration to use the active contract addresses, or set the fields to address(0). Consider removing the non-payment/referral flows entirely.

Note: Also check that Position Manager contract 0x75E42e6f01baf1D6022bEa862A28774a9f8a4A0C points to the current live one.

Arbitrum and Avalanche use the same 5-of-8 signer set, while MegaETH also uses a 5-of-8 Safe but replaces one signer with a different address.

The following signer set is used for Arbitrum and Avalanche:

• 0x43A0272D6f74706A8F6F3097FBEd9119567f6bBd
• 0x32660E5Fe1C5d10330c019Df4eb522A78c1EC896
• 0x25B889f14B9E5bB65F97b456dcd1ce8a5ab0D855
• 0xd32b86F984254246005a1c1c5e0b6A48743Ddc93
• 0x49C9F377d48c417FEB1f4fb32BF2D9Eb04112Da3
• 0x9fCA624E05EfA27205e905a40f9cEE9cb455D890
• 0xeAA5600595a64a23480b2DF5FCA35A2867c912Ea
• 0xFbf5dC7C8911Bf3434e855374eC81414E44E2b12

MegaETH uses the same threshold, but a different signer set:

• 0x43A0272D6f74706A8F6F3097FBEd9119567f6bBd
• 0x32660E5Fe1C5d10330c019Df4eb522A78c1EC896
• 0x25B889f14B9E5bB65F97b456dcd1ce8a5ab0D855
• 0xd32b86F984254246005a1c1c5e0b6A48743Ddc93
• 0x49C9F377d48c417FEB1f4fb32BF2D9Eb04112Da3
• 0x9fCA624E05EfA27205e905a40f9cEE9cb455D890
• 0x89efEB90827965f3C26C8eb959f73696f0f7183d
• 0xFbf5dC7C8911Bf3434e855374eC81414E44E2b12

The signer delta is:

• Removed on MegaETH: 0xeAA5600595a64a23480b2DF5FCA35A2867c912Ea
• Added on MegaETH: 0x89efEB90827965f3C26C8eb959f73696f0f7183d

Verify that the divergence is intentional.