You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is truly two parts - client side requirement, and msg requirement.
currently some commands (see #3495 (comment)) do not require that we included the token denom when referring to tokens, where as many others do, AFAICT we ought to require the user to consciously be submitting the proper amount of tokens of the intended denom - adding denom requirements at the client level should accomplish this.
Secondly, in opposition to this, msg types sometimes include the requirement for including the denom, when this information is of course unnecessary at this level - the only denom which is allowable is the staking denom - thus it ought to be removed from message requirements - incorrect denom should be filtered at the Client level.
This conclusion is aligned with observations/PR discussion made during the peer review of the staking module (CC @cwgoes@jackzampolin). #3507
The text was updated successfully, but these errors were encountered:
Agreed - the denomination was left in x/staking msgs precisely for this reason, and could be removed after we have clearer CLI / REST interfaces that communicate to the user which denomination will be used.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue is truly two parts - client side requirement, and msg requirement.
currently some commands (see #3495 (comment)) do not require that we included the token denom when referring to tokens, where as many others do, AFAICT we ought to require the user to consciously be submitting the proper amount of tokens of the intended denom - adding denom requirements at the client level should accomplish this.
Secondly, in opposition to this, msg types sometimes include the requirement for including the denom, when this information is of course unnecessary at this level - the only denom which is allowable is the staking denom - thus it ought to be removed from message requirements - incorrect denom should be filtered at the Client level.
This conclusion is aligned with observations/PR discussion made during the peer review of the staking module (CC @cwgoes @jackzampolin). #3507
The text was updated successfully, but these errors were encountered: