-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add a new ReleaseSchedule
trait
#49
Conversation
…plemented and tested
…ndingProject but it is already implemented if the caller adds it in teh BidInfoFilter
Runtime on skeleton is not compiling. pallet-vesting needs to be configured there |
parameter_types! { | ||
pub const MinVestedTransfer: u64 = 256 * 2; | ||
pub UnvestedFundsAllowedWithdrawReasons: WithdrawReasons = | ||
WithdrawReasons::except(WithdrawReasons::TRANSFER | WithdrawReasons::RESERVE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understood correctly, this means that funds that are locked (or "held") can still be used for paying fees, transaction costs, and tipping. Is this the behavior we want?
I can imagine someone with locked PLMC that wants it out could just tip the whole locked amount to another account of his to take the money out
A simple example of a FRAME pallet demonstrating | ||
the ease of requirements for a pallet in dev mode. | ||
|
||
Run `cargo doc --package pallet-dev-mode --open` to view this pallet's documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need much documentation right now for this pallet, but let's remove the deprecated info from the template at least
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 729f6e2.
Solved in 0817995. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main vesting logic is too big to review in our current time frame. Next time it will be more useful to have a diff of the original pallet_vesting.
I suggest we merge this for now since your tests are passing, and address any issues we encounter once we use the pallet inside pallet_funding
|
This PR introduces a new
ReleaseSchedule
trait and a newlinear-release
pallet that implements it. The trait serves to apply release limits to a particularfungible
and provides several key methods to interact with the release schedule for an account.Key features of the
ReleaseSchedule
trait include:vesting_balance
: This method returns the amount that is currently being vested and cannot be transferred out of an account. It returns None if the account has no vesting schedule.add_release_schedule
: This method allows a release schedule to be added to a given account. If the account has reached the MaxVestingSchedules, an error is returned and nothing is updated. It's a no-op if the amount to be vested is zero. Importantly, this doesn't alter the free balance of the account.set_release_schedule
: This method sets a release schedule for a given account, without locking any funds. Similar to the add_release_schedule, it returns an error if the account has MaxVestingSchedules and doesn't alter the free balance of the account.can_add_release_schedule
: This method checks if a release schedule can be added to a given account.remove_vesting_schedule
: This method allows for a vesting schedule to be removed from a given account. Note, this does not alter the free balance of the account.The main differences with
pallet_vesting
are:fungible::Hold
instead ofLockableCurrency
, this change enable a more granular control.set_release_schedule
to set a ReleaseSchedule without locking thefungible
in the same transaction.