feat: Add option to designate Reward Recipient to Lock and Incentives #5281
Conversation
|
Also it appears e2e is failing at the create balancer pool step with this change |
|
@czarcas7ic good call, will apply fix and reassign you for review |
|
Please ping on slack when its R4R, thank you @mattverse |
| @@ -94,7 +94,7 @@ func MergeLockupsForSimilarDurations( | |||
| } | |||
| // create a normalized lock that will absorb the locks in the duration window | |||
| normalID = k.GetLastLockID(ctx) + 1 | |||
| normalLock = types.NewPeriodLock(normalID, owner, normalizedDuration, time.Time{}, lock.Coins) | |||
| normalLock = types.NewPeriodLock(normalID, owner, lock.RewardReceiverAddress, normalizedDuration, time.Time{}, lock.Coins) | |||
There was a problem hiding this comment.
This also feels like unexpected behavior. What if we have 5 locks, all with different rewardReceiverAddresses? This would set the normalized lock to whatever the final lock's rewardRecieverAddress is. Should we require that all locks have the same rewardReceiverAddress in order to merge them?
There was a problem hiding this comment.
IMO we should not be using this method anymore, since this was a method created use for migration in v7, and our codebase has changed alot since then.
however, I do think that your case states a valid point thus added logic to prevent merging locks if the reward address is not the owner as a saftey measure just in case we do come across using this method in 2d6aa30
There was a problem hiding this comment.
If this method is unused, can we remove it?
There was a problem hiding this comment.
We still need the method though since we have the old upgrade handler :(
Co-authored-by: Adam Tucker <[email protected]>
Co-authored-by: Adam Tucker <[email protected]>
Co-authored-by: Adam Tucker <[email protected]>
x/lockup/keeper/msg_server_test.go
Outdated
| s.Require().Equal(newLock.RewardReceiverAddress, "") | ||
| } else { | ||
| s.Require().Equal(newLock.RewardReceiverAddress, s.TestAccs[1].String()) |
There was a problem hiding this comment.
nit: these are flipped. The expected value should be the first value and actual should be the second value.
|
|
||
| // check if the reward receiver is the lock owner. | ||
| // if not, we do not normalize the lock. | ||
| if lock.RewardReceiverAddress != "" { | ||
| continue | ||
| } |
There was a problem hiding this comment.
ref: https://github.com/osmosis-labs/osmosis/pull/5281/files#r1208613288
I don't understand why we use an empty string placeholder when we could use the owner address directly. Please let me know
…#5281) * Add Reward Recepient to lock * Add changelog * Store receiver if receiver is lock owner * Add defense in depth * Debuggoing.. * Add debug * More logs * Fixed * Update x/incentives/keeper/distribute.go * Update x/lockup/keeper/lock.go * Update x/lockup/keeper/lock_test.go Co-authored-by: Adam Tucker <[email protected]> * Update x/lockup/types/msgs.go Co-authored-by: Adam Tucker <[email protected]> * Update x/lockup/types/msgs.go Co-authored-by: Adam Tucker <[email protected]> * Adams review * Adam's review * Fix test * Add romans comment --------- Co-authored-by: Adam Tucker <[email protected]>
Sub-component of #5044
What is the purpose of the change
This PR introduces a new state entry
reward_receiver_addressto the period lock. This field would be set to the lock owner by default at the time of lock's creation, and only would be changed by a separate messageSetLockRewardReceiverAddress.Distribution at epoch time would be done to the reward receiver address set in state, instead of directly using the lock owner.
By utilizing this field, further integration with contracts or authz would be possible.
Testing and Verifying
According tests has been added.
Documentation and Release Note
Unreleasedsection ofCHANGELOG.md?Where is the change documented?
x/{module}/README.md)