Authored by: @JayLovesPotato, Four Pillars
Compiled by: AididiaoJP, Foresight News
Key Points
Regulated token standards on EVM are not converging into a single unified specification but are clearly divided by function. ERC-1450, ERC-3643, and ERC-7943 should therefore not be seen as competing standards, but rather as complementary components responsible for issuance, identity, execution, and integration, respectively.
Note: In simple terms, regulated token standards are technical specifications designed specifically for 'regulated tokens.' Ordinary tokens (like standard ERC-20) can be transferred and held by anyone with almost no restrictions. Regulated tokens, however, typically represent regulated real-world assets such as securities, fund shares, bonds, RWAs, etc. They transform the token from 'freely transferable by anyone' into 'compliant with financial regulations.'
The key difference between chains lies not in whether they possess regulatory functions, but in where these functions are implemented and enforced. EVM retains a high degree of flexibility at the individual asset contract level; Solana and Move-based chains place more functions within shared token frameworks; Stellar and XRPL embed them directly into the ledger; while Canton and Avalanche L1 extend further into the market and network operation layers.
The competitiveness of regulated token standards will likely depend more on their flexibility in adapting to regulatory changes than on the sheer number of features. A more pragmatic direction is building a compliance stack: standardizing recurring execution functions like freezing, forced transfers, and pre-transfer validation, while decoupling product-specific policies—such as identity providers, jurisdictional rules, and holding limits—into replaceable modules.
Even within the Ethereum EVM environment, which is most familiar to institutions, multiple ERCs address similar needs for regulated tokens. They generally support transfer restrictions, investor qualification checks, freezing, forced transfers, and lost asset recovery. However, the legal structures and operational authorities assumed by each standard differ significantly.
Beyond EVM, other chains have introduced comparable functionalities at the token program, ledger, or network level, further broadening the paths to implementing regulated assets.
This partly reflects the fact that regulated token standards have yet to form a clear structure. A more fundamental reason is that the functions required for regulated assets are difficult to cram into a single specification. Questions like who maintains the legal record of securities, which institution certifies investor qualifications, and how much control operators should retain in case of incidents—vary by product and jurisdiction.
Consequently, the market is moving towards an architecture where these functions are distributed across multiple layers and combined as needed, rather than pursuing a single, fully self-sufficient standard.
Regulated Token Standards on EVM
Early standards mostly attempted to directly replicate traditional financial operational structures into token contracts. Under ERC-1450, the Registered Transfer Agent is responsible not only for issuance and redemption but also for executing every transfer, with ordinary users prohibited from calling `transfer` and `approve`. This clarifies who maintains the legal record and who is responsible for responding to court orders or lost keys. However, it also moves away from the permissionless asset flow assumed by traditional DEXs and lending protocols.
ERC-3643, on the other hand, distributes regulatory functions across a token contract, an Identity Registry, a Trusted Issuers Registry, and independent compliance modules, rather than concentrating them under a single authority. Transfers are validated against claims signed by trusted entities, including KYC status, residency, and qualified investor status; issuers can also add rules like investor caps and country-specific holding limits. Retaining the basic ERC-20 structure while allowing for the replacement of individual rules is a meaningful advantage. The trade-off is the operational burden of coordinating multiple contracts, identity issuers, and privileged management roles.
The more recent ERC-7943 takes a different path: it does not define regulatory policies themselves but instead exposes a set of generic interfaces, including `canSend`, `canReceive`, `canTransfer`, frozen balance queries, and forced transfer functions. This enables wallets, exchanges, custodians, and DeFi services to interact with different regulated assets in a consistent manner. In other words, ERC-3643 is a stack for creating regulated tokens, while ERC-7943 is more akin to an integration layer connecting multiple stacks. The recent CMTAT implementation adding support for ERC-7943 further illustrates that this minimal interface can be layered on top of existing issuance standards.
ERC-7518 and ERC-8047 target more specialized needs. ERC-7518 applies conditions for different share classes, jurisdictions, and lock-up periods to individual ERC-1155 partitions; ERC-8047 records parent-child lineages as assets move, allowing enforcement to target specific fund flows rather than entire accounts. The former enables clearer differentiation of rights within a single asset; the latter allows for more precise post-hoc tracing and enforcement. They are more likely to serve as modules complementing broader compliance stacks rather than replacing an all-encompassing standard like ERC-3643.
Where Other Chains Place Regulatory Functions
Solana's approach is characterized by placing recurring token functionalities in a lower, shared layer. Functions like Transfer Hook, Permanent Delegate, and Confidential Transfer are provided through the universal Token Extensions library, while the Solana Attestation Service allows applications to reuse off-chain information like KYC status, geolocation, and investor qualifications. This reduces the need for each issuer to independently rebuild and audit the same functions. However, integration can still break when wallets or protocols don't support a particular extension. Moreover, DeFi applications must treat assets configured with powerful issuer controls like Permanent Delegate as an additional layer of counterparty risk.
Stellar and XRPL expose authorization, freezing, and clawback as properties of native ledger assets. These controls consistently apply in transfers and native transaction functions, meaning applications don't need to reinterpret custom logic for each token contract. Stellar is extending ledger asset connectivity with smart contract environments via Stellar Asset Contracts; XRPL is building around MPT, moving from authorized holding, freezing, and recovery towards privacy-related features. However, the deeper rules are embedded into the ledger, the more their evolution depends on network upgrades and consensus. Control settings may also more directly constrain an asset's liquidity and utility.
Sui and Aptos fall between EVM's contract-centric model and the ledger-native model. Sui records denylist statuses and global suspension authority for regulated assets in a Currency Registry; Aptos uses the Fungible Asset framework's TransferRef to freeze accounts or, when necessary, bypass restrictions via privileged transfers. Recurring execution functions like address blocking and emergency pauses are provided by the framework; more complex policies, such as investor categorization and country-specific holding limits, are left to independent Move modules. In this regard, their architecture most closely resembles the modular direction the EVM ecosystem itself is heading.
Canton extends the scope of regulation from tokens to the operation of entire markets. CIP-56 standardizes not only balance transfers but also includes party-specific information disclosure, recipient approval, and atomic Delivery vs. Payment (DvP); the Token Standard V2 is being tested on a separate DevNet in 2026. This design offers stronger operational consistency and privacy but also requires a dedicated identity and development environment. Consequently, existing public chain liquidity and applications cannot simply migrate over.
Avalanche L1 is better understood as an option for building regulated markets themselves, not just issuing regulated tokens. Operators can use allowlists to restrict transaction participants and contract deployers while requiring validators to meet KYC, AML, or licensing conditions. This stack can also connect identity providers like Jumio and Keyring to `txAllowlist`, making it well-suited for institutional-only exchanges or payment networks. The trade-off is operational: validators, upgrades, bridges, and liquidity must all be managed independently, incurring costs and fragmentation far exceeding those of issuing a single token on an existing EVM network.
Separating General Execution Functions from Regulatory Policies
Collectively, these paths reveal clear limitations at both extremes: neither embedding the entire regulatory stack into the network nor leaving all functionality to a single ERC is optimal. The general execution functions that recur across most regulated assets—pre-transfer validation, freezing, forced transfers, emergency pauses, and metadata disclosing management authority and associated risks—are best placed close to the token framework, ledger, or a minimal interface like ERC-7943. This reduces implementation variance and audit costs among issuers while enabling wallets, exchanges, and custodians to consistently identify an asset's control structure.
In contrast, decisions about which identity providers to trust, which jurisdictions to allow, how to calculate investor-level holding limits and lock-ups, and who can execute legal orders—are better left to asset-specific ERCs or independent modules. These rules vary by product and jurisdiction and must be updated with legal changes. Hard-coding them into network base rules would not only slow down upgrades but could also turn the policy choices of specific financial markets into defaults for a general-purpose chain.
In other words, the regulated token market is more likely to develop in the form of a compliance stack rather than converge on a single standard. In this model, replaceable identity, jurisdictional, and product-specific rules are built on top of general execution functions. Ethereum and the broader EVM ecosystem still hold advantages in policy flexibility and access to existing liquidity; ledger-native chains are stronger in execution consistency and operational simplicity; and dedicated networks like Canton are most prominent in privacy and institutional workflows.
Therefore, adoption is unlikely to be decided by which standard has the longest feature list. More important is whether regulatory policies can change without requiring asset reissuance or forcing wallets, exchanges, and custodians to rebuild integrations from scratch. Another critical test is whether external participants can clearly identify, assess, and manage the powerful controls embedded within an asset.
