Conversation
merisman
left a comment
There was a problem hiding this comment.
I know we aren't planning to use token options anytime soon, but I don't want this to slip through the cracks. The grantee will call, but the erc-20 transfer occurs on the set recipient, which would take some extra coordination for Approvals. Should we take the payment from the grantee, as they are making the call? I could see both ways being viable option, one is just complicated to organize the approval from a front end.
function exerciseTokenOption(uint256 _tokensToExercise) external nonReentrant onlyGrantee {
if(block.timestamp>shortStopTime && terminated) revert MetaVest_ShortStopDatePassed();
if (_tokensToExercise == 0) revert MetaVesT_ZeroAmount();
if (_tokensToExercise > getAmountExercisable()) revert MetaVesT_MoreThanAvailable();
// Calculate paymentAmount
uint256 paymentAmount = getPaymentAmount(_tokensToExercise);
if(paymentAmount == 0) revert MetaVesT_TooSmallAmount();
address recipient = getRecipient();
safeTransferFrom(paymentToken, recipient, getAuthority(), paymentAmount);
tokensExercised += _tokensToExercise;
emit MetaVesT_TokenOptionExercised(grantee, recipient, _tokensToExercise, paymentAmount);
}
yeah good point, I think so too. It's simpler to have the grantee address approve and send the payment so all interactions are coming from there. This way the recipient address could stay gas-less and passive as well. Will do and add tests accordingly |
8f7a282 to
c2b87d7
Compare
|
Done. And I just realized it makes no sense to report |
TODO
updateVestingStartTime()updateUnlockStartTime()Added
MetavestController.recipientOverride: Overrides all downstream metavest vaults's recipient addresses. Set by authority onlyBaseAllocation.desiredRecipient: Specifies desired recipient of the tokens. Set by grantee onlyMetavestController.updateMetavestVestingStartTime()MetavestController.updateMetavestUnlockStartTime()BaseAllocation.updateVestingStartTime()BaseAllocation.updateUnlockStartTime()Updated
recipientfields to related events