[RFC] Adopt the SEAL Whitehat Safe Harbor Agreement

[jensei]

Authors: @jensei (Lazy Summer DAO), @dickson (SEAL)

---

1. Summary:

This RFC proposes that the Lazy Summer DAO formally adopt the SEAL (Security Alliance) Whitehat Safe Harbor Agreement, a widely used industry framework that enables vetted whitehat actors to intervene during active exploits to rescue protocol funds with clear rules, incentives, and legal protection.

Umbrella Proposal & Temp Check: [RFC] Arbitrum User Reimbursement, Insurance Fund, and Other Improvements

SEAL Whitehat Safe Harbor Agreement Documentation: SEAL Whitehat Safe Harbor – Security Frameworks by SEAL
SEAL Whitehat Safe Harbor Agreement Legal Agreement: safe-harbor/documents/agreement.pdf at main · security-alliance/safe-harbor · GitHub

Adopting this framework strengthens Lazy Summer Protocol’s incident response capabilities, reduces ambiguity during live exploits, and aligns the protocol with best-in-class security practices already adopted by leading DeFi protocols.

---

2. Context & Motivation:

Lazy Summer Protocol operates curated, DAO-governed and @BlockAnalitica - risk assessed vaults; that emphasize simplicity, trust, and passive participation. While audits, risk reviews, and monitoring are critical preventative tools, active exploits require rapid, decisive action that traditional disclosure processes are often too slow to support.

Recent industry incidents; including those discussed across Lazy Summer DAO governance forum, have reinforced a key lesson: during a live exploit, speed and clarity matter more than process purity.

2.1 What is the Safe Harbour Agreement

The Safe Harbor Agreement addresses a critical need in crypto: enabling whitehats to intervene during active exploits when the urgency of an attack makes traditional processes too slow to save funds.

The Safe Harbor Agreement was created by SEAL, a nonprofit founded by samczsun, to secure the future of crypto. In addition to the Safe Harbor Agreement, SEAL runs multiple initiatives including SEAL 911 (emergency response hotline for exploits), SEAL Intel (crypto-native threat intelligence sharing), SEAL Frameworks (open source security best practices and playbooks), SEAL Wargames (incident response training), and more in development.

Key aspects of the agreement include:

• Encouraging Whitehats to Protect the Protocol: By adopting the Safe Harbor Agreement, Lazy Summer DAO incentivizes whitehats to step in and protect the protocol during active exploits by limiting their legal exposure.
• Intervention Only During Active Exploits: Whitehats are authorized to act only when there is an immediate or ongoing exploit that threatens the protocol. This agreement is not intended for routine security testing or bug bounty reporting. It applies only to critical situations where the urgency of the exploit supersedes traditional procedures for responsible disclosure in order to save funds.
• Mandatory Return of Rescued Funds: Under the terms of the Safe Harbor, whitehats are required to return all rescued assets to a pre-designated recovery address controlled by the protocol within 72 hours of recovery to ensure these funds are quickly secured, preventing delay or potential loss.
• Clear Guidelines and Legal Protection: The agreement establishes strict rules for how whitehats must operate during an exploit, ensuring recovery efforts are conducted professionally and safely, minimizing the risk of mistakes or further damage to the protocol. By adhering to these guidelines, whitehats can limit their potential legal exposure, allowing them to act in good faith without fear of liability.
• Incentivized Rescue Efforts: To motivate whitehats to act during critical situations, the agreement offers a bounty system that rewards rescuers with a percentage of the recovered assets, up to a predefined cap, for successful interventions.

The framework is already in use by protocols such as Uniswap, zkSync, Pendle, PancakeSwap, and Balancer, and has emerged as an industry standard for responsible exploit response.

Adopting SEAL complements (rather than replaces) audits, monitoring, and governance controls by providing a last-line-of-defense mechanism when prevention fails.

---

3. Proposal:

This RFC proposes that Lazy Summer DAO:

3.1 Formally adopt the SEAL Whitehat Safe Harbor Agreement

By adopting the agreement, Lazy Summer would:

• Authorize whitehats to intervene only during active, ongoing exploits
• Require all rescued funds to be returned to predefined recovery addresses within 72 hours
• Offer predefined, capped bounties to incentivize fast and responsible recovery
• Provide legal clarity and protection for good-faith rescue actions

