all contracts - base
SummerGovernorV2 - base, sonic, arbitrum, mainnet

staking token will be : https://basescan.org/address/0x194f360D130F2393a5E9F3117A6a1B78aBEa1624
reward tokens -> sumr,usdc,usdt,weth,wbtc,eurc

Even though Sumr token is not globaly transferable right now, it should be considered that when the protocol is deployed Sumr token will be globally transferable and transferEnabled will be true.

• vesting wallet escrow will not be initialized with factories at start
• Summer staking will not be initialized with non zero caps at start
• already deployed timelock contracts will be used with new governance contract

SummerStaking.sol

• updateLockupBucketCap(Bucket _bucket, uint256 _newCap) (onlyGovernor)
  • Limits: none on _newCap.
  • Semantics: cap=0 disables staking in that bucket (always exceeds); type(uint256).max effectively unlimited.
• updatePenaltyEnabled(bool _penaltyEnabled) (onlyGovernor)
  • Limits: boolean only.
• rescueToken(address _token, address _to) (onlyGovernor)
  • Limits: _token != address(WRAPPED_SUMMER_TOKEN); _to any non-zero address implied by SafeERC20 semantics.
• Notable hard caps (not admin-settable): MAX_LOCKUP_PERIOD = 3*365d, MAX_AMOUNT_OF_STAKES = 1000, penalty bounds 2%–20%.

SummerVestingWalletsEscrow.sol

• addVestingFactory(address _vestingFactory) (onlyGovernor)
  • Limits: _vestingFactory != 0, must not already be added (duplicate prevented).
• removeVestingFactory(address _vestingFactory) (onlyGovernor)
  • Limits: _vestingFactory != 0, must exist in set.
• rescueWallet(address _wallet, address _newOwner) (onlyGovernor)
  • Limits: _newOwner != 0.
• rescueToken(address _token, address _to) (onlyGovernor)
  • Limits: _token != 0, _to != 0.
• Constructor address[] _initialVestingFactories
  • Limits: each entry must be non-zero; no array length cap beyond gas.

StakedSummerToken.sol (xSUMR)

• addStakingModule/removeStakingModule(address) (onlyGovernor)
  • Limits: add requires non-zero; remove no additional constraints.
  • Effect: grants/revokes MINTER_ROLE and BURNER_ROLE.
• grantMinterRole/revokeMinterRole(address) (onlyGovernor)
  • Limits: none on address (but role semantics apply).
• pause/unpause() (onlyGuardianOrGovernor)
  • Limits: boolean state toggle only.
• Safety constraints (not admin-set):
  • Transfers disabled except mint/burn (enforced by _canTransfer).
  • burnFrom allowed only by token owner or addresses with BURNER_ROLE (and still respects allowance).
  • Direct AccessControl.grantRole/revokeRole are disabled; must use the provided governed functions.

SummerGovernorV2.sol

• Constructor-enforced threshold constraint:
  • proposalThreshold must be within [1000e18, 100000e18] at deploy time (via _validateProposalThreshold).
• Cross-chain governance:
  • sendProposalToTargetChain(...) (onlyGovernance, onlyHubChain)
  • No explicit array-length checks; relies on matching lengths as used by OZ Governor machinery on the destination.
• Execution/funding:
  • _payNative(uint256) requires contract balance ≥ quoted native fee.
  • receive() accepts ETH only from LayerZero endpoint or the timelock().

No. For integrated protocols, we place no additional limits on admin-set values or array lengths; those protocols’ own governance is assumed trusted.

-

-

Voting power is always equal to the amount of staked summer / summer is staked vesting wallet

The StakingRewardsManagerBase, SummerGovernor, and SummerTimelockController contracts form the basis of the V2 version. They were chosen because they have existing security audits from Chainsecurity and Prototech, which was preferable to developing new contracts from scratch. A summary of the audit reports and their findings is available in the README_GovernanceV2.md file.

Previous audits (with overlapping scope):

• StakingRewardsManagerBase.sol,ProtocolAccessManaged.sol,ConfigurationManaged.sol REPORT
• StakingRewardsManagerBase.sol, SummerGovernor.sol REPORT

Known Issues and Limitations

Rewards duration immutability in StakingRewardsManagerBase

In StakingRewardsManagerBase, calling notifyRewardAmount(rewardToken, reward, newRewardsDuration) for an already-configured reward token will revert if newRewardsDuration differs from the stored rewardsDuration for that token. This is enforced to prevent mid-stream schedule changes:

// For existing reward tokens, check if current period is complete
if (_isRewardToken(rewardToken)) {
    if (newRewardsDuration != rewardTokenData.rewardsDuration) {
        revert CannotChangeRewardsDuration();
    }
}

• To change a reward token's rewardsDuration, wait until the current reward period finishes, then call setRewardsDuration(rewardToken, newDuration). Passing a different duration via notifyRewardAmount will fail for existing tokens.
• Operational implication: integrations that rotate reward programs must either reuse the same duration or sequence a setRewardsDuration after the prior period ends. Attempting to extend/shorten during an active period is intentionally disallowed.
• There is a mismatch between comment and code

• https://summer.fi
• https://docs.summer.fi/lazy-summer-protocol/lazy-summer-protocol
• https://github.com/OasisDEX/summer-earn-protocol/blob/a01063ce6d2ed917b6a104a64835a9e73b5da5f0/packages/gov-contracts/README_Governance_v2.md
• https://github.com/OasisDEX/summer-earn-protocol/blob/a01063ce6d2ed917b6a104a64835a9e73b5da5f0/packages/gov-contracts/README.md

The StakingRewardsManagerBase is forked from the Synthetix rewards contract and adds support for multiple reward tokens. SummerStaking inherits from StakingRewardsManagerBase.

Governance is advised to wait for the rewards period to end - even if it was the same duration (if not - to use the setRewardsDuration and then notify). In general, governance should be assumed trusted enough not to cause any issues/problems to the protocol and/or the users.