mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-05-08 22:58:00 +00:00
Benjamin Kampmann
c78c2892a4
* mark template and utils as non-publish * switch to development version for testing * activate unleash check * maybe if I disable all rules... * Fix isolated compilation of `max-encoded-len-derive` with `syn` error[E0369]: binary operation `==` cannot be applied to type `syn::Path` --> src/lib.rs:88:29 | 88 | .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate)) | --------- ^^ ----------------------------------- _ | | | syn::Path error: aborting due to previous error For more information about this error, try `rustc --explain E0369`. Error: could not compile `max-encoded-len-derive` * WIP: bump changes crates since v3 tag to next breaking cargo unleash version bump-breaking --changed-since v3.0.0 cargo unleash version set-pre dev --changed-since v3.0.0 FIXME: Don't modify crates that are not yet released, e.g. `max-encoded-len-derive` * Update lockfile * WIP: Bump sp-transaction-pool as well * WIP: Bump sp-offchain as well * WIP: Bump frame-system-rpc-runtime-api as well * WIP: Bump sp-authority-discovery as well * Manually deactivate dev-deps before `cargo unleash check` Otherwise we run into `Cycle detected` error. * Bump sp-consensus-slots * Add missing Cargo.lock change * Bump sp-consensus-vrf as well * Bump sp-keyring as well * Bump sp-consensus-pow as well * Try to speed up the `unleash-check` job Previously, the job took 106 minutes - let's see if explicitly specifying a `CARGO_TARGET_DIR` will help * fixup: Ensure the temp target dir exists for unleash check * Bump pallet-transaction-payment-rpc-runtime-api as well Needed for Polkadot * Bump pallet-transaction-payment-rpc as well Needed for Polkadot * Try updating crates after patching in the Polkadot CI job * Use another approach to update patched Substrate crates * Try to update all sp-core versions in Polkadot CI job * Simplify sp-core version checking * Apply another shellcheck lint * Just do the simplest thing I guess * Welp don't do --offline then * Clean up `unleash-check` job triggers Co-authored-by: Denis Pisarev <denis.pisarev@parity.io> * Fix a note in unleash-check cache step * Add a note about temporary optimization in cargo-unleash * Pin a newer version of cargo-unleash Co-authored-by: Igor Matuszewski <xanewok@gmail.com> Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>
Treasury Module
The Treasury module provides a "pot" of funds that can be managed by stakeholders in the system and a structure for making spending proposals from this pot.
Overview
The Treasury Module itself provides the pot to store funds, and a means for stakeholders to propose, approve, and deny expenditures. The chain will need to provide a method (e.g.inflation, fees) for collecting funds.
By way of example, the Council could vote to fund the Treasury with a portion of the block reward and use the funds to pay developers.
Terminology
- Proposal: A suggestion to allocate funds from the pot to a beneficiary.
- Beneficiary: An account who will receive the funds from a proposal if the proposal is approved.
- Deposit: Funds that a proposer must lock when making a proposal. The deposit will be returned or slashed if the proposal is approved or rejected respectively.
- Pot: Unspent funds accumulated by the treasury module.
Interface
Dispatchable Functions
General spending/proposal protocol:
propose_spend- Make a spending proposal and stake the required deposit.reject_proposal- Reject a proposal, slashing the deposit.approve_proposal- Accept the proposal, returning the deposit.