The site talks about ERC-3643 and permissioned tokens constantly, so here is the plain-language version of what that actually means. A tokenized real asset is a token, and which token standard it uses decides three things that matter: whether it is compliant, who is allowed to hold it, and how liquid it is. This guide explains the three standards you will meet, ERC-20, ERC-1400, and ERC-3643, why compliant real-asset deals land on the permissioned one, and why the same feature that makes a token a legal security is the one that keeps its secondary market thin.
Most compliant EU real-asset security tokens use ERC-3643 (also called T-REX), a permissioned standard on EVM chains where identity and compliance are enforced inside the token, so it only transfers to investors who have been verified and are eligible to hold it. ERC-1400 was the earlier security-token standard that ERC-3643 has largely superseded in practice. ERC-20 is the plain fungible standard behind stablecoins and utility tokens, and it is the wrong tool for a compliant security because it has no transfer restrictions at all.
The one thing to hold onto: the permissioning that makes the token a legal security is the same thing that makes it illiquid. Controlling who can hold it is the requirement, and it necessarily limits the buyer pool.
Here is the whole landscape in one table. The single most important column is the middle one, because whether transfers are controlled is what separates a security token from everything else.
| Standard | Permissioned? | Typical use |
|---|---|---|
| ERC-20 | No. Anyone can hold and transfer | Stablecoins (USDC, USDT), utility tokens, anything meant to move freely |
| ERC-1400 | Yes. Partitions and controller operations | The first security-token standard (Polymath, 2018); largely superseded in practice |
| ERC-3643 (T-REX) | Yes. On-chain identity plus a compliance layer | The de facto standard for compliant real-asset and security tokens on EVM chains |
If you only remember one line: a real-asset security token is a permissioned token, and in 2026 on a general-purpose chain that almost always means ERC-3643. A token that anyone can freely receive is, almost by definition, not a compliant security. The sections below explain each standard and, more usefully, what the choice means for you whether you are issuing the token or buying it.
ERC-20 is the original and most common token standard on Ethereum and compatible chains. It defines a simple, fungible token: a fixed set of functions for checking balances and transferring tokens between addresses. Any address can hold an ERC-20 token, and any holder can transfer it to any other address, with no restriction and no questions asked. It is the standard behind the vast majority of tokens you have heard of, including the big stablecoins: USDC and USDT are ERC-20 tokens.
That total freedom is exactly right for what ERC-20 is for. A stablecoin or a utility token is supposed to move frictionlessly between any two parties; the open, permissionless transfer is the feature, not a bug. It is also why ERC-20 tokens are liquid: anyone can buy or sell them at any time, so deep markets can form.
And it is precisely why ERC-20 is the wrong tool for a compliant real-asset security. A security cannot be held by just anyone. Securities law requires the issuer to control who owns and transfers the instrument, to enforce eligibility (qualified or professional investors only, for a private placement), to run KYC and AML, and often to respect jurisdiction limits, holding limits, and lockups. A plain ERC-20 token can do none of that; it has no concept of who is allowed to hold it. So while a tokenized real-asset deal lives in the same EVM world as ERC-20, the security itself needs a standard that adds the control ERC-20 deliberately leaves out. The classification of the instrument as a security, and why that pulls it under securities law rather than the crypto-asset regime, is covered in the MiCA and CASP licensing guide.
ERC-1400 was the first widely-discussed standard built specifically for security tokens, introduced around 2018 and closely associated with Polymath, one of the oldest names in tokenization. It is not a single function set but a family of related standards, and it tried to encode what a regulated security actually needs:
ERC-1400 was an important step and it shaped everything that came after. In practice, though, it has been largely superseded by ERC-3643 for new real-asset issuance on EVM chains. The reason is not that ERC-1400 was wrong, it is that ERC-3643's model, built around a dedicated on-chain identity system and a modular compliance layer, became the more widely adopted, better-tooled, and more composable approach. ERC-1400 is not dead, and some issuers and platforms still use it or variants of it, but if you are looking at a new compliant real-asset token in 2026, ERC-3643 is the one you are most likely to meet. It is worth noting that Polymath, which drove ERC-1400, went on to build the dedicated Polymesh chain, a different answer to the same problem, covered in the Polymesh roast.
ERC-3643, also known as T-REX, short for Token for Regulated EXchanges, is the permissioned token standard that has become the default for compliant securities on EVM chains. It was originally developed by Tokeny and is now maintained as an open standard by the ERC-3643 Association. It is compatible with ERC-20 at the interface, so it plugs into existing wallets and infrastructure, but it wraps that familiar interface in two components a security needs.
Every holder is tied to an on-chain identity that carries verifiable claims about them: that they have passed KYC, that they are a qualified or professional investor, their jurisdiction, and whatever else the offering requires. The token does not transfer to an address; it transfers to a verified identity that is allowed to hold it. This is the piece that turns a wallet address into a known, eligible investor, which is the foundation of a compliant security.
Every single transfer is checked, before it settles, against the rules of the specific offering: is the receiver whitelisted and eligible, are jurisdiction limits respected, are holding limits and lockups honoured, is the maximum number of holders not exceeded. If a transfer would break any rule, the token rejects it. The rules are modular, so an issuer composes the exact set the offering needs. The compliance is not a policy in a document that someone has to enforce later; it is enforced by the token itself, at every transfer, automatically.
ERC-3643 also gives the issuer's agent the control functions a legal wrapper can require: the ability to freeze, force-transfer, or recover tokens under defined circumstances. That is a feature for compliance and legal enforceability, and a consideration a holder should understand, since it means the token is genuinely a controlled security rather than a bearer instrument.
The plain-English version: ERC-3643 looks like an ordinary token to the infrastructure around it, and behaves like a regulated security in who can actually hold and move it. Only verified, eligible investors can ever receive it, every transfer is checked against the offering's rules, and the issuer keeps the control the law requires. That is why it became the standard the serious real-asset platforms build on, and it is the standard behind most of the EU real-asset SPV deals this site discusses.
The standard is not a technical footnote. It determines real things on both sides of a deal.
Choosing the standard is really choosing the platform and its regulatory stack, because the two come together. A permissioned standard like ERC-3643 means your offering's rules are enforced programmatically: only verified, eligible investors can hold the token, transfers that would breach the terms are blocked by the token itself, and the agent controls your legal wrapper needs are built in. That lowers the ongoing compliance burden and is part of what makes the token a security that regulators and institutional investors can accept. In practice, platforms are built around a standard, Tokeny around ERC-3643, Securitize around its own regulated US stack, Polymesh around base-layer compliance, so the token-standard decision and the platform decision are one decision, walked in the platforms comparison guide.
The standard tells you what you own and how you can move it. A permissioned token means you had to be verified and whitelisted to receive it, and you can only ever sell it to another investor who has cleared the same onboarding. That is the security working as designed, and it is also the reason you should treat the position as a controlled security to hold, not a freely tradable token. It is worth knowing, too, that the issuer's agent may be able to freeze or recover tokens under defined circumstances, which is a compliance feature and a fact to understand before you buy.
The connection everyone misses: the permissioning that makes the token compliant is the same thing that makes it illiquid. Because an ERC-3643 token can only move to a verified, eligible investor, the pool of people who can legally buy your position at any moment is small, which is one of the structural reasons secondary sales are slow and usually at a discount to NAV. This is the standard doing its job, not failing at it, and it is exactly why a permissioned token is a signal to plan the position as hold-to-maturity. The full picture of that is in the exit and liquidity guide, and the token mechanics are point five of the 9-point due diligence checklist.
Everything above is the EVM world, where compliance is added by the token standard on top of a general-purpose chain. That is the dominant model, but it is not the only one, and it is worth knowing the alternative so a deal on different infrastructure does not confuse you.
The other model puts the compliance in the base layer of a dedicated chain. Polymesh is the clearest example: it is a purpose-built chain where identity and permissioning are part of the protocol itself, so a security token does not need an ERC-3643-style standard bolted on, because the chain enforces eligibility natively. It is an elegant idea, and it is a different bet from the EVM approach: build the compliant rails as a chain, versus add compliance to the chains everyone already uses. The trade-offs, and why the market has mostly favoured the EVM-plus-standard model so far, are in the Polymesh roast.
Other general-purpose chains have their own mechanisms for the same goal, for example transfer hooks and token extensions that let a token enforce compliance-style rules. The specific mechanism varies, but the principle is constant across all of them: a real-asset security token, on any chain, must control who can hold and transfer it. Whether that control lives in an EVM token standard like ERC-3643, in the base layer of a chain like Polymesh, or in a chain's token-extension mechanism, the requirement is the same, and it is the requirement, not the mechanism, that defines a security token.
For an operator tokenizing a real asset for a private placement to qualified or professional investors, which is the typical case this site covers, the practical answer is short: a permissioned standard on an EVM chain, in 2026 most commonly ERC-3643, issued through a platform built around it. That gives you the broad EVM ecosystem, programmatic compliance, and a standard institutional investors and their counsel already recognise.
But do not over-index on the standard as an abstract choice, because you rarely pick it in isolation. You pick a platform and a regulatory stack that fit your asset, your jurisdiction, and your investor base, and the standard comes with it. An EU real-asset SPV to professional investors points toward the ERC-3643 model; a US-touching institutional fund points toward a regulated stack like Securitize; a bet on dedicated compliant rails points toward Polymesh. The standard is the consequence of that decision, not the start of it. The decision itself is the subject of the platforms comparison guide, and where it sits in the full raise is in the how-businesses-tokenize guide.
The token standard falls out of the structuring decisions: your asset, your jurisdiction, your investor base, and the compliance your wrapper needs. A strategy call works through those and the platform choice that follows, for your specific raise.
Book a tokenization strategy call →The token standard is one output of a bigger set of decisions: the asset, the jurisdiction, the investor base, the compliance your legal wrapper needs, and the platform that fits all of it. A strategy call works through those for your specific deal, so the token standard is the obvious consequence rather than a guess. For European real-economy businesses with €5M+ in assets or revenue. No pitch, no obligation.
On an EVM chain, the de facto standard for a compliant real-asset security token in 2026 is ERC-3643 (T-REX), a permissioned standard where identity and compliance are enforced in the token so it only transfers to verified, eligible investors. ERC-1400 was the earlier standard it largely superseded. ERC-20 (stablecoins, utility tokens) has no transfer control and is not used for a compliant security. See section 01.
ERC-20 lets any address hold and transfer the token freely, which is right for a stablecoin. ERC-3643 is ERC-20-compatible at the interface but adds an identity layer (ONCHAINID) and a compliance layer that gate every transfer to verified, eligible holders. ERC-20: anyone can hold it. ERC-3643: only verified, eligible investors can. See section 04.
The first security-token standard (around 2018, associated with Polymath): partitions, transfer restrictions with reason codes, controller operations, document management. It shaped the field but has been largely superseded by ERC-3643 for new EVM real-asset issuance. Not dead, but ERC-3643 is what you are most likely to meet in 2026. See section 03.
A permissioned token standard for compliant securities on EVM chains, originally by Tokeny, now maintained by the ERC-3643 Association. Two parts: on-chain identity (ONCHAINID) tying each holder to a verified, eligible identity, and a modular compliance layer that checks every transfer against the offering's rules and blocks any that would break them. Plus agent controls (freeze, recover) the legal wrapper may need. See section 04.
It defines what you own and how you can move it. A permissioned token is a controlled security: you had to be verified to receive it, you can only sell to another onboarded, eligible investor, and the agent may be able to freeze or recover tokens. That control is the point, and it is why the position is hold-to-maturity, not freely tradable. See section 05.
Because the standard enforces your offering's rules automatically and comes bundled with your platform and regulatory stack. Choosing ERC-3643 versus Securitize's stack versus Polymesh is really choosing the platform that fits your asset, jurisdiction, and investors. The standard is the consequence of that decision. See section 07.
Because the permissioning that makes the token compliant also limits who can legally buy it. An ERC-3643 token can only transfer to a verified, eligible investor, so the buyer pool at any moment is small, which is a structural reason secondary sales are slow and usually at a discount to NAV. It is the standard doing its job. Plan the position as hold-to-maturity, per the exit guide.