Shutter DAO 0x36 Transition Proposal by Cactus (fka Tally)
This proposal was prepared in July 2026 by ScopeLift, the team which operates Cactus, the governance platform formerly known as Tally, for stakeholders of the Shutter DAO 0x36. It details a plan to migrate the Shutter DAO 0x36 to a set of modern governance contracts built on the standard OpenZeppelin Governor.
Migrating governance contracts is a technically challenging process with non-trivial risk. Millions of dollars are at risk for the DAO if the process is botched. The stakes demand a process where no step is irreversible until the new system has proven itself. That is exactly how our plan is structured, based on our experience executing similar critical updates for other major DAOs.
Our team is uniquely qualified to execute the migration safely and support the DAO’s need for a governance frontend on an ongoing basis. Our proposal bundles these services as follows:
High Level Description
The new OZ Governor will be deployed with a configuration that aligns its functionality with the DAO’s existing governance mechanism. This includes:
- 10M SHU proposal threshold (up from 1M as requested)
- 1 day (or longer) voting delay (new feature & best practice for preventing governance attacks)
- 3 day voting period
- Quorum of 3% of supply
- Simple majority voting (with voting weight snapshot at vote-start)
- Guardian role with proposal cancellation rights (set to the same council multisig)
- A delay of 2 days after a proposal is passed until execution, enforced by a Timelock contract
The migration plan does not require a change to the token, or redelegation by token holders. The SHU token supports ERC20Votes, which is compatible with the OZ Governor, and can thus be left as-is.
The new OZ Governor, plus the existing token, will be fully supported in the Cactus) (formerly Tally) frontend.
The steps for the migration are as follows:
- Build, test, and deploy the new Governor contracts.
- Configure and index the existing token and new Governor in Cactus.
- Submit, pass, and execute a proposal on the existing governance system that adds the new governance Timelock (the DAO’s new onchain identity) as a module on the Safe, allowing the new governance system to control the Safe.
- Submit, pass, and execute a proposal on the new governance system that transfers a de minimis amount of treasury funds from the existing Safe to the new governance treasury. (Note that this step is technically optional, but highly recommended, as it proves the new system end-to-end while the stakes are small).
- Submit, pass, and execute an additional proposal on the new governance system that transfers all remaining funds to the new governance Timelock, assigns the Timelock to all roles, and disables the Azorius module on the Safe.
After this process is complete, the new governance contracts will have full control over funds and onchain roles. The new governance contracts will also have control over the old governance Safe, allowing it to perform actions from that address if needed for some reason in the future (e.g. an airdrop to that address, a missed role that needs to be transferred, etc.).
Note that the DAO’s Snapshot SubDAO (the separate Safe that executes Snapshot votes via reality.eth) is unaffected by this migration. It operates independently of the old governance system, and the main DAO’s clawback authority over it simply transfers to the new Timelock as one of the roles in step 5.
Finally, if desired, ScopeLift will write a script to mine an address for the new Governor and/or Timelock, allowing the new governance addresses to retain the nominative 0x36 prefix.
Options for Proposer Whitelist (Hats replacement)
The existing governance system uses a Hats role to whitelist addresses that can make proposals even without having the requisite 1M SHU delegation. Stakeholders have requested an increase of the proposal threshold to 10M SHU, a move which would restrict proposers (outside the whitelist) to only 6 addresses, some of which seem inactive.
This feature does not have a direct analog in the existing OZ Governor contracts and available extensions. To replace this feature, we suggest the DAO take one of two paths:
Option 1: Custom Proposer Whitelist Extension
ScopeLift will develop a custom extension to the Governor which will allow Governance itself to whitelist addresses to propose. Such an extension would be small (perhaps 2 dozen lines or less) and quick to develop.
Given the sensitive, high stakes nature of the code, we strongly recommend an audit on any new code used in a production governance system. This is the primary downside for taking the custom extension approach.
If the DAO pursues this option, ScopeLift has several trusted third party security partners who can perform this audit in a timely fashion at a slight discount to market rates. We are also happy to collaborate with any auditors with whom the DAO has an existing relationship.
Option 2: Franchiser Deployment
The Franchiser contracts provide DAOs an audited, battle-tested way to delegate their treasury tokens to aligned actors. It has been used successfully by large DAOs, like Uniswap, amongst others. ScopeLift can deploy and configure a set of Franchiser contracts for the DAO. The DAO can then vote to delegate sufficient tokens to stakeholders to allow them to propose.
It’s important to note that any delegate that receives such a delegation would be able to propose AND vote with the voting weight assigned to them, which makes this option materially different from a simple “whitelist to propose” mechanic.
Because the Franchiser contracts rely on tokens held by the new governance Timelock, delegation from the treasury must be sequenced as an additional step after the proposal to take over the treasury passes. This means the DAO must make sure it has a stakeholder, amongst the six addresses with more than 10M SHU, available to make the proposal. Alternatively, the new contracts can launch with a configuration below the 10M SHU threshold, and raise it to 10M with the same proposal that enables the treasury delegations.
Note that Franchiser delegations can be configured to expire after a certain amount of time, if not renewed by the DAO, and can be revoked by the DAO before expiry at any time.
Development Process
ScopeLift will guide the DAO through the assembly, testing, and migration of the DAO from its existing Safe + Azorius configuration to a modern Governance system. Our services are comprehensive, and include:
- Assembly and deployment of the Governor system from the OZ Governor extensions
- Authorship of the deployment scripts and proposal scripts that will be used in the migration process
- Authorship of extensive integration tests, which fork the live state of the mainnet and simulate every step of the process described above. This step is absolutely critical to ensuring this sensitive process is carried out correctly, and ScopeLift has considerable experience writing these kinds of tests.
- Activation and configuration of the DAO’s new Cactus portal page
- Collaboration with DAO stakeholders through each step of the onchain proposals submission and execution
- Ongoing clientside support for the DAO’s Cactus portal page
Why the OpenZeppelin Governor
The OpenZeppelin Governor is a battle-tested governance framework used by most of the largest DAOs in the space. It is derived from the industry pioneering Compound Governor contracts, which were first deployed in 2020. Collectively, hundreds of billions of dollars across the ecosystem are secured by the OZ Governor family of contracts. DAOs like Uniswap, Compound, Arbitrum, Optimism, ZKsync, Gitcoin and many more use variants of the Governor.
Equally as important, the OpenZeppelin Governor contracts serve as a de facto standard, on top of which much tooling has been built. Several rich, featureful clients exist, including open source options. The most widely used client is Cactus (formerly Tally), which is operated by ScopeLift as of April 2026. While we hope Shutter DAO will choose Cactus as its primary client, there is no lock-in. The DAO is free to pursue alternative vendors in the future, or in parallel for redundancy. Choosing the Governor ensures the DAO will be able to avoid another painful, sensitive migration process again in the future.
Why ScopeLift
ScopeLift is a full-stack web3 engineering partner. We’ve been shipping high-stakes smart contracts, DApps and core infrastructure across the EVM since 2016.
We also operate the Cactus governance platform (formerly Tally) and have deep experience in the challenges that come with building robust web3 governance mechanisms. ScopeLift has developed critical smart contracts for the Uniswap Foundation, Tally, ZKsync, Project Eleven, Wormhole, Endaoment, Obol, Railgun and more. Many of these projects had a primary focus on helping DAOs improve their onchain governance systems.
Here are a few of those highlights:
- UniStaker: a staking primitive that encourages governance participation by allowing token holders to earn reward distributions as long as they are actively engaged in governance decisions. Originally designed for Uniswap, the UniStaker project was later generalized to create Staker, which made it straightforward to be adopted by other DAOs. This staking system has been used by ZKsync, Obol, and Rarible.
- Flexible Voting: extended OpenZeppelin’s DAO Governor to enable novel voting patterns, e.g. splitting voting weights across options for a given proposal, and use cases, e.g. shielded voting, custodial voting, subsidized offchain voting, etc. The extension has been added to the OZ standard governance library and is used by many DAOs, including Compound, ZKSync, Wormhole, Gitcoin, PoolTogether, Frax, Obol, Rarible, and AGLD.
- Seatbelt: built an automated governance proposal simulator which generates human-readable, plain language reports compatible with Governor Bravo and OZ Governors for easy pre-screening before execution. Used on Uniswap, Compound, and ENS, and feeds data to Cactus and Agora governance clients for their safety check features.
- ZKsync: developed the ZK token and governance contracts for the GovOps, Token and Protocol governors, as well as governance “RSS feeds.” Also developed the DAO’s capped minter processes, used to distribute newly minted tokens as part of the Token Program Proposal processes. Also developed and deployed the ZKStaker governance staking contracts, and the recently announced Fee Flow contracts for returning value to the DAO.
- Wormhole: developed MultiGov, a cross-chain governance system that leverages Wormhole’s interoperability infrastructure to extend DAO governance features and enable seamless voting and proposal mechanisms across multiple chains.
- Compound, Gitcoin, Radworks and PoolTogether: performed sensitive Governor updates, similar in nature to this proposed migration, without disruption.
Our nimble group of EVM experts has fine-tuned its development process over the years, following the best practices honed working with dozens of elite dev teams. By approaching each project in carefully designed phases, we can be flexible and adaptable to changing needs, while remaining thorough and uncompromising.
We’re also the creators and maintainers of Umbra (umbra.cash), the first implementation of stealth addresses on Ethereum, and contributors to Ethereum’s stealth address ERC standards.
Technical Deep Dive
Contract Architecture
The new system consists of two contracts, assembled entirely from audited, unmodified OpenZeppelin components pinned to the latest release, v5.6.1 (plus the optional proposer whitelist extension, if the DAO selects Option 1 above):
The Governor is composed from the OZ Governor core plus the following standard extensions:
- GovernorSettings — Makes the voting delay, voting period, and proposal threshold adjustable by governance itself, so future parameter changes are ordinary proposals rather than migrations.
- GovernorVotes — Reads voting power directly from the existing SHU token’s ERC20Votes checkpoints. This is why no token change or redelegation is needed.
- GovernorVotesQuorumFraction — Expresses quorum as a percentage of total token supply, exactly as the current system does.
- GovernorCountingFractional — Implements For/Against/Abstain voting. Quorum counts For + Abstain votes and passage requires For > Against — both identical to the current system’s counting rules (we verified this equivalence at the source level). Beyond the standard behavior, this extension enables richer voting integrations in the future, such as delegates voting on behalf of constituencies with divided opinions, votes cast from other domains, or privacy-preserving voting schemes that tally encrypted ballots, including schemes like Shutter’s own shielded voting applied to onchain governance.
- GovernorTimelockControl — Routes all passed proposals through the Timelock, enforcing the execution delay.
- GovernorProposalGuardian — Grants a designated guardian address the power to cancel proposals up to the moment of execution. The guardian will be set to the DAO’s existing security council multisig, preserving the council’s veto power with the same trust model as today: the council can block, governance can replace the guardian, and neither gains any power it doesn’t already hold in the current system.
The Timelock is an unmodified OZ TimelockController. It holds the treasury and all onchain roles, and becomes the DAO’s onchain identity. Proposal execution after the delay is permissionless (as it is today). The Timelock can receive NFTs (including the DAO’s Hats Protocol top hat, which is an ERC-1155).
Two behaviors improve on the current system without any configuration effort. First, votes can be cast by signature, meaning delegates can vote gaslessly through supporting frontends — under the current system, every vote is an onchain transaction paid by the voter. Second, passed proposals never expire — under the current system, a passed proposal must be executed within a ~3 day window or it dies (this has killed four passed proposals to date, requiring full re-votes).
Configuration Parameters
| Parameter |
New system |
Current system |
| Voting delay |
7200 blocks (~1 day)* |
none — voting opens at submission |
| Voting period |
21600 blocks (~3 days) |
21600 blocks (~3 days) |
| Proposal threshold |
10M SHU (per stakeholder request) |
1M SHU, or a whitelisted Hats role |
| Quorum |
3% of total supply (For + Abstain) |
3% of total supply (Yes + Abstain) |
| Passage criterion |
For > Against |
Yes > 50% of Yes + No (equivalent) |
| Execution delay |
2 days (Timelock) |
14400 blocks (~2 days, in Azorius) |
| Veto / cancellation |
Guardian = council Safe (0x3ea731dAF66D6A7980549f90152CD9A761B9c0C0) |
Guard owned by the same council Safe |
| Execution window |
Unlimited (no expiry) |
21600 blocks, then proposal expires |
| Vote by signature |
Yes (gasless voting) |
No |
* Proposed default. As noted in the High Level Description, stakeholders may opt for a longer voting delay; the final value will be confirmed before deployment (and remains adjustable by governance afterward via GovernorSettings).
Roles and Funds to Be Transferred
Treasury balances as of July 7, 2026 (block 25,482,761); exact amounts will be re-inventoried immediately before the final proposal is assembled. Junk/spam airdrop tokens are deliberately excluded — any asset missed can always be recovered later through the Safe module retained in step 5.
| Asset |
Amount |
| SHU |
550,737,117 |
| USDC |
297,857 |
| sUSDS |
596,037 |
| SPARK |
50,018,481 |
| ETH / WETH |
~2.0 / ~2.0 |
| Uniswap V2 USDC/SHU LP tokens |
99.9% of pool (≈42.65M SHU + ≈99k USDC) |
| Role |
Contract |
Action |
| Keypers registry owner |
0xf88823c6A253564Aa7717b12b86F6FEE259d95b7 |
transferOwnership → Timelock |
| Keyper config list owner |
0x5fa005e8a4d45695f7E9EB81cf4f7d0FDbcAE0E2 |
transferOwnership → Timelock |
| Collator registry owner |
0x159481E8A78A61a47815b95DEaFc60023Fc4f829 |
transferOwnership → Timelock |
| Collator config list owner |
0x93a2b17a942D57f8e3E8E6338615a8657691e02C |
transferOwnership → Timelock |
| SHU staking owner |
0xc643fd3107799D5EEf411E936323A3975bc105aA |
transferOwnership → Timelock |
| SHU staking upgrade admin (ProxyAdmin) |
0x02acEEdC8Da5145E2F7D9E1614b533300Df844d9 |
transferOwnership → Timelock |
| Staking rewards distributor owner |
0xFAd7db6b2EBE2cB586dD08DC6A9D07d4a0FBEf49 |
transferOwnership → Timelock |
| SubDAO parent-control module (FractalModule) owner |
0xbc138DEf32E8552Ec6fA742c9A846e5EA84a6937 |
transferOwnership → Timelock |
| Hats Protocol top hat (proposer-role admin) |
Hats 0x3bc1A0Ad72417f2d411118085256fC53CBdDd137, tree #64 |
ERC-1155 transfer → Timelock |
| SHU token owner |
0xe485E2f1bab389C08721B291f6b59780feC83Fd7 |
transferOwnership → Timelock (ceremonial: no pause or mint powers remain in the token) |
| DAO Safe module configuration |
0x36bD3044ab68f600f6d3e081056F34f2a58432c4 |
Enable Timelock module (step 3); disable Azorius module (step 5) |
Notably absent from this list: the vesting system (1,000+ vesting contracts holding ~195M SHU) requires no action whatsoever. Vesting contracts hold SHU directly and their delegations live in the token itself, so beneficiaries’ voting power and claim rights carry over untouched. The same is true of every existing token delegation.
Testing and Simulation
Every onchain action in this plan will be exercised, end to end, before any of it touches mainnet:
- We write fork-based integration tests that run against a fork of live mainnet state — the real Safe, the real Azorius module, the real token balances and role assignments.
- These tests execute the actual deployment scripts and the actual proposal payloads — not simplified stand-ins. The calldata submitted on mainnet is byte-for-byte the calldata that passed the simulation.
- The full sequence is simulated: deployment, the Azorius proposal that enables the Timelock module (including its vote, timelock, and execution), the de minimis verification transfer, and the final omnibus proposal — with assertions on every post-state: balances moved, ownerships transferred, module configuration correct, and the new Governor able to operate the Safe.
- The simulation results are reproducible and will be shared with stakeholders and delegates ahead of each vote, so anyone can verify what a proposal will do before voting on it.
This testing methodology is how ScopeLift has delivered comparable governance deployments and migrations, and it is the single most important control against the risks described at the top of this document.
Resourcing & Costs
We are offering the combined at a substantially discounted bundled rate, reflecting our interest in supporting the DAO through its current transition.
| Sub-project |
Standard Price |
| Governance migration engineering |
$50,000 |
| Cactus Pro Platform (1 Year) |
$50,000 |
| Sub-Total |
$100,000 |
| Cactus Pro Platform 50% Bundle Discount |
-$25,000 |
| Bundled engagement price |
$75,000 |
The governance migrations will be led by one of ScopeLift’s Lead Engineers, supported by ScopeLift’s full senior engineering team. We will target completion of all smart contract work in ~3 weeks of engagement start, with the goal of executing the various onchain proposals required for the upgrade in August.
Payment terms can be structured as a single payment or in milestones aligned with deliverables.
Thank you for your time and we’re happy to answer any questions.
