[RFC] Operational Realignment for the Transition Period

General Discussion Request for Comment [RFCs]
, , , ,
1

Subtitle: Sunsetting Legacy Incentive Programs, Confirming the Security Mandate, and Reviewing Treasury-Support Positions.

1. Summary:

This RFC gathers, into a single thread, a set of related decisions the DAO needs to make about its operating posture during the current transition, and asks for a directional signal on each via separate polls (at the bottom of this proposal).

Following the protocol exploit, the wind-down of the Labs Co., and the open strategic question in [RFC] Determining the Future Direction of Lazy Summer DAO, several standing programs and mandates no longer fit the environment they were designed for. The proposal is to wind down discretionary incentive spend that has lost its purpose, re-confirm and extend the one mandate that protects the DAO during the transition (the Guardian Module), and bring the DAO’s treasury-support positions and their operating multisigs under review for consolidation.

This is deliberately structured as one RFC with independent polls so @Recognized_Delegates attention stays in one place while [RFC] Determining the Future Direction of Lazy Summer DAO is live, and so each item can be supported or rejected on its own merits. Based on the polls, items with clear support will be promoted either as individual SIPs or, since the executable items are almost all on Base batched into a common SIP where it makes sense to do so. The Guardian item (Part B) is time-critical and will proceed on its own accelerated track regardless of the others.

The three parts map directly onto the wind-down bullets enumerated in [RFC] Determining the Future Direction of Lazy Summer DAO.

Option B → minimizing ongoing operational costs (Part A); maintaining governance security while treasury decisions are finalized (Part B), and consolidating assets held across operational multisigs into governance-controlled custody/timelock (Part C).

2. Context & Motivation:

2.1 Why now, and why together

Each program below was designed for a growing, pre-exploit protocol. Rather than bring seven or eight disconnected proposals that each re-litigate the same backdrop, this RFC states the shared context once and lets @Recognized_Delegates signal on each decision independently.

**The unifying thesis is to stop paying for outcomes the DAO can no longer produce, keep the protections it still needs, and take control of the assets it still holds. That is why the Guardian mandate (Part B) is being extended, not sunset, and why the treasury positions (Part C) are being brought under review and custody rather than reflexively liquidated.

2.2 The case holds under either outcome of RFC in regards to the future direction of the DAO

  • Option A (Continue Building): programs calibrated for the old protocol and old operating model should not be carried forward by default. Incentives for a rebuilt protocol should be redesigned deliberately, on a fresh thesis, with named operators; not inherited by auto-renewal. The security mandate, however, becomes more important during a rebuild, and the treasury positions should be consciously managed rather than left on autopilot.

  • Option B (Orderly Wind-Down): these are exactly the standing outflows, recurring governance obligations, and dispersed operational multisigs that an orderly wind-down consolidates and closes.

This RFC does not presuppose or advance either option. It is written to be correct under both, and can equally be read as input into the [RFC] Determining the Future Direction of Lazy Summer DAO discussion.

2.3 One item is time-critical

The Guardian Module (SIP0.2) was granted with a 180-day expiration, executed on Base on ~10 February 2026. That expiry falls around ~9 August 2026; roughly three weeks from this posting. The Guardian’s proposal-cancellation authority (the “with expiry date” guardian type) is the DAO’s fastest defence against governance attacks, and there has already been one attempt. If it lapses mid-transition, with a consolidating treasury as an attractive target, the DAO loses that defence at the worst possible moment. Part B therefore cannot wait on the debate over Part A, and is flagged throughout for an accelerated (and possibly expedited/EXP) track.

2.4 My Conflicts of interest Disclosed Up Front

In the interest of transparency: I, the author of this RFC am a signer and participant in several of the mandates under review, including the delegate-rewards multisig, the Guardian Module, the Arcadia PoL execution multisig, and the Aerodrome metagovernance multisig. Cutting delegate rewards touches my own potential compensation; extending the Guardian preserves a role I hold; the Part C positions are operated by multisigs I sign on. This is normal for a small, active DAO, but I wanted to name it here plainly so it is on the record. @Recognized_Delegates should weigh each poll accordingly, and other signers/operators are invited to confirm or contest the framing in discussion below.

3. Proposal:

[Part A] Sunset discretionary incentive programs

A1. Lazy Beach Club referral program (SIP5.5)

