Token Standards for Regulated Assets: ERC-3643 vs ERC-1400 vs ERC-1404 Compared at the Code Level

Why Regulated Assets Require Specialized Token Standards

A 2026 study of 20 major real-world asset platforms across 23 technical and operational dimensions found that most use hybrid infrastructure. Smart contracts handle token issuance, transfer controls, and redemption, while identity verification, custody, and legal ownership remain connected to off-chain systems.

This creates a clear technical challenge. A standard ERC-20 contract can record balances and transfer tokens. Still, it cannot independently verify investor eligibility, enforce jurisdiction rules, apply lockups, freeze holdings, recover assets, or explain why a regulated transfer failed.

This is where regulated asset token standards differ. ERC-3643 provides a standardized identity and compliance framework. ERC-1400 supports partitioned balances and broader securities lifecycle functions. ERC-1404 offers a lightweight interface for detecting and explaining transfer restrictions.

This code-level comparison examines how ERC-3643 vs ERC-1400 vs ERC-1404 handle investor verification, transfer validation, administrative controls, testing, and integration.

It helps to choose the most suitable standard for a regulated token project. But for the technical and legal framework, read this guide to RWA tokenization architecture, legal structure, and market data.

ERC-3643 vs ERC-1400 vs ERC-1404 at a Glance

ERC-3643 is a final ERC requiring ERC-20 compatibility, on-chain identity, transfer pre-checks, recovery, freezing, pausing, minting, burning, forced transfers, and batch operations. ERC-1400 and ERC-1404 remain marked Draft and stale in the Ethereum EIPs repository.

What Should a Code-Level Comparison Measure?

A meaningful security token standards comparison must go beyond a feature checklist.

Engineering teams should examine:

• Standardized interfaces and external dependencies
• Calls executed before _transfer
• Storage reads and state changes
• Restriction and error handling
• Minting, burning, freezing, and recovery permissions
• Upgrade and administrator authority
• Events available to wallets, exchanges, and indexers
• Unit, fuzz, and invariant testing requirements

Every additional registry, controller, compliance module, and privileged role adds another branch that developers must test and auditors must review.

How Does ERC-3643 Enforce Compliance?

ERC-3643 Contract Architecture

An ERC-3643 implementation separates the token from several supporting contracts:

• Identity Registry
• Identity Registry Storage
• Trusted Issuers Registry
• Claim Topics Registry
• Compliance contract
• Compliance modules

The Identity Registry connects a wallet address to an identity contract and an investor country code. Its isVerified() function checks whether an investor is registered and holds the required claims issued by approved claim issuers.

The Compliance contract evaluates transaction-level rules. These may include approved countries, maximum ownership percentages, investor limits, or restrictions on transfers between investor categories.

How an ERC-3643 Transfer Executes

The following simplified example shows the main execution path:

function transfer(address to, uint256 amount)

    public

    whenNotPaused

    returns (bool)

{

    require(!_frozen[msg.sender] && !_frozen[to]);

    require(amount <= availableBalance(msg.sender));

    require(identityRegistry.isVerified(to));

    require(compliance.canTransfer(msg.sender, to, amount));

    _transfer(msg.sender, to, amount);

    compliance.transferred(msg.sender, to, amount);

    return true;

}

The token checks the pause state, frozen wallets, transferable balance, receiver identity, and offering-level rules before updating balances. It then calls transferred() so the compliance contract can update its state.

ERC-3643 also standardizes functions such as:

• forcedTransfer
• setAddressFrozen
• freezePartialTokens
• mint
• burn
• recoveryAddress
• Batch minting, freezing, burning, and transfers

These interfaces make ERC-3643 a strong permissioned ERC-20 token architecture. However, its multi-contract structure increases deployment complexity, external-call risk, role-management requirements, and audit scope.

How Does ERC-1400 Model Security Tokens?

ERC-1400 is not a small interface. It combines several proposed standards:

• ERC-1410 for partitioned balances
• ERC-1594 for validation, issuance, and redemption
• ERC-1643 for document management
• ERC-1644 for controller operations

Together, these interfaces attempt to model more of the security lifecycle than a basic transfer-restriction hook.

How ERC-1400 Partitions Work

ERC-1400 partitions divide one investor’s balance into subsets with different rights or restrictions.

A token could use partitions for:

• Locked and unlocked holdings
• Primary and secondary-market tokens
• Different share classes
• Jurisdiction-specific balances
• Separate distribution or voting rights

balanceOfByPartition(partition, holder);

partitionsOf(holder);

transferByPartition(partition, to, value, data);

