Skip to content
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

Alternative sign() payment design #767

Open
Tracked by #663
volovyks opened this issue Jul 30, 2024 · 1 comment · May be fixed by #768
Open
Tracked by #663

Alternative sign() payment design #767

volovyks opened this issue Jul 30, 2024 · 1 comment · May be fixed by #768

Comments

@volovyks
Copy link
Collaborator

volovyks commented Jul 30, 2024

Currently, we have the #[payable] sign() function with a dynamic pricing model.
Downsides:

  • Unpredictable price, users do not know the exact price of a signature.
  • Each change of the minimum signature price is a breaking change.

Alternative design:

  • sign() always requires 1 yN of deposit
  • users must call fund() and attach a deposit of their choice
  • Users are charged for each successful sign() request from their contract balance

The alternative design allows both static and dynamic sign() request price models. I'm leaning toward a static one.

@think-in-universe
Copy link
Member

I created a relevant issue in #814, and I do prefer the above model over the existing one.

I just want to point out that it's important to consider the case that the user is a contract. For the fund function, I would suggest it takes one receiver parameter, so that one can fund others when necessary.

@volovyks volovyks moved this from Backlog to Selected in Emerging Technologies Aug 29, 2024
@volovyks volovyks moved this from Selected to Backlog in Emerging Technologies Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

2 participants