Closed 0xPilou closed 5 months ago
First glance additional thinking points:
_createVestingSchedule
logic and avoid duplication_executeEndVesting
should have some check for the vesting schedule to have been claimedupdateVestingSchedule
considerations with the claimable?First glance additional thinking points:
- Prefer to converge on a single internal
_createVestingSchedule
logic and avoid duplication_executeEndVesting
should have some check for the vesting schedule to have been claimed- Are there any
updateVestingSchedule
considerations with the claimable?
Updated the contract to only use a single internal function.
For executeEndVesting
and updateVestingSchedule
, I do not see further considerations required specifically for claimable schedules.
What extra check did you foresee in executeEndVesting
?
My rational was that if the schedule has been claimed, then _isFlowOngoing
evaluates to true, and the vesting can then be ended. Else, (receiver didn't claim), only emit a "fail to execute vesting end" event.
It shouldn't be a problem since this function can only be called after the early end (which is the latest date possible of claim validity)
Install this PR (you need to setup Github packages):
yarn add @superfluid-finance/ethereum-contracts@PR1944
yarn add @superfluid-finance/sdk-core@PR1944
yarn add @superfluid-finance/sdk-redux@PR1944
GH closed this PR automatically a bit unexpectedly. Fixing.
The contract modification works includes :
VestingSchedule
data structure : addedbool isClaimable
in order to reflect if a given schedule requires claiming to start flowingVestingSchedule
data structure : addedclaimValidityDate
used for claimable vesting scheduleVestingScheduleCreated
event : addedbool isClaimable
_executeCliffAndFlow
method : behavior changes depending if the schedule is claimable or not. (i.e. if claimable, only the sender or receiver can execute)New contract version is available and deployed at : https://sepolia-optimism.etherscan.io/address/0xB47FbC1B7f8372825D742709087b909D36137FD2