Skip to content
Decision guide // updated July 2026

ERC-3643 vs ERC-1400 vs ERC-20: Choosing a Token Standard for Regulated Assets

When ERC-3643, ERC-1400, or a plain ERC-20 is the right call for a regulated asset in 2026, from the team that builds ERC-3643 permissioned tokens.

TL;DR

ERC-3643 (T-REX) is the standardized choice for regulated tokens that need portable on-chain identity and modular compliance across many issuers and jurisdictions. ERC-1400 is the earlier security-token family, still in draft and less actively developed. And a plain permissioned ERC-20, with a strong transfer agent, is the simplest option and remains very common by assets: the largest single tokenized fund, BlackRock's BUIDL, uses exactly that. The right pick depends on how many issuers, how much portable identity, and how much DeFi composability you need, not on which standard is newest.

Protofire builds ERC-3643 permissioned tokens, so we have a commercial stake in this comparison. The sections below name where a plain permissioned ERC-20 or ERC-1400 is the better call, and the regulatory and adoption claims link to their sources. See our other decision guides, including crypto custody and stablecoin models.

Scorecard

At a glance

01ERC-364302ERC-140003Permissioned ERC-20
Standard statusFinalDraft (stagnant)Final (base standard)
Identity layerONCHAINID, on-chain claimsLeft to the implementerNone (off-chain whitelist)
Compliance modelModular, fully on-chainPartitions + off-chain validationCustom off-chain, in transfer agent
On-chain enforcementYes, every transferPartial / implementation-dependentCustom only
Portable identityYes, where issuers trust the same claimsNoNo
Recovery / forced transferYes (agent roles)Yes (ERC-1644)Custom only
Best fitMulti-issuer, multi-jurisdiction securitiesLegacy or partition-heavy structuresSingle-agent funds wanting max liquidity
In detail

The three standards

01

ERC-3643 (T-REX)

The modern permissioned-token standard
Strengths
  • +A Final Ethereum standard with an active Association behind it
  • +On-chain identity (ONCHAINID) and modular, on-chain compliance enforced on every transfer
  • +Reusable identity across issuers that trust the same claim issuers, so an investor verified once can be recognized again
Trade-offs
  • Heavier setup: you stand up identity and registry infrastructure and issue claims
  • By design it limits permissionless-DeFi composability (only claim-holding wallets can hold it)
  • Higher gas and complexity than a plain ERC-20

ERC-3643, the T-REX standard, is a permissioned ERC-20 with a modular, on-chain compliance stack. Eligibility runs on ONCHAINID (on-chain identities holding signed claims), an identity registry, a trusted-issuers registry (who may sign claims), and a claim-topics registry (which claims are required); a transfer only succeeds when both the investor and the offering rules pass. It is a Final Ethereum standard governed by the ERC-3643 Association (90+ members including law firms and financial institutions, DTCC among them), with an open-source reference implementation.

Adoption is meaningful and standardizing: the Association reports over $32B in tokenized assets on the standard, it was presented to the US SEC in 2025 and used in Singapore's Project Guardian pilots, and an ISO standardization initiative is underway. Tokeny's T-REX v4 is a reference-implementation version, extended beyond the frozen EIP, not a separate standard. The trade-off is weight: you run identity and registry infrastructure and issue claims, and by design the token is not freely composable in permissionless DeFi. It is best suited to multi-issuer, multi-jurisdiction regulated securities.

02

ERC-1400

The earlier security-token family (less active)
Strengths
  • +Partitions (ERC-1410) model tranches and share classes cleanly
  • +Document management (ERC-1643) and controller operations (ERC-1644) for forced transfer and recovery
  • +A fit for existing ERC-1400 deployments and partition-heavy structures
Trade-offs
  • Still a Draft EIP that never reached Final; effectively stagnant
  • No standard identity layer; compliance validation is left to the implementer, often off-chain
  • Its originator (Polymath) moved to a separate L1, and exchange and custodian support is thin

ERC-1400 is an umbrella of security-token interfaces: ERC-1594 (core transfers with restriction reason codes), ERC-1410 (partially-fungible partitions for tranches), ERC-1643 (on-chain document links), and ERC-1644 (controller operations for forced transfer and recovery). Pioneered by Polymath around 2018 to 2019, it introduced many ideas the space still uses, especially partitions.

In 2026 it is best described as less actively developed: it never moved past Draft, it deliberately leaves identity and compliance validation to each implementer (usually off-chain), which fragments deployments, and Polymath itself moved to its Polymesh L1. It is not wrong, and it remains situationally valid for existing deployments or partition-heavy structures with an off-chain compliance UX, but momentum on Ethereum has clearly moved to ERC-3643.

03

Permissioned ERC-20

The simplest option, and widely used by AUM
Strengths
  • +The simplest, most liquid, and most universally supported token base
  • +With a strong off-chain transfer agent controlling the whitelist, it is a proven regulated pattern
  • +Maximum integration and composability for the approved set of holders
Trade-offs
  • No standardized on-chain identity or compliance; every restriction is custom code
  • Controls and eligibility depend on trusting an off-chain transfer agent
  • No portable identity across issuers; each deployment reinvents its whitelist

