You are viewing a single comment's thread from:
RE: Symbiont{s} | Steem DAO | Wallet Development Update #1
Instead, we adopted a more deterministic approach by hard-coding the ID of the return proposal and programmatically flagging any proposal that receives greater support.
Wouldn't it be better to do it the way the chain itself does it, by using the payouts and the available budget? There's nothing magical about "the" return proposal. Alternatively, if you do want to flag return proposals, couldn't you just detect that they're paying to @steem.dao rather than hardcoding a specific proposal number?
Hi, @danmaruschak,
The most appropriate long-term solution is to implement a permanent chain-level pivot that stakeholders can vote on. Unlike ordinary proposals, this pivot must not be subject to removal by individual users. Instead, it should be embedded at the protocol level to ensure continuity and safeguard against governance manipulation.
Since such a native mechanism is not currently available, the community has reached consensus to designate a specific proposal to serve as the de facto return proposal for the next decade. To enhance resilience, a secondary backup proposal has also been created. It will serve as a contingency in the event that the primary proposal's owner becomes compromised or acts counter to stakeholder interests. This interim arrangement provides a reliable and transparent fallback, maintaining operational safety until a native, immutable return pivot can be formally integrated into the protocol.
Refund proposals (also known as return proposals) are automatically flagged with the refund flag when the account @steem.dao is set as the beneficiary, just as you suggested. The hardcoded aspect lies in identifying which proposal is currently being funded. While we could have opted for a dynamic calculation approach instead of hard-coding the proposal ID, we ultimately determined that the performance overhead made it an unattractive solution.
However, this is not a perfect solution. For example, a proposal that has not yet started but ranks above the return proposal in terms of votes may be incorrectly flagged as funded. Another potential issue occurs when a large number of proposals are ranked above the return proposal. Some of these may not receive funding due to budget constraints, yet they will still be flagged as funded simply because they appear above the return proposal. As in most cases where no native solution exists, it ultimately comes down to weighing the advantages against the disadvantages.
Thank you,
I'm not really following what makes this a performance-constrained problem. Don't you already have an ordered list of proposals in terms of voting support, whether or not each one is past its start date and before its end date, what its payment is, and what the total budget is? I assume you'd need that info just for the basic display. Can't you then just iterate through that short list until you figure out which one exhausts the budget (usually a return proposal)?
Hi, @danmaruschak,
If the calculation is performed client-side, we must ensure that the page is not slow and loads within an acceptable timeframe across all types of devices. On the other hand, performing the calculation server-side also presents scalability challenges, as having thousands of users accessing the proposals page simultaneously would place significant load on the server infrastructure.
The calculation logic itself is relatively straightforward. Each proposal whose daily payout is less than or equal to the available daily DAO budget is marked as funded. As proposals are processed in descending order of vote ranking, the cumulative sum of daily payouts is tracked. Once this cumulative total exceeds the DAO's daily budget, all remaining proposals are no longer flagged as funded.
We will proceed with testing this approach further, and if any noticeable decline in user experience is observed, it should be relatively easy to revert. Given the points outlined in the post, this remains our preferred approach provided it performs well in practice, as we generally dislike implementations that require additional maintenance.
Thank you,