SIP-16: Streamr 1.0 network parameters

Background

Several network-wide parameters play a pivotal role in shaping the operations of the incentive layer. This proposal both enumerates and provides detailed explanations for these distinct parameters, proposing an initial value for each.

It's important to note that these values are subject to modification through future governance proposals should they be considered inadequate.

In the sections below, you'll find a comprehensive list of the network-wide parameters, complete with descriptions and their proposed initial values.

Please be aware that these parameter proposals pertain to the Streamr 1.0 mainnet. In upcoming testnets, there may be variations in parameters, such as a reduced slashing percentage and shorter durations, reflecting the experimental nature of the testnets.

Most important parameters

Slashing amount: 10%

Operators will lose 10% of their staked tokens if they are found to be violating protocol rules and are subsequently removed from a sponsorship. The same penalty applies if operators decide to unstake from a sponsorship prematurely.

Max queuing time when undelegating: 30 days

When a delegator chooses to initiate an undelegation process, it's important to consider that the operator might not be able to promptly return the tokens. This delay can occur if the tokens are currently staked within sponsorships.

In such cases, the request for undelegation is placed in a queue, and the operator is granted a specific timeframe, as defined by this parameter, to secure the necessary tokens for repaying the delegator.

Should the operator fail to meet this deadline, they may be unstaked by force from sponsorships in order to free up the required capital. It's worth noting that this timeframe should not be set to a duration shorter than the maximum penalty period specified below.

Maximum penalty period: 14 days

Sponsorship creators have the ability to establish a minimum duration during which operators are required to keep their tokens staked. If operators unstake during this period, their stake is slashed. This parameter sets the longest time that can be chosen as the minimum staking period.

Minimum operator’s own stake: 5%

This parameter establishes the mandatory proportion of tokens that operators must stake from their own holdings, as opposed to tokens they can accept via delegation from external sources.

This requirement serves to restrict the extent of leverage through delegation that operators can acquire. To illustrate, if this parameter is set at 5%, it implies that operators staking 5,000 DATA from their own reserves can accept up to 95,000 DATA via delegation.

Minimum stake: 5,000 DATA

A minimum stake per sponsorship is essential to guarantee that there are sufficient tokens available for rewarding flaggers and reviewers in the event of an operator being penalized for misconduct. Furthermore, the creator of the sponsorship has the option to increase the minimum stake if they choose to do so.

Minimum delegation: 100 DATA

A minimum delegation amount serves as a protective measure against spamming operators with very small delegations.

Flagging and voting

Minimum stake for voting eligibility: 0.5% of total stake in network

In order to be eligible to be selected as a reviewer on flags, an operator’s value needs to exceed a certain threshold, which is intended to be distinctly higher than the minimum stake. The purpose of this is to defend against an attacker creating a large number of operators and funding them with only the minimum stake in an attempt to control a majority vote in randomly selected sets of flag reviewers. The threshold is defined as a percentage of total stake across all operators, so that the threshold automatically scales as the network grows.

Flag stake: 500 DATA

The flag stake is the amount that operators must put at risk to flag another operator for potential protocol violations. In this case, operators are required to place 500 DATA at stake to initiate a flag against another operator if they suspect a violation. It's important to note that if the flag is ultimately deemed invalid, the operator who initiated the flag will lose the flag stake. Automated spot checks conducted by the node software flag potential violations independently, ensuring protocol integrity.

Flag reviewer reward: 20 DATA

Each reviewer who participates in the flag review process and votes for the majority result is paid a reward of 20 DATA. This reward serves as an incentive for nodes to actively engage in the validation of flagged operators within the protocol.

Flagger reward: 360 DATA

If the flag raised by an operator is deemed valid, the flagger is rewarded with 360 DATA. This reward serves as an incentive for operators to flag potential protocol violations accurately, contributing to the overall integrity and adherence to protocol rules.

Flag reviewer count: 7

The number of operators that are randomly selected to review a flag by inspecting and validating the work of the flagged operator, and then voting whether the flag was valid or not. The voting is stake-weighted.

Review period: 1 hour

The duration of time that must pass between the act of flagging and the commencement of the voting process. The node software autonomously carries out reviews and votes on flags if it is selected as a reviewer, eliminating the need for human involvement during the review and voting phases.

Voting period: 15 minutes

The duration of time allocated for reviewers to cast their votes following the review period. Similar to the review period, the voting process is entirely automated by the node software. Therefore, there is no requirement for human intervention within the specified voting period.

Flag protection period: 1 hour

If an operator is flagged and the flag is deemed invalid, they can not be flagged again for a short period. Operators are not allowed to fully unstake during an active flag. Therefore, without this protection period, an attacker could prevent an operator from ever unstaking by continuously flagging them. This protection period gives the operator a window of time during which they can unstake if they wish.

Operator value maintenance

Operator uncollected earnings limit: 5%

Operators continuously earn rewards from sponsorships on every block. For the operator’s total value to be correctly reflected on-chain, those earnings must be periodically collected to limit the error between the recorded on-chain value and the ‘real-time’ value of the operator, which constantly changes due to uncollected earnings accumulating.

Normally, the node software handles this earnings collection and maintenance of operator value automatically. The operator is responsible for ensuring that this happens by ensuring their nodes are running and the wallets of their nodes have enough MATIC to pay gas for transactions.

If the amount of uncollected earnings exceed the operator’s recorded value by more than 5%, any entity can demonstrate to the operator smart contract that the values are outside acceptable limits. The party providing such proof (a ‘fisherman’) is rewarded, and the operator who violated this margin loses a portion of their uncollected earnings. This mechanism helps maintain the accuracy and integrity of the on-chain value, protecting the interests of participants in the protocol.

Fisherman’s reward: 25%

If it is demonstrated that an operator’s uncollected earnings exceed the above margin, the ‘fisherman’ providing the proof is entitled to a share of the operator's uncollected earnings that were included in the proof.

Importantly, only the operator who violated the error margin loses a portion of their earnings. This mechanism ensures that the consequences of inactivity are borne by the responsible operator.