IOST security record

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

The following inputs may not be validated in the `createVestingSchedule` function: #### No Zero Address Check to `_beneficiary` The function `createVestingSchedule` does not explicitly validate that the `_beneficiary` is not the zero address. If `_beneficiary = address(0)`, any call to `release` would attempt to transfer tokens to the zero address. Depending on the underlying ERC20 token implementation: - Some tokens treat transfers to address(0) as a burn, which might be unintended. - Others might revert on transfers to address(0), causing the tokens to remain locked in the contract. The current `IOSToken` will revert transfers to `address(0)`, potentially locking the tokens in the contract forever. #### Slice Period Seconds is Larger Than Duration If `slicePeriodSeconds` is larger than `duration`, no tokens become vested until `currentTime >= cliff + duration`. If the intended vesting is truly linear or incremental, it could be an unintended design. If the team wants lump-sum vesting at the end (one big slice), the current design should be okay. The admin could deliberately set `slicePeriodSeconds = duration` or even `slicePeriodSeconds > duration` and get a single unlocking event at the end. #### The `_start` Can be Before the Current Time There is no restriction preventing `_start` from being less than the current block timestamp (`block.timestamp`). When `_start + _cliff` is already in the past, the schedule may be partially or fully vested upon creation. If this design is intended to allow the `beneficiary` to immediately have the right to release some or all of the tokens, the current should be okay.