VestingToken
Git Source Inherits: ERC20Upgradeable, ReentrancyGuardUpgradeable, IVestingToken Authors: JA (@ubinatus) v3, Klaus Hott (@Janther) v2 VestingToken locks ERC20 and contains the logic for tokens to be partially unlocked based on milestones.State Variables
ONE
Percentages and fees are calculated using 18 decimals where 1 ether is 100%.underlyingToken
The ERC20 token that this contract will be vesting.manager
The manager that deployed this contract which controls the values forfee and feeCollector.
_decimals
Thedecimals value that is fetched from underlyingToken.
_startingSupply
The initial supply used for calculating theclaimableSupply, claimedSupply, and lockedSupply.
_importedClaimedSupply
The imported claimed supply is necessary for an accurateclaimableSupply but leads to an improper offset
in claimedSupply, so we keep track of this to account for it.
_milestones
An array of Milestones describing the times and behaviour of the rules to release the vested tokens._lastReachedMilestone
Keep track of the last reached Milestone to minimize the iterations over the milestones and save gas._metadata
Maps a an address to the metadata needed to calculateclaimableBalance and lockedBalanceOf.
Functions
constructor
initialize
Initializes the contract by setting up the ERC20 variables, theunderlyingToken, and the
milestonesArray information.
*The Ramp of the first Milestone in the milestonesArray will always act as a Cliff since it doesn’t have
a previous milestone.
Requirements:
underlyingTokenAddresscannot be the zero address.timestampsmust be given in ascending order.percentagesmust be given in ascending order and the last one must always be 1 eth, where 1 eth equals to 100%.- 2
percentagesmay have the same value as long as they are followed by aRamp.LinearMilestone.*
decimals
Returns the number of decimals used to get its user representation. For example, ifdecimals equals 2,
a balance of 505 tokens should be displayed to a user as 5.05 (505 / 10 ** 2).
Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. Since we can’t predict
the decimals the underlyingToken will have, we need to provide our own implementation which is setup at
initialization.
NOTE: This information is only used for display purposes: it in no way affects any of the arithmetic of the
contract.
addRecipient
Vests anamount of underlyingToken and mints LVTs for a recipient.
Requirements:
msg.sendermust have approved this contract an amount ofunderlyingTokengreater or equal thanamount.
addRecipients
Vests multipleamounts of underlyingToken and mints LVTs for multiple recipients.
Requirements:
recipientsandamountsmust have the same length.msg.sendermust have approved this contract an amount ofunderlyingTokengreater or equal than the sum of all of theamounts.
importRecipient
Behaves asaddRecipient but provides the ability to set the initial state of the recipient’s metadata.
This functionality is included in order to allow users to restart an allocation on a different chain and
keeping the inner state as close as possible to the original.
The Metadata.claimedAmountAfterTransfer for the recipient is inferred from the parameters.
The Metadata.claimedBalance is lost in the transfer, the closest value will be
claimedAmountAfterTransfer.
In the rare case where the contract and it’s users are migrated after the last milestone has been reached,
the claimedAmountAfterTransfer can’t be inferred and the claimedSupply value for the whole contract is lost
in the transfer.
*The decision to do this is to minimize the altering of metadata to the amount that is being transferred and
protect an attack that would render the contract unusable.
Requirements:
unlockedmust be less than or equal to this contractsunlockedPercentage.claimableAmountOfImportmust be less than or equal than the amount that would be claimable given the values ofamountandpercentage.msg.sendermust have approved this contract an amount ofunderlyingTokengreater or equal thanamount.*
importRecipients
Behaves asaddRecipients but provides the ability to set the initial state of the recipient’s
metadata.
This functionality is included in order to allow users to restart an allocation on a different chain and
keeping the inner state as close as possible to the original.
The Metadata.claimedAmountAfterTransfer for each recipient is inferred from the parameters.
The Metadata.claimedBalance is lost in the transfer, the closest value will be
claimedAmountAfterTransfer.
In the rare case where the contract and it’s users are migrated after the last milestone has been reached,
the claimedAmountAfterTransfer can’t be inferred and the claimedSupply value for the whole contract is lost
in the transfer.
The decision to do this to minimize the altering of metadata to the amount that is being transferred and
protect an attack that would render the contract unusable.
*The Metadata for the recipient is inferred from the parameters. The decision to do this to minimize the
altering of metadata to the amount that is being transferred.
Requirements:
recipients,amounts, andclaimableAmountsOfImportmust have the same length.unlockedmust be less than or equal to this contractsunlockedPercentage.- each value in
claimableAmountsOfImportmust be less than or equal than the amount that would be claimable given the values inamountsandpercentages. msg.sendermust have approved this contract an amount ofunderlyingTokengreater or equal than the sum of all of theamounts.*
exportRecipient
Returns
exportRecipients
Returns
updateLastReachedMilestone
This function will check and update the_lastReachedMilestone so the gas usage will be minimal in
calls to unlockedPercentage.
This function is called by claim with a value of startIndex equal to the previous value of
_lastReachedMilestone, but can be called externally with a more accurate value in case multiple Milestones
have been reached without anyone claiming.
unlockedPercentage
claimedSupply
claimableSupply
lockedSupply
claimedBalanceOf
Returns
claimableBalanceOf
Returns
lockedBalanceOf
Returns
claim
Claims available unlockedunderlyingToken for the caller.
Transfers claimable amount to msg.sender and requires a claim fee (msg.value).
Reverts if there’s no claimable amount. Protected against re-entrancy.
burn
Allows an investor to burn their vested and underlying tokens. First attempts to burn the underlying tokens. If unsuccessful, these are sent to address ‘0xdead’. This operation is followed by the burning of the equivalent vested tokens. Assumes the underlying token has a burn function with the selector ‘0x42966c68’.transfer
Calculates and transfers the fee before executing a normal ERC20 transfer. This method also updates the metadata inmsg.sender, to, and feeCollector.
transferFrom
Calculates and transfers the fee before executing a normal ERC20 transferFrom. This method also updates the metadata infrom, to, and feeCollector.
milestones
Exposes the whole array of_milestones.
metadataOf
Exposes the inner metadata for a given account.transferFeeData
Returns the current transfer fee associated to thisVestingToken.
claimFeeData
Returns the current claim fee associated to thisVestingToken.
_updateMetadataAndTransfer
This function updates the metadata on thesender, the receiver, and the feeCollector if there’s any
fee involved. The changes on the metadata are on the value claimedAmountAfterTransfer which is used to
calculate _claimableAmount.
*The math behind these changes can be explained by the following logic:
- claimableAmount = (unlockedPercentage * startingAmount) / ONE - claimedAmount
When there’s a transfer of an amount, we transfer both locked and unlocked tokens so the
claimableAmountAfterTransferwill look like: - claimableAmountAfterTransfer = claimableAmount ± claimableAmountOfTransfer
Notice the ± symbol is because the
sender’sclaimableAmountis reduced while thereceiver’sclaimableAmountis increased. - claimableAmountOfTransfer = claimableAmountOfSender * amountOfTransfer / balanceOfSender We can expand 3) into:
- claimableAmountOfTransfer =
(unlockedPercentage * ((startingAmountOfSender * amountOfTransfer) / balanceOfSender)) / ONE) -
((claimedAmountOfSender * amountOfTransfer) / balanceOfSender)
Notice how the structure of the equation is the same as 1) and 2 new variables can be created to calculate
claimableAmountOfTransfera) startingAmountOfTransfer = (startingAmountOfSender * amountOfTransfer) / balanceOfSender b) claimedAmountOfTransfer = (claimedAmountOfSender * amountOfTransfer) / balanceOfSender ReplacingclaimableAmountOfTransferin equation 2) and expanding it, we get: - claimableAmountAfterTransfer = ((unlockedPercentage * startingAmount) / ONE - claimedAmount) ± ((unlockedPercentage * startingAmountOfTransfer) / ONE - claimedAmountOfTransfer) We can group similar variables like this:
- claimableAmountAfterTransfer =
(unlockedPercentage * (startingAmount - startingAmountOfTransfer)) / ONE -
(claimedAmount - claimedAmountOfTransfer)
This shows that the new values to calculate
claimableAmountAfterTransferif we want to continue using the equation 1) are: c) startingAmountAfterTransfer = startingAmount ± (startingAmountOfSender * amountOfTransfer) / balanceOfSender d) claimedAmountAfterTransfer = claimedAmount ± (claimedAmountOfSender * amountOfTransfer) / balanceOfSender Since these values depend linearly on the value ofamountOfTransfer, and the fee is a fraction of the amount, we can just factor in thetransferFeePercentageto get the values for the transfer to thefeeCollector. e) startingAmountOfFee = (startingAmountOfTransfer * transferFeePercentage) / ONE; f) claimedAmountOfFee = (claimedAmountOfTransfer * transferFeePercentage) / ONE; If we look at equation 1) and setunlockedPercentageto ONE, thenclaimableAmountmust equal to thebalance. Therefore the relation betweenstartingAmount,claimedAmount, andbalanceshould be: g) startingAmount = claimedAmount + balance Since we want to minimize independent rounding in all of thestartingAmounts, andclaimedAmounts we will calculate theclaimedAmountusing multiplication and division as shown in b) and f), and thestartingAmountcan be derived using a simple subtraction. With this we ensure that if there’s a rounding down in the divisions, we won’t be leaving any token locked.*
_setupMilestones
Validates and initializes the VestingToken milestones. It will perform validations on the calldata: - Milestones have percentages and timestamps sorted in ascending order. - No more than 2 consecutive Milestones can have the same percentage. - 2 Milestones may have the same percentage as long as they are followed by a Milestone with aRamp.Linear.
- Only the last Milestone should have 100% percentage.
_tryFetchDecimals
Perform a staticcall to attempt to fetchunderlyingToken’s decimals. In case of an error, we default to
18.
_getBalanceOfThis
Perform a staticcall to attempt to fetchunderlyingToken’s balance of this contract. In case of an error,
reverts with custom UnsuccessfulFetchOfTokenBalance error.
_claimedAmount
This method is used to infer the value of claimed amounts. If the unlocked percentage has already reached 100%, there’s no way to infer the claimed amount.
Returns
_claimableAmount
Returns
_processClaimFee
Processes the claim fee for a transaction. This function retrieves the claim fee data from the manager contract and, if the claim fee is greater than zero, sends themsg.value to the fee collector address. Reverts if the transferred value is less than the
required claim fee or if the transfer fails.
Events
Claim
Burn
MilestoneReached
Structs
Metadata
claimedAmountAfterTransfer is used to calculate the _claimableAmount of an account. It’s value is
updated on every transfer, transferFrom, and claim calls.
While claimedAmountAfterTransfer contains a fraction of the claimedAmountAfterTransfers of every token
transfer the owner of account receives, claimedBalance works as a counter for tokens claimed by this account.