Golem crowdfunding whitepaper: Release candidate
We are pleased to present today, the next version of our crowdfunding whitepaper. We have taken all community feedback into consideration, and we consider this version to be our release candidate. The refreshed whitepaper is available here. But before diving in, please allow me first to describe what we have changed to address the critical feedback we’ve received, and why we stuck to some of our original ideas too.
I will first of all go through Daniel Zakrisson’s conclusions from his great analysis of our draft whitepaper (thank you Daniel once again for this great work).
More and better team info — show us this is a killer team that can deliver the grand vision of the Golem. The team and their ability to execute will always be the most important part any startup project.
I truly believe that we are a great team — and with the crowdfunding, we will be able to make it the best team that could deliver this project. We have expanded our team description in the whitepaper significantly, to give everyone more context on where we’ve come from, and who we are. This is complimented by the this blog post.
Budget — the min and max cap size differ around 5 times. From the description I don’t see the “Additional features” offered in the max cap scenario being 5 times as complex as the min cap scenario. This leads to questions about how efficient funds in a max cap scenario will be used
This is indeed a really valid concern. From our point of view it is however, rather a question of if we are able to deliver everything we promise, if we do not reach the cap. We have redrafted the roadmap in this regard, with the most significant change being redesigned timeline and a clearer division of deliverables between milestones, in particular redefinition of the Iron and the removal of this release from the minimum cap scenario.
A market strategy is needed
We have added a description of our plan here. In fact, we had originally spent quite a lot of time researching that, but the truth is that we had focused on technology in the draft whitepaper and skipped that almost completely. Now it is built into the roadmap section, as different releases will need different approaches.
We do not provide an analysis of “our competition” in the whitepaper, because we actually do believe that Golem is in fact not directly competing with anyone. If we consider other projects with goals which sound similar, it turns out that they either are not so similar after all, or they are completely dead — just a webpage, with no developers or code behind the name. And, if we consider cloud providers and datacenters, the fact is that we do not want to compete with them. We want to give them an alternative (we believe much better) way of interacting with their customers. Whether they decide to us Golem or not is up to them, but I can say sincerely, that we have a lot of interest from small and medium-sized professional providers who consider Golem to be exactly the technology for them. So, though it may sound ironic on the surface, not “outcompeting” anyone will be critical. What will make Golem success is in fact to convince developers to integrate it, and for requestors to use it. And we now describe that in the go-to-market strategy in the whitepaper.
I hope to see some external due diligence of code they have published so far — from a security and ability point of view
and
More and deeper security discussions are needed, along with time tables
We are doing through security checks of the crowdfunding contract, including an external audit by Zeppelin which will most likely be presented next week.
I am not sure if there is a serious point in doing a security audit of the Golem alpha right now, because even without it, we know very well that it is not secure, and we will be addressing all of these issues over the next couple of months. In fact, a significant improvement to Golem’s security is one of the most important things to still be done for the Brass release. And an external security audit is planned for Brass as well.
On top of it all, security audits are really, really costly — this is by far the largest component of the “contractors” part of our budget. So, we do not see the point of financing an external audit right now, as we are not able to afford one pre-crowdfunding anyway. We are of course aware that security is critical though, hence we’ve added a section where we summarize how we want to attack the issues we know about. And as you know, we have Alex Leverington on board, who is obsessed with this topic, and rightly so.
A much better roadmap is needed so that the investors can hold the developers accountable for the progress of the project
The problem is that, with this type of project, any commitment with date is a risk… Not because you are not willing to keep the promise, but because it is very hard to estimate the effort needed beforehand. Recall for example how we waited and waited for Frontier, and the planned release date was not announced. This is completely understandable: developers did not want to commit to dates they were not sure they will be able to meet. That is why we do not really have precise ETAs for Metropolis and Serenity, as far as I know. For Golem it is a similar case.
Even still, we have reviewed the roadmap in this regard, and have decided to present our general estimates for every release and piece of key functionality. We have used this dates while working on the budget. I do hope that the community will understand why it is done this way. If anything is not clear, please ask.
The crowdsale strategy could be improved in order to give the project, founders and investors better incentives to create a great project
I will just explain what we are doing, and why.
The crowdfunding will be conducted in the simplest manner possible. It will last three weeks, or until the cap is reached. The conversion rate will be flat during the whole crowdfunding — no discounts, no presales. Tokens will be transferable right after the crowdfunding ends. We do not work with exchanges to facilitate early token trading or the integration of crowdfunding contract into their services.
I am aware of ongoing discussions about how to make crowdfunding better, to ensure for example high distribution of the token (reduction of the purchases) or to maximize revenue (Dutch auction). However, we have a feeling, that we cannot be on every bleeding-edge technological frontier. :) Contracts might be short, but they are complicated too, and we do not want to take this risk right now. We have our own ideas about how this could be done, and perhaps we will work on that at some point (as imapp, not as Golem), but our key priority now is to finance the project.
All crowdfunding money is upfront. This is somehow standard when crowdfunding projects with tokens. I do realize this is not a standard for VC style financing, but we would need to either add governance to the crowdfunding contract (which would, with some simplification, mean creating a DAO — and we are not ready for the risks involved, as probably are not potential participants) or we do that in rounds. This again brings its own risks, which can be summarized as non being able to finance the project without violating commitment to the first-round token holders, regardless of how successful the project is.
The company and developers’ endowment will be locked for 6 months. Why 6 months only? Because we want to push our first major release in 6 months, and because the lock-up is not compliant with the migration feature of the token. As we are sure we will have to upgrade the token at some point, we do not want to risk a situation where we have to hold up Golem network progress, to wait for the end of lock-up period. Yet I want to declare, that if the company is to do anything with its 12% endowment before we are done with what we promise in the roadmap, it will be only to finance Golem’s further development.
The developers’ endowment is distributed among 23 people, with the majority (almost 90%) going to 11 people who we believe to be critical to the project’s success.
We also had some comments (not from Daniel’s post) that the token design we propose is inferior to our our original (fee-based) ideas. We do not agree with that and I have described why in a separate blog post.
We put this updated whitepaper before you, with the hope that we are coming to the end of the beginning, and that we will be able to call it “final” after this weekend. With the presentation of the contract code scheduled for Monday, we are planning to announce our crowdfunding date next week. As with all we do within Golem, this will not be some ninja-stealth announcement; we will set the date at least a couple of days in advance. So the crowdfunding will start at the very end of October, or the first days of November, most likely.
As always, thank you for taking the time to read us, and thank you for your support. If you have any questions or comments, you can reach us most easily on our Slack.
