Please use this thread to share the contracts or utilities that you'd most like to see added to OpenZeppelin Contracts.
Share one idea per answer and use the like button to vote for other suggestions!
An area we're actively looking into is Layer 2 and bridges, so if you have specific requests around this topic they're specially welcome!
Hi, how about disallowing sending token to its own contract address?
Many new users lost their funds due to they transferred wrongly.
Just like this one:
That has been discussed before, we don't want to add this check by default because we find it too opinionated, but it could be opt-in.
Okay, I see. Thanks for pointing out this.
Upgrades Plugins support for Foundry.
I've seen projects using a different way of designing Ownable contracts by embedding a new owner into the ownerable contract at deployment. The benefit is project owners can claim ownership at their discretion and don't need to worry about the credit risk of devs.
See this link for one example.
See this link for another.
It has been discussed before, you can have a look at here:
*EDIT: Just seeing the one idea per answer
A standardized MasterChef
A standardized StakingRewards, for both when baseToken == rewardToken and when baseToken != rewardToken
An Escrow and/or PaymentSplitter that can handle different (maybe even multiple?) ERC20
EDIT: Related: #1099
EDIT #2: Looks like a #1238 was a valid PR accepted into an escrow-exploration branch that no longer exists. As such, I can't follow the thought process of why it's not a standard. Any thoughts here?
*EDIT #3: PaymentSplitter now does this, but Escrow does not.
@0xLostArchitect Do you use the Escrow contracts? How?
The reality is we're not making changes to these contracts because they're not something we have clear use cases for.
Currently we have two - one for a marketplace and one for a Reflection style contract that accounts for various tokens.
We are transitioning to using our own ERC20, and there will be a large number of different contracts transferring said token as rewards (ideally into an Escrow). Preferably we can use a form of a SharedEscrow (likely using some form of AccessControl), so that there aren't some large number of Escrows floating around. This would essentially be a mix of the TokenEscrow linked to above with some DEPOSITER_ROLE.
The second functional requirement regards payouts from purchases on the marketplace, for which we would like to both use an Escrow but also payout in the native token.
Therefore, the dream would be something like A permissioned Escrow that can handle both >= 1 ERC20.