Security Token Standards: What Issuers Should Know

Two token standards now carry Final status on the Ethereum improvement proposal track for permissioned real-world assets. ERC-3643, created in July 2021, specifies a full framework with an on-chain identity registry and a pluggable compliance contract. ERC-7943, created in June 2025 and finalized this year, specifies a minimal interface that can sit on top of a fungible, non-fungible or multi-token base. An issuer tokenizing a commercial property, a carbon credit inventory or a gold reserve has to choose one, and the choice determines what the token can do on day one and who can build on it later.

What a security token standard actually standardizes

A plain fungible token has one rule: whoever holds it can send it. A security token adds a second rule before every transfer: is this transfer allowed? The standard defines where that question gets asked, who can answer it, and what happens when the answer is no.

Both standards agree on the core verbs. A transfer check, named `canTransfer` in both, runs before tokens move. A restricted `forcedTransfer` lets an authorized agent move tokens without the holder's signature, for enforcement or recovery. A freeze function locks some or all of a wallet's balance. Both require that sensitive functions sit behind access control, and ERC-7943 deliberately kept the ERC-3643 naming so that tooling written for one can read the other, per the ERC-7943 specification.

Where they differ is how much they prescribe around those verbs. That difference is the whole decision.

ERC-3643: the framework approach

ERC-3643 bundles the token with two further contracts. An identity registry maps each wallet to an identity contract and a country code, and exposes an `isVerified` check against the claims that identity carries. A compliance contract holds the rules of the offering itself, either custom-built or assembled from modules that can be added and removed, and is consulted through `canTransfer` on every transaction. The token must be pausable. Forced transfers bypass the compliance rules but still require the receiver to be on the registry. Token recovery, for an investor who loses wallet access, is supported and recorded on-chain, as the ERC-3643 specification describes.

For an issuer, this is attractive because the questions are answered. Who is allowed to hold the token? Whoever is in the registry with the right claims. How do I restrict holders by jurisdiction? Country code in the registry plus a module in the compliance contract. What happens when a holder loses their keys? Recovery, with a record. A CRE sponsor running a 506(c) raise with a 12-month lockup and a cap on non-US holders can express every one of those constraints in the standard's own vocabulary.

The cost is weight. The identity registry is a shared piece of infrastructure that someone has to operate, and the claims inside it have to come from an issuer the registry trusts. A token on this standard is, by design, not freely composable with permissionless protocols, because every counterparty must be in the registry first. That is a feature for a private placement. It is a constraint for anyone who wants the token to be collateral or a trading pair somewhere the issuer does not control.

ERC-7943: the interface approach

ERC-7943 takes the opposite view. It mandates no identity system and no role model. It defines the interface and leaves the implementation to the issuer. The interface extends a base token standard, signals support through interface detection, and requires four things: a transfer-level check, account-level eligibility checks, a restricted forced transfer, and frozen-balance accounting.

The notable design decision is the split between `canSend` and `canReceive` on the account side and `canTransfer` on the transaction side. ERC-3643 does not run account-level checks inside its transfer check. ERC-7943 requires it. The practical effect is that an issuer can impose one-way restrictions: a wallet can be blocked from receiving new tokens while still being allowed to sell what it has. For a fund that has closed to new investors in one jurisdiction but must let existing holders exit, that is the exact control needed. For a carbon credit token where a registry account has been suspended pending review, the same control lets the holder liquidate without the issuer having to force anything.

The cost is that the standard does not tell you how to decide who is eligible. The issuer has to bring an identity source, a rule engine and an administrator model. That is more work up front, but it means the eligibility logic can be whatever the deal requires, and the token can inherit from a base standard that other venues already understand.

What this means for a real-asset issuer

The two standards are not competing for the same deal. They are competing for the same decision at different points in an asset's life.

• Primary issuance. A property or a well interest sold to a known list of accredited investors is well served by the framework approach. The registry is the cap table. Eligibility is the KYC file. The constraints are legal, not technical, and the standard encodes them directly.
• Secondary liquidity. The moment an issuer wants the token to trade on a venue it does not operate, or to be accepted as collateral by a lender it has not onboarded, the minimal interface starts to matter. A venue can check `canSend` and `canReceive` without knowing anything about the issuer's registry. We have written about why transfer controls are the thing a secondary market actually tests, and the standard determines how legibly those controls are exposed.
• Multi-asset structures. A carbon credit vintage, a basket of gold bars, or a portfolio of leases is naturally a multi-token structure. ERC-7943 extends to multi-token bases natively. ERC-3643 is built on a fungible base. An issuer with heterogeneous assets under one wrapper will find the interface approach fits better.
• Enforcement. Both support forced transfers and freezes. The difference is whether the transfer bypasses the compliance rules, as in ERC-3643, or is simply a restricted function that emits a distinct event, as in ERC-7943. Court-ordered transfers and lost-key recovery work under either, but the audit trail reads differently.

None of this replaces the legal structure. A token on either standard still represents an interest in an SPV, a trust or a fund, and the governing documents still control what a transfer means. The standard is the enforcement layer, not the contract. A sponsor working through how an asset moves from legal entity to on-chain record should expect the standard to be chosen around the structure, not the other way round.

The convergence that issuers should watch

The two standards are already converging in naming, and ERC-7943 explicitly chose `forcedTransfer` over a shorter alternative to stay backward compatible with ERC-3643. That is a signal that the market expects both to persist, with the framework used where the issuer controls the whole lifecycle and the interface used where the token has to be read by strangers.

Beyond Ethereum and its rollups, the same pattern is appearing in other environments, usually with the same four verbs: eligibility, transfer check, freeze, forced move. The vocabulary is becoming standard even where the code is not. For the digital capital markets this is the useful development, because a tokenized real asset is only as liquid as the number of venues that can read its rules without a phone call. Readers new to the stack can start with what RWA tokenization is before choosing between the two.

The question for an issuer is no longer whether to use a permissioned standard. It is which layer of the stack should hold the rules: inside the token, where only the issuer can change them, or at the interface, where any venue can read them. For a private placement that will never trade, the first is simpler. For a gold reserve, a carbon inventory or an income-producing property that the issuer hopes will find secondary buyers, the second is where liquidity comes from.

Prefer email? Send the offering memo or a short asset summary to deals@commertize.com. We reply within one business day, with no obligation to engage us.