ComparisonAsset Tokenization Studio
ERC-3643 vs ERC-1400: choosing a permissioned token standard for securities
ERC-1400 and ERC-3643 both turn a freely transferable token into one that can refuse a transfer, but they put the intelligence in different places. ERC-1400 gives the token partitions, status-coded transfer checks, document references and controller powers. ERC-3643 binds every holder to an on-chain identity carrying claims from trusted issuers and runs a modular compliance contract on every transfer. This comparison covers both, how Asset Tokenization Studio uses them and how to choose.
On this page
- Why a plain ERC-20 cannot carry a regulated security
- The four interfaces inside ERC-1400
- What an ERC-3643 token checks before a transfer settles
- ERC-1400 and ERC-3643 side by side
- Which parts Asset Tokenization Studio implements
- Picking a standard for the offering in front of you
- Where both standards stop
- Questions and answers
- Sources
Why a plain ERC-20 cannot carry a regulated security
An ERC-20 token moves whenever the holder signs. That is the point of it, and it is exactly what a regulated security cannot allow. A share sold in a private placement may only pass to investors who meet eligibility criteria; a bond may be locked for a period after issue; a court may order a transfer the holder refuses to sign; an investor who loses a key still owns the security and expects it back.
Each of those needs the token to know something the base standard does not track: whether the recipient is eligible, whether a balance is restricted, and who may act without the holder's signature. The two families compared here answer those questions in different ways, and the difference shapes the integrations around the token more than the token itself.
The four interfaces inside ERC-1400
ERC-1400 adds no functions of its own. It is an umbrella over four component standards, proposed together and still listed as a draft2.
- ERC-1410 partially fungible token
- Splits each holder's balance into named partitions with their own metadata, such as locked and unlocked units or separate share classes, and transfers by partition.
- ERC-1594 core security token
- Adds pre-transfer checks that return a status code and a reason, transfers carrying off-chain data such as a signed authorisation, and issuance and redemption functions.
- ERC-1643 document management
- Lets the issuer attach document references and their hashes to the token, for example a prospectus or a term sheet, and emits an event when one changes.
- ERC-1644 controller operations
- Gives a designated controller forced transfer and forced redemption powers, each emitting its own event so the override is visible in the token's history.
What an ERC-3643 token checks before a transfer settles
In ERC-3643, eligibility lives in identity contracts and a compliance contract outside the token, not in the token's own balance logic1.
- Sending holder
Signs an ordinary transfer, as with any ERC-20 token.
- T-REX token
Checks free balance, frozen status and pause state before asking the registries.
- Identity Registry
Links the recipient's wallet to an identity contract and a country code.
- Trusted claim issuers
The KYC or eligibility providers whose signed claims the token accepts, for the claim topics it requires.
- Compliance contract
Applies offering-level rules, such as holder-count or per-investor limits, and updates its state after the transfer.
ERC-1400 and ERC-3643 side by side
| Criterion | ERC-1400 family | ERC-3643 (T-REX) |
|---|---|---|
| Standard status | Draft; the public discussion issue was closed for housekeeping, not as an accepted standard2 | Final ERC, with the token required to remain ERC-20 compatible1 |
| Identity model | Not specified; eligibility is whatever the transfer check implements, often an address allowlist | Each wallet linked to an identity contract holding claims signed by issuers the token trusts |
| Compliance logic | Inside the token's transfer checks, which return a status code and reason for each refusal | A separate, modular compliance contract consulted before and updated after every transfer |
| Classes, tranches and locks | Native partitions, so one token can hold locked and unlocked units or several classes | One balance per token; classes are usually separate tokens and locks use partial freezes |
| Overrides and recovery | Controller transfer and controller redemption, if the token is declared controllable | Forced transfer, wallet freeze, partial freeze and a recovery function for lost wallets |
| Documents | Document references and hashes attached to the token | Not part of the standard; documents are handled outside the token |
| What integrators must support | Partition-aware balances and transfers, and interpretation of status codes | Identity registry lookups and claim issuance, so venues and custodians can onboard holders |
The table compares the standards as written. Individual implementations, including Asset Tokenization Studio, may add or omit features.
Which parts Asset Tokenization Studio implements
Asset Tokenization Studio states ERC-1400 support and partial ERC-3643 support4. Its contract documentation places the ERC-1400 implementation, including partition storage, in the core layer, with ERC-3643 compliance and identity facets alongside KYC, allowlist and blocklist control, freeze, hold and clearing3. The factory that creates each security also deploys the identity contracts it uses for compliance3.
In practice that gives an issuer partitions for share classes and locked balances from the ERC-1400 side, and identity-based eligibility from the ERC-3643 side, in one security. The Studio also adds features neither standard defines, such as hold operations for escrow, clearing workflows that approve pending transfers, record-date snapshots and bond and equity corporate actions5.
The word partial matters. Before relying on a venue, custodian or compliance tool built for T-REX tokens, list the functions it calls and confirm each one exists in the version you deploy. The same applies in reverse for tools expecting ERC-1400 partition calls. Our Asset Tokenization Studio overview explains the contract architecture in more detail.
Picking a standard for the offering in front of you
- If
A private placement where only verified investors may hold, with a lock-up after issue.
ThenLead with ERC-3643-style identity and claims, and implement the lock-up as a partial freeze or a locked partition.
Eligibility is the main rule, and claims let several venues reuse one KYC result.
- If
Fund units in several share classes with different fees or rights.
ThenUse partitions if the classes share a register and corporate actions; use separate tokens if they are legally separate instruments.
Partitions keep one cap table, while separate tokens keep each class's rules independent.
- If
A bond issued in tranches with different coupons or maturities.
ThenIssue each tranche as its own security unless the tranches are fungible after a seasoning period.
Coupon and maturity logic is configured per security, and fungibility rules are easier to audit that way.
- If
Distribution through venues and custodians that already onboard T-REX tokens.
ThenConfirm they can work with the subset of ERC-3643 your deployment implements before committing.
Their onboarding flow depends on identity registry calls that a partial implementation may not expose.
- If
The offering needs on-chain proof of which document version investors were shown.
ThenUse ERC-1643 document hashes or an equivalent timestamped record.
ERC-3643 does not define a document interface.
Where both standards stop
Questions and answers
Can a security token migrate from ERC-1400 to ERC-3643 later?
Not in place. The two standards store eligibility and balances differently, so migration means issuing a new token, moving holders across under a controlled process and retiring the old one, usually with the transfer agent confirming the register at each step. Plan the standard before issuance; a later switch is a corporate action with legal and operational work, not a software update.
Which standard do custodians and trading venues support?
It varies by firm and changes often, so ask each one directly rather than relying on marketing lists. Ask which functions they call during onboarding, transfers and corporate actions, whether they handle partitions, and whether they issue or accept identity claims. Then compare those answers with the exact feature set of the token version you plan to deploy.
Are ERC-3643 and ERC-1400 specific to Hedera?
No. Both were written for EVM-compatible networks and are used on several of them. Hedera's smart contract service runs EVM bytecode, which is why Asset Tokenization Studio can implement both patterns there. What is specific to the Studio is its combination of the two, its added features such as hold and clearing, and its diamond-proxy upgrade model.
Does ERC-3643 put investors' personal data on-chain?
It should not. The standard links a wallet to an identity contract that holds claims, which are signed statements from trusted issuers that a check was passed. A sound design keeps the underlying documents and personal details with the KYC provider off-chain and publishes only what the transfer check needs, such as a claim topic, an issuer signature and a country code.
Sources
- ERC-3643: T-REX - Token for Regulated EXchanges — Ethereum Improvement Proposals · checked 10 October 2026
- ERC 1400: Security Token Standard (discussion issue) — Ethereum EIPs on GitHub · checked 10 October 2026
- ATS contract architecture overview — Hashgraph on GitHub · checked 10 October 2026
- Asset Tokenization Studio repository — Hashgraph on GitHub · checked 10 October 2026
- ATS capabilities overview — Hashgraph on GitHub · checked 10 October 2026