In my mind I see 2 proposals. Not sure if this is even logical, but if there’s an addition of like to see, that’s your standard 7 day proposal. Then also gave have a way to file something under “urgent proposals” that maybe has a 1 day vote window (or enough time to let it be fair, whatever that means) so we can implement change quick if needed. It would be rough knowing we have our nose open to an attack of some kind while we vote for 7 days is my thinking. Idk how that could ever work other than 2 proposals one standard proposal and one urgent one?
Do we have it such in summary form in discord? I believe guys there will need it tho haha. Something concise I hope in lightpaper form we could present to the majority of doggos or doggos wannabes out there.
So much more to do! Gogo Tally
Reflecting on this idea a bit more. I think this belongs with the Organization & Governance Den. I’ve collected some interesting Postmortems from other DAOs:
- Postmortem: EP9 deployment - General Discussion - ENS DAO Governance Forum
- Maker MCD Ethereum System Liquidation report and Black Thursday Compensation Analysis - Governance - The Maker Forum
- BadgerDAO Exploit Technical Post Mortem
No need to read through them in detail. I’m just looking at their structure and elements that can be useful for pulling into our own process.
I get the intention and idea, but my main question is, how would you gate (who’s deciding) if something is urgent or not? Take into account that anyone that meets the criteria to create a proposal can do so.
The way I see it is that in case of critical cases the DAO must be able to act immediately with minimized publicity. Hence the ‘pause button’ feature and the emergency. This would allow the necessary fixes to be put in place with the time needed.
But I’ll also check if Governor Bravo has the feature of different vote flows
It is pretty cool. Looking forward to a new version of TallyDAO
I think doggo name is too similar to doggy, look how garbage doggy is now. I suggest changing the name of the token
Thanks! Clear, concise, competent!
Wow, the true DAO is coming
Can confirm Wish’s statement about duplicative efforts in BanklessDAO. There has to be a better way to improve intra-pack communication. Could be through liaison dogs or like Wish said with dogs that listen in on another group’s meetings and then report back to their pack.
complete and useful
wow its nice , the true DAO is coming
I enjoyed the Dao formation and the planning done
Is there any consideration given to the timing of the DAO launch as it relates to overall market sentiment etc.?
Finally got a chance to take part in a real DAO, it’s cool!
How will the DAO structure proposal prevent or mitigate hostile takeovers such that we’ve seen with the Beanstalk protocol, when a flashloan was used to buy a majority governance and manipulate certain governance proposals?
Hey, yeah so there are a couple of different ways we are looking at this!
1 - There is a time delay between a vote conclusion and its execution. In Governor Bravo by default it’s a 2 day delay (compound.finance/docs/governance), but this can be set in the contract deployment. Best practice is to have at least some delay to ensure time to review for safety. There is also a set voting period, (3 days in the default) though I’ll have to double check that proposals will stay in the full voting period even if execution criteria is met before moving to the timelock, as some DAOs do enable the shortened voting period. But another way is to simply vote down malicious proposals before they are able to pass - though that is obviously just basic DAO functionality.
2 - We also intend to have an emergency multisig with very targeted powers to cancel malicious proposals that make it through. We will be sharing more on the emergency multisig structure and powers before launch
3 - I don’t expect there to be any supply of the token available for flash loan attacks at least for a while after launch… There will be some contract level restrictions that I don’t believe we’ve talked much about yet, but will be obvious when the contracts are launched. So this is not a permanent safeguard, but will deal with it in the early days.
A quick review of the periods/delays set out in the proposal:
- ‘Vote delay’ - time between set-up of vote on-chain & voting start → 3 days
- ‘Voting period’ - the duration in which votes can be cast → 7 days
- ‘Time lock’ - a delay between vote close and execution for passed proposals → 3 days