0xf725…0041

All memos sent from and to 0xf725…0041.

{"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)"}
{"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"}
{"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.** "}
0x36852fc62216c6dd169552f4d3a786ecdb0ddf3fdf61b9f9f8581383c587386bbafkreifuxwyvopfeiivfmwnp36wtl47kc336kchraqrsnat2vdmveneslibafkreigj53hwheyk3yvaa36k5gekg6rltw5zg2zgtd6g7rshxp27gc63du
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.
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.
{"title":"Configure SHU Staking and Reward Paramet","description":"Summary\nThis proposal sets the initial configuration in the staking contracts for Shutter Keyper and Delegated Staking. It comprises 26 transactions and is meant as a provisional starting configuration, especially designed for testing. After this initial setup configuration, the DAO can and should tweak individual parameters. Real staking can only start once the DAO sends SHU tokens to the contract, which is not part of this proposal. \nPreviously, Shutter DAO 0x36 voted for a total reward rate of 8 SHU per minute (i.e. ~0.133 SHU per second), see https://snapshot.org/#/shutterdao0x36.eth/proposal/0x689f926b783fedae3c490d424caaa7ddee1b4d61963678a7ed91875fdb8e1aae. However, how those rewards would be split between Keypers and Delegators was not strictly defined. Below, we detail a provisional split based on assumptions about the amount of SHU staked by Keypers and by Delegators. We then provide the transactions needed to configure the reward distributor and register the Keypers, thus completing the configuration setup for SHU staking.\nBackground\nTotal Reward Rate: 0.133 SHU / second (as per the economic proposal that roughly equates to 8 SHU / minute).\nUndefined Split: The original proposal set the total reward rate but did not specify how it would be allocated between Keyper staking rewards and Delegator staking rewards.\nAssumptions:\nKeyper Staking: 2.3M SHU total staked by Keypers (23 Keypers × 100,000 SHU each).\nDelegator Staking: 70M SHU total staked by Delegators (~7% of fully diluted supply of 1 billion).\nGiven these assumptions, the ratio of Keyper Stake to Delegator Stake is:\n Keyper Share = 2,300,000 / (2,300,000 + 70,000,000) ≈ 0.0316 (3.16%)\n Delegator Share = 70,000,000 / (2,300,000 + 70,000,000) ≈ 0.9684 (96.84%)\nTherefore, out of the total reward rate of 0.133 SHU/second:\nKeypers receive:\n 0.133 × 0.0316 = 0.0042 SHU/second\n (i.e., 4,200,000,000,000,000 wei/second)\nDelegators receive:\n 0.133 × 0.9684 = 0.1288 SHU/second\n (i.e., 128,800,000,000,000,000 wei/second)\nNote: If actual participation differs from the assumptions, governance can adjust the split in the future.\n\nRationale & Next Steps\nThese transactions finalize the configuration of Staking V1 by:\nAssigning the Keyper and Delegator reward rates.\nRegistering the Keypers.\nEstablishing the official SHU token address to distribute rewards.\nThe chosen split (≈3% Keypers, ≈97% Delegators) is an initial assumption. The DAO retains the right to revisit and update this ratio if Keyper or Delegator participation significantly diverges from the assumed 2.3M vs. 70M SHU staking amounts.\nAs a next step, and after some testing of the staking with these parameters, the DAO will need to send 10M SHU to the staking contract.\nOnce executed, Keypers and Delegators can begin staking, and rewards will accrue at the configured rates.\n\nTransactions\nBelow are the calls required to finalize the reward distribution and enable SHU staking for both Keypers and Delegators.\n\nTarget\nFunction\nParameter Types\nParameter Inputs\nTransaction Value\n0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49\nsetRewardConfiguration\naddress, uint256\n0xc643FD3107799d5eEF411E936323a3975BC105aa, 4200000000000000\n0\n0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49\nsetRewardConfiguration\naddress, uint256\n0xf0DD9e28577d7Ef943d574af35F1AA1C0D6446A7, 128800000000000000\n0\n0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49\nsetRewardToken\naddress\n0xe485E2f1bab389C08721B291f6b59780feC83Fd7\n0\n\n\n\nAdd keypers\n\nAs per: \n\nTarget\nFunction\nParameter Types\nParameter Inputs\nTransaction Value\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x1c0a6fDd52A0c3F18cd6640695884e6248a13533, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x23d33956940083e0E92Dd608D6E576AfbEcc83a9, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x322F63e33B35CD227a51ae2B8b7Ef9EB8Ca8A238, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x3cA93C6c6E3081B26eCA2af4ec2E50d1BA975aE4, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x52e94E093a162F1D3D5481828cfaB3807Ea32b3A, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x618509C70Bd8b97b78B43c6AF081a55f7225901f, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x7238E49003771F9A1bE44585483979c69B6b0F5c, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x772213aaD4c6B37d2cc0Fa3B74F9ace5a028B8C8, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x90A09a9797A04CA679D8F8A6748f728D8f49F34B, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0xcB43AEAA8c029Da18A499dC684FdD250ab3FCd13, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0xE1A425b2726D92Bc5178e7F5Ed30256481F5337f, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0xf8A17443c1e98535aBe4D6D9Fdb9C99E8D36D87a, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0xfc7d75e4bb6D18591cDc1E766CE7cF231bc08fBc, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x0b4c93ffF2273c67533B861A3314D7339331605a, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x0c8f3E3912F35a59ffddc9Ff1ABB8FafC89b29de, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x48A0e1789C82084aE28c179bd5742454f8CD4ed6, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x5604cdde0626872514b48A336848Fc724fd60810, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x79Bc5989e6814e3e180938eeC854e91Cec178693, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x7Ca18A55b64c1509d34e964a9e323a6c71e905a2, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x99c5fB73f496110456aA8E80aE03C2D7548769c7, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0xcc7cd01106951B4809e640873C15363609d2C58e, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0xe03472CCb8e011b7Dfb3343837D75Bf6C9c3324C, true\n0\n0xc643FD3107799d5eEF411E936323a3975BC105aa\nsetKeyper\naddress, bool\n0x39092B27c6c4b68b240eE330Eb7356b3B7348328, true\n0\n\n\n\n","documentationUrl":"https://snapshot.org/#/shutterdao0x36.eth/proposal/0x689f926b783fedae3c490d424caaa7ddee1b4d61963678a7ed91875fdb8e1aae"}
{"title":"Configure SHU Staking and Reward Paramet","description":"\n\n### Summary\n\nThis proposal executes the final step to activate staking rewards for Shutter DAO 0x36. Previously, the DAO voted for a total reward rate of 8 SHU per minute (i.e. ~0.133 SHU per second), see https://snapshot.org/#/shutterdao0x36.eth/proposal/0x689f926b783fedae3c490d424caaa7ddee1b4d61963678a7ed91875fdb8e1aae . \n\nHowever, how those rewards would be split between Keypers and Delegators was not strictly defined. \n\nBelow, we detail a provisional split based on assumptions about the amount of SHU staked by Keypers and by Delegators. \n\nWe then provide the transactions needed to configure the reward distributor and register the Keypers, thus completing the configuration setup for SHU staking.\n\n### Background\n\n* Total Reward Rate: 0.133 SHU / second (as per the economic proposal that roughly equates to 8 SHU / minute).\n* Undefined Split: The original proposal set the total reward rate but did not specify how it would be allocated between Keyper staking rewards and Delegator staking rewards.\n* Assumptions:\n * Keyper Staking: 2.3M SHU total staked by Keypers (23 Keypers × 100,000 SHU each).\n * Delegator Staking: 70M SHU total staked by Delegators (~7% of fully diluted supply of 1 billion).\n\nGiven these assumptions, the ratio of Keyper Stake to Delegator Stake is:\n\nKeyper Share = 2,300,000 / (2,300,000 + 70,000,000) ≈ 0.0316 (3.16%)\n\nDelegator Share = 70,000,000 / (2,300,000 + 70,000,000) ≈ 0.9684 (96.84%)\n\nTherefore, out of the total reward rate of 0.133 SHU/second:\n\n* Keypers receive:\n0.133 × 0.0316 = 0.0042 SHU/second\n(i.e., 4,200,000,000,000,000 wei/second)\n* Delegators receive:\n0.133 × 0.9684 = 0.1288 SHU/second\n(i.e., 128,800,000,000,000,000 wei/second)\n\nNote: If actual participation differs from the assumptions, governance can adjust the split in the future.\n\n###\nRationale & Next Steps\n\n* These transactions finalize the configuration of Staking V1 by:\n 1. Assigning the Keyper and Delegator reward rates.\n 2. Registering the Keypers.\n 3. Establishing the official SHU token address to distribute rewards.\n* The chosen split (≈3% Keypers, ≈97% Delegators) is an initial assumption. The DAO retains the right to revisit and update this ratio if Keyper or Delegator participation significantly diverges from the assumed 2.3M vs. 70M SHU staking amounts.\n* As a next step, and after some testing of the staking with these parameters, the DAO will need to send 10M SHU to the staking contract.\n* Once executed, Keypers and Delegators can begin staking, and rewards will accrue at the configured rates.\n\nTransactions\n\nBelow are the calls required to finalize the reward distribution and enable SHU staking for both Keypers and Delegators.\n\n|Target|Function|Parameter Types|Parameter Inputs|Transaction Value|\n| --- | --- | --- | --- | --- |\n|0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49|setRewardConfiguration|address, uint256|0xc643FD3107799d5eEF411E936323a3975BC105aa, 4200000000000000|0|\n|0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49|setRewardConfiguration|address, uint256|0xf0DD9e28577d7Ef943d574af35F1AA1C0D6446A7, 128800000000000000|0|\n|0xfad7db6b2ebe2cb586dd08dc6a9d07d4a0fbef49|setRewardToken|address|0xe485E2f1bab389C08721B291f6b59780feC83Fd7|0|\n\n## Add keypers\n\nAs per:\n\n|Target|Function|Parameter Types|Parameter Inputs|Transaction Value|\n| --- | --- | --- | --- | --- |\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x1c0a6fDd52A0c3F18cd6640695884e6248a13533, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x23d33956940083e0E92Dd608D6E576AfbEcc83a9, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x322F63e33B35CD227a51ae2B8b7Ef9EB8Ca8A238, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x3cA93C6c6E3081B26eCA2af4ec2E50d1BA975aE4, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x52e94E093a162F1D3D5481828cfaB3807Ea32b3A, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x618509C70Bd8b97b78B43c6AF081a55f7225901f, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x7238E49003771F9A1bE44585483979c69B6b0F5c, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x772213aaD4c6B37d2cc0Fa3B74F9ace5a028B8C8, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x90A09a9797A04CA679D8F8A6748f728D8f49F34B, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0xcB43AEAA8c029Da18A499dC684FdD250ab3FCd13, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0xE1A425b2726D92Bc5178e7F5Ed30256481F5337f, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0xf8A17443c1e98535aBe4D6D9Fdb9C99E8D36D87a, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0xfc7d75e4bb6D18591cDc1E766CE7cF231bc08fBc, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x0b4c93ffF2273c67533B861A3314D7339331605a, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x0c8f3E3912F35a59ffddc9Ff1ABB8FafC89b29de, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x48A0e1789C82084aE28c179bd5742454f8CD4ed6, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x5604cdde0626872514b48A336848Fc724fd60810, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x79Bc5989e6814e3e180938eeC854e91Cec178693, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x7Ca18A55b64c1509d34e964a9e323a6c71e905a2, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x99c5fB73f496110456aA8E80aE03C2D7548769c7, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0xcc7cd01106951B4809e640873C15363609d2C58e, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0xe03472CCb8e011b7Dfb3343837D75Bf6C9c3324C, true|0|\n|0xc643FD3107799d5eEF411E936323a3975BC105aa|setKeyper|address, bool|0x39092B27c6c4b68b240eE330Eb7356b3B7348328, true|0|","documentationUrl":"https://snapshot.box/#/s:shutterdao0x36.eth/proposal/0x689f926b783fedae3c490d424caaa7ddee1b4d61963678a7ed91875fdb8e1aae"}
{"title":"Pay Blockful for Services Provided During August ","description":"Hey Shutter DAO Community!! \n\nWe are proposing to get paid for our second-month(August) [providing Development and technical support services](https://shutternetwork.discourse.group/t/blockful-tech-service-provider/448) in August. \n\nWe’ve held this proposal requesting the payment until all the deliveries from that were finalized, [as the Op Bridge had some issues and was reset](https://shutternetwork.discourse.group/t/proposal-to-deploy-a-dex-pool-on-a-low-cost-chain-part-3/370/3), which took us some more time to get it confirmed and prooved.\n\nBelow I'm sending August's overall cost and time consumption.\n\n| Forum thread | Task | Time | Cost |\n| --- | --- | --- | --- |\n| [Unclaimed Vesting token](https://shutternetwork.discourse.group/t/unclaimed-vest-administrative-tasks-for-shutter-dao-0x36-treasury/467/8) | [Craft Calldata](https://github.com/orgs/blockful-io/projects/9/views/2?pane=issue&itemId=72783370) | 12h | $1.020 |\n| [Deploy a DEX pool in a low-cost chain](https://shutternetwork.discourse.group/t/proposal-to-deploy-a-dex-pool-on-a-low-cost-chain-part-3/370/6) | [Deploy A Standard Token in Optimism](https://github.com/orgs/blockful-io/projects/9/views/2?pane=issue&itemId=68619754) | 16h | $1.360 |\n| [Deploy a DEX pool in a low-cost chain](https://shutternetwork.discourse.group/t/proposal-to-deploy-a-dex-pool-on-a-low-cost-chain-part-3/370/6) | [Make SHU Available in the Optimism Bridge UI](https://github.com/orgs/blockful-io/projects/9/views/2?pane=issue&itemId=68621249) | 8h | $680 |\n| | TOTAL | 36h | $3.060 |\n\nwallet: blockful.eth\n\nToken: USDGLO\n\nNetwork: Ethereum"}
{"title":"Proposal for Staking Mechanism's Indexing and Host","description":"## Proposal\n\nBlockful will build an indexer to provide a list of all Keypers in the Staking contract, host the backend necessary for that and the front-end for the community to access that service.\n\n## Grant Amount & Disbursement Schedule\n\n**One time payout of 1360 USDGLO:**\n\nIndexer development work - $1360\n\n- 12 development hours\n- 4 scoping and management hours\n- 16*85 = 1360\n\n**Monthly Payout of 250 USDGLO:**\n\nBackend hosting - $150/month\n\nFrontend hosting - $100/month\n\n**Possible additional costs:**\nIn case the DAO decides not to point a domain it owns to be used for the system, the cost of the new domain acquisition will be added to the one-time payout.\n\n## Motivation\n\nAs we are now finished with the Staking Mechanism - both contracts and front-end development - there are two issues to be faced on making that available for use after the audit is ready:\n\n- **Development of an indexer to make the Keypers list available**\n - As we scoped the initial proposal, we did not include the work of any backend, as the need was not clear at the time.\n - During the development of the project, the necessity of an indexer to keep track of all the Keypers added to the contract to allow the display of those in the front-end without an overhead of computation on each load-time of the interface became clear.\n - That need comes from the optimization of the contract sizes to respect EVM limitations, which moved us towards having the keypers tracked through a mapping structure instead of a list.\n - The indexer will query the events of adding and removing keypers in the contract, structures them as a list database and make it available for easy display on the frontend.\n - Blockful has done similar work before in our AI Delegates project as well as in an internal data project we are developing. We are confident in our capacity to deliver this in time for the front-end to be live as soon as the audits are ready.\n- **Hosting of the front-end and back-end**\n - In the original proposal to build the staking mechanism, the hosting of the front-end was not included, as the opinion was that the cost was not fit\n - At our call for alignment of next steps it was pointed by member of the community that it’d be preferable for the DAO if blockful would host it, and it should be brought as a separate proposal given the increased scope-\n - Since we now have clarity of the size and complexity of the front-end, we are able to adjust the costs, and reduce our initial offer of $1500 to $250, including the backend.\n - The work scope for this point is hosting and maintaining availability of the back-end indexer and the front-end interface.\n\n### Technology\n\nThe indexer will be built using Ponder and PostgresDB.\n\nThe front-end and back-end will be hosted with railway and made available through Vercel in a domain to be provided by the DAO or chosen by blockful with its costs added to this proposal one time payout\n\n## Roadmap\n\n### Team\n\n1 Project Manager - Zeugh\n\n1 Back-end Engineer - Leo\n\n1 Front-end Engineer - Franco\n\n### Technology\n\nThe indexer should be completed in 4 days time.\n\nThe hosting and making available of the front-end and back-end should be completed in 2 days after the indexer is ready.\n\n## Misc\n\nThe hosting of the service includes the costs of the system and our team support to keep the system available under normal conditions, mainly issues such as servers momentarily going down and needing to be reset, managing it’s billing, accounts and structure.\n\nAny additional work to change, upgrade, or update the system will be charged separately, allowing us to reduce the cost of the hosting in this proposal to our minimal viable offer.\n\n### Alternative Structure\n\nBlockful is o to change the proposal from monthly payment to a one time payout for the periods of 6 months or 12 months with the full cost of that period.\n\n### Reporting\n\nReporting will be done once the indexer is completed and at any time issues occur with the system's hosting.\n\n### Additional Costs\n\nAny extra hours needed beyond basic availability maintenance, such as system upgrades, will be charged at the same hourly rate as the service provider's proposal.\n\n### Discontinuation\n\nIn case of payment discontinuation, Blockful will give 28 days for a new proposal to be made and agreed upon between the parties, shutting down the system after that time in case none is presented.\n\nDiscontinuation from the DAO side will come in the form of notice to the Service Provider post on the forum and ending of the payments.\n\nDiscontinuation through Blockful’s side will come through formal notice on the forum and shutting down of the system 28 days after.\n\n\n## Transactions\nOne transaction to pay the initial cost and first month.\n\nThe discussion should continue in the forum to determine the best payment method for fixed monthly value on the following months.\n\n## Voting Options\n\nVote “Yes” to approve the one time payout and the monthly payment\n\nOR\n\nVote “No” to refuse the proposal\n\nOR\n\nVote “Abstain” if you do not have an opinion but want to help the vote reach quorum\n\n## License\n\nCC0: This work is marked with [CC0 1.0 1](https://creativecommons.org/publicdomain/zero/1.0/) as dedicated to the public domain."}
{"title":"Pay Blockful: Staking and July Tech Services","description":"This proposal has been posted, open for discussion and updated at: https://shutternetwork.discourse.group/t/execute-payments-to-blockful-for-staking-and-service-provider/474\n\nBlockful has finished its first month as [Tech Service Provider](https://shutternetwork.discourse.group/t/blockful-tech-service-provider/448) in July and has finished development over [the staking mechanism](https://shutternetwork.discourse.group/t/development-staking-and-delegate-mechanism-blockful/418).\n\nWe are combining the different payments in a single proposal to make the approval process less demanding on governance. As it's all based on pre-approved scopes, this should not be an issue, but we are ready to split them into separate proposals if necessary.\n\n[**Deploying A SHU/USDC Pool in Swapr v3 on Gnosis Chain**](https://shutternetwork.discourse.group/t/final-proposal-to-deploy-a-shu-usdc-pool-in-swapr-v3-on-gnosis-chain/441/6)\n\n| Scope | Estimated Hours | Cost | Status |\n| --- | --- | --- | --- |\n| https://github.com/orgs/blockful-io/projects/9/views/2?pane=issue&itemId=68622212 | 14h | $ 1,190.00 | Done |\n| https://github.com/blockful-io/shutter-bridge/issues/2 | 14h | $ 1,190.00 | Done |\n| https://github.com/blockful-io/shutter-bridge/issues/3 | 8h | $ 680.00 | Done |\n| Total | 36h | $ 3,060.00 | |\n\n[**Staking and Delegate Mechanism - Blockful**](https://shutternetwork.discourse.group/t/development-staking-and-delegate-mechanism-blockful/418)\n\n| Feature | Time to Develop | Milestones | SHU Disbursement | USDC Disbursement | Status |\n| --- | --- | --- | --- | --- | --- |\n| i) Design | 1 week | | | | |\n| vi) Front-end | 3 weeks | | | | |\n| ii) Staking contract (L1 and L2) | 3 weeks | | | | |\n| iv) Testnets deployment and tests | 1 week | Milestone 1 | 15000 | 10000 | Done |\n| iii) Delegate contract (L1 and L2) | 3 weeks | | | | |\n| iv) Testnets deployment and tests | 1 week | Milestone 2 | 15000 | 10000 | Done |\n\nTotal disbursement for Blockful:\n\n| Description | Amount $ (USDGLO) | Amount SHU |\n| --- | --- | --- |\n| Service Providing | 3,060.00 | |\n| Staking/delegate Mechanism | 20,000.00 | 30,000 |\n| Total | 23,060.00 | 30,000 |\n\nPayment details:\n\nwallet: blockful.eth\n\nToken: USDGLO\n\nNetwork: Ethereum"}
I'm curious on this. I believe for a good time something similar should exist but never had the energy to move towards it. LFG https://jbm.infura-ipfs.io/ipfs/QmWAXVsg3mQewPUKcAu2nhqSdmEwbMmKEUWYg1tSYXDgnk
I just wanted the NFTs lol will schedule something once anything cool is on my mind :) https://jbx.mypinata.cloud/ipfs/QmbcYLrzsR7XNfW5c4V5tXuXbBhnzzW3q26cEUH7N7NsqX https://jbx.mypinata.cloud/ipfs/QmNPAAFRTTb2Ji7N4KPfRkAAzm7SsxdkQR4CN9di4quhoz
1-50 of 72