Discussing cryptotoken best practices

in #protocols8 years ago

While the irrational ICO activity that we’ve seen lately could do some short-term damage, in the long-run the cryptotoken model can be a massive positive for the world by enabling entrepreneurs to build decentralized protocols that empower people in new ways and also by democratizing ownership of innovation to the masses.

To help minimize abuse of this emerging model though, there should be a set of best practices that entrepreneurs and users hold all cryptotoken-based projects accountable for. To be clear, I understand that people will do what they want and standards will emerge organically over-time regardless. But we’ve already witnessed extreme amounts of money (over $29M in the past 3 weeks as you can see below) pour into projects of dubious quality, so I wanted to help push the discussion forward based on what I’ve learned in the space to date.

A set of best practices

It’s my intention for this to be a working set of best practices that evolves over time (these things change fast) and welcome all comments from the community:

1.) The founding team should demonstrate a strong technical reason for the protocol and token to exist. Ethereum exists because it enables developers to write smart contracts better than Bitcoin in the near-term. ETH is the token required for developers to run smart contracts. Zcash will exist because it will attempt to do privacy better than Bitcoin in the near-term and the token gives you access to the anonymity protocol.

These protocols enable users to do things that they can’t do with other protocols right now and the tokens incentivize users to behave in ways they otherwise may not. Their whitepapers describe the problems they are solving clearly and demonstrate significant technical research. A whitepaper that demonstrates research and a clear reason to exist is essential.

2.) There should be transparent communication from the founding team to the community. Transparency is crucial in crypto. If the founding team of a project is not sharing ideas and progress on public channels like Reddit, Slack, Twitter, or Bitcointalk, this is a red flag. All legitimate projects have active, open discussions across social channels.
The identity of the founding team should be known for any project raising external funds pre-product as well. For a launched project (see Bitcoin) this is less important.

3.) There should be a testnet or beta version of the protocol to demonstrate the founding team’s ability to execute. While shipping a live version can require significant capital for security audits among other things, there should be some indication that the founding team can execute. A testnet or beta version is a good indication that the founding team will be able to execute on their vision.

4.) A component of the token distribution should come directly from a blockchain if possible (distributed to any user that wants to participate in exchange for resources). Having a continuous issuance component is important for crypto protocols because it is inclusive, drives engagement and allows the network to gather valuable resources. Users are incentivized to use the Steem network because of the ability to earn Steem Power. Steem Power is accessible to anyone who has an internet connection and a keyboard to write. As a result, Steem is able to attracts resources in a powerful, decentralized way.

Note: For some projects, the token represents ownership in the future profits of the network (Augur), or ownership in another asset (stablecoins like Digix) in which case continuous issuance may not make sense. But generally speaking, fixed issuance tokens lack the strong network ownership effects that tokens with continuous issuances have and look more like traditional equity raises.

5.) There should be a cap on funds raised (if the project is pre-product). Generally as an entrepreneur building technology, there is a feeling that you should always raise as much money as possible because you never know when you will need it. I disagree with this view at the pre-product stage. Raising excess funds without a clear plan on how to use them leads to bad habits.

Entrepreneurs at the idea stage should be optimizing for shipping a product as efficiently as possible. There’s way too much risk at play to optimize on capital raised at this stage and when you raise too much you set up unfair expectations and develop an unhealthy culture of spending without delivering (bad for the entrepreneur and bad for investors). A reasonable cap for a pre-product seed is $2M. For perspective, several of the most successful projects didn’t raise anything (e.g Bitcoin).

6.) The founding team should own between 10% and 50% of the token and should not get liquidity in the first 3 years of the project. The key here is that the token owners and founders are well aligned and the founders are properly incentivized. Too little ownership and the founders aren’t properly incentivized. Too much ownership and the founders have too much control (especially problematic when the token gives you power in the network and the founders aren’t best equipped to have the power). All founding teams should be transparent about ownership as well.

Lots of learning opportunities remain

This is still a nascent ecosystem where there are only a few “successes” to point to and even the successes are still early in development.

I’d argue that the only cryptotokens to date that meet these standards are: Bitcoin, Ethereum, Zcash, Steem, Filecoin and Augur and all but Bitcoin are still pre-v1. There will be many more in the future but it’s important for entrepreneurs and investors alike to tread carefully and continue thinking about standards for these projects.


  • Follow me on Twitter
  • Hear about why I'm excited about Steemit here
Sort:  

thanks for the comment - i agree with you completely :)

there certainly is the sentiment that the market is going to do what it wants regardless and it's not worthwhile to put together best practices like this. but agree -- there's an opportunity cost to $29M and a lot of scars that can occur as a result of bad practices.

That seems like a good set of heuristics to me, especially applied to the examples of recent successful ICOs. I knew there were some big ones recently, but I didn't realize how recently or that it was to the tune of $29M. That's a whole lot of money floating around the space.

Some readers might think, "Doesn't sound like my problem, I'm not dumb enough to fund a losing bet. Serves those undisciplined investors right." What they may not realize is that there is a finite supply of investment capital available, and failed projects impact innovation, which benefits everyone.

If you took that $29M, did your due diligence, and invested the right amounts in a number of companies that meet those requirements, you'd net a lot more real blockchain innovation. Further, investors that get burned through bad investments are likely to be gunshy about future opportunities, whereas if they invested in successful projects, they'd more willing (and able) to support others in the future.

Sounds like the most important way to support innovation in the space is to focus on educating amateur investors. I assume the solution to getting them to read and follow that advice will be in your next post, right? :)

Thanks for sharing, really thought provoking piece!

I would like to add

  1. A clear solid business plan to the ico. How does the development team plans to build a profitable business. What are the revenue streams, the cost center and the break even points?

  2. Is the project solving a real life business problem? Is it just a dream or are you first building and then locking for problems to solve?

I see a lot of ICO on the market that do not solve a real business problem, are more pipe dreams then real products and probably will burn the raised money faster then a P&D cycle.

the tech is more important than the business plan at the seed stage.

i actually think that most ico "whitepapers" focus way too much on the business plan. a biz plan doesn't mean anything if you don't build tech that people are going to use.