🥩Staking
Aligning incentives for the long run
Introduction
Staking, or bonding, is the act of locking up funds under some terms so that they are not transferable and otherwise not entirely usable as they otherwise would be. The terms, referred to as unstaking terms describe the circumstances under which the funds may begin to cease being staked. This may involve who is able to initiate this, at what time and whether there is a possible delay from initiation to completion. This time lag is referred to as the unstaking period. Another critical term will also be whether and some part, possibly all of, the funds may be burned. This is referred to as slashing.
Staking is used for two purposes to serve the system as a whole by providing more robust incentives for socially optimal conduct in some role that impacts the overall success of the system.
Exposure: By requiring that someone who occupies a role that impacts the value of the system has exposure to that value in their portfolio. For this requirement to be effective, this exposure should not be hedgeable, and it is generally assumed that markets for this are missing. It is also assumed that any harm or benefit that results from the actions of the actor will capitalize in the value of the platform, and thus be partially reflected in the value of the stake. This should in total discourage harmful conduct and encourage beneficial conduct.
Punishment: In cases where it is possible to, if only imperfectly, have the system adjudicate whether an actor has acted harmfully, the ability to slash funds as a result of such detection can generate very strong incentives for pro-social behavior. The adjudication may be purely cryptographic, or it may require some level of social consensus. In either case, to the extent that it reliably can detect failure - that is avoiding false positives and negatives, it is a very cost-effective means of generating incentives compared to the first approach. It's cheaper because it allows for less capital to be locked for a given level of deterrence effect.
Locks
A lock is limitation applied to how funds can be used in an account, primarily to enable staking, and it is defined by
a lock ID, unique across all locks on that account
an amount , which is a quantity of tokens, and
a type, of which there are a finite number
These are the different types of locks that currently exist, each has a distinct ID, which means it is very easy to work at what sort of staking is going on funded by a given account.
Vesting
Vesting only occurs on accounts which existed in the genesis block, and it occurs using a linear curve on the amount of funds encumbered by a vesting lock. Is implemented using the pallet_vesting pallet described below.
Binding
When initiating staking of some kind, it is very often - although not always, in the context of inhabiting some other kind of role, like being a member. This means that the initiating the staking effectively requires proving two things at the same time
You occupy the role you claim, by virtue of controlling the role account.
You control the funds living on the staking account in question.
Both are achieved by signing with for some account and in general they will not be the same. As a result, it is required that a user connects - or binds, a given account which holds funds for the purposes of staking, to their membership, in advance of being able to use that account for staking as that member. This binding is a two step process, per account, where the first step is to turn the account into a staking candidate by issuing a request to bind to a given member by signing via this account, and the second step is for the member to accept this candidate, using the controller account for that membership.
Rivalry
In what follows we attempt to briefly summarizes the what locks exist, their purposes and in what combinations are allowed on the same account. The reason some combinations of locks are acceptable, while others are not, stems from whether reusing capital across the two purposes of the locks is compatible with these purposes. Allowing capital to be reused has the benefit of more efficient use of capital for a single actor, reducing the barrier to getting involved in multiple activities simultaneously. At the same time, it may in some cases not be acceptable, if it ends up reducing the effective bond needed to generate good incentives for some form of participation. The model for reuse of accounts is quite simple. There is a finite set of lock types in the system, and they are partitioned into two subsets: rivalrous and non-rivalrous locks.
No lock of a given type can be applied more than once to a given account.
Non-rivalrous locks can be combined with any other lock of any kind.
Rivalrous locks can only be combined with other non-rivalrous locks.
| Lock | Binding | ID | Rivalrous |
|---|---|---|---|
Voting | No | *b"voting " | No |
Vesting | No** | *b"vesting " | No |
Invitation | No* | *b"invitemb" | No |
Bound Staking Account | Yes | *b"stakcand" | No |
Council Candidate Staking | Yes | *b"candidac" | Yes |
Council Member Staking | Yes | *b"councilo" | Yes |
Validation & Nomination Staking | No | *b"staking " | Yes |
Proposals Staking | Yes | *b"proposal" | Yes |
Storage WG Staking | Yes | *b"wg-storg" | Yes |
Content Directory WG Staking | Yes | *b"wg-contt" | Yes |
Forum WG Staking | Yes | *b"wg-forum" | Yes |
Membership WG Staking | Yes | *b"wg-membr" | Yes |
Distributor WG Staking | Yes | *b"wg-distr" | Yes |
Builders WG Staking | Yes | *b"wg-opera" | Yes |
Gateway WG Staking | Yes | *b"wg-gatew" | Yes |
HR WG Staking | Yes | *b"wg-operb" | Yes |
Marketing WG Staking | Yes | *b"wg-operg" | Yes |
Bounty Entry Staking | Yes | *b"bounty " | Yes |
* It is not possible to initiation the invitation lock, it is automatically applied when a new member is invited on, hence the question of whether binding is required for applying the lock does not even apply. ** Vesting is only going to be setup for accounts originating from mainnet genesis block, and so by definition no binding would be needed for that.
Balances
The total balance of an account is the total number of tokens in the account, and it can be split into two distinct parts the free balance and the reserved balance, where the latter refers to reservations in the sense described in #reservation. The naming of the former is quite misleading, it is inherited from Substrate terminology, as it does not refer to funds that freely can be used for any purpose. The second constraint which ultimately still may encumber the free balance are locks, as described in Locks. The key concept to understand is that locks "stack", hence the net effect of all locks on an account is simply equivalent to the lock for the largest amount. Hence for example, if you have a free balance of 10, and locks of size 7, 6 and 2, then they net out to a locking effect of 7, which means that only 10 - 7 = 3 of the tokens actually are entirely unencumbered, also called usable. We refer to this balance as the usable balance. We can thus summarise as follows
total_balance = free_balance + reserved_balance
usable_balance = max(free_balance - max{lock_1, ..., lock_N, 0}, 0)
where lock_i is the lock amount of the i'th lock.
<add image here of how locks and reservations interact to influence the free, reserved, total and usable balance>
The Invitation Lock Exception
The precise constraint for what invitation locks allow is as follows: if the transaction otherwise would have succeeded if the invitation lock was not present, and it is not among one of the cases below, then the transaction will still succeed regardless of the lock amount:
Any transaction with non-zero tip.
Balance transfers.
Bidding on an NFT.
Buying an NFT now.
Accepting an offer for an NFT which requires payment.
Purchase creator tokens in a sale or from AMM.
Contribute funds to a bounty.
Paying for a channel swap.
Sending funds to the council or working group budget.
Gifting a membership.
Buying a membership.
This upside of this exception to how locks are normally influencing funds available to fund transactions is that despite the membership controller account possibly having a usable balance which is too low, funds encumbered by this lock can be deployed for the relevant purposes of a transaction, which on many occasions may make the difference, certainly for a totally new user.
Slashing
Slashing is the act of reducing the balance of an account by some amount, and also reducing the size of the lock which represents the use case under which the slashing occurs.
State bloat
Some modules such as forum and working group allows user to call extrinsics that allows them to occupy storage. This can be a problem since some malicious users could use this to fill up the storage, either taking all the allotted space for that given storage map or claim storage space until no single node has enough storage. Furthermore, there is no incentive even for regular users to cleanup their storage use.
That's why when a user can use up storage on top of the transaction fee we require either a deposit or additional stake.
When no longer using up the storage the stake is released or the deposit is paid off.
While staking is easier to implement when we are already requiring an stake account, a deposit allows to incentivize other users cleaning up by paying the deposit to them instead of the original person making the deposit.
As it stands now the modules require a deposit to prevent the state bloat are:
Forum pallet
Pallet Discussion
Blog
The pallets requiring a stake to prevent state bloat are:
Working Group
Membership
Last updated