Closed herbig closed 1 year ago
just one spec needs updated:
Does this break anything down the workflow? How do we handle queue and execute on the frontend? would these still go as normal?
It shouldn't break anything in any of the flows, and the current front end wouldn't need to adjust in any way, since that requires at least one transaction in the proposal screen.
Queue / Execute on the frontend would work as normal for Proposals with transactions, but if you get the state of one without transactions that has already passed its vote period (and passed) the state would just say executed.
In
submitProposal
, if TX count is 0, does it need to settxHashes
,timelockPeriod
, orexecutionPeriod
? Curious if it saves gas to skip setting those.
You wouldn't need to set these, but I didn't want to get too into building a lot of logic around not having transactions, just make it possible not to have them.
But I could see not setting them at all yeah
Description
Multiple beta feedback users have mentioned the desire to conduct votes on chain for things that do not necessarily involve transactions.
This change allows us to build such a feature into the frontend if we decide to do so, without adding any additional complexity to the contracts.