#2151 Testing batch calls within OpenGov Treasury Spend tracks.
Hi All,
Two referenda were opened to test the use of batch calls as applied to Open Gov treasury spends. The first was referenda 58, this was issued on the Big Tipper track which has a spend limit of 33 KSM. The referendum tested two individual spends (8 & 2 KSM) both of which were within the maximum spend of the track and whose total spend was also within the tracks limits. The second was referenda 62, this was executed on the Small Tipper track which has a spend limit of 8 KSM. This referendum was tested using two individual spends each within the maximum limit of the track (8 KSM) and with a total (8+8 KSM) exceeding the track's limit.
Both referenda passed and parties received funding. The passing of these referenda provides us with some information:
The good
We (the community) now have added flexibility in the way that we can propose spends.
- We can for instance, proportion tips with a finder's fee
- Group spends together to save on preimage and deposit fees *
- Use this as a mechanism to directly allocate project funding to the respective major parties
* - There is an approval risk when grouping spend proposals together.
The cautious With the good comes some caution, as seen with referendum 62 we can circumvent the total spend limits of a track, there by achieving the benefits of quicker approval times with lower thresholds.
I believe that the good outweighs the bad and that the community can be that deciding factor whether referenda like 62 are allowed to pass or rejected due to perceived abuse. It might also be a candidate for a bug fix. What do you think?
I thank you all for participating in this test, thought it was not exhaustive the information was imo useful.
Regards,
Show More
Overall 50 % of users are feeling optimistic. The text suggests implementing batch calls while monitoring individual transactions to ensure they stay within a set budget. The author agrees with this approach and emphasizes the importance of being cautious until further measures are established. This solution is seen as the best way forward for now, ensuring financial responsibility during voting processes.
Overall 50 % of users are feeling against it. The experiment run by @paradox has been deemed very bad due to serious consequences such as vote snipping, short confirmation times, and nullifying tracks' spending limits. The ideal solution would be allowing batch calls but ensuring individual call amounts are within the track's spending limit.
AI-generated from comments
Thanks for running this experiment @paradox!
IMO I'd upgrade cautious to very bad. Circumventing the track limits like this can have serious consequences, especially if we consider the short confirmation times of tracks likes Small Tipper, the potential for vote snipping and the fact that most people read only the description and don't check the actual call. It basically nullifies the tracks' spending limits. This definitely qualifies as a bug for me.
Allowing batch calls is definitely good, but if I had to choose between allowing batch calls with this possibility or disallowing them entirely, I'd choose the latter without second thought. Obviously the ideal solution would be to allow for batch calls but check the individual calls and ensure the amount of the total spend is within the track's spending limit.
Obviously the ideal solution would be to allow for batch calls but check the individual calls and ensure the amount of the total spend is within the track's spending limit.
I agree that this is the best way forward, until a fix or safety measure is in place we (the voters) need to be vigilant.
Discover similar proposals
