As part of Mainnet GA, IoTeX is proud to announce Native Staking v2, a new transaction-based staking design that will greatly improve the scalability, security, and flexibility of the IoTeX Network!

Background

A core part of decentralized governance in the IoTeX Network is staking, where token holders deposit (“stake”) IOTX to facilitate network operations (e.g., consensus) and governance. By staking, token holders enhance the security of the IoTeX Network and earn IOTX rewards in return. IoTeX currently utilizes smart contracts to manage staking operations – every staking-related action (i.e., new stake, re-stake, un-stake, withdraw) requires a smart contract call, which limits scalability and flexibility.

Native Staking v2: Design Overview

After months of research, the IoTeX Foundation has developed Native Staking v2, a transaction-based staking mechanism that is more scalable, secure, and flexible. In the table below, we compare the designs of the legacy staking mechanisms (i.e., Native Staking v1) and the new Native Staking v2:

a) Implementation

nsv2 is a new protocol that decodes voting information sent via transaction payloads. Users can make new votes or update existing votes simply by sending a native transaction (example structure below) to a defined endpoint. No more costly and time-consuming smart contract calls!

voteBucket {Voter, Delegate, Amount, Duration, Auto-Stake, Self-Stake}

b) Bonus votes from staking duration

In nsv1, bonus votes from staking durations “decay” over time, which adds computational overhead to the blockchain and is not scalable. nsv2 removes the concept of “decay” — a voter’s bonus votes remain the same throughout the defined staking period. See the “Voting Power” section below for more details.

c) Bonus votes from self-staking

To encourage more new Delegates and increase the security of the network, each Delegate will specify a bucket as their “master bucket” and will receive an extra 6% bonus votes on any IOTX auto-staked in this bucket for more than three months. In the future, this master bucket may be eligible for slashing (coming later in 2020). See the “Voting Power” section below for more details.

d) Transfer buckets to another address

Voters can now transfer existing buckets to another address (as well as add tokens to an existing bucket), providing flexibility for users and also providing the foundation for innovative bucket lending/borrowing use cases.

e) Register on behalf of a Delegate

Register a new Delegate on behalf of another user. This was built primarily to manage the migration of Delegate profiles (currently registered on Ethereum) to the IoTeX Mainnet.

Voting Power - Calculation

“Voting power” is a function of several variables, including # of IOTX staked, stake duration, auto-stake bonus, and self-stake bonus. Voters can create multiple buckets with different variable choices to build a diverse voting portfolio. The total votes of a bucket with ‘X’ native IOTX staked for ‘d’ days, where ‘a’ indicates auto-stake is on/off and ‘s’ indicates self-staking bucket, is summarized by the formulas below:

T — Time (i.e., staking duration)

This remains unchanged. ‘b’ is a log factor, which is currently set to 1.2.

A — Auto-staking

When a user enables auto-staking, their votes are boosted by a factor of m[0,1)

S — Self-staking

When a Delegate auto-stakes IOTX for >3 months, their votes are boosted by a factor of n[0,1)

Voting Power - Results & Examples

A bucket auto-staked for X days yields the same amount of bonus votes until auto-stake is turned off. After X days, the voter can choose to disable auto-stake (or not). Once auto-stake is disabled, the bucket’s bonus votes will remain the same until X days later when the bonus votes go to zero. Voters that stake for X days with auto-staking enabled have exactly the same voting power as voters who stake for 2X days with auto-stake disabled. This occurs when m = 1 in the auto-staking function A(a) = 1 + a*m. The absolute difference in voting power for enabling/disabling auto-stake is a fixed value when staking for the same number of days (~38,000 votes per million tokens). The parameter ‘n’ in the self-staking function S(s) = 1 + s*n is nested in the outermost layer, meaning it has a direct correlation with the voting power associated with a Delegate’s master bucket.

Tools & References

nsv2 utilizes a new protobuf definition for staking/registration messages, as well as a new protocol to handle staking/registration operations.