Shape the future of Lazy Summer DAO. Cast your vote on active protocol upgrades and treasury allocations.
**0. Clarification** Initially proposed by [Curia](https://forum.summer.fi/t/sip5-23-delegate-rewards-framework-v2/793), this onchain proposal aims to transfer the requested funds ($4620 in SUMR) to a [Safe Multisig address](https://forum.summer.fi/t/sip5-23-delegate-rewards-framework-v2/793/4); as well as $420 in SUMR to CuriaLab. > *Pricing of SUMR token used was VVWAP of March daily prices (excluding first and last 5 days).* --- ### **1. Executive Summary** This proposal introduces Delegate Rewards V2, a redesigned incentive framework for Lazy Summer DAO’s Reward Framework Qualified Delegate (RFQD) program. Recognizing that the current framework (SIP5.6) has demonstrated a [structural misalignment](https://forum.summer.fi/t/delegate-responsibilities-next-steps-for-compensation-framework/568/17?u=curia) between treasury spend and governance workload, this proposal replaces it with a Dual-Pool system anchored to a fixed maximum quarterly budget of $4,200 USD ($1,400 USD monthly). To protect quorum stability and elevate contribution quality, the monthly budget features an 85% baseline allocation ($1,200) strictly rewarding delegates who maintain at least an 80% onchain voting participation rate, alongside a 15% allocation ($200) reserved exclusively for the top 3 delegates driving high-value forum discussions as measured by the Peer Recognition Score (PRS). Finally, to align delegate incentives with the long-term economic health of the protocol, mitigate sell pressure, and reduce administrative strain, all funds will be managed by a dedicated Quarterly-Funded Safe Multisig and distributed following a monthly governance approval vote (tracked under future SIP3.Y.Z proposals). ### **2. Motivation** The delegate compensation system formalized in SIP5.6 served Lazy Summer DAO well during its early governance phase. As the protocol’s complexity has grown—with DAO-managed vaults, expanded risk frameworks, and increasing governance throughput—the structural weaknesses of a static retainer model have become measurable and well-documented. **2.1 The Data Case for Reform** - **Inverted Pay-to-Workload [Ratio](https://forum.summer.fi/t/delegate-responsibilities-next-steps-for-compensation-framework/568/17?u=curia):** In [June 2025](https://forum.summer.fi/t/sip3-5-delegate-rewards-distribution-june/267), the DAO processed 1 proposal and paid out approximately 152,000 SUMR—the second-highest monthly total of the year. In May 2025, the DAO processed 14 proposals and paid only ~126,500 SUMR. Treasury spend had a negative correlation with governance workload. - **Rising Fixed Cost Baseline:** As the delegate set grew from 14 members (March) to 23 (December), the treasury baseline crept from ~118k to ~165k SUMR per month, driven by headcount rather than governance output. **2.2 Treasury Constraint** The design of this framework was ultimately dictated by our current financial constraints. As of March 5, 2026, the Lazy Summer treasury holds a total balance of ~$298k USD. However, it is heavily weighted in SUMR (93.4%), with light stablecoin (2.8%) and ETH (3.8%) balances.  While forum discussions initially suggested a $1,500/month payout for high-value contributors, the DAO agreed this must serve as a long-term “north star.” Implementing that model today would require ~$25,000/month, which creates an unsustainable sell-side pressure given our lean stablecoin runway. Consequently, all V2 framework decisions have been heavily optimized to fit within our current fiscal constraints. ### **3. Goals and Objectives** To directly address the issues outlined above, Delegate Rewards V2 was designed with three primary objectives: | **Goal** | **How this framework addresses it** | | --- | --- | | **Quorum Stability** | Pool A heavily weighted to make voting participation financially attractive | | **Contribution Quality** | Pool B rewards top PRS scorers; pre-vote forum engagement > post-vote | | **Treasury Sustainability** | Fixed quarterly budget cap; structured monthly payouts; quarterly reporting | ### 4. Proposed Framework Specifications To execute the goals outlined above, the V2 Delegate Reward Framework will operate under the following parameters: **4.1 The Quarterly Budget Cap** All delegate rewards will be drawn from a fixed quarterly SUMR budget, denominated in USD to provide predictability and recalculated at the start of each month. The budget for this framework is capped at **$4,200 USD equivalent per quarter** (distributed as $1,400 USD per month). **4.2 The Pricing Mechanism & Buffer** To protect both delegates and the treasury from SUMR price volatility, payouts are calculated at the start of each month using a 20-Day TWAP, trimming the first and last 5 days of the month to minimize volatility and manipulation. A conditional 10% buffer, funded from multi-sig operations costs outside the $1,400 budget, is added to cover potential price drops between the calculation date and the actual payout execution. If the token price holds steady, delegates receive a small bonus; if it drops by up to 10%, their baseline USD compensation remains fully protected. *Example: A 20-day TWAP of $0.20 converts the $1,400 budget to 7,000 SUMR; with the 10% buffer, the total payout becomes 7,700 SUMR.* **4.3 The Dual-Pool Split** The $1,400 monthly budget is divided into two distinct pools. This 85/15 split deliberately prioritizes quorum stability under a lean budget, while ensuring the contribution pool remains concentrated enough to be financially meaningful. - **Pool A — Voting Baseline (85% / ~$1,200/month):** Rewards consistent onchain participation. Making this pool highly attractive ensures quorum remains stable even as the delegate set grows. - **Pool B — Contributions (15% / ~$200/month):** Rewards high-value forum contributions that shape outcomes before the voting phase (forum analysis, proposal feedback, and thoughtful contributions) via the PRS leaderboard. **4.4 Baseline Eligibility (Pool A)** To unlock Pool A rewards, a delegate must achieve a minimum **80% voting participation rate** across all onchain proposals within the calendar month. This is a strict, binary outcome with no partial credit: | **Tier** | **Participation Rate** | **Outcome** | | --- | --- | --- | | **Standard** | 80–100% | Qualifies for the full Pool A reward. | | **Ineligible** | < 80% | No reward. Half-effort does not qualify. | - **Rationale:** The 80% floor secures quorum while providing a realistic buffer for missed proposals, balancing the protocol’s need for stability with the explicit part-time nature of the delegate role. **Voting Power Threshold:** To ensure the program attracts high-value contributors rather than becoming a low-effort yield source, the minimum delegated voting power required to qualify as a Qualified Delegate is locked at **1M SUMR.** **On Core Team Eligibility:** Core team members are eligible for rewards, but are expected to adhere to a formal "Honor System / Opt-Out" clause, self-assessing if their operational role gives them an informational advantage and opting out accordingly. **4.5 PRS Utilization (Pool B Payouts)** The $200 Contribution Pool is highly concentrated to incentivize deep protocol work (e.g., forum analysis, proposal feedbacks, thoughtful forum contributions). To ensure the reward is financially impactful and creates healthy competition, it will be split exclusively among the **top 3 highest-scoring delegates** on the monthly Peer Recognition Score (PRS) leaderboard as follows: **1st Place = 50% ($100), 2nd Place = 30% ($60), 3rd Place = 20% ($40).** **The PRS Eligibility Floor:** To protect the contribution pool from forum farming, delegates must meet a strict eligibility floor to appear on the PRS leaderboard in any given month: 1. **Voting Prerequisite:** Active governance participation is mandatory. A delegate *must* successfully meet the Pool A baseline (voting on at least 80% of proposals) to be eligible for Pool B rewards. 2. **Peer Validation:** To receive a PRS score, a delegate must have at least three (3) forum contributions that receive recognition (likes or direct validation) from **two or more** other Qualified Delegates. **The Peer Recognition Score (PRS)** Contribution quality will be measured through the Peer Recognition Score (PRS) which is an objective way to measure forum contribution using likes. To distinguish high-value insights from standard noise, the system weighs validation through likes based on reputation, meaning an endorsement from a delegate carries significantly more weight than a random like. For full details on PRS, please check this link: [**Summer Forum Peer Recognition Score**](https://www.notion.so/Summer-Forum-Peer-Recognition-Score-Draft-v1-3132dc1c1f7980babdc5ca85402dc2ec?pvs=21) ### **5. Success Metrics & Reporting** **5.1 Monthly Qualification Audit:** At the end of each month, eligibility is assessed. Jensei will track and confirm onchain voting participation rates (supported by Labs), while Curia will finalize and report the off-chain PRS leaderboard. **5.2 Quarterly KPI Report:** Curia will publish a quarterly report covering: * **Governance Stability:** Quorum consistency, actual increase in active voting power, increase in voting power. * **Forum Contribution:** Amount of comments, amount of proposals month by month. * **Decentralization Growth:** Increase in active delegates, Nakamoto coefficient. * **Protocol Impact:** TVL growth, New yield sources added. * **Monthly Top Contributors.** ### **6. Governance & Implementation Timeline** | Phase | Dates | Milestone / Action | | --- | --- | --- | | Week 0 | Feb 5 | Forum thread discussions initiated; delegates provided data exposing current model flaws, which were explored further in community calls. | | Week 1 | Feb 9–13 | Core Delegate Incentive Working Group (DIWG) formed; hosted Workshop Part 1 to explore tensions and options. | | Week 2 | Feb 16–20 | Hosted Workshop Part 2; secured foundational consensus on the budget cap, baseline voting, and Dual-Pool structure. | | Week 3 | Feb 23–27 | Published the Transparency Hub and updated the Miro board to track framework designs. | | Week 4-5 | Mar 2–13 | Drafted the V1 SIP skeleton and published to the forum as an open RFC to gather delegate feedback. | | Week 6-7 | Mar 16–27 | Extended DIWG review to integrate delegate feedback and lock in final execution mechanics (Multisig, TWAP, Sunset Clause). | | Week 8 | Mar 30–Apr 3 | (Current Phase) Finalized **SIP 5.23** published to the forum for final community review. | | Week 9 | Apr 6–10 | Active voting week. | | Launch | Mid-April | Official implementation for Q2. | ### **7. Framework Review & Sunset Clause** To avoid the inertia problem of V1, where a broken system persists despite the data, this framework includes a strict quarterly checkpoint. The DIWG will automatically trigger a formal framework review (and potential sunset) if either of the following thresholds are breached in the Quarterly KPI Report: * **Low Governance Throughput:** Fewer than 4 proposals go to a vote in a single quarter. * **Low Delegate Participation:** Pool A utilization falls below 60% of Qualified Delegates. **Sunset Execution Mechanics:** If a sunset is triggered, the framework will enter a wind-down state: * **Unspent Funds:** Any remaining SUMR in the Delegate Rewards Multisig will be immediately returned to the main DAO Treasury. * **Ongoing Obligations:** The final month's earned rewards and Curia's final data reporting retainer will be paid out before the remaining funds are returned. * **Reinstatement:** The framework will remain suspended until a new, revised Delegate Rewards SIP is submitted and approved via an onchain DAO vote. ### **8. Costs** **8.1 PRS and Data Provider Compensation** Curia will serve as the dedicated Data Provider for the V2 framework. Responsibilities include maintaining the PRS data pipeline, dashboard, and publishing the quarterly report. For managing this operational and technical overhead, Curia will receive a lean retainer of **$420 USD per quarter** (representing exactly 10% of the total quarterly delegate payout budget, ensuring administrative costs remain strictly capped). **8.2 Technical Execution & Distribution Costs** A lean budget for gas and signer stipends for the Safe Multisig will be introduced prior to the formal onchain vote. ### **9. Specification & Onchain Execution** If this SIP passes successfully, it will authorize the following immediate onchain actions to initiate the V2 Framework: 1. **Deploy the Delegate Rewards Safe Multisig:** A new Safe will be deployed with a 3-of-5 signature threshold. * *Signer Selection & Rotation:* Signers consist of active DAO contributors and delegates. If a signer becomes inactive or wishes to step down, the remaining signers will coordinate with the DAO to nominate and rotate in a new signer to maintain the 5-person set. * *Initial Signers:* * Jensei: `0x746bb7befd31d9052bb8eba7d5dd74c9acf54c6d` * Curia: `0x17296956b4E07Ff8931E4ff4eA06709FaB70b879` * Brian Adams | Sixty: `0xc2971FE806CE4438dA09e21fC7be7FB121Cf7e13` * Eren Targ: `0x6860036343886107dF9995Bd57e8945be8Cb69b7` * Raphael_Anode: `0x8795C17d02AF912C3586D03228e0165e9fdDE526` 2. **Transfer the Q2 Budget:** Transfer the Q2 equivalent of **$4,620 USD in SUMR** (The $4,200 quarterly budget + $420 for the 10% volatility/gas buffer) from the DAO Treasury directly to the newly deployed Delegate Rewards Safe Multisig. 3. **Transfer the Data Retainer:** Transfer the Q2 retainer of **$420 USD in SUMR** directly to Curia Lab (`0x17296956b4E07Ff8931E4ff4eA06709FaB70b879`) for Data and KPI reporting. ### **10. Call to Action** This is the finalized SIP draft based on the RFC consensus. Delegates and community members are invited to: - Review the final parameters and the newly added Sunset Clause. - Prepare for the upcoming Governance vote.
1. Overview: This sub-SIP details the payouts to be made for previously approved referral campaign, detailed here: [[SIP5.5] Enable onchain referrals and update AdmiralQuarters contracts on all chains to support Referral Codes](https://forum.summer.fi/t/sip5-5-enable-onchain-referrals-and-update-admiralquarters-contracts-on-all-chains-to-support-referral-codes/202). The payouts are made on Base and include; * 59,531.763016 $SUMR * 1,785.783027 $USDC * Total recipients: 672 --- ### 2. Motivation: The Lazy Summer Protocol’s referral program (as introduced in [SIP5.5]) requires monthly settlement of rewards earned by referrers and referees. March referral period has concluded, and users have accumulated SUMR and USDC allocations based on activity tracked in the [Lazy Beach Club Dune Dashboard](https://dune.com/lazysummer/lazy-beach-club). This SIP is necessary to transfer the required tokens to MERKL and enable users to claim their rewards transparently and trustlessly. --- #### 2.1 Historical monthly metrics for context |**2025/26**|**July**|**August**|**September**|**October**|**November**|**December**|**January**|**February**|**March**| | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | |Total SUMR|19,053.7651 SUMR|22,272.589 SUMR|40,582.388 SUMR|53,989.690 SUMR|52,967.722 SUMR|55,232.370 SUMR|58,981.345 SUMR|53,302.252 SUMR|59,531.763 SUMR| |Total USDC|687.48 USDC|789.35 USDC|1,337.99 USDC|1,728.54 USDC|1,691.77 USDC|1,747.70 USDC|1,857.97 USDC|1,594.91 USDC|1,785.78 USDC| |Total Recipients|227|334|419|547|569|579|666|679|672| --- ### 3. Specification: This SIP does **not** modify smart-contract logic. It authorizes: * Creation of a new MERKL campaign for March referral rewards. * Transfer of: * 59,531.763 SUMR * 1,785.78 USDC to the MERKL clams contract on Base. The payout distribution is predefined in the following .json , for both USDC and SUMR rewards: * [USDC](https://drive.google.com/file/d/1QGDlEUJfGEY9F9ho63zdU6AsMdUEby44) * [SUMR](https://drive.google.com/file/d/1lzdDVTtm4jqm31NomI_8D7piErQF032X) #### 3.1 Execution plan 1. Upon successful governance approval, and execution, the multisig triggers MERKL campaign creation. 2. SUMR and USDC amounts are transferred from the DAO treasury to the MERKL claims contract. 3. MERKL makes claims available for all eligible March participants. #### 3.2 Actors responsible Lazy Summer DAO - executes the MERKL campaign setup and performs token transfers, while MERKL handles distribution and claim logic. --- ### 4. Risk Assessment: **Technical Risk:** * Low. MERKL infrastructure has been user for prior referral payouts without issue. * Mitigation: Standard verification of token amounts and campaign parameters before vote. **Economic Risk:** * Minimal. Payouts were already committed under [SIP5.5] and reflect earned rewards. **Governance / Operational Risk:** * Requires accurate execution by the DAO. * Mitigation: Public spreadsheet, onchain transparency, and reproducible calculations. --- ### 5. Voting: > If **YES** - Approve SUMR and USDC disbursement to eligible March participants. > If **NO** - Do not disburse for March; continue with further discussion.
1. Overview: This proposal continues the delegate compensation program first approved in **[[SIP5.6]](https://forum.summer.fi/t/sip5-6-retroactive-compensation-for-delegates/229)**, this time applying it to **March 2026**. The goal is to sustain high-quality governance engagement and reward meaningful participation from active delegates across Lazy Summer Protocol governance. > Extending **[[SIP3.11.5]](https://forum.summer.fi/t/sip3-11-5-delegate-rewards-distribution-february/764)** (February Distribution) to **[SIP3.11.6]** (March Distribution). This proposal includes the 3rd distribution of rewards to [Aerodrome Metagovernance](https://forum.summer.fi/t/sip5-18-aerodrome-metagovernance/652) signers. --- ### 2. Motivation: Active and accountable delegates remain a cornerstone of protocol governance. March 2026 focused on compensation and rewards distribution, fees, security, and improving governance tooling. Compensating delegates for their time and contributions ensures continued accountability and engagement. --- ### 3. Specification: |**Item**|**Value**| | --- | --- | |Rewards Token|**[SUMR](https://basescan.org/token/0x194f360D130F2393a5E9F3117A6a1B78aBEa1624)**| |Source of Rewards|Lazy Summer **[DAO Treasury](https://basescan.org/address/0x447bf9d1485abdc4c1778025dfdfbe8b894c3796)** (Base)| |Total Distribution Amount|**440,065.99 SUMR**| |Distribution Schedule|One-time disbursement following onchain approval| |Eligibility Period|March 1st – March 31th (2026)| |Distribution Method|Direct transfer to verified delegate wallet addresses| #### 3.1 Aerodrome Metagovernance Stipend As covered in the [**[SIP5.18]**](https://forum.summer.fi/t/sip5-18-aerodrome-metagovernance/652) the Aerodrome Metagovernance signers requested to include a monthly payment. Labs Co team members (@chrisb, @halaprix, @jensei) has confirmed waiver of their stipend - therefore, the DAO spending on monthly payment now includes @MasterMojo and @Sixty in March delegate rewards distribution. ##### 3.1.1 Stipend Calculation Methodology 1. **Daily Prices & Volumes Used** | Date | Close Price (USD) | Volume (USD) | | ------ | ----------------- | ------------ | | Mar 05 | 0.00342 | 7,850 | | Mar 06 | 0.00338 | 7,420 | | Mar 07 | 0.00335 | 6,980 | | Mar 08 | 0.00333 | 6,540 | | Mar 09 | 0.00329 | 6,210 | | Mar 10 | 0.00326 | 5,980 | | Mar 11 | 0.00322 | 5,740 | | Mar 12 | 0.00319 | 5,420 | | Mar 13 | 0.00317 | 5,110 | | Mar 14 | 0.00315 | 4,880 | | Mar 15 | 0.00312 | 4,540 | | Mar 16 | 0.00310 | 4,210 | | Mar 17 | 0.00308 | 3,990 | | Mar 18 | 0.00305 | 3,740 | | Mar 19 | 0.00303 | 3,981.86 | | Mar 20 | 0.00300 | 398.99 | | Mar 21 | 0.00301 | 5,812.62 | | Mar 22 | 0.00302 | 644.71 | | Mar 23 | 0.00299 | 490.91 | | Mar 24 | 0.00296 | 398.80 | | Mar 25 | 0.00296 | 4,415.65 | | Mar 26 | 0.00297 | 148.11 | > ***Source dataset:** CoinGecko [historical export](https://www.coingecko.com/en/coins/summer-2/historical_data?start=2026-03-03&end=2026-03-26).* 3. **Volume-Weighted Average Trading Price (VWAP)** For VWAP we need price×volume. We will exclude first and last 5 days of the month from the VWAP weighting* (meaning VWAP is for Mar 05-26). `VWAP (Mar 05–26) ≈ $0.00318` 4. Convert $500 to SUMR * 500/0.00318 ≈ **157,233 SUMR** 5. Transfer 500 USDC to each signer to lift up the strain on SUMR in the DAO Treasury (Total 1000 USDC). --- ### 4. Risk Assessment: * Onchain vote will authorize SUMR disbursement from the DAO Treasury. * Delegate participation data was sourced from the **[Lazy Summer Governance Dashboard](https://dune.com/lazysummer/lazy-summer-dao-governance)**. * The final delegate list and breakdown is made publicly available **[here](https://docs.google.com/spreadsheets/d/e/2PACX-1vTOcW98nSMK1XdSVZ268c3M6MCqY-xvlr7Ji1GUjk0v9V_iXJfrpqE1wxJW1JcvRAaSb6LApoz3xonx/pubhtml#gid=1359441710)**. * Any entity may only receive compensation through a single verified delegate address. * Suspected Sybil delegates will be excluded, subject to verification by @Recognized_Delegates. --- ### 5. Voting: > If **YES** - Approve **440,065.99 SUMR** disbursement to eligible **March** delegates. > If **NO** - Do not compensate for **March**; continue with further discussion.
1. Overview: This proposal authorizes the **distribution of contributor compensation for the SUMR Transfer Readiness Working Group (TR-WG)** following the successful delivery of its mandate and the subsequent activation of SUMR transferability. The working group charter was ratified under [**SIP5.8**](https://forum.summer.fi/t/sip5-8-sumr-tr-wg-charter/310), which allocated **up to 120,000 SUMR** for community contributors upon completion of the group’s deliverables. With SUMR transferability now enabled and the expected post-activation window elapsed, this proposal executes the **one-time compensation payment to eligible TR-WG contributors**. *** ## 2. Motivation: The **Transfer Readiness Working Group (TR-WG)** was established in July 2025 to coordinate the cross-disciplinary work required to safely enable **SUMR token transferability**. **The working group brought together contributors across several domains:** * Governance Design * Tokenomics Modeling * Protocol Readiness * Liquidity Considerations * Communications and Narrative Coordination The TR-WG produced a series of outputs that ultimately contributed to the governance process enabling **SUMR transferability**, which has since been activated onchain. Under **SIP5.8**, contributors external to the Labs Co core team were eligible for **a one-time compensation payment of up to 10,000 SUMR**, contingent on participation and delivery. Now that SUMR transferability has been enabled through governance, and the expected post-activation period has elapsed, the DAO can proceed with fulfilling the compensation commitment defined in the original charter. This SIP therefore executes the **final compensation distribution to TR-WG contributors**, completing the working group lifecycle. For transparency purposes I would like to ask [@Raphael\_Anode](https://forum.summer.fi/u/raphael_anode) to update the [**SUMR TR-WG Checklist**](https://forum.summer.fi/t/sumr-tr-wg-checklist/341). *** ## 3. Specification: This proposal authorizes the **distribution of SUMR compensation from the DAO treasury** to eligible contributors of the TR-WG. ### 3.1 Budget | Parameter | Value | | -------------- | ------------------------------------------------------------------------------------------------- | | Maximum Budget | 120,000 SUMR | | Payment Time | One-time compensation | | Source | [Lazy Summer DAO Treasury](https://debank.com/profile/0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796) | > *As defined in **SIP5.8**, **Labs Co team members are excluded from compensation**, with the budget reserved for external/community contributors.* ### 3.2 Eligible Contributors The following [@TR-WG](https://forum.summer.fi/groups/tr-wg) members are eligible for compensation under the charter: | Contributor | Affiliation | | ------------------------------------------------------------------------ | ---------------- | | [@Raphael\_Anode](https://forum.summer.fi/u/raphael_anode) | Anode | | [@vumichien](https://forum.summer.fi/u/vumichien) | Community | | [@MasterMojo](https://forum.summer.fi/u/mastermojo) | Community | | [@jengajojo\_daoplomats](https://forum.summer.fi/u/jengajojo_daoplomats) | DAOplomats | | [@crunchy\_vertex](https://forum.summer.fi/u/crunchy_vertex) | Community | | [@TokenBrice](https://forum.summer.fi/u/tokenbrice) | DeFi Collective | | [@BaptistellaLabs](https://forum.summer.fi/u/baptistellalabs) | Baptistella Labs | | [@FBrinkkemper](https://forum.summer.fi/u/fbrinkkemper) | Community | | [@Sixty](https://forum.summer.fi/u/sixty) | Community | | [@Eren\_DAOplomats](https://forum.summer.fi/u/eren_daoplomats) | DAOplomats | ### 3.3 Compensation Structure Each contributor shall receive **10,000 SUMR**. > *I would like to ask **everyone eligible (tagged above)** to share/confirm wallet address where the funds should be distributed to. **I aim to publish this proposal onchain ~18.03.2026.*** ### 3.4 Execution Upon approval: * SUMR will be transferred from the **Lazy Summer DAO Treasury**. * Payments will be distributed to eligible contributors. * The working group will be considered **fully concluded**. *** ## 4. Risk Assessment: This proposal introduces **minimal technical or governance risk**, as it executes a previously approved compensation framework. ### 4.1 Treasury Impact The maximum allocation of **120,000 SUMR** was already authorized under SIP5.8. This proposal simply executes the payment tied to the working group’s completion. ### 4.2 Governance Precedent Working group compensation tied to defined deliverables creates: * clear incentives for contributors * predictable governance expectations * accountability tied to milestone completion This structure aligns with best practices for **DAO contributor coordination**. *** ## 5. Voting: > If **YES** - Approve the distribution of TR-WG compensation as defined under SIP5.8 and authorize the transfer of SUMR from the DAO treasury to eligible contributors. > If **NO** - Do not execute compensation payments at this time, and reopen discussion regarding contributor compensation.
1. Overview: This SIP proposes that the Lazy Summer DAO formally adopt the SEAL (Security Alliance) Whitehat Safe Harbor Agreement, enabling authorized whitehats to intervene during active exploits under predefined rules, incentives, and legal protections. > ***RFC:*** [*\[RFC\] Adopt the SEAL Whitehat Safe Harbor Agreement*](https://forum.summer.fi/t/rfc-adopt-the-seal-whitehat-safe-harbor-agreement/586) *** ## 2. Motivation: Lazy Summer Protocol operates DAO-governed, risk-assessed vaults designed for simplicity and passive participation. While audits, monitoring, and risk reviews are essential preventative controls, they do not eliminate the possibility of active exploits. During a live exploit, speed and clarity matter more than process purity. Traditional responsible disclosure frameworks are too slow in situations where funds are actively being drained. The [SEAL Safe Harbor Agreement](https://frameworks.securityalliance.org/safe-harbor/overview) creates a pre-authorized, rule-bound framework that allows vetted whitehats to intervene immediately and recover funds without legal ambiguity. **Adopting Safe Harbor provides:** * A last-line-of-defense mechanism during active exploits. * Clear predefined bounty expectations. * Removal of post-exploit negotiation ambiguity. * Alignment with industry-standard incident response practices. *** ## 3. Specification: ### 3.1 Adoption of the SEAL Safe Harbor Agreement Lazy Summer DAO will formally adopt the SEAL Whitehat Safe Harbor Agreement under the following finalized parameters. #### **Protocol Details** Protocol Name: `Lazy Summer Protocol` Summer Governor: `0xBE5A4DD68c3526F32B454fE28C9909cA0601e9Fa` Timelock Address: `0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796` Protocol Access Manager: `0xf389BCEa078acD9516414F5dabE3dDd5f7e39694` #### **Bounty Terms** Based on [\[RFC\]](https://forum.summer.fi/t/rfc-adopt-the-seal-whitehat-safe-harbor-agreement/586) feedback and informal signaling: * **Percentage:** 10% of recovered funds * **Per-Incident Cap:** $100,000 USD * **Aggregate Cap:** $100,000 USD * **Retainable:** No (non-retainable; all funds must be returned first) * **Identity Requirement:** Pseudonymous **Clarifications:** * Whitehats may intervene only during active exploits. * All recovered funds must be returned to designated recovery addresses within 72 hours. * Bounty is paid after verification by the protocol. * Safe Harbor does not apply to routine bug bounty disclosures or security research. #### **Diligence Requirements** Whitehats acting under Safe Harbor must: * Act in good faith to minimize harm. * Only interact with contracts strictly necessary to halt or mitigate the exploit. * Return all recovered funds within 72 hours. * Identify themselves pseudonymously to designated security contacts for coordination. #### **Designated Security Contacts** The following contributors are nominated as Safe Harbor coordination contacts: * LS Guardians: [@jensei](https://forum.summer.fi/u/jensei) [@blockful](https://forum.summer.fi/u/blockful) [@Raphael\_Anode](https://forum.summer.fi/u/raphael_anode) [@halaprix](https://forum.summer.fi/u/halaprix) [@MasterMojo](https://forum.summer.fi/u/mastermojo) [@JavierD](https://forum.summer.fi/u/javierd) [@chrisb](https://forum.summer.fi/u/chrisb) [@Sixty](https://forum.summer.fi/u/sixty) - via [Signal Group](https://signal.group/#CjQKIFoFcIiS83AKZWLlTRhfovPSFGGkoGpP5VLNCGWeNe4_EhDehOfY_zDHUB91ipCnX3tj) * [@BlockAnalitica](https://forum.summer.fi/u/blockanalitica) (on risk coordination) * Labs Co * Lazy Summer Foundation #### **Chains & Asset Recovery Addresses** Recovery addresses are defined per supported chain and controlled by the DAO or Guardian structure. **DAO-governed Timelock/Treasury Address:** * Ethereum: `0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796` * Optimism: `0x25B97896A1d731875B3aec785977E421029Fc90A` * Unichain: `0x25B97896A1d731875B3aec785977E421029Fc90A` * Sonic: `0x4c32A28AD95deaBc06bF7C83AdEbCF6fe6721ED9` * Arbitrum: `0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796` * Base: `0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796` * HyperEVM: `0x0C939b702524fDaBa4914E905Bcb850182308141` **In case of timelock compromise, use Guardian Multisig:** * Ethereum: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` * Optimism: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` * Unichain: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` * Sonic: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` * Arbitrum: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` * Base: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` * HyperEVM: `0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4` **Initial coverage includes:** * Ethereum: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-1/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-1/deployed_addresses.json) * Optimism: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-10/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-10/deployed_addresses.json) * Unichain: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-130/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-130/deployed_addresses.json) * Sonic: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-146/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-146/deployed_addresses.json) * Arbitrum: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-42161/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-42161/deployed_addresses.json) * Base: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-8453/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-8453/deployed_addresses.json) * HyperEVM: [summer-earn-protocol/packages/deployment/ignition/deployments/chain-999/deployed\_addresses.json at main · OasisDEX/summer-earn-protocol · GitHub](https://github.com/OasisDEX/summer-earn-protocol/blob/main/packages/deployment/ignition/deployments/chain-999/deployed_addresses.json) #### **Scope Definition** ChildContractScope: `All` All contracts and child contracts deployed prior and after to adoption are in scope. ### 3.2 Implementation Plan 1. **Register Agreement Onchain** The finalized parameters will be registered in the SEAL Safe Harbor Registry: `0x1eaCD100B0546E433fbf4d773109cAD482c34686` 2. **Instruct Labs Co to** [**Update Terms of Service & Docs**](https://frameworks.securityalliance.org/safe-harbor/self-adoption-guide/#4-update-terms-of-service--docs) To ensure all users are informed and legally covered. 3. **An official announcement shall be shared across all communication channels, explaining the adoption and its significance to the community.** *** ## 4. Risk Assessment: Operational risk can involve miscommunication during an exploit leading to confusion. **Mitigation:** * Predefined recovery addresses * Designated security contacts * Registry-based transparency *** ## 5. Voting: > If **YES:** Lazy Summer DAO formally adopts the SEAL Whitehat Safe Harbor Agreement. > If **NO:** The DAO declines to adopt the Safe Harbor framework at this time.
Summary This is a cross-chain governance proposal to add 1 new Ark to the existing LazyVault_LowerRisk_USDT Fleet on mainnet. ## Motivation Expanding this fleet with additional an Ark will enhance the protocol's capabilities on mainnet. ## Technical Details - Hub Chain: base (Production) - Target Chain: mainnet - Fleet Commander: 0x17Ee2D03e88b55E762c66C76ec99C3A28A54AD8d - Number of Ark to add: 1 ## New Ark Address 1. `0x00589A321a766BDeB6E6C344B4C4Cc8A661fFBB8` ## Specifications ### Actions This proposal will execute the following actions on mainnet: 1. Grant COMMANDER_ROLE to Fleet Commander for the Ark 2. Add the Ark to the Fleet Commander ### Cross-chain Mechanism This proposal uses LayerZero to execute governance actions across chains. ## References Discourse: https://forum.summer.fi/t/sip2-57-onboard-sky-money-usdt-savings-to-usdt-lr-fleet-mainnet/770