The growth thesis behind it is inoperative: vaults are paused, so there is no deposit flow to refer; the Labs Co. that ran the monthly code issuance, reconciliation and payout preparation is winding down; and the program has already effectively stopped. June 2026 settled 541.72 SUMR and 37.84 USDC across 94 recipients, down from ~59,500 SUMR / 672 recipients in March. SUMR referral emissions were already cut 80% in February 2026 (RFC) on sustainability grounds; that logic now applies with much more force, and the growth-side justification is gone.

Onchain referral rewards (USDC + SUMR) for users and integrators, was established under [SIP5.5] Enable onchain referrals and update AdmiralQuarters contracts on all chains to support Referral Codes, from [RFC] Enable onchain referral/revenue share mechanism for both Users and Integrators, settled monthly (SIP5.5.1–SIP5.5.11).

Hereby, I propose to let all referral rates to zero as of a cut-off (proposed 31 July 2026, 23:59 UTC); bring one final settlement sub-SIP (SIP5.5.12) covering accrual to the cut-off, via Merkl on Base; discharge the standing monthly-payout obligation. No onchain execution required as the admiralQuarters contracts keep accepting referral codes; those codes simply carry no entitlement. Existing Merkl claims remain claimable.

If instead it is to be continued, a named entity must step forward to run the monthly reconciliation (Dune), Merkl campaign setup, and payout preparation that Summer.fi/Labs previously performed. Absent a named operator, continuation is not operationally viable.

A2. SUMR Staking V2 reward programs (SIP3.13 / SIP3.17 / SIP3.19)

Two distinct reward streams are attached to SUMR Staking V2:

  1. SUMR emissions: 450,000 SUMR per 90-day period, most recently renewed under [SIP3.19].
  2. USDC revenue share: 20% of monthly protocol revenue, distributed via Merkl under the SIP3.13.x series (most recent: June 2026).

Both buy alignment with “protocol growth” that currently does not exist. Paying 450k SUMR/quarter for that alignment is not defensible at present treasury levels. The revenue share has collapsed to a rounding error: June revenue was $11,900.68, of which $2,380.14 went to stakers, with a further $73.61 paid to Merkl to distribute it. With vaults paused, June even had to switch from LVUSDC to plain USDC because LVUSDC cannot currently be minted (due to a pause).

Monthly USDC flow to stakers, SIP3.13.X series:

Dec '25 Jan '26 Feb '26 Mar '26 Apr '26 May '26 Jun '26
$5,775.20 $8,700.90 $5,638.93 $4,906.60 $3,858.90 $3,015.16 $2,380.14

Hereby, in regards to the following I propose to:

  • SUMR emissions: let the current SIP3.19 period run to its periodFinish (~late September 2026; exact value to be read from the staking contract) and do not renew. Already-streamed SUMR continues to accrue and remains claimable; not clawed back. No onchain action.
  • USDC revenue share: discontinue as of the cut-off (proposed 31 July 2026, 23:59 UTC); one final settlement sub-SIP (SIP3.13.7); thereafter 100% of the DAO’s revenue share accrues to the Timelock.

If instead the revenue share is to continue as with the referral program, a named entity must step forward to administer it each month. The monthly revenue reconciliation across five networks, the Merkl campaign creation, and the payout SIP. This has been carried by Summer.fi/Labs to date; with that capacity winding down, continuation without a named operator is not viable.

TipJar / TipStreams (verify before assuming): The 20% staker share has to date been calculated offchain and paid from the Treasury, not routed by a dedicated onchain tipstream. If so, discontinuing it requires no TipJar change; the funds simply remain in the Timelock. Before this is promoted to a SIP, the live TipJar configuration per chain (Ethereum, Base, Arbitrum, Sonic, HyperEVM) should be read and published, checking:

  1. whether any recipient is an address other than the Timelock, and
  2. any lockedUntilEpoch constraints. Retargeting a non-Timelock stream is a genuine consolidation action and belongs in Part C / a treasury SIP, not here.

Explicitly out of scope for this RFC: disabling the staking module (withdraw-only mode). SUMR Staking V2 is the source of voting power under Governance V2. Freezing new stakes freezes the delegate set (and combined with stakers exiting once rewards end) creates real quorum risk exactly when the DAO must pass consequential votes. If withdraw-only mode is later pursued (it is listed in [RFC] Determining the Future Direction of Lazy Summer DAO as Option B), it should be its own proposal, sequenced after the above mentioned RFC resolves, and the early-unstake penalty should be waived first so lockers are not trapped between an unrewarded lock and a penalised exit. Poll A2 includes a separate signal on the penalty waiver.