This agreement does not apply to routine security research, audits, or bug bounty disclosures.

3.2 Adoption Details (Draft / To Be Finalized)

The following parameters are proposed as a starting point and are explicitly open for community input before finalization in a SIP.

Protocol Details:

• Protocol Name: Lazy Summer Protocol
• Summer Governor: 0xBE5A4DD68c3526F32B454fE28C9909cA0601e9Fa
• Timelock Address: 0x447BF9d1485ABDc4C1778025DfdfbE8b894C3796
• Protocol Access Manager: 0xf389BCEa078acD9516414F5dabE3dDd5f7e39694

Proposed Bounty Terms:

• Rewards: 10% of recovered funds (TBD, see poll below)
• Per-incident Cap: $100,000 USD (TBD, see poll below)
• Aggregate Cap: $100,000 USD (TBD, see poll below)
• Retainable: False (all funds returned first) (TBD, see poll below)
  • When retainable is True, whitehats are allowed to retain their bounty from the recovered funds directly. This streamlines the payout process for whitehats and protocols.
  • When retainable is False, whitehats are required to return all recovered funds to the protocol, which will then payout the bounty after verification by the protocol.
• Identity: Pseudonymous (TBD, see poll below)
  • When identity is Anonymous whitehats are allowed to remain anonymous and are not required to provide any information about themselves to the protocol.
  • *When identity is Pseudonymous whitehats must identify themselves to the protocol, but are not required to provide their real name or any identification.
  • When identity is Named whitehats must identify themselves to the protocol with their full legal name.
• Diligence Requirements: To be defined in SIP (see poll below)
  • Designated security contacts for the protocol who whitehats will contact following a safe harbor recovery.
  • Addresses controlled by the protocol which recovered protocol funds will be returned to by the whitehat.
  • List of all on-chain assets owned by the protocol protected under Safe Harbor.

Contact Details:

Designated security contacts will be published for post-recovery coordination. I hereby nominate @halaprix, @Raphael_Anode, @jensei + @BlockAnalitica for additional coordination re: risk parameters. Feel free to nominate yourself, or others in the comments below.

Chains & Asset Recovery Addresses:

Recovery addresses will be specified per supported chain (Base, Ethereum, Arbitrum, Sonic, HyperEVM) and controlled by the DAO / designated guardian multisig.

Please comment below your thoughts / nominations.

Scope:

Contracts protected under Safe Harbor will be explicitly listed and versioned.

• Proposed default: ExistingOnly, expandable via governance.
  • When None, only the address listed above will be considered in scope.
  • When ExistingOnly, only the address and child contracts of that address deployed before the adoption of safe harbor will be considered in scope.
  • When FutureOnly, only the address and child contracts of that address deployed after the adoption of safe harbor will be considered in scope.
  • When All, the address and all of its child contracts will be considered in scope.

3.3 Implementation Plan

If supported, the following steps are proposed:

1. Register the Agreement On-Chain
The Safe Harbor Agreement will be registered in the SEAL Safe Harbor Registry
(0x1eaCD100B0546E433fbf4d773109cAD482c34686) with finalized parameters.
2. Communicate Adoption
Publish a clear announcement explaining: What Safe Harbor is. When it applies. What it does and does not authorize.
3. Governance-Based Scope Updates
Any future contracts, chains, or upgrades will be added to scope via governance vote.

---

4. Open Questions:

The @Recognized_Delegates are explicitly invited to provide input on:

1. Bounty Parameters

• Appropriate percentage and USD caps
• Retainable vs non-retainable structure

2. Scope Defaults

• ExistingOnly vs All child contracts
• Initial chain coverage

3. Identity Requirements

• Pseudonymous vs named whitehat recoveries.

4. Operational Ownership

• Which @Recognized_Delegates are listed as immediate contacts.
• Which multisig or entity should control recovery addresses and verification.

---

5. Next Steps:

• Gather community and delegate feedback
• Refine adoption parameters based on discussion
• Finalize scope, bounty, and operational details
• Promote to a formal SIP for onchain governance approval.

---

6. Informal Support Indicator:

To gauge initial sentiment, community members are encouraged to signal on the following.

