-
Notifications
You must be signed in to change notification settings - Fork 19
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
Signature deposit #611
Signature deposit #611
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.
A test here with relayer making a call into the contract would also be nice to see just in case relayer cannot fund the request
@ChaoticTempest we do not have Relayer setup in multichain test and I do not think we need it just to test if deposits work with relayer. But I will doublecheck if it works before we merge this. |
I had a call with @r-near. We should be fine with passing DelagateActions with deposits. |
contract/src/lib.rs
Outdated
/// To avoid overloading the network with too many requests, | ||
/// we ask for a small deposit for each signature request. | ||
/// The fee changes based on how busy the network is. | ||
pub fn signature_deposit(&self) -> u128 { |
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.
now that I think about this a bit more, I'm not sure if allowing people to call this function to check what's the required deposit would be great experience, since this amount can change in the time they call this function and when they call sign
. This would cause a lot of retries which could further congest the network.
So instead, to avoid having this situation, we should ask the users to always make the highest deposit we can take when calling into sign
, and then we can refund the difference to the account if the cheaper requests are possible
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.
People may want to spend 1 yN maximum.
If they provide more than we need, we will definitely refund (separate PR).
You may be right that it should not be a part of the API since it will work in ~90% of cases which is not enough. People can call sign()
with the maximum amount they are ready to spend and get an error if the network is under load.
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.
Yeah I'm also think people would always deposit the maximum deposit to ensure it get processed. And we can refund the difference based on load
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 will add refund logic after yield/resume is merged
Terraform Feature Environment Destroy (dev-611)Terraform Initialization ⚙️
|
We will need to add a refund functionality after wee implement yield/resume approach.