After integrating OpenGov to both Moonriver avd Moonbeam, we are considering an innovative enhancement to the OpenGov process – the introduction of collaborative decision deposits. This proposed feature aims to enable proposers to pool resources with fellow token holders, fostering enhanced collaboration and facilitating well-informed decisions within the governance framework.
Pros of Collaborative Decision Deposits:
Inclusivity: This feature promotes broader participation by reducing the financial barrier for proposers, making governance more accessible to a diverse range of community members.
Shared Responsibility: Collaborative deposits encourage shared ownership of proposals, aligning interests and strengthening the commitment of proposers and participants.
Community Cohesion: By fostering collaboration among token holders, this feature can enhance community cohesion and engagement, creating a stronger and more interconnected ecosystem.
We invite you to share your thoughts on this proposed enhancement.
Pooling and posting of decision deposits should happen at the proposal stage. Attention seeking referenda skip the proposal stage when they have no chance of getting the decision deposit. This is especially needed for the referendum killer (50,000 dot decision deposit) and referendum canceller(10,000 dot decision deposit). These calls are important for keeping the tracks clear of nuisance and/or fraud referenda but also must be invoked cautiously because the a) decision deposit is at risk of confiscation and b) we don’t want to interfere with legitimate on-chain busyness. 500 accounts posting 100 dots would demonstrate that there is community support for a killer call (ie. force transfer the killed referendas decision deposit to treasury).
Most token holders aren’t governance goonies that poor hours a day into reviewing referenda. It would be nice to be able keep the tracks clear so that people with limited time can use their time most effectively by only having to reviewing legitimate referenda.
It’s worth noting that Substrate’s account abstraction is a useful lever here.
For the Moonbeam case specifically, I’d imagine that this is the exact use-case of smart contracts. A smart contract controls an account on the Moonbeam chain, and this smart contract can handle a collaborative decision deposit.
I’m not sure about the complexity of pooling decision deposits in the pallet itself, but it’d probably be better as a separate pallet as opposed to integrated into the main OpenGov pallet itself.