Introducing EP5.13 & EP5.14 into the ENS DAO Governance documentation

docs/dao/proposals/5.13.mdx

@@ -0,0 +1,72 @@
+{/** @type {import('@/lib/mdxPageProps').MdxMetaProps} */}
+export const meta = {
+    description: 'This proposal aims to establish a Security Council for the ENS DAO with the authority to veto malicious proposals, with a built-in expiration mechanism to prevent centralized control and ensure greater delegation and governance distribution over time.',
+    emoji: '📖',
+    contributors: [
+        'alextnetto.eth'
+    ],
+    proposal: {
+        tally: '42329103797433777309488042029679811802172320979541414683300183273376839219133',
+        type: 'executable'
+    }
+};
+
+# [EP 5.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)

docs/dao/proposals/5.14.mdx

@@ -0,0 +1,73 @@
+{/** @type {import('@/lib/mdxPageProps').MdxMetaProps} */}
+export const meta = {
+    description: 'This proposal aims to introduce new permissions for deploying Endowment funds, focusing on improved diversification and alignment with the evolving market landscape and liquidity.',
+    emoji: '📖',
+    contributors: [
+        'alextnetto.eth'
+    ],
+    proposal: {
+        tally: '462537345451524095629071359388092434511638926463658570104856324869910407296726',
+        type: 'executable'
+    }
+};
+
+# [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;
+
+   1. Through the [Genesis Vault](https://app.stakewise.io/vault/mainnet/0xac0f906e433d58fa868f936e8a43230473652885).
+
+3. Mint (and burn) osETH on Stakewise v3;
+
+   1. Through the Genesis Vault
+
+4. WETH/osETH pool on Balancer;
+5. WETH/osETH pool on Aura Finance;
+6. Swaps:
+
+   1. WETH <> osETH on Balancer
+   2. USDC <> osETH on Uniswap v3
+   3. USDC <> WETH <> osETH on CoW Swap
+   4. RPL <> WETH on Uniswap v3
+   5. RPL <> WETH on CoW Swap
+
+7. 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.