Balance Transfer - Any Proxy - adding a limit / threshold

[VinceCorsica]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

The ability to transfer funds is associated to the Any Proxy.
However there is no limit outside of the available balance to transfer all funds.
This prevents to delegate with granularity / guardrails
And in case of security events it exposes all funds

Request

Modifying / Complementing current pallet in order to have a proxy which permit to define a max amount up to transfer can be done.

This limit will be allowed for a specific period of time which can be set (like for the delayed proxy)

Solution

No response

Are you willing to help with this request?

Yes!

[ggwpez]

We can think here about having a limit of a proxy for the amounts of funds that it can transfer. The limit should have:

• optional duration in blocks for which it is valid, after that duration expired the proxy will not be able to transfer anymore
• total amount of balance that can be transferred out during this duration

For example: Alice authorized proxy Bob to be able to transfer up to 1000 DOT over the next week.
Also possible: Alice authorized proxy Bob to be able to transfer up to 1000 DOT. No time limitation.

[bkchr]

We can think here about having a limit of a proxy for the amounts of funds that it can transfer. The limit should have:

* optional duration in blocks for which it is valid, after that duration expired the proxy will not be able to transfer anymore

* total amount of balance that can be transferred out during this duration

This is not really important here, because this logic needs to be implemented downstream in the real runtime.

I see the following two ways to implement this:

1. Introduce a new pallet that handles the logic. The AnyWithLimit proxy would only be allowed to call the special dispatch function in this new pallet. This dispatch would get a call that should be dispatched. The pallet would need to ensure that the rules are applied to the call and it being rejected if not following the rules.

2. The proxy pallet is changed to store extra data along side a ProxyType. This data would need to be passed to filter as a mutable reference. The data, like the ProxyType should be passed to the runtime via the Config trait. In this data we would for example then store the limit etc. The filter implementation would then take that these limits are respected.

[Nathy-bajo]

@bkchr Let me give it a shot, assign me please.

[bkchr]

One thing I forgot to mention, the extra data in 2 would need to request some extra deposit fee (depending on the size).

[kianenigma]

In AHM we could add one new proxy type that delegates the logic to a smart contract, which can implement all sorts of proxy types.

This won't play well with the proxy replication methods though.

[bkchr]

In AHM we could add one new proxy type that delegates the logic to a smart contract, which can implement all sorts of proxy types.

Yeah, but this would also only work on AHM and is basically ETH account abstractions.