Welcome to the RFC phase of SEAL Safe Harbor!

[rholterhus]

Overview

The Whitehat Safe Harbor initiative is a framework in which protocols can offer legal protection to whitehats who aid in the recovery of assets during an active exploit. This initiative is being prepared by the Security Alliance (a.k.a. SEAL) team, and will begin a month-long public RFC (request for comments) process starting February 14th, 2024.

Please use the GitHub discussions section of this repository to share your feedback, ask questions, or join the conversation. We appreciate input from whitehats, protocol representatives, and everyday users about all aspects of the initiative.

Resources

• security-alliance/safe-harbor: the GitHub repo which houses all components of the initiative.
• Whitehat Safe Harbor Agreement: the key legal document that defines the framework.
• Whitehat Safe Harbor Agreement Summary: a helper document that summarizes the official agreement.
• Safe Harbor FAQ: answers to common questions about SEAL Safe Harbor.
• securityalliance.org: the official website of the Security Alliance.
• Safe Harbor Signup Form: a signup form if you'd like to get in touch regarding Safe Harbor integration.

[BrJu]

Nice initiative. Applicability might be a challenge as always but good to improve current situation.

A few initial comments on the current version - there should be some explicit constraints on the protocol side

• lack of requirements for ensuring that the protocol is ensuring the recovery address is securely managed (at least evidences available that will convince WH that this is reasonable to trust the address is not going to be hacked or misused)
• I would suggest that an escrow address is straightaway (together with the ARA) created in order to directly transfer the reward to this escrow, together with a description of a specific and fair process that will be used by the protocol before being able to use the fund transferred to the escrow or pay the reward (ideally with a fully transparent release process too)
• security team commitment should include some confirmation that the addresses above are secured, as well that there is a broader incident response plan

[DicksonWu654]

A multisig escrow address by SEAL would be neat as an alternative / default - maybe there's some legal liability on SEAL if something were to happen though so I would understand why it wouldn't be created

[SpekGit]

Great initiative. It is important to protect white hats during active exploit, and not to friendly fire them. Question: is it applicable for white hats around the world?

[OperatorHiKE]

I think it applies to all WHs. The problem is around the protocols

[DicksonWu654]

hmm @SpekGit are you talking about whitehats frontrunning each other thinking it's another hack? I don't think there will be any harm, other than wasted gas though. A solution could be a whitelist for other trusted WH's but that would require a trusted entity to assert that no black hats use it to their advantage