Most conversations about token standards still start with technology: “Is it on Ethereum or Stellar?”, “Is it ERC‑20 compatible?”, “Does it run on Canton?”
For heads of markets, treasury, and operations, those are secondary questions. The real ones are: will this token behave like a regulated security or cash instrument, will it fit our control framework, and will regulators accept it as robust as today’s infrastructure?
That comes down to concrete behaviours:
- Who can hold it
- How transfers are authorised
- How errors are fixed
- How much is standardised rather than reinvented in bespoke code.
This post outlines a simple feature matrix for tokenized assets and applies it to seven widely used standards: ERC‑20, ERC‑1400, ERC‑3643 (T‑REX), CIP‑56, Stellar native assets, Stellar Asset Contracts (SEP‑41 / SAC), and TIP‑20.
The goal is not to crown a winner, but to make the trade‑offs visible so you can choose standards that match your product set, control framework, and regulatory profile.
The Nine Behaviours That Matter
Instead of starting from chain wars, we start from nine behaviours that show up repeatedly in capital‑markets requirements, RFPs, and architecture diagrams.
These are the kinds of questions that come up when you talk to operations, compliance, and legal about tokenised bonds, fund units, money‑market instruments, or tokenised cash.
- Opt‑in to receive: Can an account choose whether it is able to receive a given token, or can anyone push assets to it unilaterally? This is central for regulated portfolios that cannot legally hold certain instruments and want to avoid “airdrop risk” and unwanted positions.
- Offer–accept transfers: Is a transfer always a one‑sided “push”, or can the standard express a two‑sided “offer→accept” flow where both parties participate before settlement? That question often decides whether on‑chain settlement can mirror existing bilateral workflows between trading desks, clients, and venues.
- Pre‑approved / delegated transfers: Can an account set standing instructions, such as pre‑approvals, mandates, or delegated rights, so that not every transfer requires a fresh signature but still happens under explicit policy? Think of this as the on‑chain analogue of mandates given to administrators, sub‑custodians, or paying agents.
- Allow‑lists and block‑lists: Does the standard give you a canonical way to express which investors or accounts are allowed or blocked from holding or receiving a given asset, or is that left entirely to bespoke contract logic and off‑ledger records? This is where suitability, distribution restrictions, and KYC status typically surface.
- Forced transfer / clawback: In some regimes, the ability to reverse or re‑route balances, after fraud, operational error, sanctions, or court orders, is not a nice‑to‑have but a requirement. Other regimes explicitly forbid that kind of control. The important part is whether the feature is available and standardised, not whether you personally like it.
- Freeze and lock controls: Can you freeze a position, suspend transfers from a particular holder, or lock units as collateral without destroying them? In capital markets this can be as mundane as a trading halt or a record‑date freeze for a corporate action, or as complex as collateral management in a margin or repo arrangement.
- Mint and burn controls: All token standards let you change supply, but they differ in how strongly they structure lifecycle operations: who is allowed to mint, under what conditions redemptions or burns can happen, and whether those controls are visible in a standard way to custodians, fund administrators, and risk systems.
- Native DvP and multi‑leg workflows: Delivery versus Payment and multi‑asset trades (for example, securities versus cash, collateral versus funding, basket rebalancing) can be modelled in many ways. The question here is whether the standard itself anticipates those workflows, or whether you are expected to build bespoke settlement logic on top, or rely on off‑chain netting and matching engines.
- Privacy model: Finally, how visible are balances and transfers? Fully public ledgers make transparency easy but can clash with confidentiality requirements around positions, client lists, and trading activity. At the other end, some platforms offer ledger‑level privacy where only involved parties and entitled observers see holdings and flows. Others sit in the middle, using techniques like off‑chain data, partitioning, or selective disclosure to keep sensitive details away from the public record.
Taken together, these behaviours give you a more useful lens than questions like “is this token EVM‑compatible?” or “how fast are blocks?” when you are designing infrastructure for real markets.
High‑Level Feature Matrix
The following matrix applies those nine behaviours to seven token standards that feature heavily in institutional conversations today. It is intentionally coarse grained: Yes / No / Partial rather than implementation detail.
- Yes: Supported in a standardised way across typical deployments.
- Partial: Achievable in practice, but either not standardised or heavily dependent on how an issuer configures their contracts.
- No: Not available in the base standard and requires custom patterns or external systems.
| Feature |
ERC-20 |
ERC-1400 |
ERC-3643 |
CIP-56 |
Stellar native |
SEP-41 / SAC |
TIP-20 |
| Opt-in to receive |
No |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| Offer–accept flows |
No |
No |
No |
Yes |
No |
Partial |
No |
| Pre-approved / delegated transfers |
Partial |
Partial |
Yes |
Yes |
Partial |
Partial |
Yes |
| Allow-list / block-list |
Partial |
Yes |
Yes |
Yes |
Partial |
Partial |
Yes |
| Forced transfer / clawback |
No |
Yes |
Yes |
Partial |
Yes |
Yes |
Yes |
| Freeze / lock controls |
No |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| Mint / burn controls |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| Native DvP / multi-leg workflows |
No |
Partial |
Partial |
Yes |
No |
Partial |
Partial |
| Privacy |
No |
Partial |
Partial |
Yes |
No |
Partial |
Partial |
A few things to note:
- This is intentionally schematic. Real deployments often add, restrict, or re‑implement features depending on regulation, risk appetite, and platform constraints.
- “Partial” is not a judgement. It simply means “possible, but not guaranteed by the base standard.”
The interesting part is not whether a given cell says “Yes” or “No” but why, and what that implies for the design of your front‑to‑back stack.
Three Design Patterns Hiding in the Matrix
Looking across the matrix, you can see three broad design patterns emerge.
1. Minimal base and maximum composability
Standards like ERC‑20 sit at one end of the spectrum. They define a very small surface area and leave almost everything else to the application layer. Transfers are unilateral pushes. There is no built‑in concept of offer–accept, allow‑lists, or clawback. Privacy is determined entirely by the underlying public ledger.
The advantage is simplicity and ubiquity, which matters for distribution and liquidity. The cost is that every issuer who needs regulated behaviour has to reinvent and re‑audit their own “policy layer” on top, often with slightly different semantics. Custodians, fund administrators, and venues then need to learn each of those policies case by case.
2. Regulated behaviour as extensions
Security‑token standards like ERC‑1400 and ERC‑3643 push further. They introduce identity, allow‑lists, transfer restrictions, controller operations, and recovery patterns as part of the standard. You see many more “Yes” entries for allow‑lists, forced transfer, and freeze or lock controls.
This makes them more natural for regulated assets such as private placements, tokenised equities, or restricted bonds, but it also means applications and intermediaries need to speak a richer, more opinionated language: partitions, controllers, identity registries, and so on.
At the same time, they still live on fully public ledgers, so privacy is usually handled by pushing sensitive data off‑chain or by using partitions to approximate segregation rather than by hiding balances and flows at the ledger level.
3. Workflow‑centric and privacy‑aware
At the other end you have standards and platforms that start from capital‑markets workflows and privacy, then work backwards to tokens.
Some standards, such as CIP‑56 on Canton, bake offer–accept flows, receiver controls, administrative policies, and atomic multi‑leg settlement into a small set of interfaces, and run on a ledger where balances and transfers are private to the parties and entitled observers.
Other ecosystems take different routes, for example, Stellar trustlines and clawback flags, or TIP‑20’s focus on policy‑aware payments for stablecoins, but they share an emphasis on modelling institutional operations more explicitly.
The trade‑off here is that you gain a lot of structure and built‑in behaviour, but lose some of the “anything goes” freedom of a minimal standard.
How to Use This Matrix in Practice
For most regulated institutions, the point is not to pick a “perfect” standard and ignore the rest. Many banks, asset managers, and market infrastructures already operate across multiple chains and standards and will continue to do so.
Instead, this kind of feature matrix is useful in three concrete ways:
- Requirements capture: When a business sponsor says “we need clawback for operational errors”, “we cannot accept unsolicited deposits into client accounts”, or “regulators expect true DvP for this product”, you can map those directly to the rows in the matrix and see which standards are natural fits and which would require significant additional engineering or off‑ledger processes.
- Architecture and risk design: If a feature is “Yes” in the standard, you still need to decide how you will configure and govern it: who can trigger a clawback, who manages allow‑lists, which flows are offer→accept versus pre‑approved, and how freezes interact with margin and collateral. If a feature is “Partial” or “No”, you know up front that it will be a custom build or require legal and operational workarounds.
- Communication with partners: Custodians, venues, and service providers often talk past each other when they say “we support ERC‑20” or “we support security tokens”. A neutral feature matrix makes it easier to ask specific questions: “Do you support opt‑in to receive?”, “How do you expose freeze events into your reconciliation stack?”, “What does DvP look like in your environment?”
Used this way, the matrix is less about scoring standards and more about making assumptions explicit, so that traditional finance institutions can adopt tokenisation without giving up the controls they rely on today.