A plain ERC-20 has no notion of investors, jurisdictions, or restrictions, so issuers use it for regulated assets by bolting on off-chain controls: a transfer agent maintains a KYC whitelist and gates mint and transfer in custom code. It is not a security-token standard, but with a capable transfer agent it is a legitimate and widely used pattern.

This is visible at the top of the market: BlackRock's BUIDL, the largest tokenized fund at about $2.5B, is a permissioned ERC-20 run through Securitize's on-chain registry and compliance contracts (its DS Protocol), not ERC-3643 or ERC-1400. The trade-off is that the compliance logic is issuer-specific rather than a shared open standard, with no portable identity across issuers. It is the right choice when a single transfer agent controls the whitelist end to end and you want maximum liquidity for the approved set.

Verdict

Which should you use?

If your priority is
Portable identity and on-chain compliance across issuers

you are issuing regulated securities across multiple issuers or jurisdictions and want auditable, modular, on-chain compliance and reusable investor identity.

ERC-3643
If your priority is
An existing deployment or partition-heavy structure

you already run ERC-1400, or you specifically need partition and tranche modeling with an off-chain compliance UX.

ERC-1400
If your priority is
Simplicity, liquidity, and a single transfer agent

one transfer agent controls the whitelist end to end and you want the simplest, most liquid token for an approved set, the BUIDL model.

Permissioned ERC-20
Also consider

Adjacent and emerging standards

  • ERC-4626 and ERC-7540 vaults: not security-token standards but the yield-vault wrapper, often wrapping a permissioned token underneath. ERC-7540 (async) is the RWA-relevant one, used by Centrifuge, Ondo, and Backed.
  • ERC-7518 (DyCIST) and ERC-1404: ERC-7518 is an emerging ERC-1155-based, semi-fungible, cross-chain compliant standard (Draft, early adoption); ERC-1404 is the minimal restricted-transfer extension for simple lock-ups.
  • Non-EIP frameworks: Polymesh is a security-token-native Layer 1, while Switzerland's CMTAT is a Solidity security-token standard you deploy on a general EVM chain like Ethereum. Pick Polymesh if you want a purpose-built securities chain rather than a general EVM, and CMTAT if you are issuing a compliant token under Swiss law.

FAQ

What is a security token?
A security token is a blockchain token that represents a regulated financial asset, an equity, bond, fund share, or other security, and carries that asset's compliance rules in the token itself. Unlike a plain ERC-20, it enforces who may hold or receive it (identity and eligibility checks, transfer restrictions, and forced transfers for legal recovery) at the contract level, which is why standards like ERC-3643 and ERC-1400 exist. Tokenizing a real-world asset (RWA) means issuing it as one of these tokens so it can settle, transfer, and be managed on-chain while staying inside its legal framework.
Is ERC-3643 better than ERC-1400?
For most new regulated-token projects on Ethereum, yes, but not because it is newer. ERC-3643 is a Final standard with a standard on-chain identity layer (ONCHAINID), modular on-chain compliance, portable investor identity across issuers, and an active Association and ISO initiative behind it. ERC-1400 never moved past Draft, leaves identity and compliance to each implementer (which fragments deployments), and its originator moved to a separate chain. ERC-1400 is still situationally valid for existing deployments or partition-heavy structures, but the momentum and standardization are with ERC-3643.
Can I just use a regular ERC-20 for a tokenized security?
Often, yes, if you pair it with a strong off-chain transfer agent, and it is the dominant pattern by assets. The largest tokenized fund, BlackRock's BUIDL at about $2.5B, is a permissioned ERC-20 run through Securitize's on-chain compliance contracts. The trade-off is that all compliance and identity logic is custom and off-chain-trust-dependent, and there is no portable identity across issuers. It fits when one transfer agent controls the whitelist end to end. It fits less well when you need many issuers to share a compliance and identity layer, or want the rules auditable on-chain, which is where ERC-3643 earns its extra weight.
What is ONCHAINID?
ONCHAINID is the on-chain identity layer ERC-3643 uses, implementing the ERC-734/735 key-and-claim model (note those two base standards themselves never reached Final). Each investor has an identity contract that holds verifiable claims (KYC passed, accredited, jurisdiction) signed by trusted issuers such as a KYC provider. The token does not store personal data; it checks whether an address's identity holds the claims the compliance rules require. Because identity and claims live separately from the token, the same verified identity can be reused across issuers that recognize the same claim issuers and topics, which is the portability that a per-deployment ERC-20 whitelist cannot offer.
Does the standard depend on which regulation applies?
The regulation shapes the compliance rules, not usually the base standard. In the EU, a tokenized fund share is a financial instrument under MiFID II, not a MiCA e-money or asset-referenced token, so MiCA's stablecoin buckets are the wrong frame for tokenized securities; in the US, most tokenized securities use Reg D 506(c) or Reg S private placements. ERC-3643's modular compliance is designed to encode whichever jurisdiction-specific rules apply, which is a reason multi-jurisdiction issuers favor it. We assess the standard against your legal structure with your counsel before building.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last updated: July 2026.

Build it

We build ERC-3643 permissioned tokens with the identity, eligibility, and transfer rules on-chain, plus the vaults, NAV oracles, and proof-of-reserve a regulated asset needs around them.

ERC-3643 development

Book a call with Alejandro Losa

Tokenizing a regulated asset? Talk to us about the right standard and the compliance stack around it.

Protofire 2026. All rights reserved

Message us on Telegram