RitzyDevBox

Yeah basically, the store proposal function is called twice when creating a bravo contract 1. The 5 parameter propose function calls the 4 parameter one. which results in 2 calls...

Wont this result in a different hash since the encoded calldata will be different? uint256 proposalId = hashProposal(targets, values, _encodeCalldata(signatures, calldatas), descriptionHash); If someone attempts to call Queue, or Execute...

@frangio cant this just be fixed by calling the super instead? function propose( address[] memory targets, uint256[] memory values, string[] memory signatures, bytes[] memory calldatas, string memory description ) public...

@frangio, Can you clarify a bit for me, I haven't played with Diamond pattern inheritance in over a decade. Won't this respect downstream overrides? its more of the upstream ones...

Yeah I know that would be a big breaking change. I have it working as you proposed currently. Openzepplin interfaces are widely used, and it would save a lot of...

The current governor is limited its tightly coupling the behavior to the proposals and does not allow dynamic options. There is a clear use case for the additional bytes parameter...

Thanks, Yeah I def can wait for 5.0, I have a lot of refactoring to do anyway. I originally duplicated the entire design. But after a few of our conversations...

@frangio do you guys have a roadmap or eta for 5.0 release? I finished all my smart contract coding, and I'm on to the front-end but once I have the...

The DDOS would be user specific, so only that particular user wouldn't be able to vote. Potentially this can be solved by setting a hard cap on the number of...

params would work however since voting would potentially be transition to tokenId, the interface for has voted should be updated with a `bytes calldata params` as well `function hasVoted(uint256 proposalId,...