[TEMP CHECK] Adopt The SEAL Safe Harbor Agreement

Title: [TEMP CHECK] Adopt The SEAL Safe Harbor Agreement

Authors: @samczsun, Skylock.xyz, bgdlabs.eth
Date: 2025-05-20


Disclaimer: I am submitting this proposal solely in my personal capacity


Summary

This proposal outlines Aave Governance’s adoption of the SEAL (Security Alliance) Whitehat Safe Harbor Agreement (“Safe Harbor Agreement”). By adopting Safe Harbor, Aave improves the security of its on-chain assets by allowing whitehats to intervene during active exploits to save protocol funds. Safe Harbor provides legal protection and capped incentives for rapid, structured rescue of assets.

Motivation

The Safe Harbor Agreement addresses a critical need in crypto: enabling whitehats to step in when traditional responsible-disclosure procedures are too slow to prevent fund loss. Aave is committed to enhancing its security and protecting user funds during critical moments. While audits and preventive measures are vital, active exploits demand a swift, decisive response mechanism.

Benefits of adopting Safe Harbor:

  • Agile Defense Against Exploits: Whitehats may intervene as soon as an active exploit is detected, providing a rapid response mechanism that complements Aave’s ability to pause pools. In cases where pausing is not fast enough to prevent fund loss, whitehat intervention can reduce damage and accelerate asset recovery.

  • Clarified Rescue Process: A predetermined recovery workflow ensures whitehats know exactly where to send rescued funds, preventing chaotic negotiations and enabling efficient, decisive action.

  • Clear Financial Boundaries: A capped bounty (matching Aave’s existing bug-bounty maximum) aligns incentives, eliminates post-exploit reward disputes, and keeps intervention focused on fund recovery rather than negotiating payouts.

  • Industry-Standard Alignment: Adoption of Safe Harbor aligns Aave with leading protocol-security practices, reinforcing its proactive stance on asset protection.

Specification

Upon passing this TEMP CHECK, Aave Governance will proceed to the ARFC stage, where the following parameters will be fully defined and finalized for inclusion in the AIP and on-chain registration:

  • Agreement Registration: The Safe Harbor Agreement will be registered on-chain by calling the Safe Harbor Registry at
    0x8f72fcf695523a6fc7dd97eafdd7a083c386b7b6 on Ethereum with the appropriate adoptionDetails payload.

  • Parameters to be Defined During ARFC:

    • Asset Recovery Addresses: Specific Aave-controlled addresses for recovered-fund deposits.

    • Scope: The full list of smart contracts to be covered under Safe Harbor (covering major systems such as Aave v2, Aave v3, GHO, etc).

    • Security Contact: Designated contact details for coordination during incidents.

    • Bounty Terms:

      • Percentage of recovered funds

      • USD-denominated cap

      • Whether bounties are retainable from recovered funds

    • Identity Requirements: Whitehat anonymity and KYC provisions

    • Diligence Requirements: Any additional conditions for eligibility or compliance

These elements will be specified in detail during the ARFC stage and proposed as part of the corresponding AIP.

Implementation Plan

  1. On-chain Registration: The finalized registerSafeHarbor(...) transaction will be executed via the AIP.

  2. Community Communication: Official announcement across Aave communication channels to educate users.

  3. Future Scope Updates: Additional systems or contract versions will be added via subsequent governance votes.

Disclaimer

The authors are not presenting this TEMP CHECK on behalf of any third party and are not compensated for creating it.

Next Steps

  1. Engage with the community and core security team to refine the detailed proposal.

  2. Escalate to a TEMP CHECK Snapshot after community discussion.

  3. If the Snapshot outcome is YAE, advance to the ARFC stage with detailed contract lists and adoption parameters.

Copyright

Copyright and related rights waived via CC0.

8 Likes

Hey everyone - I’m Dickson one of the leads of Safe Harbor & Co-founder of Skylock!

Feel free to comment and let us know if you have any questions! Always happy to talk about Safe Harbor!

1 Like

Hey, thanks for putting this proposal together