A3. Delegate Rewards Framework V2 (SIP5.23)

The RFQD delegate-compensation framework ([SIP5.23]): a fixed $4,200/quarter dual-pool system, funded quarterly to a 3-of-5 Safe, distributed monthly under the SIP3.11.x series. Q2 has been finalised with the June distribution.

[SIP5.23] Delegate Rewards Framework V2 contains a self-executing sunset clause: the framework enters wind-down if fewer than 4 proposals go to a vote in a quarter, or Pool A utilisation falls below 60% of Qualified Delegates. It also already specifies the mechanics: unspent SUMR in the rewards multisig returns to the Treasury, the final month’s earned rewards and @Curia’s final data retainer are paid, and reinstatement requires a fresh onchain-approved SIP. Given the current environment and governance throughput, the cleanest path is likely to invoke the existing clause rather than run a bespoke termination, but @Recognized_Delegates should confirm whether the Q2 KPI thresholds were in fact breached, or whether an explicit vote is preferred regardless.

Hereby, I propose to confirm the sunset (via the existing clause or explicit vote), fund the final earned month (executed), the final Curia retainer (executed), delivery of the quaterly KPI report by @Curia, and return unspent funds from the rewards Safe (0x9a218f744EE78E7a84e1C28acbcc2ce5cC72Bb0E) to the Treasury.

Note on COI: this is delegates voting on their own compensation.

[Part B] Confirm & extend the security mandate

B1. Extend Expiry and Re-confirm Signers of Guardian Module (SIP0.2)

A narrowly-scoped emergency multisig [SIP0.2] Establish Guardian Module & Emergency Risk Controls able to pause vaults, zero deposit caps, and cancel in-flight malicious proposals. Currently 8 signers, 6/8 threshold, 180-day expiry (~9 August 2026) via setGuardianExpiration on the ProtocolAccessManager on each chain.

In my honest opinion, during a transition and consolidation of treasury, unwinding positions, an open strategic question, the governance-attack surface is higher, not lower. Letting the Guardian lapse now would be the single most dangerous omission on this list. [RFC] Determining the Future Direction of Lazy Summer DAO Option B explicitly lists “maintaining governance security while treasury decisions are finalized.”

Two live design questions from the original thread:

  1. Threshold. 6/8 was contested at launch (@Ceazor, @chrisb: too slow for pure panic actions, which only pause/cap/cancel and move no funds). A renewal is the moment to decide whether to keep 6/8 or lower it (e.g. 3/8) for faster reaction, ideally paired with the periodic liveness check @Sixty proposed.
  2. Signer set. With the Labs Co. winding down, several original signers were Labs contributors. Availability and responsiveness must be re-verified; the set may need rotation using the backups already identified (e.g. @Thomas, @TokenBrice).

Hereby, I propose to renew the Guardian expiry for a further period (up to the 180-day max) via setGuardianExpiration across all supported chains, re-confirm or rotate the signer set, and decide the threshold. On its own accelerated track given the ~9 August expiry, likely a standalone SIP, and a candidate for the EXP expedited path if timing gets tight.

[Part C] Review treasury-support positions & operating multisigs

For both positions there are two separable decisions:

  1. paid operating mandate (signer stipends, a recurring cost that can be cut cleanly), and
  2. underlying position (a treasury-deployment question). Per [RFC] Determining the Future Direction of Lazy Summer DAO, treasury-deployment/liquidation decisions are deferred to dedicated proposals. These polls therefore signal direction and custody only; the mechanics and timing of any unwind (especially where market impact or lock constraints apply) would be specified in a follow-up SIP. Reflexive liquidation is explicitly not proposed here: the SUMR PoL and veAERO positions currently support the SUMR price, and the treasury is heavily SUMR-weighted.
C1. Arcadia protocol-owned liquidity + 2/3 execution multisig (SIP5.17)

A DAO-owned Arcadia Pro PoL position on Base [SIP5.17] SUMR Liquidity management on Base, ~$100k stables + ~$100k SUMR (600k SUMR transferred), deployed into the Aerodrome SUMR CL pool. Executed by a 2/3 Safe (0x89b39e0007577e5aE3d9f87CAaeaC4d2A3db5B34); Arcadia is non-custodial the DAO owns the account (0x18A2D63cE434DD77e2b518458E636aA7ff4d7cc8) and can terminate automations and withdraw at any time. Ownership was to revert to the DAO once deployment completed.

