Dissecting ERC-1400 and ERC-3643: The Technical Case for a New Standard

TL;DR

We have philosophically argued the necessity of a Standards Track EIP in previous research. Now it’s time to prove that argument with code.

• ERC-1644’s controllerTransfer treats legally distinct regulatory actions—FREEZE, SEIZE, CONFISCATE—as a single function, and the non-standardization of the _data parameter makes on-chain verification impossible.
• The four sub-standards of the ERC-1400 ecosystem (ERC-1594, 1410, 1643, 1644) were proposed independently, causing integration complexity and satisfying only ~40% of the 31 regulatory requirements.
• ERC-3643’s monolithic structure does not account for cross-chain environments and cannot apply differentiated regulations by asset class.
• However, the new standard is not an isolated replacement. Through ERC-1400 compatibility adapters, it ensures continuity with the existing ecosystem, and its modular structure enables gradual adoption. This is evolutionary succession, not destruction.

Introduction: Code Doesn’t Lie

In our previous research, we posed a critical question: Can regulatory compliance be achieved with an Informational EIP alone? The answer was clear. A conceptual framework is a necessary condition, but not a sufficient one. Enforceability—the ability for regulatory authorities to freeze, seize, and confiscate assets—only becomes meaningful when implemented as executable code.

Now it’s time to support that philosophical argument with technical evidence.

ERC-1400 and ERC-3643 are pioneers in security token standardization. Proposed by Polymath in 2018, ERC-1400 was the first to systematize the concept of security tokens, while Tokeny’s ERC-3643 (T-REX) was the first standard to implement actual regulatory compliant tokens. Without them, neither our research nor ERC-TRUST would exist.

However, respect and objective analysis can coexist. In this article, we will deeply dissect the code of existing standards to prove why a new standard is technically inevitable. At the same time, we will demonstrate how the new standard maintains compatibility with the existing ecosystem, walking the path of “evolutionary succession” rather than replacement.

The Uncomfortable Discovery

To be honest, we initially tried to extend ERC-1400.

Compatibility with the existing ecosystem was important, and building on a proven codebase seemed safe. There was no reason not to leverage the infrastructure that Polymath and Securitize had already used to issue hundreds of tokens. Our early design documents were titled “ERC-1400 Extension.”

However, the moment we tried to map RCP’s six regulatory actions to ERC-1644’s controllerTransfer, we hit a fundamental wall.

FREEZEd assets can be released. When a regulatory investigation ends, the freeze is lifted, and the asset regains liquidity. But CONFISCATEd assets are permanent. Ownership itself is revoked, and the previous owner can claim no legal rights. SEIZE is somewhere in between—ownership is retained but control is lost.

These three states have completely different legal meanings. But can we express this difference with controllerTransfer‘s _data parameter—a free-form byte array? Technically, yes. But it cannot be verified on-chain. Smart contracts cannot distinguish between FREEZE and CONFISCATE, so there’s no way to enforce different legal effects through code.

“We reached the conclusion that a new standard, not an extension, was inevitable. It was not a choice but a discovery.”

ERC-1400 Ecosystem: The Fragmentation Dilemma

Structural Complexity

ERC-1400 is not a single standard. It is an ecosystem composed of four sub-standards:

This modularization provides flexibility but also causes serious integration complexity. Each sub-standard was proposed independently, and interdependencies are not clearly defined. Developers must determine which combinations are necessary, and incomplete implementations leave regulatory gaps.

The Fatal Limitation of controllerTransfer

ERC-1644 defines an interface for regulatory authority enforcement actions. Its core is the controllerTransfer function:

// ERC-1644: Controller Token Operations
function controllerTransfer(
    address _from,
    address _to,
    uint256 _value,
    bytes calldata _data,
    bytes calldata _operatorData
) external;

This single function handles all controller actions. The problem is the _data parameter. Theoretically, you can encode the action type here, but the standard doesn’t define its format:

// Implementation A's approach
bytes memory data = abi.encode("FREEZE", block.timestamp, "Regulatory investigation");

// Implementation B's approach
bytes memory data = abi.encode(uint8(1), uint256(30 days)); // 1 = freeze, duration

// Implementation C's approach
bytes memory data = ""; // Not used at all

// Result: 0% interoperability, on-chain verification impossible

Each implementation can use a different encoding method, and interoperability is not guaranteed. More critically, on-chain verification is impossible. You cannot write logic within a contract to distinguish FREEZE from CONFISCATE, so you cannot enforce differentiated state transition rules for each action.

RCP’s six regulatory actions each have unique legal meanings and state transition rules:

