Comments (3)
we have excluded_delegators_set already. However, it excludes delegators at reward calculation stage. The share of excluded delegators is shared among others. In this request share of the excluded needs to remain in the staking balance.
We are going to have a lot of different configuration parameters due to minor differences in needs.
I would like to suggest a holistic configuration:
Let's have another map called payment_mapping_dict, a dictionary of PKH and target description pairs.
A PKH is either a tz or a kt address.
A target description is a text which may have ONE and ONLY ONE of the values below:
- another PKH: make payments to this address rather than original delegator KT address. Requires reporting change. Requested in #39
- Ignore : The same behavior as excluded delegators set. Requested in #8
- donotpay: the same behavior as this request expects.
Present and future target descriptions need to be mutually exclusive. e.g. we cannot 'ignore' and 'donotpay' the same delegator at the same time.
What do you (all users) thing?
from tezos-reward-distributor.
payment_mapping_dict
looks like a logical sentence.
if really need it.
from tezos-reward-distributor.
In V5 this is supported.
Use rules map to exclude anyone by setting a destination to it. Valid destinations are:
TOB = To Balance
TOF = To Founders
TOE = To everyone
Also rewards for accounts below min delegation amount can be paid to target by using mindelegation key. See examples/*.yaml file.
from tezos-reward-distributor.
Related Issues (20)
- Payment for cycle 527 was off, overpaid delegates HOT 4
- Cleanup: min_payment_amt HOT 5
- Pre-commit hooks
- Configure script requires refactor
- Update docs to use octez-*
- Dry run command not reading correctly
- Batch payer class is unmanageable.
- exit status is always 0 even when TRD fails (in single-shot mode)
- Don't require signer to know about baker address
- Problem with using the new addresses as owner and founder. HOT 10
- Smoke tests are stuck in an infinite loop on the CI only HOT 1
- payouts in failed/backtracked transactions are marked as paid
- Signer auth HOT 2
- re-running failed operations with TzKT backend is so slow, it hangs HOT 2
- use `simulate_operation` instead of `run_operation` HOT 1
- TRD exiting with status code 1, even when it succeeds HOT 2
- Payment to KT always fails on first try, it goes through in a second attempt. HOT 1
- TzStats "offline_losses" is not working HOT 4
- -M 4 seems to be broken, wrong status for backtracked transactions and ctez vaults are no longer avoided
- payment error. Cycle 669 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tezos-reward-distributor.