Good First Issues in Solidity

It is a know issue in Compound Governance that proposal queueing will fail if it contains 2 (or more) actions that have the same target, value, and calldata. While this can be circumvented by adding extra (useless) bytes at the end of the calldata to create unicity, it is possible to create such a proposal and not realised if will never be executable after the voting ends. We should modify the behavior of _propose in GovernorTimelockCompound to reject proposals that have duplicated actions

Question for research Should Compose Support an ERC-4626 Implementation? Before deciding whether to include an ERC-4626 implementation in Compose, we would like to conduct research on how ERC-4626 is actually used and extended in projects. Research Question How is ERC-4626 customized in the wild? Specifically: How do real-world projects extend ERC-4626 implementations? Do most vaults override core functions? Are teams typically inheriting from OpenZeppelin’s implementation or other contract lib? Is there meaningful value in providing a reusable facet version inside Compose? Context The development is currently blocked for ERC4626 (See related Issue & PR) The hesitation to include ERC-4626 in Compose is based on the following concerns: Many/most vaults will have custom versions of these standard functions, and so will not use provided version by Compose facets. This vault standard add some complexity with the muldiv function (that can be delayed if we don't include ERC-4626) This

#127 (comment)