• FREEZE: Temporary trading halt, reversible, ownership retained
• SEIZE: Forced custody by court order, ownership retained but control lost
• CONFISCATE: Permanent revocation of ownership, irreversible
• LIQUIDATE: Debt repayment through forced sale
• RESTRICT: Partial trading restrictions, conditionally allowed
• RECOVER: Return of stolen/fraudulent assets to original owner

These differences cannot be expressed with a single function’s non-standardized _data parameter.

ERC-3643: The Monolithic Constraint

Identity Registry: Innovation and Its Boundaries

ERC-3643 (T-REX) introduced an innovative approach called Identity Registry. All token holders are linked to verified identities, and transferability is determined by identity verification status.

// ERC-3643 Identity Registry Interface
interface IIdentityRegistry {
    function isVerified(address _userAddress) external view returns (bool);
    function identity(address _userAddress) external view returns (IIdentity);
    function registerIdentity(
        address _userAddress,
        IIdentity _identity,
        uint16 _country
    ) external;
    
    // Limitation 1: No cross-chain state synchronization mechanism
    // Limitation 2: No differentiated verification levels by asset class
    // Limitation 3: Real-time propagation of KYC status changes impossible
}

This was an important advancement in protocol-level integration of regulatory compliance. However, this approach inherently assumes a single chain. When the same asset exists simultaneously on Ethereum, Polygon, and Arbitrum, there is no mechanism to maintain consistency between Identity Registries on each chain.

Compliance Module: The Single Boolean Problem

// ERC-3643 Compliance Interface
interface ICompliance {
    function canTransfer(
        address _from,
        address _to,
        uint256 _value
    ) external view returns (bool);
    
    // Problem: Single bool return
    // - Cannot distinguish rejection reasons (KYC incomplete? Holding limit exceeded? Blacklist?)
    // - Time-based conditions (token expiry, schedule) not supported
    // - Differentiated rules by asset class cannot be applied
}

canTransfer simply returns true or false. There is no information about why a transaction was rejected or what conditions must be met to allow it. If a regulatory authority wants to apply different rules for specific asset classes—for example, investment-grade bonds to general investors, high-yield bonds only to accredited investors—they must deploy separate contracts.

Cross-chain: The Uncharted Territory

ERC-3643 was designed in 2018. At that time, cross-chain was merely a theoretical concept. Now the Rollup-centric roadmap has become reality, and bridging the same asset to multiple L2s is routine.

This is why RAI (Regulated Asset Identity) is necessary. RAI enables consistent identity tracking across chains, automatically synchronizing to other chains when KYC status changes on one chain. ERC-3643’s Identity Registry does not support such system-wide AML.

Regulatory Requirements: A Comparative Analysis

RCP analyzed the requirements of 15 global financial regulators and derived 31 core items. We analyzed each standard’s compliance with the 25 items implementable on blockchain.

Compliance Summary

Critical Gaps in Existing Standards

Core areas commonly unmet by existing standards:

Time-based Features:

• (23) Token Expired Time: Intrinsic attributes of financial products like bond maturity, option exercise periods

Advanced Regulatory Actions:

• (12) Cancellation or Modification of Transactions: Transaction cancellation by court order
• (14) Kill Switch: Emergency contract suspension/disposal
• (15) Blacklist Management: Dynamic blacklist management and cross-chain synchronization

Dynamic Management:

• (29) Gasless Support: Resolving gas fee issues during regulatory emergency actions
• (30) Asset Class Management: Differentiated regulations for bonds/stocks/derivatives

Why a New Standard Is Inevitable

The Technical Impossibility of Extension

“Why not just extend the existing standard?”

This question is natural. However, due to the nature of Solidity smart contracts, this is technically impossible.

The Destructiveness of Function Signature Changes:

To replace ERC-1644’s controllerTransfer with six granular functions:

// Current ERC-1644
function controllerTransfer(address, address, uint256, bytes, bytes) external;

// Necessary changes
function freeze(address _target, uint256 _value, uint256 _duration) external;
function seize(address _from, address _custodian, uint256 _value, bytes32 _courtOrder) external;
function confiscate(address _from, uint256 _value, bytes32 _legalBasis) external;
// ...

This is a breaking change. All integrations depending on the existing interface—wallets, exchanges, DeFi protocols—break. Hundreds of already deployed contracts cannot be upgraded, and ecosystem-wide migration is required.

Integration of Fragmented Sub-standards:

To integrate ERC-1594, 1410, 1643, 1644 into a single coherent interface requires resolving namespace conflicts and state management duplication for each standard. This requires effort equivalent to writing a new standard and is, in effect, a new standard.

Not Isolated, But Connected

Does a new standard inevitably mean disconnection from the existing ecosystem?