Here what we need is largely a custody-confirmation and direction question:

  1. confirm the Arcadia account and any residual multisig-held assets are under DAO/Timelock control,
  2. decide whether to keep the PoL deployed (it supports SUMR liquidity/price) or begin an orderly withdrawal, and
  3. wind down any remaining execution mandate now that setup is long complete. Because the position is non-custodial and DAO-owned, this is the simpler of the two.
C2. Aerodrome veAERO metagovernance + 3/5 multisig (SIP5.18)

A ~176k veAERO position [SIP5.18] Aerodrome Metagovernance, ~$101k) held in a 3/5 Safe (0x95e346c0c8405C0996bb3d5f51264c92345d68BC; signers MasterMojo, Sixty + Labs Co. chrisb/halaprix/jensei), voting each epoch to direct AERO emissions to SUMR pools. Signer stipend originally ~$1,000 SUMR/signer/month (Labs waived; ~8,000 SUMR/month net), already reduced ~50% from April 2026 in-thread, as Flight School rewards weren’t being earned and that program is itself sunsetting.

Hereby, I propose that the paid mandate can be ended or further reduced cleanly (the operational burden has largely standardised to periodic voting/claiming). The position is the hard part: veAERO is time-locked, so there is no clean exit, only resale on the Vexy.fi secondary market at a discount, or borrowing against it on 40acres.finance. Dumping it also removes emissions support for SUMR liquidity. So this poll signals direction and custody; any actual unwind path, valuation, and timing must be worked out in a dedicated follow-up SIP with proper analysis. Interim option: retain the position but end the paid mandate, letting it run passively or pass to the Guardians/a minimal caretaker.

4. Open Questions:

  1. Cut-off date. Is 31 July 2026 23:59 UTC the right common cut-off for the referral and staking revenue-share settlements? It aligns with existing monthly cadence and gives ~2 weeks’ notice.
  2. Batch vs. split SIPs. For items that pass, which should be batched into a common Base SIP (A1, A2 revenue-share settlement, A3) and which stand alone (B1 for sure; C1/C2 likely)?
  3. Administrators. If the community wants to keep the referral program and/or the staking revenue share, who steps forward to administer the monthly work? (A1, A2.)
  4. Delegate rewards mechanism. Invoke SIP5.23 clause automatically (were the Q2 KPI thresholds breached?), or run an explicit termination vote?
  5. Guardian threshold & signers. Keep 6/8 or lower it; which signers re-confirm; is EXP warranted given the ~9 Aug expiry?
  6. Penalty waiver. Should the DAO commit now to waiving the early-unstake penalty when staking rewards end, independent of any later withdraw-only decision?
  7. TipJar. Could @halaprix publish the live per-chain tipstream config and lockedUntilEpoch values? (A2.)
  8. Part C positions. Keep the PoL / veAERO deployed as SUMR price support, or begin orderly unwind? How to handle veAERO’s lock? Should these two be pulled out into their own treasury RFC if they generate substantial discussion?
  9. Claim windows. Should unclaimed Merkl rewards (referral, staking) have an explicit forfeiture/sweep date if Option B is chosen?

5. Next Steps:

  1. Gather community and @Recognized_Delegates feedback on each poll.
  2. Immediately advance Part B (Guardian) on its own track, draft the renewal SIP now, targeting execution well before the ~9 August expiry; treat EXP as a fallback if the standard cycle runs tight.
  3. Obtain and publish the technical prerequisites: staking periodFinish; per-chain TipJar config; Guardian setGuardianExpiration calldata; confirmation of DAO custody of the Arcadia account (@Thomas) and any multisig-held residual assets (@MasterMojo, @Sixty).
  4. For Part C, bring direction + custody to a vote here, and open dedicated follow-up SIPs for any position unwind, with market-impact and lock analysis.

Sequencing note: this RFC is independent of the outcome of [RFC] Determining the Future Direction of Lazy Summer DAO. If delegates would rather hold Part A and Part C until the strategic direction settles, (that is a legitimate view) but Part B should proceed regardless, because the Guardian expiry does not wait for the debate.

