This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Batch calls can be used to circumvent the limits of spend tracks #13167
Labels
J2-unconfirmed
Issue might be valid, but it’s not yet known.
Comments
github-actions
bot
added
the
J2-unconfirmed
bkchr
added a commit
that referenced
this issue
Feb 24, 2023
…tch calls When calling `spend` the origin defines the `max_amount` of tokens it is allowed to spend. The problem is that someone can send a `batch(spend, spend)` to circumvent this restriction as we don't check across different calls that the `max_amount` is respected. This pull request fixes this behavior by introducing a so-called dispatch context. This dispatch context is created once per outer most `dispatch` call. For more information see the docs in this pr. The treasury then uses this dispatch context to attach information about already spent funds per `max_amount` (we assume that each origin has a different `max_amount` configured). So, a `batch(spend, spend)` is now checked to stay inside the allowed spending bounds. Fixes: #13167
paritytech-processbot bot
pushed a commit
that referenced
this issue
Feb 27, 2023
…tch calls (#13468) * `pallet-treasury`: Ensure we respect `max_amount` for spend across batch calls When calling `spend` the origin defines the `max_amount` of tokens it is allowed to spend. The problem is that someone can send a `batch(spend, spend)` to circumvent this restriction as we don't check across different calls that the `max_amount` is respected. This pull request fixes this behavior by introducing a so-called dispatch context. This dispatch context is created once per outer most `dispatch` call. For more information see the docs in this pr. The treasury then uses this dispatch context to attach information about already spent funds per `max_amount` (we assume that each origin has a different `max_amount` configured). So, a `batch(spend, spend)` is now checked to stay inside the allowed spending bounds. Fixes: #13167 * Import `Box` for wasm * FMT
ukint-vs
pushed a commit
to gear-tech/substrate
that referenced
this issue
Apr 10, 2023
…tch calls (paritytech#13468) * `pallet-treasury`: Ensure we respect `max_amount` for spend across batch calls When calling `spend` the origin defines the `max_amount` of tokens it is allowed to spend. The problem is that someone can send a `batch(spend, spend)` to circumvent this restriction as we don't check across different calls that the `max_amount` is respected. This pull request fixes this behavior by introducing a so-called dispatch context. This dispatch context is created once per outer most `dispatch` call. For more information see the docs in this pr. The treasury then uses this dispatch context to attach information about already spent funds per `max_amount` (we assume that each origin has a different `max_amount` configured). So, a `batch(spend, spend)` is now checked to stay inside the allowed spending bounds. Fixes: paritytech#13167 * Import `Box` for wasm * FMT
nathanwhit
pushed a commit
to nathanwhit/substrate
that referenced
this issue
Jul 19, 2023
…tch calls (paritytech#13468) * `pallet-treasury`: Ensure we respect `max_amount` for spend across batch calls When calling `spend` the origin defines the `max_amount` of tokens it is allowed to spend. The problem is that someone can send a `batch(spend, spend)` to circumvent this restriction as we don't check across different calls that the `max_amount` is respected. This pull request fixes this behavior by introducing a so-called dispatch context. This dispatch context is created once per outer most `dispatch` call. For more information see the docs in this pr. The treasury then uses this dispatch context to attach information about already spent funds per `max_amount` (we assume that each origin has a different `max_amount` configured). So, a `batch(spend, spend)` is now checked to stay inside the allowed spending bounds. Fixes: paritytech#13167 * Import `Box` for wasm * FMT
taqtiqa-mark
pushed a commit
to subversive-upstream/polkadot-sdk-substrate-frame-treasury
that referenced
this issue
Sep 14, 2023
…tch calls (#13468) * `pallet-treasury`: Ensure we respect `max_amount` for spend across batch calls When calling `spend` the origin defines the `max_amount` of tokens it is allowed to spend. The problem is that someone can send a `batch(spend, spend)` to circumvent this restriction as we don't check across different calls that the `max_amount` is respected. This pull request fixes this behavior by introducing a so-called dispatch context. This dispatch context is created once per outer most `dispatch` call. For more information see the docs in this pr. The treasury then uses this dispatch context to attach information about already spent funds per `max_amount` (we assume that each origin has a different `max_amount` configured). So, a `batch(spend, spend)` is now checked to stay inside the allowed spending bounds. Fixes: paritytech/substrate#13167 * Import `Box` for wasm * FMT
taqtiqa-mark
pushed a commit
to subversive-upstream/polkadot-sdk-substrate-frame-support
that referenced
this issue
Sep 14, 2023
…tch calls (#13468) * `pallet-treasury`: Ensure we respect `max_amount` for spend across batch calls When calling `spend` the origin defines the `max_amount` of tokens it is allowed to spend. The problem is that someone can send a `batch(spend, spend)` to circumvent this restriction as we don't check across different calls that the `max_amount` is respected. This pull request fixes this behavior by introducing a so-called dispatch context. This dispatch context is created once per outer most `dispatch` call. For more information see the docs in this pr. The treasury then uses this dispatch context to attach information about already spent funds per `max_amount` (we assume that each origin has a different `max_amount` configured). So, a `batch(spend, spend)` is now checked to stay inside the allowed spending bounds. Fixes: paritytech/substrate#13167 * Import `Box` for wasm * FMT
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
Good day,
With reference to the subjected matter, batch calls can be used to circumvent the total spend limits of a track. This is evident by the successful outcome of referendum 62.
I appreciate that security is the first priority and a simple fix would be to remove batch functionality for spend proposals. Batch calls do provide flexibility to spend proposals which I would like to see retained. Please give this some consideration as a solution is designed.
Please find further context here on how this was discovered.
Steps to reproduce
https://kusama.polkassembly.io/referenda/62
The text was updated successfully, but these errors were encountered: