Joystream Handbook
Search…
⌃K
🥩

Accounts & Staking

Staking is the primary mechanism by which impact on the trajectory of the system is allocated across actors.

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.

Accounts

wip ****

Module Accounts

wip : dynamic and static

Staking

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.
  1. 1.
    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.
  2. 2.
    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.

Transactions

wip
  • fees
  • weight
  • tips: where they go
  • locks and balances

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.
Lock
Description
Voting
wip
Vesting
wip
Invitation
wip
Bound Staking Account
wip
Council Candidate Staking
wip
Council Member Staking
wip
Validation & Nomination Staking
wip
Proposals Staking
wip
Storage WG Staking
wip
Content Directory WG Staking
wip
Forum WG Staking
wip
Membership WG Staking
wip
Distributor WG Staking
wip
Builders WG Staking
wip
Gateway WG Staking
wip
HR WG Staking
wip
Marketing WG Staking
wip
Bounty Entry Staking
wip

Vesting

WIP

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
  1. 1.
    You occupy the role you claim, by virtue of controlling the role account.
  2. 2.
    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.

Reservation

WIP Only used in vesting

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

As you can read in the Invitations section of the membership subsystem article, the purpose of the invitation lock is to onboard a new member, for example a creator, onto the system. This means they have to be granted some minimal quantity of initial funds that allow them to engage with the system in a very basic way. Typically, this will be done by applications that apply their own Sybill resistance check. Since all such checks are imperfect, the invitation lock is applied with an amount matching the initial quantity of funds credited, and this lock prevents the user from simply cashing out by exchanging the tokens to some other account for some sidepayment. At the same time, the lock also allows consuming the funds for a wide range of transactions, for example such as creating a channel or uploading a video. Some transactions are explicitly excluded because they inherently involve transferring funds to some new stakeholder, for example when bidding on an NFT or funding a bounty.
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:
  1. 1.
    Any transaction with non-zero tip.
  2. 2.
    Balance transfers.
  3. 3.
    Bidding on an NFT.
  4. 4.
    Buying an NFT now.
  5. 5.
    Accepting an offer for an NFT which requires payment.
  6. 6.
    Purchase creator tokens in a sale or from AMM.
  7. 7.
    Contribute funds to a bounty.
  8. 8.
    Paying for a channel swap.
  9. 9.
    Sending funds to the council or working group budget.
  10. 10.
    Gifting a membership.
  11. 11.
    Buying a membership.
TODO: Add links to explicit extrinsics in other articles later!
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. TODO: add example later of how this explicitly helps

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.

WIP: 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