6. Informal Support Indicators:

Non-binding signals to gauge sentiment before any SIP. Each item is independent, so I kindly ask @Recognized_Delegates to support or reject on its own merits.

[Part A] Sunset discretionary incentive programs

A1. Sunset the Lazy Beach Club referral program (SIP5.5)?
  • YES - stop accrual and settle a final payout
  • YES - stop accrual and DO-NOT settle a final payout
  • YES, but with a different cut-off date (comment)
  • NO, keep it running (a named administrator must step forward)
  • Abstain / need more information
0 voters
A2.1. Sunset the SUMR Staking V2 reward programs?
  • YES - end both; no SUMR renewal + final USDC revenue-share settlement
  • YES - end both; no SUMR renewal, and DO-NOT settle a final payout
  • YES to ending SUMR emissions only, keep the USDC revenue share (with named administrator)
  • YES to ending the USDC revenue share only; keep SUMR emissions
  • NO - keep both running as-is
  • Abstain / need more information
0 voters
A2.2. Should the early-unstake penalty be waived once staking rewards end?
  • YES - waive it as part of the sunset
  • YES - but handle it in a separate proposal
  • NO - leave lock terms as they are
  • Abstain / need more information
0 voters
A3. Sunset the Delegate Rewards Framework V2 (SIP5.23)?
  • YES - invoke the existing sunset clause
  • YES - but via an explicit termination vote
  • NO - keep the framework running
  • Abstain / need more information
0 voters

[Part B] Confirm & extend the security mandate

B1. Extend the Guardian Module mandate before its ~9 Aug expiry?
  • YES - renew the expiry and re-confirm/rotate signers, on an accelerated track
  • YES - and pursue the [EXP] expedited path given the timing
  • NO - let the mandate lapse
  • Abstain / need more information
0 voters
B1.1. Guardian signing threshold on renewal?
  • Keep 6/8
  • Lower it (e.g. 3/8) for faster emergency reaction, with a liveness check
  • Other (comment)
  • Abstain / need more information
0 voters

[Part C] Review treasury-support positions & operating multisigs**

C1. Arcadia protocol-owned liquidity (SIP5.17) direction?
  • Confirm DAO/Timelock custody and keep the PoL deployed for now
  • Confirm custody and begin an orderly withdrawal (mechanics via follow-up SIP)
  • Wind down the execution mandate but leave the position as-is
  • Abstain / need more information
0 voters
C2. Aerodrome veAERO position (SIP5.18) direction?
  • Retain the position as SUMR liquidity support for now
  • Begin an orderly unwind (mechanics/lock handling via follow-up SIP)
  • Retain the position, but end the paid operating mandate
  • Abstain / need more information
0 voters
C2.1. Aerodrome metagovernance operating mandate (signer stipends)?
  • End the paid mandate
  • Further reduce it (already cut ~50% from April)
  • Keep it as-is
  • Abstain / need more information
0 voters

Tagging @Recognized_Delegates for feedback.
Specific tags: @chrisb (Referral/Staking History, Guardian, Aero signer), @Curia (Delegate Rewards Framework), @MasterMojo, @Sixty, @halaprix (Aerodrome Metagov, Guardian signer), @Thomas (Arcadia PoL), and @BlockAnalitica for any risk, and risk-management input.

–jensei

1 Like
[SIP0.3] Renew Guardian Module Mandate & Re-confirm Guardian Set
2

Thank you for the update @jensei

I hereby confirm the PoL position is still held and operated by the Arcadia Account (and is under control of the 2/3 Safe0x89b39e0007577e5aE3d9f87CAaeaC4d2A3db5B3.

On the signer set, I’m still fine to take up the role if needed.

1 Like
3

Given the sensitive nature of continuing the Guardian Module, I would like to confirm my support for the expedited extension of the security mandate.

  1. My thoughts here are to reduce the threshold from 6/8 to 4/8 to ensure swifter responses during any malicious attacks.

  2. I am a signer on this multisig, and I can confirm my availability for the next 180 days (post expiry date). It would be great if the remaining signers could signal their availability before the vote proceeds.

Perhaps it would be best practice to share this as it’s own separate SIP given its importance and the looming expiry date @jensei.

2 Likes
4

The Guardian needs to be extended until orderly winddown is finished. We’re happy to work on that until then, unless the protocol transitions to a indefinite situation.

1 Like