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,
Comments (2)
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.
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.