-
Notifications
You must be signed in to change notification settings - Fork 36
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
EIP-0018 ErgoFund #44
base: master
Are you sure you want to change the base?
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.
Approved, but please move old version into an Appendix, to have one file only
| Box | Quantity | Tokens | Additional registers used | Purpose | Spending transactions | | ||
|---|---|---|---|---|---| | ||
|Control | 1 | ControlBoxNFT | R4: Price (Long), <br /> R5: address[script] (SigmaProp) | Control price and address to pay for campaign registration | <div align="center">-</div> | | ||
|Sell| 1 | SellNFT <br /> Registration tokens | <div align="center">-</div> | Register a new campaign | registerCampaign, <br/> returnRegistrationToken | |
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.
Why would you need to return the registration token since this box is already a bottleneck for starting crowdfunding? I guess you could burn the token instead or send it to the false
script.
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 am opposed to the idea of having one sell box. There is no reason for that in this case (unlike cases like SigmaUSD bank box)
No reason to create a bottleneck when there is no gain.
### Pledge Contract | ||
|
||
This box can only be spent if the first input box, which is the campaign box related to this pledge. Which means the campaign has failed. | ||
(Conditions: fund collected for the project is less than the defined minToRaise and the height of the network exceeds the fundRaisingDeadline), also, in this case, the fee of funds' returning will be deducted from the backer's fund.<br /> |
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.
It can be considered to let the campaign owner finish the campaign if funds are raised even before the deadline.
sigmaProp(fundraisingFailure) | ||
} | ||
``` | ||
### Campaign Contract |
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 am strongly against the idea of having campaign tokens, at least in this way.
The point of crowdfunding is to be able to collect many possibly small funds. Now we are making the campaign box a bottleneck for donating to the campaign and I see no gain for that.
With the current design, there is no point in having a separate campaign box and pledge box. You can easily get all funds in the campaign box and give the equivalent amount of token to users for a later possible refund. I am proposing to do that since this also suffers from the issue I explained above -- I am making the point that donating should not go through the campaign box.
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 have previously proposed an idea to @kushti about how to have campaign IDs. So if the point of having a campaign token is that, there are simpler solutions to that.
"For the ErgoFund contracts, I think the campaign ID should be controlled by the sell contract otherwise someone can mess with the UI and potentially impersonate a campaign" in a chat with kushti.
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 concur @anon-real, moreover, I'm wondering if there is an option to design the whole system without the accumulation in the campaign box.
Of the top of my head:
The campaign starts with a box with height and target amount in the registers. The box value is the fee to the ErgoFund service. Box id is used as campaign id or via purchased campaign token bought from ErgoFund.
Backers create a donation box that either can be spent by the campaign owner upon height and target donation amount requirements are met or by the backers themselves if the campaign is failed.
ErgoFund service is funded from the campaign box value and optionally by taking a % from donations (enforced in donation box contract).
sigmaProp(fundraisingFailure) | ||
} | ||
``` | ||
### Campaign Contract |
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 concur @anon-real, moreover, I'm wondering if there is an option to design the whole system without the accumulation in the campaign box.
Of the top of my head:
The campaign starts with a box with height and target amount in the registers. The box value is the fee to the ErgoFund service. Box id is used as campaign id or via purchased campaign token bought from ErgoFund.
Backers create a donation box that either can be spent by the campaign owner upon height and target donation amount requirements are met or by the backers themselves if the campaign is failed.
ErgoFund service is funded from the campaign box value and optionally by taking a % from donations (enforced in donation box contract).
No description provided.