ERC20Vesting: vesting functionality for ERC20 tokens

[Keref]

🧐 Motivation Escrowed tokens are omnipresent in DeFi, as governance, airdrops and liquidity mining use vesting to control dumping. I suggest adding an ERC20Vesting extension that easily allows vesting tokens.

📝 Details

Vesting can be used in particular in combination with ERC20Wrapper. The vesting schedule is linear by default but can be overriden (we use some exponential for our own vesting schedule). The logic when withdrawing isn't fixed: the extension returns the amount already vested and the amount remaining, up to the implementation to choose whether to allow early unlock and which penalty to apply.

I think it would make sense to add some additional virtual function to handle the data field, or to modify a schedule (eg, to allow partial withdrawal). The function names differ from VestingWallet, maybe it would make sense to harmonize those. Please give me feedback!

Draft implementation: https://github.com/Keref/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Vesting.sol

[Amxx]

Hello @Keref

Are you familiar with our VestingWallet ? Can you tell us more about the usecases where it does not work for you ?

My first thought is that the vesting should be handled by a dedicated contract, and not by the token itself.

[Keref]

Hi, yes I'm aware. The vesting wallet is created to vest for 1 unique beneficiary provided in the constructor. This makes it only usable for initial distribution of tokens for, say, a VC who bought tokens early.

What I'm proposing is an ERC20 extension that can be added to any token. It can be used to escrow governance tokens, in my case the esToken allows depositing Token, also extends a number of governance functions, and uses ERC20Vesting (we prefer vesting rather than the ve- model).

[frangio]

The linked contract says its an extension of ERC20 but the contract doesn't extend ERC20 in any way. Can you clarify how the interaction is supposed to work with ERC20 balances?

[Keref]

Indeed good feedback, the balance verification was in my mock contract. I changed ERC20Vesting to extend ERC20, and add some vesting function with balance check.

A simple use case would be to extend ERC20Wrapper and ERC20Vesting, and to only allow withdrawal of vesting tokens (e.g only if vesting is over, or could burn the remaining like Radiant Protocol does).

In our case, our esToken extends ERC20Wrapper, ERC20Vesting, ERC20Votes, and tokens can be deposited for governance and rewards, with a 3 months unlock period (code isn't open source but will be soon, can share the link here when it is).

It can also extend a masterchef-like contract so that withdrawal takes 1 week.

[frangio]

Are the tokens under vesting supposed to be transferable?

We need a clear description of what the feature is supposed to be so we can evaluate if it's a right fit for the library. If there is something like this out there please share the reference.

[Keref]

Here's an attempt to clarify all: ERC20Vesting is an ERC20 extension that allows controlling token flows through vesting. Vesting unlocks one or more functions (withdrawal, transfer, mint...)

Functionalities:

• Restricted token transfer by default
• Simultaneous vesting batches for each user (different amounts of tokens vesting with different start date)
• Configurable vesting schedule (default function is linear unlock)
• Extensible: contract can add properties indexed by vestingId

Example use cases:

• Escrowed governance token with vesting: A typical use case is to extend a governance escrowed token (which already extends ERC20Wrapper and ERC20Votes) with ERC20Vesting, and override the ERC20Wrapper withdraw() to require _vesting()
• Weighted governance: similar to escrowed governance, but with a ve- lockup flavor, depositing tokens with a longer lockup provides the depositor with additional governing power
• Vested rewards for liquidity mining: instead of distributing Token (e.g through a "masterchef" or Aave incentive controller), distribute esToken, which in turn can be redeemed for Token after vesting. Rewards can be withdrawn early but with a penalty. This is used by e.g GMX and Radiant to control farm and dump.

I added some mock contracts for each example use case EsGovernanceTokenMock, VeGovernanceTokenMock, VestedMiningRewardsMock to showcase how to use and why this is useful as a general extension to include in OpenZeppelin. For example a ve- lockup model can then be implemented with less than 30 lines of code. Thanks for your feedback! 🙏

Edit: btw there aren't test files because for our project we use Brownie tests, so I'd rather not duplicate unless there's actual interest in integrating ERC20Vesting in OpenZeppelin

[frangio]

Great, thank you. We will leave this open for consideration.

[TrejGun]

As the whole US economy is based on debts it makes sense to include functions for changing vesting owners. Unfortunately this contract does not have such functionality. OZ VestingWallet has such functionality when is extended from Ownable. But the easiest way to transfer ownership would be NFT with vesting because it would be easy to trade on any marketplace

[Rickcodes21]

Cross-chain swaps, also known as atomic swaps or cross-chain atomic swaps, are a mechanism that allows the exchange of one cryptocurrency directly for another between two different blockchain networks without the need for an intermediary, such as a centralized exchange. These swaps are secure, trustless, and decentralized, making them an attractive solution for interoperability between blockchain ecosystems. Here’s how cross-chain swaps work:

1.  Participants:
•   Cross-chain swaps involve at least two participants, each using a different blockchain network. For simplicity, let’s call them Alice and Bob.
2.  Agreement:
•   Alice and Bob agree to swap cryptocurrencies. They specify the amount to be exchanged, the exchange rate, and the duration of the swap (a predefined time window during which the swap can occur).
3.  Hash Time-Locked Contracts (HTLCs):
•   Alice and Bob both create Hash Time-Locked Contracts (HTLCs) on their respective blockchain networks. These smart contracts lock up the funds being exchanged.
•   HTLCs consist of two key components: a cryptographic hash of a secret and a time lock.
4.  Secret Generation:
•   Alice generates a random secret and hashes it to create a cryptographic hash (Hash1). She shares Hash1 with Bob but keeps the secret itself secret.
5.  Swap Initiation:
•   Alice initiates the swap by revealing Hash1 and the time lock to Bob. Bob can then verify the information on Alice’s blockchain.
6.  Bob’s Participation:
•   Bob, seeing that Alice has revealed Hash1 and the time lock, creates a second cryptographic hash (Hash2) using the same secret but does not reveal the secret itself.
•   He initiates a similar HTLC on his blockchain, using Hash2 and the same time lock as Alice’s HTLC.
7.  Execution:
•   Once both HTLCs are in place and the time lock has not expired, Alice and Bob can claim the funds in each other’s HTLCs by revealing the secret they know.
•   Alice reveals the secret to claim Bob’s funds on Bob’s blockchain, and Bob does the same to claim Alice’s funds on Alice’s blockchain.
•   This reveals the secret on both blockchains, ensuring that both participants receive the cryptocurrency they agreed to swap.
8.  Completion:
•   The swap is considered complete when both participants have successfully claimed the funds from each other’s HTLCs.
•   If either party fails to claim the funds within the specified time lock period, the funds are returned to their original owners.
9.  Trustlessness and Security:
•   Cross-chain swaps are trustless because neither party can access the other’s funds without revealing the secret, and there’s no need for a trusted intermediary.
•   The security of cross-chain swaps relies on cryptographic principles and the predetermined rules of the HTLCs.