Functional Networks, Not Perpetual Promises

A Blockchain Founder’s Personal Reading of the SEC Crypto FAQ

Author’s note: This essay is my personal interpretation as a technology and product builder. It is not legal advice or a compliance assessment. Publication on ArcBlock’s official website does not make it the company’s legal or compliance position, or a determination by the SEC or another authority. Specific legal questions should be addressed to qualified legal counsel.

When is software finished?

For a system that people actually use, there is rarely a simple date. Security problems still need fixing after launch. Performance needs attention. Users encounter problems that the next release will have to address. A system can already work while its developers still have years of work ahead.

Regulatory discussion can blur those two facts. Is a team maintaining a system it has delivered, or still doing the essential work it promised would bring that system into existence? Observing that both teams are writing code does not answer the question.

That distinction is what I find most useful in the SEC staff’s new FAQ. Improving a working network and promising to build one should not be treated as the same activity simply because both require developers.

The Division of Corporation Finance’s September 25 FAQ makes the distinction more concrete. As someone who intends to keep working on products for a long time, I care about whether the framework recognizes what changes after delivery and leaves a clear place for continued maintenance and improvement.

In my earlier CLARITY essays, I discussed substance rather than labels and boundaries that builders can rely on over time. This time, I want to bring the question closer to everyday work: what has been delivered, what remains promised, and what people can actually use today.

Read the documents at their actual level

The FAQ is CorpFin staff guidance. It is not a Commission rule, regulation, or statement. The Commission has neither approved nor disapproved it. It has no legal force or effect, changes no applicable law, and creates no new obligations. That qualification belongs near the beginning of any discussion, not in small print at the bottom.^[1]

Its starting point is the Commission's March 17 interpretation, Application of the Federal Securities Laws to Certain Types of Crypto Assets and Certain Transactions Involving Crypto Assets, effective March 23. That document distinguishes an asset from an investment contract involving it. An asset that is not itself a security can nevertheless be sold through an arrangement that is one. An investment contract in this context is the investment arrangement around the asset, not necessarily a document bearing that title. The interpretation also addresses when that relationship can end. It applies the existing Howey framework; it does not replace it.^[2]

For readers outside securities law, the relevant Howey question is whether people invest in a common enterprise with a reasonable expectation of profit from others' essential managerial efforts. The focus is the consequential work purchasers are relying on someone else to perform, such as developing a system that does not yet function. Merely noticing that developers continue to work does not answer that question.

There is also an August document in this story. Q2.3 expressly cites the Commission's view on page 56 of its August 18 Regulation Crypto Assets proposing release. The September FAQ explains that view. It does not turn the proposed offering exemptions or investment-contract safe harbor into adopted rules.^[3]

Those are different levels of authority: a Commission interpretation, an interpretation expressed within a proposing release, and staff answers explaining their application. They can make the agency's position clearer without delivering the legislative durability I have argued for. This is a builder's reading of that direction, not legal advice or a classification of ABT or any other asset.

Software does not become finished when it becomes functional

Q2.3 is the answer I find most useful. Once a crypto system is functional, the activities it describes include securing and maintaining it, improving its functionality, and facilitating network effects, including by sponsoring or funding development. Under the Commission view cited by the staff, those services are not essential managerial efforts for this purpose. Promises to provide those services after functionality therefore do not satisfy that element of Howey.^[1]

This recognizes something ordinary about software. A working operating system still needs security updates. Its developers may improve performance or support new hardware for years. The existence of a future release does not tell us that today's system is still waiting to become usable. That is a software analogy, not a legal comparison between operating systems and crypto assets, but it helps explain why counting commits is the wrong test.

The definition matters. For Q2.3, functionality concerns whether the system's own token can be used for the purpose programmed into that system. Its footnote expressly points to this definition in Section III of the March release. A functioning website alone does not establish that.^[1][2]

Whether the issuer has fulfilled its specific promises is a separate question. Q1.1 says to look at what the issuer actually told purchasers it would achieve. Meeting a general definition of functionality does not, by itself, show that those particular commitments were met.^[1]

That distinction prevents an easy overreading. Some working software does not prove that every material development commitment was fulfilled. A record of delivery still has to be compared with the commitments it is supposed to satisfy.