operatorTransferByPartition(...);

The critical accounting invariant is that the sum of an investor’s partition balances must equal that investor’s total token balance.

Transfer Validation and Off-Chain Data

ERC-1400 proposes the following preflight functions:

canTransfer(to, value, data);

canTransferFrom(from, to, value, data);

canTransferByPartition(from, to, partition, value, data);

Instead of returning only true or false, they return a byte status code and additional bytes32 data.

Transfer functions can also receive a byte data parameter. An implementation may use this field for signed broker approval, transfer-agent authorization, or another off-chain input. The data structure remains implementation-specific.

ERC-1400 does not mandate one identity protocol. A deployment may use identity contracts, external registries, signed credentials, or centrally maintained address lists.

This flexibility is valuable, but it creates substantial variation. Developers should inspect the actual repository and deployed bytecode rather than assuming every ERC-1400 implementation behaves identically.

How Does ERC-1404 Restrict Transfers?

ERC-1404 takes a much smaller approach. It extends ERC-20 with two functions:

function detectTransferRestriction(

    address from,

    address to,

    uint256 value

) public view returns (uint8);

function messageForTransferRestriction(

    uint8 restrictionCode

) public view returns (string memory);

The issuer defines the restriction logic and the meaning of each code. Both transfer and transferFrom must evaluate detectTransferRestriction(). A nonzero result should stop the transaction.

A restricted token Solidity implementation could use:

if (!allowed[from]) return 1;

if (!allowed[to]) return 2;

if (block.timestamp < lockedUntil[from]) return 3;

if (balanceOf(to) + value > holdingLimit[to]) {

    return 4;

}

return 0;

A wallet or exchange can call the view function before submitting a transaction. It can then pass the returned code to messageForTransferRestriction() and display a readable explanation.

ERC-1404 does not standardize identity contracts, claim issuers, partitions, documents, freezing, recovery, forced transfers, or compliance modules. Its small interface simplifies initial integration, but almost every regulatory control must be designed, secured, and audited separately.

One Regulated Transfer Implemented Three Ways

Assume Investor A attempts to send 100 tokens to Investor B.

Both investors require valid KYC. Investor B must live in an approved jurisdiction; Investor A’s lockup must have expired, and Investor B cannot exceed the ownership limit.

ERC-3643 Execution Flow

Token.transfer

→ Check pause and frozen balances

→ IdentityRegistry.isVerified(B)

→ Compliance.canTransfer(A, B, 100)

→ Update ERC-20 balances

→ Compliance.transferred(...)

Identity eligibility lives in the registry architecture. Jurisdiction and ownership-limit rules normally sit in the Compliance contract.

ERC-1400 Execution Flow

canTransferByPartition

→ Identify the source partition

→ Evaluate investor eligibility

→ Validate signed transfer data

→ Return status code

→ transferByPartition

→ Update partition balances

Lockups and share classes can be represented through partitions. Identity verification remains implementation-specific.

ERC-1404 Execution Flow

transfer

→ detectTransferRestriction

→ Read whitelist, lockup, country, and cap mappings

→ Return restriction code

→ Revert or update ERC-20 balances

All compliance storage, update procedures, and administrator permissions are custom.

A successful preflight call does not guarantee execution. Identity status, balances, holding limits, or pause conditions may change before mining. The state-changing transfer must repeat every validation check.

Identity, Freezing, and Recovery

ERC-3643 provides the clearest standardized identity infrastructure through wallet mappings, claims, trusted issuers, claim topics, and country codes.

ERC-1400 permits different identity approaches but does not select one. ERC-1404 requires developers to build or integrate their own system.

Raw passports, tax records, and KYC documents should not be placed on-chain. A safer design stores attestations, hashes, eligibility states, expiration dates, and revocation information while keeping personal data off-chain.

Administrative powers also differ:

• ERC-3643 agents can freeze holdings, force transfers, and recover assets.
• ERC-1400 controllers can perform controller transfers and redemptions.
• ERC-1404 requires custom administrative functions.

These capabilities create key-management risk. Use narrowly scoped roles, multisignature authorization, explicit role revocation, timelocks where appropriate, and separate events for every exceptional action.

What Production Repositories Reveal

Official specifications describe interfaces. Public repositories show how regulated token systems are organized in practice.

Tokeny’s original T-REX repository was archived in October 2025 and now directs users to the dedicated ERC-3643 repository. Any new ERC-3643 deployment should use the maintained codebase, pin a reviewed release or commit, and record that version in the deployment documentation.

