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.

Reviewed 7 min read

On this page
  1. Why a plain ERC-20 cannot carry a regulated security
  2. The four interfaces inside ERC-1400
  3. What an ERC-3643 token checks before a transfer settles
  4. ERC-1400 and ERC-3643 side by side
  5. Which parts Asset Tokenization Studio implements
  6. Picking a standard for the offering in front of you
  7. Where both standards stop
  8. Questions and answers
  9. 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.

transfer requestis recipient verified?check required claimsclaims validcan transfer?rules passrecord transfer01Sending holder02T-REX token03IdentityRegistry04Trusted claimissuers05Compliancecontract
  1. Sending holder

    Signs an ordinary transfer, as with any ERC-20 token.

  2. T-REX token

    Checks free balance, frozen status and pause state before asking the registries.

  3. Identity Registry

    Links the recipient's wallet to an identity contract and a country code.

  4. Trusted claim issuers

    The KYC or eligibility providers whose signed claims the token accepts, for the claim topics it requires.

  5. Compliance contract

    Applies offering-level rules, such as holder-count or per-investor limits, and updates its state after the transfer.

  1. Sending holder to T-REX tokentransfer request
  2. T-REX token to Identity Registryis recipient verified?
  3. Identity Registry to Trusted claim issuerscheck required claims
  4. Trusted claim issuers to Identity Registryclaims valid
  5. T-REX token to Compliance contractcan transfer?
  6. Compliance contract to T-REX tokenrules pass
  7. T-REX token to Compliance contractrecord transfer
Conceptual message order for a compliant ERC-3643 transfer, simplified from the standard; a failure at any step reverts the transfer.

ERC-1400 and ERC-3643 side by side

CriterionERC-1400 familyERC-3643 (T-REX)
Standard statusDraft; the public discussion issue was closed for housekeeping, not as an accepted standard2Final ERC, with the token required to remain ERC-20 compatible1
Identity modelNot specified; eligibility is whatever the transfer check implements, often an address allowlistEach wallet linked to an identity contract holding claims signed by issuers the token trusts
Compliance logicInside the token's transfer checks, which return a status code and reason for each refusalA separate, modular compliance contract consulted before and updated after every transfer
Classes, tranches and locksNative partitions, so one token can hold locked and unlocked units or several classesOne balance per token; classes are usually separate tokens and locks use partial freezes
Overrides and recoveryController transfer and controller redemption, if the token is declared controllableForced transfer, wallet freeze, partial freeze and a recovery function for lost wallets
DocumentsDocument references and hashes attached to the tokenNot part of the standard; documents are handled outside the token
What integrators must supportPartition-aware balances and transfers, and interpretation of status codesIdentity 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.

    Then

    Lead 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.

    Then

    Use 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.

    Then

    Issue 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.

    Then

    Confirm 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.

    Then

    Use 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

  1. ERC-3643: T-REX - Token for Regulated EXchanges — Ethereum Improvement Proposals · checked 10 October 2026
  2. ERC 1400: Security Token Standard (discussion issue) — Ethereum EIPs on GitHub · checked 10 October 2026
  3. ATS contract architecture overview — Hashgraph on GitHub · checked 10 October 2026
  4. Asset Tokenization Studio repository — Hashgraph on GitHub · checked 10 October 2026
  5. ATS capabilities overview — Hashgraph on GitHub · checked 10 October 2026

More in Asset Tokenization Studio

Back to Asset Tokenization Studio

Next step

Check your venue and custodian requirements against the Studio

Send us the offering summary and the venues or custodians you plan to use. We will map the functions they expect against the Asset Tokenization Studio version you would deploy and flag the gaps.

Review a token standard choice