ERC-1400 Security Token Standard: How to Create One, vs ERC-3643

ERC-1400 is a modular Ethereum standard for security tokens that splits a single token contract into partitioned balances with independent compliance rules. Unlike a standard ERC-20 where every token is identical, ERC-1400 lets issuers create restricted and unrestricted tranches, enforce lockup periods, and manage multiple share classes — all within one contract.

#Why ERC-1400 Matters for Founders

If you're tokenizing a regulated asset with any structural complexity — different investor classes, vesting tranches, or restricted shares — ERC-20 won't cut it. You need a standard that treats your token as a financial instrument, not a fungible commodity.

ERC-1400 combines multiple sub-modules including ERC-1410 for partitioned balances, ERC-1594 for issuance and redemption, ERC-1643 for document references, and ERC-1644 for controller transfers (Source: QuillAudits). This modular design is what separates it from simpler token standards.

By 2026, ERC-1400 has become the leading standard for institutional tokenization projects due to its composable on-chain legal framework (Source: Blockchain App Factory). The standard's adoption tracks directly with the growth of RWA tokenomics across institutional markets.

"ERC-1400 strikes a balance between regulatory needs and blockchain innovation. It creates a framework where security tokens work within legal boundaries while staying transparent and efficient." — Primior, Security Token Standard Guide

We've helped dozens of projects through token standard selection as part of our advisory work. Here's how ERC-1400 actually works and when it's the right choice.

#The ERC-1400 Modular Architecture

The standard isn't a single interface. It's a framework we call the ERC-1400 Modular Architecture — four sub-standards that each handle a distinct stage of the security token lifecycle. You adopt the modules you need and leave the rest.

ERC-1410 — Partitioned Balances. The core innovation. ERC-1400 uses partitions via ERC-1410 for partial fungibility, enabling restricted and unrestricted token classes (Source: Zealynx). A single holder can own tokens across multiple partitions — say, a "vesting" partition and a "tradable" partition — each with independent transfer rules.

ERC-1594 — Core Securities Operations. Handles issuance and redemption with compliance checks. Before tokens are minted, the contract validates that the recipient meets all eligibility requirements. Redemption burns tokens and updates balances across relevant partitions.

ERC-1643 — Document Management. Links off-chain legal documents to the on-chain token. Offering memoranda, prospectuses, compliance certificates — all referenced from the contract with URI pointers and document hashes for integrity verification.

ERC-1644 — Controller Transfers. Enables authorized controllers to force transfers when legally required. Court orders, regulatory actions, lost key recovery — scenarios that securities law requires but standard ERC-20 can't handle.

#How Partitioned Transfers Work

The partition system is what makes ERC-1400 fundamentally different from ERC-3643 and other security token approaches. We call this the Partition Transfer Model.

Step 1: Partition selection. When a transfer is initiated, the sender specifies which partition the tokens come from. A holder with 1,000 tokens in "restricted" and 500 in "unrestricted" can only transfer from the partition they designate.

Step 2: Partition-level rules. Each partition carries its own transfer restrictions. The "restricted" partition might enforce a 12-month lockup. The "unrestricted" partition might allow free transfer to verified holders. Rules are checked before any balance moves.

Step 3: Compliance validation. Beyond partition rules, global compliance checks apply. KYC/AML status, jurisdictional restrictions, and maximum holder limits are validated. The contract returns Ethereum Status Codes (EIP-1066) for any failure, giving the caller a specific reason rather than a generic revert (Source: Primior).

Step 4: Balance update. Only after all checks pass does the partition balance update. The sender's balance in the specified partition decreases, the receiver's balance in the corresponding partition increases.

This partition-aware transfer model means your tokenomics can have structurally different token classes without deploying separate contracts. Preferred shares, common shares, locked team allocations, and freely tradable tokens — all in one ERC-1400 contract.

#How to Create an ERC-1400 Token: The 5 Components of an ERC-1400 Implementation

Creating an ERC-1400 security token is a structured exercise. It is not a matter of forking an ERC-20 template and adding a few modifiers. The standard pulls in four sub-EIPs that each carry their own implementation surface, and a correct build needs all five of the following components wired together before the contract is fit for an audited deployment.

We call this the 5 Components of an ERC-1400 Implementation. Every security token engagement we've taken through to deployment touches each of these in order.

1. The partition schema. Define the partitions before you write a line of Solidity. A partition is a bytes32 identifier that segments balances inside the contract. Founders typically start with three: RESTRICTED_REG_S, RESTRICTED_REG_D, and UNRESTRICTED. RWA issuers with a tranched cap table will add more. The schema goes into the tokenomics design first, because partitions drive everything downstream: vesting, transfer rules, and the on-chain reporting your investors will ask for.

