There has been discussion in the community work group thread and the telegram channel regarding this topic.
The Boosting Threshold Score only prices collective attention according to the demand for the Dao’s attention and fails to consider its supply
The exponential curve is only dependent on the number of already-boosted proposals: the more proposals in the boosted set, the harder it is to add to the set. But this fails to take into account that a Dao’s bandwidth will vary over time. It also assumes that proposals will require an equal amount of time to evaluate on average, thus failing to capture the fact that bandwidth requirements will vary across proposals.
In other words, the BTS equation assumes a perfectly inelastic supply of collective attention– defined as the average capacity for due diligence of a single REP holder.
Here it is for reference:
Since the boosting threshold does not respond to changes in the DAOs bandwidth or the bandwidth requirements of boosted proposals, there is no way to know if the DAO is optimizing its attention allocation: at any given time the DAO could be over-exerting its collective attention by boosting too many proposals (or a few heavy duty ones) or under-utilizing it by boosting too few (or many trivial ones).
Suggestions So Far
To address this issue, I’ve suggested that we add a factor to the BTS equation that allows the curve to shift right or left depending on the Dao’s bandwidth. This would allow the boosting threshold to respond to the supply of a Dao’s collective attention in addition to the demand for it.
One way to gage bandwidth is with voter participation rates, such as the moving average of % of total REP staked towards the last 10 boosted proposals.
- @matan has pointed out that voter participation doesn’t necessarily reflect attention supply since people could abstain on proposals that are outside of their area of interest or expertise
- @ezra_w added that people might abstain when they see that a vote is already going in the direction they desired
Ezra suggested that we use web traffic stats to gage supply of collective attention.
- My concern here is that it relies on off-chain measures that can be manipulated and require some trusted server/admin to report. Curious to hear workarounds.
Another approach is to target some average “boosted proposal success rate” by adding a difficulty factor that shifts the curve based on the variance from the target.
Difficulty factor, d = actual_success_rate – targeted_success_rate. When d < 0 the BTS curve shifts to the left, making it easier to pass proposals, and vice versa.
Matan has pointed out that this might not actually matter since supply of collective attention will vary a lot less than the demand for it.