Authors: Uniswap Accountability Committee
Over the past two years, the DAO has approved numerous EVM-based deployments for Uniswap v3. There has only been one instance of a deployment proposal that did not pass the off-chain stage due to not meeting quorum: Fantom. We believe that this sets a precedent for optimistically acknowledging incoming EVM-based deployments as canonical. The same precedent can be set for v2 since there was a recent proposal to deploy v2 across all target chains with v3 in one fell swoop.
The v3-deployments.uniswap.eth & v2deployments.uniswap.eth ENS subdomains act simply as records of the v3/v2 deployments that the DAO has “blessed”. From a legal as well as technical perspective, alterations to the subdomain don’t hold any weight–it’s merely a place onchain that the DAO can recognize v3/v2 deployments across various EVM chains. This way, there’s a public place to keep track of which deployments are official. Such recognition is important because it allows users and developers to ensure that the contracts they’re interacting with are representative of the real Uniswap (i.e. the Uniswap fork that has been approved by the DAO), thereby ensuring security and consistency across each fork.
When the DAO currently approves deployments onchain, only the v3-deployments.uniswap.eth & v2deployments.uniswap.eth text records are being altered. The actual contract deployment is completed by a third party, like @GFXlabs. In fact, the deployment has to be completed prior to the onchain vote since the text record alterations requires the
We are proposing to enable the Uniswap Accountability Committee multisig to alter the subdomains as soon as a deployment’s RFC passes the 7-day discussion period–given there are no major points of contention during the RFC phase. The RFC should give ample time to the DAO to make a decision regarding the deployment without having to partake in a 4+ week governance ordeal. And to make sure voters have a say in this process, we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
Currently, the Uniswap DAO, more specifically the timelock address (0x1a9C8182C09F50C8318d769245beA52c32BE35BC) owns AND manages both subdomains. This proposal would make the Accountability Committee the manager of the subdomains. If at any time the DAO would like to alter the manager again or regain control, this can be done via an onchain vote since the timelock still owns the subdomains.
Step 1
Step 2 (Work for the Deployer and Accountability Committee)
The onchain proposal needs to include the function calls below to grant the Accountability Committee write permissions to the subdomains. The DAO will maintain ownership of the primary domain, uniswap.eth, and thus have the ability to revoke the Committee's permissions through a governance vote and establish checks and balances.
For Uniswap v3 Subdomain:
setOwner(
node = 0x0b9638d2c5bd4528d603562a1fa1e734fe1b88e680f448d779531e9bc2b55f12,
owner = 0x3B59C6d0034490093460787566dc5D6cE17F2f9C
)
For Uniswap v2 Subdomain:
setOwner(
node = 0x30e9fa72b4d7d40be0f8809d748497121d5f38ebf8700a7d2e303074e9ccf1a5,
owner = 0x3B59C6d0034490093460787566dc5D6cE17F2f9C
)
The Accountability Committee will retroactively alter the subdomain text record for any deployments that are approved and haven't been included in the subdomains after the approval of this proposal. The Committee will also add the text for deployments that did not go through the formal governance process from the Uniswap Revitalization and Growth proposal.
Authors: Uniswap Accountability Committee
Over the past two years, the DAO has approved numerous EVM-based deployments for Uniswap v3. There has only been one instance of a deployment proposal that did not pass the off-chain stage due to not meeting quorum: Fantom. We believe that this sets a precedent for optimistically acknowledging incoming EVM-based deployments as canonical. The same precedent can be set for v2 since there was a recent proposal to deploy v2 across all target chains with v3 in one fell swoop.
The v3-deployments.uniswap.eth & v2deployments.uniswap.eth ENS subdomains act simply as records of the v3/v2 deployments that the DAO has “blessed”. From a legal as well as technical perspective, alterations to the subdomain don’t hold any weight–it’s merely a place onchain that the DAO can recognize v3/v2 deployments across various EVM chains. This way, there’s a public place to keep track of which deployments are official. Such recognition is important because it allows users and developers to ensure that the contracts they’re interacting with are representative of the real Uniswap (i.e. the Uniswap fork that has been approved by the DAO), thereby ensuring security and consistency across each fork.
When the DAO currently approves deployments onchain, only the v3-deployments.uniswap.eth & v2deployments.uniswap.eth text records are being altered. The actual contract deployment is completed by a third party, like @GFXlabs. In fact, the deployment has to be completed prior to the onchain vote since the text record alterations requires the
We are proposing to enable the Uniswap Accountability Committee multisig to alter the subdomains as soon as a deployment’s RFC passes the 7-day discussion period–given there are no major points of contention during the RFC phase. The RFC should give ample time to the DAO to make a decision regarding the deployment without having to partake in a 4+ week governance ordeal. And to make sure voters have a say in this process, we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
Currently, the Uniswap DAO, more specifically the timelock address (0x1a9C8182C09F50C8318d769245beA52c32BE35BC) owns AND manages both subdomains. This proposal would make the Accountability Committee the manager of the subdomains. If at any time the DAO would like to alter the manager again or regain control, this can be done via an onchain vote since the timelock still owns the subdomains.
Step 1
Step 2 (Work for the Deployer and Accountability Committee)
The onchain proposal needs to include the function calls below to grant the Accountability Committee write permissions to the subdomains. The DAO will maintain ownership of the primary domain, uniswap.eth, and thus have the ability to revoke the Committee's permissions through a governance vote and establish checks and balances.
For Uniswap v3 Subdomain:
setOwner(
node = 0x0b9638d2c5bd4528d603562a1fa1e734fe1b88e680f448d779531e9bc2b55f12,
owner = 0x3B59C6d0034490093460787566dc5D6cE17F2f9C
)
For Uniswap v2 Subdomain:
setOwner(
node = 0x30e9fa72b4d7d40be0f8809d748497121d5f38ebf8700a7d2e303074e9ccf1a5,
owner = 0x3B59C6d0034490093460787566dc5D6cE17F2f9C
)
The Accountability Committee will retroactively alter the subdomain text record for any deployments that are approved and haven't been included in the subdomains after the approval of this proposal. The Committee will also add the text for deployments that did not go through the formal governance process from the Uniswap Revitalization and Growth proposal.
https://gov.uniswap.org/t/update-uni-v3-v2-deployment-process-march-2024/23468/7
https://gov.uniswap.org/t/update-uni-v3-v2-deployment-process-march-2024/23468/7
https://gov.uniswap.org/t/update-uni-v3-v2-deployment-process-march-2024/23468/4
https://gov.uniswap.org/t/update-uni-v3-v2-deployment-process-march-2024/23468/4
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’ll be voting in favor of the proposal during the on-chain vote for the reasons outlined in our comment above which we made during the temp-check phase.
The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’ll be voting in favor of the proposal during the on-chain vote for the reasons outlined in our comment above which we made during the temp-check phase.
The snapshot is live to move forward with this amended governance process. The only edit to this proposal is the addition of a challenge period, allowing delegates to vote against a deployment during the onboarding package temp check, as suggested by @MattOnChain.
we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
The snapshot is live to move forward with this amended governance process. The only edit to this proposal is the addition of a challenge period, allowing delegates to vote against a deployment during the onboarding package temp check, as suggested by @MattOnChain.
we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
The Sei snapshot demonstrates how this will be implemented.
Voting will end on Feb 16 @ 2pm ET.
Similar to StableLab's post on their Delegate Platform thread, we are supportive of many of the proposal changes. Recognizing that this proposal will likely pass, we did want to share our reasoning on voting to not update the process as currently proposed:
Similar to StableLab's post on their Delegate Platform thread, we are supportive of many of the proposal changes. Recognizing that this proposal will likely pass, we did want to share our reasoning on voting to not update the process as currently proposed:
For these reasons, although supportive of many of the provisions within the proposal, we have decided to vote against.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’ve participated in a number of votes to recognize deployments as canonical in the past and we’ve found that they typically do not raise any concerns. Streamlining that process and reducing the friction created both for the deployments but also for delegates by the governance process makes sense.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’ve participated in a number of votes to recognize deployments as canonical in the past and we’ve found that they typically do not raise any concerns. Streamlining that process and reducing the friction created both for the deployments but also for delegates by the governance process makes sense.
As long as delegates can still vote on whether or not a deployment should also receive an onboarding package (similar to the Sei vote), we believe the updated deployment process makes sense.
As a result, we’ll be voting in favor of the proposal.
It’s worth highlighting that for the next few deployments, on chain votes may not include direct fund transfers as there may be enough funds already in the accountability wallet given the recent price appreciation of the $UNI tokens.
The snapshot is live to move forward with this amended governance process. The only edit to this proposal is the addition of a challenge period, allowing delegates to vote against a deployment during the onboarding package temp check, as suggested by @MattOnChain.
we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
The snapshot is live to move forward with this amended governance process. The only edit to this proposal is the addition of a challenge period, allowing delegates to vote against a deployment during the onboarding package temp check, as suggested by @MattOnChain.
we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
The Sei snapshot demonstrates how this will be implemented.
Voting will end on Feb 16 @ 2pm ET.
Similar to StableLab's post on their Delegate Platform thread, we are supportive of many of the proposal changes. Recognizing that this proposal will likely pass, we did want to share our reasoning on voting to not update the process as currently proposed:
Similar to StableLab's post on their Delegate Platform thread, we are supportive of many of the proposal changes. Recognizing that this proposal will likely pass, we did want to share our reasoning on voting to not update the process as currently proposed:
For these reasons, although supportive of many of the provisions within the proposal, we have decided to vote against.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’ve participated in a number of votes to recognize deployments as canonical in the past and we’ve found that they typically do not raise any concerns. Streamlining that process and reducing the friction created both for the deployments but also for delegates by the governance process makes sense.
The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’ve participated in a number of votes to recognize deployments as canonical in the past and we’ve found that they typically do not raise any concerns. Streamlining that process and reducing the friction created both for the deployments but also for delegates by the governance process makes sense.
As long as delegates can still vote on whether or not a deployment should also receive an onboarding package (similar to the Sei vote), we believe the updated deployment process makes sense.
As a result, we’ll be voting in favor of the proposal.
It’s worth highlighting that for the next few deployments, on chain votes may not include direct fund transfers as there may be enough funds already in the accountability wallet given the recent price appreciation of the $UNI tokens.
