“Anyone who wants to sell you overnight success or wealth is not interested in your success; they are interested in your money.” ― Bo Bennet

In my last post, I warned about signs related to potential cracks in the Bitcoin startup ecosystem. That post inspired Fred Wilson to invoke Carlota Perez's framework about technology cycles, where a collapse typically wedges itself between the “installation” and “deployment” phases. In other words, “nothing important happens without crashes”.

I may have been premature in warning for an ecosystem crash "a la 2000 dotcom event", but I’d like to clarify that my position was primarily predicated on what might happen in the category of crowdfunded sales in cryptocurrency-driven applications, also known as Dapps (Distributed Applications), or DAOs in the making (Distributed Autonomous Organizations). My fears were not directed at the traditional VC-funded startups that are resulting from increased entrepreneurial activity in the overall cryptography-driven technology segment.

That said, I want to focus on how we can make cryptocurrency crowdsales more resilient to future pitfalls or types of failures that could affect the rest of the segment. Although the overall dollar amounts are not yet significantly high in this category, the negative psychological impact and indirect consequences (e.g. knee-jerk regulation) would be far greater, if anything bad were to happen.

The crowdsale process using a Dapps model with App Coins is an important strategic feature of the cryptocurrency model, and a potential new value creator. Therefore, we must get it right.

I've been observing this sector closely, have participated in it, and regularly speak with entrepreneurs and stakeholders who are involved in such projects.

This is not meant as a specific project critique. There are organizations that are doing a good job with some of these practices. This is meant as a set of suggested improvements, mostly based on what already works in the startup space that we can learn from. From a success factors perspective, I don’t see how different these projects are from the evolution of a startup, as that process is already known and documented.

Just like a regular Kickstarter-style project, there are 3 phases of a Dapp/DAO crowdsale project, no matter how big or small it is. Simply put, there is a “before”, “during” and “after” stage.

In looking at these 3 phases, it appears that we have perfected the “during” phase, i.e. the mechanics of the crowdsale itself, including the booting-up of tokens, branded coins or unique cryptocurrency and their initial distribution; but I think that we can improve in the other phases.

As a starting point for getting up to speed on this, David Johnston has published a series of white papers covering the theory and specifications of Dapp crowdsales, and you can also follow a number of the pioneering companies who are at various stages of crowdsale deployment, from his Dapps Venture Fund. David’s collection of papers is a great initial read, but alone they are not enough to ensure overall success in the crowdsale continuum, and those papers are oriented towards a Dapp formation, not a DAO necessarily. Although some Dapp characteristics apply to a DAO, a DAO is a lot more complex to bring to market, as I’ve already detailed in An Operational Framework for Decentralized Autonomous Organizations.

That said, there is a point that I don’t agree with David Johnston on, as he advocates: "There are no legal entities required for a Dapp to operate because it is not a company.” You cannot escape the legalities of operating an organization by just stating that “it’s not a company.” But let’s not digress for now, and rather let’s dive into these 3 phases.

Usually, a white paper is published as the first stake in the ground. The white paper is typically a technology blueprint, and offers a vision that the founders have. But often, the implementation part is the weakest element I have seen in those papers; so the linkage to the vision's realization needs to be stronger.

There is a wide gap between a white paper and an implementation plan that delivers on that vision, and this has been a weak link in most of the white papers I have reviewed. This weakness can be addressed by separating the vision from its implementation (more of this, below).

In this stage of the project (which could be a few months in the making), the organization behind the project needs to gain the confidence of the public they are supposed to attract, by earning their trust. They can do so by communicating implementation details with credibility, and by outlining the credentials and experiences of the founders; not just by generating excitement via the white paper’s vision.

Before users can trust the protocol, they need to trust the people who created it.

So, my advice is to take a page from what startups already do and explain more clearly what you plan on doing via a pitch deck approach that has details. Of course, the project can later take input from the community to refine its evolution, but there needs to be a good directional starting point.

There is lots of good advice on startup pitching. Here is a list of some of the best curated ones from Startup Management. In a nutshell, you need to cover:

1. Team: History & experience of founders

2. Product: what will be developed? Describe the protocol or service as if it was a product. (the white paper is not the product)

3. Customers/Users: Who will be using the service? Describe the typical user or customer and what you’ll offer them that is different or better than what currently exists.

4. Market Approach: How will you acquire these customers?

5. Governance: Who is the legal entity behind the project? What form of incorporation has it taken? Who are the official directors? And in which jurisdiction is it adhering to?

6. Success Metrics: What success milestones do you foresee making yourself accountable for, from a product, market, and organizational perspective?

7. Budget: How will the money be spent and what salaries will be drawn? Executive/founders salaries should be revealed.

8. Reporting: What process, frequency and level of details in progress reporting will you commit to?

9. DAO-specific: Why is the DAO/Dapp construct better than what already exists today, and how will no users and investors be rewarded in the future?

10. Governance Level II: Would you commit to an independent authority to perform an audit during your development phase?

This is the stage that involves the actual crowdsale mechanics, from accepting “coins” to issuing tokens, certificates, wallet receipts, shares or whatever is being traded for participation in the crowdsale. I’m not going to spend too much time there because the projects seem to be well versed in implementing the technology required to operate the sale itself.

I like this part in David Johnston’s principles, “The funds raised from such a crowd-sale should be controlled by an entity that is independent of the founders, commonly a Foundation.”, but I am seeing not so independent Foundations with plenty of founders in it who are making the wrong decisions, potentially leading to a difficult evolution.

Some additional thoughts on this stage:

