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.

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.

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.

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?

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!

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.

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?

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!

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), 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?

  Quoted from  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.

  back to top ↑

3. 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.

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), 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?

  Quoted from  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.

  back to top ↑

3. 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.