This proposal addendum seeks to establish a minimum allocation threshold of 5% of the total DAO-allocated Cubes for any single BUILD project. Any project receiving less than this threshold will not be allocated Cubes by the stake.link DAO; instead, their Cubes will be proportionally redistributed to the other projects that meet or exceed the threshold.
Abstract
In the current BUILD Cubes distribution model, it is possible for the stake.link DAO’s collective Cubes to be allocated across numerous projects, including those receiving very minor percentages of the total vote. Such fragmented allocations often result in “dust” rewards for individual users (i.e., economically insignificant amounts of tokens), leading to poor capital efficiency and administrative overhead. This proposal introduces a 5% minimum allocation threshold to ensure that the DAO’s Cubes are strategically concentrated in projects where they can have a meaningful impact and generate substantive rewards for eligible participants.
Motivation
The primary motivations for implementing a minimum allocation threshold are:
Maximize Reward Impact: By consolidating allocations, we ensure that eligible $SDL stakers and $stLINK holders receive more substantial, economically meaningful reward distributions rather than trivial “dust” amounts that may not even cover gas fees.
Improve Operational Efficiency: Reducing the number of unique projects requiring tracking, calculation, and distribution for minimal allocations streamlines the claiming process for the protocol and its users.
Reflect Strong Conviction: A threshold signals the DAO’s conviction, ensuring resources are not spread too thinly across projects that garner minimal support.
Expected Outcome
This mechanism will result in a more impactful and economically efficient distribution of the stake.link DAO’s BUILD Cubes. Participants will receive more substantial rewards from fewer, higher-conviction projects, reducing the likelihood of “dust” allocations and streamlining the claiming process.
Although it would be a good narrative on paper to support all projects, to show alignement with build rewards, we have to be pragmatic here and side with the user :
Having a rough estimate of how many cubes will have and some quick maths, even a nicely sized wallet of 1000 stlink would have less than 10$ for projects below 5 %.
In support on the team sanity and overal operational efficiency i strongly support this proposal.
Violates trust with the community members and stakeholders.
People vote and in real time can visualize the allotment for that particular token. These items are vehicles for possible exponential growth. 1% position could grow 10 to 100 fold in this class of items and become 10% or 99% of one’s portfolio of different crypto companies.
Vehemently against this.
It’s also ridiculous that this SLURP comes out weeks after SLURP45 was submitted.
Because people can see the vote in real time and mathematically calculate how much they would receive, the “dust” argument does not hold muster. If people want to vote for an item and receive dust, then that is their prerogative. And the amount they would retrieve is transparent.
This is the opposite of decentralized, permission-less, sovereign—- it centralizes planning by you, it crafts a permissioned scenario where only you have permission to allocate members’ vote, and usurps sovereignty from every single community member.
This goes against the tenet of crypto participation.
Let me ask this question. Does the council and nops also have a vote to allocate their preferences? That would cause significant dimunition of any of our votes.
If so, it would be nice to know what the council and nops allocation would be.
@candide it would be nice if you can write your thoughts down as a single reply and not spam three consecutive ones. Also I don’t think this is the place to lecture about the ethos of decentralization, we are here for decision making. You clearly misunderstand the way the protocol and the governance works. The council ratifies what the community wants, they have no further say in the process; including node operators.