Multi vesting contract feature proposal

[MerlinEgalite]

🧐 Motivation There is already a VestingWallet contract allowing to deploy a vesting contract to a specific beneficiary address. However, when you must create vestings for tens of people, this is too restrictive as you need to deploy a contract per beneficiary, costing a lot of gas and it's hard to manage.

It would be nice to have a multi vesting contract, like the dss-vest of Maker but with better naming and complementary features.

This is really needed for DAOs in general and having an OZ implementation would ease DAO's operational cost and reinforce trust between the DAO and their investors, advisors, contributors, etc.

📝 Details

• [ ] Create a MultiVesting contract allowing to create multiple vestings for multiple beneficiaries through the same contract
• [ ] Implement all the available feature of the dss-vest
• [ ] Add the ability to add or not a manager that can revoke a vesting contract
• [ ] If a manager is set, add the possibility for the owner to change the manager

Happy to help if needed!

[Amxx]

Hello @MerlinEgalite

I'll definitelly have a look a dss-vest, but in the meantime I'd like to point you to 2 options:

NFF

However, when you must create vestings for tens of people, this is too restrictive as you need to deploy a contract per beneficiary, costing a lot of gas and it's hard to manage.

You could do it for "decently" cheap using a factory. This is why I built NFF a while back:

• the github repo
• the frontend
• the contract deployed on mainnet

Creating a vault using this approach cost ~168k gas. Its not nothing, but its way less than deploying a new contract (and it comes with transferability)

VestedAirdrop

Another thing I build is the VestedAirdrop contract. This contract is not trustless, so each project needs one of its own. The admin can register "airdrop" in merkle trees, and enable the airdrop by adding the merkle tree root to a whitelist. Anyone in the merkle tree can come and prove that they are part of the airdrop and claim the tokens. Obviously, the airdrop a vesting schedule. An airdrop could be reduced to a single entry, in which case there is no need to even build the merkle tree and provide a merkle proof. Just whitelisting the hash of the Schedule is enough to enable it.

Both these contract were built using OZ, but they are not actually part of OZ's library. Is there any chance either of these might fit your needs? If yes, we'd love to know which one. Otherwise, we'd also love to know why not.

[MerlinEgalite]

I did not know about those options thx!

So for the 2 options I think there are some missing features that would have fit us:

• NFF: It's not possible to revoke a vesting or end it prematurely as some "real-world" vesting contracts would allow.
• VestedAirdrop: In my understanding, there's the same issue unless the admin disables the root and creates a new one, am I mistaken?

For context, we opted for the dss-vest for its modularity. However the verbosity of their contracts does not help non-technical persons to understand it nor technical persons to grasp quickly the code.

[Amxx]

Yes

• NFF is designed to be trustless. Nobody can alter a schedule once its deployed.
• in VestedAidrop, the admin indeed must disable a schedule before possibly re-enable it in a different format.

[vachmara]

Hey @MerlinEgalite,

If you're still looking for a solution for creating vesting contracts for multiple beneficiaries through the same contract and reducing gas costs.

I recommend checking out the Token Vesting Contracts project. It seems to address the requirements you mentioned earlier and could be a good fit for your project.

[MerlinEgalite]

Interesting, I'll have a look! I've almost finished my own implementation solvest meanwhile haha