memoscan

0x77c8…41fb

All memos sent from and to 0x77c8…41fb.
0x77c8e959…41fbsent to0x1f3d3a7a…0591·#24,929,488·0x1cdb1698…d6cd54
{"title":"Retroactive Grant for blockful Security Work","description":"$150,000 retroactive grant to blockful: $149,900 in sUSDS shares plus $100 in ETH to fund the recipient wallet for gas. Forum: https://shutternetwork.discourse.group/t/retroactive-grant-for-blockfuls-security-work/810"}
0x77c8e959…41fbsent to0x1f3d3a7a…0591·#24,669,685·0x1e9e5109…e2eaf6
{"description":"## Summary\n\nThis proposal serves as a fallback, in case we don't get sufficient quorum for [proposal #95](https://app.decentdao.org/proposals/95?dao=eth:0x36bD3044ab68f600f6d3e081056F34f2a58432c4).\n\nInstall a guard module on Azorius enabling a designated security council to veto malicious proposals before execution. Changes timelock period from 0 to 2 days. This is an emergency security measure in response to identified governance vulnerabilities.\n\n---\n\n## Motivation\n\nOur security research has identified a critical governance vulnerability in 0x36 DAO that requires immediate protective action. The current market valuation of SHU, and the configuration of quorum and proposal permissions on Shutter 0x36, allow for any address with **~$100k worth of SHU** to create any amount of proposals and individually approve them unless defense votes to reject each proposal, while the attacker only needs to vote 1 of them to approve, and could take control of the whole treasury with that. \n\nA security council guard provides:\n- **Emergency veto capability** for governance attacks/malicious proposals\n- **Standard practice** in high-value DAOs (ENS, Arbitrum, Optimism)\n\nA timelock of **2 days (14,400 blocks)** gives the security council time to respond to vetoing a proposal after its approval. The council can veto at any time — during voting, during the timelock, or even during the execution window — but the timelock provides an additional buffer beyond the voting period itself.\n\n**This proposal establishes the security foundation that will allow safe disclosure, open discussions, and implementation of future protections.**\n\n---\n\n## Technical Implementation\n\n**Deploy and configure security measures:**\n\n- Deploy `SecurityCouncilAzorius` guard contract with council multisig as `owner()` [DONE]\n- Install guard on Azorius module via `setGuard()`\n- Set timelock period (`timelockPeriod`) from **0 to 14,400 blocks** (approximately 2 days)\n\n**Transaction sequence (atomic execution):**\n\n1. `Azorius.updateTimelockPeriod(14400)` — set 2-day timelock\n2. `Azorius.setGuard(guardAddress)` — install security council guard\n\n---\n\n## Security Council Composition\n\nWe propose an **8-member council** of trusted, active delegates:\n\n1. **0xffFA76e332cA7afaae3931cb5d513B7fd681C4CF** - Kleros Labs\n2. **0xe52C39327FF7576bAEc3DBFeF0787bd62dB6d726** - 5pence\n3. **0xDffDb9BeeA2aB3151BcBcf37a01EE8726F22ed94** - d0z3y\n4. **0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44** - Mikko Ohtamaa\n5. **0x06c2c4dB3776D500636DE63e4F109386dCBa6Ae2** - Jacob Czepluch\n6. **0x1F3D3A7A9c548bE39539b39D7400302753E20591** - blockful\n7. **0x057928bc52bD08e4D7cE24bF47E01cE99E074048** - DAOplomats\n8. **0xB6647e02AE6Dd74137cB80b1C24333852E4AF890** - Lanski\n\n---\n\n## Multisig Configuration\n\n- **Threshold:** 5-of-8 (balance of security and responsiveness)\n- **Implementation:** Safe Multisig\n- **Chain:** Ethereum mainnet (Shutter 0x36 operates on mainnet)\n- **Initial deployment:** 1-of-1 Safe (blockful placeholder), upgraded to 5-of-8 after confirming addresses and availability to participate.\n\n---\n\n## Veto Authority\n\nThe security council can veto any proposal or individual transaction before execution if it:\n\n- Threatens treasury security\n- Contains malicious calldata\n- Is identified as spam or governance attack\n\n**Veto timing:** The council can act during voting, during the timelock period, or during the execution window. The 2-day timelock provides additional reaction time beyond the voting period itself.\n\n**Veto mechanism:** The guard computes a transaction hash for each proposal action. If that hash is vetoed, the transaction reverts when Azorius attempts execution.\n\n---\n\n## Timeline\n\n- **Proposal posted:** Mar 13\n- **Voting period:** 3 days (standard 0x36 period)\n- **Execution:** Mar 16\n- **Full disclosure:** Post-mortem after execution. Details already on repo [blockful/shutter-security-council](https://github.com/blockful/shutter-security-council)\n\n---\n\n## Why This Sequence\n\nStandard responsible disclosure practice requires:\n\n1. Put safeguard in place (this proposal)\n2. Coordinate with DAO\n3. **Implement fix**\n4. **Disclose publicly only after fix is deployed**\n\n## Long-Term Considerations\n\nThis security council is an **emergency measure**. Post-mitigation, the DAO can:\n\n- Evaluate governance parameter improvements (proposal thresholds, voting delays, execution periods)\n- Consider path to remove or adjust security council as other governance parameters are hardened\n- Implement comprehensive governance upgrade to restore fuller decentralization with security\n\n**The goal is not permanent centralization.** It's establishing a security foundation that allows the community to discuss in the open the risks exposed, and decide to keep it, change it or create other defense structures..\n\n## Next Steps\n\nWith this proposal in place, we can:\n\n1. Safely disclose the full technical details of the vulnerability\n2. Have open community discussion about long-term governance improvements\n3. Implement additional protections through subsequent proposals\n\n\n## Why Now\n\n**Governance vulnerabilities don't wait.** The economic incentive exists today. Every day without protection is a day of risk.\n\nWe understand this creates permissioned execution. We're asking the community to adopt this **to prevent permanent loss.**\n\n## Voting Instructions\n\n- **Vote YES** to approve emergency security council implementation\n- **Vote NO** if you believe the risk doesn't warrant this measure\n\n## Links\n\n- **Forum discussion:** For security, post will only be made after proposal. In the 0x36 [governance forum](https://shutternetwork.discourse.group/c/shutter-dao/dao-proposals/15).\n- **Security Council multisig:** [Safe](https://app.safe.global/transactions/history?safe=eth:0x3ea731dAF66D6A7980549f90152CD9A761B9c0C0)\n- **Security Council contract:** [Etherscan](https://etherscan.io/address/0xb04f553c482063a99b10c55033b56bd50b6b0334#code)\n\n## Questions\n\nHappy to address questions in this forum thread. Some technical details of the risk and attack simulations will be withheld until after the mitigation is in place.\n\n**Thank you for your attention to Shutter DAO's security and governance integrity.**\n","title":"[SECURITY](Fallback) Implement Security Council to Prevent Governance Attacks"}
0x77c8e959…41fbsent to0x1f3d3a7a…0591·#23,298,478·0x7de86136…253bf6
And so the era of DUNAs begins. We vote FOR this proposal. Creating a DUNA for Uniswap will help the DAO achieve what it could not before, due to the legal impossibilities of an unincorporated organization. In addition, it provides more legal security for participants in governance, . We hope that, with DUNA, Uniswap DAO will not only improve legal and operational issues, but also others related to the evolution of the organization and the protocol.
0x77c8e959…41fbsent to0x1f3d3a7a…0591·#23,298,473·0x4a88c15b…a3f42e
We vote FOR this proposal. Incentive programs are not usually effective in the long term, since when the money runs out, capital migrates to new opportunities. In the case of this proposal, we like the idea of bringing in other protocols that partially fund the incentives, because it does not depend solely on Uniswap DAO to keep the rewards flowing.