Would you be open to sharing some of SEAL’s most notable achievements? For example, any major recoveries from hacks or involvement in high-profile incidents?

I think a lot of community members weren’t too familiar with SEAL before this temp check went live, so a bit more context could really help everyone better understand the initiative

Also, just to clarify: is SEAL the same as SEAL 911, or are they separate efforts?

1 Like

Having collaborated on the TEMP CHECK, we can confirm we support this initiative.

We think a properly structured framework like the SEAL Safe Harbor Agreement is very aligned with both the security standards of the Aave protocol and with its DAO structure, by being able to signal subscription to the agreement in a decentralised manner, via an Aave governance proposal.

As commented on the TEMP CHECK, if passing, we are glad to refine the contracts covered and any special conditions for the Aave ecosystem, on the ARFC stage.

4 Likes

Very happy to support this proposal. I was this year in touch with seal due to a friend getting hacked. The speed and support were really great. Having Seal support for Aave is just securing the protocol and it’s user even better. There is no drawdown for us implementing this.

2 Likes

Hey Tor_GAINS!

SEAL is the Security Alliance started by Samczsun! Yes actually, SEAL911 is a part of SEAL! SEAL has a lot of different initiatives like SEAL911, SEAL Intel, Wargames, Frameworks, and Safe Harbor.

For Safe Harbor we’re beginning to gain adoption. For example, we recently adopted protocols like Uniswap, Zksync, & Balancer. We’d love for Aave to be next!

In terms of SEAL in general we’ve done a lot of awesome things! SEAL911 has helped out in countless major incidents in the past. Wargames has run wargames for many protocols like Yearn, Base, and Optimism. Actually there’s a good Coin Telegraph article here.

Let me know if you have any more questions! Happy to answer them!

2 Likes

The current proposal has been escalated to TEMP CHECK Snapshot under Skywards program, by ACI.

Vote will start tomorrow, we encourage everyone to participate.

2 Likes

Aave has a strong security culture that it has upheld over the years by working with the best security teams, we are happy to contribute to that culture by supporting this proposal.

1 Like

After Snapshot monitoring, the current TEMP CHECK Snapshot ended recently, reaching out both Quorum and YAE as winning option with 627K votes.

Therefore [TEMP CHECK] Adopt The SEAL Safe Harbor Agreement has PASSED.

Next step will be the publication of an ARFC with detailed contract lists and adoption parameters.

1 Like

Summary

The SEAL Whitehat Safe Harbor Agreement gives Aave DAOs a clear legal playbook for letting vetted whitehats rescue funds during an exploit while shielding both sides from most civil liability. It resolves bounty-payment disputes through escrow valuation and SIAC arbitration, obliges the DAO to pay a reward (at recommended rate of 10%) unless challenged within 15 days, and lets the DAO enforce identity-verification, diligence, and sanctions-screening requirements.

We recommend (i) implementing KYC/OFAC checks for whitehats, (ii) publishing the Exhibit D user-adoption steps and Exhibit E risk disclosures in the protocol docs, (iii) conditioning six-figure bounties on a post-mortem plus a short seven-day confidentiality window, and (iv) assessing whether differentiated caps per chain are warranted. After aligning these points with the SEAL team, it has been resolved that Aave may set its own identity and diligence parameters and will pin the full agreement to IPFS; formal amendments are disfavoured, but post-mortem and confidentiality practices can be requested informally, and a single bounty schedule will apply across all chains.

On that basis, we endorse full adoption of the SEAL framework.


The SEAL Whitehat Safe Harbor Agreement establishes a comprehensive architecture that enables decentralised autonomous organisations to invite ethical hackers to intervene during a live exploit and repatriate endangered assets. From the vantage point of a DAO contemplating adoption, the instrument offers clear strategic advantages while simultaneously presenting legal and operational exposures that warrant scrutiny.

Bounty Dispute Resolution