Polymath’s legacy core contracts are not an ERC-1400 implementation, but their Transfer Manager pattern remains useful as an architectural reference. Polymath separated whitelist checks, investor-count limits, ownership-percentage limits, and manual approvals into modules. That separation makes individual rules easier to test and replace than one large transfer function containing every condition.

Securitize’s DSToken v4 is also separate from the three standards compared here. Its repository describes an ERC-20-compatible system with Registry, Compliance, and Trust services, plus distinct Master, Issuer, Exchange, and Transfer Agent roles. It also includes locking, seizing, trade pausing, bulk operations, and proxy-based upgrades.

The shared lesson is simple: a production-compliant security token smart contract is rarely one contract. Identity, validation, permissions, lifecycle actions, and upgrades must work as one system.

Gas, Storage, and Deployment Complexity

Do not claim one RWA token standard is cheaper without a reproducible benchmark.

Use the same:

• Solidity compiler
• Optimizer settings
• EVM version
• Compliance scenario
• Test accounts
• Proxy architecture
• Storage-access assumptions

Record the repository commit and run Foundry gas snapshots for deployment, onboarding, successful transfers, failed transfers, freezing, forced transfers, partition movements, minting, redemption, and identity updates.

ERC-3643 incurs external identity and compliance calls. ERC-1400 may require additional partition storage writes. ERC-1404 can be smaller, but custom mappings, administrator functions, and upgrade logic still consume gas.

How Should Developers Test Restricted Tokens?

Unit tests should cover invalid identities, expired claims, frozen wallets, partial freezes, active lockups, country restrictions, holding limits, paused transfers, unauthorized administrators, forced transfers, and wallet recovery.

Fuzz transfer values, expiration dates, country codes, partitions, ownership limits, freeze amounts, and operator permissions.

Important invariants include:

• Partition balances equal the total balance.
• Failed transfers do not update the compliance state.
• Frozen holdings cannot move through normal transfers.
• Unauthorized accounts cannot execute forced transfers.
• Recovery does not change total supply.
• Only restriction code 0 succeeds under ERC-1404.

Wallets, exchanges, custodians, and indexers must also track identity updates, freezes, recoveries, partition changes, controller transfers, issuance, redemption, and document events.

ERC-3643 vs ERC-1400 vs ERC-1404: Which Should You Use?

Choose ERC-3643 When

ERC-3643 is suitable when standardized identity, trusted claim issuers, modular compliance, freezing, forced transfers, wallet recovery, and permissioned holding are core requirements.

Consider ERC-1400 When

ERC-1400 is worth considering when the asset requires partitioned balances, multiple share classes, document management, issuance and redemption functions, or controller operations.

However, because the proposal remains in Draft status and is marked stale, the specific implementation, interfaces, and deployed code should be reviewed carefully rather than relying on the ERC-1400 label alone.

Consider ERC-1404 When

Consider ERC-1404 when the project needs a restricted ERC-20 with a small preflight and error-message interface and already has custom identity and compliance infrastructure.

Do not select a standard by its ERC number alone. Review the repository commit, deployed bytecode, proxy configuration, upgrade authority, role assignments, registry dependencies, event coverage, audit scope, and alignment with the asset’s legal documents.

ERC-3643 vs ERC-1400 vs ERC-1404: The Final Code-Level Verdict

ERC-3643 is the strongest standardized architecture for identity-driven permissioned tokens.

ERC-1400 offers the richest model for partitions and security lifecycle operations, but its unfinished status and implementation differences require code-level review.

ERC-1404 is the simplest integration layer, yet it leaves most tokenized asset compliance logic to the developer.

Disclaimer: This article is for educational and technical comparison purposes only. It does not constitute legal, regulatory, investment, or security advice. Token issuers should consult qualified legal counsel, compliance specialists, and smart-contract auditors before selecting or deploying any regulated asset standard.

FAQs

Is ERC-3643 Compatible With ERC-20?

Yes. ERC-3643 requires ERC-20 compatibility but adds identity, compliance, pause, freeze, and transferable-balance checks before tokens move.

Does ERC-1404 Include KYC?

No. It standardizes transfer-restriction detection and message lookup. The issuer supplies the KYC, whitelist, jurisdiction, lockup, and ownership-limit logic.

Which Standard Supports Native Partitions?

ERC-1400 provides partition-specific balances and transfers through functions such as balanceOfByPartition() and transferByPartition().

Which Standard Has the Smallest Integration Surface?

ERC-1404 has the smallest standardized interface. ERC-3643 supplies more built-in infrastructure, while ERC-1400 requires deeper handling of partitions and implementation-specific rules.