6.1 What percentage of recovered funds should be awarded to whitehats under the Safe Harbor Agreement?

Options:

• 5% (More conservative, closer to traditional bounty levels)
• 10% (Balanced, aligned with industry Safe Harbor norms)
• 15% (Higher incentive for rapid intervention)
• Other / Comment below

6.2 What should be the maximum bounty per Safe Harbor incident?

Options:

• $50,000 USD
• $100,000 USD (Aligns with last critical bug bounty)
• $150,000 USD
• Other / Comment below

Last bounty program announcement: Summer.fi 100k Bug Bounty Program In Partnership With Immunefi

6.3 What should be the total aggregate cap across all Safe Harbor incidents?

Options:

• $100,000 USD
• $200,000 USD
• $300,000 USD (≈3× critical bounty)
• $500,000 USD
• Other / Comment below

6.4 Should whitehats be allowed to retain their bounty directly from recovered funds?

Options:

• Yes - Retainable (Whitehats keep bounty directly; faster payout)
• No - Non-retainable (All funds returned first; bounty paid after verification)
• No strong preference

6.5 What level of identity disclosure should be required from whitehats?

Options:

• Anonymous
• Pseudonymous (Identify to protocol only)
• Named (Full legal identity)
• No strong preference

6.6 What should be the default contract scope covered by Safe Harbor?

Options:

• ExistingOnly (Contracts deployed before adoption)
• All (Existing + future contracts)
• FutureOnly
• Other / Comment below

These polls are non-binding and intended to help the Lazy Summer DAO converge on Safe Harbor parameters.

---

Adopting the SEAL Whitehat Safe Harbor Agreement equips Lazy Summer Protocol with a clear, fast, and industry-aligned response mechanism for active exploits; the moments when user funds are most at risk.

This RFC does not request treasury funds, emissions, or budget allocation. It seeks governance approval to strengthen protocol resilience, improve crisis outcomes, and align Lazy Summer Protocol with proven best practices across DeFi.

As always, feedback from @Recognized_Delegates, contributors, and community members is highly encouraged before progressing to a SIP.

[dickson]

Hi all - I’m Dickson from SEAL Safe Harbor! It’s a pleasure collaborating with @jensei & happy to answer any questions y’all have about Safe Harbor!

[Sixty]

I am supportive of the adoption of the SEAL Whitehat Safe Harbor Agreement, as this will add a critical line of defense if the protocol faces any exploits/attacks.

My only strong position is that the bounty should not be capped and should be 10% of the total amount recovered. This aligns incentives in a way that ensures that the effort to recover exploited funds is economically viable for whitehats.

I also believe that security bounties overall should be in line with the total amount (TVL) secured by the protocol, as setting a cap here creates perverse incentives that encourage potential hackers to exploit the protocol for a higher payout instead of submitting a bug bounty.

Finally, I think that its a no-brainer that all existing + future contracts should be covered under this agreement, as we continue to make changes to the protocol (e.g Governance v2)

[Eren_DAOplomats]

Welcome to the forum @dickson It’s great to see SEAL engaging directly.
I am fully supportive of adopting the Safe Harbor agreement. In the heat of an exploit, legal ambiguity causes hesitation, and hesitation causes loss of funds. Removing that friction is a net positive for the protocol.

[Ceazor]

I noticed a lot of my votes didnt align with most others, so I thought it wise to justify my divergence.

——-
200K for total aggregate
rewards should increase as exposure is increased. We want the whitehats to work hard and not stop as a single vector.

—-
Retainable on payout
I dont think there is much point of asking them to return it and then we pay them.
This encourages white hats (WHs) to grey hat hack the project. "(steal the funds and wait for offer to return)

we want white hats to have as little friction as possible. If they dont honor the 100K cap, then we have to reassess the SEAL deal thereafter.

—
Identity

I dont think we should care if they are doxxed or not.
we want as many WHs as possible. There is little reason to for doxxing. This encourages BHs and GHs

These are my thoughts at the current time.

[Raphael_Anode]

Highly recommend signing on with SEAL. We recommended similar to 1Inch, Rootstock and Reserve Protocol as well as Compound.

They’re the best in the game, and they only get paid if they can actually make a material difference.

We voted for covering All contracts, paying anons (which we think is especially important here), , but not paying before verification.