Skip to content
Snippets Groups Projects
Select Git revision
  • 8093
  • 8001
  • 7980
  • 8038
  • gh-readonly-queue/master/pr-8070-f1d1d9c5c8d0effe4c60b81f6eaaa112ddc14658 protected
  • 8070
  • gh-readonly-queue/master/pr-8062-342f46a4e37749a749a405e6cacece9687f2a9f2 protected
  • master default protected
  • gh-readonly-queue/master/pr-7703-d13f1f60adc942621e2d335b0ea5d54accc02140 protected
  • gh-readonly-queue/master/pr-8071-9be43c0abf0a02a28d8fd4bbe9cfaed17dfcf18c protected
  • 8083
  • 6224
  • 8068
  • 8091
  • gh-readonly-queue/master/pr-8057-82827221b774e24b98cd7f2306c1f2c1ea281c40 protected
  • 8020
  • 6515
  • 8089
  • 6523
  • 6630
20 results
Compare History
user avatar
Balances: Configurable Number of Genesis Accounts with Specified Balances for Benchmarking (#6267)
runcomet authored 
# Derived Dev Accounts

Resolves https://github.com/paritytech/polkadot-sdk/issues/6040

## Description
This update introduces support for creating an arbitrary number of
developer accounts at the genesis block based on a specified derivation
path. This functionality is gated by the runtime-benchmarks feature,
ensuring it is only enabled during benchmarking scenarios.

### Key Features
- Arbitrary Dev Accounts at Genesis: Developers can now specify any
number of accounts to be generated at genesis using a hard derivation
path.

- Default Derivation Path: If no derivation path is provided (i.e., when
`Option<dev_accounts: (..., None)>` is set to `Some` at genesis), the
system will default to the path `//Sender//{}`.

- No Impact on Total Token Issuance: Developer accounts are excluded
from the total issuance of the token supply at genesis, ensuring they do
not affect the overall balance or token distribution.

polkadot address: 14SRqZTC1d8rfxL8W1tBTnfUBPU23ACFVPzp61FyGf4ftUFg

---------

Co-authored-by: default avatarSebastian Kunert <skunert49@gmail.com>
04847d51
Name Last commit Last update
..
src
Cargo.toml
README.md
README.md

Tipping Pallet ( pallet-tips )

Note :: This pallet is tightly coupled to pallet-treasury

A subsystem to allow for an agile "tipping" process, whereby a reward may be given without first having a pre-determined stakeholder group come to consensus on how much should be paid.

A group of Tippers is determined through the config Config. After half of these have declared some amount that they believe a particular reported reason deserves, then a countdown period is entered where any remaining members can declare their tip amounts also. After the close of the countdown period, the median of all declared tips is paid to the reported beneficiary, along with any finders fee, in case of a public (and bonded) original report.

Terminology

  • Tipping: The process of gathering declarations of amounts to tip and taking the median amount to be transferred from the treasury to a beneficiary account.
  • Tip Reason: The reason for a tip; generally a URL which embodies or explains why a particular individual (identified by an account ID) is worthy of a recognition by the treasury.
  • Finder: The original public reporter of some reason for tipping.
  • Finders Fee: Some proportion of the tip amount that is paid to the reporter of the tip, rather than the main beneficiary.

Interface

Dispatchable Functions

  • report_awesome - Report something worthy of a tip and register for a finders fee.
  • retract_tip - Retract a previous (finders fee registered) report.
  • tip_new - Report an item worthy of a tip and declare a specific amount to tip.
  • tip - Declare or redeclare an amount to tip for a particular reason.
  • close_tip - Close and pay out a tip.
  • slash_tip - Remove and slash an already-open tip.