The Agreement prescribes an articulated procedure for resolving controversies concerning bounty payments. Points of contention may relate to the quantum of the Bounty, a whitehat’s entitlement to the Reward, or the extent to which any portion of the Bounty may be offset under the indemnification provisions. Where the sole issue is the valuation of the tokens forming the Bounty and eligibility is uncontested, the disputed sum must be placed in a dual-signatory escrow. Each side then appoints an independent valuation expert within thirty days. If the higher appraisal does not exceed 130 percent of the lower appraisal, the Bounty is fixed at the arithmetical mean of the two. Should the spread surpass that threshold, the parties designate a neutral appraiser whose determination is final and binding. Once the valuation is settled, the escrow agent releases the appropriate amount to the party legally entitled to receive it.

General Dispute Resolution Framework

Any dispute that remains unresolved after thirty days ripens into an “Arbitrable Dispute” and is submitted to binding arbitration administered by the Singapore International Arbitration Centre. Proceedings are conducted in English before a three-member tribunal whose constituents must have no prior or present connection with the parties unless expressly waived and must possess at least fifteen years of experience in sophisticated corporate transactions, or be a retired judge of the United States federal district courts with demonstrable arbitral expertise. Each party bears one-half of the initial arbitrator compensation and transcript fees; however, ultimate allocation of costs is governed by the tribunal’s award, which ordinarily shifts attorneys’ fees and the balance of arbitral expenses to the non-prevailing party. The resulting decision may be entered in any court of competent jurisdiction and enforced accordingly.

DAO Obligations Under the Agreement

By adopting the SEAL Safe Harbor framework, a DAO undertakes a constellation of substantive and procedural commitments. It must honour the agreed-upon Bounty—frequently articulated at ten per cent of recovered assets—and initiate any contest to a whitehat’s eligibility within fifteen days after funds reach the Asset Recovery Address, failing which acceptance of the reward is conclusively presumed. The DAO further covenants to release compliant whitehats from civil liability, waiving even unknown or later-discovered claims. Operationally, it must maintain a designated Asset Recovery Address, demarcate the smart-contract perimeter that falls within the programme’s scope, and publish clear channels for emergency communications. Governance formalities require that the Agreement be approved through the DAO’s ordinary decision-making apparatus, with any necessary smart-contract upgrades implemented in accordance with those procedures.

Sanctions compliance constitutes a critical dimension of the arrangement. Although whitehats represent that they are not subject to Office of Foreign Assets Control (OFAC) restrictions, the DAO retains discretion to calibrate the intensity of verification. Section 3.1 references the “identityRequirement struct,” empowering the DAO to accept fully anonymous or pseudonymous rescuers—albeit with heightened risk—or to mandate basic, intermediate, or full KYC verification. The same section allows the DAO to impose bespoke diligence requirements through the “diligenceRequirements string”; such conditions may encompass technical parameters for the rescue, documentation standards, time-sensitive reporting obligations, coordination protocols, or supplementary representations by the whitehat. The Agreement expressly cautions that jurisdictions may view anonymous rescues as elevating sanctions risk, and therefore recommends pre-payment screening and monitoring to avoid disbursing rewards to prohibited persons.

Termination of the Agreement

Termination mechanics are delineated in Section 8. The programme and the Agreement’s term commence upon ratification through the DAO’s governance process and conclude when the DAO passes a proposal that terminates participation. Termination, however, leaves intact any provisions that by their nature survive with respect to events predating the cessation. Amendment is addressed in Section 9.1: SEAL may alter the general form or non-community-specific clauses by giving forty-five days’ prior written notice on its website and principal social-media outlets, whereas alterations to community-specific terms must proceed through the DAO’s own adoption procedures and affect only that community.

Holding Whitehats Accountable

Accountability mechanisms are threaded throughout the Agreement. Section 3.1 makes satisfaction of every eligibility criterion—including identity and diligence requirements—a condition precedent to any reward, permitting the DAO to withhold payment if a whitehat falls short. Section 7.1(a) obliges whitehats to indemnify the protocol community and its affiliates for damages arising from misrepresentation or material breach, though liability is capped at the bounty amount actually received. The representations and warranties in Section 5, such as the prohibition on assigning rights or delegating obligations without written consent, furnish additional grounds for withholding rewards and seeking indemnification if breached. Section 9.9 further entitles the DAO to seek specific performance or injunctive relief, without the necessity of proving actual damages or posting security, should a whitehat threaten or commit a breach.

