ERC-3643, also known as T-REX (Token for Regulated EXchanges), is the standard the institutional tokenisation market converged on. Developed by Tokeny in Luxembourg from 2019 onwards and finalised as an EIP in 2021, it is now the implementation backbone for the largest deployed tokenised funds, almost certainly including BlackRock's BUIDL, Apollo's ACRED, and (with the hedge that the contract internals are not fully public) JPMorgan Asset Management's MONY. The reason it won is less about features than about architecture: it took the lesson from ERC-1400 and made the separation of token logic from compliance logic the central design commitment.
The four-contract architecture
Token, Identity Registry, Compliance, Trusted Issuers Registry. A T-REX deployment is not one contract, it is a set of four that talk to each other. Each has a single responsibility, and each can be upgraded or reconfigured without touching the others. The token contract holds balances and exposes the ERC-20 surface. The Identity Registry maintains the on-chain identity of every approved holder. The Compliance contract enforces transfer restrictions through modular rules. The Trusted Issuers Registry lists which entities are authorised to issue identity claims (KYC verifications) that the Identity Registry will accept.
That sounds bureaucratic. It is, deliberately. The bureaucracy is the point: each piece can be replaced when the regulatory or operational environment changes, without a token upgrade.
Token contract
Lightweight, mostly-ERC-20. The token holds balances, total supply, and the standard transfer, transferFrom, balanceOf interface. It does not hold compliance rules. It does not hold identity data. When a transfer is requested, the token contract makes two outbound calls before changing state: one to the Identity Registry to confirm the recipient has a valid identity, and one to the Compliance contract to confirm the specific transfer is allowed under current rules. If either call fails, the transfer reverts.
Because the token contract changes rarely (basically only when a token-level bug is found), it can sit behind a tighter governance regime than the compliance contract, with longer time-locks and a higher signing threshold for upgrades.
Identity Registry and OnchainID
Identity is a contract, not a wallet attribute. Each approved holder has an OnchainID (an identity contract deployed at a known address) which carries claims signed by trusted issuers. A claim is a signed statement of the form "this identity has been KYC-verified", "this identity is a qualified purchaser", "this identity is in the United Kingdom and tax-resident there." The wallet itself is just a key; the wallet is linked to an OnchainID, and the OnchainID is the thing the registry actually queries.
This indirection matters operationally. A holder who rotates wallets (key rotation, custody migration, multi-sig membership change) does not lose their KYC status, they update the wallet pointer on the OnchainID. A holder whose KYC lapses does not lose their wallet, the claim on the OnchainID expires and the registry stops returning a valid identity for that holder.
Compliance contract and modules
Modular rules, hot-swappable. The Compliance contract does not itself encode jurisdictional logic. It is a thin orchestrator that calls into a list of compliance modules, each of which implements a specific check. A jurisdiction-restriction module returns false for transfers to non-approved jurisdictions. A QP-threshold module returns false for transfers to unverified-purchaser identities. A daily-volume-cap module returns false for transfers above a configured limit per holder. A holding-period module returns false during a lock-up.
When the QP threshold changes (the SEC revises a definition, MAS adjusts an institutional-investor cut-off), the module is replaced or reconfigured. The token does not redeploy. Holders do not migrate. Indexers, wallets, and DeFi-adjacent infrastructure do not have to be told about a new contract address. This is the load-bearing innovation of the design.
Trusted Issuers Registry
Pluggable KYC providers. Different deployments need different verifiers. A US-domiciled institutional fund may accept claims from Securitize and from an internal compliance team. A pan-Asian fund may accept claims from a Singapore-licensed verifier, a Tokyo-licensed one, and an internal Hong Kong team. The Trusted Issuers Registry is just a list of public keys whose signed claims the Identity Registry will treat as authoritative, with per-issuer rules about which claim topics each is permitted to issue.
That separation lets a deployment add or remove KYC providers without touching the rest of the stack, which is what makes ERC-3643 a workable substrate for cross-border offerings.
The transfer flow, end to end
A holder calls token.transfer(to, amount). Before any state change, the token executes:
require(identityRegistry.isVerified(to), "Recipient not verified");
require(compliance.canTransfer(msg.sender, to, amount), "Compliance check failed");
identityRegistry.isVerified(to) walks the OnchainID for to, checks that the claims required for this token (KYC, jurisdiction, investor class) are present, current, and signed by trusted issuers. compliance.canTransfer iterates over the configured modules and returns false if any module rejects.
If both pass, the token updates balances and emits the standard ERC-20 Transfer event. To an external indexer the transfer looks identical to any ERC-20 transfer; the eligibility plumbing is invisible above the interface.
Why MONY almost certainly uses this
Three converging signals. First, JPMAM as a regulated MMF issuer needs compliance-at-the-protocol-level enforcement; relying on off-chain controls alone would not satisfy the supervisory expectation for a 506(c) plus 3(c)(7) wrapper holding QP money. Second, BUIDL is widely understood to use T-REX patterns and MONY is structurally a close analogue. Third, the operational integration with Morgan Money requires the identity-registry pattern that ERC-3643 standardises, and reinventing that primitive in a custom standard for one product would be operationally indefensible.
The honest hedge: MONY's exact contract architecture is not fully public. The token address is known but the implementation choices may include a custom variant rather than vanilla T-REX. Conservative framing in conversation is "almost certainly ERC-3643 or a close institutional variant" rather than "definitely T-REX vanilla."
Part 4 takes the case where the underlying asset cannot settle instantly and the deposit-and-redemption mechanic itself has to change shape. ERC-3643 handles eligibility; ERC-7540 handles asynchrony.