ERC-1155 is a flexible multi-token standard: one contract can hold many fungible and non-fungible asset classes and move them in cheap batches. ERC-3643 is a permissioned token standard: every transfer is checked against an on-chain identity registry and a compliance module. If your token is a regulated security that must only ever sit in verified investors’ wallets, ERC-3643 does most of the heavy lifting for you. If you are managing a portfolio of distinct assets, high-volume units or semi-regulated instruments, ERC-1155 is often more efficient — but you will have to build the compliance layer yourself.
We have shipped both. Our real estate tokenization platform used ERC-1155 security tokens on Hedera with compliance enforced in custom contract logic, while many of the regulated issuances we advise on start from ERC-3643. This guide explains the trade-offs we weigh.
Key takeaways
- ERC-1155 = many token types (fungible and non-fungible) in one contract, batch transfers, shared metadata URI. No identity or compliance controls out of the box.
- ERC-3643 = an ERC-20-compatible security token tied to ONCHAINID identities, a trusted-issuer registry and modular compliance rules checked on every transfer.
- Choose ERC-3643 for equity, bonds and fund units sold under securities rules; choose ERC-1155 for portfolios of distinct assets, energy or carbon units and gaming-style economies — adding compliance hooks where needed.
- A token never creates legal ownership. The legal wrapper (SPV, fund, note) defines the rights; the standard enforces how those rights move.
What is real-world asset tokenization?
Real-world asset (RWA) tokenization represents rights in an off-chain asset — a building, a loan, a fund unit, a megawatt-hour, a tonne of avoided CO2 — as tokens on a blockchain. The token standard you choose determines how balances are stored, who can move them, what metadata travels with them and how easily wallets, custodians and trading venues can integrate. Pick wrongly and you end up rebuilding compliance features in a hurry, or paying gas for complexity you never needed.
For a broader primer, see What is RWA tokenization?.
What is ERC-1155?
ERC-1155, the Multi Token Standard, lets a single smart contract manage any number of token types, each identified by a numeric id. A token ID can have a supply of one (behaving like an NFT) or millions (behaving like a fungible token). Its core features are:
balanceOf(account, id)andbalanceOfBatchfor querying many balances at once.safeTransferFromandsafeBatchTransferFrom, which move one or many token types in a single transaction.- Receiver hooks (
onERC1155Received,onERC1155BatchReceived) so tokens are not lost in contracts that cannot handle them. - A single
uri(id)metadata pattern where{id}is substituted, so thousands of assets share one metadata template. - Operator approvals via
setApprovalForAll(there is no per-token allowance as in ERC-20).
What ERC-1155 does not include is any notion of investor identity, eligibility, jurisdiction, lock-ups, freezing or forced transfers. Any of those must be added through extensions — for example by overriding the internal _update hook to call a compliance contract, or by implementing the ERC-7943 uRWA interface on top.
What is ERC-3643?
ERC-3643 is the Ethereum standard that grew out of the T-REX (Token for Regulated EXchanges) protocol. It is a Final ERC, supported by a non-profit industry association, and it is designed specifically for regulated securities. An ERC-3643 deployment is a small suite of contracts:
| Component | Role |
|---|---|
| Token | ERC-20-compatible security token with agent functions (mint, burn, pause, freeze, forced transfer, recovery) |
| Identity Registry | Maps wallet addresses to ONCHAINID identity contracts and investor country |
| Trusted Issuers Registry | Lists the KYC providers and agents allowed to issue claims |
| Claim Topics Registry | Defines which claims (e.g. KYC passed, accredited investor) a holder must have |
| Modular Compliance | Pluggable rules such as country restrictions, max holders, max balance, time locks |
On every transfer the token asks two questions: is the receiver a verified identity with the required claims? and does this transfer satisfy every compliance module? If either answer is no, the transfer reverts. That is the property regulators and transfer agents care about: tokens physically cannot reach an ineligible wallet.
ERC-1155 vs ERC-3643 at a glance
| Criterion | ERC-1155 | ERC-3643 |
|---|---|---|
| Token model | Many fungible and non-fungible IDs in one contract | One fungible (ERC-20-compatible) token per contract |
| Identity | None natively; add via custom logic | ONCHAINID linked through the Identity Registry |
| KYC/AML enforcement | Custom-built | Built in through claims from trusted issuers |
| Transfer restrictions | Open unless you override hooks | Every transfer validated by compliance modules |
| Freeze / forced transfer / recovery | Custom-built | Standard agent functions |
| Batch transfers | Native, gas-efficient | Batch functions for agents (e.g. batch mint, batch transfer) |
| Metadata | Per-ID URI with {id} substitution |
Token-level name, symbol, decimals; documents off-chain |
| Wallet & exchange support | Broad (NFT marketplaces, wallets) | Growing; permissioned venues and specialist custodians |
| Development effort for securities | Higher — you build compliance | Lower — compliance framework exists |
| Typical RWA fit | Property portfolios, energy/carbon units, mixed asset pools | Equity, bonds, fund units, regulated real estate shares |
Key architectural differences
Identity and compliance
With ERC-1155 you decide where compliance lives. On our real estate platform, the KYC/AML module was deliberately pluggable so a regulated provider could be connected without changing token logic, and transfer restrictions were enforced inside the token contract. That works well — but it is your code, so it must be specified, tested and audited as such.
ERC-3643 gives you a battle-tested pattern: claims written to ONCHAINID by trusted issuers, verified by the registry, enforced by modular compliance. You still need legal advice on which claims and rules apply, but the plumbing exists.
Transfer control and ownership model
ERC-1155 balances are keyed by (account, id), so one wallet can hold slices of fifty buildings in one contract. ERC-3643 is one token per instrument, so fifty buildings usually means fifty token contracts (often deployed through a factory) sharing registries. The ERC-3643 approach is cleaner for cap-table management of each instrument; the ERC-1155 approach is cleaner for portfolio views and batch operations.
Metadata and batch efficiency
ERC-1155’s shared URI scheme and batch transfers are genuinely useful when you have many small, distinct units — for example the ENERGY tokens in our electricity tokenization project, where one token equals one watt-hour and readings arrive continuously. ERC-3643 is not designed for that pattern.
Where each standard fits
When ERC-1155 may be the better choice
- Portfolios of distinct assets under one programme — separate token IDs per property, vintage or pool.
- High-volume units such as energy, carbon credits or loyalty points, where batch minting and burning matter.
- Mixed fungible and non-fungible assets — for example a title NFT plus fractional shares in the same contract.
- Semi-regulated or closed-loop programmes where a whitelist or ERC-7943 interface is sufficient.
When ERC-3643 is usually the better choice
- Tokenized equity, bonds and fund units offered under securities law.
- Real estate SPV shares sold to investors across several jurisdictions with different eligibility rules.
- Issuances needing transfer-agent controls — freezes, recovery, forced transfers on court order.
- Programmes that want ecosystem interoperability with custodians and venues already supporting ERC-3643.
Legal ownership and token representation
Whichever standard you choose, the token is a record of rights defined elsewhere — in the articles of an SPV, a fund prospectus, a note or a trust deed. Regulators in the EU (MiCA and the DLT Pilot Regime), the UK, the US, the UAE, Singapore and Switzerland all look at the substance of the instrument rather than the token standard. Our SPV guide covers this in depth: Legal structures for tokenization.
A five-question decision framework
- Is the token a security in any target jurisdiction? If yes, start with ERC-3643 unless you have a strong reason not to.
- How many distinct assets will you issue? Dozens of IDs with shared rules favour ERC-1155; one instrument per legal entity favours ERC-3643.
- Who must be able to stop a transfer? If agents need freeze, forced-transfer and recovery powers, ERC-3643 provides them natively.
- Where will tokens trade? Check which standards your intended custodian, transfer agent and venue support today.
- How much custom code are you prepared to audit? Every compliance feature you build on ERC-1155 is code you own.
If you are still unsure, our token standard decision guide walks through more asset types.
Security, scalability and interoperability
Both standards are mature, but the risks differ. ERC-1155’s receiver callbacks introduce re-entrancy surface; use checks-effects-interactions and re-entrancy guards. ERC-3643’s compliance modules add gas to every transfer and must be tested as a system — a misconfigured module can freeze a whole cap table. In both cases, plan for an independent smart contract audit and an upgrade strategy with clear governance.
Worked example: one portfolio, two designs
Imagine a sponsor tokenizing five commercial buildings for professional investors in four EU countries and Switzerland, with quarterly rent distributions and an internal secondary market.
Design A — ERC-1155 with compliance hooks
- One contract; token IDs 1–5, one per building.
- An eligibility contract fed by the KYC provider decides canReceive(investor, id).
- Distributions computed per ID; investors claim all five in one transaction.
- Agent functions (freeze, forced transfer) added as custom code, exposed through the ERC-7943 multi-token interface for interoperability.
- Pros: one contract, portfolio view, efficient batch distributions. Cons: more custom compliance code to audit; fewer custodians support ERC-1155 out of the box.
Design B — five ERC-3643 tokens sharing one identity registry - Five token contracts deployed from a factory, one per building SPV. - Shared Identity Registry Storage, claim topics and trusted issuers. - Modular compliance per token (e.g. different country lists). - Distributions computed per token; investors claim from each (or via an aggregator contract). - Pros: standard security-token framework, broad ecosystem, regulator familiarity. Cons: more contracts; portfolio views and batch operations need extra tooling.
Both are valid. In our real estate project, the client prioritised a single multi-property marketplace and efficient distributions, so we chose Design A on Hedera. A sponsor planning to list each building’s token with third-party venues would likely choose Design B.
Cost and effort comparison
| Effort area | ERC-1155 + hooks | ERC-3643 |
|---|---|---|
| Token contracts | Moderate (custom compliance) | Low (framework) |
| Identity integration | Custom eligibility contract | ONCHAINID + claims |
| Audit scope | Larger (custom logic) | Smaller (known framework + config) |
| Portfolio operations | Native batch | Aggregation layer needed |
| Venue/custody integration | Check support | Broader support |
Hybrid: get the best of both
Some programmes combine the two: ERC-3643 for investor-facing securities and ERC-1155 for operational units (for example energy or carbon units that feed the securities’ cash flows). Others implement ERC-7943 on an ERC-1155 contract so venues that understand ERC-3643-style calls (canTransfer, forcedTransfer, frozen balances) can integrate with minimal effort. See ERC-7943 explained.
Frequently asked questions
ERC-1155 manages many token types in one contract and focuses on efficiency and flexibility. ERC-3643 manages one regulated token per contract and enforces identity checks and compliance rules on every transfer.
Yes, if you add transfer restrictions and identity checks yourself or implement an interface such as ERC-7943. We have delivered ERC-1155 security tokens for real estate with compliance enforced in the contracts.
It enforces the results of KYC/AML. Regulated providers verify investors off-chain and issue claims to their ONCHAINID; the token then refuses transfers to wallets without the required claims. Personal data stays off-chain.
For many small transfers of different asset types, ERC-1155 batch operations are cheaper. ERC-3643 adds compliance checks to each transfer, which costs more gas but delivers enforcement you would otherwise build and audit yourself.
Yes, through a token swap or a migration contract, but it requires investor communication and careful snapshotting. It is cheaper to choose the right standard at design time.
Regulators focus on outcomes — eligibility, investor protection, record accuracy — not standards. ERC-3643’s documented framework can make those outcomes easier to demonstrate.
Yes. Platforms often issue different instruments with different standards while sharing KYC, wallets and portals.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
