There is this confusing situation whereby the act of bonding 0 tokens to a node actually constitutes rebonding all tokens that are already bonded to the network, to a different node than the one they are currently bonded to.
This is confusing to delegators, DAO operators and voters.
Note: This is a general issue across the Livepeer Protocol, and is not particular to this application.
Expected behaviour
Hmm - this is a tough one - but my proposal is to focus on optimising the clarity for the end voter, even if that might be at expense of the (probably more sophisticated) vote proposer.
One proposal would be to:
a. Create a new function in the UI called "rebond", which effectively calls "bond" but with arguments being 0 and the address of the new node to be bonded to
b. Present this to voters with a description "Rebond all existing bonded tokens to {new node's address}"
Another proposal could be:
i. Add some additional explanatory text to the UI to make it clear that the amount being requested to bond is "in addition to that already bonded", and also make it clear that "any existing bonded tokens will be bonded to the address" - this covers for the scenarios where a)
ii. If a vote proposer sets the "bond to" address to be different from the one it is currently bonded to, then make it clear to the voter that this is rebonding (although perhaps this is impossible to establish whether?)
Current behaviour
There is this confusing situation whereby the act of bonding 0 tokens to a node actually constitutes rebonding all tokens that are already bonded to the network, to a different node than the one they are currently bonded to.
This is confusing to delegators, DAO operators and voters.
Note: This is a general issue across the Livepeer Protocol, and is not particular to this application.
Expected behaviour
Hmm - this is a tough one - but my proposal is to focus on optimising the clarity for the end voter, even if that might be at expense of the (probably more sophisticated) vote proposer.
One proposal would be to:
a. Create a new function in the UI called "rebond", which effectively calls "bond" but with arguments being
0andthe address of the new node to be bonded tob. Present this to voters with a description "Rebond all existing bonded tokens to {new node's address}"
Another proposal could be:
i. Add some additional explanatory text to the UI to make it clear that the amount being requested to bond is "in addition to that already bonded", and also make it clear that "any existing bonded tokens will be bonded to the address" - this covers for the scenarios where a)
ii. If a vote proposer sets the "bond to" address to be different from the one it is currently bonded to, then make it clear to the voter that this is rebonding (although perhaps this is impossible to establish whether?)
Thoughts?