Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

pallet-treasury: Ensure we respect max_amount for spend across batch calls #13468

Merged

Conversation

bkchr
Copy link
Member

@bkchr bkchr commented Feb 24, 2023

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

…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
@bkchr bkchr added A0-please_review Pull request needs code review. D9-needsaudit 👮 PR contains changes to fund-managing logic that should be properly reviewed and externally audited B1-note_worthy Changes should be noted in the release notes T1-runtime This PR/Issue is related to the topic “runtime”. C1-low PR touches the given topic and has a low impact on builders. labels Feb 24, 2023

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2443849

Copy link
Member

@ggwpez ggwpez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one idea.

@gavofyork
Copy link
Member

bot merge

@paritytech-processbot paritytech-processbot bot merged commit 2957120 into master Feb 27, 2023
@paritytech-processbot paritytech-processbot bot deleted the bkchr-treasury-ensure-max-amount-in-batch branch February 27, 2023 17:49
@jakoblell jakoblell added D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited and removed D9-needsaudit 👮 PR contains changes to fund-managing logic that should be properly reviewed and externally audited labels Mar 22, 2023
ukint-vs pushed a commit to gear-tech/substrate that referenced this pull request Apr 10, 2023

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…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 pull request 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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B1-note_worthy Changes should be noted in the release notes C1-low PR touches the given topic and has a low impact on builders. D1-audited 👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited T1-runtime This PR/Issue is related to the topic “runtime”.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Batch calls can be used to circumvent the limits of spend tracks
5 participants