ERC-3643 is a standardized permissioned-token framework: on-chain identity plus modular compliance, checked on every transfer. STV3 is a Diamond-standard upgradeable architecture where compliance plugs in as a transfer-layer facet. One is a standard, the other an architecture.
These two get compared head-to-head. They shouldn’t be. They answer different questions.
Why
ERC-3643, also called T-REX, is an established standard for permissioned tokens. It defines two things: an on-chain identity registry (ONCHAINID) that ties a wallet to a verified identity, and a modular compliance contract that holds the rules. Every transfer is checked against both. If the receiver isn’t verified, or a compliance rule fails, the transfer reverts. The value is standardization: the interface is fixed, so wallets, exchanges, and other issuers can interoperate against a known shape. It is widely adopted in the security-token space.
STV3 is a different kind of thing. It is an ERC-20 built on the Diamond Standard (EIP-2535), a modular, upgradeable proxy where behavior lives in swappable facets. The core ERC-20 facet is immutable. Around it sit DiamondCut and DiamondLoupe (ERC-165) for upgrade management, a CCTFacet with ERC-677 transferAndCall, role-based mint and burn, and Chainlink CCIP for cross-chain, and a DefaultValidationFacet that exposes beforeUpdateValidation and afterUpdateValidation hooks. That validation facet is where compliance rules would plug in, at the transfer layer, before and after state changes.
So the comparison is a standard versus an architecture. ERC-3643 specifies what compliance looks like and how identity is checked. STV3 specifies where compliance attaches and how the token can change over time.
The edge cases
Be precise about what STV3 ships today. The public STV3 repository presents the validation facet as an extension point “prepared for future implementation.” It is a hook, not a rule set. The repo does not implement specific transfer restrictions, and it does not reference ERC-3643 or ERC-7943. So STV3 does not do ERC-3643’s job out of the box, and it doesn’t claim to. The Diamond gives you the seam; the rules are yours to write into it.
ERC-3643’s identity model is a genuine advantage worth conceding. ONCHAINID gives you a portable, on-chain claim about who a holder is. STV3’s architecture doesn’t prescribe an identity layer at all. You would bring your own, whether that’s an ERC-3643-style registry, an off-chain allowlist, or something else, and enforce it in the validation facet.
Upgradeability cuts both ways. A Diamond lets a security token adapt for years without a migration. It also means the upgrade key is a control surface a regulator and your holders will ask about. That is a governance question, not a code question.
What this means for your structure
Pick by the constraint you actually have. If you need interoperability and a standard identity model that other venues recognize today, ERC-3643 is the mature, interoperable choice. If your priority is an upgradeable architecture where compliance is a pluggable facet and cross-chain is native, the Diamond pattern STV3 uses fits better, provided you accept responsibility for writing and governing the rules.
These are not mutually exclusive. You can enforce ERC-3643-style checks inside a Diamond’s validation hook. The standard tells you what to check; the architecture tells you where to put it. Stobox enforces compliance at the token transfer layer and backs open standards, including ERC-7943 (uRWA); see ERC-3643 vs ERC-7943.
Gene Deyev’s take
People frame this as a fight. It isn’t. A standard and an architecture solve different problems, and the honest answer is you often want both. ERC-3643 earned its adoption, and its identity model is real value, not marketing. What I care about is that a security lives for years, and the rules around it will change more than once. That’s why I favor a modular, upgradeable base with compliance enforced at the transfer layer, so you can adapt without a migration and without asking holders to move their tokens. But upgradeability is a governance responsibility, not a free lunch. Whatever you choose, keep it on open standards. The ownership record has to outlive any one contract, any one vendor, including us.
— Gene Deyev, CEO & Co-Founder, Stobox. Co-author of the Stobox Tokenization Framework and the STV3 protocol; ERC-7943 backer; SEC Crypto Task Force roundtable participant (2025).
Related questions
- ERC-3643 vs ERC-7943
- How to choose a tokenization platform
- What happens if the platform disappears?
- Security token liquidity
Last updated: 2026-07-12.