Q2.1 brings the same discipline to communication. Describing a system's existing utility and capabilities is, without more, unlikely to constitute a promise of essential managerial efforts. The answer also addresses indefinite aspirations about future capabilities, qualified by the absence of promotion of potential profit. It remains a facts-and-circumstances answer.^[1]

I would not read this as advice to make roadmaps vague. A product owes users a clear explanation of what works and what is still being developed. The useful distinction is between explaining a product and selling an expectation tied to someone's future managerial work. Removing a few words from a website cannot substitute for examining the underlying arrangement.

A new name does not retire an old promise

Consider two development histories. In one, a team ships a usable network and spends years maintaining it, fixing problems, and extending what users can do. In the other, each new chapter begins with another launch, new financing, and a renewed promise that the essential system will arrive later, perhaps accompanied by another token and listing campaign.

Those are meaningfully different factual records under the framework. The distinction does not depend on whether the founders have been in crypto for eight years or eight months. It depends on the work and promises associated with the particular arrangement. A new project may be legitimate and useful; being new is not the problem. Nor does continuity alone settle the treatment of an old one.

Q2.2 addresses a specific version of this problem. If another party assumes the original issuer's promises to perform essential managerial efforts, separation from the associated investment contract does not occur merely because the original issuer will no longer perform them. The answer covers both an affirmative assumption and one arising by operation of law.^[1]

That is narrower than a general rule about serial entrepreneurs. Starting a separate company is not necessarily assuming the previous company's promises. But it also gives the new venture no inherited exemption. Its own offer, conduct, and commitments still need their own analysis. A change of company name cannot do the work of fulfilling a promise.

There is an uncomfortable counterexample to any simple story that only successful networks can separate from an investment contract. The March interpretation also discusses failure or abandonment: the relationship may end when purchasers can no longer reasonably expect the promised efforts to occur. It expressly preserves potential liability for earlier failures, misstatements, and unlawful offerings. Q2.2 limits that reasoning where someone else takes over the promises.^[1][2]

So my argument is not that continuing to build earns a legal reward while stopping creates a legal penalty. Functionality and abandonment are different facts with different consequences. For a builder, the useful point is that ongoing work on a functional system need not be treated as an endless extension of the original development promise.

The last two answers reinforce how specific these boundaries are. Q2.5 says that announcing a buyback of a non-security crypto asset, where the system is functional, does not constitute a promise of essential managerial efforts. For a system that is not functional, presenting that announcement as a source of yield or return can change the analysis. This is an answer about that particular Howey element, not a general approval of buybacks or their execution.^[1]

Q2.6 is narrower still. Providing a secondary market does not automatically make a trading platform a promoter. The platform must meet the definition in Securities Act Rule 405. The answer does not decide every other obligation of the platform, and a listing does not establish that the underlying network is functional.^[1]

Neither answer is a substitute for delivery. They help identify which conduct matters to which question.

Delivery was the beginning of continued work

For ArcBlock, this distinction is concrete. We delivered usable products long ago, and customers have continued to use them. Over the past eight years, the work has continued: improving those products, addressing problems that arise in actual use, and extending capabilities on the same foundation.

From Blocklets and decentralized identity to ArcChain, ArcSphere, and ArcSpace, the products and implementations have evolved along a continuous line. Delivered capabilities become the foundation for further development, while customer use brings new needs. Having substantial development work ahead today does not mean the earlier delivery never happened.

Anyone who has worked on a product for years will recognize this. Customers do not stop needing maintenance because a launch was announced. Once people begin using a system, the next work often becomes more concrete. What needs improving, which capabilities are worth extending, and which designs need reconsidering emerge through continued use.

That is why Q2.3 resonates with me. It recognizes the work that follows delivery. A network can be functional while its team continues to maintain it carefully and make it more useful. Continued development is an ordinary part of a product’s life. The fact that development has not stopped should not, by itself, be read as evidence that the original system was never built.

This is what I care about most in the FAQ: whether the framework can distinguish work that turns a promise into a working system from work that makes an already working product better. For us, delivery happened long ago, customers have continued using the products, and the work continues.

References