• Skirting around regulation by cleverly finding the right language in your Terms & Conditions doesn’t make you immune to future scrutiny, nor should it give you the illusion to have received a blank cheque from your investors.

• Setting bylaws doesn’t give investors visibility into how you will operate.

• I don’t like the promoter’s role there. Why do you need a promoter, especially as someone who is not involved in the business? Virality is good if it rolls on its merits.

• Remember that fools will fund any idea, but smart people will fund out of a conviction that you are capable to implement these ideas.

This is the stage when a company goes in the dark, as it typically takes from 3-12 months for the software development to bear its initial fruit. This is where the organization needs to treat their members/early users  like shareholders and valued investors, and I recommend taking a page from how startups update their investors via a monthly update that includes the good, bad and ugly. For some examples, read-up one of several articles on VC-CEO relationships, or just use Jason Calacanis’ What should I include in my monthly investment update?

Publishing regular blog posts as a form of update is useful as long as they contain a good dose of detail, reality and self-introspection.

One of the key aspects of the development phase that’s often missing is a “clear” linkage between the cryptocurrency (or token) and how value is created around the operations of the (future) DAO or Dapp; whether such value is based on transaction volumes, user actions or other native activity (more on this in a future post). Tokens and cryptocurrency are part of the “Performance DNA” of a DAO/Dapp, therefore you cannot be vague on this linkage.

Some generic challenges and questions to keep in mind:

• Are you building an application, an open source protocol, a platform, or a business? Each one leads to different business & operating models.

• Sausage-making updates are not the same as a formal update that focuses on progress against objectives. Don't confuse activity with results, e.g following Github commits is not enough, as it’s the minimum expected. Rather, show usage and what testers are doing with your software releases, what you are learning from them, and how you are iterating your approaches.

• Although you are primarily building software, you should also focus on starting to think about the ecosystem of partners and stakeholders around your software, especially if it is a platform that enables new capabilities for others.

It’s launch time! This is when your product/service/software hits general availability in the market, and real users are using it. You are in the wild!

But hopefully, your test-net stage has prepared you well for this phase. Satoshi Nakamoto had a long testing period for his protocol by managing his own mining servers and trying it with a handful of friends first.

Business development, marketing, management and leadership skills become as important as the technical know-how that got you there so far.

Now, you can be more deterministic in how your future will evolve by taking a managed approach to your evolution. Yes, a DAO is supposed to be "autonomous", but the reality is that autonomy is typically gradually earned by being first “guided”, then “semiautonomous”, and finally fully autonomous.

When you hit the market (assuming you have achieved product/market fit), then what’s most important becomes your traction (repeat engagement and growth), and the certitude that you are creating and accumulating new (tangible) value for the organization and its stakeholders.

Bitcoin was a model, but copying it is not easy. It was based on a) a big idea, b) open source c) nonprofit for itself d) a foundation. But Bitcoin generated an incredible ecosystem around it that now supports it.

Every next project has an uphill battle as they must define clearly how different or additive they are to Bitcoin. You cannot assume that just because you developed a handful of unique features that Bitcoin doesn't have, that Bitcoin will go away. 80% of the cryptocurrency activity is still around Bitcoin, and it commands 80% of the total market cap in cryptocurrencies. Bitcoin is not perfect, but many of its parts are excellent. It is the reference point. Most other projects start with a "better or more perfect vision", but they need to deliver on it.

True, Bitcoin didn’t have a central management authority, yet it managed to do relatively well with an upwards and revolutionary trajectory, despite its ups and downs. Some people see this as part of its eventual stabilization (as collective wisdom prevails), whereas others see Bitcoin as full of weaknesses, and think that the "experiment" must be repeated but without those mistakes.

Two key conditions of the DAO construct are to be open source and that its Foundation is non-profit. These requirements raise the bar on the difficulty level it takes to reach a state of business equilibrium.

If the Foundation is non-profit, the Dapp or the DAO needs to generate profits or create real (internal or external) capital value. Otherwise, it will be dead, or it will need to continue raising money.

The essence of any organization, whether DAO or not, is to find a business model where users do useful things to grow the organization's value.

The challenge with making the protocol software as open source is that open source business models aren’t that straightforward, and some think that the Economics of Open Source make it hard to have another RedHat. Profits are an important part of properly running a company whether they are spent or not. Profits offer a cushion in case things go bad, and they are there, waiting to be reinvested when opportunities arise.

I’ve oriented this blog post as a message to those involved in premines, presales and crowdsales of cryptography-based models, protocols, services and platforms, but I’m not implying there is bad intent of their part. However, there is a lack of maturity in what it takes to win the confidence of investors and the market. And there is a lack of operational experience in following through with the initial euphoric visions, and into the realities of releasing products that work, and ensuring that the market adopts them.

Maybe there is no way to avoid overshooting our expectations, and the Carlota Perez model for Techno-Economic Paradigm Shifts will prevail, as we hit the bump, adjust and re-deploy.

But maybe if we curb our enthusiasm a little, and double our vigilance, at least some of the effects of the imminent correction will be easier to swallow. And if we are successful in booting-up a few more Bitcoinalike Autonomous Organizations, then it would be a good thing, as it would draw more participants who can draw on the experiences of the pioneers.

With public money comes greater responsibility. Doing a public crowdfunding campaign is a two-way street. It's almost like being a public company from Day 1. It’s not easy being in the public eye.

If you can’t deliver the transparency, don’t take that path.

And if we don’t self-govern to higher standards, the regulators will come and put a damper on this journey.

]]>