Crate pallet_nis
source ·Expand description
Non-Interactive Staking (NIS) Pallet
A pallet allowing accounts to auction for being frozen and receive open-ended inflation-protection in return.
Overview
Lock up tokens, for at least as long as you offer, and be free from both inflation and intermediate reward or exchange until the tokens become unlocked.
Design
Queues for each of 1..QueueCount periods, given in blocks (Period). Queues are limited in
size to something sensible, MaxQueueLen. A secondary storage item with QueueCount x u32
elements with the number of items in each queue.
Queues are split into two parts. The first part is a priority queue based on bid size. The
second part is just a FIFO (the size of the second part is set with FifoQueueLen). Items are
always prepended so that removal is always O(1) since removal often happens many times under a
single weighed function (on_initialize) yet placing bids only ever happens once per weighed
function (place_bid). If the queue has a priority portion, then it remains sorted in order of
bid size so that smaller bids fall off as it gets too large.
Account may enqueue a balance with some number of Periods lock up, up to a maximum of
QueueCount. The balance gets reserved. There’s a minimum of MinBid to avoid dust.
Until your bid is consolidated and you receive a receipt, you can retract it instantly and the funds are unreserved.
There’s a target proportion of effective total issuance (i.e. accounting for existing receipts) which the pallet attempts to have frozen at any one time. It will likely be gradually increased over time by governance.
As the proportion of effective total issuance represented by outstanding receipts drops below
FrozenFraction, then bids are taken from queues and consolidated into receipts, with the queue
of the greatest period taking priority. If the item in the queue’s locked amount is greater than
the amount remaining to achieve FrozenFraction, then it is split up into multiple bids and
becomes partially consolidated.
With the consolidation of a bid, the bid amount is taken from the owner and a receipt is issued.
The receipt records the proportion of the bid compared to effective total issuance at the time
of consolidation. The receipt has two independent elements: a “main” non-fungible receipt and
a second set of fungible “counterpart” tokens. The accounting functionality of the latter must
be provided through the Counterpart trait item. The main non-fungible receipt may have its
owner transferred through the pallet’s implementation of nonfungible::Transfer.
A later thaw function may be called in order to reduce the recorded proportion or entirely
remove the receipt in return for the appropriate proportion of the effective total issuance.
This may happen no earlier than queue’s period after the point at which the receipt was issued.
The call must be made by the owner of both the “main” non-fungible receipt and the appropriate
amount of counterpart tokens.
NoCounterpart may be provided as an implementation for the counterpart token system in which
case they are completely disregarded from the thawing logic.
Terms
- Effective total issuance: The total issuance of balances in the system, equal to the active
issuance plus the value of all outstanding receipts, less
IgnoredIssuance.
Re-exports
pub use pallet::*;
Modules
- The
palletmodule in each FRAME pallet hosts the most important items needed to construct this pallet. - Autogenerated weights for pallet_nis