Empowering the foundation is positive, but the feedback regarding the board selection being independent was not applied. This makes me concerned about keeping all funded entities equally and truly accountable.
Reducing the supply cap of the Comets on Ethereum as a protective measure chosen by Gauntlet makes sense, especially after the Kelp/Aave attack. Therefore, we voted FOR the proposal.Reducing the supply cap of the Comets on Ethereum as a protective measure chosen by Gauntlet makes sense, especially after the Kelp/Aave attack. Therefore, we voted FOR the proposal.Creating a committee to manage Compound’s treasury and generate an additional source of revenue for the DAO is necessary and has already been implemented across several other DAOs. Internalizing this management could reduce costs for Compound, but it is important that the level of rigor regarding security and transparency remains high, so the DAO does not become the victim of an exploit and lose its treasury in an attack or become exposed to vulnerabilities in other protocols. We voted FOR the proposal.The delegate incentive program is fundamental to Compound. The protocol depends on the constant participation of delegates to approve parameter changes and to introduce and remove markets. It is ongoing work that keeps the protocol functional and operational. For this reason, it is fair that Compound compensates some delegates to help ensure the votes needed to pass proposals critical to the protocol. We voted FOR the proposal.Compound v4 introduces several changes that will place it on the same path as its main competitors, Morpho and Aave. We agree with the upgrades, although the cost of implementing them is high. We voted FOR the proposal, but it is essential that the Compound Foundation consistently communicates the progress and deliverables of this new version of the protocol, in order to provide greater transparency and confidence to $COMP holders.
ipfs://QmPiTo2F5BgVtAZ5YdF7GDxSxTwTro44cj2KJ7xgLiPP5B{"title":"Proposer Gating - Phase 1","description":"Phase 1 of the Proposer Gating proposal: assign Proposer hats to 9 trusted delegates and raise the SHU proposer threshold to 1,000,000 SHU on the existing strategy. Forum discussion: https://shutternetwork.discourse.group/t/implement-proposer-roles/817"}
This domain will not be used by end users, so it doesn't have the explicit necessity non technical.
In private, I suggested cid.eth (chain ID), which was registered later by clowes.eth. That’s also a strong option and, importantly, doesn’t require a DAO proposal.
I’d personally prefer to avoid going down the on-chain proposal route here. It could open the door to similar requests in the future, and one- and two-letter domains can become a meaningful revenue source for the DAO.
We should proceed with business as usual until next steps are clearly defined. If the eventual decision is to shut down the working groups, the worst-case outcome is simply returning the remaining funds to the DAO.
In support for activating ENSIP-19. Calldata reviewed: https://discuss.ens.domains/t/executable-enable-l2-reverse-registrars-and-new-eth-registrar-controller/20969/15
eth.limo has been amazing and core to the ENS product and community.We support the Unruggable team and trust them to coordinate and create a team to handle this core infrastructure. While the proposal seeks stable funding, in practice, this will not happen. The calldata and how it's structured are much more similar to the service provider program than to labs. The requirement for annual USDC approval renewal contradicts the goal of providing the stable, open-ended funding that Labs has. We gave early feedback/concerns in the forum and also in DMs, which continue to be the same. Mainly about focusing on maturing the service provider program and also about the funding amount/team expansion needed. We agree with the vision that Unruggable is trying to push for the DAO to have a more equitable structure for funding mechanisms and reporting for teams, including labs. Labs also look favorable to advance discussions regarding this future structure. The main reason to vote against it is that, in our view, discussions and efforts need to evolve this subject openly rather than push one specific proposal in a rushed way.
It is great to have the commitment from ENS Labs for doing quarterly reports on the progress: https://discuss.ens.domains/t/temp-check-ep-5-22-ensv2-development-funding-request/19762/24
# [EP 5.23] [Executable] blockful's governance security bounty
## Summary
This proposal aims to compensate the blockful team for their work in identifying, analyzing, reporting and mitigating a severe vulnerability in ENS DAO's governance structure.
## Background
In March 2024, blockful uncovered a critical vulnerability that could have led to a [~$150M](https://dune.com/steakhouse/ens-steakhouse) theft and protocol capture. Their subsequent work led to the implementation of the Security Council, significantly enhancing ENS DAO's resilience against attacks.
## Contribution Details
The team involved is a [different](https://discuss.ens.domains/t/blockful-service-provider-reports/19553#p-54163-other-contributions-not-related-to-service-provider-scope-14) squad than the one working on the scope of the [ENS service provider](https://discuss.ens.domains/t/blockful-service-provider-reports/19553). It was developed by 2 researchers, 1 smart contract engineer and 4 different auditors the team has worked with previously. Summing up to ~600 hours, the scope includes:
* Comprehensive vulnerability assessment and risk analysis: **[Here](https://mirror.xyz/research.blockful.eth/-PfMduhpxdypPrutofr6099T4ROpsAmX0fPNbvDgR\_k)** is our detailed security report.
* Data analysis of ENS governance metrics and study of past DAO attacker's behaviors.
* Design, development and deployment of the Security Council contract and multisig.
* The Security Council was thought with several key features to balance security and decentralization.
* Smart contract implementation and testing ([GitHub](https://github.com/blockful-io/security-council-ens))
* Governance proposal drafting and support [[1](https://snapshot.org/#/ens.eth/proposal/0xf3a4673fe04a3ecfed4a2f066f6ced1539a5466d61630428333360b843653c54), [2](https://snapshot.org/#/ens.eth/proposal/0xa0b1bfadf6853b5b0d59d3c4d73c434fc6389339887d05de805361372eb17c3a), [3](https://www.tally.xyz/gov/ens/proposal/42329103797433777309488042029679811802172320979541414683300183273376839219133)]
More details can be found on the links above for past proposals and the [report](https://mirror.xyz/research.blockful.eth/-PfMduhpxdypPrutofr6099T4ROpsAmX0fPNbvDgR\_k).
## Compensation Rationale
 As a team that is totally bootstrapped and never received any investment, this support us to keep it sustainable with the resources invested towards this initiative. The requested amount represents fair compensation for:
* The potential loss prevention of ~$150M, capture of the DAO and protocol. The attack is anything but theoretical and there are actually many groups of investors who specialize in "risk free value raiders". They have exerted the attack on other DAOs before. Currently there are [unknown whales](https://etherscan.io/address/0x245445940b317e509002eb682e03f4429184059d#tokentxns) buying ENS for +450 days and have ~2M ENS, showing how feasible the scenario is, more than the average quorum, in one wallet.
* A critical code bug bounty in [ENS is $250k USDC](https://immunefi.com/bug-bounty/ens/scope/#assets). Our work was much beyond identifying and disclosing.
* Significantly lower cost compared to standard rates charged by other security service providers in the DAO space, which typically demand liquid compensation. An example is that Open Zeppelin (one of the most reputable players in security) [charges $4M/year at Compound](https://compound.finance/governance/proposals/76), which recently [suffered](https://mirror.xyz/research.blockful.eth/v0GEP49oXP1gzMDlyP91-S4XIa8PIOd0vKq-6R8f54I) this type of attack.
* Months of dedicated work by the team involved (researchers, devs and auditors).
* The long-term value added to ENS through enhanced security.
* Our commitment to ENS's long-term success and continued contribution, as evidenced by the 2-year vesting schedule.
## Compensation Structure
* Total amount: 100k USDC + 15k vested ENS tokens
* Vesting period: 2 years
* Vesting start date: April 8, 2024 (date of initial research disclosure)
* Vesting schedule: Linear vesting
* Will be sent to the meta-governance multisig, transferred, and vested to blockful.
## Benefits to ENS DAO
* Sets a positive precedent that **responsible vulnerability disclosure and correction are rewarded**, encouraging future security contributions
* Preserves DAO treasury liquidity by using part of the bounty in ENS tokens instead of USDC or ETH
* Enhances governance security by increasing the number of engaged, security-focused token holders
## Conclusion
By approving this compensation, ENS DAO acknowledges the critical importance of security research and proactive governance improvements. The vesting structure ensures ongoing commitment and aligns incentives for continued contribution to ENS's security and stability.
I support bundling the proposals, but the title and description of values should express it clearly: https://discuss.ens.domains/t/ep-5-24-executable-term-5-q4-collective-working-group-funding-proposal/19801/6
I support the litigation and also appreciate the effort of ENS Labs. Thanks!
My only feedback is that the first voting process was confusing, as there were conditions and no option to abstain. I and other delegates in the forum pointed this out.
# [EP 5.14] [Executable] Endowment permissions to karpatkey - Update #4
# Abstract
This proposal aims to introduce new permissions for deploying Endowment funds, focusing on improved diversification and alignment with the evolving market landscape and liquidity. We are also introducing an independent audit report together with the Permissions Update; this will be the standard practice for Permissions Updates going forward.
# Motivation
Effective treasury management strategies must be adapted to market conditions and protocol updates; for existing Permissions, there might be migrations and introductions of new pools; for new Permissions, protocols and pools that were previously considered immature and unsuitable for the Endowment’s risk appetite may become viable options as they become more time- and battle-tested. This proposal seeks to request new permissions from the ENS DAO for karpatkey, enabling the introduction of new yield-generation strategies for the Endowment.
The new permissions have also been audited by [ThirdGuard](https://thirdguard.com/), an independent 3rd-party, to ensure the suggested changes have been thoroughly reviewed by a technically-competent, independent party.
# Specification
## New permissions implemented in this payload
1. Deposit osETH on Aave v3;
2. Stake (and unstake) ETH on Stakewise v3. Through the [Genesis Vault](https://app.stakewise.io/vault/mainnet/0xac0f906e433d58fa868f936e8a43230473652885).
3. Mint (and burn) osETH on Stakewise v3. Through the Genesis Vault.
4. WETH/osETH pool on Balancer;
5. WETH/osETH pool on Aura Finance;
6. Swaps:
* WETH \<> osETH on Balancer
* USDC \<> osETH on Uniswap v3
* USDC \<> WETH \<> osETH on CoW Swap
* RPL \<> WETH on Uniswap v3
* RPL \<> WETH on CoW Swap
1. Unsign order on Cow Protocol so that a pending order that has been submitted but not executed can be cancelled.
## Additional implementation details
1. The enableModule(address module) function is called to enable the modules, pointing it to the [Avatar address](https://app.safe.global/home?safe=eth:0x4F2083f5fBede34C2714aFfb3105539775f7FE64) (the Endowment).
2. The payload to be executed upon the successful approval of this proposal can be found [here](https://gist.github.com/JeronimoHoulin/55f50e86d1dc874e4e685d5e9b496a67). The proposed permissions policy can be visualised in the aforementioned [link](https://roles.gnosisguild.org/eth:0x703806E61847984346d2D7DDd853049627e50A40/roles/MANAGER/diff/C5Twf3khKv2Ny8PvzoARgHFKFFK8vIiNR7nDkrIM?annotations=false) for ease of review.
3. We have tested the payload to make sure all interactions mentioned on this proposal work as expected through our [Test Safe](https://app.safe.global/transactions/history?safe=eth:0xC01318baB7ee1f5ba734172bF7718b5DC6Ec90E1).
4. With the introduction of the [new Roles App Permissions Visualisation tool](https://roles.gnosisguild.org/eth:0x703806E61847984346d2D7DDd853049627e50A40/roles/MANAGER?annotations=false), manually updating the “Preset Permissions - ENS Endowment” [document](https://docs.google.com/document/d/1KU4a7s-AxAAAPJxd8vexn7kCl8hsr3-c7VIDfEPHbKc/edit?usp=sharing) is no longer necessary. The new tool provides an up-to-date and accurate method for exploring the current permissions granted to karpatkey by the ENS DAO.
# Auditing process
## Introduction of an independent audit report
We have received feedback in the previous proposal that independent, 3rd party code review would be helpful for the ENS community and delegates to make a more informed decision and to reduce delegate fatigue.
In our commitment to transparency and effort towards DAO efficiency, karpatkey decided to engage with independent, third-party firms / individuals for every contract upgrade starting with this proposal. [ThirdGuard](https://thirdguard.com/) has been engaged for this proposal’s code review; ThirdGuard is a provider of on-chain risk monitoring solutions, and has been working with the Zodiac Roles Modifier since its inception (and its precursor, Scope Guard). Given their past experiences across Zodiac Roles Modifier, Solidity, and DeFi risk management, ThirdGuard was deemed to be a suitable candidate to fulfil the role of policy reviewer. Their approach to auditing the permissions can be found [here](https://www.loom.com/share/0b3cbcd6907a4455ab45ead4887c7f9a?sid=9bd0a2c7-d932-45c0-acad-8516201c56ea).
**The ThirdGuard audit for the permissions in this payload can be found** [**here**](https://github.com/ThirdGuard/roles-policy-audits/blob/main/ENS/ens-policy-audit-v2-21st-Aug-2024.pdf)**.**
Audit report summary is as follows:
* No material findings were found.
* Policy changes requested were considered bona fide actions needed by the Manager to carry out their DeFi operations.
* 1 Informational Finding and 1 Warning were logged, and acknowledged by karpatkey. These findings do not post an immediate risk but are relevant to security best practices.
# [EP5.13][Executable] Security Council
\## Abstract
The primary mission of ENS DAO is to govern the protocol and allocate resources from the treasury in line with the DAO's constitution and broader objectives. However, due to changing economic dynamics, the DAO is increasingly vulnerable to attacks aimed at draining its treasury.
To safeguard the DAO's integrity and longevity, a Security Council with the authority to cancel malicious proposals is needed. To avoid perpetuating centralized power, the Security Council's authority will have a built-in expiration date. After two years, anyone will be able to call a \[function]\(https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol#L59) that revokes the council's power to veto proposals, ensuring a time-limited mechanism to counter malicious attacks while promoting more delegation and governance distribution.
!\[security-council-diagram]\(https://hackmd.io/\_uploads/BJb0bHP\_A.png)
\## Motivation
As ENS continues to grow, its treasury in ETH is always growing. Simultaneously, the percentage of tokens actively delegated is on the decline.
This imbalance creates a risk where an attacker could acquire enough $ENS to gain control of the DAO at a cost lower than the treasury's total value. This has been a growing concern since March 2023.
Past attacks on DAOs have exploited similar vulnerabilities, with some \[being thwarted]\(https://x.com/AragonProject/status/1656028382939815937) by components with veto power. Currently, the ENS governance process involves a proposal passing through the governor, relying on delegated voting power for approval. If approved, the governor queues the proposal in a timelock contract, delaying execution by two days. While the governor can cancel proposals, it follows the same pathway as a malicious proposal, introducing potential risks.
The short-term solution was delegating 3.8M $ENS to a contract that can only vote "Against"; more details about this can be found in \[Nick's forum post]\(https://discuss.ens.domains/t/introducing-veto-ensdao-eth/19088). The attack is still profitable and, depending on market conditions can be up to a 3x ROI, like in Dec 2023. We need a \*\*mid-term solution\*\* to cancel the attack, which is this proposal. An article about this research done by the Blockful team will be published \[here]\(https://blockful.io/blog/ens-security-council) after the proposal is executed and there is no attack risk.
\## Specification
To enhance security, the \[SecurityCouncil contract]\(https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol) will be deployed, receiving the PROPOSER\_ROLE in the timelock, granting it the ability to cancel proposals (callable only by the \[Security Council multisig]\(https://etherscan.io/address/0xaa5cd05f6b62c3af58ae9c4f3f7a2acc2cdc2cc7)) without the power to initiate or modify other DAO actions. \*\*The scope of this proposal is to assign the PROPOSER\_ROLE to the SecurityCouncil contract (\[Etherscan]\(https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0#code))\*\*.
To ensure decentralization, the contract will also feature a time-based expiration mechanism that allows anyone to revoke the PROPOSER\_ROLE after two years. This window provides time to strengthen delegation and address current vulnerabilities, facilitating the DAO's transition to a more secure governance scenario.
\## Security considerations
Assigning the PROPOSER\_ROLE to a multisig within the timelock contract is overly broad for our requirements as it allows the address to create operations in the timelock. If the multisig signers are compromised, they could potentially propose and execute malicious changes. Therefore our approach is deploying a new contract similar to the current veto.ensdao.eth contract, which can only do one action: to CANCEL a transaction in the timelock, triggered only by the security council multisig.
The risk is mitigated but one scenario remains: if the whole multisig is compromised then a malicious entity could kick other signers and effectively stop the DAO from executing proposals by canceling all transactions, including any that would remove this contract from the PROPOSER\_ROLE. Anyways, after 2 years, \[anyone can remove the PROPOSER\_ROLE from the contract]\(https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol#L59).
\## Council Operations
It is in the best interest of everyone to make clear the expectations and responsibilities ENS DAO put on those members, backed by the reputation, other roles and gains those might have in the organization.
The security council is expected to act only in emergency, in the given following situations or similar cases:
\* If a proposal goes against the ENS constitution
\* If a proposal is approved with malicious intent against the DAO longevity/sustainability
\* If such proposal is approved by any group of voters, but directly financially incentivised to vote against the DAOs interests to preserve their own financial stake.
\* If any approved proposal goes directly against the DAO for the sole benefit of an attacker.
\## Relevant links
\- SecurityCouncil contract (\[GitHub]\(https://github.com/blockful-io/security-council-ens/blob/main/src/SecurityCouncil.sol), \[Etherscan]\(https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0#code))
\- Security Council multisig (\[Safe]\(https://app.safe.global/home?safe=eth:0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7), \[Etherscan]\(https://etherscan.io/address/0xaA5cD05f6B62C3af58AE9c4F3F7A2aCC2Cdc2Cc7))
\- Snapshot proposals:
  \- \[\[EP5.7]\[Social] Security Council]\(https://snapshot.org/#/ens.eth/proposal/0xf3a4673fe04a3ecfed4a2f066f6ced1539a5466d61630428333360b843653c54)
  \- \[\[EP5.10]\[Social] Confirming the ENS DAO Security Council Members]\(https://snapshot.org/#/ens.eth/proposal/0xa0b1bfadf6853b5b0d59d3c4d73c434fc6389339887d05de805361372eb17c3a)
\- \[Forum discussion]\(https://discuss.ens.domains/t/temp-check-enable-cancel-role-on-the-dao/19090/19)
contact@blockful.iohttps://blockful.io/https://avatars.githubusercontent.com/u/107982496Developing tailor-made blockchain solutions using top-notch technologyweb3 builders, software house