No. Continuity can be maintained through a compatibility layer.

ERC-1400 Compatibility Adapter:

contract TRUSTToken is IERC1400, ITRUSTCore {
    
    // ERC-1400 interface implementation (external compatibility)
    function controllerTransfer(
        address _from,
        address _to,
        uint256 _value,
        bytes calldata _data,
        bytes calldata _operatorData
    ) external override onlyController {
        // Parse action type from _data
        ActionType action = _parseActionType(_data);
        
        // Internally call granular functions
        if (action == ActionType.FREEZE) {
            _freeze(_from, _value, _parseDuration(_data));
        } else if (action == ActionType.SEIZE) {
            _seize(_from, _to, _value, _parseCourtOrder(_data));
        } else if (action == ActionType.CONFISCATE) {
            _confiscate(_from, _value, _parseLegalBasis(_data));
        }
        // ...
    }
    
    // ERC-TRUST native interface (new features)
    function freeze(
        address _target,
        uint256 _value,
        uint256 _duration,
        bytes32 _reason
    ) external onlyRegulator {
        // Explicit type, on-chain verifiable, state tracking
        _freeze(_target, _value, _duration);
        emit AssetFrozen(_target, _value, _duration, _reason, msg.sender);
    }
}

If an existing DeFi protocol supports ERC-1400 tokens, ERC-TRUST tokens integrate through the same interface. Internally, it uses granular regulatory actions, but externally exposes an ERC-1400 compatible interface.

Migration Path:

Existing ERC-1400 token holders can convert to ERC-TRUST through a wrapper contract. They deposit original tokens and receive equivalent ERC-TRUST tokens, with reverse conversion possible at any time. This enables gradual adoption.

ERC-TRUST: Design Direction

Six-Module Architecture

ERC-TRUST is designed with the following structure (specific code will be disclosed sequentially from E017 onwards):

1. Core Regulatory Actions: Granular implementation of FREEZE, SEIZE, CONFISCATE, LIQUIDATE, RESTRICT, RECOVER
2. Identity Management: RAI system and cross-chain identity tracking
3. Advanced Enforcement: Time-based and conditional regulatory enforcement
4. Cross-chain Operations: Cross-chain atomic enforcement and state synchronization
5. Audit & Monitoring: Integrated audit trail and real-time monitoring
6. Asset Lifecycle: Token expiration management and asset class-specific regulations

Each module can be implemented independently. Some projects may implement only Core, while others may implement all modules. This inherits ERC-1400’s sub-standard approach while reducing confusion through clear dependency definitions.

Not Replacement, But Evolution

ERC-TRUST does not negate ERC-1400 and ERC-3643. It takes one more step forward on the path they paved.

Without Polymath, the concept of security tokens itself would not have been systematized, and without Tokeny, protocol-level integration of regulatory compliance would not have been demonstrated. We respect and inherit that legacy.

At the same time, the blockchain ecosystem has evolved. Cross-chain has become commonplace, DeFi handles complex financial products, and regulators demand more sophisticated compliance. ERC-TRUST is the standard that responds to this new reality.

Conclusion: The Responsibility of Succession

Code doesn’t lie.

ERC-1644’s controllerTransfer cannot distinguish between six regulatory actions. The non-standardization of the _data parameter destroys interoperability and makes on-chain verification impossible. ERC-1400’s fragmented sub-standards cause integration complexity, and ERC-3643’s monolithic structure does not support cross-chain and asset class differentiation.

This is fact, not criticism.

At the same time, the fact that we would not exist without them is also truth. ERC-1400 established the concept of security tokens, and ERC-3643 demonstrated protocol-level integration of regulatory compliance. We stand on their shoulders.

ERC-TRUST is evolutionary succession. It connects to the existing ecosystem through compatibility layers, supports gradual transition through migration paths, and enables selective adoption through modularization. This is evolution, not destruction; continuity, not disconnection.

In our next research, we will explore the dual-track EIP strategy of Informational EIP and Standards Track EIP. We will examine how the two EIPs operate independently yet complementarily, and what the joint proposal with Horizen Labs means.

References

1. Polymath. (2018). ERC-1400: Security Token Standard. https://github.com/ethereum/eips/issues/1411
2. Tokeny. (2021). ERC-3643: T-REX Token Standard. https://eips.ethereum.org/EIPS/eip-3643
3. Polymath. (2018). Security Token Standard (STS) Technical Specification. https://github.com/PolymathNetwork/polymath-core
4. Ethereum. (2018). ERC-1644: Controller Token Operation Standard. https://github.com/ethereum/eips/issues/1644
5. Tokeny. (2023). T-REX Documentation. https://docs.tokeny.com/