What are the differences between security tokens and utility tokens?

A security token and a utility token can use the same technical standard and appear in the same wallet. The relevant difference lies in the rights they confer, their issuance terms and the activities carried out around them. Those factors determine what needs to be assessed before designing a contract, offering the token or enabling trading.

In the European Union, “security token” is a common industry expression. The legal question is whether the asset falls within a category of financial instrument. MiCA defines utility tokens and excludes crypto-assets that qualify as financial instruments. Classification therefore comes before choosing the applicable framework. Product documentation should specify the rights acquired by the buyer and the obligations assumed by the issuer, regardless of the token’s name.

What a security token represents

The term generally describes a token representing a financial instrument, such as certain shares, bonds or units in collective investment undertakings. Each instrument carries its own rights. A share may confer profit participation and voting rights; a bond embodies the terms of a debt. Neither should be reduced to a generic promise of returns.

The MiFID II list of financial instruments contains several categories. For transferable securities, ESMA’s guidelines consider requirements including that the instrument is not an instrument of payment, belongs to a class and is negotiable on the capital market. Those criteria do not replace the tests for other categories.

The technology does not settle the issue either. A record on Ethereum, a private network or a database does not by itself transform an investor’s rights. The legal and economic terms must be examined first, followed by the representation method and the effects of the chosen register.

What utility token means under MiCA

Article 3 of MiCA defines a utility token by its exclusive purpose of providing access to a good or service supplied by its issuer. There is an access right: saying that these tokens confer no rights would be inaccurate.

For a hypothetical example, a provider could issue units redeemable for storage capacity that it supplies itself. Assessing that arrangement would require examining the terms of use, redemption mechanism, transferability and provider obligations. Calling the product a utility token on a website does not establish its classification.

Nor does every utility token necessarily face identical obligations. MiCA’s scope, the type of offer and any applicable exemptions must be examined. An exemption from one requirement is not a general authorisation to issue, intermediate or market any product.

Two examples of the distinction

Consider a token that gives access to an issuer’s service and is consumed when used. The design needs to explain what service is available, how consumption is measured, whether units expire and what happens if the service ends. Users need to know what their balance entitles them to and who owes that obligation.

Now consider a debt issuance represented by tokens. Investors need to understand the borrower, maturity, interest, security, payment priority and consequences of default. A contract can automate parts of recordkeeping or payment processing, but the debtor’s ability to meet its obligations remains an economic and legal matter.

These are analytical examples, not universal classifications. Adding revenue sharing, governance rights or repurchase commitments requires reassessing the complete arrangement. A profit-sharing percentage does not, on its own, determine the relevant legal category.

How classification affects product development

A tokenised financial instrument may require transfer restrictions, holder identification, encumbrance management, recovery and procedures for implementing valid decisions made outside the network. The required functions depend on the instrument and applicable framework. ERC-3643 offers useful technical mechanisms, but implementing the standard does not establish regulatory compliance.

For an access token, the challenge may be coordinating balances with service delivery: preventing duplicate redemption, resolving failed consumption and keeping the application consistent with the contract. The product must also explain which data stays off-chain and who can change its terms.

In both cases, user permissions should be separated from operator permissions. If an account can pause operations, issue tokens or change rules, those powers need documentation and testing. A token’s label does not remove its dependence on administrators.

Documenting classification before issuance

The design file should bring together holder rights, issuance terms, transferability, economic operation, contractual documentation and the activities planned for each participant. Asset classification and the obligations associated with issuance, distribution, custody and trading can then be assessed separately.

Article 2 of MiCA helps establish its scope but does not replace that assessment. In Spain, securities represented using DLT also require consideration of Law 6/2023 and the role of the ERIR. Calling a token a utility does not avoid requirements arising from its actual features.

Once the classification is established, the product, contracts and interface should describe the same right. Changes to the promise made to holders, payment structure or distribution model should trigger a fresh assessment before deployment.