NIS Module

Provides a non-interactive variant of staking.

License: Apache-2.0

lib.rs:

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.