memoscan

0x1f3d…0591

All memos sent from and to 0x1f3d…0591.
0xf7253a0e…0041sent to0x1f3d3a7a…0591·#25,728,670·0xecf719d5…d3db16
{"title":"Security Bounty for blockful","description":"## Summary\n\n$150,000 security bounty to blockful for discovering and remediating a governance capture vulnerability in Shutter DAO.\n\n## The vulnerability\n\nCapturing Shutter DAO governance cost roughly $150k to reach quorum, against a treasury of about $6M. That is a ~45x return for an attacker.\n\nblockful proved the attack was practical by accumulating 2.2M SHU in 3 days without price impact, then disclosed it responsibly to the brainbot team, who acted on the information and delegated 60M SHU to raise the cost of attack.\n\n## Remediation\n\n- Cyfrin-audited SecurityCouncilAzorius veto guard\n- 2-day timelock on proposal execution\n- Anticapture monitoring for abnormal token accumulation\n\n## Payout\n\n- $149,900 in sUSDS shares\n- $100 in ETH to fund the recipient wallet for gas\n\n## Included at no cost\n\n12 months of governance frontend support on Anticapture for Shutter DAO, covering the governance frontend and other Anticapture products.\n\n[Forum discussion](https://shutternetwork.discourse.group/t/retroactive-grant-for-blockfuls-security-work/810)"}
0x76a6d08b…bbb8sent to0x1f3d3a7a…0591·#25,037,037·0x02b46376…915e37
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.
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"}
0x76a6d08b…bbb8sent to0x1f3d3a7a…0591·#24,923,342·0x7b2cd06b…7f2762
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"}
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"}
0xf7253a0e…0041sent to0x1f3d3a7a…0591·#24,650,819·0x384a6a9c…547f09
{"description":"## Summary\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 [DONE]\n- Install guard via `setGuard()` function on the Azorius module\n- Configure guard with security council multisig address (5-of-8 Safe)\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] Implement Security Council to Prevent Governance Attacks"}
0xf7253a0e…0041sent to0x1f3d3a7a…0591·#24,650,742·0x319473f4…5c133d
{"title":"[SECURITY] Implement Security Council to Prevent Governance Attacks","description":"## Summary Install 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. --- ## Motivation Our 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. A security council guard provides: - **Emergency veto capability** for governance attacks/malicious proposals - **Standard practice** in high-value DAOs (ENS, Arbitrum, Optimism) A 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. **This proposal establishes the security foundation that will allow safe disclosure, open discussions, and implementation of future protections.** --- ## Technical Implementation **Deploy and configure security measures:** - Deploy `SecurityCouncilAzorius` guard contract [DONE] - Install guard via `setGuard()` function on the Azorius module - Configure guard with security council multisig address (5-of-8 Safe) - Set timelock period (`timelockPeriod`) from **0 to 14,400 blocks** (approximately 2 days) **Transaction sequence (atomic execution):** 1. `Azorius.updateTimelockPeriod(14400)` — set 2-day timelock 2. `Azorius.setGuard(guardAddress)` — install security council guard --- ## Security Council Composition We propose an **8-member council** of trusted, active delegates: 1. **0xffFA76e332cA7afaae3931cb5d513B7fd681C4CF** - Kleros Labs 2. **0xe52C39327FF7576bAEc3DBFeF0787bd62dB6d726** - 5pence 3. **0xDffDb9BeeA2aB3151BcBcf37a01EE8726F22ed94** - d0z3y 4. **0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44** - Mikko Ohtamaa 5. **0x06c2c4dB3776D500636DE63e4F109386dCBa6Ae2** - Jacob Czepluch 6. **0x1F3D3A7A9c548bE39539b39D7400302753E20591** - blockful 7. **0x057928bc52bD08e4D7cE24bF47E01cE99E074048** - DAOplomats 8. **0xB6647e02AE6Dd74137cB80b1C24333852E4AF890** - Lanski --- ## Multisig Configuration - **Threshold:** 5-of-8 (balance of security and responsiveness) - **Implementation:** Safe Multisig - **Chain:** Ethereum mainnet (Shutter 0x36 operates on mainnet) - **Initial deployment:** 1-of-1 Safe (blockful placeholder), upgraded to 5-of-8 after confirming addresses and availability to participate. --- ## Veto Authority The security council can veto any proposal or individual transaction before execution if it: - Threatens treasury security - Contains malicious calldata - Is identified as spam or governance attack **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. **Veto mechanism:** The guard computes a transaction hash for each proposal action. If that hash is vetoed, the transaction reverts when Azorius attempts execution. --- ## Timeline - **Proposal posted:** Mar 13 - **Voting period:** 3 days (standard 0x36 period) - **Execution:** Mar 16 - **Full disclosure:** Post-mortem after execution. Details already on repo [blockful/shutter-security-council](https://github.com/blockful/shutter-security-council) --- ## Why This Sequence Standard responsible disclosure practice requires: 1. Put safeguard in place (this proposal) 2. Coordinate with DAO 3. **Implement fix** 4. **Disclose publicly only after fix is deployed** ## Long-Term Considerations This security council is an **emergency measure**. Post-mitigation, the DAO can: - Evaluate governance parameter improvements (proposal thresholds, voting delays, execution periods) - Consider path to remove or adjust security council as other governance parameters are hardened - Implement comprehensive governance upgrade to restore fuller decentralization with security **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.. ## Next Steps With this proposal in place, we can: 1. Safely disclose the full technical details of the vulnerability 2. Have open community discussion about long-term governance improvements 3. Implement additional protections through subsequent proposals ## Why Now **Governance vulnerabilities don't wait.** The economic incentive exists today. Every day without protection is a day of risk. We understand this creates permissioned execution. We're asking the community to adopt this **to prevent permanent loss.** ## Voting Instructions - **Vote YES** to approve emergency security council implementation - **Vote NO** if you believe the risk doesn't warrant this measure ## Links - **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). - **Security Council multisig:** [Safe](https://app.safe.global/transactions/history?safe=eth:0x3ea731dAF66D6A7980549f90152CD9A761B9c0C0) - **Security Council contract:** [Etherscan](https://etherscan.io/address/0xb04f553c482063a99b10c55033b56bd50b6b0334#code) ## Questions Happy 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. **Thank you for your attention to Shutter DAO's security and governance integrity.** "}
0x3b9f4762…2589sent to0x1f3d3a7a…0591·#23,948,257·0x31e7e742…d9d969
The discontinuation of Compound v2 is a reasonable and strategic decision, given that the legacy markets see little usage and the protocol is now fully focused on v3. That said, v2 can still represent a reputational risk to Compound in the event of a vulnerability, as illustrated by the Balancer v2 exploit. There are still tens of millions of dollars in assets remaining in Compound v2. For this reason, communication with users should also be carried out broadly across social media, to publicly reinforce the discontinuation of v2 — rather than relying solely on a banner on the Compound website. Clear and proactive communication with both the market and users is essential. Therefore, we voted FOR the proposal.
0x3b9f4762…2589sent to0x1f3d3a7a…0591·#23,927,673·0x1654afd3…3fc041
We view the delegation of tokens by Avantgarde to the Compound Foundation as positive. These $COMP tokens can be used to protect the DAO in the event of an attack or malicious proposal, increasing the voting power of the Compound Foundation’s wallet. For this reason, we voted FOR the proposal.
0x3b9f4762…2589sent to0x1f3d3a7a…0591·#23,927,601·0x301e5755…a6026c
Alongside the renewal of the Proposal Guardian, the Renewal of the Community Multisig is essential to maintaining Compound’s security. For this reason, we voted FOR the proposal.
0x3b9f4762…2589sent to0x1f3d3a7a…0591·#23,640,046·0x98fc3126…00ac4e
Excited to see some allocation on Morpho and also great to have TWAP functionality directly from the endowment smart contract.More usage of ENS names and interesting experiment with $ENS incentives. Looking forward to see the results and iterate.
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.
0xf7253a0e…0041sent to0x1f3d3a7a…0591·#22,069,699·0xb73f13cb…c78344
We vote FOR the proposal. The incentives requested in the proposal can (1) help the migration of liquidity from v3 to v4 and (2) bring more TVL/volume to Unichain. As described in the proposal, incentive programs are common in the ecosystem - and can be one-off solutions to grow new solutions. However, it is important that KPIs are managed. Tracking the efficiency of capital allocation in liquidity programs is key to not throwing money at the DAO with no return for it. If the KPIs are not met, the Gauntlet must draw up new plans to achieve the objectives stipulated in the proposal. If they don't succeed, the money should go back to the DAO. In addition, it's essential to think about the long-term strategy - mentioned by Gauntlet/UF in the proposal. We know how incentive programs can work for a short time - only as long as rewards are distributed to users. It is essential that capital allocation is done with this in mind, with a view to not repeating the same problems of other projects that have done the same in the market. We also advocate the creation of a proposal that encourages more Hooks to be created on Uniswap. However, it would be interesting to fund mainly those that bring some kind of return to the DAO.
0xf7253a0e…0041sent to0x1f3d3a7a…0591·#22,068,828·0xe74b7df8…cb3165
We vote FOR the Uniswap Unleashed proposal. The Uniswap Foundation's request for ~U$125M for Grants and Operations is relevant and will be important to (1) contribute to the development/growth of Hooks and (2) attract more projects/people to build on Uniswap/Unichain. We understand the competitiveness of the market, but we agree with the concern expressed by other delegates: it's a high amount and paid all at once. An update on the fulfillment of the KPIs proposed by Devin in the proposal is essential for us to understand the allocation of capital in this proposal. Just as we voted for the proposal on incentives for Uniswap v4/Unichain, we are concerned about how both products will benefit the DAO. We understand that the success of both is indirectly beneficial to the Uniswap DAO, but (1) there is still no direct revenue sharing mechanism and (2) most Hooks do not choose to enable charging a fee on applications created with the product. Therefore, we would like UF to continue the good work, funding good projects and supporting the evolution of Uniswap - as a product and DAO - but also to carry out actions with the organization in mind, holders of $UNI, its delegates and the entire body of people working on Uniswap governance. Good synergy between UF, Uniswap Labs and the DAO is essential. All parties need to be heard and have power to make decisions.
0x76a6d08b…bbb8sent to0x1f3d3a7a…0591·#21,467,854·0xe000367b…f27861
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.