A security token, in the capital-markets sense rather than the two-factor authentication key on a keyring, is a blockchain token that carries a financial claim: equity, debt, a fund unit, a share of revenue, or a fractional interest in an asset. Because it carries that claim, who may hold it is restricted, and those restrictions are enforced by the token contract itself rather than by paperwork alongside it.
The technical signature of a security token is not what it represents. It is that transfers are conditional. A utility token moves to any address; a security token asks an identity registry and a rule engine for permission first, and reverts if the answer is no.
Scroll to see the full diagram
What the instrument is
A security token represents complete or fractional ownership interests in assets or entities, which is the framing the ERC-1400 documentation uses and the one that travels most cleanly across jurisdictions.1 Shares in a company, a note, a unit in a fund, an interest in real estate or intellectual property: the token is a record of that claim, and the claim exists in law before the contract exists in code.
Whether a specific token meets the legal definition of a security is a separate question with its own machinery. In the United States that runs through the Howey investment-contract analysis, and in the European Union it turns first on whether the asset qualifies as a MiFID financial instrument, which places it outside MiCA. Both are treated properly on their own pages, and the answer for any particular instrument depends on its own facts and is a call for counsel.
What belongs here is the design side. Once counsel has made that call, a set of technical requirements follows, and those requirements are unusually concrete.
Permissioning is the defining technical feature
The ERC-1400 documentation states the distinction cleanly: utility tokens have no limitations on who can send or receive the token, while security tokens are subject to many restrictions based on identity, jurisdiction and asset category.1 That single sentence is most of the engineering brief.
It means the token cannot rely on a wallet address as the unit of identity. It needs to know that address belongs to a verified person or entity, that the entity is eligible in its jurisdiction, that the transfer does not breach a holder cap or a lockup, and that the receiving side is equally verified. All of that has to be checked before the transfer settles, not reconciled afterwards.
NIST's overview of token design makes the neutral version of the point: token behaviour, including restriction and custody arrangements, is a matter of design and management choices rather than an inherent property of the technology.2 Nothing about a blockchain forces a token to be transferable to anyone.
Two standards, two ways of writing the rules
ERC-3643, the T-REX standard, states its requirements directly: it must be ERC-20 compatible, must be used in combination with an onchain identity system, must be able to apply any rule of compliance required by the regulator or the token issuer, and must expose an interface to pre-check whether a transfer will pass before it is submitted.3 The rules live in an identity registry and a compliance contract that the token calls, so an issuer can change a country restriction or a holder cap without redeploying the asset.
ERC-1400 takes a different route. It is described as a standard incorporating differentiated ownership, error signalling, document references, gate keeper access control and issuance and redemption semantics.1 Differentiated ownership is the part worth understanding: balances are separable, so one instrument can carry a restricted tranche and an unrestricted tranche with different rules on each.
Purpose-built chains take the same ideas down a layer. Polymesh describes itself as inspired by ERC-1400 while adding capabilities around governance, identity, compliance, confidentiality and settlement at the protocol level rather than in a contract.4 The tradeoff is the usual one: fewer moving parts inside your own code, and a smaller surrounding ecosystem to integrate with.
The powers the issuer keeps, and why they exist
Permissioned instruments almost always retain three capabilities that make crypto-native engineers uncomfortable. The ability to freeze and unfreeze transfers for a holder or the whole asset. The ability to force a transfer. And a recovery process that reissues a holder's balance to a new address.4
These are not backdoors bolted on for convenience. A transfer agent that cannot execute a court order, honour a probate transfer or reissue a position after a lost key is not a transfer agent, and a registered instrument that cannot do those things does not satisfy the obligations of the register it represents.
That said, the powers are the diligence surface. Who holds them, behind what approval, with what disclosure to holders, and with what public record when they are used. In our view an issuer who has not written those answers down before launch has not finished designing the instrument, and holders reading the contract will find the powers whether the documentation mentions them or not.
What permissioning costs in distribution
A token that reverts on transfer to an unverified address is incompatible with most of what makes onchain assets interesting. It cannot sit in a permissionless liquidity pool, because the pool contract is not a verified holder. It cannot be posted as collateral in a lending market that knows nothing about your identity registry. It cannot cross a generic bridge, because the bridge's escrow address is unverified on the far side.
So the venue list is chosen at the same moment as the compliance stack, and it is much smaller than the one an open token reaches. Teams routinely discover this after deployment, when a listing conversation ends with the integration question rather than the commercial one.
The honest framing for a founder is that permissioning buys enforceability at the price of reach. Whether that trade is worth making depends entirely on whether the eligible buyer set was ever going to be large, which is a business question rather than a technical one.
The order these decisions have to happen in
Five things, in this order. What the claim legally is and which entity in which jurisdiction issues it. Which exemption or authorisation the offering relies on. Who is permitted to hold, expressed as rules a contract can evaluate rather than prose in a subscription document. The written list of venues the token must reach. And only then the standard, with the admin powers enumerated and each one assigned an owner and an approval path.
Doing it in that order means the standard choice is nearly automatic by the time you reach it. Doing it in reverse produces the pattern we see most often in diligence: a deployed contract, then a compliance requirement, then restrictions retrofitted onto a design that assumed open transfers.
Nothing on this page is legal advice or a recommendation to buy, sell or hold anything. Classification is fact-specific and jurisdiction-specific and belongs with your legal team. The design consequence is what sits here: a security token is a legal instrument with a settlement layer attached, and the instrument is the part that has to be right first.
Common questions
What is a security token in crypto?
A security token is a blockchain token carrying a financial claim such as equity, debt, a fund unit or a fractional interest in an asset, described in the ERC-1400 documentation as complete or fractional ownership interests in assets or entities.1 It is a different thing from the two-factor authentication device also called a security token. The crypto sense is an instrument; the hardware sense is a login credential.
How is a security token different from a utility token?
Technically, by who is allowed to hold it. Utility tokens have no limitations on who can send or receive them, while security tokens carry restrictions based on identity, jurisdiction and asset category enforced at transfer time.1 Legally, by what the holder is promised: a claim on returns rather than access to a product. The legal test is applied to the specific facts of an offering and is a matter for counsel.
What token standard do security tokens use?
ERC-3643 and ERC-1400 are the two in institutional use. ERC-3643 requires ERC-20 compatibility, an onchain identity system, the ability to apply any compliance rule set by a regulator or issuer, and a pre-check interface for transfers.3 ERC-1400 covers differentiated ownership, error signalling, document references, operator access control and issuance and redemption semantics.1 Purpose-built chains such as Polymesh implement comparable logic at the protocol layer.
Can an issuer freeze or claw back a security token?
In most permissioned designs, yes, and deliberately so. Freeze and unfreeze, forced transfer and a holder recovery process are standard capabilities on security-token platforms.4 They exist because a registered instrument has to be able to honour court orders, probate transfers and lost-key recovery. The diligence question is not whether the powers exist but who holds them, behind what approval, and with what record when they are used.
See RWA Tokenomics Design for how this applies in practice.
Sources
- ERC-1400: Security Token Standard
thesecuritytokenstandard.org, 2018
Defines security tokens as complete or fractional ownership interests in assets or entities, contrasts them with utility tokens on holder restrictions, and lists differentiated ownership, error signalling, document references, operator access control and issuance and redemption semantics. Maintained outside the formal EIP process. - NISTIR 8301: Blockchain Networks, Token Design and Management Overview
National Institute of Standards and Technology, 2021
A technical overview and conceptual framework of token designs and management methods, covering token types and how they are held in custody. - EIP-3643: T-REX, Token for Regulated EXchanges
Ethereum Improvement Proposals, 2021
Requires ERC-20 compatibility, an onchain identity system, the ability to apply any compliance rule required by regulator or issuer, and a transfer pre-check interface. - What is a Security Token?
Polymesh Association, 2026
Describes Polymesh as inspired by ERC-1400 with added governance, identity, compliance, confidentiality and settlement capability, and lists controller access for token recovery, transfer freezing and onchain ownership records.
Last reviewed 2026-08
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
100+ projects advised. Complete tokenomics in 4 to 6 weeks.