# \[RFC\] - Adopt The SEAL Safe Harbor Agreement **URL:** \ **Category:** Requests for Comment\ **Created:** [December 4, 2024, 5:26pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971 "2024-12-04T17:26:53Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Dickson](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dickson](https://gov.uniswap.org/u/Dickson)\ **Post date:** [December 4, 2024, 5:26pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/1 "2024-12-04T17:26:53Z")
# [RFC] - Adopt The SEAL Safe Harbor Agreement Category: Request for comment Authors: Skylock.xyz, @eek637 * * * ## Introduction This proposal outlines Uniswap Governance’s adoption of the SEAL ([Security Alliance](https://www.securityalliance.org/)) Whitehat Safe Harbor Agreement (“Safe Harbor Agreement”). By adopting Safe Harbor, Uniswap improves the security of its on-chain assets by allowing whitehats to intervene during active exploits to save protocol funds. ### What is the Safe Harbor Agreement? The Safe Harbor Agreement addresses a critical need in crypto: enabling whitehats to intervene during active exploits when traditional responsible disclosure procedures are not feasible. Key aspects of the agreement include: - Encouraging Whitehats to Protect the Protocol: By adopting Safe Harbor, Uniswap 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 applies only to critical situations where responsible disclosure procedures would not save funds due to the urgency of the exploit, and it is not intended for routine security testing or vulnerability reporting. - 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 recovering them. This ensures that recovered 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 similar to a bug bounty. Whitehats are rewarded with a percentage of the recovered assets, up to a predefined cap, for their successful interventions. For more information, check out the Safe Harbor Agreement [here](https://github.com/security-alliance/safe-harbor/blob/main/documents/agreement.pdf). * * * ## Rationale Uniswap, by design, does not include a pause function, meaning the protocol cannot be halted in the event of an exploit. This makes it essential to have a mechanism that allows rapid response and asset recovery during emergencies. The Safe Harbor Agreement provides this necessary solution, empowering whitehats to act immediately during an exploit, offering a swift and structured recovery process without needing to pause the protocol. Benefits of adopting the Safe Harbor Agreement include: - Agile Defense Against Exploits: Whitehats are authorized to intervene as soon as an active exploit is detected, enabling them to respond faster than traditional methods. This ensures that Uniswap is protected against threats even without the ability to halt the protocol. Immediate action minimizes the window for malicious actors, reduces damages, and accelerates the recovery of assets during critical moments. - Clarified Rescue Process: The agreement ensures that every step, from intervention to fund recovery, is predetermined and streamlined. Whitehats know exactly where to send recovered funds, preventing chaotic negotiations or rushed decisions during an exploit. This clarity ensures efficient, decisive action when it matters most. - Clear Financial Boundaries: The predefined bounty system, with a cap matching Uniswap Labs’ existing bug bounty for V3, ensures that whitehats are incentivized fairly without creating conflicting priorities between exploit intervention and standard vulnerability disclosure. By setting expectations upfront, it eliminates post-exploit negotiations, ensuring funds are returned promptly without attempts to change the reward amount, keeping the process fair and transparent. - Aligning with Industry Best Practices: By adopting the Safe Harbor Agreement, Uniswap aligns itself with leading security practices across the industry, reinforcing its commitment to staying at the forefront of protocol security. Adoption of the agreement complements audits by providing an additional layer of security, ensuring that the protocol is better prepared to respond to active threats. * * * ## Adoption Details Uniswap will adopt the agreement with the following parameters. For a full description of these adoption details, review the [Safe Harbor for Protocols](https://www.notion.so/securityalliance/Safe-Harbor-for-Protocols-76a61d6bfc2747b9a2c0263092e8a51f?pvs=4#05b2a7f1cecb47cf8e977d7cad21dda2) document. 1. Asset Recovery Address: Addresses controlled by Uniswap, which recovered funds will be returned to in the event of a hack. [Source](https://github.com/uniswapfoundation/governance-processes/blob/main/TREASURY_ADDRESSES.md) | Chain | Address | | --- | --- | | Ethereum | 0x1a9C8182C09F50C8318d769245beA52c32BE35BC | | Arbitrum | 0x2BAD8182C09F50c8318d769245beA52C32Be46CD | | Avalanche | 0xeb0BCF27D1Fb4b25e708fBB815c421Aeb51eA9fc | | Base | 0x31FAfd4889FA1269F7a13A66eE0fB458f27D72A9 | | Blast | 0x2339C0d23b60739B3E5ABF201F05903D24A26C77 | | Boba | 0x53163235746CeB81Da32293bb0932e1A599256B4 | | BSC | 0x341c1511141022cf8eE20824Ae0fFA3491F1302b | | Celo | 0x0Eb863541278308c3A64F8E908BC646e27BFD071 | | Filecoin EVM | 0xFf3b2DA1379cc67cc2755194604713f10b820b0E | | Gnosis | 0xfFA5599136fBaB9af7799A6703b57BB33E5390Cf | | Linea | 0x581F86Da293A1D5Cd087a10E7227a75d2d2201A8 | | Manta Pacific | 0x683553d74D9779955a15d57D208234C956B6Eae6 | | Mantle | 0x9b7aC6735b23578E81260acD34E3668D0cc6000A | | Moonbeam | 0xB2af16D6c7074228fC487F17929De830303E6531 | | Optimism | 0xa1dD330d602c32622AA270Ea73d078B803Cb3518 | | Polygon | 0x8a1B966aC46F42275860f905dbC75EfBfDC12374 | | Polygon zkEVM | 0x1808cc3ffb04e8bB67BfEB5510D44e62cF380717 | | Redstone | 0x2d00e94d78Fc307FC5E6195BBe2fB6aFC2FC07d4 | | Rootstock | 0x38aE7De6f9c51e17f49cF5730DD5F2d29fa20758 | | Scroll | 0xEfc9D1096fb65c832207E5e7F13C2D1102244dbe | | Sei | 0xe75358526ef4441db03ccaeb9a87f180fae80eb9 | | Taiko | 0xf6b53E8dA8bc7dbddB8E7B39635d17D7CCdCD6E5 | | WorldChain | 0xcb2436774C3e191c85056d248EF4260ce5f27A9D | | ZkSync | 0x2BAD8182C09F50c8318d769245beA52C32Be46CD | | Zora | 0x36eEC182D0B24Df3DC23115D64DB521A93D5154f | 1. Scope: List of all on-chain assets protected under Safe Harbor. [V1 Source](https://docs.uniswap.org/contracts/v1/guides/connect-to-uniswap), [V2 Source 1](https://docs.uniswap.org/contracts/v2/reference/smart-contracts/v2-deployments), [V2 Source 2](https://gov.uniswap.org/t/temperature-check-deploy-uniswap-v2-on-all-chains-with-v3/21799/12), [V3 Source](https://gov.uniswap.org/t/official-uniswap-v3-deployments-list/24323/3), [UniStaker and V3FactoryOwner Source](https://docs.unistaker.io/), [Franchiser Factory Source](https://github.com/NoahZinsmeister/franchiser/blob/main/spec.md) | Chain | Name | Address | Type (None, Existing Only, All) | | --- | --- | --- | --- | | Ethereum | UniswapV1Factory | 0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95 | All | | Ethereum | UniswapV2Factory | 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f | All | | Arbitrum | UniswapV2Factory | 0xf1D7CC64Fb4452F05c498126312eBE29f30Fbcf9 | All | | Avalanche | UniswapV2Factory | 0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C | All | | Base | UniswapV2Factory | 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 | All | | Blast | UniswapV2Factory | 0x5C346464d33F90bABaf70dB6388507CC889C1070 | All | | Boba | UniswapV2Factory | 0x40a26d18440948d8eE121b78ca4e88C37D30143b | All | | BSC | UniswapV2Factory | 0x8909Dc15e40173Ff4699343b6eB8132c65e18eC6 | All | | Celo | UniswapV2Factory | 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 | All | | Filecoin EVM | UniswapV2Factory | 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 | All | | Gnosis | UniswapV2Factory | 0x8c8b524ce7c9D2e3f59aB6711bE4Ac826FA46a0f | All | | Linea | UniswapV2Factory | 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 | All | | Moonbeam | UniswapV2Factory | 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 | All | | Optimism | UniswapV2Factory | 0x0c3c1c532F1e39EdF36BE9Fe0bE1410313E074Bf | All | | Polygon | UniswapV2Factory | 0x9e5A52f57b3038F1B8EeE45F28b3C1967e22799C | All | | Rootstock | UniswapV2Factory | 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 | All | | Scroll | UniswapV2Factory | 0x114a43df6c5f54ebb8a9d70cd1951d3dd68004c7 | All | | WorldChain | UniswapV2Factory | 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f | All | | Zora | UniswapV2Factory | 0x0F797dC7efaEA995bB916f268D919d0a1950eE3C | All | | Ethereum | UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 | All | | Arbitrum | UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 | All | | Avalanche | UniswapV3Factory | 0x740b1c1de25031C31FF4fC9A62f554A55cdC1baD | All | | Base | UniswapV3Factory | 0x33128a8fC17869897dcE68Ed026d694621f6FDfD | All | | Blast | UniswapV3Factory | 0x792edAdE80af5fC680d96a2eD80A44247D2Cf6Fd | All | | Boba | UniswapV3Factory | 0xFFCd7Aed9C627E82A765c3247d562239507f6f1B | All | | BSC | UniswapV3Factory | 0xdB1d10011AD0Ff90774D0C6Bb92e5C5c8b4461F7 | All | | Celo | UniswapV3Factory | 0xAfE208a311B21f13EF87E33A90049fC17A7acDEc | All | | Filecoin EVM | UniswapV3Factory | 0xB4C47eD546Fc31E26470a186eC2C5F19eF09BA41 | All | | Gnosis | UniswapV3Factory | 0xe32F7dD7e3f098D518ff19A22d5f028e076489B1 | All | | Linea | UniswapV3Factory | 0x31FAfd4889FA1269F7a13A66eE0fB458f27D72A9 | All | | Manta Pacific | UniswapV3Factory | 0x06D830e15081f65923674268121FF57Cc54e4e23 | All | | Mantle | UniswapV3Factory | 0x0d922Fb1Bc191F64970ac40376643808b4B74Df9 | All | | Moonbeam | UniswapV3Factory | 0x28f1158795A3585CaAA3cD6469CD65382b89BB70 | All | | Optimism | UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 | All | | Polygon | UniswapV3Factory | 0x1F98431c8aD98523631AE4a59f267346ea31F984 | All | | Polygon zkEVM | UniswapV3Factory | 0xff83c3c800Fec21de45C5Ec30B69ddd5Ee60DFC2 | All | | Redstone | UniswapV3Factory | 0xece75613Aa9b1680f0421E5B2eF376DF68aa83Bb | All | | Rootstock | UniswapV3Factory | 0xaF37EC98A00FD63689CF3060BF3B6784E00caD82 | All | | Scroll | UniswapV3Factory | 0x70C62C8b8e801124A4Aa81ce07b637A3e83cb919 | All | | Sei | UniswapV3Factory | 0x75FC67473A91335B5b8F8821277262a13B38c9b3 | All | | Taiko | UniswapV3Factory | 0x75FC67473A91335B5b8F8821277262a13B38c9b3 | All | | WorldChain | UniswapV3Factory | 0x7a5028BDa40e7B173C278C5342087826455ea25a | All | | ZkSync | UniswapV3Factory | 0x8FdA5a7a8dCA67BBcDd10F02Fa0649A937215422 | All | | Zora | UniswapV3Factory | 0x7145F8aeef1f6510E92164038E1B6F8cB2c42Cbb | All | | Ethereum | FranchiserFactory | 0xf754A7E347F81cFdc70AF9FbCCe9Df3D826360FA | All | | Ethereum | UniStaker | 0xE3071e87a7E6dD19A911Dbf1127BA9dD67Aa6fc8 | All | | Ethereum | V3FactoryOwner | 0x2e27332b25Ce245F6628377bc83573A001313C58 | All | - “All”: The Safe Harbor Agreement will cover both the subcontracts currently deployed under this contract and any future subcontracts deployed through it. This ensures that all present and future subcontracts are protected. 1. Contact Details: Designated security contact for Uniswap 2. Bounty Terms: Predetermined rewards for successful whitehats that protect protocol funds * * * ## Implementation Plan 1. Register Agreement On-Chain: - The agreement will be registered on Ethereum in the Safe Harbor Registry at address 0x8f72fcf695523a6fc7dd97eafdd7a083c386b7b6, including all adoptionDetails. This ensures transparency and immutability. 2. Communicate Adoption: - An official announcement will be made across all Uniswap communication channels, explaining the adoption and its significance to the community. 3. Future Updates to Scope: - New versions of Uniswap (e.g., V4) will be reviewed and added to the Safe Harbor Agreement scope via Uniswap Governance vote, ensuring continued protection for all new contracts and functionalities. * * * ## Conclusion Adopting the SEAL Whitehat Safe Harbor Agreement equips Uniswap with a rapid response mechanism for active exploits, enabling whitehats to step in effectively when needed most. The agreement provides clear guidelines for action, increasing the protection of user funds and demonstrating Uniswap’s commitment to proactive security. * * * ## References - SEAL Whitehat Safe Harbor Agreement:[GitHub Repository](https://github.com/security-alliance/safe-harbor) - SEAL Whitehat Safe Harbor Agreement Overview: [Notion](https://securityalliance.notion.site/SEAL-Whitehat-Safe-Harbor-Agreement-dbdccd84e279405d89156ff80f83fa01?pvs=74) - Uniswap Bug Bounty: [Uniswap Labs Bug Bounty Update](https://blog.uniswap.org/uniswap-labs-bug-bounty-update) * * * Please share your thoughts and feedback in the discussion below before the proposal moves to a formal vote. ---
**Author:** ![404DAO](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/404dao/32/8120_2.png) [@404DAO](https://gov.uniswap.org/u/404DAO)\ **Post date:** [December 4, 2024, 7:24pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/2 "2024-12-04T19:24:22Z")
Thanks for bringing this forward @Dickson. We’re curious, how did you determine the bounty cap of 2.25M? ---
**Author:** ![Dickson](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dickson](https://gov.uniswap.org/u/Dickson)\ **Post date:** [December 4, 2024, 7:40pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/3 "2024-12-04T19:40:03Z")
Hey @404DAO - Thanks for reviewing the proposal! SEAL worked together with the UF to put forth the bounty terms. The bounty cap of 2.25M was chosen to match the current bounty cap for V3 of being 2.25M [source](https://blog.uniswap.org/uniswap-labs-bug-bounty-update). ---
**Author:** ![pepo](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/pepo/32/9497_2.png) [@pepo](https://gov.uniswap.org/u/pepo)\ **Post date:** [December 9, 2024, 4:55pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/4 "2024-12-09T16:55:06Z")
I find the proposal compelling and am in support of it. However, I would like clarification on the following points: 1. **Incentive Overlap** Considering Uniswap Labs already operates a bounty program, could you clarify if there’s an overlap where participants might benefit from both this proposal and the existing program? How is this “double dipping” of incentives defined or avoided? 2. **Address Management and Security** How will the addresses be maintained and how we can ensure there is not a single point of failure? - I’ve noticed that some recovery addresses for different chains, like the one for Arbitrum (see: [GitHub Repository](https://github.com/uniswapfoundation/governance-processes/blob/main/TREASURY_ADDRESSES.md)), are simply Externally Owned Accounts. We should ensure that these are ultimately controlled by the DAO to prevent potential loss of funds and legal liabilities. - Regarding the scope of contracts covered by the bounty, in the event of a hack, will the bounty be calculated on a “per contract” basis, or will it be a singular “event-based” bounty? Clarification here is crucial to prevent disputes if a security breach occurs. - How does this apply specifically to the hook contracts of Uniswap V4? > [@Dickson](#): > > The Safe Harbor Agreement will cover both the subcontracts currently deployed under this contract and any future subcontracts deployed through it. This ensures that all present and future subcontracts are protected. 1. **Contact Details and Availability** I suggest implementing a mechanism where the availability of the contact person is confirmed periodically, perhaps every few months. If there’s no confirmation, there should be a system in place to rotate the Point of Contact (PoC) to ensure continuous support and communication. ---
**Author:** ![Dickson](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dickson](https://gov.uniswap.org/u/Dickson)\ **Post date:** [December 9, 2024, 5:28pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/5 "2024-12-09T17:28:35Z")
Hey Pepo! Thanks for reading over the proposal! 1. The Safe Harbor Agreement covers only active exploits - Which would be considered out of scope of Uniswap’s Bug Bounty (since it doesn’t apply to active exploits). So whitehats would only be paid once through Safe Harbor & there wouldn’t be any double dipping 2. Pinging @eek637 to answer - Pinging @eek637 to answer - It will be a event-based bounty not per contract - I believe it’s clearly stated in the legal document, but I will add additional clarification inside the DAO proposal too - Currently we’re not including the scope of v4 contracts since they haven’t been deployed yet but when v4 comes out we’ll have another DAO proposal to update the scope of the Safe Harbor Agreement to include the v4 addresses in the scope as well. 3. Oh that’s an interesting idea. So would we want to have the POC to, every few months, post a forum post confirming that they’re available. If they aren’t then we should elect a new POC in place of them? ---
**Author:** ![eek637](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/eek637/32/7037_2.png) [@eek637](https://gov.uniswap.org/u/eek637)\ **Post date:** [December 9, 2024, 5:35pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/6 "2024-12-09T17:35:35Z")
@pepo the arbitrum address is the alias for Uniswap’s mainnet timelock address (docs [here](https://docs.arbitrum.io/how-arbitrum-works/arbos/l1-l2-messaging#address-aliasing)). You can check out a successful transaction using that address [here](https://vote.uniswapfoundation.org/proposals/45). ---
**Author:** ![pepo](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/pepo/32/9497_2.png) [@pepo](https://gov.uniswap.org/u/pepo)\ **Post date:** [December 9, 2024, 6:04pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/7 "2024-12-09T18:04:38Z")
> [@eek637](#): > > @pepo the arbitrum address is the alias for Uniswap’s mainnet timelock address (docs [here](https://docs.arbitrum.io/how-arbitrum-works/arbos/l1-l2-messaging#address-aliasing)). You can check out a successful transaction using that address [here](https://vote.uniswapfoundation.org/proposals/45). Thanks for this clarification, I wasn’t aware of Arbitrum Aliases, wanted to make sure we were in the loop for the security standards of the DAO. > [@Dickson](#): > > If they aren’t then we should elect a new POC in place of them? I think that would make sense, especially when thinking way down the road. Thanks for all these clarifications. ---
**Author:** ![Dickson](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dickson](https://gov.uniswap.org/u/Dickson)\ **Post date:** [December 9, 2024, 6:45pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/8 "2024-12-09T18:45:05Z")
Thanks for your suggestions & questions! I updated the DAO proposal with the clarification on the bounty & the POC stating their availability every 4 months ---
**Author:** ![dennisonb](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/dennisonb/32/1860_2.png) [@dennisonb](https://gov.uniswap.org/u/dennisonb)\ **Post date:** [December 9, 2024, 7:19pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/9 "2024-12-09T19:19:46Z")
Welcome to the forum @Dickson ! Great post, I like the inclusion of the addresses for the funds for upfront transparency. I was immediately wondering about that myself. Given the critical nature of whitehat interventions, has the team considered adding a requirement for post-incident reports from whiteats to help improve protocol security? This could help document attack vectors and prevention strategies while maintaining the whitehat’s anonymity. ---
**Author:** ![Dickson](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dickson](https://gov.uniswap.org/u/Dickson)\ **Post date:** [December 9, 2024, 7:46pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/10 "2024-12-09T19:46:53Z")
Hi @dennisonb! Thanks for reviewing the proposal! That’s an interesting idea! I’m unsure if the whitehats are actually the best to write that report. Whitehats are not the people who had originally discovered the bug (since that should be reported through a bug bounty) - thus they might not have full knowledge on how the exploit actually worked (ie. a MEV bot that’s rescuing funds by frontrunning the hacker). Given how high profile Uniswap is, there should be no shortage of reports on the incident if it were (but hopefully never) occur. Additionally I think it would be best to not add non-essential restraints on the whitehat. Their job is solely to rescue funds and return them to the protocol. ---
**Author:** ![kpk](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/kpk/32/10526_2.png) [@kpk](https://gov.uniswap.org/u/kpk)\ **Post date:** [December 16, 2024, 3:48pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/11 "2024-12-16T15:48:02Z")
Thanks for sharing this proposal, @Dickson. At Karpatkey, security is a core value for us, so we’re fully behind this initiative. Uniswap is a battle-tested protocol, and we truly appreciate the hard work that its stakeholders continue to put into maintaining its security. As a leader in the space, Uniswap has the opportunity to set the gold standard for security practices, and we believe the SEAL proposal is a big step in that direction. We’re excited to see this move forward and hope it’s adopted soon! ---
**Author:** ![Dickson](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dickson](https://gov.uniswap.org/u/Dickson)\ **Post date:** [December 16, 2024, 6:24pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/12 "2024-12-16T18:24:43Z")
Thank you all for the support! We’ve now moved on to the temperature check phase! Here’s the Temp Check forum post: [https://gov.uniswap.org/t/temp-check-adopt-the-seal-safe-harbor-agreement/25072](https://gov.uniswap.org/t/temp-check-adopt-the-seal-safe-harbor-agreement/25072) & Here’s the Snapshot: [https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xba36ded3039fc2588cdc7352e2ac6dd40ca0c3548576d9d31256663fbfc3f1b4](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xba36ded3039fc2588cdc7352e2ac6dd40ca0c3548576d9d31256663fbfc3f1b4) ---
**Author:** ![BlockworksResearch](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/blockworksresearch/32/7292_2.png) [@BlockworksResearch](https://gov.uniswap.org/u/BlockworksResearch)\ **Post date:** [December 16, 2024, 9:09pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/13 "2024-12-16T21:09:22Z")
We fully support this proposal and believe it makes sense to leverage white hat responses in the event of a hack. White hats should have protection when intervening in security breaches. We also support the dynamic bounty structure, as it ensures there’s always a sufficient incentive for white hat intervention. A few questions on what this looks like moving forward: - Regarding the point of security contact for Uniswap: Is it ever expected that the DAO will nominate these positions, or will they always be appointed by the foundation? While this is not a concern for us in relation to our sentiment on the proposal, we would like to understand the long-term plan. Other DAOs, like Arbitrum, use a security council that rotates every six months. Is this something Uniswap has considered implementing? ---
**Author:** ![eek637](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/eek637/32/7037_2.png) [@eek637](https://gov.uniswap.org/u/eek637)\ **Post date:** [December 16, 2024, 9:39pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/14 "2024-12-16T21:39:36Z")
On the Designated Contact, I raised my hand for it as I’d been chatting with @Dickson et al about the proposal for a couple of months. In general, there isn’t as much to do here as an L2 security council (and hopefully nothing to do at all!). Ultimately, the adoption details can be modified by governance vote so if there’s a compelling reason to change it up it’s easy enough to do. I’d suggest we leave as is for a bit and potentially revisit in six months to a year. ---
**Author:** ![Avantgarde](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/avantgarde/32/8918_2.png) [@Avantgarde](https://gov.uniswap.org/u/Avantgarde)\ **Post date:** [December 19, 2024, 8:23am UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/15 "2024-12-19T08:23:53Z")
We support this proposal as it adds a valuable and complementary function to Uniswap’s security framework and current bug bounty program. The possibility of recovering funds from active exploits serves as a nice safeguard, and would arguably be highly appreciated by any affected users should such a scenario present itself. After all, security over user funds is imperative. Bounty structure is also fair. Will be voting yes! ---
**Author:** ![kaereste](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/kaereste/32/7799_2.png) [@kaereste](https://gov.uniswap.org/u/kaereste)\ **Post date:** [December 20, 2024, 5:39pm UTC](https://gov.uniswap.org/t/rfc-adopt-the-seal-safe-harbor-agreement/24971/16 "2024-12-20T17:39:25Z")
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two. We’re voting FOR the proposal. We generally favor proposals that help enhance protocol security, and the proposed agreement—although hopefully we never have to use it—does precisely that. All the questions that came to our mind after originally reading the proposal have already been addressed, so we don’t have any material reason to be skeptical or against the proposal.