Royalty increase update for v1 collections #631
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## release/v1.x #631 +/- ##
================================================
+ Coverage 79.40% 79.48% +0.08%
================================================
Files 14 14
Lines 971 975 +4
================================================
+ Hits 771 775 +4
Misses 200 200 ☔ View full report in Codecov by Sentry. |
| @@ -16,8 +16,8 @@ pub struct CollectionInfo<T> { | |||
| pub struct RoyaltyInfo { | |||
| pub payment_address: Addr, | |||
| pub share: Decimal, | |||
| pub updated_at: Option<Timestamp>, | |||
There was a problem hiding this comment.
just want to check with @MightOfOaks to make sure this won't break on read
There was a problem hiding this comment.
Earlier the code was in sync with a v2 update that we abandoned and was never deployed on chain. So, the v1 contracts that are currently on chain do not have an updated_at attribute in their CollectionInfo.RoyaltyInfo.
The PR basically reverts all the previous changes regarding royalty updates and keeps the update_time separately similar to how it's done for the v2 contracts.
| @@ -27,6 +29,7 @@ const CONTRACT_VERSION: &str = env!("CARGO_PKG_VERSION"); | |||
|
|
|||
| const CREATION_FEE: u128 = 1_000_000_000; | |||
| const MAX_ROYALTY_SHARE_BPS: u64 = 1_000; | |||
| const MAX_ROYALTY_SHARE_DELTA_BPS: u64 = 200; | |||
There was a problem hiding this comment.
this will be a PITA to update, but this may be how we must do it for now
| ); | ||
| // Make sure the share is not increased more than MAX_ROYALTY_SHARE_DELTA_BPS at a time | ||
| if share > old_royalty_info.share { | ||
| let share_delta = share - old_royalty_info.share; |
There was a problem hiding this comment.
what if share < old_royalty_info.share
There was a problem hiding this comment.
The reasoning was that the upwards updates are the risky ones that may cause traders to lose money if the change is too steep.
No description provided.