mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-16 12:01:12 +00:00

Files

T

Muharem cb944dc548 Treasury spends various asset kinds (#1333 )

### Summary 

This PR introduces new dispatchables to the treasury pallet, allowing
spends of various asset types. The enhanced features of the treasury
pallet, in conjunction with the asset-rate pallet, are set up and
enabled for Westend and Rococo.

### Westend and Rococo runtimes.

Polkadot/Kusams/Rococo Treasury can accept proposals for `spends` of
various asset kinds by specifying the asset's location and ID.

#### Treasury Instance New Dispatchables:
- `spend(AssetKind, AssetBalance, Beneficiary, Option<ValidFrom>)` -
propose and approve a spend;
- `payout(SpendIndex)` - payout an approved spend or retry a failed
payout
- `check_payment(SpendIndex)` - check the status of a payout;
- `void_spend(SpendIndex)` - void previously approved spend;
> existing spend dispatchable renamed to spend_local

in this context, the `AssetKind` parameter contains the asset's location
and it's corresponding `asset_id`, for example:
`USDT` on `AssetHub`,
``` rust
location = MultiLocation(0, X1(Parachain(1000)))
asset_id = MultiLocation(0, X2(PalletInstance(50), GeneralIndex(1984)))
```

the `Beneficiary` parameter is a `MultiLocation` in the context of the
asset's location, for example
``` rust
// the Fellowship salary pallet's location / account
FellowshipSalaryPallet = MultiLocation(1, X2(Parachain(1001), PalletInstance(64)))
// or custom `AccountId`
Alice = MultiLocation(0, AccountId32(network: None, id: [1,...]))
```

the `AssetBalance` represents the amount of the `AssetKind` to be
transferred to the `Beneficiary`. For permission checks, the asset
amount is converted to the native amount and compared against the
maximum spendable amount determined by the commanding spend origin.

the `spend` dispatchable allows for batching spends with different
`ValidFrom` arguments, enabling milestone-based spending. If the
expectations tied to an approved spend are not met, it is possible to
void the spend later using the `void_spend` dispatchable.

Asset Rate Pallet provides the conversion rate from the `AssetKind` to
the native balance.

#### Asset Rate Instance Dispatchables:
- `create(AssetKind, Rate)` - initialize a conversion rate to the native
balance for the given asset
- `update(AssetKind, Rate)` - update the conversion rate to the native
balance for the given asset
- `remove(AssetKind)` - remove an existing conversion rate to the native
balance for the given asset

the pallet's dispatchables can be executed by the Root or Treasurer
origins.

### Treasury Pallet

Treasury Pallet can accept proposals for `spends` of various asset kinds
and pay them out through the implementation of the `Pay` trait.

New Dispatchables:
- `spend(Config::AssetKind, AssetBalance, Config::Beneficiary,
Option<ValidFrom>)` - propose and approve a spend;
- `payout(SpendIndex)` - payout an approved spend or retry a failed
payout;
- `check_payment(SpendIndex)` - check the status of a payout;
- `void_spend(SpendIndex)` - void previously approved spend;
> existing spend dispatchable renamed to spend_local

The parameters' types of the `spend` dispatchable exposed via the
pallet's `Config` and allows to propose and accept a spend of a certain
amount.

An approved spend can be claimed via the `payout` within the
`Config::SpendPeriod`. Clients provide an implementation of the `Pay`
trait which can pay an asset of the `AssetKind` to the `Beneficiary` in
`AssetBalance` units.

The implementation of the Pay trait might not have an immediate final
payment status, for example if implemented over `XCM` and the actual
transfer happens on a remote chain.

The `check_status` dispatchable can be executed to update the spend's
payment state and retry the `payout` if the payment has failed.

---------

Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
Co-authored-by: command-bot <>

2023-10-07 19:32:35 +02:00

src

Treasury spends various asset kinds (#1333 )

2023-10-07 19:32:35 +02:00

Cargo.toml

Fix build profiles (#1229 )

2023-08-29 13:39:41 +02:00

README.md

Child bounties comments (#11053 )

2022-04-16 09:55:37 +00:00

README.md

Bounties Module ( pallet-bounties )

Bounty

NOTE: This pallet is tightly coupled with pallet-treasury.

A Bounty Spending is a reward for a specified body of work - or specified set of objectives - that needs to be executed for a predefined Treasury amount to be paid out. A curator is assigned after the bounty is approved and funded by Council, to be delegated with the responsibility of assigning a payout address once the specified set of objectives is completed.

After the Council has activated a bounty, it delegates the work that requires expertise to a curator in exchange of a deposit. Once the curator accepts the bounty, they get to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address, the curator fee and the return of the curator deposit. The delay allows for intervention through regular democracy. The Council gets to unassign the curator, resulting in a new curator election. The Council also gets to cancel the bounty if deemed necessary before assigning a curator or once the bounty is active or payout is pending, resulting in the slash of the curator's deposit.

This pallet may opt into using a [ChildBountyManager] that enables bounties to be split into sub-bounties, as children of anh established bounty (called the parent in the context of it's children).

NOTE: The parent bounty cannot be closed if it has a non-zero number of it has active child bounties associated with it.

Terminology

Bounty:

Bounty spending proposal: A proposal to reward a predefined body of work upon completion by the Treasury.
Proposer: An account proposing a bounty spending.
Curator: An account managing the bounty and assigning a payout address receiving the reward for the completion of work.
Deposit: The amount held on deposit for placing a bounty proposal plus the amount held on deposit per byte within the bounty description.
Curator deposit: The payment from a candidate willing to curate an approved bounty. The deposit is returned when/if the bounty is completed.
Bounty value: The total amount that should be paid to the Payout Address if the bounty is rewarded.
Payout address: The account to which the total or part of the bounty is assigned to.
Payout Delay: The delay period for which a bounty beneficiary needs to wait before claiming.
Curator fee: The reserved upfront payment for a curator for work related to the bounty.

Interface

Dispatchable Functions

Bounty protocol:

propose_bounty - Propose a specific treasury amount to be earmarked for a predefined set of tasks and stake the required deposit.
approve_bounty - Accept a specific treasury amount to be earmarked for a predefined body of work.
propose_curator - Assign an account to a bounty as candidate curator.
accept_curator - Accept a bounty assignment from the Council, setting a curator deposit.
extend_bounty_expiry - Extend the expiry block number of the bounty and stay active.
award_bounty - Close and pay out the specified amount for the completed work.
claim_bounty - Claim a specific bounty amount from the Payout Address.
unassign_curator - Unassign an accepted curator from a specific earmark.
close_bounty - Cancel the earmark for a specific treasury amount and close the bounty.