Today, SEC made a major announcement about Crypto, Web3 and related industries. This is one more step in the direction of SEC is trying to simplifying the rules for people involved in Crypto and digital assets.
A company launches a crypto network, attracts users, and keeps improving its software. Does that continuing work make its token an investment security? What if it buys tokens back? What if users receive a digital receipt for assets they have staked?
These questions sit at the intersection of software development and financial regulation. On September 25, the SEC’s Division of Corporation Finance published FAQs addressing them. The document builds on the Commission’s March 17 interpretation. It is staff guidance with no independent legal force; it does not amend the law. [1]
For developers, founders, and ordinary token buyers, the significance lies in the distinctions. A token’s purpose, the promises surrounding it, and the way a product operates deserve separate attention.
A token and an investment are different questions
Consider two purchases. In one, you buy a ticket to use an existing service. In the other, you give a team money because it promises to build a business and generate returns for you.
Both could involve a digital token. Economically, they are different arrangements.
The March interpretation explains that a crypto asset which is not itself a security can still be offered through an investment contract. The Howey test examines an investment of money in a common enterprise with expected profits from others’ efforts. The relevant inquiry includes the issuer’s promises of essential managerial work. [2]
In announcing that framework on March 17, SEC Chairman Paul Atkins said it acknowledged that:
“most crypto assets are not themselves securities.”
This is background to the September FAQs, not a new statement from Atkins about today’s release. [3]
The word “themselves” carries weight. Calling something a utility token does not decide whether its sale involves an investment contract. Equally, recording an asset on a blockchain does not automatically make it a security.
What the September FAQs clarify
The following is a condensed overview, subject to the circumstances and definitions in the document. [1]
Topic | Staff’s clarification |
|---|---|
Functionality and decentralization | Classification definitions differ from the particular promises an issuer must fulfill. |
Staking receipts | Qualifying receipts can be digital tools; some protocol-issued receipts can be digital commodities. |
Receipt structure | A receipt adds no financial benefits and cannot authorize issuer reuse of deposited assets. |
Marketing | Current utility and aspirational features without profit promotion generally differ from investment promises. |
Transferred obligations | Another party assuming development promises does not end the investment contract. |
Continued development | Maintaining and improving a functional system does not constitute the relevant essential managerial efforts. |
Decentralized systems | Issuer statements likely cannot create a new investment contract when a functional system has no central party. |
Buybacks | Functional systems differ from unfinished systems pitching buybacks as returns. |
Trading platforms | Secondary-market availability alone does not establish promoter status; Rule 405 governs. |
Why software teams should pay attention
Software is rarely finished. Users expect bugs to be fixed, security to improve, and applications to remain usable as demand grows.
Imagine a payments application with an established network. Its engineers optimize transaction processing, strengthen monitoring, and improve wallet usability. As an engineering matter, these are sensible responsibilities. A team should not have to choose between keeping a service dependable and abandoning its users.
The practical question is how that work relates to the financial arrangement offered to buyers.
CoinGape’s September 25 coverage emphasizes the treatment of ongoing maintenance and upgrades on functional networks, alongside the fact-specific treatment of marketing tied to investor profits. Its report also notes that the FAQ answers were neither approved nor rejected by the Commission. [4]
My interpretation is that the guidance helps teams separate ordinary product stewardship from the promises used to raise investment money. But a production deployment is not, on its own, a legal opinion about functionality or the completion of every promise.
For C# Corner readers, this makes documentation valuable beyond engineering. Release records, delivered features, operating permissions, and statements made to customers should describe the same product.
Buybacks: the announcement is only part of the story
A token buyback means an issuer purchases tokens from the market. It can affect circulating supply, but it does not guarantee a higher price.
The Block’s September 25 report draws attention to a crucial distinction: a buyback announcement involving a functioning network does not by itself create the investment-contract concern addressed in the FAQ. A project still under development that markets repurchases as a source of yield or returns can receive different treatment. The report also stresses that outcomes depend on the circumstances. [5]
Consider the difference between a treasury team explaining a repurchase policy and a fundraiser telling prospective buyers that future repurchases will make them money. A buyer should want to understand the funding, purpose, and promises in either case.
My takeaway for founders is to avoid treating buybacks as a substitute for demand. A product needs a convincing reason for customers to use it. A repurchase program cannot supply that reason.
Staking receipts: read the rights behind the token
Staking generally involves committing assets to help a proof-of-stake blockchain operate. Liquid staking arrangements can issue a receipt token representing an interest in the staked assets. The March interpretation examines these arrangements and their conditions in detail. [2]
An everyday analogy is a warehouse receipt. You deposit goods and receive evidence of your ownership. That receipt is different from handing the goods to a business that can sell them, lend them, or use them to fund its own operations.
The analogy is imperfect, but it helps explain why the agreement matters more than the label.
For a wallet or DeFi application, I would want the user experience to answer four questions clearly: What do I own? Who can move the underlying assets? How do I redeem? What could interrupt access?
Those are product-design questions as well as questions for legal review. A screen that displays only an expected reward percentage leaves too much unexplained.
What experts and authorities are saying
Early same-day coverage is focused on explaining the FAQs. I could verify reporting from The Block and CoinGape, but not a broad set of named legal experts reacting directly to the September 25 document. It would be premature to present an industry consensus.
Earlier legal analysis of the March framework nevertheless provides useful context, provided its date is explicit.
In a March 24 analysis, Akin’s team, including John C. Murphy and Peter I. Altman, described the interpretation as:
“a turning point in crypto enforcement”
Their assessment was positive about the clearer framework, while recognizing continuing ambiguity. They emphasized that deciding when an investment contract forms or ends requires examining the promises made and the reasonableness of relying on them. This was commentary on the March interpretation, not today’s FAQs. [6]
Sullivan & Cromwell’s March 19 analysis offered a complementary caution:
“the securities law analysis of crypto assets and crypto assets transactions remains fact-specific”
The firm highlighted the importance of what issuers actually promised, including how they defined functionality and decentralization. Its analysis helps explain why two superficially similar token projects can require different conclusions. Again, this is earlier background commentary. [7]
Together, these perspectives suggest a useful reading: greater clarity can improve decision-making without making every project easy to classify. That is my synthesis of the sources, not a claim that the firms jointly endorsed the September release.
What builders and buyers should do with this information
For development teams, I would start with a plain-language description of the product. Explain what exists today, what remains planned, what the token does, and what control the organization retains.
Then compare that description with the website, fundraising deck, community messages, and application interface. If one describes a service and another sells an expectation of financial returns, the inconsistency deserves attention.
For buyers, the most useful questions remain concrete:
What rights does this token give me?
Is the product working today?
What promises am I relying on?
Can anyone lend, freeze, or otherwise use my assets?
Where would rewards come from, and can they change?
What happens if the team stops operating?
These are my practical suggestions, not new obligations imposed by the FAQs.
Regulatory classification also cannot answer whether a smart contract is secure, whether a business has customers, or whether a token is reasonably priced. A clearer legal explanation does not remove the need to examine the product.
I see the September guidance as useful progress toward a more specific conversation about crypto. For builders, the opportunity is to make products whose purpose and operation people can understand. For users, the opportunity is to ask better questions before committing money.
The industry will earn trust through that combination: understandable rights, working technology, and promises that match reality.
Sources
Research cutoff: September 25, 2026. The earlier quotations are dated explicitly and are not presented as reactions to the September FAQs.
Join the conversation! Your thoughts help the community grow.