Meta Issue: 4.4

[Amxx]

Candidates:

• Make some private functions internal to allow the developpement of "withSignature" functions (like permit) #2568
• Add a VestingWallet  #2748
• Extend PaymentSplitter to support ERC20 tokens #2858
• Add an internal _setApprovalForAll function (721 & 1155) #2834
• Fix EIP712 for delegatecalls #2852
• #890: Add ECDSA.toEthSignedMessageHash(bytes) for abritrary length message hashing #2865
• Add a MerkleProof.processProof utility function #2841
• Governor improvements
  • Allow Governor + CompoundTimelock to manage native tokens (eth) in and out of the timelock contract. #2849
  • Delay the Pending state until strictly after proposal.voteStart #2892
  • Add Governor module for governance-settable parameters #2904
  • Allow Governor + CompoundTimelock to manage native tokens (eth) in and out of the timelock contract. #2849
    • Changelog entry
• Add SignedMath with math utilities for signed integers #2686 → moved to 4.5

[k06a]

Do you consider index recovery from #2815 or non-ordered merkle tree proof validation?

[sabotagebeats]

@Amxx let me know if i can help with #2701 and #2762

[Amxx]

@Amxx let me know if i can help with #2701 and #2762

You can track the work in progress on this branch: https://github.com/Amxx/openzeppelin-contracts/tree/feature/paymentsplitter/contracts/finance

I understand your desire to see this issue address, but we want to make sure we do it right. In particular, there are a lot of challenges to work around, and difficult choices to make.

In particular, we would like

• A single contract supporting multiple assets tokens.
• The ability to reallocate payment shares dynamically, with moving of shares only affecting future payments.

Both feature are easilisy implementable alone, but the combination feels insolvable.

[sabotagebeats]

In particular, we would like

• A single contract supporting multiple assets tokens.

This one seems pretty easy, the code I added in the comment does this. If there is a registration array, multiple tokens could be rescued in one call by looping the array.

• The ability to reallocate payment shares dynamically, with moving of shares only affecting future payments.

This can be accomplished if the reallocation calls release on all ether in the contract, and rescue all tokens, before the reallocation occurs. The addresses of the tokens to be released must be added in a array somewhere I'm the contract. There's not a way for the contract to be able to pull all the tokens balances that it holds that I know of, without calling balances on the original contracts, which it won't know about unless they're added to a registry array. Unless you know a better way?

Additionally need to be careful too because then the recipients are trusting the reallocation role holder, so it would be best to use a gnosis safe multisig to hold that role and control reallocation

[frangio]

The first release candidate has been released. It will be at least 3 weeks before the final release is published. We will be announcing more details about the timeline later.

[whitecow]

Any update on release date?

[Amxx]

@whitecow 4.4 release candidate is currently available. Actual release should be out in 1 to 2 weeks

[frangio]

A new release candidate is available with a few bug fixes.

A release candidate for the upgradeable contracts is available as well.

[frangio]

This release is out now! Short announcement in the forum.

This release was a little slow because it was the first time we formalized a longer Open Review Period and were trying to get the bug bounty set up on time. Thanks for the patience. Things will be faster next time!