Add Recurring Payments to the Treasury pallet

[rrtti]

Add a call that sets up in motion repeating payments following certain conditions. The treasury would keep funding it according to the budget until there was a motion to cancel it. This could potentially be used on social contract designs for maintaining services in Kusama.

The call would include:

• a Claimer address, authorized by the motion to claim the amount;
• an amount to be paid each TimeSlot;
• a TimeSlot, defined as the block number/s in which the claimer is authorized to get the amount,
• an ExpirationTime, defined as a block number after which the Claimer is not authorized to get the amount any longer for the period being and needs to wait to the next TimeSlot or open a new motion;
• a TimeCap, defined as the max time the recurring payment is set up for. After this, the Council should review via a new motion.
• a Cancellation call, defined as a motion to cancel the recurring payment.

[jam10o-new]

I'd be interested in hearing @drewstone's take on this and the overlap with the features of Edgeware's block reward payouts. Obviously there's a difference in that Edgeware does recurring payments from block reward and this would be a recurring payment from treasury.

[drewstone]

Thanks for linking @joshua-mir. This does seem similar to the existing and latest work I'm pushing for on Edgeware: hicommonwealth/edgeware-node#168. You're correct in that we are funding things through an additional block reward. The intention with the new updates is similar in that we want to have continuous funding for services/teams to work on Edgeware and this provides another outlet besides one-shot grants.

It would be interesting if there was a way to generalise the funding source so that both and many more applications become possible with these ideas, potentially enabling swapping of funding domains through democracy/council motions. For example, Edgeware currently mints new money for the Treasury every interval. This issue/proposal would take money from the Treasury. Both processes could be summed up into a general concept of where does the money come from and be agnostic beyond it fulfilling some common trait. This may be unnecessary complexity, but could also lead to greater expressiveness in the input and, say, allow governance votes to decide where he funding comes from (minting/transferring/etc).

I do like all variants of this idea and this one seems very similar. In fact, the following can be mapped together:

• TimeSlot is similar to MintingInterval
• ExpirationTime is $/infinity$ on Edgeware with the updates from the PR
• TimeCap set to null.
• Cancellation call is identical to removing that account from the recipient set.

Similarly with exp/timecap, we could batch a scheduled call at some future date to remove any account to achieve similar logic, right?

[Swader]

Just throwing my hat in the ring here as well, we've been mulling over this idea in terms of funding public infrastructure. We've been using Avado nodes to run full Kusama nodes, and those can be connected to through a load balancer, so your requests go to one of those randomly. The load balancer measures how much traffic each node got (along with some error checks IRT block number and other freshness attributed), and can distribute some funds based on those stats. If we automate monthly payments from the treasury to the pool of these nodes, we have auto-funded public distributed infrastructure as a service.

[kianenigma]

@shawntabrizi I updated the labels based on the assumption that you being assigned means this issue is verified and will (someday) be worked on. Please revert if otherwise.

[mmagician]

Hey, any updates on this issue?
I'm asking because we've got a grant team that's halfway through their project now. Their work was in response to @Swader's RFP. It would be an awesome example of a successful project if someone (likely Vedran themselves) could run the infrastructure using their Load Balancer setup & we automate the payouts from the Treasury.

Is this something that we could potentially put a bounty on, for someone to work on PR to develop this feature? I'd be happy to help with the curation if needed.

[shawntabrizi]

Infinitely reoccurring payments do not exist, but my understanding is that with the latest spend logic, you could get approved for N spends, which are spaced out every M blocks, and it would basically replicate the re-occuring spend behavior for a finite timeline.

If there are any issues with the recipients of the payments, the future pre-approved spends can be canceled.

This is all taking advantage of the valid_from parameter of spend. cc @muharem

[xlc]

It doesn't make a lot of sense of making fixed amount recurring payment of DOT due to price fluctuation.
A simple alternative is just make a big bounty, and have curator make payment periodically. It requires manual work but the DOT amount can be adjusted by conditions, which could be DOT price, KPI etc.

But with stablecoins, this will be useful.

[joepetrowski]

We can close this, solved by #1333