Shape the future of Lazy Summer DAO. Cast your vote on active protocol upgrades and treasury allocations.
1. Overview: Extend the governance voting period from **3 days to 7 days**, leaving the voting delay and timelock queue unchanged. | Parameter | Current | Proposed | |----|----|----| | Voting delay | 86400 (1 day) | unchanged | | **Voting period** | **259200 (3 days)** | **604800 (7 days)** | | Timelock queue (`minDelay`, all chains) | 86400 (1 day) | unchanged | | Satellite execution | +1 day | unchanged | | Quorum | 30% | unchanged (SIP4.2) | **End-to-end:** 1 day delay + 7 days voting + 1 day queue = **9 days** on the hub, **10 days** including satellite relay, compared to 5 and 6 days today. --- ### 2. Motivation: **Review capacity is shrinking; scrutiny time should grow to compensate.** The Labs Co. is winding down, BA Labs has stepped down as risk curator, and the Summer.fi UI sunsets on 31 August 2026. SIP4.2 raised quorum to 30% and the proposal threshold to 100,000 stSUMR on the reasoning that safeguards should track the protocol's risk profile. The same reasoning applies to time: the DAO is moving to a caretaker posture where proposals are reviewed by a smaller set of delegates, less continuously. **The voting window is the right one to extend.** * It is where scrutiny actually happens. Delegates read, discuss and vote during this window. The queue is a passive wait that nobody monitors by default. * **Three days is tight for a 30% quorum** once delegates disperse. Seven days guarantees every proposal stays open across a full calendar week (surviving weekends, holidays and part-time attention) and should *reduce* failed-quorum risk rather than add friction. * **Extending the queue instead would compound across chains for no extra review.** Every satellite action already passes the hub's full voting and queue windows before being relayed; the satellite leg is pure execution of something already approved. A 7-day queue on all chains would push cross-chain execution to 20 days while adding no window that anyone is actually watching. > A guardian can cancel a proposal directly on Governor V2. Extending the voting period widens the window in which a problem is *noticed*; the cancel path is what allows it to be *stopped*. **Nothing remaining is time-critical.** No Ark onboarding, no rebalancing, no emissions tuning. Withdrawals are permissionless ERC-4626 redemptions unaffected by any governance parameter, and emergency pausing runs through the Guardian Module rather than a vote, so this does not slow incident response. --- ### 3. Specification: The Governor's clock is timestamp-based (`SummerToken.clock()` returns `block.timestamp`; `CLOCK_MODE()` returns `mode=timestamp`), so `votingPeriod` is denominated in **seconds**. | Parameter | Value | |----|----| | Function | `setVotingPeriod(uint32)` | | Target | `SummerGovernorV2` (Base) — `0x4cEeE1b6289624d381383C1Bb42B118d5f2c3274` | | Value | `0` | | Argument | `604800` (7 days) | | Selector | `0xe540d01d` | | Calldata | `0xe540d01d0000000000000000000000000000000000000000000000000000000000093a80` | | Authority | `onlyGovernance` → executes via the Timelock | | Risk level | Low (single settings update; no funds move, no role changes) | Proposals are created and voted on exclusively on Base; satellites are execute-only, so no satellite calls are needed. --- ### 4. Risk Assessment: * **Technical.** One settings update on an OZ `GovernorSettings` extension. No funds move, no roles change. The clock unit is confirmed as seconds, removing the only real encoding risk. * **Reduced agility.** Proposal-to-execution moves from 5 → 9 days on the hub, 6 → 10 days cross-chain. Acceptable given nothing remaining is time-critical, and emergency response does not run through governance. * **In-flight proposals.** Applies to proposals created after execution; open votes keep their original schedule. * **External expiry constraint.** Actions with short external validity cannot survive governance delay at all — Merkl claims, whose proofs expire in \~4 hours, are the live example. These must be structured as governance-approved authorizations executed by a fast actor. * **Reversible.** A future SIP can restore a shorter period. * **No effect on user funds.** Withdrawals are permissionless and ungated by governance parameters. --- ### 5. Voting: > If **YES** - extend the voting period from 3 days to 7 days. > If **NO** - keep the voting period at 3 days.
1. Overview: Grant `GUARDIAN_ROLE` and set a guardian expiration on **HyperEVM**, bringing it in line with the four chains covered by SIP0.2/SIP0.3. Two calls per guardian on HyperEVM's `ProtocolAccessManager`, executed from the Base governor and relayed via LayerZero. HyperEVM currently has no active guardians, so the two HyperEVM Fleets have **no emergency pause capability**, the only chain in that position. --- ### 2. Motivation: **HyperEVM was added after the Guardian Module was established** and was not included in the SIP0.2 grant or the SIP0.3 renewal, which covered four chains. `FleetCommander.pause()` is `onlyGuardianOrGovernor`. With no active guardian, the only path is a full governance cycle 5 days today. **Two things are needed, and granting the role alone is not enough.** `isActiveGuardian` requires `hasRole(GUARDIAN_ROLE, account) && guardianExpirations[account] > block.timestamp`. `grantGuardianRole` only sets the role; the expiration defaults to `0`, leaving the guardian permanently inactive. **A grant without a matching `setGuardianExpiration` is a no-op in practice**. --- ### 3. Specification: | Parameter | Value | |----|----| | Network | HyperEVM (chain ID 999) | | Contract | `ProtocolAccessManager` — `0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | | Authority | `onlyGovernor` / `onlyRole(GOVERNOR_ROLE)` → executes via the HyperEVM Timelock | | Execution | Base governor → LayerZero → HyperEVM timelock (`0x244c6EFC140b9cC4D69d3bf4d9137Dc4195Be86c`) | | Risk level | Low–Medium (role grant; mirrors the existing guardian mandate) | #### 3.1 Call order: both calls, in this order, per guardian **Call 1: grant the role** | Parameter | Value | |----|----| | Function | `grantGuardianRole(address account)` | | Target | `0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | | Account | `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` | **Call 2: set the expiration** *(without this the guardian is inactive)* | Parameter | Value | |----|----| | Function | `setGuardianExpiration(address account, uint256 expiration)` | | Target | `0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | | Account | `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` | | Expiratio | 1800000000 | #### 3.2 Choosing the expiration value `setGuardianExpiration` validates `expiration - block.timestamp` against: | Bound | Value | |----|----| | `MIN_GUARDIAN_EXPIRY` | 7 days | | `MAX_GUARDIAN_EXPIRY` | 180 days | The argument is an **absolute unix timestamp**, and the bound is checked against `block.timestamp` **at execution**, not at proposal time. #### 3.3 Verification after execution On the HyperEVM `ProtocolAccessManager`: * `hasRole(0x55435dd261a4b9b3364963f7738a7a662ad9c84396d64be3365284bb7f0a5041, <guardian>)` → `true` * `guardianExpirations(<guardian>)` → the intended timestamp * `isActiveGuardian(<guardian>)` → **`true`** this is the one that matters --- ### 4. Risk Assessment: * **Technical.** Two role-management calls on an existing contract. No funds move. * **Relay dependency.** Execution depends on the Base → HyperEVM LayerZero path. This path has been exercised, SIP0.4 included HyperEVM revocations. * **Privilege expansion, bounded and intended.** Guardians gain pause authority over the two HyperEVM Fleets. This is the same mandate the DAO already approved on four chains, with the same set and the same automatic expiry. Guardians cannot cancel guardian-expiry proposals at either the Governor or Timelock layer, so they cannot entrench themselves. * **Reversible.** `revokeGuardianRole(address)` (`0x4b4b5389`) via a fresh SIP; powers also lapse automatically at expiry. --- ### 5. Voting: > If **YES** - grant `GUARDIAN_ROLE` and set a guardian expiration on HyperEVM for the confirmed SIP0.3 guardian set. > If **NO** - leave HyperEVM without an active guardian.
1. Overview: Grant `GUARDIAN_ROLE` and set a guardian expiration on **HyperEVM**, bringing it in line with the four chains covered by SIP0.2/SIP0.3. Two calls per guardian on HyperEVM's `ProtocolAccessManager`, executed from the Base governor and relayed via LayerZero. HyperEVM currently has no active guardians, so the two HyperEVM Fleets have **no emergency pause capability**, the only chain in that position. --- ### 2. Motivation: **HyperEVM was added after the Guardian Module was established** and was not included in the SIP0.2 grant or the SIP0.3 renewal, which covered four chains. `FleetCommander.pause()` is `onlyGuardianOrGovernor`. With no active guardian, the only path is a full governance cycle 5 days today. **Two things are needed, and granting the role alone is not enough.** `isActiveGuardian` requires `hasRole(GUARDIAN_ROLE, account) && guardianExpirations[account] > block.timestamp`. `grantGuardianRole` only sets the role; the expiration defaults to `0`, leaving the guardian permanently inactive. **A grant without a matching `setGuardianExpiration` is a no-op in practice**. --- ### 3. Specification: | Parameter | Value | |----|----| | Network | HyperEVM (chain ID 999) | | Contract | `ProtocolAccessManager` — `0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | | Authority | `onlyGovernor` / `onlyRole(GOVERNOR_ROLE)` → executes via the HyperEVM Timelock | | Execution | Base governor → LayerZero → HyperEVM timelock (`0x244c6EFC140b9cC4D69d3bf4d9137Dc4195Be86c`) | | Risk level | Low–Medium (role grant; mirrors the existing guardian mandate) | #### 3.1 Call order: both calls, in this order, per guardian **Call 1: grant the role** | Parameter | Value | |----|----| | Function | `grantGuardianRole(address account)` | | Target | `0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | | Account | `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` | **Call 2: set the expiration** *(without this the guardian is inactive)* | Parameter | Value | |----|----| | Function | `setGuardianExpiration(address account, uint256 expiration)` | | Target | `0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | | Account | `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` | | Expiratio | 1800000000 | #### 3.2 Choosing the expiration value `setGuardianExpiration` validates `expiration - block.timestamp` against: | Bound | Value | |----|----| | `MIN_GUARDIAN_EXPIRY` | 7 days | | `MAX_GUARDIAN_EXPIRY` | 180 days | The argument is an **absolute unix timestamp**, and the bound is checked against `block.timestamp` **at execution**, not at proposal time. #### 3.3 Verification after execution On the HyperEVM `ProtocolAccessManager`: * `hasRole(0x55435dd261a4b9b3364963f7738a7a662ad9c84396d64be3365284bb7f0a5041, <guardian>)` → `true` * `guardianExpirations(<guardian>)` → the intended timestamp * `isActiveGuardian(<guardian>)` → **`true`** this is the one that matters --- ### 4. Risk Assessment: * **Technical.** Two role-management calls on an existing contract. No funds move. * **Relay dependency.** Execution depends on the Base → HyperEVM LayerZero path. This path has been exercised, SIP0.4 included HyperEVM revocations. * **Privilege expansion, bounded and intended.** Guardians gain pause authority over the two HyperEVM Fleets. This is the same mandate the DAO already approved on four chains, with the same set and the same automatic expiry. Guardians cannot cancel guardian-expiry proposals at either the Governor or Timelock layer, so they cannot entrench themselves. * **Reversible.** `revokeGuardianRole(address)` (`0x4b4b5389`) via a fresh SIP; powers also lapse automatically at expiry. --- ### 5. Voting: > If **YES** - grant `GUARDIAN_ROLE` and set a guardian expiration on HyperEVM for the confirmed SIP0.3 guardian set. > If **NO** - leave HyperEVM without an active guardian.
> **Connected RFC:** https://forum.summer.fi/t/rfc-revoke-curator-roles-across-all-fleets/905 > **Related:** https://forum.summer.fi/t/ba-labs-stepping-down-as-risk-curator-for-the-lazy-summer-protocol/899 --- ### 1. Overview: Revoke `CURATOR_ROLE` from **BA Labs (`0xa16f07b4dd32250dec69c63ecd0aef6cd6096d3d`) on every Fleet across all networks**, following BA Labs' [announcement](https://forum.summer.fi/t/ba-labs-stepping-down-as-risk-curator-for-the-lazy-summer-protocol/899) that it is stepping down as risk curator. Executed as `revokeCuratorRole(fleetCommander, account)` calls on each chain's `ProtocolAccessManager`. --- ### 2. Motivation: Per the connected RFC: with all Arks removed under SIP2.60, a Fleet has nothing to allocate between, so the curator mandate has no remaining function. It is a live permission that nothing is actively watching, on a protocol whose risk-management capacity is winding down and whose front-end sunsets on 31 August 2026. Two developments since the RFC make this concrete: * **BA Labs has publicly announced it is stepping down as risk curator.** Revoking the onchain role is the corresponding onchain act. * **The role holder enumeration is now [published](https://forum.summer.fi/t/rfc-revoke-curator-roles-across-all-fleets/905/3)** (thanks @halaprix for the role-decoding interface), so the call list below is complete rather than indicative. --- ### 3. Specification: | Parameter | Value | |----|----| | Action | `revokeCuratorRole(fleetCommanderAddress, account)` | | Account revoked | BA Labs curator: `0xa16f07B4Dd32250DEc69C63eCd0aef6CD6096d3d` | | Revocations | 14 (Ethereum 5, Base 3, Arbitrum 3, HyperEVM 2, Sonic 1) | | Networks | Ethereum, Base, Arbitrum, Sonic, HyperEVM | | Contract | `ProtocolAccessManager` per chain | | Selector | `0xe9296665` | | Authority | `onlyGovernor` → executes via the Timelock | | Execution | Base governor → LayerZero → destination timelock | | Risk level | Low (permission removal; no funds move; no role grants) | #### 3.1 Calls **Ethereum:** `ProtocolAccessManager 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694` | \# | Fleet | Fleet address | |----|----|----| | 1 | LazyVault_HigherRisk_WETH | `0x2E6abcbCCeD9Af05bc3B8a4908e0c98c29A88e10` | | 2 | LazyVault_LowerRisk_WETH | `0x67e536797570b3d8919Df052484273815A0aB506` | | 3 | LazyVault_LowerRisk_USDC *(exploited)* | `0x98C49e13bf99D7CAd8069faa2A370933EC9EcF17` | | 4 | LazyVault_LowerRisk_USDT | `0x17Ee2D03e88b55E762c66C76ec99C3A28A54AD8d` | | 5 | **LazyVault_HigherRisk_USDC** *(exploited)* | `0xE9cDA459bED6dcfb8AC61CD8cE08E2D52370cB06` | **Arbitrum:** `ProtocolAccessManager 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694` | \# | Fleet | Fleet address | |----|----|----| | 6 | LazyVault_LowerRisk_USDC_2 | `0x71d77C39dB0eB5d086611a2e950198E3077cf58A` | | 7 | LazyVault_LowerRisk_USDC | `0x4F63cfEa7458221CB3a0EEE2F31F7424Ad34bb58` | | 8 | LazyVault_LowerRisk_USDT | `0x98C49e13bf99D7CAd8069faa2A370933EC9EcF17` | **Sonic:** `ProtocolAccessManager 0xAFb8a8beA8F7CdB4b65437b0c5963dc7Cd270bC6` | \# | Fleet | Fleet address | |----|----|----| | 9 | LazyVault_LowerRisk_USDCe | `0x507A2D9E87DBD3076e65992049C41270b47964f8` | **HyperEVM:** `ProtocolAccessManager 0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f` | \# | Fleet | Fleet address | |----|----|----| | 10 | LazyVault_LowerRisk_USDC | `0x252E5Aa42c1804b85b2ce6712cd418A0561232Ba` | | 11 | LazyVault_LowerRisk_USDT | `0x2cC190fb654141DfBEaC4c0f718F4d511674D346` | **Base:** `ProtocolAccessManager 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694` | \# | Fleet | Fleet address | |----|----|----| | 12 | LazyVault_LowerRisk_EURC | `0x64Db8f51f1bf7064BB5A361a7265F602d348E0f0` | | 13 | LazyVault_LowerRisk_USDC | `0x98C49e13bf99D7CAd8069faa2A370933EC9EcF17` | | 14 | LazyVault_LowerRisk_WETH | `0x2bb9ad69FEBA5547b7cD57aAfe8457D40bF834af` | --- ### 4. Risk Assessment: * **Technical.** Permission removal only. No funds move, no approvals, no role *grants*. Verify each chain's `ProtocolAccessManager` on its explorer before encoding a wrong AccessManager silently targets the wrong surface. Note Ethereum/Base/Arbitrum share `0xf389BCEa…` while Sonic and HyperEVM differ. * **Operational sequencing.** `removeArk` is `onlyGovernor` and runs through the Timelock, not the curator, so SIP2.60 does not depend on BA's curator role. But any curator-gated divestment or rebalance would. * **Governance/security.** Single-purpose, reduces privileged surface, grants nothing. Explicitly does **not** touch the Guardian module (being renewed under SIP0.3), `SUPER_KEEPER_ROLE`, `COMMANDER_ROLE`, or `ADMIRALS_QUARTERS_ROLE` a wider role teardown is a separate discussion. * **Reinstatement.** Re-granting `CURATOR_ROLE` requires a fresh onchain-approved SIP. --- ### 5. Voting: > If **YES** - revoke `CURATOR_ROLE` from BA Labs (`0xa16f07B4Dd32250DEc69C63eCd0aef6CD6096d3d`) on all 14 listed Fleets across Ethereum, Base, Arbitrum, Sonic and HyperEVM. > If **NO** - leave the roles granted.
| Parameter | Value | |----|----| | Fleets | `DAO_LazyVault_USDC_1`, `DAO_LazyVault_WETH_1`, `LazyVault_HigherRisk_WETH`, `LazyVault_LowerRisk_USDC`, `LazyVault_LowerRisk_USDT`, `LazyVault_LowerRisk_WETH` | | Network | Mainnet | | Arks removed | 37 | | Unpause fleet | Yes — `LazyVault_LowerRisk_USDC` only | | Set tip rate | Already `0` | | Risk mgmt | **mixed** — dao-risk-managed (2 Fleets) + ba-risk-managed (4 Fleets) | | Execution | Base governor → LayerZero (`dstEid=30101`) → mainnet timelock `0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796` | ##### Actions (in order): `removeArk()` × 11 on DAO_USDC_1; × 6 on DAO_WETH_1; × 7 on HigherRisk_WETH; then `unpause()` + `removeArk()` × 1 on LowerRisk_USDC; then `removeArk()` × 6 on LowerRisk_USDT; × 7 on LowerRisk_WETH. **39 calls total.** ##### Arks removed: **DAO_LazyVault_USDC_1** — `0xd77F9a9F2b0C160dB3e9dC2Cce370c1a740C76fc` *(dao-risk-managed)* `MorphoVault-usdc-Gauntlet_USDC_RWA-1`, `MorphoVault-usdc-Smokehouse_USDC-1`, `MorphoV2Vault-usdc-Clearstar_USDC_Core-1`, `MorphoV2Vault-usdc-Steakhouse_High_Yield_Instant-1`, `MorphoV2Vault-usdc-Steakhouse_Prime_Instant-1`, `MorphoV2Vault-usdc-Steakhouse_Reservoir_USDC-1`, `SkyRewards-SPK-USDC-1`, `Syrup-usdc-1`, `MorphoV2Vault-usdc-Yearn_OG_USDC_v2-1`, `MorphoV2Vault-usdc-Steakhouse_3Fx_USDC-1`, `MorphoV2Vault-usdc-Gauntlet_USDC_Prime-1` **DAO_LazyVault_WETH_1** — `0x0C1FBCCC019320032D9acD193447560C8C632114` *(dao-risk-managed)* `MorphoV2Vault-weth-Gauntlet_WETH_Prime_V2-1`, `MorphoV2Vault-weth-Steakhouse_Prime_Instant_V2-1`, `MorphoVault-weth-Steakhouse_WETH-1`, `MorphoVault-weth-Yearn_OG_WETH-1`, `MorphoVault-weth-Gauntlet_WETH_Prime-1`, `MorphoV2Vault-weth-Yearn_OG_WETH_V2-1` **LazyVault_HigherRisk_WETH** — `0x2E6abcbCCeD9Af05bc3B8a4908e0c98c29A88e10` `MorphoVault-weth-Yearn_OG_WETH-1`, `Spark-weth-1`, `CompoundV3-weth-1`, `AaveV3-weth-1`, `FluidLite-weth-1`, `Origin_ARM-weth-steth-1`, `Origin-weth-1` **LazyVault_LowerRisk_USDC** — `0x98C49e13bf99D7CAd8069faa2A370933EC9EcF17` *(exploited Fleet)* `unpause()` — not before 2026-07-23T10:38:35Z (minimum pause time, now elapsed); then `Syrup-usdc-1` **LazyVault_LowerRisk_USDT** — `0x17Ee2D03e88b55E762c66C76ec99C3A28A54AD8d` `MorphoV2Vault-usdt-Sky_USDT_Savings_V2-1`, `AaveV3-usdt-1`, `MorphoV2Vault-usdt-Steakhouse_Prime_Instant-1`, `Spark-usdt-1`, `MorphoVault-usdt-Gauntlet_USDT_Prime-1`, `MorphoVault-usdt-Steakhouse_USDT-1` **LazyVault_LowerRisk_WETH** — `0x67e536797570b3d8919Df052484273815A0aB506` `Spark-weth-1`, `MorphoVault-weth-Steakhouse_WETH-1`, `AaveV3-weth-1`, `CompoundV3-weth-1`, `MorphoV2Vault-weth-KPK_ETH_Prime_v2-1`, `MorphoV2Vault-weth-Steakhouse_Prime_Instant_V2-1`, `MorphoVault-weth-Gauntlet_WETH_Prime-1` ##### Voting: > If **YES** - execute the above for the six Mainnet Fleets (remove all remaining Arks; unpause LazyVault_LowerRisk_USDC so its final Ark can be removed). > If **NO** - leave the Fleets unchanged.
> **Connected RFC:** https://forum.summer.fi/t/rfc-operational-realignment-for-the-transition-period/875 --- ### 1. Overview: Reconfigure SUMR Staking V2 so the lockup system winds down cleanly, in two governor-only parameter changes: 1. **`NoLockup` bucket cap → `type(uint256).max`** (uncapped); staking remains fully open at the no-lockup tier. 2. **All six lockup bucket caps → `0`** (disabled); no new lockups of any duration can be created. 3. **`updatePenaltyEnabled(false)`** -> the early-unstake penalty no longer applies, so existing lockers can exit without a fee. > **No existing stake is closed, moved, or altered by this proposal, and no voting power is confiscated.** Staking stays open, so governance participation is preserved. --- ### 2. Motivation: https://forum.summer.fi/t/rfc-operational-realignment-for-the-transition-period/875 (A2) set out the case for ending the SUMR Staking V2 reward programs: SUMR emissions run to `periodFinish` and are not renewed, and the USDC revenue share is discontinued. It also stated the fairness principle this SIP implements, that **the early-unstake penalty should be waived first, so lockers are not trapped between an unrewarded lock and a penalized exit.** Poll A2.2 carried a separate signal on exactly that.  The bucket change applies the same logic one step earlier in the lifecycle. A lockup is a bilateral bargain: the staker forgoes liquidity for up to three years, and the DAO compensates that with a quadratic reward multiplier funded by emissions and revenue share. With both sides of that compensation ending, continuing to *issue* new lockups would bind users into commitments the DAO has already decided not to pay for. Disabling those buckets stops new entrants taking the trade; uncapping `NoLockup` keeps staking, delegation and voting fully available. --- ### 3. Specification: #### 3.1 Parameters | Parameter | Value | |----|----| | Contract | `SummerStaking` -> `0xcA2e14c7C03C9961c296C89e2d2279F5F7DB15b4` | | Network | Base | | Related | `StakedSummerToken` (stSUMR) `0x7cC488F2681cFC2A5E8A00184bfA94ea6d520D1c` | | Authority | `onlyGovernor` → executes via `SummerTimelockController` `0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796` | | Execution | Base governor → Timelock (direct on Base hub, no LayerZero relay) | | Calls | 7 × `updateLockupBucketCap` + 1 × `updatePenaltyEnabled` = **8** | | Risk level | Low technically; the material consideration is governance/quorum (§4) | #### 3.2 Calls Function signatures, verified: ``` function updateLockupBucketCap(Bucket _bucket, uint256 _newCap) external onlyGovernor; function updatePenaltyEnabled(bool _penaltyEnabled) external onlyGovernor; ``` `Bucket` enum values, verified in order: | \# | Bucket | Lockup range | New cap | Effect | |----|----|----|----|----| | 0 | `NoLockup` | 0 seconds | `type(uint256).max` | **Uncapped — staking stays fully open** | | 1 | `ShortTerm` | 1 second – 14 days | `0` | Disabled *(already 0 by default)* | | 2 | `TwoWeeksToThreeMonths` | \>14 – 90 days | `0` | Disabled | | 3 | `ThreeToSixMonths` | \>90 – 180 days | `0` | Disabled | | 4 | `SixToTwelveMonths` | \>180 – 365 days | `0` | Disabled | | 5 | `OneToTwoYears` | \>365 – 730 days | `0` | Disabled | | 6 | `TwoToThreeYears` | \>730 – 1095 days | `0` | Disabled | `updatePenaltyEnabled(false)` — disables the early-unstake penalty. `type(uint256).max` = `115792089237316195423570985008687907853269984665640564039457584007913129639935` (`0xff…ff`, 32 bytes). Cap semantics are explicit in the contract: `cap == 0` disables a bucket (any positive stake reverts with `Staking_BucketCapExceeded`); `cap == type(uint256).max` means unlimited. #### 3.3 Verified effects * **Existing stakes are untouched.** Bucket caps are enforced **only on the stake path** (`_stakeLockup` → `_wouldExceedBucketCap` → revert). `updateLockupBucketCap` writes `bucketData[_bucket].cap` and emits `LockupBucketUpdated`; it does not iterate positions, alter `lockupEndTime`, or move tokens. Setting a cap to `0` blocks *new* entries and does nothing to existing ones. * **Voting power is not affected by bucket choice.** stSUMR is minted **1:1 on the raw staked amount**. The quadratic multiplier (`WEIGHTED_STAKE_BASE + WEIGHTED_STAKE_COEFFICIENT × t²`) applies to the *weighted* balance that drives **rewards accounting only** - bucket caps are applied to the unweighted amount. Since `StakedSummerToken` is the `ERC20Votes` token, a staker's governance weight is their raw stake regardless of lockup tier. **Disabling lockup buckets therefore does not change anyone's voting power.** * **Penalty disablement is a clean boolean.** `penaltyEnabled = false` makes `calculatePenaltyPercentage` return 0. The penalty is *not* burned - `_handleTokenTransfersOnUnstake` sends the penalty to `treasury()`. Disabling it means early exits no longer route a fee to the treasury. * **Penalty being removed, for the record:** fixed **2%** if remaining lockup < `FIXED_PENALTY_PERIOD` (110 days), otherwise linear `timeRemaining / MAX_LOCKUP_PERIOD × 20%`, i.e. up to **20%** at three years. After lockup ends, and for `NoLockup`, the penalty is already 0. * **Reversible.** Both setters are governor-callable in either direction; a later SIP can restore caps or re-enable the penalty. --- ### 4. Risk Assessment: **Technical: low.** Two governor-only setters on one contract, on one chain, no relay. No funds move, no roles granted, no positions closed, no user action required. Failure mode is a revert. Guardian pre-review of decoded calldata. **Governance/quorum:** Voting power under Governance V2 is stSUMR, so it is unaffected by *bucket* changes. Removing the penalty gives every locked staker an unpenalized exit at once, and with rewards ending there is little reason to stay. A large voluntary exit would reduce total stSUMR and therefore quorum. **Economic.** Unpenalized exits may increase circulating SUMR and create sell pressure, and the DAO treasury is heavily SUMR-weighted. The treasury also forgoes future penalty income (which, with rewards ending, is a fee charged on people leaving a program the DAO has itself discontinued). Both are foreseeable consequences of the fairness decision rather than arguments against it. **Conflict of interest.** Delegates voting on this are voting on terms affecting their own staked positions and voting weight. Worth stating on the record, as RFC did for delegate compensation. --- ### 5. Voting: > If **YES** - set the `NoLockup` bucket cap to `type(uint256).max`, set all six lockup bucket caps to `0`, and call `updatePenaltyEnabled(false)`, per the decoded calldata published in this thread. > If **NO** - leave the staking bucket configuration and early-unstake penalty as they are.