2. The compliance module. ERC-1400 does not prescribe an identity system, which means the compliance logic is yours to build or to plug in. The contract exposes canTransfer and canTransferByPartition view functions that return an Ethereum Status Code (EIP-1066) plus a bytes32 reason. Behind those view functions sits the actual rule set: jurisdictional KYC, accredited-investor checks, lockup timers, holder caps. Teams either build this in-house or wire in a third-party identity layer (the same compliance question we worked through for ERC-3643, where the identity system is baked into the standard rather than left to the issuer).

3. The document registry. ERC-1643 gives you setDocument and getDocument on the contract itself. Every offering memorandum, subscription agreement, and audit certificate that backs the security gets a URI plus a SHA-256 hash committed onchain. The legal team's job becomes easier here, not harder: when an investor or a regulator asks which prospectus governs a specific tranche, the answer is a single contract call.

4. The controller permissions. ERC-1644 is the most legally sensitive component. It defines controllerTransfer and controllerRedeem, the privileged functions that move tokens without holder consent. Securities law requires this capability for court orders, forced redemptions, and lost-key recovery. The implementation work is straightforward; the governance work is not. Who holds controller authority, what multi-sig threshold is required, and what onchain or offchain record gets created when a controller acts are decisions that belong in the issuance documentation before the contract goes live.

5. The issuance and redemption flow. ERC-1594 governs the minting and burning of tokens. issueByPartition mints into a specific partition with eligibility checks pre-validated. redeemByPartition burns and triggers any settlement obligation the issuer owes the holder. Both functions emit events that downstream systems (cap-table software, transfer agents, fund administrators) read to keep the offchain record in sync.

Once those five components are wired, the deployment sequence is the standard pattern: testnet deployment, third-party audit (we typically see issuers run Zealynx, Quill, or OpenZeppelin), audit remediation, mainnet deployment, and a registration entry with the relevant transfer agent or onchain registry. The audit step is non-negotiable for security tokens. We've yet to see a serious institutional allocator subscribe to a token without one.

The choice of token standard interacts with the broader landscape of token standards covered in our founder's guide, which is worth reading first if you're still in the standard-selection phase rather than the implementation phase.

#When to Use ERC-1400

Multi-class equity tokens. If your tokenized security has preferred and common shares, or Series A and Series B investors with different rights, ERC-1400's partition system handles this natively. One contract, multiple classes.

Tokens with vesting or lockup requirements. Partitions let you enforce lockup periods at the contract level. Team tokens sit in a "vesting" partition with time-based restrictions while investor tokens in a "tradable" partition move freely. No external vesting contracts needed.

Real-world asset tokens with complex structures. RWA tokenization frequently involves multiple tranches — senior debt, mezzanine, equity. ERC-1400 maps each tranche to a partition. Our EcoYield case study demonstrates how tranche management directly shapes tokenomics design.

Projects needing on-chain document references. If your legal team wants offering documents, compliance certificates, or audit reports referenced directly from the token contract, ERC-1643 provides that out of the box.

#The ERC-1400 Compliance Checklist

Before any ERC-1400 contract goes to audit, we run issuers through a 10-point checklist. Missing items here are the single most common cause of audit findings that send teams back into design rather than remediation. Use it as a working sheet:

1. Partition schema documented. Each partition has a name, a regulatory basis (Reg S, Reg D, Reg A+, MiCA, or jurisdiction-equivalent), and a written transfer rule. No undocumented partitions reach mainnet.
2. Transfer rules enumerated per partition. Lockup duration, eligible holder type, maximum holders per partition, and any geographic exclusions are written down before the rule engine is built.
3. canTransferByPartition returns a reason code for every failure. Generic reverts are an audit finding. Use EIP-1066 status codes so wallets and integrations can surface a specific reason to the holder.
4. Document registry populated at deployment. Offering memorandum, subscription agreement, and any related compliance certificates are committed onchain before the first issuance.
5. Controller authority defined. Multi-sig threshold, list of authorized controllers, and the offchain governance process that approves a forced transfer are written into the issuer's operating documents.
6. Issuance gating is enforceable. issueByPartition cannot be called without the recipient passing the partition's eligibility check. We've seen contracts where the check was bolted on at the dApp layer and bypassed by direct contract calls. That is an audit fail.
7. Redemption settlement is mapped to an offchain process. Burning tokens onchain doesn't settle a security. The transfer agent, cap-table provider, or paying agent has to be wired to the redemption event.
8. Event emissions cover every state change. Every issuance, redemption, partition transfer, document update, and controller action emits a typed event. Investor reporting and regulator reporting both depend on these.
9. Upgrade path documented. Most institutional security tokens deploy behind a proxy. The upgrade authority, timelock, and acceptable upgrade scope go in the documentation.
10. Audit firm engaged before mainnet. ERC-1400 is not a standard to deploy unaudited. The capital at risk on a regulated token is too large and the legal exposure to the issuer is too direct.

This checklist takes between two and four weeks to work through depending on partition count and the maturity of the issuer's compliance infrastructure. We treat it as part of the RWA tokenomics design patterns we use for any project with a security-token issuance in scope.

#ERC-1400 vs. ERC-3643: Choosing the Right Standard

We covered ERC-3643 in detail already. Here's the decision framework:

Choose ERC-1400 when your primary need is partition management. Multiple share classes, complex vesting structures, tranche-based assets. ERC-1400 gives you granular control over how different token classes behave within a single contract. You bring your own identity and compliance infrastructure.

Choose ERC-3643 when your primary need is automated compliance enforcement. ERC-3643 prescribes the identity system (ONCHAINID) and builds compliance checks directly into every transfer. Less flexibility on token structure, but more out-of-the-box compliance automation.

Use both when you need partition management AND automated identity-based compliance. The standards are complementary. ERC-1400 handles the structural complexity; ERC-3643's identity layer handles who can hold and transfer.

#ERC-1400 vs ERC-20 vs ERC-3643: A Side-by-Side Comparison

For founders evaluating standards across the full spectrum, the comparison is rarely just ERC-1400 against ERC-3643. ERC-20 sits in the background as the default, and the real question is which of the three matches the asset being tokenized.

Capability	ERC-20	ERC-1400	ERC-3643
Primary use	Utility, fungible, payment	Security tokens with structural complexity	Compliant security tokens with identity layer
Partition support	None	Native (ERC-1410)	None (single class, identity-gated)
Identity system	None	Issuer's choice	ONCHAINID (prescribed)
Compliance enforcement	None	Issuer-defined per partition	Built into every transfer
Document onchain	None	ERC-1643 native	Compliance attestations onchain
Forced transfer	None	ERC-1644 controller	Recovery via identity registry
Reason codes on failure	Generic revert	EIP-1066 status codes	Compliance module return codes
Typical asset	Native token, stablecoin	Multi-class equity, tranched RWA	Single-class regulated token
Audit complexity	Low	High (modular surface)	Medium (prescribed surface)

The headline difference: ERC-20 has no concept of who holds the token, ERC-1400 makes the issuer responsible for that concept, and ERC-3643 builds the concept into the standard itself. Three increasingly opinionated points on the same spectrum.

For an asset with multiple share classes, tranches, or vesting partitions, ERC-1400 is almost always the right base. For a single-class regulated token where the issuer wants compliance enforcement built into the wire, ERC-3643 is cleaner. For a utility token with no securities exposure, ERC-20 remains the default and adding either ERC-1400 or ERC-3643 is overengineering.

Standards selection sits inside a wider conversation about how the token slots into the offering structure. We typically work this through alongside your tokenomics data room, since the partition schema and the cap table are two views of the same document.

#Tokenomics Design Implications

Choosing ERC-1400 directly shapes your token model:

Partition design is allocation design. Your token allocation table maps to partitions. Team allocation, investor allocation, treasury, ecosystem fund — each can be a partition with its own rules. This means your tokenomics data room needs to document not just allocations but partition-level transfer restrictions.

Liquidity is partition-dependent. Not all tokens in your supply are equally liquid. Tokens in restricted partitions can't trade. Your liquidity model must account for which partitions contribute to circulating supply at any given time.

Controller powers need governance. ERC-1644's forced transfer capability is powerful and risky. Your tokenomics documentation must define exactly when controllers can act, who holds controller authority, and what governance process approves forced transfers. Investors will scrutinize this.

Gas costs scale with partition complexity. Each partition adds storage and computation overhead. A token with 2 partitions costs less per transfer than one with 8. Design the minimum number of partitions that meet your structural requirements.

---

ERC-1400 is infrastructure for security tokens that need structural complexity — multiple classes, tranches, or vesting partitions — managed within a single contract. The standard's modular architecture means you adopt only what you need. But modularity also means more design decisions upfront. Get the partition structure wrong and you're redeploying.

If you're building a security token and need your tokenomics to hold up under institutional scrutiny, book a discovery call. We'll assess whether ERC-1400, ERC-3643, or a combination fits your compliance and structural requirements. Sometimes neither is the right answer. We'll tell you that too.

#Where ERC-1400 Fits for RWA Issuers

Real-world asset tokenization is the cluster where ERC-1400 sees the most production use. The standard's partition system maps cleanly to the tranche structures common in tokenized credit, tokenized real estate, and tokenized private equity. Three patterns appear repeatedly.

Tokenized real estate with senior and mezzanine investors. A real estate vehicle issues two partitions: one for senior debt holders with first-loss protection and a defined coupon, one for mezzanine holders with a higher yield and a deeper risk position. Each partition has its own transfer restrictions, its own redemption schedule, and its own waterfall logic on the offchain settlement side. This is the kind of structural decision we walk through in our piece on tokenizing real estate.

Tokenized credit with restricted investor classes. A private credit fund issues to U.S. accredited investors under Reg D and to non-U.S. investors under Reg S. Two partitions, two transfer rule sets, one contract. Holders cannot move tokens between partitions, and the eligibility checks on each partition enforce the regulatory boundary at the wire level.

Tokenized private equity with multi-year vesting and secondary lockups. Team partitions vest over four years with a one-year cliff. Investor partitions have a 12-month lockup from issuance. Secondary partitions unlock after a defined event (an IPO, a token generation event, a regulator-approved liquidity window). One contract, four partitions, four sets of rules.

In each case the value of ERC-1400 over a custom contract is that the standard is recognized by the wallets, indexers, and compliance tools in the security-token stack. A custom implementation may be cheaper to write but is more expensive to integrate. The institutional buyers who matter for these issuances are the ones who refuse to subscribe to a token their custodian can't reliably index.

#Frequently Asked Questions About ERC-1400

#What is ERC-1400 in simple terms?

ERC-1400 is an Ethereum standard for security tokens. It extends ERC-20 with three capabilities that securities law requires and ERC-20 does not provide: balance partitioning (so one contract can hold multiple classes of token), an onchain document registry (so legal documents are referenced from the token), and controller transfers (so issuers can move tokens when a court order or regulator requires it). It is the standard used by most institutional tokenization projects that need structural complexity within a single contract.

#Is ERC-1400 a security?

ERC-1400 is a token standard, not a security itself. The standard is the technical specification a contract follows. Whether a token implemented in ERC-1400 is a security under any given jurisdiction is a separate analysis that depends on the offering structure, the asset backing the token, the rights it carries, and the applicable regulator's framework. Issuers use ERC-1400 because their token is already a security and the standard provides the compliance scaffolding that security needs.

#What is the difference between ERC-1400 and ERC-20?

ERC-20 is a fungible-token standard. Every token in an ERC-20 contract is identical and transfers freely between any two addresses. ERC-1400 extends ERC-20 with partitioned balances, transfer rules that can vary by partition, an onchain document registry, and forced-transfer powers for authorized controllers. ERC-1400 contracts also return specific failure codes (EIP-1066) on transfer rejections rather than generic reverts, which lets wallets and integrations explain to a holder why a transfer was blocked.

#What is the difference between ERC-1400 and ERC-3643?

Both standards target security tokens but they make different design choices. ERC-1400 leaves the identity and compliance system to the issuer and provides partitioning to handle multiple share classes in one contract. ERC-3643 prescribes ONCHAINID as the identity system and builds compliance checks into every transfer at the standard level, but it does not support partitioning. Use ERC-1400 when structural complexity (multiple share classes, tranches, vesting partitions) is the priority. Use ERC-3643 when automated identity-based compliance for a single-class token is the priority.

#How do I create an ERC-1400 token?

Creating an ERC-1400 token has five components: the partition schema, the compliance module, the document registry, the controller permissions, and the issuance and redemption flow. Each component maps to one of the sub-EIPs that make up the standard (ERC-1410, ERC-1594, ERC-1643, ERC-1644). The implementation sequence is design the partition schema first, build the compliance rules per partition, populate the document registry, define controller authority and governance, then wire issuance and redemption. A third-party audit before mainnet deployment is standard practice for security tokens.

#What is a partition in ERC-1400?

A partition in ERC-1400 is a bytes32 identifier that segments balances inside a single contract. A holder can own tokens across multiple partitions, and each partition can have its own transfer rules, lockup logic, and eligibility checks. Partitions are the mechanism that lets one ERC-1400 contract represent multi-class equity, tranched RWA structures, or vesting allocations without deploying a separate contract per class. Transfers happen via transferByPartition, which always specifies which partition the tokens move from.

#Which standard should I use for tokenizing real-world assets?

The right standard depends on the asset structure. For a single-class RWA token aimed at a single investor class with built-in compliance enforcement, ERC-3643 is a clean fit. For an RWA token with tranches (senior debt, mezzanine, equity), multiple investor classes (Reg D and Reg S in parallel), or built-in vesting, ERC-1400 is the better base because partitioning is native. For a tokenized utility wrapper around an RWA (where the token does not itself represent the underlying security), ERC-20 may be sufficient and either security-token standard is overengineered. The standard selection is downstream of the offering structure and the legal opinion on what the token represents.

---