Idea about redistributing the rewards

  1. Validator and test net nodes should get more. 2) There shouldn’t be a huge gap between soft node rewards and DTM rewards. I don’t really mind missing out on soft node rewards if that’s required for the project to succeed, but it feels very unfair that DOR miners receive so much rewards. It’s unfair. Soft node holders have been lied to for a long time. Those who are still sticking around shouldn’t be treated unfairly like this. So many promises about being able to quickly run Mainnet nodes since 2021 and big promises of huge rewards. I can live with all those lies and delays but NOT if soft node holders are treated unfairly compared to DOR miners. Do DOR miners add any value to the network rn? Or are they just a way of getting revenue for Constellation? I argue it’s the latter.

Anyway, I do agree that Validator and testnet nodes should receive more rewards and should def not run nodes at a loss. I support this!


I agree that the halving could negatively affect the node operators who have been diligently supporting both Testnet and Mainnet. Please develop a HIP @Serg . You have my thanks and support.

I totally agree with your statements.
Soft node rewards should be completely phased out, and DTM rewards and “Bounties” are ridiculous. Neither have made any significant contribution to the ecosystem.

My 2 cents

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


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).


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.


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.


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 and related rights Serg 2023.


Wonderful work, Serg. Very detailed, well-written, and it’s possible this may have helped spur some of their discussions as well. :+1:

1 Like