-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bespoke timelock contract #706
Comments
Can you give details on how we plan to implement this contract? Would Thinking to something like this: struct Stream {
// slot 0
address sender;
uint40 startTime;
uint40 cliffTime;
bool isCancelable;
bool wasCanceled;
// slot 1
IERC20 asset;
uint40 endTime;
bool isDepleted;
bool isStream;
bool isTransferable;
// slot 2 and 3
Lockup.Amounts amounts;
// slot [3..n]
UnlockDetails[] unlockDetails;
}
struct UnlockDetails {
uint40 milestones;
uint128 amount;
} |
@andreivladbrg the design of the contract is up to you because I don't have much time on my hands nowadays. But no, |
Another timelock user: https://twitter.com/ashleighschap/status/1712946120584781961 Created this LockupDynamic stream: |
As discussed with @andreivladbrg on the call, it is not worth it to over-optimize the protocol for this particular use case. We can consider this optimized contract later if we suddenly get a large influx of timelock users. |
Context
We keep getting requests for timelocks - e.g. see this recent tag on Twitter:
https://twitter.com/Arr00c/status/1712559004814381308
This mention has resulted in two LockupDynamic streams with one segment and a duration of 1 second:
This is how the release curve looks like:
Task
The context above is sufficient proof that there's a need for timelocks in web3. We should build a bespoke contract focused on this use case.
Building this feature entails a soft pivot from "streaming-only" to "token distribution", but that's ok. See the related discussions here and here.
The text was updated successfully, but these errors were encountered: