The single-token model often asks one token to do two jobs that work against each other. A better approach is to issue one token for users and a separate security token for investors.
One of the recurring problems in the crypto industry is the failure to distinguish between two fundamentally different groups of people: the people who use a platform and the people who invest in the company developing it. These groups may have a common interest in seeing a project succeed, but their economic interests are not necessarily the same. A user wants a product or service that works, is reasonably priced, and is easy to use. An investor wants a return on the capital invested in the business. Those objectives can overlap, but they can also conflict.
The conventional crypto fundraising model often tries to satisfy both groups with one token. The project issues a token, sells it to raise capital, and then tells the market that the same token will eventually serve as the currency or utility asset of the platform. The token is expected to attract investors through the possibility of price appreciation while also functioning as the means by which customers access the product or service.
An investor who purchases a token as an investment generally wants its price to rise. Ideally, that investor would prefer to hold the token and sell it later at a profit. A user, on the other hand, needs to spend the token to use the platform. If the token is expected to appreciate significantly, users may be reluctant to spend it. Why would someone use a token to purchase a service today if they believe that token may be worth substantially more tomorrow? This behavior is reminiscent of Gresham’s law: people tend to hold what they believe will appreciate and spend what they believe will lose value. Although it is not an exact application of the principle, the same economic tension can arise when a token is expected to serve both as an investment and as a means of payment.
The reverse problem can also occur. If the token is designed to be inexpensive and readily available so that customers can use the platform without worrying about its price, it may not provide the investment characteristics that the project used to attract capital in the first place. The company is effectively asking one asset to serve two different economic purposes.
The utility token is designed to operate within the platform. It may be used to purchase services, access features, reward participation, pay transaction fees, or perform other functions necessary to make the product work. Its design should focus on usability, predictable transactions, and the practical needs of customers. The security token, by contrast, represents an investment in the company or a defined economic interest in the business. Depending on its terms, it may represent equity ownership, voting rights, rights to distributions, revenue participation, or some combination of those interests. It is intended for investors, not as the everyday currency of the platform.
This separation allows the company to design the utility token around the needs of its customers without having to make it serve as an investment vehicle. At the same time, the company can offer investors a security that directly reflects the rights and economic interests they are purchasing. The distinction matters. A customer buying a service should not have to speculate on the future price of a company’s equity-like token just to use the product. Likewise, an investor should not have to rely on the hope that customers will continually buy and hold a utility token in order to realize a return on the investment.
The company can raise capital through a properly structured securities offering while building a separate utility system for its actual customers. The two tokens can be economically connected where appropriate, but they should not be confused with one another. This is not a proposal to avoid securities regulation. Quite the opposite. The investment token should be treated as a security when its rights and economic substance make it one, and it should be offered and administered in compliance with applicable securities laws. The benefit is that the project acknowledges the investment for what it is instead of trying to disguise an investment offering as the sale of a product token. The security token also offers an opportunity to improve how a company communicates with and administers the rights of its shareholders.
In a traditional company, shareholder information, ownership records, voting materials, and distribution records may be spread across transfer agents, corporate recordkeeping systems, banks, lawyers, and other service providers. Shareholders may receive notices through different channels, submit proxies through separate systems, and wait for administrative processes to be completed before learning the results of a vote or receiving a distribution. A properly designed security token could bring many of these functions together.
The token’s smart contract could be designed to reflect the rights attached to the relevant class of shares. Depending on the company’s governing documents and applicable law, those rights might include voting entitlements, distribution rights, transfer restrictions, lockup periods, and other class-specific provisions. The token could also be programmed to recognize the number of shares held by each eligible shareholder and calculate that shareholder’s proportional entitlement to a distribution.
Consider a company with 500 shareholders. If the company needs to conduct a shareholder vote, a properly integrated system could identify the holders of the relevant class of securities, determine their voting entitlements, distribute voting instructions electronically, receive their votes, and record the results. Instead of relying entirely on a paper-based or fragmented process, the company could communicate with eligible shareholders through a common digital system.
The same concept could apply to distributions. If the board or other authorized corporate body properly declares a dividend or other distribution, the system could calculate each eligible holder’s entitlement based on the applicable shareholding records and facilitate payment. In a suitable arrangement, distributions could be made directly to the verified payment addresses associated with the shareholders.
The advantage is not simply speed. It is the possibility of reducing administrative friction, improving transparency, and giving shareholders more direct access to the company. A shareholder should not have to navigate an unnecessarily complicated process to find out what the company is doing, exercise a valid voting right, or receive a distribution to which that shareholder is entitled. The same system could also make it easier to communicate with shareholders when the company needs approval for a corporate action. Notices, voting deadlines, records of participation, and results could be made available through an integrated platform. The company could maintain a more current and transparent record of ownership and shareholder activity.
Of course, code does not replace corporate law. The company’s articles, bylaws, shareholder agreements, applicable corporate statutes, and securities requirements still determine what rights shareholders have and how those rights must be exercised. A smart contract cannot create a lawful dividend where one has not been properly declared, eliminate a required shareholder approval, or override a transfer restriction imposed by law or the governing documents. Nor does a wallet address, by itself, necessarily establish the legal identity of a shareholder. The system must connect token ownership to reliable shareholder records and comply with applicable transfer-agent and recordkeeping requirements.
But those are design and compliance issues, not reasons to abandon the concept. The technology can be built to work alongside the legal framework. In January 2026, the SEC’s divisions of Corporation Finance, Investment Management, and Trading and Markets issued a statement addressing tokenized securities and the use of distributed ledger technology in maintaining issuer securityholder records. The statement recognizes that an issuer or its agent may use blockchain records as part of the master securityholder file, while emphasizing that tokenization does not remove the security from the reach of federal securities laws.[1]
The point is straightforward: a security token should not merely be a digital certificate that sits in a wallet. It can be designed as an integrated system for recording and administering the rights attached to the security. It is important to understand that a utility token and a security token are not simply two versions of the same product. They perform different functions and should be designed accordingly.
A utility token is built to support the operation of a platform. Its code may govern how users obtain it, spend it, transfer it, redeem it, or use it to access services. Depending on the business, it may include transaction-fee logic, usage limits, reward mechanisms, account balances, redemption rules, or other functions necessary to operate the product. The overriding objective is to make the platform work efficiently for its users.
A security token has a different job. Its code must reflect the legal and economic rights of the security. Those rights may include ownership interests, voting entitlements, distribution calculations, transfer restrictions, investor eligibility rules, lockups, and other provisions specific to the security being issued. The token may also need to interact with shareholder records, corporate notices, voting systems, and distribution mechanisms.
These are different programming requirements. A utility token designed to facilitate the purchase of storage, healthcare services, or access to a digital platform does not need the same architecture as a token representing shares in the company that operates that platform. Trying to force both functions into one token can create unnecessary complexity and conflicting incentives.
The better approach is to design each token around its actual purpose. The utility token should serve the customer and the platform. The security token should serve the investor and reflect the rights attached to the investment. There may be ways for the two tokens to interact. For example, the company might use revenue generated from the sale of utility tokens as part of the economic formula for distributions to security holders. But that relationship should be expressly documented and implemented in the security’s governing terms. It should not depend on vague promises that the utility token will somehow become valuable as the platform grows.
MintHealth: a separate healthcare utility token and investment token. MintHealth developed a healthcare blockchain concept using two separate tokens. VIDA was designed as a fixed-price utility and reward token for the platform. Patients would earn VIDA for completing healthy activities and could redeem the tokens for healthcare-related benefits and products. Insurance companies, healthcare providers, and corporate wellness programs were expected to purchase or fund the rewards. The separate MHST token was designed to represent an investment in MintHealth. Its offering documents described MHST as non-voting common stock and provided for distributions equal to 10% of VIDA net sales revenue. MintHealth filed an offering statement under Regulation Crowdfunding. There is an important qualification: the company’s SEC offering memorandum stated that VIDA was still under development and had generated no sales at that time. MintHealth is therefore a useful documented example of the proposed two-token design, but its offering documents should not be treated as proof that the complete operating model became a successful business.[2]
Sia: utility for network users and revenue participation for investors. Sia provides another example of separating the interests of users from those of investors. Its Siacoin is the network’s utility token. Customers use Siacoins to purchase decentralized storage, storage providers receive Siacoins as payment, and hosts also use Siacoins as collateral. Siafunds serve a different purpose: they entitle holders to a share of fees generated by storage-related transactions on the network. Sia’s documentation describes a 3.9% fee allocation to Siafund holders. The company treated Siafunds as securities and conducted a Regulation D offering in 2018. The important difference is that Siacoin trades at a market price; it is not an issuer-priced utility token designed to maintain a fixed dollar value. Sia nevertheless demonstrates the central concept: the token used by customers to operate the network can be separate from the investment instrument that gives investors an economic interest in the network’s growth.[3]
These examples are not identical to every feature of the model proposed here. They do, however, demonstrate that separating utility and investment functions is not merely an academic exercise. Projects have explored and implemented structures in which users transact with one token while investors hold a different instrument carrying defined economic rights.
The crypto industry has spent years trying to make one token do everything. It is supposed to raise capital, attract speculators, reward users, provide access to a platform, serve as a means of payment, and increase in value as the business grows. That is a lot to ask of one digital asset.
The underlying idea is simple: do not make customers use an investment vehicle to buy a product, and do not make investors rely on a product token to represent their investment.