We voted For: The split between v1 on Ethereum and v2 on RARI Chain has been a real source of confusion, and consolidating binding decisions back on Mainnet while keeping RARI Chain for ecosystem coordination and signaling is the cleanest way to resolve it. The proposed Governor and Timelock parameters are sensible defaults, and narrowing the Security Council to pause, operational reversal, and blocking harmful payloads keeps emergency powers scoped to where they belong. We also like the cohort-based delegate relaunch, since onboarding has been harder than it should be and a structured intake gives new delegates a real path in. Glad to see this published as a temperature check with the direction shaped by community feedback before the binding migration steps execute.
We voted Against: This is an unsolicited on-chain proposal with a blank title and description, no forum discussion, and no RFC or governance process behind it, whose single executable action transfers 500,000 RARI from the DAO to the proposer’s own wallet. The proposer submitted it with empty metadata and is voting it through with their own tokens, which is the profile of a treasury-drain attempt rather than a legitimate governance action. We voted Against and encourage other delegates to do the same, since executing an unexplained self-transfer that never passed through any part of Rari’s normal process would directly harm the DAO.
We voted For: This raises the quorum on the legacy RARI DAO V1 Governor from 15% to 20% of total voting power, a targeted parameter change that leaves the current and future canonical governance untouched. Strengthening the minimum participation on the V1 path is a sensible hardening as that legacy surface winds down, since a 15% floor is low enough for a single large position to clear on its own, and the move to 20% is a moderate step that raises the bar without setting an unnecessarily high threshold that could stall legitimate activity. We are comfortable supporting it, and appreciate that it is framed as reassessable rather than a permanent target if the voting-power distribution shifts.
We voted Against: The proposal’s two sentences say it grants full control of the DAO to Falcon, and the payload does exactly that. Its single action has the DAO’s UpgradeExecutor delegatecall a contract named Memory, deployed by the proposer’s own address, to write one storage slot, and that slot is the proposer’s entry in the executor’s ADMIN_ROLE, the role that decides who holds EXECUTOR_ROLE, so a Yes would let one address run arbitrary changes through the executor with no vote and no timelock. The voting power behind it is new: the proposer held no veRARI at the RRC-56 snapshot on August 27 and holds 132,576.29 at this one, about 66% of all voting power and more than three times the 40,154.55 quorum RRC-56 had just raised, and the proposal skipped the RRC and forum process entirely. Whatever case an activist investor wants to make for veRARI holders belongs in a proposal the DAO can evaluate, not in a transfer of admin rights to one wallet. We encourage delegates with V1 voting power to vote Against, and if it clears the vote, the 48-hour timelock is the window for the holders of the timelock’s cancel role to stop it, which we would support.
We voted For: With Impossible Finance now owning Rarible’s brand and platform, admin control over the protocol contracts on the 25 listed networks should sit with the team shipping fixes and upgrades rather than with a former CTO kept on as a courtesy holder, and the vote itself carries no executable actions and no treasury cost. We checked the main admin Safe (0x7350…53b7) on Base, Arbitrum and Polygon, and it is a 4-of-11 today rather than a single-signer setup, so the swap needs four signatures and the end state should leave the Impossible Finance multisig as the only owner, with all eleven current signers removed. Two asks before the transfers: please publish the receiving Impossible Finance addresses and their signing thresholds in the thread, since the DAO is approving a handover to addresses it has not yet seen, and give a date for moving the single-key EOA networks onto a multisig rather than leaving that as an open follow-up. Thanks to @yahordz for pulling the network list together and correcting the Telos address, and to @enacu for agreeing to carry out the handover.