-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: mandatory replace #1169
base: master
Are you sure you want to change the base?
feat: mandatory replace #1169
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good from a quick glance, just a reminder that we should probably disallow execute_issue for replaces.
Also will be good to see updated tests in https://github.com/interlay/interbtc/blob/master/parachain/runtime/runtime-tests/src/parachain/replace.rs
66151f4
to
93d5b17
Compare
…ku/feat_mandatory_replace_request # Conflicts: # parachain/runtime/interlay/src/weights/replace.rs # parachain/runtime/kintsugi/src/weights/replace.rs
1ab5cbd
to
b217ece
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll also need to add benchmarks for some of the additional conditional flows for example in _cancel_issue
Have added benchmarking for the following pallet code
Redeem pallet
The benchmarking has been redone for the issue and redeem pallet code. |
de9b057
to
ca767e9
Compare
// its a replace issue call if requester is vault | ||
let slashed_collateral = if is_replace_request { | ||
// only cancel replace request if issue is expired | ||
ensure!(issue_expired, Error::<T>::TimeNotExpired); | ||
// for replace request griefing collateral is set as zero | ||
issue.griefing_collateral() | ||
} else { | ||
let to_be_slashed_collateral = if issue_expired { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// its a replace issue call if requester is vault | |
let slashed_collateral = if is_replace_request { | |
// only cancel replace request if issue is expired | |
ensure!(issue_expired, Error::<T>::TimeNotExpired); | |
// for replace request griefing collateral is set as zero | |
issue.griefing_collateral() | |
} else { | |
let to_be_slashed_collateral = if issue_expired { | |
// its a replace issue call if requester is vault | |
let to_be_slashed_collateral = if is_replace_request { | |
// only cancel replace request if issue is expired | |
ensure!(issue_expired, Error::<T>::TimeNotExpired); | |
// for replace request griefing collateral is set as zero | |
issue.griefing_collateral() | |
} else if issue_expired { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can flatten the conditionals right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not really, if it's not a replace request to_be_slashed_collateral
is also used to call vault-registery
methods and decrease to-be-issued
tokens which is only require for cancel_issue
and not cancel_replace
, hence i don't think we can flatten the condition
7bb6766
to
2c37913
Compare
crates/redeem/src/lib.rs
Outdated
// the inclusion fee is paid by new vault itself hence we can set it as zero | ||
Amount::zero(vault_id.wrapped_currency()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could result in the vault being unable to pay inclusion fees. If we want to be able to fully replace all issued tokens, I guess there's not really a way around this. But we should make it very clear in the UI that the vault is responsible for making sure it can pay these fees @tomjeatt cc @gregdhill
fn integration_test_nominated_collateral_prevents_replace_requests() { | ||
test_with_nomination_enabled_and_vault_opted_in(|vault_id| { | ||
assert_nominate_collateral(&vault_id, account_of(USER), default_nomination(&vault_id)); | ||
assert_noop!( | ||
RuntimeCall::Replace(ReplaceCall::request_replace { | ||
currency_pair: vault_id.currencies.clone(), | ||
amount: 0, | ||
}) | ||
.dispatch(origin_of(vault_id.account_id.clone())), | ||
ReplaceError::VaultHasEnabledNomination | ||
); | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gregdhill this test was probably a left-over from when rewards were proportional to issued tokens, right? If so, this test can be removed altogether
@@ -643,7 +628,7 @@ mod spec_based_tests { | |||
test_with(|vault_id| { | |||
set_redeem_period(1000); | |||
let redeem_id = request_redeem(&vault_id); | |||
mine_blocks(12); | |||
mine_blocks(100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change required? If so, I'd like to know why
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert back for test case integration_test_redeem_expiry_with_period_increase
, can't revert back for integration_test_redeem_can_only_be_cancelled_by_redeemer
Reasons
cancel_redeem
flow changed- the old version use to check
UnauthorizedRedeemer
ensure first, check out here - The new version
TimeNotExpired
ensure needs to pass beforeUnauthorizedRedeemer
asUnauthorizedRedeemer
is not required for replace cancel.
@gregdhill we have a lot of issues and redeems to migrate, I'm worried we might not have enough capacity in a single block. I've heard stories of chain getting stuck because of overweight migrations. Should we implement a multi-block migration? |
dd0ac31
to
033392b
Compare
…ku/feat_mandatory_replace_request # Conflicts: # Cargo.lock
As discussed, we are parking this for now. I just wanted to record one thought I had on this pr: issue and redeem periods are different, we need to make sure that the issue can't get cancelled while the redeem is opened |
Closes #823 & #1182
The PR adds the following extrinsic
Add Extrinsic:
request_replace
Parameters:
origin
: old vaultcurrency_pair
: the currency id of the fundsamount
: the amount of BTC to replacenew_vault_id
: The address of the new Vault involved in this replace requestgriefing_currency
: The collateral amount provided by the old vault as griefing protectionPostconditions
to_be_issued
tokens, done byrequest_issue
to_be_redeem
tokens, done byrequest_redeem
Dry Run,
Bob(old vault) wants to replace
5 BTC
with Alice(new_vault)Bob calls
request_replace
with the amount as 5BTC
he is not replacing the full available lock collateral hence bob can ba feesto_be_issued
+ 5to_be_redeem
+ 4.9 (0.1 as fee - fee calculation is done byget_redeem_fee
)Bob calls
execute_redeem
to_be_redeem
- 4.9issued
- 4.9to_be_issued
- 5issued
+ 5Modify Extrinsic:
execute_redeem
Postconditions
in the case ofis_redeem_a_replace_request
gets a triggerto_be_redeem
tokensissued
tokensto_be_issued
tokensissued
tokensModify Extrinsic:
cancel_redeem
Postconditions
in case of_cancel_replace_request
gets triggerto_be_issued
tokensto_be_redeem
tokensReplaceRequest
IssueRequest
old_vault
by transferring punishment fee tonew_vault
Dry Run,
Bob(old vault) wants to cancel the earlier
5 BTC
request_replace
call with Alice(new_vault)Bob calls
cancel_redeem
with the amount as 5BTC
to_be_issued
- 5to_be_redeem
- 4.9cancel_redeem
handlescancel_replace
logicReplacePeriod
is set toRedeemPeriod
Vault struct
old_vault
is fully replacing the fees is set as zero.Migrations Procedure
TxPause
to filter calls torequest_replace
.