I can’t emphasize this enough: Communications, regardless of how inconsequential or innocuous they may appear, can make or break a project. A single errant statement by a CEO can put an entire project at risk.
Projects should tailor strict communications policies to the nuances of their token launch strategy. So let’s break this down using strategies from the token launch framework:
Decentralize
This strategy is all about ensuring that purchasers of a project’s tokens do not have a “reasonable expectation of profits based on the managerial or entrepreneurial efforts of others” (as outlined in the Howey Test). In a decentralized project, tokenholders would not expect a managerial team to deliver profits, because no single group or individual has this power. Founding teams must not indicate otherwise, or risk implicating securities laws.
So what is a “reasonable expectation?” This is shaped, in large part, by how a project or token issuer talks (and tweets, texts, and emails) about a token. Courts have repeatedly found that when projects announce that their core team is driving progress and economic value, investors are reasonable in relying on the efforts of that core team for investment returns. This finding can then be used to justify the application of securities laws.
When it comes to decentralization, a strict communications policy isn’t a cheap ploy to evade U.S. securities laws – it’s a way to legitimately decrease the likelihood that token purchasers are relying on managerial or entrepreneurial efforts for profits, which helps protect web3 projects and their users. The fact is that, by refusing to establish constructive rules and by weaponizing communications against builders, the SEC has created incentives that are diametrically opposed to their own mission. Web3 builders are actually incentivized to disclose less about their project and their activities to the public.
So what would this strategy look like in practice?
First, projects should not discuss or reference their own tokens before launching the token. This includes potential airdrops, token distributions, or token economics. The consequences of doing so can be severe – the SEC has successfully stopped companies from issuing tokens, and they could try this again. Don’t give them the opportunity.
Second, following a token launch, projects should refrain from discussing the price or potential value of a token, or framing it as an investment opportunity. This includes mentioning any mechanisms that could cause the token to appreciate in value; as well as any commitments to use private capital to continue to fund the development and success of the project. All of these actions increase the likelihood that tokenholders could be found to have a reasonable expectation of profits.
After a project decentralizes, how members of the project’s ecosystem – including founders, development companies, foundations, and the DAO – speak about their roles is critically important. It’s easy for founding teams to slip into language that frames things as centralized, even if the project is extremely decentralized, especially when they are used to talking about achievements, milestones, and other launches in the first person.
A few ways to avoid this pitfall:
- Refrain from referring to oneself in a way that inaccurately connotes ownership of or control over the protocol or DAO (e.g., “As CEO of the protocol…”, “Today, we turned on X functionality of the protocol…”).
- Avoid forward-looking statements where possible, particularly with respect to mechanisms like programmatic “burning” of tokens to achieve pricing targets or stability.
- Avoid committing to or guaranteeing ongoing efforts, and refrain from referring to ongoing efforts as having outsized importance to the project’s ecosystem (for example, use “initial development team” rather than “core development team” or “main development team” where appropriate, and do not refer to individual contributors as “managers”).
- Emphasize efforts that have facilitated or will foster greater decentralization, like contributions from third-party developers or app operators.
- Give the project’s DAO or foundation its own voice to avoid confusion with the DevCo or founders that started the project. Even better: Avoid confusing third-parties, and rename or rebrand the original DevCo so that it does not share a name with the protocol.
Ultimately, what anyone communicates should reflect the principles of decentralization, particularly in public contexts. Communications need to be open and designed to prevent significant asymmetrical information accruing to any one individual or group.
For more on the practical implications of decentralization, see here and here.
The sum up
Once decentralized, no individual or company is the voice of the project. The project’s ecosystem is its own living system, separate and distinct. Making just one mistake can be catastrophic.
X-clude
When launching outside of the U.S., projects can take inspiration from the traditional finance world, and adopt strict communications policies that follow the requirements of Regulation S, which provides an exclusion from certain registration requirements under U.S. securities laws for offerings made outside the U.S.
The goal of the strategy is to prevent tokens from flowing back into the U.S., so communications should avoid “Directed Selling Efforts” that promote or advertise the token in the U.S. and risk “conditioning the U.S. market” for the tokens (i.e., creating demand for the token in the U.S.). Ultimately, the strictness of these policies will depend on whether there is “substantial U.S. market interest” (SUSMI) for the tokens (i.e., significant market demand for the token in the U.S.).
The sum up
If you aren’t offering tokens in the U.S., don’t communicate as though you are. Any statements you make on social media about a project’s tokens should specifically highlight that the tokens aren’t available in the U.S.
Restrict
Restricting a token launch to transfer-restricted tokens or “off-chain” points can allow for a more flexible communications policy. Thoughtfully executed projects are insulated from legal risk, because individuals can’t make an “investment of money” to acquire tokens under the Howey Test.
Still, this insulation can quickly disintegrate if projects encourage participants to view their transfer-restricted tokens or points as an investment product. These statements can significantly undermine the legal basis for restricting a token at all.
The sum up
Restrictions don’t absolve builders of legal consequences. Careless statements can haunt a project for years to come, preventing it from ever being able to shift launch strategies, or even decentralize.