ERC-1400 (Security Token Standard)

What is ERC-1400, and what's the fundamental difference from ERC-20?

ERC-1400 is a set of standards designed for security tokens, formally titled the Security Token Standard. It isn't a single contract but a framework combining four sub-standards: ERC-1410 splits a holder's balance into separate partitions; ERC-1594 performs compliance checking before a transfer executes; ERC-1643 manages the legal documentation bound to the token; ERC-1644 lets an authorized controller execute forced transfers.

The fundamental difference from ERC-20 lies in the data model itself. ERC-20 assumes every token is fully fungible — one token in your wallet is indistinguishable from one in someone else's, and no check runs before a transfer to verify who the recipient is or whether they're eligible to receive it. That design works fine for utility tokens, but securities inherently don't behave that way: shares in the same company can simultaneously exist in multiple states — still locked up, already unlocked and freely tradable, or restricted to holders in specific jurisdictions — and ERC-20's single homogeneous balance model has no way to express that distinction at all.

ERC-1400 solves this with partial fungibility: under the same token contract, a holder's balance can be split into several partitions, each carrying its own metadata (which issuance it belongs to, when it unlocks, what transfer restrictions apply), distinct from one another, while tokens within the same partition remain fungible with each other.

Why does a whole new set of standards need to exist? Why not just add rules on top of ERC-20?

In theory, a compliance layer could be wrapped around ERC-20 externally, but this approach runs into a fundamental problem: ERC-20's own transfer function has no built-in check-before-execute mechanism, so an external compliance layer can only catch problems after the transfer has already happened, or rely entirely on a front-end interface to intercept non-compliant actions. But a front end can be bypassed — anyone calling the contract's transfer function directly skips whatever the front end checks — an unacceptable risk for securities, since a transfer that violates regulatory requirements (sold to an ineligible investor, breaking a lock-up, exceeding an ownership concentration cap) leaves the issuer, not the buyer, on the hook.

ERC-1400 writes compliance checking directly into the transfer logic of the token contract itself (via ERC-1594). Every transfer, no matter which interface initiates it, must first pass the contract's built-in checks: confirming the recipient has cleared KYC/AML, confirming the ownership cap isn't exceeded, confirming the lock-up period has passed, confirming the transfer isn't to a restricted jurisdiction. Fail any check and the transfer simply fails, returning a standardized error code explaining why. This design turns compliance logic from external and bypassable into built-in and unavoidable — the core reason institutions are willing to adopt it for regulated securities.

Regulators and financial institutions have long needed an onchain token that can natively enforce the same control logic traditional securities law requires, rather than every issuer custom-building its own compliance mechanism from scratch. That's exactly the background behind ERC-1400 — a modular, interoperable standard replacing expensive bespoke development.

How does ERC-1400 actually work, and what does each sub-standard do?

Walking through a complete transfer, here's each sub-standard's role:

ERC-1410 (partitioned holdings) — each holder's balance isn't a single number but split into multiple partitions, such as "primary issuance, unlocked" versus "private placement, locked until 2027," each carrying its own metadata, letting the contract apply different logic to different partitions.

ERC-1594 (issuance validation and transfer restrictions) — when a transfer is initiated, the contract first calls a check function, confirming both sender and recipient's compliance status, investor eligibility, jurisdictional restrictions, ownership caps, and similar conditions; only if all pass does the transfer proceed. If any check fails, the transfer fails and returns a standardized error code (such as "recipient hasn't cleared KYC" or "exceeds ownership concentration cap"), making the failure reason clear and auditable rather than a vague "transaction failed."

ERC-1643 (document management) — binds legal documents such as the offering memorandum, investor agreement, and regulatory filings to the token contract, as a hash or link, letting holders and regulators check directly onchain where this security's associated legal documentation sits and whether its content has been tampered with.

ERC-1644 (controller operations) — authorizes a specific role, usually the issuer or its agent, to execute forced transfers when regulatory requirements are met, such as a court order to freeze or transfer holdings in a particular account, or correcting an anomalous transfer caused by a technical error; this authority itself is subject to strict limits and auditing.

All four sub-standards combined make up the complete ERC-1400 — remove any single one and it can no longer fully cover the functions a security's lifecycle requires.

When investors or issuers evaluate a tokenized securities project and see it uses ERC-1400, what should they actually pay attention to?

First, adopting the ERC-1400 standard framework doesn't automatically mean the issuer complies with all applicable securities law. ERC-1400 provides a technical container capable of executing compliance logic; what rules actually get filled into that container (who counts as an accredited investor, how long the lock-up runs, what the ownership cap is) is entirely up to the issuer, and the standard itself doesn't verify whether those rules are set correctly. Checking an ERC-1400 token means checking exactly what restrictions its contract actually codes, not the fact that it uses ERC-1400 at all.

Second, ERC-1644's forced transfer authority is a double-edged sword. It exists to satisfy regulatory requirements, such as complying with a court order, but if this authority is poorly designed or governed, it could in theory also be abused. Checking who has the power to trigger a forced transfer, whether the triggering conditions are publicly transparent, and whether multi-signature or third-party oversight mechanisms exist is an often-overlooked but critical part of evaluating this class of token.

Third, the partition mechanism solves the problem of a security existing in multiple states simultaneously, but it also means tokens in different partitions under the same contract can carry wildly different actual rights. Before buying, confirm which partition you're actually receiving and that partition's lock-up and transfer restrictions — never assume every token under a contract address is identical just because the address is the same.

Fourth, ERC-1400 is a technical standard, not a regulatory framework itself. Different jurisdictions define securities differently, set different accredited investor thresholds, and impose different disclosure requirements; the same ERC-1400 contract deployed in different regions needs its compliance parameters adjusted locally — it isn't a single rule set that works globally as-is.