Add Vesting #425
Add Vesting #425
Conversation
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
|
|
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
| import { durationToTimestamp } from './utils/duration'; | ||
| import { toUint, validateUint } from './utils/convert-strings'; | ||
|
|
||
| export type VestingSchedule = 'linear' | 'custom'; |
There was a problem hiding this comment.
Since we already have the "steps" schedule implemented as a mock and as an example in "Usage", do you think it's worth adding the option here?
There was a problem hiding this comment.
Actually, I don't reckon it's worth it. The steps schedule is mostly for demonstration purposes, it's kinda naive and I expect it to be used almost never or very rarely
| <HelpTooltip link="https://docs.openzeppelin.com/contracts-cairo/access#ownership_and_ownable"> | ||
| Simple mechanism with a single account authorized for all privileged actions. | ||
| </HelpTooltip> | ||
| </label> | ||
| <label class:checked={opts.schedule === "custom"}> | ||
| <input type="radio" bind:group={opts.schedule} value="custom"> | ||
| Custom | ||
| <HelpTooltip link="https://docs.openzeppelin.com/contracts-cairo/access#role_based_accesscontrol"> | ||
| Flexible mechanism with a separate role for each privileged action. A role can have many authorized accounts. | ||
| </HelpTooltip> |
There was a problem hiding this comment.
The tooltips need to be fixed
There was a problem hiding this comment.
If we don't want to include the steps vesting option, I think we can at least direct users to it as an example when hovering the Custom tooltip
| if (!match) { | ||
| if (!match || match.length < 2) { |
There was a problem hiding this comment.
Are there cases where a happy match also has match.length < 2?
There was a problem hiding this comment.
No, since later on we access the 1st and the 2nd items of the match array in unsafe manner. Either way it'll result in a runtime exception, but it's better to have a straightforward error than index-out-of-bounds one
| case 'Governor': | ||
| case 'Custom': | ||
| return c.options.upgradeable === isUpgradeable; | ||
| } |
There was a problem hiding this comment.
In case we add new contract kinds and forget to update this later on, this will help force a compile error:
| } | |
| default: | |
| const _: never = c.options; | |
| throw new Error('Unknown kind'); | |
| } |
| // These contracts have no acess control | ||
| return |
There was a problem hiding this comment.
| // These contracts have no acess control | |
| return | |
| // These contracts have no access control option | |
| break; |
| } else { | ||
| t.notRegex(contract.source, regexOwnable, JSON.stringify(contract.options)); | ||
| } | ||
| } |
There was a problem hiding this comment.
In case we add new contract kinds and forget to update this later on, this will help force a compile error:
| } | |
| } | |
| break; | |
| default: | |
| const _: never = contract.options; | |
| throw new Error('Unknown kind'); |
No description provided.