Tom Ding is an early crypto crowdfunding platform entrepreneur and the founder of String Labs, an incubator for blockchain systems.

In this opinion piece, Ding aims to provide an overview of considerations he believes should be made by those seeking to launch protocol tokens that power a decentralized network or decentralized application.

At last week's Consensus 2017 conference and Token Summit, almost every other conversation I had started or ended with a variation of the question: 'Do you have a token for sale? What token should I buy?'

It makes sense. Token funding is faster, more liquid and more equitable to all participants when compared to VC funding. Plus, it's an amazing mass growth hack for adoption.

That's the promise, and it's generally true when things are well designed.

Yet, as a long-time crypto entrepreneur and token participant, the funding structure of some projects deeply concerns me. Some have little substantial technical research or development, lack proper team (except the usual 'advisor' tricks), or worse off, consider token distribution an 'exit' opportunity for the founders.

Compounding this is the fact that, with the price rise, FOMO (fear of missing out) among investors is still at all-time high.

This post is intended to start a discussion on this critical topic. We as industry practitioners have a major responsibility to self-regulate, and shape the right market dynamics for this emerging industry.

Protocols are software, but not just any old software. They are a set of software code that provide a coordinated service by formalizing (economic) relationships among its human and/or machine participants. By design, it benefits the public, and a properly designed protocol excels in something highly valuable known as 'social scalability', as explained by Nick Szabo.

To be more precise, what we're really funding is typically a specific instance of a protocol. The $18m contributed to ethereum, is primarily tied to one instance of the ethereum network (ETH) – which had a specific genesis block structure and was backed by the non-profit Ethereum Foundation. (Although, it could be argued that Ethereum Classic and other forks benefited from it.)

Now, how does that compare to traditional technology startup?

Public protocols are by definition open-source, permissionless (enabling participation) and autonomous (functioning independent of the developer).

Thus we could logically extend that:

This crucial difference – of contributing towards a commons and sustainable network, rather than to a private company – should define how we think these funding activities, rather than simplistically recycle any startup logic.

For example, valuing a protocol-based network's tokens is fundamentally different from valuation of a startup, even if it has a comparable function, users and growth trajectory.

This is true for many different reasons – among them are:

(See Aleksandr Bulkin’s excellent article for more discussions.)

The tokens behind these public protocols are created as an instrument to incentivize a large group of independent actors to collectively make the protocol-based network more valuable, specifically on two set of people:

In a 'trustless' protocol, the strongest implicit trust is being placed on the developers (and foundations/companies behind them) to not screw up the protocol, either intentionally or for lack of motivation/competency.

Hence, what we should be constantly optimizing for are ways to incentivize them and align their interest with rest of community.

Given that public protocols themselves resemble public goods, there's a strong argument that many projects, exceptions notwithstanding, should adopt a not-for-profit model,  where all money collected and a portion of the tokens goes to the foundation as an endowment.

A specific nuance, though, is how to deal with early contributors or companies who made significant financial investments to progress the project, prior to the token distribution. Reasonable, known practices include returning the investments as debt (with risk-adjusted interest), or rewarding the contributors with a portion of the tokens in proportion to the initial investments.

Note founders: This is not an 'exit event' for you.

We should in particular caution against attempts to turn the token funding into an 'exit' event. The distribution of the tokens is merely a beginning of a new dapp or blockchain network. The point of rewarding a founding team with tokens is to incentivize them to continue create value for the network and align their interest with broader stakeholders.

Yet, by agreeing to cashing out to the founders and team, this creates a dangerous incentive – the donators implicitly accepted a significant 'payment' – which they may not fully realize – for a new network that has not yet withstood the test of code quality, security or user adoption.

Sometimes there are valid reasons, or at least justifiable enough, to fund a private company, or consortium, instead of a not-for-profit.

For example, the protocol being developed is in a highly specialized vertical, regionally based, or the to-be-funded company has made a significant contribution to bootstrap the initial network. Another consideration is, on what layer does the protocol work? The closer you get to the blockchain layer, the less likely it should be a private company.

A (significant) 'private funding discount' should be applied to funding amount and network valuation to adjust for the:

Additional measures should be in place to balance and check the for-profit company, such as:

The token economy is based on key developers and contributors, who are rewarded a good portion of the token distribution for their past and much-needed future contributions.

Thus, at least part of their tokens, in particular those paid as part of their pay check, should be vested over a certain period of time (such as 6–12 months or longer) to ensure that they have sufficient incentives to contribute positively to the project.

This could be implemented in a smart contract. The control of the vesting could be held by an independent foundation, a multisig of key community representatives or some type of community governance mechanism.

You come up with a big idea of decentralized X. Write a beautifully crafted white paper. Put together a nice team. Token Launch! 24 hours later, you have $5m in cryptocurrency.

The question is, can the founders really execute that big idea? The dilemma most token donators face today is they're almost never given an opportunity for a careful evaluation. There's always a time rush amplified in a single round.

A more responsible way, for complex projects, is to divide them into smaller rounds with six months or longer in between, so people can take controlled risk and observe how the team execute in real world.

This could be achieved by a smart contract that predefines the rules for each round. (See DFINITY FDC for an example)

This is a contentious question.

Having no cap sounds inherently greedy: 'What would you use all this money for?' On the other hand, historically even good entrepreneurs significantly underestimate the funding they need to deliver a well-crafted product.

When you run out of funding, the project fails. No one is happy.

Further, in a bullish market, a cap can easily result in tokens ending up in the hands of a select few. Brave's Basic Attention Token just finished a $35m sale in 45 seconds, and 25% apparently went to a single address. So, there are really three separate underlying concerns here.

There needs to be:

Assuming the funding goes to a not-for-profit foundation, we need to factor in the budget for the lifespan of the foundation (eg 5–10 years). That's a bit different from your typical startup funding, which usually assumes a 12–18-month leeway as it expects more funding or revenue.

However, the initial crowdfunding is not the only source.

You could...

Combine a pseudonymous decentralized network with a bullish market and you end up with whales eating any cap you put on it. That's also bad if you’re aiming for broader distribution of tokens.

Here are some possible ideas that attempt to balance this goal with 'too much money' problem:

The harder question, of course, is why would a founding team ever want less money? What’s the check and balance?

In the future, I see two interesting possible paths for protocol-type foundations:

Follow the author on Twitter or email him here.

This article was originally published on Medium, and has been repurposed here with the author's permission.

Colorful abacus image via Shutterstock