Now that Constellation has published the new rewards distribution my proposal makes no sense any longer:
However I would like to share with you what I wanted to propose. My idea was intended to keep a similar approach as the once already existing, not doing a huge change into the rewards, keeping all the reward pools and affecting as less as possible holders.
| title |
description |
author |
discussions-to |
status |
type |
category |
created |
requires |
| Rewards % redistribution 202305 |
Proposal for a redistribution of the percentage of rewards assigned to each reward pool on the benefit of nodes pools (mainnet and testnet) |
Serg |
Idea about redistributing the rewards - #2 by andrewseer |
draft |
Standard |
Core |
2023-05-20 |
N/A |
Abstract
This proposal aims to have fair redistribution of the rewards among the different reward pools by increasing the percentage of rewards assigned to the node rewards pools (mainnet and testnet).
Motivation
The current reward distribution among the pools is as follows:
| Rewards Pool |
Ratio |
| Soft Nodes |
20 % |
| Data Pool |
65 % |
| Stardust Tax |
10 % |
| Validator nodes (mainnet) |
4 % |
| Testnet nodes |
1 % |
| Total |
100 % |
This distribution considers Data Pool with a huge weight as it is mean to be a finite pool of rewards used to create initial use cases so other businesses can follow that lead and see the power of using cryptocurrency incentives with real world applications for data and utility. However, the current usage of the full amount assigned to this pool is to reward DTM and DTM NFT owners. It is worth it to mention that ~85% of these rewards go to an undisclosed company who bought 3.000 DTM devices. This company accumulated as rewards ~35M $DAG in 2 months and a half, which is the equivalent of 29 months of validator rewards. This vast accumulation of $DAG by a single entity could pose a risk to the ecosystem…
Stardust tax might be considered fair from a global point of view, especially considering that these $DAG are intended to bring nothing else than value to the ecosystem. However, as its wallets have more than 80M $DAG, it is considered a considerable amount for starting to support projects which might be impactful for HGTP and its ecosystem.
Nodes are the core of the network; they establish the foundation of the network infrastructure. The nodes run the Tessellation protocol, securize the network, provide throughput, and notarize and validate the data. They are the base layer and without them nothing could be build or run.
Operating a node involves hardware (or virtual hardware) costs, maintenance cost, and special dedication of the node operator to maintain the node up and running offering the best service and performance possible. This is particularly evident in testnet, where operators must commit additional effort to perform specific testing of several beta versions before they are included in an official release.
The first epoch will end at epochProgress 1.296.000, and it is estimated this event will take place the 5th of June of 2023. This means that tokens minted will be reduced from 658,43621389 per snapshot to 329,21810694 per snapshot, resulting in a 50% reduction in the tokens minted per snapshot.
Considering the cost and effort associated with node operation, the reduction in rewards may discourage continued operation, thereby endangering the entire network. Given the significance of the nodes, this HIP proposes a redistribution of rewards in the most equitable manner, minimizing the impact on token holders, while preserving as much of the original approach as possible. The distriution proposed is as follows:
| Rewards Pool |
Ratio |
| Soft Nodes |
20 % |
| Data Pool |
50 % |
| Stardust Tax |
5 % |
| Validator nodes (mainnet) |
19 % |
| Testnet nodes |
6 % |
| Total |
100 % |
This distribution would only be valid until PRO score is released and network is open for any node operator with 250.000 $DAG collateral. Once this happen, there might be potentially thousands of nodes supporting the network, and the distribution shall be reviewed.
Specification
Currently org/tessellation/config/types.scala includes:
case class ProgramsDistributionConfig( weights: Map[Address, Weight] = Map( Address("DAGSTARDUSTCOLLECTIVEHZOIPHXZUBFGNXWJETZVSPAPAHMLXS") -> Weight(5L), // stardust tax primary Address("DAG8VT7bxjs1XXBAzJGYJDaeyNxuThikHeUTp9XY") -> Weight(5L), // stardust tax secondary Address("DAG77VVVRvdZiYxZ2hCtkHz68h85ApT5b2xzdTkn") -> Weight(20L), // soft staking Address("DAG0qE5tkz6cMUD5M2dkqgfV4TQCzUUdAP5MFM9P") -> Weight(1L), // testnet Address("DAG3RXBWBJq1Bf38rawASakLHKYMbRhsDckaGvGu") -> Weight(65L) // data pool ), remainingWeight: Weight = Weight(4L) // facilitators )
and it shall be modefiied to:
case class ProgramsDistributionConfig( weights: Map[Address, Weight] = Map( Address("DAGSTARDUSTCOLLECTIVEHZOIPHXZUBFGNXWJETZVSPAPAHMLXS") -> Weight(3L), // stardust tax primary Address("DAG8VT7bxjs1XXBAzJGYJDaeyNxuThikHeUTp9XY") -> Weight(2L), // stardust tax secondary Address("DAG77VVVRvdZiYxZ2hCtkHz68h85ApT5b2xzdTkn") -> Weight(20L), // soft staking Address("DAG0qE5tkz6cMUD5M2dkqgfV4TQCzUUdAP5MFM9P") -> Weight(6L), // testnet Address("DAG3RXBWBJq1Bf38rawASakLHKYMbRhsDckaGvGu") -> Weight(50L) // data pool ), remainingWeight: Weight = Weight(19L) // facilitators )
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Rationale
Performing only the change of the values has the minimum impact possible in the rest of the code.
Backwards Compatibility
No backward compatibility issues found.
Test Cases
Test cases still need to be implemented, but the core function has not been changed and it has been well tested by the protocol team.
Security Considerations
This change does not bring any additional security risks or concerns.
Copyright
Copyright and related rights Serg 2023.