Legal Protections for Whitehats

Whitehats who comply with the Agreement obtain robust shields. Section 6.1 delivers an irrevocable release from the protocol community for all claims arising out of the rescue or the Agreement. Section 6.2 extends the release to unknown or unsuspected claims, while Section 6.3 includes an express covenant by the DAO not to sue. Although Section 7.1(a) preserves indemnification exposure, the clause caps financial liability at the bounty amount, thereby limiting downside risk for compliant whitehats.

Legal Protections for DAOs

The Agreement reciprocally protects DAOs. Under Section 6.4, whitehats release the protocol community from all claims that might otherwise arise in connection with the rescue. The indemnification promise in Section 7.1(a) reinforces that protection by shifting damages stemming from a whitehat’s misrepresentations or breaches back to the whitehat. Representations in Section 5.2—that the whitehat possesses requisite expertise, is not subject to sanctions, will comply with law, and will not infringe third-party intellectual property—further insulate the DAO.

Important Limitations

The Safe Harbor Agreement does not—and cannot—shield either party from every contingency. Whitehats remain exposed to criminal prosecution, sanctions enforcement, and liability for actions that exceed the Agreement’s scope. DAOs remain vulnerable to regulatory oversight, third-party litigation related to the exploit, and the non-delegable obligation to pay any bounty that becomes due. Section 9.2 emphasises that nothing in the Agreement constitutes legal advice on compliance, underscoring the need for each party to perform its own independent analysis of applicable law.

Implementation Recommendations

In light of the foregoing analysis, we regard the following measures as essential to a risk-adjusted adoption of the SEAL conditions by the DAO.

First, the DAO should stipulate that the identityRequirement field be set to “Named” making completion of a full know-your-customer review and screening against all OFAC sanctions lists a non-waivable prerequisite to bounty eligibility. By conditioning payment on successful KYC clearance and sanctions vetting, the DAO mitigates the risk of inadvertently rewarding a prohibited person and demonstrates affirmative compliance with prevailing AML/CTF rules.

Second, the User Adoption Procedures contained in Exhibit D—together with the risk disclosures set out in Exhibit E—ought to be woven verbatim into the publicly accessible protocol documentation, ensuring that community participants and prospective whitehats can review, in a single repository, the steps required for programme participation and the attendant legal and technical hazards.

Third, the Agreement should be augmented with a covenant obliging any whitehat who is to receive a bounty exceeding a designated monetary threshold—USD 500,000 provides a sensible marker—to furnish both a detailed post-mortem analysis and a publicly releasable incident report.

Fourth, the foregoing reporting requirement must be harmonised with a short-term confidentiality obligation under which whitehats refrain from publicising exploit particulars for a defined period—seven days is customary—or until the DAO releases its own root-cause summary, whichever occurs sooner.

Finally, the DAO should evaluate whether to impose differentiated bounty ceilings on a per-chain basis, calibrated to the economic value and technical intricacy of recoveries conducted on each network where the protocol is deployed.

Conclusion

After calibrating our recommendations with the SEAL team, the following practical conclusions have been reached:

  1. Aave shall retain unfettered discretion to define the identity-verification and diligence thresholds within the identityRequirement and related fields, and an immutable copy of the complete Agreement will be pinned to IPFS to safeguard its provenance.
  2. While the SEAL team discourages formal amendments in order to preserve a single, uniform framework across all participating protocols, they have acknowledged our proposals concerning post-mortem disclosure and a short confidentiality window and recommends that the DAO pursue these practices through direct, informal requests to whitehats rather than by textual modification.
  3. The framework does not presently accommodate chain-specific bounty segmentation; a single bounty methodology will therefore apply across every network on which the protocol operates.

In light of these understandings and our overall analysis, we support continued progress toward full adoption of the SEAL Whitehat Safe Harbor Agreement.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

2 Likes