How to Raise Money on a Blockchain with a Token
We’ve now seen several multi-million dollar crowdfundings done on a blockchain. Projects are raising money through the token model: selling the native token needed to use their corresponding networks (Ethereum’s ether, Augur’s Rep, IPFS’ Filecoin, and others).
What is the token model?
For the basics on how this token model works and why it’s powerful, you can read my introductory post. I’ll refer to these tokens as protocol tokens in this post — a more accurate name to what others and I have called “App Coins” in the past.
When considering raising money through a token, a few common questions arise:
- Should we consider the token model?
- How do we perform the token sale?
- Is this legal?
I‘m going to share current approaches and then offer ideas on future approaches using increasingly decentralized, on-chain methods.
Should we consider the token model?
In short: if your project has a network effect, yes.
While tokens serve many functions, the biggest benefit to the token model is that it provides the economic incentives for your network to get off the ground and overcome the classic chicken and egg problem. In other words, it gives all users of your app the ability to own a little piece of your network, incentivizing them to start using it at the start. This gives it a higher chance of success with a lot less capital needed.
How do we identify the network effect in our project?
In some projects the network effect and token model is obvious. For example, the network effect of Uber is the growing network of riders and drivers. So the token model for a Decentralized Uber and dUberCoin is pretty straight forward: make dUberCoin the native token of the Decentralized Uber network and reward early riders and drivers with more of it at the start.
Bitcoin was the first example of the token model: early miners could mine bitcoin of unclear value at the time — now worth ~$65,000 per block — using just a laptop. While that’s no longer possible, it attracted the initial miners needed to bootstrap the network.
It may take a little work to think about what this would look like for your project. My hunch is that a surprising percentage of current and future businesses fall into this category since most businesses rely on some kind of network effect.
It’s important to recognize what the network (or networks!) within your project are. At the moment many “apps” are really a bundle of a few things. For example, a food delivery app like GrubHub is really a bundle of: a network of restaurants and consumers, another network of restaurant advertisers (for sponsored placement in the app) and consumers, and a thin end-user client “app” that sits on top of these networks. Each of these networks could have their own token. It’s also possible some tokens don’t fully encompass all elements or what feels like the full value of a project. For example, Augur’s Rep token allows you to participate as an oracle to the prediction markets of the network and get compensated for it, but doesn’t take a cut of all transactions in the network.
These underlying networks and their user interfaces will get unbundled and re-bundled. We will see a bunch of different interfaces to the same blockchain-based networks in the same way there were a bunch of different Twitter clients early on and there are a bunch of different Bitcoin/Ethereum wallets today. Similarly, we will probably see a bunch of different networks and their tokens under the hood of what feels like a single end-user “app”. WeChat is a great example of this: it has many different networks in one UI.
How do we perform the token sale?
There have been two major types of fundraising through protocol tokens:
1. Pre-release sales
Pre-release sales have historically been most common and can be conducted in fiat, digital currency, or some combination. Examples include Ethereum (pre-sold ether for bitcoin), ZCash (pre-sold ZCash for fiat in a traditional equity fundraise from angel and institutional investors). They occur when a project needs money to develop and test a protocol to get it off the ground. Importantly, this means the protocol’s native token also has not yet been created, so IOUs for those tokens are being sold, not the token itself.
2. Post-release sales
Post-release sales are increasingly common. While they can be conducted through a central escrow agent, they are increasingly being conducted through a smart contract on the Ethereum blockchain which accepts crypto and atomically pays out the new protocol token. A recent example is the FirstBlood project. They occur when a project has launched an initial version of their protocol and corresponding token and wants money to continue its development. The project can then use digital currency raised to fund the continued development of the project.
Sales conducted on-chain through smart contracts couldn’t really be done before Ethereum, which is why they are a newer concept. I think this style will become the most common over time. Ethereum.org has a simple tutorial on how to code one up. You can also create your first basic token in 15 seconds using The Token Factory.
Pre-release sales make sense: it’s hard work to get a well-thought-out and tested protocol off the ground. Just like a startup, funding is often needed to get to an initial release. However, there are problems with these pre-release sales: we’ve gone off the blockchain and there’s now an IOU for a token that doesn’t yet exist. We also now need some kind of legal entity to accept these initial investments (more on that later).
A potential approach to get the early funding benefits of a pre-release sale with the reduced trust required in a post-release sale is as follows:
- Create your protocol token as a standard Ethereum (ERC20) token, but just release to the blockchain the standard functions needed to create the token and have it fit the ERC20 standard. At this point none of the “hard part” of writing the protocol has been done. Said another way, you modularize the development of the protocol such that you just release the standard token functionality (send, receive, basic accounting) on-chain as the first piece of the protocol developed, with the rest to be completed later.
- Use the digital currency raised to fund further development of the protocol.
This approach avoids the trusted/centralized “IOU” portion of pre-sales by giving token purchasers the token itself, even though the protocol is not yet complete. It obviously has its risks: projects funded this way could never come to fruition, like any early project. But the forces in the world from both sides are clear: developers want to be able to raise money to create new protocols and people want access to these new protocol tokens as early as possible. The two will converge and stabilize in a way where developers and future users can fund projects to a minimum viable product more easily.
How much of the token should we sell and how should we distribute the funds raised?
Different approaches will make sense for different protocols.
The current norm is setting aside 10–20% of the protocol tokens and selling the remaining 80–90%. A small portion of tokens set aside immediately goes to the core developers of the protocol to recognize their work to date, with the majority set aside to fund future work. This gives the project two sources of funding: the funds raised in the initial sale, and the ability to sell or disburse the tokens held back in the future.
How these allocations work is evolving and taking ideas from traditional companies. An early example of this is ZCash, where there is a “Founder’s Reward” that looks like the 4 year vesting schedule you’d typically find in a startup.
Whether or not these rough allocations make sense remains to be seen. A typical startup has the opposite structure: typically 20% (not 80–90%) of a project is sold in its first funding.
And therein lies a key point in the early stages of protocol tokens. We have yet to hit a situation where the combination of funds set aside in the initial sale and tokens held back have run out — yet. This is a close equivalent to running out of cash and the options pool in a typical company. Ethereum, for example, hasn’t hit this bump yet because 1) it’s young and 2) the price of ETH vs every fiat currency has, more or less, been on the rise, making the ETH the Ethereum Foundation set aside last longer. As a result, we’ve never seen the idea of multiple fundraises as is common with startups. Running out of funds for future development seems likely, as work on these protocols is never really “done”, although they may mature and change less over time.
Some combination of three things will happen in the future as a result:
- Protocols will hold back more than 10–20% of the tokens in the initial sale. This allows for more cushion to fund development. In a scenario where these funds are not really needed, token holders could vote to distribute or burn those funds so all token holders get an even share of that value back.
- The companies who have built value-added services on top of these protocols will directly pay for or themselves work on the protocols in the future. We’ve seen some of the major internet companies like Google, Facebook, and Apple do this with current core internet protocols. The Bitcoin Foundation is an early example of this: industry members had paid memberships which funded core developers.
- The users of these protocols could agree on mutual dilution. This is a way of using the protocol to raise funds for further development, much in the way that everyone in a startup will dilute themselves to create more options for new employees. This requires reasonably-functioning decentralized governance. Something similar was proposed by Vitalik when the Ethereum foundation was running low on funds, but became unnecessary as the price of Ethereum climbed. I’m not aware of this being done yet in practice, but I think it will become more common in the future along with the first two points.
Is this legal?
As with most legal questions, it seems the answer is: it depends. This model is new and largely untested. The most important question is whether or not it will be considered a security under US securities law. Some approaches to the various properties of a token which make it feel more like a security (thus riskier) and others which make it feel less like a security (less risky).
One example is is the amount of functionality of the token. If the token is only a vehicle to pay out a portion of profits it feels more like a security. If it allows you to uniquely use and access a network with a specific utility it feels less like a security. Another factor is the marketing around a token. If it’s marketed as generating or even guaranteeing profit, it feels more like a security. If it is marketed as serving a specific utilitarian purpose, it feels less like a security.
We are currently working on an simple legal framework to categorize the level of risk associated with different approaches along with top lawyers and industry groups like Coin Center. We hope to open source this framework in the next few weeks as part of our goal to advance the decentralized application ecosystem. This post will be updated at that time. Coin Center, a non-profit industry policy group, published a good longer form report on this in January.
Legal structures used to handle funds raised
Most groups who have raised funds through a token sale create some kind of entity to handle the funds raised. The most common structure at the moment is setting up an (often Swiss) foundation. This foundation has some governance, much like the corporate governance you’d see in a normal company, which determines both the initial and ongoing distribution of funds raised. This is what Ethereum has done, more or less. Many C corporations in the US are searching for a good structure at the moment.
A simple answer here may ultimately be the best one: don’t create an entity at all. Allow the token holders to vote on the disbursement of the funds raised to develop the protocol in a decentralized governance style.
Pulling it all together
To tie up a few of the ideas mentioned in this post, here’s what doing all of this on-chain without the need for a central controlling entity might look like:
- For launch, the community and core developers suggest an initial allocation of the tokens which is baked into the protocol. Crowdsale smart contract is released and raises funds; sets aside for future protocol development.
- As time goes on, token holders (not just a central company or foundation) can vote on how to distribute the funds set aside for development.
Contributors can be individuals or even a series of C Corps who have bank accounts to pay rent, salaries, and other costs, as long as funding decisions are done through decentralized voting or similar. This is the case with Maker DAO — they have a few small companies and a series of individuals who are funded by the community. There is a risk personal liability enters where central liability fades here, but my gut is that lessens with reasonable decentralization.
In all likelihood there will be some kind of core group making recommendations to the community which, if things are progressing reasonably, will be backed by the majority of token holders.
This approach replaces the need for a central foundation, company, or entity with decentralized governance. As we’ve seen in Bitcoin, Ethereum, and other protocols, it’s early days for decentralized governance in the realm of software protocols and there will be a lot of hard work and learning to do. However, given the nature and goals of most decentralized protocols, this probably produces the best outcome for all involved long term.
Thanks to Alex Felix for supplying graphs and Martin Koppelman (Gnosis), Andy Milenius (Maker DAO), Will Warren, Brian Armstrong, Dan Romero, Jarrad Hope, Joey Krug (Augur), Chris Dixon, and many at Coinbase for contributing to the ideas in this post.
These are ideas and should not constitute or substitute for legal advice.