This parameter, MINORITY_BLOC_SLASH, doesn’t exist in original TCR whitepaper. Actually, the opposite is explicitly mentioned:
Token voters in the minority voting bloc neither lose tokens nor receive any reward.
Are we going to diverge from this idea? What’s the rationale behind each option?
The MINORITY_BLOC_SLASH parameter and why it might be useful in some cases is explained in this post by mike goldin.
If we have the parameter it can always be set to 0 if we do not want to punish people for ending up in the minority.
This comment to the above article is interesting too.
Unless we implement a variable DISPENSATION_PCT as suggested there, it seems that the best option is to set a high, probably max, MINORITY_BLOC_SLASH and a high DISPENSATION_PCT too.
The way I understant MINORITY_BLOC_SLASH parameter by looking at formulas here (extracted from that article above), is that tokens in the losing bloc are redistributed only to the voters in the winning bloc. So there’s no need to redistribute them to challenger/applicant too. It actually makes sense as challenger/applicant will likely be voters too, so they will already have “double” reward. This way everything is simpler, and we can keep this parameter tied only to Voting app, i.e., Curation app doesn’t need to know about it.
I’m going to update the technical specs doc accordingly.
