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

Are refunds manual or automatic? #2251

Closed
theoreticalbts opened this issue Mar 21, 2018 · 6 comments
Closed

Are refunds manual or automatic? #2251

theoreticalbts opened this issue Mar 21, 2018 · 6 comments

Comments

@theoreticalbts
Copy link
Contributor

theoreticalbts commented Mar 21, 2018

So suppose the announced_launch_time is reached, but the SMT creator has not revealed the cap.

According to the whitepaper, and issue #2241, refunds occur manually. According to the implementation, refunds occur automatically. The purpose of the issue is to discuss which is the correct definition of the product: The whitepaper (manual) or the implementation (automatic).

Whichever way we decide to do it, either the whitepaper or the implementation will need to be updated, since they disagree about which way it should be done.

Manual refunds

According to the whitepaper, refunds are manual -- each contributor individually decides whether to issue smt_refund_operation. This allows a SMT creator and its community to mutually agree to delay a launch in case of some unforeseen circumstance:

  • The SMT creator says "I'm okay with delaying the launch" by not revealing the cap
  • Each community member individually says "I'm okay with delaying the launch" by not asking for a refund

Automatic refunds

The code in #2245 implements refunds as automatic: Once announced_launch_time passes, refunds become a "ping" operation which can be executed by anybody. Effectively, this means users get their refunds immediately. (There is no way for a user to refuse to accept a "ping" refund executed by somebody else.)

@Kiwonik
Copy link
Contributor

Kiwonik commented Mar 21, 2018

@theoreticalbts I believe the correct issue to link here is #2056 where the problem was first described and called a malicious attack on ICO. Also that issue was reopened as result of it. #2245 is only a simple refactoring of code to make it simpler and uncluttered.

@Kiwonik
Copy link
Contributor

Kiwonik commented Apr 27, 2018

@theoreticalbts @youkaicountry
I insist that refunds are both manual and automatic.

  • They are manual as long as ICO has not reached conclusion (success or fail state). Thus they allow to delay the ICO with mutual agreement as described above. This requires that the pings/executors are cut out of the picture as I understand they are now.
  • They are automatic once ICO reaches fail state. When ICO can no longer succeed (caps not revealed by launch_execution_time or too few contributions to reach revealed min cap, possibly due to manual refund) every contributor should be automatically refunded.

Again, please see updated ICO flow diagram for reference steemit/smt-whitepaper#172

@theoreticalbts
Copy link
Contributor Author

I'm not necessarily opposed to automatic refunds if we implement the automatic actions framework.

@Kiwonik
Copy link
Contributor

Kiwonik commented May 18, 2018

Agreed then. This closes the issue unless somebody else disagrees.

@mvandeberg
Copy link
Contributor

We will do automatic refunds (triggered by a ping) using automated actions.

@mvandeberg
Copy link
Contributor

Resolved.

To be implemented in #2731

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants