ERC-3643 vs ERC-1400: Security Token Standards

ERC-3643 and ERC-1400 are the two dominant Ethereum standards for permissioned security tokens, and they solve the same problem — enforcing who can hold and transfer a regulated instrument — with different architectures. ERC-3643 (the T-REX protocol) binds every token holder to an on-chain identity and verifies eligibility at transfer time; ERC-1400 is a modular framework built around partitions, document references, and controller operations. For most new multi-jurisdiction offerings in 2026, ERC-3643 is the default choice because it is a finalized official ERC with the larger active ecosystem — but ERC-1400's partition model still fits instruments with multiple share classes or tranche-level restrictions. The honest answer, though, is that the standard matters less than the compliance system feeding it.

Why Plain ERC-20 Fails for Securities

An ERC-20 token has exactly one transfer rule: anyone holding tokens can send them to any address. That is disqualifying for a security, for three reasons:

• No transfer restrictions. Securities sold under exemptions like Reg D carry resale limitations and holding periods. ERC-20 has no mechanism to block a transfer to an ineligible buyer.
• No identity binding. An ERC-20 balance belongs to an address, not a person. If an investor fails re-KYC, lands on a sanctions list, or loses their keys, the contract neither knows nor cares. Regulators do.
• No issuer controls. There is no native way to freeze a position, execute a court-ordered transfer, or recover tokens from a lost wallet. For a registrar maintaining a legal ownership record, those are operating requirements, not edge cases.

Both ERC-3643 and ERC-1400 close these gaps. They stay ERC-20 compatible at the interface level (wallets and explorers can read balances), but every transfer passes through a compliance gate before it settles.

ERC-3643 (T-REX): Identity-Bound Permissioned Tokens

ERC-3643 — originally the T-REX ("Token for Regulated EXchanges") protocol developed by Tokeny — is a suite of interoperating contracts rather than a single token contract. Per the EIP-3643 specification, the architecture separates the token from the machinery that decides who may hold it:

• ONCHAINID. Each investor controls an on-chain identity contract that stores keys and verifiable claims (KYC passed, accreditation verified, country of residence). The identity — not the wallet address — is the unit of eligibility, so one investor can hold through multiple wallets under a single verified identity.
• Identity Registry. Maps wallet addresses to ONCHAINID contracts and holds investor country codes. Only addresses registered here can receive tokens.
• Trusted Issuers Registry and Claim Topics Registry. Define which claim providers (KYC vendors, licensed verifiers) the issuer trusts, and which claims are required. Compliance is delegated to attestations from named claim issuers, not hard-coded into the token.
• Modular Compliance contract. Enforces offering-level rules on every transfer: jurisdiction limits, maximum holder counts, per-investor caps, lockup windows. Every transfer() call checks both identity eligibility and compliance rules before executing — a non-compliant transfer simply reverts.
• Recovery and agent controls. If an investor loses wallet access, an issuer agent can verify the investor against their ONCHAINID and force-move the balance to a new address, per the ERC-3643 documentation. Agents can also freeze addresses or partial balances.

Two governance facts matter for institutional buyers. First, ERC-3643 is a finalized, official Ethereum ERC — it completed the EIP process and carries Final status at eips.ethereum.org. Second, stewardship moved from a single vendor to the nonprofit ERC3643 Association, which reports more than $32 billion in assets tokenized with the standard and cites engagement with the SEC's Crypto Task Force. Treat vendor-reported adoption figures as directional, but the trajectory is clear: ERC-3643 has become the default permissioned token standard on EVM chains, and it deploys anywhere the EVM runs — public mainnets or private, permissioned networks.

ERC-1400: The Partition-Based Framework

ERC-1400, driven primarily by Polymath, took a different route. It is an umbrella framework — a library of sub-standards designed to interoperate, per the Security Token Standard specification:

Sub-standard	Function
ERC-1410	Partially fungible tokens — balances divided into partitions (originally "tranches") that can carry different transfer rules
ERC-1594	Core issuance and transfer validation, including canTransfer checks that return machine-readable reason codes
ERC-1643	Document management — attaching offering memoranda and legal documents to the token contract with hashes
ERC-1644	Controller operations — forced transfers and redemptions by an authorized controller, with mandatory on-chain events

The distinctive ideas are worth taking seriously:

• Partitions let a single token contract represent multiple classes or states of the same security — locked vs. unlocked balances, Class A vs. Class B shares, Reg D vs. Reg S tranches — each with its own restrictions.
• On-chain documents (ERC-1643) bind the legal paper to the token natively.
• Explicit controller semantics (ERC-1644) make forced transfers a first-class, auditable operation: if isControllable() returns true, the controller can move tokens without holder consent, and every such action emits a ControllerTransfer event.

The caveat is ecosystem trajectory. ERC-1400 never completed the EIP process — it lives as Ethereum issue #1411 and a community-maintained spec rather than a finalized ERC. And Polymath, its principal author, subsequently launched Polymesh, a purpose-built layer-1 for regulated assets, shifting its center of gravity away from Ethereum-based ERC-1400 deployments. ERC-1400 remains in production use — custody-technology firm Taurus has published ERC-1400 deployment work, and earlier adopters included ConsenSys and BNP Paribas — but new tooling investment has visibly consolidated around ERC-3643.

Head-to-Head Comparison

Dimension	ERC-3643 (T-REX)	ERC-1400 family
Identity model	On-chain identity (ONCHAINID) with verifiable claims from trusted issuers; eligibility attached to the person, not the wallet	No native identity layer; eligibility typically enforced via external whitelist or off-chain checks feeding canTransfer
Transfer control	Every transfer validated against identity registry + modular compliance rules; non-compliant transfers revert	canTransfer validation with reason codes; enforcement logic left to the implementer
Partitions / tranches	Not native (one token = one instrument; classes handled as separate tokens or compliance rules)	Native partitions (ERC-1410) — multiple classes and lock states in one contract
Corporate actions & documents	Handled at platform layer; agent roles for issuer operations	Native document attachment (ERC-1643); controller framework for corporate events
Forced transfer / recovery	Built-in recovery via ONCHAINID re-verification; agent freeze and forced transfer	Controller operations (ERC-1644) with explicit on-chain controller events
Standard status	Official ERC, Final status (EIP-3643)	Never finalized as an ERC; community-maintained framework
Governance	ERC3643 Association (nonprofit, multi-member)	Historically Polymath-driven; Polymath moved focus to Polymesh
Ecosystem adoption	$32B+ tokenized per the ERC3643 Association; broad vendor and platform support	Established legacy deployments; slower new-tooling momentum
Auditability	Multiple audited reference implementations; compliance decisions readable on-chain	Reason-code model aids auditability; implementation quality varies by vendor
Chain support	Any EVM chain, public or permissioned	Any EVM chain, public or permissioned

The US Compliance Angle: Reg D and Reg S

Neither standard makes an offering compliant — exemption strategy, disclosure, and filings live in the legal workstream, which is why every serious project runs token design and securities compliance in parallel, in coordination with qualified counsel. But the standards map to US requirements differently:

• Accredited-investor gating (Reg D 506(b)/506(c)). ERC-3643 expresses "accredited" as a claim on the investor's ONCHAINID, signed by a trusted verifier — the token itself checks it on every transfer. ERC-1400 achieves the same outcome through whitelist logic behind canTransfer, which works, but the eligibility source of truth sits outside the standard.
• Holding periods and lockups. Rule 144-style resale restrictions can be encoded as time-based compliance rules in ERC-3643's modular compliance contract, or — quite elegantly — as a locked partition in ERC-1400 that converts to an unlocked partition at expiry.
• Reg S / Reg D separation. Offerings sold simultaneously offshore and onshore need to keep the tranches from bleeding into each other during the distribution compliance period. This is ERC-1400's strongest use case: two partitions, two rule sets, one instrument. In ERC-3643 the same separation is handled with country-code rules in the compliance module or separate token deployments.
• Court orders and error correction. Both standards support forced transfers — ERC-1644's controller operations and ERC-3643's agent recovery — which registrars need for garnishments, estate transfers, and fat-finger corrections. Whether and when to exercise those powers is a legal and governance question, not a technical one.

What Matters More Than the Standard

Here is the part vendor comparisons skip: the token standard is the enforcement surface, not the compliance program. Three things above the contract layer determine whether your offering actually stays compliant:

1. The registry of record. Someone must maintain the legally authoritative ownership record and keep it reconciled with on-chain state. If the token and the register disagree, the register wins in court — so the reconciliation process matters more than the token's bytecode.
2. The compliance rules engine. Claims expire. Sanctions lists update daily. Accreditation lapses. The off-chain system that decides who gets whitelisted and when they come off is where compliance actually happens; the standard just refuses transfers based on what that system last told it.
3. Issuer control and deployment. Who holds the agent keys, who can update compliance modules, and where the stack runs. Institutions with data-residency or key-control requirements increasingly choose on-premise deployment of the full tokenization stack rather than shared SaaS — the standard is identical either way; the control model is not.

This is also why build-vs-buy is the real decision. Deploying an audited ERC-3643 suite is weeks of work; building the identity pipeline, rules engine, and registry reconciliation around it is the 18-month project — a trade-off we break down in our developer guide to building an RWA platform. Across the 32 deals structured on Asset Haus infrastructure spanning 9+ jurisdictions, the standard choice was rarely the hard part; wiring it to a defensible compliance program was.

Alternatives, Briefly

Two non-standard approaches show up in evaluations and deserve awareness-level mention:

• ERC-20 plus external allowlist wrapper. A vanilla ERC-20 with transfers routed through a gatekeeping contract. Simpler to ship, but identity, recovery, and rule semantics are all bespoke — you inherit none of the audit history or tooling of a standard, and every integrator must learn your custom logic.
• Non-EVM approaches. Purpose-built chains like Polymesh bake identity and compliance into the protocol layer, and permissioned ledgers (Hyperledger-family, R3 Corda) remain common in bank consortia. These trade EVM ecosystem breadth for protocol-level guarantees — a reasonable trade for closed networks, a costly one if you may ever need public-chain distribution.

Decision Framework

• Choose ERC-3643 if you are launching a new offering, need multi-jurisdiction investor eligibility enforced on-chain, want a finalized official standard with active governance and the broadest current tooling, or expect institutional counterparties to ask "which standard?" and want the consensus answer.
• Choose ERC-1400 if your instrument genuinely needs partitions — multiple share classes or Reg D/Reg S tranches inside one contract — or you are extending an existing ERC-1400 deployment where migration costs outweigh ecosystem benefits.
• Choose neither in isolation. Score platforms on the registry, rules engine, and deployment model (SaaS, white-label, or on-premise) before the token layer — our comparison of real estate tokenization platforms shows how the same standard performs very differently depending on the infrastructure around it, and our case studies show what those stacks look like in production.

Under a structured evaluation, most teams reach a defensible standard decision in days. Getting the surrounding compliance architecture right is what the rest of a 120-day launch model is for.

FAQ

Is ERC-3643 an official Ethereum standard?

Yes. ERC-3643 completed the EIP process and holds Final status at eips.ethereum.org. ERC-1400, by contrast, was never finalized as an ERC — it remains a widely referenced community framework maintained outside the official EIP repository.

Can ERC-3643 tokens be used for Reg D offerings?

Yes — accreditation is expressed as a verified claim on the investor's on-chain identity, and lockups and resale restrictions are enforced by the compliance module at transfer time. The standard enforces the rules; defining them correctly for a 506(b) or 506(c) offering is legal work done in coordination with qualified counsel.

Which standard do major platforms use?

ERC-3643 has the broader current footprint — the ERC3643 Association reports $32B+ in assets tokenized with the standard, with adopters across Europe, the US, and the Gulf. ERC-1400 persists in legacy and bank-led deployments (Polymath, its author, later shifted to its own Polymesh chain). Asset Haus infrastructure deploys ERC-3643 by default, with $200M+ facilitated across deals on the platform.

Can I migrate from ERC-1400 to ERC-3643?

Yes, but it is a reissuance, not an in-place upgrade: deploy the new token, re-verify holders into the identity registry, and swap balances under issuer control. Both standards' forced-transfer capabilities make the mechanics tractable; the effort sits in re-papering and investor communications.

Does the token standard make my offering compliant?

No. The standard is an enforcement mechanism for rules defined elsewhere — in your exemption strategy, offering documents, and eligibility policies. A perfectly implemented ERC-3643 token with wrong compliance rules is still non-compliant. Evaluate the registry, rules engine, and issuer controls first; the standard second.

Choosing a token standard for a live offering? Request a platform assessment and get a standard-and-architecture recommendation mapped to your jurisdictions.