-
Notifications
You must be signed in to change notification settings - Fork 160
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
Module Development Task: Vesting Escrow Wallet #269
Comments
Issue Status: 1. Open 2. Started 3. Submitted 4. Done This issue now has a funding of 5000.0 POLY (749.5 USD @ $0.15/POLY) attached to it.
|
Issue Status: 1. Open 2. Cancelled Work has been started. These users each claimed they can complete the work by 4 months, 2 weeks ago. 1) shanefontaine has been approved to start work. The following are steps that will be taken to complete this task:
The following are questions that I have related to the task:
Note: I have written a very similar contract before and have experience with this kind of smart contract. Learn more on the Gitcoin Issue Details page. |
@shanefontaine Sounds like a plan from your side.
If you have more queries then please let me know. |
@satyamakgec Am I approved and allowed to proceed on this work? |
@CPSTL please put some light here. |
@shanefontaine Please let me know if you have any questions as you work towards this task. |
@CPSTL @satyamakgec A few questions: Business Logic
Architecture
The code so far is here. I'd like you to take a look and make sure nothing is out of the ordinary. A good chunk of the business logic is there, but my next step is to integrate it with your existing architecture and then test it of course. |
Yes, many possible scenarios where the employee gets the more tokens as vested ex- Performance bonus.
It depends upon the divisibilty of the security token by default all securitytoken with in the polymath ecosystem have 18 decimals but issuer can choose whether he/she want their ST divisible or not. so you have to keep these things in mind at the time of creation of this module.
The sum is granted at once. so whatever the tokens are assigned at first call then it gets automatically divided as per the cliffing strategy issuer or delegate (Authorised person) put into the contract.
As per the lucidchart you need to create something like that
hmm Interesting IMO employee should get a right to take its unclaimed token. But yes there will be some strategy to pull out the unclaimed tokens by the issuer after a certain challenging period. (will give you more info after internal discussion).
I prefer to be deleted no need to keep the unnecessary data we already have all the logs present in the blockchain. You will delete the vesting schedule but you need to provide two options(as described in lucidchart) to issuer/delegate related to the remaining tokens management.
(1) It will work as conjunction with STO module so suppose you created some buying restriction in your STO. ex- restriction 1 - If someone buys the token amount more than 50000 then his/her tokens get vested for 2 years with a cliff of 4 months so these 50000 tokens get vested into the vested contract with the template data provided from the STO. I think now you can compare 1 and 2 clearly.
An issuer can create some templates not too many, only those that issuer can frequently use (ex- for every new joinee, for providing gratuity etc.)
Yes, Admin can push the token.
You will have some variable in contract
No, Issuer will have the edit option to change the vesting schedule using this all the tokens get live quickly and an employee can withdraw the tokens/issuer push these tokens to them. Architecture
|
Thank you for the quick response. I am implementing those changes as we speak. On issue I am trying to wrap my head around right now is a matter of architecture. I have been reading through this, as well as a number of other references on your site about how the factories and interfaces work. I believe I understand it, but am having an issue compiling my code. When I compile it, I get the following errors:
The first error is here in my Wallet Factory. I understand that a flag is raised when the contract is an abstract contract, but I do not think that this is the case here. Is there something I am missing during this initialization? I thought that the IModule "interface defines some functionality which is common across all modules." Why would I be getting this error if I neither edited |
FYI more info on this
Yes, option one will be Implemented and Issuer can retrieve any remaining unvested portion. For your error, you need to implement a I hope this will help. Thanks |
You said option one and issuer, which are contracdictory. Which did you mean? |
@shanefontaine The Employee / Affiliate should be able to claim any tokens vested up until the schedule is voided. With that being said, afterwards the Issuer can retrieve any remaining unvested portion of tokens. Does that help answer your question? |
@CPSTL Yes, it does, partially. What if the employee/affiliate has unclaimed, vested tokens after void of contract. I believe (and suggest) the solution is to make it in such a way that upon cancellation, the issuer receives the unvested tokens, the employee receives all vested tokens, and the account gets deleted. Does that sound reasonable? |
Can this simply be done by creating a new vesting schedule with these tokens (as opposed to adding onto an existing schedule). Creating a new vesting schedule for new tokens makes sense, and is easy to implement/understand from an issuer's perspective. Adding tokens onto an existing schedule makes implementation much more complex, causing a state change for each variable needing changing and recalculations/checks for each parameter. I cannot think of a scenario where an issuer would need to add to an existing vesting schedule and NOT simply create a new one (even if it behaves the same way as the old one).
In this scenario, does the employee always get all of their tokens? |
Yes
Yes simply create a new, My example has only sketched a scenario and I am a favor of creating a new one not to edit the same schedule.
Yes |
@shanefontaine Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
Hey @shanefontaine how are you doing with this task? Let us know if you have any more questions :) |
@CPSTL Great. I am almost complete. I have a few questions regarding testing, so I am setting up a time to chat with @satyamakgec. After our call, I should be able to complete it w/in 24 hours and I'll submit a PR. |
@CPSTL @satyamakgec I am finishing it up now and will have a PR submitted soon. I apologize for the delay. |
Cool no worries!. When you submit the PR then let me know so I can start the reviewing process. |
PR has been submitted. |
@shanefontaine Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
I have submitted a PR. |
@shanefontaine Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
I have submitted a PR. |
@shanefontaine Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
1 similar comment
@shanefontaine Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
@shanefontaine You have to submit the PR on gitcoin via |
@shanefontaine Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
Issue Status: 1. Open 2. Started 3. Submitted 4. Done @shanefontaine due to inactivity, we have escalated this issue to Gitcoin's moderation team. Let us know if you believe this has been done in error!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days |
Issue Status: 1. Open 2. Cancelled The funding of 5000.0 POLY (870.0 USD @ $0.17/POLY) attached to this issue has been cancelled by the bounty submitter
|
1 similar comment
Issue Status: 1. Open 2. Cancelled The funding of 5000.0 POLY (870.0 USD @ $0.17/POLY) attached to this issue has been cancelled by the bounty submitter
|
closing in the favor of #422 |
Module Development Task
Vesting Escrow Wallet
Short Summary
As an Issuer, I can program an automated token vesting schedule for employees and/or affiliates so that Tokens get delivered to their wallets as contractually defined.
This would be a smart contract that the issuer can send tokens to and then select the address that would be able to withdraw them according to their specific vesting schedule.
Bounty Requirements
IMPORTANT: Please work from the development-1.5.0 branch instead of master.
Module Details and Specs (Wireframe)
Wireframe Link: https://www.lucidchart.com/invitations/accept/450646a3-5af0-42b5-b155-de5ec94232d4
Assumptions & User/Issuer Stories
As an issuer I want to be able to add a module for vesting schedule to my STO
As an issuer I want to add vesting schedules to employees / affiliates I have minted tokens so that I can incentivize them for the long term
As an issuer I want to add vesting schedules to employees / affiliates I have not minted tokens so that I can incentive new employees / affiliates for the long term
As an issuer I want to be able to create a template of a vesting schedule so that I can easily apply them to each of the employees / affiliates
As an issuer I want to be able to bulk add vesting schedules for each of my employees / affiliates so that I don't have to manually do it for each individual one
As an issuer I want to be able to void a vesting schedule so that I can stop the automated vesting if an employee / affiliate leaves
As an issuer I want to be able to add multiple vesting schedules for each employee / affiliate so that I can issue out tokens as bonus and continue to incentivize them for the long term
As an issuer I want to be able to view all my vesting schedules and it's progress so I can have a quick overview on how much tokens each of my employees / affiliates have
The text was updated successfully, but these errors were encountered: