ERC-3643 vs ERC-1400: Choosing a Security Token Standard

Video transcript

Pick ERC-3643 for a Final standard with identity checks on every transfer. Pick an ERC-1400 design mainly for partitions, such as tranches. Either way, audit the override powers first.

ERC-3643 is a Final Ethereum standard. ERC-1400 was proposed in 2018, never left Draft, and ConsenSys archived its implementation in 2025.

Every ERC-3643 transfer passes two gates. The Identity Registry confirms the receiver holds claims from a trusted issuer. Then the Compliance contract applies the offering's rules.

ERC-1400 has no identity layer. It standardizes how to ask whether a transfer would succeed, and leaves the rules to the implementation.

Both standards let the issuer side move tokens without the holder. ERC-3643 agents can mint and force transfers around compliance, and ERC-1400 controllers can move or redeem anyone's tokens. Those keys need the strongest protection.

Map every owner, agent and controller to a key, multisig or timelock. Test every bypass path, check who edits trusted issuers, bind each signed approval to one transfer, and verify partition accounting.

Choose ERC-3643 for a Final standard with eligibility held onchain. Choose an ERC-1400 design when one token must hold several tranches, and you accept owning a Draft spec and its audits.

Either way, the admin keys decide the outcome. Read the full comparison, or talk to Guardian about auditing your permissioned token.

A security token needs rules a plain ERC-20 cannot express: who may hold it, who may receive it, and who can move it by force.

ERC-3643 and ERC-1400 answer those needs in different ways. This comparison reads both specifications as an auditor would: where compliance is enforced, who can override it, and what can break.

Status first, because the two are not at the same stage.

Status and Design

ERC-1400 began as GitHub issue #1411, opened on September 13, 2018. It was closed on June 11, 2022 "for housekeeping purposes", with its front matter still marked Draft.

Its parts are drafts too: ERC-1410 for partitions, ERC-1594 for core transfer checks, ERC-1643 for documents and ERC-1644 for controller operations.

ConsenSys's ERC-1400 implementation, used by its Codefi Assets platform, was archived on March 25, 2025 and is now read-only.

ERC-3643 was created on July 9, 2021 and is listed as Final. The ERC3643 Association, a Luxembourg non-profit, says it governs the standard and counts 152 member organizations.

How Each Enforces Compliance

ERC-3643: identity onchain

Beyond freeze and pause checks, every ERC-3643 transfer passes two gates. First, the Identity Registry's isVerified confirms the receiver holds the required claims, signed by a trusted issuer.

Then the Compliance contract's canTransfer applies the offering's global rules. Compliance can be tailor-made or modular.

Four contracts sit behind those gates:

• Identity Registry: links each wallet to an identity contract and a country code.
• Identity Registry Storage: holds those records, and can serve several registries.
• Claim Topics Registry: lists the claims an investor must hold.
• Trusted Issuers Registry: lists who may issue each claim.

In the T-REX reference suite, the identity contract is ONCHAINID, which its docs say is based on ERC-734 and ERC-735. The Association describes "one ONCHAINID per investor, reused across tokens".

Only agents can add or remove identities in the registry.

ERC-1400: rules left to the issuer

ERC-1400 has no identity layer. It requires a standard way to ask whether a transfer would succeed, and why not.

ERC-1594's canTransfer returns an ERC-1066 status code and a reason field the issuer defines. The rules behind it are up to the implementation.

Transfers can carry a data field. ERC-1594 describes a co-signing model: the holder approves the transfer, and an authorized party signs data that travels with it.

Partitions

ERC-1410 splits a holder's balance into partitions, each with its own key and balance. Tokens are fungible within a partition, but not necessarily across them.

That lets one token carry several tranches or classes of asset. Operators can be approved for one partition or for all.

Override Powers

Both standards let the issuer side move tokens without the holder, for legal action or lost keys. Those powers are where a stolen admin key does the most damage.

ERC-3643 is explicit about the bypass. Mints and forced transfers "bypass the compliance rules" and need only a verified receiver. Burns bypass "all checks on eligibility".

ERC-1644 says controller transfers "potentially also need to respect other transfer restrictions". It leaves that choice, and how controllers are authorized, to the implementation.

ERC-1400's one-way switches are worth copying. Once isControllable or isIssuable returns false, it must return false forever.

Attack Surface Compared

Read side by side, the two specs concentrate risk in four places:

The ERC-3643 EIP says its audits were "primarily focused on the specific implementation by Tokeny". Your modules, roles and integrations are new code.

What to check in an audit

• Map every owner, agent and controller to a key, multisig or timelock.
• Test each bypass path: mint, forced transfer, burn, recovery and controller calls.
• Check who can edit trusted issuers, claim topics and compliance modules.
• Bind each signed approval to one transfer, one chain and an expiry.
• Check partition accounting on every transfer, redemption and default-partition move.
• Confirm an identity change for one token cannot wrongly unlock another.

Buying a platform rather than building? Our tokenization platform due diligence checklist covers what to ask the vendor.

Gas and Composability

Gas depends on the implementation, so benchmark your own build. The specs show where the cost sits.

An ERC-3643 transfer calls the Identity Registry, which checks claims, and the Compliance contract before and after the move. More compliance modules mean more checks.

ERC-1410 warns that iterating over a holder's partitions "needs to be cognisant of block gas limits". Commenters on the ERC-1400 issue also raised the contract size limit.

Composability

Both standards are ERC-20 compatible, so wallets can read balances. But transfers revert when the rules say no.

In ERC-3643, every receiver needs a verified identity. A pool, vault or bridge contract must be registered before it can receive the token.

ERC-7943 (uRWA), created in June 2025 and now Final, takes a lighter route. It defines a small interface for transfer checks, frozen balances and forced transfers across ERC-20, ERC-721, ERC-1155 and ERC-6909.

When to Pick Each

Choose ERC-3643 when

• You want a Final standard and a public reference implementation.
• Eligibility should live onchain, as claims reused across tokens.
• An agent model fits your transfer and recovery process.

Choose an ERC-1400 design when

• One token must hold several tranches or classes, each with its own rules.
• You want controller and issuance powers that can be switched off for good.
• You accept a Draft spec and will own the implementation and its audits.

Either way, the admin keys decide the outcome. For where these standards sit in wider tokenization risk, see our RWA tokenization guide.

How Guardian Audits Permissioned Tokens

Guardian's smart contract audit starts with a design review of "roles, upgrade paths, threat model, and economic assumptions".

An invariant suite then fuzzes accounting and solvency, and senior researchers attack privileged flows with proof-of-concept depth.

For institutions, Guardian reviews token systems and settlement contracts before launch. Its OpSec audit covers who can "upgrade, pause, mint, set parameters or move funds".

Frequently Asked Questions

Is ERC-1400 an official Ethereum standard?

No. ERC-1400 was proposed in GitHub issue #1411 in September 2018 and never became a final EIP. The issue was closed in June 2022 for housekeeping, and its front matter still says Draft.

Is ERC-3643 compatible with ERC-20?

Yes. The standard says the token "MUST be ERC-20 compatible", so wallets and explorers can read it. Transfers still revert unless the receiver has a verified identity and the compliance rules allow the move.

What is ONCHAINID?

An onchain identity contract, based on ERC-734 and ERC-735, that holds claims from trusted issuers, such as a KYC check. ERC-3643's reference suite uses it to decide whether a wallet's owner may hold a token.

Can an ERC-3643 issuer move tokens without the holder?

Yes. Agents can force transfers, mint, burn, freeze and recover tokens. The EIP says mints and forced transfers "bypass the compliance rules", so the keys behind agent roles need the strongest protection.

Sources

• Ethereum Improvement Proposals: ERC-3643, T-REX, Token for Regulated EXchanges (Final; created July 9, 2021)
• GitHub, ethereum/EIPs: ERC 1400, Security Token Standard, issue #1411 (opened September 13, 2018; closed June 11, 2022)
• SecurityTokenStandard, EIP-Spec: ERC-1410, Partially Fungible Token Standard (Draft, 2018)
• SecurityTokenStandard, EIP-Spec: ERC-1594, Core Security Token Standard (Draft, 2018)
• SecurityTokenStandard, EIP-Spec: ERC-1644, Controller Token Operation Standard (Draft, 2018)
• GitHub, ConsenSys: UniversalToken, ERC1400 implementation (archived March 25, 2025)
• GitHub, ERC-3643: T-REX smart contracts implementing EIP-3643
• ERC3643 Association: ERC-3643 overview (read November 2026)
• ONCHAINID Docs: Concepts (read November 2026)
• Ethereum Improvement Proposals: ERC-7943, uRWA, Universal Real World Asset Interface (Final; created June 10, 2025)
• Guardian: Smart Contract Audit
• Guardian: OpSec Audit