Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delegators those overdelegate #69

Open
habanoz opened this issue Apr 6, 2019 · 7 comments
Open

delegators those overdelegate #69

habanoz opened this issue Apr 6, 2019 · 7 comments
Labels
critical Critical

Comments

@habanoz
Copy link
Contributor

habanoz commented Apr 6, 2019

Currently, rewards are shared among all delegators. If the delegate is over-delegated this is not desirable for delegators.

It is necessary to implement a mechanism to avoid paying to delegators those over-delegate.

@jdsika jdsika added this to the Babylon 2.0 milestone Sep 10, 2019
@jdsika
Copy link
Contributor

jdsika commented Sep 10, 2019

Enforcing proper behaviour according to overdelegation is important. Over-delegation hurts the baker as it ruins his statistics for the important rankings. Partial rewards from the overdelegation should be payed to the baker. We have to check which was the last address that did the delegation and caused the over-delegation. A problem: This can not only happen with a new delegation but also with stocking up on an already delegating address by increasing the funds. The behaviour needs to be clearly documented.

@jdsika jdsika added the critical Critical label Sep 10, 2019
@jdsika
Copy link
Contributor

jdsika commented Sep 10, 2019

I think we should as well include the possibility to define this payment matrix:

Bildschirmfoto 2019-09-10 um 15 26 50

@habanoz
Copy link
Contributor Author

habanoz commented Sep 14, 2019

Baking config (yml) file can be used to select payment matrix. Do you think this is essentials for bakers?

@habanoz
Copy link
Contributor Author

habanoz commented Sep 14, 2019

We have to check which was the last address that did the delegation and caused the over-delegation. A problem: This can not only happen with a new delegation but also with stocking up on an already delegating address by increasing the funds. The behaviour needs to be clearly documented.

It is not easy to keep track of delegations. Tzscan creates a list of delegations. This can be used for tzscan backend. What about rpc backends?

@jdsika jdsika modified the milestones: Babylon 2.0, v6.5 Oct 18, 2019
@chiptus
Copy link
Contributor

chiptus commented May 6, 2020

We have to check which was the last address that did the delegation and caused the over-delegation. A problem: This can not only happen with a new delegation but also with stocking up on an already delegating address by increasing the funds. The behavior needs to be clearly documented.

I wonder how can I find this by hand, like if I go to an explorer will I be able to see this? As I see it, for now, if it's a new delegation, the easiest would be to give the new delegation 0% from its rewards.

@SemElVik
Copy link

SemElVik commented May 6, 2020

of course you can see.
for example here: https://tzkt.io/tz1......................../delegators

@jdsika jdsika removed this from the v6.5 (Carthage) milestone Aug 27, 2020
@jdsika jdsika added this to the v11.0 (Ithaca) milestone Mar 22, 2022
@jdsika
Copy link
Contributor

jdsika commented Mar 22, 2022

This issue will resolve itself with Tenderbake I think. Check new specification

@jdsika jdsika modified the milestones: v11.0 (Lima), v11.5 (Lima) Dec 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical Critical
Projects
None yet
Development

No branches or pull requests

4 participants