Safe Harbor - Protecting your Protocol in Real Time

Robert MacWha

Jun 23, 2024

All else has failed, user funds are about to be lost, and no hope remains.

This is when the Safe Harbour Agreement kicks in. It acts as a last line of defense for protocols facing multi-million dollar losses, enabling whitehats to race against black-hat hackers and save user funds before it’s too late.

The Safe Harbour Agreement is a framework designed to offer legal protection to whitehats assisting in the recovery of assets during active exploits. Spearheaded by the Security Aliance, the initiative is one part in their wider effort to secure the future of crypto. In short, if a protocol is being hacked, it lets whitehats step in and try to stop the attacker.

By participating, protocols can establish clear procedures for whitehats to follow, enabling them to intervene and save at-risk assets without fear of legal repercussions. This isn’t like historic instances of unauthorized whitehacking,” but rather a colaboration between protocols and security researchers, providing an aditional layer of security and enhancing overall safety.

Ethical whitehacking has already shown to be an effective method of combatting black-hats. A prime example is the 2023 Curve Finance exploit. Bot operator “c0ffeebabe.eth” detected, front-ran, and saved 2,879 ETH from the original hacker’s attack transaction. Without their actions a further $5.5M in user funds would have been lost. Safe Harbor will make these ethical incdents more likely and help save user funds.

Your New Contingency Plan

The Safe Harbour Agreement is the newest contingency plans for protocols protecting against hacks. It’s not intended to replace bug bounties or audits; rather, it operates in situations where other security measures cannot. In nearly any case where a whitehat encounters a bug within a smart contract they should disclose the vulnerability, reap their reward, and move on. The Safe Harbour Agreement is used in situations where the above is impossible.

If a whitehat knows that a vulnerability is actively being, or about to be, exploited, then the agreement kicks in. Maybe a fork of the contract has just been exploited and they know the original is next. Maybe (like us) they’ve developed a mempool bot to detect and automatically frontrun hacks. Whatever the reason, the Safe Harbour agreement should only be used as a last resort.

In such a scenario, the Safe Harbour Agreement allows whitehats to ethically intervene, protect user funds, and mitigate the impact of the hack. By clearly defining the procedures and rewards for whitehats, the Safe Harbour Agreement enhances protocol security, ensuring a last line of defence when all other measures have failed.

Agreement Flowchart

Adopting the Agreement

Adopting the Safe Harbour Agreement is about as challenging as setting up a bug bounty. To help simplify this process, we’ve created a Safe Harbor Adoption Tool that walks protocols through the adoption, helps make decisions, and automatically generates required documentation. We’ve also created a Safeharbor Checklist Template that can be used to track the adoption process.

For smaller teams using our adoption tool, this process should take less than an hour. For larger organizations, it depends on the number of decision makers. If you chose not to use our adoption tool, you can follow the below steps to manually adopt the Safe Harbour Agreement.

1. Deciding your Adoption Terms

The first step in adopting the Safe Harbour Agreement is to determine the specific terms of your adoption. This sets out what whitehats can and cannot protect, how their will be compensated, and any limitations or identity requirements they might have.

Assets Under Scope: Identify which assets will be included in the scope of the agreement. This could be specific ERC20 tokens, NFTs, smart contract wallets, or any other relevant digital assets associated with your protocol.
Bounty Terms: Establish the reward structure for whitehats. This includes setting the percentage of recovered funds that will be given as a bounty and any caps on the total bounty amount. We recommend that you set this to the bounty terms on your critical bug bounties - roughly 10% of the at-risk funds.
Identity Requirements: Define any requirements or verification steps required by whitehats to claim their bounty. For example, you might require all whitehats to submit to a KYC verification process and be fully de-anonymized in order to claim their reward. Alternatively, if you want a larger breadth of potential whitehats, you might accept anonymous whitehats with minimal verification.
Contact Details: Finally, list the proper contact channels whitehats should use after exfiltrating at-risk funds. This should include a way to contact whoever is responsible for smart contract security in your organization, and at least two backups.

An in-depth explanation of each term can be found in the “Safe Harbour Agreement Implementation Standard”.

2. Creating your Asset Recovery Address

Your Asset Recovery Address is now one of the most important addresses your protocol controls. This is the address that whitehats will deposit exfiltrated funds into immediately following an attack. When creating this address, make sure it is highly secure and initialized on all chains where you have Assets under Scope. It should be able to handle large sums of assets and have the necessary security measures to prevent unauthorized access. Consider a hardware wallet or multi-signer wallet such as a Gnosis safe.

3. Finalizing your adoption

Once the terms have been decided and the asset recovery address is set up, the final steps involve formalizing the adoption of the Safe Harbour Agreement. For DAOs this will involve creating a Governance proposal and publicly adopting the agreement, while for centrally controlled protocols internal adoption is enough. These steps can either be done manually, or you can use Skylock’s Safe Harbor Adoption Tool to automatically generate the required documentation.

Governance: For DAOs, create a governance proposal for voting on the adoption of the Safe Harbour Agreement. The proposal should outline all the terms of the agreement and explain the points in favour of adoption. As a starting point you can also review “Exhibit B — DAO Adoption Procedures” in the Safe Harbor GitHub.
Agreement Fact Page: Fill in an agreement fact page that provides comprehensive information on your protocol’s adoption of the agreement. A template fact page is provided in the Safe Harbor GitHub at “Exhibit F - Adoption Form”. This page must be maintained off-chain and made publicly available.
User Adoption Procedures: Adapt “Exhibit D - User Adoption Procedures” to your protocol’s adoption and insert them into your protocol’s terms of service. This ensures that all users are informed of the agreement.
On-chain Transaction: Finally, a governance address must send an on-chain transaction to the Safe Harbour registry contract calling the adoptSafeHarbor() method with the selected adoption details. The address initiating this transaction should represent the decision-making authority of the protocol, making the adoption legally binding. Upload to IPFS: Once the adoption process has been completed all relevant documentation, including a full copy of the adapted “Safe Harbour Agreement,” should be uploaded to IPFS for safekeeping.

What’s next

Once you’ve finished adopting the agreement, what next? Hopefully, nothing. Whenever you deploy a new smart contract you should remember to update Safe Harbour documentation, but otherwise, you hope that the rest of your security procedures are enough to stop you from ever needing the agreement. If your protocol is hacked, you know you’ve done everything within your power to ensure the safety of your and your users’ funds.